Книга
← К списку книгЗагрузка разделов…
активнаАктивные записи участвуют в каталоге и синках. Неактивная книга скрыта, но не удалена из базы.
Книга
Внутренний мирWindows Server2003, SP1 и R2
Уилльям Бозуэлл
Внутренний мир Windows Server 2003, SP1иR2
Уилльям Бозуэлл
Издательский дом “Вильямс" Москва ♦ Санкт-Петербург ♦ Киев 2006
ББК 32.973.26-018.2.75
Б76
УДК 681.3.07
Издательский дом “Вильямс”
Главный редактор С.Н. Тригуб
Зав. редакцией В.Р. Гинзбург
Перевод с английского В.С. Иващенко, ОЛ. Лещинского
Под редакцией В. С. Иващенко
По общим вопросам обращайтесь в Издательский дом “Вильямс" по адресу:'info@williamspublishing.com, http://www.williamspublishing.com
115419, Москва, а/я 783; 03150, Киев, а/я 152
Бозуэлл, Уилльям.
Б76 Внутренний мир Windows Server 2003, SP1 и R2. : Пер. с англ. — М. : ООО “И. Д. Вильямс", 2006. — 1264 с.: ил. — Парал. тит. англ.
ISBN 5-8459-1058-7 (рус.)
Эта книга посвящена серверной операционной системе Windows Server 2003 R2 компании Microsoft. В ней доходчиво и очень подробно рассмотрены все основные механизмы управления сервером, к которому может предоставляться доступ компьютерам, работающим под управлением около десятка различных версий настольных операционных систем Windows.
После изучения процесса развертывания Windows Server 2003 на примере одного сервера последовательно рассматриваются вопросы модернизации серверов, установки нового аппаратного обеспечения, настройки подсистемы преобразования имен, развертывания и интеграции службы DNS, установки и настройки службы Active Directory, а также предоставления для совместного доступа ресурсов сервера под управлением Windows Server 2003 авторизованным клиентам как в локальной сети, так и в сети Интернет. Особое внимание уделяется новым возможностям обеспечения безопасности.
Эта книга предназначена для профессионалов в области информационных технологий и станет настольным справочником для системных администраторов.
ББК 32.973.26-018.2.75
Все названия программных продуктов являются зарегистрированными торговыми марками соответствующих фирм.
Никакая часть настоящего издания ни в каких целях не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами, будь то электронные или механические, включая фотокопирование и запись на магнитный носитель, если на это нет письменного разрешения издательства Addison-Wesley Publishing Company, Inc.
Authorized translation from the English language edition published by Addison-Wesley, Copyright © 2003.
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the publisher.
Russian language edition is published by Williams Publishing House according to the Agreement with R&I Enterprises International, Copyright © 2006.
ISBN 5-8459-1058-7 (pyc.)ISBN 0-7357-1158-5 (англ.)ISBN 5-8459-1058-7 (pyc.)ISBN 0-7357-1158-5 (англ.)© Издательский дом “Вильямс”, 2006
ISBN 5-8459-1058-7 (pyc.)
ISBN 0-7357-1158-5 (англ.)
ISBN 5-8459-1058-7 (pyc.)
ISBN 0-7357-1158-5 (англ.)
© Pearson Education, Inc., 2003
Оглавление
Предисловие25
Об авторе29
Глава 1. Установка и настройка Windows Server 200331
Глава 2. Модернизация и автоматизированная установка103
Глава 3. Добавление аппаратных средств151
Глава 4. Преобразование имен NetBIOS197
Глава 5. Управление службой DNS239
Глава 6. Службы Active Directory297
Глава 7. Управление репликацией Active Directory369
Глава 8. Проектирование доменов Windows Server 2003423
Глава 9. Развертывание доменов Windows Server 2003463
Глава 10. Обслуживание Active Directory519
Глава 11. Безопасность доступа по сети и протокол Kerberos551
Глава 12. Управление групповыми политиками649
Глава 13. Управление безопасностью Active Directory711
Глава 14. Настройка подсистемы хранения данных741
Глава 15. Управление файловыми системами785
Глава 16. Управление совместно используемыми ресурсами857
Глава 17. Управление шифрованием файлов947
Глава 18. Управление инфраструктурой открытого ключа989
Глава 19. Управление операционной средой пользователя1035
Глава 20. Управление удаленным доступом и маршрутизацией1089
Глава 21. Восстановление после отказов системы1189
Предметный указатель1234
Содержание
Предисловие25
Кому следует прочесть эту книгу26
Кому эту книгу читать не нужно26
Условные обозначения27
Благодарности28
Об авторе29
О технических рецензентах29
Ждем ваших отзывов!30
Глава 1. Установка и настройка Windows Server 200331
Новые возможности Windows Server 200331
Сравнение версий33
Windows Server 2003, Standard Edition34
Windows Server 2003, Enterprise Edition35
Windows Server 2003, Datacenter Edition36
Windows Server 2003, Web Edition36
Версии Windows Server 2003 R237
Рекомендации по выбору аппаратных средств37
Список совместимых аппаратных средств38
Поддержка сертифицированных аппаратных средств38
Использование неподдерживаемых аппаратных средств39
Кэш-память второго уровня39
Чипсеты, материнские платы и BIOS40
Память40
Подсистема хранения41
Настройка подсистемы хранения на компьютерах архитектуры IA6444
Порядок действий при установке48
Настройка компонентов48
Настройка подсистемы хранения49
Настройка сетевых адаптеров50
Создание системы с двойной загрузкой51
Обзор возможностей программы установки Windows Server 200352
Текстовый этап53
Проверки на совместимость ACPI54
Графический этап59
Этап конфигурирования66
Отличия в установке на компьютер на основе архитектуры IA6468
Установка операционной системы Windows Server 200370
Текстовый этап установки70
Графический этап установки72
Заключительная настройка системы76
Отличия при настройке Web-сервера77
Настройка после установки78
Активация продукта79
Проверка журнала событий80
Перемещение и настройка файла подкачки страниц.82
Функциональное описание процесса загрузки операционной системы
Windows Server 200384
। Начальная загрузка84
Вторичная загрузка85
Ntldr85
Утилита ntdetect.com."86
Ядро системы86
Драйверы служб87
Инициализация ядра87
Диспетчер сеансов87
Настройка файла boot. ini88
Устранение проблем во время установки операционной системы94
Останов 0x0000007b Inaccessible_Boot_Device.95
Информация о системе95
“Зависание” программы установки96
Отказы некоторых устройств98
Проблема при копировании файлов на жесткий диск.98
Отсутствующие или некорректные приводы компакт-дисков99
Отсутствующие или неработающие сетевые адаптеры100
Проблемы в работе видеоадаптера101
Утилиты интерактивной отправки отчетов об ошибках101
Резюме102
В следующей главе102
Глава 2. Модернизация и автоматизированная установка103
Новые возможности операционной системы Windows Server 2003103
Обзор процесса модернизации операционной системы Windows NT 4.0104
Модернизация операционной системы Windows 2000105
Варианты модернизации106
Условия модернизации106
Модернизация операционной системы Windows NT 4.0 или Windows 2000 Server110
Начальная оценка110
Реализация модернизации111
Модернизация до версии Windows Server 2003 R2112
Проверки после модернизации114
Автоматизированная установка Windows Server 2003115
Клонирование дисков116
Установка по сценарию119
Службы удаленной установки129
В следующей главе150
Глава 3. Добавление аппаратных средств151
Новые возможности операционной системы Windows Server 2003151
Функциональное описание архитектуры Windows Server 2003154
Управление памятью в архитектуре IA32'154
Управление памятью в архитектуре IA64155
Поддержка устаревших приложений в архитектуре IA32155
Поддержка устаревших приложений в архитектуре IA64156
Пулы памяти158
Специальные функции по работе с памятью для архитектуры I АЗ 2160
Защита процессов162
Структура подсистемы Windows Executive.163
Разделение процессов164
Обработка ввода-вывода166
Обзор подсистемы Plug and Play170
Использование Device Manager (Диспетчер устройств)171
Интерфейс ACPI1174
Модель драйверов Windows176
Установка и настройка устройств179
Использование службы Windows Update' 179
Software Update Service (SUS)181
Обновления безопасности182
Добавление или замена центрального процессора182
Установка жестких дисков IDE182
Установка контроллеров и дисков SCSI183
Использование дисковых утилит EFI184
Добавление приводов сменных носителей186
Добавление сетевого адаптера187
Диагностика проблем в работе сети188
Использование нескольких мониторов189
Hardware Management (Управление оборудованием)189
Диагностика неисправностей при подключении новых устройств190
Обновление и откат драйверов устройств190
Создание загрузочного диска Windows Server 2003191
' Решение проблем в работе интерфейса SCSI193
Исправление “зависаний” на компьютерах, не поддерживающих РпР194
Отслеживание используемого объема памяти ядра194
В следующей главе196
Глава 4. Преобразование имен NetBIOS197
Новые возможности операционной системы Windows Server 2003198
Обзор сетевой подсистемы Windows Server 2003198
Уровень данных199
. Сетевой и транспортный уровни200
Сеансовый уровень201
Уровень представления данных201
Прикладной уровень201
Ограничения имен NetBIOS,202
SMB и имена NetBIOS202
Службы NetBIOS203
Сетевые службы и преобразование имен204
Прикладной уровень и протокол SMB205
Транспортный уровень205
Сетевой уровень207
Уровень управления доступом к среде208
Утилиты сетевой диагностики209
Утилита ipconfig,209
Утилита netstat1210
Утилита tracert212
Утилита pathping213
Утилита nbtstat213
Утилита netdiag215
Утилита netsh215
Преобразование имен NetBIOS с помощью широковещательных запросов216
Преобразование имен NetBIOS с помощью файла Lmhosts217
Настройка файла Lmho s t s.217
Использование файла Lmho s t s218
Преобразование имен NetBIOS средствами WINS219
Обзор функциональных возможностей службы WINS219
Варианты преобразования имен221
Репликация WINS222
Управление службой WINS224
Установка службы WINS,224
Настройка клиентов WINS225
Управление записями WINS227
. Настройка репликации WINS231
У правление базой данных W INS232
Установка принятых по умолчанию свойств консоли WINS236
Что можно и чего нельзя делать со службой WINS236
Отключение службы преобразования имен NetBIOS-over-TCP/IP237
В следующей главе238
Глава 5. Управление службой DNS239
Новые возможности операционной системы Windows Server 2003'239
Обзор доменной структуры DNS241
Общедоступные пространства имен DNS242
Частные пространства имен DNS243
Файл Hosts244
Первичный и вторичный серверы преобразования имен244
Записи ресурсов-245
Авторитетные ответы на запросы245
Неавторитетные ответы на запросы246
Списки корневых серверов246
Клиентские распознаватели DNS247
Обработка DNS-запросов249
1 Обработка запроса на авторитетном сервере250
Обработка запроса на неавторитетном сервере251
Запросы обратного преобразования252
Проектирование доменов DNS254
Репликация зон255
Интеграция в Active Directory257
Перенаправление запросов257
Развертывание службы DNS на основе операционной системы Windows в пределах существующей инфраструктуры260
Перенаправление запросов WINS262
Динамические обновления262
Динамические обновления и контроллеры домена263
Сборка мусора263
Безопасность службы DNS264
Настройка клиентов DNS266
Настройка параметров DNS в свойствах протокола TCP/IP266
Настройка параметров DNS в окне свойств системы267
Установка и настройка DNS-сервера268
Установка службы DNS269
Создание зон прямого преобразования269
Создание обратных зон270
Настройка иерархических зон272
Настройка вторичных DNS-серверов274
Активизация переноса зоны и рассылки уведомлений об изменениях275
Настройка вторичного сервера DNS276
Интеграция DNS-зон в службу Active Directory276
Настройка кэширующего сервера имен278
Настройка DNS-сервера на использование переадресующего сервера279
Управление службой Dynamic DNS280
Настройка динамической зоны280
Управление безопасностью динамической регистрации280
Отключение службы DNS на определенном интерфейсе281
Настройка сборки мусора282
Перенаправление WINS284
Настройка дополнительных параметров DNS-сервера285
Просмотр зон с помощью утилиты nslookup287
Управление службой DNS в режиме командной строки290
Настройка службы DHCP для взаимодействия с DNS290
Установка службы DHCP291
Авторизация сервера DHCP291
Настройка области адресов DHCP292
Настройка DNS Update Proxy294
В следующей главе296
Глава 6. Службы Active Directory297
Новые возможности операционной системы Windows Server 2003297
Недостатки системы безопасности в классической Windows NT300
Ограниченный размер базы данных SAM300
Полная зависимость от доступности одного компьютера302
Недостаточная производительность302
Недостаточная скорость репликации302
Использование различных баз данных на серверах и контроллерах домена303
Отсутствие уровней управления303
Отсутствие поддержки транзитивных доверительных отношений303
Несколько регистрационных идентификаторов304
Усовершенствования, внесенные с появлением Active Directory304
' Компоненты службы каталогов305
Краткая история служб каталогов305
ITU-T306
ISO306
IEC307
ANSI307
IETF307
Request For Comments (RFC)307
Общие принципы стандарта Х.500 ,308
Почему LDAP, а не Х.500310
Active Directory и LDAP311
Информационная модель LDAP311
Объектно-ориентированная база данных312
Классы и атрибуты312
Наследование классов313
Экземпляры классов315
Схема315
Резюме по модели LDAP315
Структура пространства имен LDAP316
Общие имена316
Характерное имя317
Относительное характерное имя318
Типизированное имя318
Информационное дерево каталога318
Контексты именования320
Поиск в LDAP320
RootDSE321
Резюме321
Структура пространства имен Active Directory322
Домены322
Контексты именования Active Directory' 323
Деревья и леса Active Directory328
Глобальный каталог330
Доверительные отношения в Active Directory332
Sysvol336
Поиск служб Active Directory337
Параметры совместимости341
Совместимость с клиентами342
Основные особенности пространств имен Active Directory344
Схема Active Directory345
Функции схемы345
Классы объектов и наследование классов347
Правила схемы347
Объекты описания схемы•348
Идентификация объектов348
Характерное имя349
Глобально уникальный идентификатор349
Расширение схемы для поддержки возможностей Windows Server 2003 R2352
Файлы поддержки Active Directory353
Утилиты Active Directory354
Стандартные консоли управления Active Directory354
Консоль Schema355
Утилиты Active Directory общего назначения358
ADSI Edit358
Браузер LDAP361
Утилита dcdiag363
Утилиты ds363
Импорт и экспорт больших объемов данных364
LDAP Data Interchange Format (LDIF)364
Утилита Idifde365
Утилита csvde366
Другие утилиты для работы с LDAP367
ADAM (Active Directory Application Mode)367
ADFS368
В следующей главе368
Глава 7. Управление репликацией Active Directory369
Новые возможности операционной системы Windows Server 2003369
Обзор репликации370
Репликация и контексты именования370
Соединения370
Репликация свойств372
Сайты372
Частота репликации373
Опрос374
Методы репликации374
Топология репликации375
Сравнение межсайтовой и внутрисайтовой репликации379
Выбор связующего сервера379
Генератор межсайтовой топологии380
Особенности межсайтовой репликации381
Выход из строя связующего сервера или генератора межсайтовой топологии381
Объекты сайта в базе данных Active Directory382
Резюме топологии репликации383
Подробное описание транзакций репликации384
Метаданные свойства384
Пример транзакции репликации386
Обработка коллизий при репликации390
Служба Windows Time394
Net Time и WIN32TM395
Проектирование архитектуры сайтов396
Настройка межсайтовой репликации400
Переименование объекта Default-First-Site -Name400
Создание нового сайта400
Создание подсетей IP,401
Создание связей сайтов402
Выбор связующих серверов404
Создание мостов связей сайтов405
У правление параметрами репликации406
Настройка интервалов репликации407
Принудительная репликация408
Специальные операции при репликации409
Создание соединений вручную409
Перемещение объектов между сайтами410
У правление топологией репликации вручную411
Диагностика проблем в процессе репликации412
Записи реестра для диагностики работы службы каталогов413
Использование утилиты repadmin•413
Использование Rep Imon416
Свойства сервера421
В следующей главе422
Глава 8. Проектирование доменов Windows Server 2003423
Новые возможности операционной системы Windows Server 2003424
Цели проектирования424
Служба DNS и пространства имен Active Directory425
Active Directory и серверы имен от сторонних производителей426
Использование отдельных зон427
Общедоступный домен с разделением на общедоступную и частную зоны428
Имя корневого домена429
Стратегия проектирования доменов430
Причины использования нескольких доменов431
Группы и использование нескольких доменов434
Проектирование доверительных отношений в лесу из нескольких доменов437
Настройка регистрации для нескольких доменов438
Стратегии проектирования организационных единиц440
Размещение организационных единиц441
Подразделения управления443
Административные функции443
Организационные единицы более высокого уровня444
Организационные единицы нижнего уровня446
Хозяева операций453
PDC Emulator454
Хозяин относительных идентификаторов — RID Master456
Хозяин инфраструктуры — Infrastructure Master457
Хозяин именования доменов — Domain Naming Master458
Хозяин схемы — Schema Master458
Распределение ролей458
Размещение контроллеров домена459
Серверы глобального каталога459
Вторичные серверы DNS460
В следующей главе461
Глава 9. Развертывание доменов Windows Server 2003463
Новые возможностцоперационной системы Windows Server 2003464
Подготовка к модернизации домена Windows NT465
DNS466
Требования к контроллерам доменов467
Защита базы данных SAM470
Функциональные уровни471
Смешанные домены и групповые политики473
Поддержка классических служб удаленного доступа Windows NT 4.0478
Поддержка классических сценариев и политик479
Размещение серверов, выполняющих роли FSMO479
Неподдерживаемые операции доменов480
Дополнительные проблемы при развертывании480
Непосредственная модернизация домена Windows NT 4.0481
Установка домена-контейнера483
Устранение неисправностей при повышении сервера487
Добавление контроллеров домена488
Определение ролей контроллеров домена490
Смена функционального уровня корневого домена на уровень Windows Server 2003491
DNS-зоны, интегрированные в Active Directory491
Обновление основных контроллеров первого домена учетных записей492
Проверки после модернизации495
Модернизация резервных контроллеров домена учетных записей496
Модернизация доменов ресурсов498
Модернизация оставшихся главных доменов учетных записей499
Смена функционального уровня леса на уровень Windows Server 2003500
Модернизация леса Windows 2000500
Модернизация схемы502
Модернизация корневых доменов Windows 2000503
Модернизация дочерних доменов,504
Миграция доменов Windows NT и Windows 2000 в домены Windows Server 2003505
Библиотека функций SID History,506
Миграция учетных записей компьютеров509
Миграция учетных записей групп510
Подготовка к миграции учетных записей510
Миграция паролей511
М играция учетных записей пользователей и групп513
Дополнительные операции в домене516
Понижение контроллера домена516
Переименование доменов517
Переименование контроллеров домена517
В следующей главе518
Глава 10. Обслуживание Active Directory519
Новые возможности операционной системы Windows Server 2003519
Выход из строя DNS-сервера520
Эффект острова520
Влияние отказа сервера DNS на клиентов под управлением операционной системы
Windows520
Выход из строя контроллера домена521
Регистрация без доступа к глобальному каталогу521
Удаление метаданных на отказавшем контроллере домена523
Выход из строя серверов, играющих роли хозяев операций525
Выход из строя ключевого компонента репликации531
Выбор нового предпочтительного связующего сервера532
. Выбор нового генератора межсайтовой топологии533
Выход из строя внешнего соединения534
Резервное копирование каталога534
Почему необходимо создавать резервные копии Active Directory535
Резервное копирование состояния системы536
Восстановление Active Directory537
Обслуживание каталога545
Сжатие базы данных Active Directory545
Восстановление базы данных Active Directory547
Перемещение файлов поддержки Active Directory548
В следующей главе549
Глава 11. Безопасность доступа по сети и протокол Kerberos551
Новые возможности операционной системы Windows Server 2003551
Архитектура безопасности операционной системы Windows Server 2003553
Компойенты LSA554
Обзор работы LSA557
Компоненты системы безопасности558
Маркеры доступа558
Разрешения'560
Идентификаторы безопасности560
Дескрипторы безопасности и списки контроля доступа565
Управление дескрипторами безопасности с помощью утилит с интерфейсом командной строки570
Оценка прав доступа573
Наследование разрешений576
Оценка записей контроля доступа с наследованием576
Описание наследования разрешений578
Безопасность паролей587
Формат паролей и хранилище паролей587
Взлом паролей588
Взлом хранилища паролей589
Политики защиты паролей589
Пароли компьютеров592
Диагностика проблем, связанных с паролями компьютеров592
Кэш регистрационных данных593
Хранение имен и паролей594
Сброс пароля595
Анонимная регистрация598
Аутентификация599
Ограничения классической аутентификации WindowsNT600
Методы аутентификации, поддерживаемые операционной системой Windows
Server 2003601
Обзор транзакций Kerberos602
Словарь Kerberos603
Структура билета Kerberos605
Дополнительные элементы Kerberos607
Данные авторизации609
Резюме по элементам Kerberos612
Анализ транзакций Kerberos613
Аутентификация при начальной регистрации пользователя614
Аутентификация при подключении к входящим в домен серверам617
Междоменная аутентификация619
Прямые доверительные отношения620
Делегирование Kerberos621
Дополнительные преимущества Kerberos622
Политики Kerberos623
Совместимость MITv5 Kerberos624
Ссылки на документацию по протоколу MITv5 Kerberos624
Приложения Kerberos625
Межсферная архитектура627
Создание доверительного отношения между сферами633
Аудит безопасности639
Журнал аудита640
Включение аудита641
Управление журналом событий с помощью утилиты audi tpol643
Рекомендации по аудиту645
В следующей главе\648
Глава 12. Управление групповыми политиками649
Новые возможности операционной системы Windows Server 2003650
Обзор функций групповых политик651
Назначение групповых политик651
Компоненты групповых политик651
Цели групповых политик681
Делегирование управления политиками687
Управление отдельными типами групповых политик688
Политики безопасности688
Политики административных шаблонов693
Политики распространения программного обеспечения700
Политики перенаправления каталогов706
Политики сценариев707
В следующей главе710
Глава 13. Управление безопасностью Active Directory711
Новые возможности операционной системы Windows Server 2003711
Обзор системы безопасности Active Directory712
Просмотр содержимого дескриптора безопасности713
Программа вычисления действующих разрешений714
Типы прав доступа714
Наследование записей контроля доступа716
Делегирование прав доступа718
У правление списками контроля доступа с помощью утилиты d s а с 1 s721
Использование групп для управления объектами Active Directory723
Типы групп723
. Сравнение глобальных и универсальных групп726
Защита объекта Active Directory с помощью глобальной группы728
Защита объекта Active Directory с помощью локальной для домена группы730
Защита объекта Active Directory с помощью универсальной группы732
Резюме относительно возможностей групп734
У четные записи служб735
Использование службы SLS и команды RunAs736
Синтаксис команды RunAs-736
Профили и команда RunAs737
Параметры команды RunAs737
Использование WMI для уведомления о событиях Active Directory738
В следующей главе739
Глава 14. Настройка подсистемы хранения данных741
Новые возможности операционной системы Windows Server 2003 ■742
Описание подсистемы хранения Windows Server 2003744
Конфитурации томов диспетчера логических дисков744
Структура базы данных LDM746
Имена групп LDM748
Ограничения динамических томов748
Когда использовать динамические диски749
Преобразование базовых дисков751
Разделы и расширение тома755
Дисковые операции на компьютерах IA32757
Выбор правильной конфигурации диска -758
Создание основного раздела на базовом диске759
♦Создание расширенного раздела и логических дисков760
Расширение раздела базового диска761
Преобразование базового диска в динамический762
Создание простых томов на динамических дисках762
Расширение томов на динамических дисках (создание составного тома)763
Создание томов с чередованием764
Создание зеркалированных томов1764
Разбиение зеркалированного тома765
Удаление тома7 67
Преобразование динамического диска в базовый767
Изменение буквы диска767
Управление дисками из командной строки769
JВосстановление данных на отказоустойчивых дисках770
iЗамена отказавшего диска в томе RAID 5771
[Создание загрузочного гибкого диска773
IЗамена отказавшего диска в составе зеркалированного тома774
|Перенос динамических дисков между компьютерами776
|Работа с дисками GPT778
IУсовершенствования в схеме GPT779
\Формат GPT779
Требования к дискам GPT781
Работа с дисками GPT782
В следующей главе783
Глава 15. Управление файловыми системами785
Новые возможности операционной системы Windows Server 2003787
IОбзор файловых систем Windows Server 2003789
|Секторы и кластеры790
;Структура файловой системы FAT793
.Адресация и размер кластеров в файловой системе NTFS799
Структура NTFS800
Записи метаданных800
Атрибуты NTFS806
Дескриптор безопасности807
Записи файлов810
Таблица MFT и фрагментация816
Именованные потоки данных816
Записи каталогов819
Дефрагментация821
Сжатие файлов823
Сжатие файлов и производительность824
Особенности сжатия файлов825
Разреженные файлы825
Преобразование файловой системы в формат NTFS826
Служба отслеживания ссылок827
Классическое обнаружение источника ссылки в системах Windows NT и Windows 9х828
. Функциональное описание отслеживания ссылок828
Отслеживание ссылок по сети830
Особенности отслеживания ссылок830
Точки функционального монтирования831
Принцип работы точек функционального монтирования831
Основные характеристики точек функционального монтирования833
Восстановление файловой системы и отказоустойчивость833
Утилиты chkdsk и autochk834
Ведение журналов для файловой системы837
Журнал изменений838
CLFS (Common Log File System)839
Защита файлов Windows’840
Квоты843
Управление ресурсами файлового сервера844
Работа файловой системы845
Операции при сжатии файлов846
Работа точек функционального монтирования, 848
Управление точками функционального монтирования с помощью утилиты Fsutil 849
Операции дефрагментации850
Операции по преобразованию файловой системы в формат NTFS853
Операции с дисками CD-RW и DVD-RAM854
В следующей главе856
Глава 16. Управление совместно используемыми ресурсами857
Новые возможности операционной системы Windows Server 2003857
Функциональное описание совместного доступа к ресурсам Windows859
Сетевые приложения■861
Сетевые поставщики862
Перенаправители-866
Настройка совместного доступа к файлам868
Совместный доступ к операционной системе Windows ХР869
Разрешения совместного доступа871
Создание общего ресурса с помощью Explorer871
Создание общих ресурсов на удаленных компьютерах873
Создание общих ресурсов из командной строки875
Восстановление административных общих ресурсов875
Теневое копирование тома876
Подключение к общим каталогам878
Просмотр878
Совместный доступ к ресурсам с помощью распределенной файловой системы880
Структура распределенной файловой системы881
Корень Dfs883
Ограничения корня Dfs883
Связи Dfs884
Таблица знаний о разделах" 887
Множественные цели Dfs888
Функциональный обзор ссылок Dfs893
Проектирование пространства имен Dfs894
Развертывание Dfs'895
Создание корня Dfs896
Создание связей Dfs896
Назначение дополнительных целей для связей897
Изменение топологии репликации898
Удаление корня Dfs899
Управление Dfs из командной строки899
Реализация Dfs в Windows Server 2003 R2900
Совместный доступ к файлам в смешанной среде901
Совместный доступ к принтерам902
Функциональное описание сетевой печати902
Начальное преобразование задания903
Расширенные метафайлы904
Драйверы принтеров от компании Microsoft904
Спулер907
Перемещение файлов спулера907
Мониторы портов910
Финальная доставка задания на печать911
Настройка печати на клиенте под управлением Windows Server 2003911
Печать на локальном устройстве печати912
Печать на сетевом устройстве печати913
Печать на хосте UNIX914
Печать на сервере печати Windows914
Автоматизация подключения клиентов к принтерам915
Устранение неисправностей в работе клиентов печати916
Печать на сервере печати от стороннего производителя916
Печать по сети Интернет916
Совместный доступ к факсам920
Архитектура службы Fax920
Установка службы Fax922
Подключение клиента к факс-серверу925
Отправка факсимильного сообщения926
Управление титульными страницами928
Управление очередями и факс-устройствами929
Мониторинг активности факс-сервера929
Управление службами печати930
Управление очередями печати930
Настройка параметров сервера печати931
Безопасность принтера932
Политики печати933
правление свойствами принтеров933
Печать из DOS938
Печать в Windows Server 2003 R2939
Устранение неисправностей при печати939
Управление печатью из командной строки940
Отслеживание расположения принтера943
Службы SharePoint943
В следующей главе945
Глава 17. Управление шифрованием файлов947
Новые возможности операционной системы Windows Server 2003948
Функциональное описание шифрования файлов949
Шифрование файлов949
Дешифровка файлов >950
Шифрование данных951
Алгоритмы шифрования данных951
Защита ключа шифрования файла954
Защита секретного ключа957
Управление сертификатами961
Оснастка Certificates (Сертификаты)961
Управление сертификатами963
Восстановление зашифрованных файлов963
Групповые политики восстановления зашифрованных файлов964
Отключение параметров групповой политики EFS965'
Открытие файлов от имени DRA966
Шифрование файлов на сервере967
Обращение от имени пользователя и Kerberos967
Доверенность для делегирования968
Файловые транзакции EFS и протокол WebD AV969
Преимущества WebDAV с точки зрения EFS970
правление передачей шифрованных файлов по WebDAV971
Особые советы по использованию EFS971
Перемещение и копирование зашифрованных файлов971
Файлы, которые не могут быть зашифрованы972
Временные файлы, файлы подкачки, файлы спящего режима и файлы спулера973
Автономные файлы973
Антивирусная проверка974
Шифрование и восстановление системы974
Процедуры EFS974
Отключите шифрование975
Настройка дополнительных агентов DRA978
Загрузка новых агентов DRA в групповые политики EFS980
Экспорт и удаление секретных ключей восстановления файлов981
Настройка шифрования каталогов на портативных компьютерах983
Восстановление шифрованных файлов985
Перенос зашифрованных файлов на другой компьютер986
В следующей главе987
Глава 18. Управление инфраструктурой открытого ключа989
Новые возможности операционной системы Windows Server 2003990
Задачи инфраструктуры открытого ключа992
Криптографические элементы в Windows Server 2003993
Методы шифрования993
Ключи шифрования994
Хеш994
Службы открытого/секретного ключа995
Технологии открытого ключа в операционной системе Windows Server 2003996
Службы шифрования в операционной системе Windows Server 2003997
Хранилище ключей999
Сертификаты1000
Документация на сертификаты1002
Локальные хранилища сертификатов1002
Центры сертификации1003
Шаблоны сертификатов1005
Отзыв сертификатов"1007
Доверительные отношения между центрами сертификации1011
Иерархия центров сертификации1013
Проектирование доверительных отношений1015
Установка центра сертификации -1017
Проверки действительности1018
Подача заявок на сертификаты1021
Сообщения управления сертификатами поверх CMS (СМС)1022
Функциональное описание подачи заявки-1022
Архивация и восстановление ключей1026
Создание агента восстановления ключей1027
Настройка центра сертификации на архивацию сертификатов1028
Создание шаблона архивации1029
Восстановление архивированного сертификата1031
Утилиты с интерфейсом командной строки для управления PKI1032
Утилита certutil1032
Утилита ds st ore1032
Утилита Certmgr1033
Утилита Signcode1033
В следующей главе1034
Глава 19. Управление операционной средой пользователя1035
Новые возможности Windows Server 2003,1036
Параллельные сборки1037
Миграция настроек пользователя1038
Файлы INF для миграции пользователей1038
Использование мастера перемещения файлов и настроек1042
Инструментарий UMST1043
Управление перенаправлением каталогов1044
Политики перенаправления каталогов1045
Управление размещением перенаправленных каталогов1045
Особенности перенаправления каталогов1049
Создание домашних каталогов и управление ими1049
Назначение домашнего каталога с помощью консоли Active Directory — Users and
Computers1050
Создание домашних каталогов из командной строки1051
Подключение домашних каталогов для клиентов более старых версий1052
Службы терминалов и домашние каталоги1053
Управление автономными файлами1053
Дополнительные варианты применения автономных файлов1053
Некорректное использование автономных файлов1054
Автономные файлы и удаленный рабочий стол1054
Настройка кэширования на стороне клиента1055
Диспетчер синхронизации1058
Операции при использовании автономных файлов1061
Управление сервером с помощью удаленного рабочего стола1062
Протокол RDP1063
Удаленный рабочий стол1063
Перенаправление устройств1066
Безопасность сервера терминалов1070
Управление ресурсами1074
Лицензирование1075
Удаленное управление1079
Управление службами терминалов с помощью командной строки1081
Продукты для “тонких” клиентов1083
Удаленный помощник1084
Отключение удаленного рабочего стола1087
В следующей главе1088
Глава 20. Управление удаленным доступом и маршрутизацией1089
Новые возможности операционной системы Windows Server 20031091
Функциональное описание поддержки устройств для глобальных сетей1092
Поддержка глобальных сетей и NDIS1093
Протокол РРР1095
Создание канала соединения1096
Аутентификация1096
У становка сетевого уровня1096
Протокол РРРоЕ1099
Аутентификация по РРР1101
Протокол SP АР1103
Протокол MS-CHAP версий vl и v21105
ПротоколЕАР,1106
Аутентификация с помощью RADIUS1109
Аутентификация коммутируемого доступа и аутентификация в домене1111
Аутентификация в нескольких доменах1112
Стандартная транзакция аутентификации по протоколу РРР1114"
Сравнение методов аутентификации для различных клиентов коммутируемого доступа1115
Ограничения аутентификации в доменах Windows NT 4.0 и доменах, работающих в режиме Mixed1119
Серверы удаленного доступа под управлением Windows NT 4.0 и домены Active
Directory1120
Нулевой сеанс1120
Анонимный доступ1121
Анонимный доступ и безопасность Active Directory1122
Применение смарт-карт для удаленного доступа1122
Форматы смарт-карт1123
Выбор смарт-карт1123
Подготовка инфраструктуры открытого ключа для смарт-карт1125
Настройка смарт-карт1126
Подготовка шаблонов сертификатов1126
Выдача сертификатов агентов подачи заявок1127
Запись пользователей смарт-картИЗО
Тестирование сертификата1133
Настройка службы RRAS на использование смарт-карт1134
Тестирование удаленной регистрации с помощью смарт-карты1135
У становка и настройка модемов1136
Тестирование и диагностика модемных подключений1137
Рекомендуемая конфигурация лаборатории для тестирования коммутируемого доступа1140
Мониторинг коммутируемых сеансов путем отслеживания протоколов1142
У странение неисправностей с помощью журнала модема1144
Настройка сервера удаленного доступа1145
Начальная настройка службы RRAS1145
Проверка коммутируемых подключений с помощью журнала удаленного доступа 1148
Настройка параметров IP для коммутируемого доступа1150
У правление маршрутизацией и удаленным доступом из командной строки1155
У правление подключениями удаленного доступа с помощью групповых политик1157
Установка коммутируемого соединения из командной строки1157
Настройка маршрутизатора с дозвоном по запросу1158
Инициализация служб маршрутизации1159
Настройка маршрутизатора с дозвоном в Интернет по требованию1159
Настройка шлюза в Интернет с использованием технологии NAT1164
Функциональное описание трансляции сетевых адресов1166
Совместный доступ в Интернет1170
Брандмауэр подключения к Интернету1171
Настройка NAT на консоли RRAS1172
Настройка трансляции сетевых адресов и ICF1173
Включение ICS и ICF1174
Настройка сетевого моста1175
Обзор функции моста1176
Настройка сетевого моста1176
Настройка VPN-соединений1176
Протокол РРТР'1177
Протокол L2TP1179
Настройка подключения виртуальной частной сети1182
Служба Internet Authentication Services (IAS)1183
Установка службы IAS1184
Настройка журнала для службы IAS и политик удаленного доступа1184
Регистрация службы IAS в базе данных Active Directory1185
Настройка серверов IAS и RRAS на поддержку аутентификации по технологии
RADIUS1186
В следующей главе1187
Глава 21. Восстановление после отказов системы1189
Новые возможности операционной системы Windows Server 20031189
Работа утилиты Ntbackup1190
Типы резервного копирования1192
Журналы резервного копирования '1194
Исключение файлов1195
Общие параметры резервного копирования1196
Заблокированные файлы и служба теневого копирования тома1198
Восстановление системы на рабочих станциях Windows ХР11199
Вопросы безопасности1200
Резервное копирование файлов состояния системы1202
Резервное копирование в файл1202
Аварийное восстановление системы1202
Сменные носители1204
Имена лент и утилита Ntbackup1205
Утилиты резервного копирования от сторонних производителей1207
Операции резервного копирования и восстановления1207
Интерактивное резервное копирование1208
Планирование резервного копирования1210
Восстановление файлов1212
Каталогизация ленты1214
Восстановление после критических ошибок1215
Интерактивное отслеживание событий1215
Коды критических ошибок1215
Интерактивные отчеты об ошибках1216
Распространенные критические ошибки1216
Дампы памяти1217
Настройка дампов памяти1217
Просмотр содержимого дампов памяти1219
Использование служб аварийного управления1220
Специальная административная консоль1222
Службы аварийного управления и критические ошибки1223
Использование безопасного режима1224
Восстановление работоспособности с помощью последней удачной конфигурации1225
Структура набора управления1226
Восстановление последней работоспособной конфигурации1226
Консоль восстановления1228
Установка загрузочной версии Recovery Console (Консоль восстановления)1228
Возможности консоли восстановления1230
Ограничения консоли восстановления1231
Загрузка консоли восстановления из служб удаленной установки1232
Что дальше1233
Предметный указатель1234
Предисловие
После выхода новой версии операционной системы всегда возникает множество вопросов. Стоит ли модернизация потраченного времени и усилий? Возникнут ли проблемы после модернизации? Как подготовиться к тестированию, оценке и, возможно, к развертыванию новой системы? Все эти вопросы оказываются особенно сложными в данной ситуации, поскольку Windows Server 2003 не является революционной операционной системой по сравнению с Windows 2000. Вместо этого в операционной системе реализованы разнообразные усовершенствования от небольших до глобальных, которые придется рассматривать по отдельности и в целом при принятии решения о необходимости модернизации существующей операционной системы. •
Кроме этого, операционная система Windows Server 2003 представляет собой первую серверную операционную систему из линейки Windows NT, в которой серверный код был выпущен отдельно от программного обеспечения для настольных компьютеров. К моменту выхода Windows Server 2003 операционная система Windows ХР была доступна уже в течение года. Для развертывания Windows Server 2003 необходимо четко представлять себе механизмы управления системой серверов Windows Server 2003, Windows 2000 и Windows NT, к которым необходимо предоставлять доступ хостам зачастую под управлением около десятка различных версий настольных операционных систем Windows (и большому числу клиентов от третьих фирм).
В этой книге описываются сложности полного развертывания операционной системы Windows Server 2003 в условиях неоднородной среды, в которой работают компьютеры под управлением нескольких операционных систем. Сначала рассматривается установка одного сервера, после чего последовательно освещаются вопросы модернизации дополнительных серверов, установки аппаратного обеспечения, настройки службы преобразования имен, развертывания и интеграции службы DNS для Windows Server 2003, установки и настройки Active Directory, а также предоставления ресурсов сервера под управлением Windows Server 2003 авторизованным клиентам как в локальной сети, так и в сети Интернет. Эта версия Windows является определенной вехой в развитии данной операционной системы, поскольку компания Microsoft стала уделять особое внимание обеспечению безопасности. Вот почему и в этой книге особое внимание уделяется новым возможностям обеспечения безопасности.
Каждая глава построена таким образом: в начале рассматриваются принципы проектирования, затем приводится описание процесса, которое позволяет выявить проблемы взаимодействия, и наконец описываются процедуры, необходимые для установки и настройки параметров операционной системы Windows Server 2003, рассматриваемых в данной главе. Каждая глава начинается с перечня новых возможностей операционной системы Windows Server 2003, а также с описания усовершенствований по сравнению с возможностями операционной системы Windows 2000. Опытные архитекторы и администраторы операционной системы Windows 2000 могут воспользоваться этим перечнем для планирования возможности перехода на новую операционную систему.
Автор этой книги подробно рассматривает возможности операционной системы Windows Server 2003, поскольку долгое время работал оператором ядерного реактора на военноморском флоте. Работая с ядерным реактором, недостаточно знать, как управлять определенной частью оборудования. Необходимо еще знать принципы, по которым оно проектировалось, принципы интеграции одного компонента с остальным оборудованием реактора, а также последствия отказа этого компонента в различных условиях для всего реактора в целом. Мне (автору) пощастливилось увидеть команду операторов, каждый член которой обладал энцик-
лопедическими знаниями об оборудовании. Вся команда поддерживала бесперебойную работу очень сложной системы, и иногда возникало впечатление, что это очень простая работа. Надеюсь, эта книга предоставит достаточный объем материала по операционной системе Windows Server 2003 для создания такой же слаженной команды специалистов в организации, занимающейся информационными технологиями.
Кому следует прочесть эту книгу
Любой профессионал в области информационных технологий, в обязанности которого входит проектирование, управление или использование технологий операционной системы Windows, обязан ознакомиться с возможностями операционной системы Windows Server 2003. Эта книга окажет посильную помощь в этом исследовании. Если планируется установка одного или нескольких экземпляров операционной системы Windows Server 2003 для выполнения специальных функций или модернизации до Windows Server 2003 Active Directory, то здесь можно найти советы по подготовке установки и диагностике проблем, возникающих в этом процессе.
Если процесс перехода на Windows 2000 уже завершен (или переход только осуществляется) и необходимо узнать, принесет ли переход на Windows Server 2003 дополнительные преимущества, обратите внимание на раздел “Новые возможности операционной системы Windows Server 2003" в начале каждой главы, что, безусловно, поможет при принятии окончательного решения о необходимости модернизации. На глобальном уровне впечатляет внимание к вопросам безопасности для всех компонентов операционной системы, особенно для сервера IIS. Кроме того, значительными усовершенствованиями можно считать улучшения в службе DNS, возможность копирования настроек Active Directory, возможность создания доверительных отношений между лесами, новую программу Active Directory Migration Tool (ADMT), интегрированные утилиты для создания результирующего набора политик RSoP (Resultant Set of Policies), которые предназначены для управления групповыми политиками, а также появление большого количества новых возможностей в Terminal Services, зашифрованной файловой системе (Encrypted File System — EFS), открытой инфраструктуре ключей (Public Key Infrastructure — PKI) и распределенной файловой системе (Distributed File System — DFS). Ко всему вышеуказанному следует добавить общее повышение производительности и стабильности и улучшение механизма управления памятью.
Для модернизации большой инфраструктуры необходимы время и деньги, но в случае Windows Server 2003 в результате модернизации получается быстрая и простая в управлении система, которая гарантирует пользователям повышение производительности и удобство.
Кому эту книгу читать не нужно
При написании книги предполагалось, что читатель знаком с серверными операционными системами WindowsNT и классическими доменами NT. Если читатель знаком с другими операционными системами и предпочитает глубоко погрузиться в особенности новой системы при изучении нового предмета, в книге приводится достаточно описаний и ссылок для понимания всех принципиальных вопросов. Если необходимо просто получить информацию об операционной системе Windows и сетевых технологиях, эта книга является не лучшим источником информации для начинающего пользователя.
Поскольку в книге рассматривается операционная система Windows Server 2003, читателям, которых интересуют установка и настройка операционной системы для настольных компьютеров, стоит обратить внимание на одну из множества книг, посвященных операционной системе Windows ХР. Если необходимо изучить, как серверные компоненты операционной системы Windows Server 2003 взаимодействуют с клиентами под управлением операционных
систем Windows 2000 и Windows ХР, а также научиться пользоваться сложными функциями наподобие перенаправления папок, применения автономных файлов, групповыми политиками, совместным использованием ресурсов, преобразованием имен, доступом удаленных пользователей, созданием сертификатов, зашифрованной файловой системой и поддержкой смарт-карт, то в этой книге будет предоставлен достаточный объем информации.
Если читателя, в основном, интересует получение сертификата специалиста по работе и управлению системами на основе Windows Server 2003, то в этой книге содержится достаточно материала для успешной сдачи экзаменов, но информация может оказаться изложенной не в том порядке, который удобен для подготовки к экзамену. Если для подготовки к экзамену необходим непосредственный опыт специалиста, то формат предоставления данных, принятый в этой книге, окажется очень полезным.
В связи с ограничением объема в этой книге не рассматриваются многие новые возможности службы Internet Information Services (IIS) версии 6.0 и множество особенностей Terminal Services в режиме приложений (application-mode). Кроме того, не рассматриваются возможности взаимодействия Novell NetWare и службы каталогов Novell (NDS — Novell Directory Services), служб для Macintosh (SFM — Services for Macintosh) или служб для Unix (SFU — Services for Unix). В главе И подробно рассматривается взаимодействие реализаций Windows Server 2003 Kerberos и UNIX MITv5 Kerberos.
Условные обозначения
В этой книге используются следующие условные обозначения для выделения важной информации в тексте.
При первом использовании новый термин выделяется курсивом.
Пути к файлам, объекты Active Directory, параметры и значения параметров реестра, а также параметры групповых политик обозначаются моноширинным шрифтом, например “Файл Hosts расположен в каталоге \Windows\System32\Drivers\Etc, а информация о конфигурации зоны DNS расположена в системном реестре, в разделе HKLM\ Software\Microsoft\Windows NT\CurrentVersion\DNS Server \ Zones”.
Элементы управления, на которых можно щелкнуть и которые можно выбрать, установить, открыть или закрыть либо вызвать для привлечения внимания, выделяются рубленым шрифтом, например “Щелкните на кнопке Add (Добавить), чтобы открыть окно Add Standalone Snap-In (Добавить изолированную оснастку)”.
Элементы меню также выделяются рубленым шрифтом, например “Щелкните правой кнопкой мыши на пиктограмме Му Network Places (Мое сетевое окружение) и выберите из контекстного меню команду Properties (Свойства)”.
Названия утилит с графическим интерфейсом и утилит, запускаемых из командной строки, со специализированными консолями пишутся с прописной буквы, например “Консоль Certificates (Сертификаты) позволяет просматривать личные сертификаты, а объекты, представляющие отключенные контроллеры доменов, удаляются с помощью программы Ntdsutil”.
Утилиты с интерфейсом командной строки выделяются моноширинным шрифтом, на' пример “С помощью утилиты ipconfig из локального кэша DNS можно удалить отрицательные ответы, для чего необходимо воспользоваться следующей командой: ipconfig /flushdns”.
При указании имен файлов и команд “заполнители" (т.е. пример, вместо которого нужно подставить собственные значения) указываются курсивом, например “Формат команды runas выглядит следующим образом: runas /и: user@domain.root /smartcard”.
Благодарности
Лучшим моментом в процессе написания книги является возможность поработать с одаренными профессионалами. Создать эту книгу было бы невозможно без их помощи и поддержки. Мне повезло вдвойне, так как этот проект поддерживался двумя издательствами из корпорации Pearson Education: New Riders и Addison-Wesley. Хотел бы представить некоторых членов команды, чтобы поблагодарить их отдельно.
Исполнительным редактором большей части проекта являлась Стейша Меллингер (Stacia Mellinger) из издательства New Riders. Терпение и безграничная преданность качеству оказались одновременно испытанием и источником вдохновения. Ее напряженная работа, энтузиазм и чувство юмора сделали радостным весь процесс создания книги. Стейша передала проект Жаклин Дусетт (Jacquelyn Doucette), исполнительному менеджеру издательства Addison- Wesley. Жаклин справилась с тысячей мелких проблем с удивительной легкостью. Тиррелл Олбо (Tyrrell Albaugh) взял на себя всю работу исполнительного менеджера, связанную с изменением названия в последний момент перед выходом книги. Хотелось бы поблагодарить всех за вклад в эту книгу.
Литературным редактором была Келли Брукс (Kelli Brooks). Благодаря вниманию Келли была сохранена целостность книги, и она стала приятной для чтения. Более того, ее удивительная способность находить значение в словах сохранила общее направление материала книги, несмотря на мои отклонения от основного курса.
Редактированием графических изображений занимался Майкл Лабонн (Michael Labonne) из издательства New Riders. На Майкла была возложена сложная задача превращения набросков в качественные диаграммы. Он очень быстро понял, почему учитель средней школы посоветовал мне стать писателем, а не художником.
Выпускающими редакторами были Илайза Уолтер (Elise Walter) и Джефф Райли (Jeff Riley) из издательства New Riders, а также Сондра Скотт (Sondra Scott) из издательства Addison-Wesley. Джефф выступал за использование Windows Server 2003 в названии и проложил путь для книги, которую вы сейчас держите в руках. Элиз привнесла в проект свежие идеи и безграничную доброжелательность, а Сондра стоически поддерживала проект в то время, когда компания Microsoft в очередной раз на несколько месяцев сдвигала сроки выхода конечного продукта.
Сложная работа по техническому редактированию легла на плечи двух удивительных людей: Дейвида Шакелфорда (David Shackelford) и Боба Райнша (Bob Reinsch). Дейв и Боб не только вложили в проект свои мудрость и опыт, но и были крайне настойчивы в вопросах полной ясности в каждом абзаце. Каждый писатель мечтает о таких рецензентах. Для выражения благодарности Дейву и Бобу одних слов недостаточно.
В превращение этой книги в привлекательный и доступный продукт свои силы вложили многие сотрудники издательств New Riders и Addison-Wesley. Этих людей слишком много, чтобы вспомнить здесь каждого. Особую благодарность хотелось бы выразить Стефани Уолл (Stephanie Wall) из издательства New Riders за помощь, поддержку и профессионализм при передаче проекта из издательства New Riders в издательство Addison-Wesley.
Наконец, хотелось бы поблагодарить друзей, которые помогали в течение двух лет, потребовавшихся для завершения этого проекта. Мой коллега, Тодд Логан (Todd Logan), был необычайно щедр, когда делился со мной своими временем, знаниями и ресурсами. Его помощь оказалась совершенно незаменимой для завершения этой книги. Кроме этого, я в долгу перед Джереми Московитцем (Jeremy Moskowitz) из компании Braincore, поделившимся со мной своим опытом в настройке групповых политик и внутренней архитектуре службы Active Directory, когда я рассматривал различные сценарии использования этих технологий. Тодд и Джереми продемонстрировали удивительную способность вйдеть суть проблемы. Они не стеснялись указывать на недостатки в моих рассуждениях и исследованиях. Я очень благодарен им за мудрость и настойчивость в поиске правильного ответа.
Об авторе
Уилльям Бозуэлл обладает сертификатом MCSE и является главным инженером компании Windows Consulting Group, расположенной в Финиксе, штат Аризона. Он не только обучает и консультирует, но и публикует материалы для колонки “Windows Insider" в журнале МСР Magazine, а также выступает на таких конференциях, как TechMentor, SANS и WinConnections. С ним можно связаться по адресу bboswell@winconsultants. com.
О технических рецензентах
Рецензенты вложили часть своего личного опыта в создание данной книги. В процессе написания книги эти профессионалы своего дела просматривали все материалы, контролировали ее структуру и руководили ходом подготовки книги к печати. Их отзывы оказались совершенно незаменимыми для обеспечения максимального качества технической информации и соответствия книги запросам читателей.
Дейвид Шакелфорд (David Shackelford) является инженером в области сетевых технологий и проживает в городе Уиттиер, штат Калифорния. Сын блестящего программиста, Дейвид получил диплом, изучая литературу средних веков. Только после этого он откликнулся на зов сетевых пакетов и ядер операционных систем. Свои сертификаты MCSE и МСТ он получил в 1997 году. Дейвид преподавал сетевые технологии Microsoft и операционные системы для компаний Intel и Hewlett-Packard перед тем, как перейти к оседлому образу жизни и стать администратором сети большого предприятия. В данный момент Дейвид работает в компании ChoicePoint, Inc. в качестве ведущего системного инженера и сетевого администратора. Недавно он начал преподавать курс технологий Cisco в университете Biola. В то время, когда Дейвид не занят игрой с сыновьями или приготовлением пива со своей терпеливой женой, его можно застать за чтением стихов или попыткой завлечь друзей в настольные стратегические игры.
Боб Райнш (Bob Reinsch) работает преподавателем и консультантом в Лоренсе, штат Канзас. Он закончил Университет штата в Уичито и работает с компьютерами с 1977 года. Он имеет сертификаты MCSE, МСТ, аккредитованного системного инженера Compaq и авторизованного инструктора Compaq, сертифицированного профессионала SAIR/GNU Linux, сертифицированного технического преподавателя, а также авторизованного инструктора по безопасности для реального мира. Это уже восемнадцатая работа Боба по техническому редактированию. С Бобом можно связаться по адресу bob@piercingblue. com.
Ждем ваших отзывов!
Вы, читатель этой книги, и есть главный ее критик и комментатор. Мы ценим ваше мнение и хотим знать, что было сделано нами правильно, что можно было сделать лучше и что еще вы хотели бы увидеть изданным нами. Нам интересно услышать и любые другие замечания, которые вам хотелось бы высказать в наш адрес.
Мы ждем ваших комментариев и надеемся на них. Вы можете прислать нам бумажное или электронное письмо либо просто посетить наш Web-сервер и оставить свои замечания там. Одним словом, любым удобным для вас способом дайте нам знать, нравится вам эта книга или нет, а также выскажите свое мнение о том, как сделать наши книги более интересными для вас.
Посылая письмо или сообщение, не забудьте указать название книги и ее авторов, а также ваш обратный адрес. Мы внимательно ознакомимся с вашим мнением и обязательно учтем его при отборе и подготовке к изданию последующих книг. Наши координаты:
E-mail:info@williamspublishing. com
WWW:http:7 /www.williamspublishing. com
Адреса для писем:
115419, Москва, а/я 78303150, Киев, а/я 152115419, Москва, а/я 78303150, Киев, а/я 152из России:
115419, Москва, а/я 783
03150, Киев, а/я 152
115419, Москва, а/я 783
03150, Киев, а/я 152
из Украины:
1
г.
лавы этой книги следуют примерно в том порядке, в котором будет выполняться уста- 1 новка операционной системы Windows Server 2003. Начнем с настройки сервера. В этой главе рассматриваются следующие темы.
Сравнение возможностей различных версий операционной системы Windows Server 2003
Рекомендации по выбору аппаратного обеспечения для версий Standard и Enterprise операционной системы Windows Server 2003
Полный список проверок, которые необходимо выполнить перед установкой операционной системы
Установка системы и критически важные решения
Подробное описание процесса установки сервера
Анализ последовательности загрузки с целью диагностики
Советы по устранению распространенных проблем при загрузке
Мы завершим изучение установки операционной системы Windows Server 2003 в главе 2, “Модернизация и автоматизированная установка”. В главе 3, “Добавление аппаратных средств”, рассматривается модификация системы после установки.
Перед установкой или модернизацией корпоративных серверов стоит обратить внимание на главы, в которых рассматриваются службы Windows Server 2003, основанные на протоколе IP, особенно на службы преобразования имен и службу DNS. Если установка сервера выполняется в домене, стоит ознакомиться с требованиями службы Active Directory (AD) и безопасностью сетевого доступа.
Новые возможности Windows Server 2003
В этой главе рассматриваются такие новые возможности Windows Server 2003, которые относятся к настройке конфигурации при установке операционной системы с установочного компакт-диска.
Новые варианты поставки серверной операционной системы. Существует четыре версии операционной системы Windows Server 2003. Каждый вариант обладает собственным набором возможностей. Существуют такие варианты: Web Edition, Standard Edition, Enterprise Edition и Datacenter Edition.
Новые требования к аппаратному обеспечению. Операционная система Windows Server 2003 требует большего объема оперативной памяти, более быстрых процессоров и больших объемов пространства на устройствах хранения.
Поддержка центральных процессоров семейства Itanium. Доступны варианты операционной системы Windows Server 2003 в редакциях Enterprise Edition и Datacenter Edition для 64-разрядной архитектуры Intel (IA64). В этой главе рассматриваются настройка систем, использующих интерфейс Extensible Firmware Interface (EFI), а также подготовка дисков на основе таблицы разделов GUID (GUID Partition Table — GPT).
Форматирование файловой системы NTFS выполняется на этапе установки. В предыдущих версиях операционной системы Windows NT/2000 загрузочный раздел создавался в файловой системе FAT, и после этого осуществлялось преобразование в NTFS. Форма- тирование непосредственно в файловую систему NTFS позволяет снизить фрагментацию для MFT (Master File Table — главная файловая таблица) и отказаться от перезагрузки в процессе установки.
Параметры безопасности. В отличие от операционной системы Windows 2000, в операционной системе служба Internet Information Services (IIS) по умолчанию не устанавливается. Это хорошая новость, так как нет причин создавать сервер, уязвимый для атак по сети, если от сервера не требуется поддержка определенных служб. При этом во время установки служб IIS каталог Inetpub все еще размещается в корневом каталоге загрузочного раздела, что является серьезной брешью в системе безопасности. Всегда при установке службы IIS пользуйтесь сценарием автоматической установки, который выберет другое место расположения для каталогов с файлами, предназначенных для хранения Web- данных.
Отказ от поддержки устаревшего программного чередования и зеркалирования дисков. При модернизации WindowsNT операционная система Windows Server 2003 не выполняет преобразование устаревших отказоустойчивых (Fault Tolerant — FT) дисковых массивов в чередующиеся и зеркалированные тома Logical Disk Manager (LDM). Этот метод отличается от принятого в операционной системе Windows 2000, в которой такое преобразование выполнялось автоматически. Если сервер Windows NT использует отказоустойчивый массив дисков, необходимо выполнить резервное копирование данных этого массива и восстановить данные после установки операционной системы. Компания Microsoft предоставляет утилиту ft on line, которая может использоваться для восстановления дискового массива после установки. При этом массив монтируется только для чтения, что позволяет выполнить резервное копирование данных.
Поддержка 12О. Операционную систему можно устанавливать непосредственно на устройства массового хранения I2O (Intelligent I/O), не загружая дополнительные драйверы.
Информация о системе. Это набор характеристик, полученных с помощью интерфейса WMI (Windows Management Instrumentation — средства управления Windows), которые представляются в удобном для использования виде.
Активация продукта. Компания Microsoft включила защиту от копирования в розничные версии операционной системы Windows Server 2003. Процесс активации связывает идентификационный ключ программного обеспечения с определенным компьютером, что позволяет предотвратить несанкционированное копирование. Версии Windows Server 2003, распространяемые с корпоративными лицензиями, не требуют активации.
Удаленный рабочий стол. Операционная система Windows Server 2003 поднимает на новый уровень обслуживания встроенные службы Terminal Services, автоматически поддерживая до двух одновременных сеансов по умолчанию для всех серверов. В операционной системе Windows 2000 для этого требовалось использовать специальные компоненты.
Автоматическое обновление файла Boot .ini. При добавлении в сервер новых дисководов автоматически выполняется обновление пути (имени) Advanced RISC Computing (ARC) в файле Boot. ini.
Улучшенное управление сервером. В новую версию операционной системы, которая вышла в конце 2005 года под названием Windows Server 2003 R2, включены Administration Tools Packs (Пакеты инструментов администрирования) для управления сервером, усовершенствования в управлении аппаратным обеспечением, а также Microsoft Management Console (ММС) 3.0 (Управляющая консоль Microsoft, версия 3.0).
Новые функции управления дисками и файлами. В версию операционной системы Windows Server 2003 R2 добавлены новые возможности для поддержки обмена файлами с пользователями, находящимися в удаленных филиалах организации, включая новую реализацию распределенной файловой системы (DFS), а также организацию и управление хранилищем данных (Storage Management for SANs).
Улучшенная совместимость с системами Linux и Unix. Инструментарий Services for Unix, который раньше предлагался для Windows Server в качестве дополнения, отныне встроен в Windows Server 2003 R2.
Сравнение версий
Существует четыре версии операционной системы Windows Server 2003. Ниже перечислены все доступные версии, а затем подробно рассмотрены различия между ними.
Standard Edition. Эта версия предназначена для поддержки служб печати и файловых служб, а также для универсальной поддержки приложений. Также эта версия может выполнять роль шлюза в Интернет и сервера коммутируемого доступа.
Enterprise Edition. Эта версия позволяет выполнить модернизацию операционной системы Windows 2000 Advanced Server. Эта операционная система поддерживает больший объем оперативной памяти и большее количество процессоров, чем Standard Edition. Кроме этого, поддерживается создание кластеров и усовершенствованных служб сертификатов. Эта версия предназначена для высокопроизводительных решений и устойчивых к отказам служб. В этой версии операционной системы поддерживаются службы, которые отсутствуют в пакете Standard Edition.
Datacenter Edition. Эта версия распространяется как часть аппаратно-программного решения, предоставляемого авторизованными дилерами. В данной версии операционной системы поддерживаются в два раза больший объем памяти и в два раза большее число узлов кластера, чем в Enterprise Edition. Кроме этого, возможно создание более отказоустойчивых решений. Данный вариант операционной системы предназначен для работы приложений в больших и критически важных центрах хранения данных.
Web Edition. Новый член семейства серверных операционных систем Windows предназначен для приложений Web-служб и хранения данных удаленных пользователей. В этом варианте операционной системы отсутствуют многие возможности Standard Edition, но при этом предлагаются привлекательная цена и простая в управлении платформа, позволяющая добиться необходимого уровня безопасности.
Варианты операционной системы Standard и Web предоставляются только для 32-раз- рядной архитектуры (IA32). Варианты Enterprise и Datacenter предоставляются в варианте
как для 32-, так и для 64-разрядной архитектуры. Версии для 64-разрядной архитектуры работают только на процессорах Intel Itanium. Версии операционной системы Windows Server 2003 для процессоров Alpha не существует.
В табл. 1.1 приведены минимальные рекомендуемые требования к аппаратному обеспечению, определенные компанией Microsoft. Слово “рекомендуемые” выделяется в связи с тем, что минимальные требования, опубликованные компанией Microsoft, не позволяют добиться приемлемого уровня производительности для корпоративных систем.
Кроме этого, компания Microsoft рекомендует выделять для раздела операционной системы минимум 1,5 Гбайт (для версий IA64 — не менее 2 Гбайт), но автор этой книги рекомендует выделять для операционной системы не менее 4 Гбайт. Это позволит установить файлы поддержки приложений, а дополнительное свободное пространство можно использовать во время дефрагментации.
Таблица 1.1. Минимальные требования к аппаратному обеспечению для операционной системы Windows Server 2003
Компонент аппаратных средств обеспечения
Web Edition
Standard Edition
Enterprise Edition
Datacenter Edition
Центральный процессор, МГц
550
550
550 (733 для IA64)
733
Оперативная память
256 Мбайт
256 Мбайт
256 Мбайт
(1 Гбайт для IA64)
1 Гбайт
Максимальный объем оперативной памяти, Гбайт
2
4
32 (64 для IA64)
64 (512 для IA64)
Поддержка кластеров
Нет
Нет
8 узлов
8 узлов
Количество процессоров
1 или 2
От 1 до 4
От 1 до 8
От 8 до 32 (64 для IA64)
Варианты операционных систем Enterprise и Datacenter Edition, предназначенные для платформы IA32, в состоянии использовать оперативную память за пределами 4 Гбайт (это ограничение налагается 32-разрядной архитектурой). Для этого используется набор технологий, совместно разработанных компаниями Microsoft и Intel. Технологии доступа к большим объемам оперативной памяти рассматриваются в главе 3, “Добавление аппаратных средств”.
Windows Server 2003, Standard Edition
Кроме характеристик, представленных в табл. 1.1, операционная система Windows Server 2003, Standard Edition имеет ряд значительных отличий от операционной системы Windows 2000 Server.
II■ Процессоры. Вариант Standard Edition поддерживает до четырех процессоров, подключенных по архитектуре “симметричная многопроцессорная обработка” (Symmetrical MultiProcessor - SMP). При этом для серверов на основе процессоров Xeon, использующих технологию Hyperthreading, считаются не только физические процессоры. Таким образом, четырехпроцессорный компьютер на основе процессоров Xeon с технологией Hyperthreading будет показан в окне Task Manager (Диспетчер задач), как восьмипроцессорный, и все восемь логических процессоров будут использоваться в работе.
I
I
Память. Поддерживается до 4 Гбайт физической оперативной памяти, как и в операционной системе Windows 2000 Server, но вариант Standard Edition также поддерживает возможность 4GB Tuning, которая доступна только в операционных системах Windows 2000
Advanced и Datacenter Server. Эта возможность позволяет выделить дополнительно 1 Гбайт оперативной памяти для приложений, выполняющихся на сервере. В файле Boot. ini для этого используется параметр 13GB или /USERVA.
Распределение сетевой нагрузки. Вариант Standard Edition поддерживает кластеры распределения сетевой нагрузки (Network Load Balance clusters — NLB clusters). В случае операционной системы Windows 2000 для получения возможности распределения сетевой нагрузки приходилось приобретать вариант Advanced или Datacenter Edition.
Службы терминалов. Вариант Standard Edition поддерживает службы терминалов в режиме приложений (Application mode), но не обеспечивает работу Terminal Server Session Directory (распределение нагрузки терминальных подключений клиентов во время сеансов с кластерным сервером Terminal Server) в кластере распределения сетевой нагрузки (NLB).
Службы сертификатов. Центр сертификации (Certification Authority — СА), работающий под управлением Standard Edition, может выдавать те же сертификаты, что и СА в операционной системе Windows 2000. Для поддержки более новой, второй, версии сертификатов и автоматической регистрации пользователей необходимо приобрести вариант Enterprise или Datacenter. Дополнительная информация по этому вопросу содержится в главе 18, “Управление инфраструктурой открытого ключа”.
Windows Server 2003, Enterprise Edition
Если необходимы следующие возможности операционной системы, придется заплатить дополнительную цену за вариант Enterprise Edition. Цена значительно отличается, но, как и в случае с другими продуктами компании Microsoft, при оптовых закупках предоставляются скидки.
Поддержка архитектуры IA64. 64-разрядная версия Enterprise Edition предоставляет возможность использования нового поколения процессоров Intel.
Процессоры. Вариант Enterprise Edition поддерживает до восьми центральных процессоров в конфигурациях симметричной многопроцессорной обработки (Symmetric Multiprocessor — SMP) и архитектуру ccNUMA (cache-coherent Non-Uniform Memory Access — неоднородный доступ к памяти с когерентным кэшем).
Память. Версия Enterprise Edition для архитектуры IA32 поддерживает до 32 Гбайт физической оперативной памяти. Сравните с 8 Гбайт поддерживаемой оперативной памяти в операционной системе Windows 2000 Advanced Server. Версия для архитектуры IA64 поддерживает до 64 Гбайт оперативной памяти.
Кластеры. Версия Enterprise Edition поддерживает кластеры из 8 узлов. Операционная система Windows 2000 поддерживает кластеры из двух узлов.
Оперативное добавление памяти. При поддержке со стороны аппаратных средств поддерживается добавление оперативной памяти к работающему серверу. Эта возможность доступна и в варианте Datacenter Edition.
Поддержка метакаталогов. Для получения возможности объединять несколько служб каталогов выход версии 3 службы Microsoft Metadirectory Services (MMS) был отложен до выпуска операционной системы Windows Server 2003, но эта возможность поддерживается только в варианте Enterprise Edition. Дополнительная информация доступна на сайте по адресу www.microsoft. com/windows2000/server/evaluation/news/bulletins/ mmsroadmap.asp.
Windows Server 2003, Datacenter Edition
Эта версия предназначена для наиболее мощных систем, например, для создания хранилищ данных, графического и экономического моделирования, а также реализации систем оперативного формирования аналитических отчетов (Online Analytical Processing— OLAP). Кроме возможностей, доступных в Enterprise Edition, в варианте Datacenter Edition поддерживаются следующие возможности.
Поддержка IA64. 64-разрядный вариант Datacenter Edition использует возможности масштабирования серверов IA64, включая поддержку оперативной памяти до 512 Гбайт (при поддержке со стороны материнской платы) и до 64 центральных процессоров.
Процессоры. Версия Datacenter Edition для архитектуры IA32 поддерживает до 32 процессоров в конфигурациях симметричной многопроцессорной обработки (Symmetric Multiprocessor — SMP) и архитектуры ccNUMA.
Память. Версия Datacenter Edition для архитектуры IA32 поддерживает до 64 Гбайт физической оперативной памяти.
Кластеры. Вариант Datacenter Edition поддерживает до восьми узлов в кластере. Для сравнения: операционная система Windows 2000 поддерживает до четырех узлов в кластере.
Нельзя приобрести только программное обеспечение Datacenter Edition. Эта операционная система предоставляется только в составе готового решения от таких поставщиков, как IBM, HP, Groupe Bull, Hitachi и Unisys, а также от таких апологетов компании Intel, как Dell, Gateway и NEC. Полный список партнеров доступен на сайте компании Microsoft по адресу www. microsof t. сот/servers в разделе Datacenter Edition.
Приобретая решение на основе Datacenter Edition от одного из этих поставщиков, клиент получает пакет из программного обеспечения и аппаратных средств, а также комплекса услуг. Каждая система перед передачей клиенту тестируется с помощью набора тестов для сертификации компанией Microsoft. Поставщик предоставляет круглосуточную поддержку семь дней в неделю. На вопросы отвечают специалисты Microsoft. Поставщик должен предоставлять такие услуги.
Гарантированное минимальное время работы — 99,9 % (в течение года допускается до девяти часов простоя на обслуживание)
Услуги по установке и настройке
Оценка доступности
Круглосуточная поддержка аппаратного и программного обеспечения в течение семи дней в неделю
Поддержка аппаратного и программного обеспечения с выездом специалиста к клиенту
Службы обновления
Как несложно догадаться, эти платформы и обслуживание достаются за большую цену. Но в заоблачном мире высоконадежных серверов решение, полностью реализованное на основе Datacenter Edition, стоит намного дешевле подобного решения на основе архитектуры RISC.
Windows Server 2003, Web Edition
Иногда эту версию называют “Blade Server” из-за того, что она проектировалась для работы в крупных Web-серверах (так называемых фермах — Web farm), в которых применяется высокая плотность компонентов.
Кроме ограничения в 2 Гбайт оперативной памяти (объем виртуальной памяти также ограничен 4 Гбайт), Web Edition не поддерживает отдельных возможностей, которые часто ас-
социируются у пользователей с серверами под управлением операционной системы Windows. Операционная система лишена всех функций, которые не нужны Web-платформе, что позволяет обеспечить большую безопасность решения. Вот краткое описание сокращенного набора функций.
Маршрутизация и удаленный доступ. В версии Web Edition поддерживается только одно VPN-соединение, которое предназначено для управления операционной системой. Этот вариант операционной системы не в состоянии работать в качестве сервера удаленного доступа или в качестве шлюза Интернет. Также не поддерживается брандмауэр ICF.
Active Directory. Версия Web Edition не может работать в качестве контроллера домена. Сервер под управлением этой операционной системы может входить в домен.
Файловые службы и службы печати. Версия Web Edition способна устанавливать соединения с клиентами под управлением Windows и может содержать том распределенной файловой системы (DFS). Поддерживается шифрование файлов. Не поддерживается теневое копирование (см. главу 21, “Восстановление после отказов системы”). Версию Web Edition нельзя использовать в качестве сервера служб удаленной установки (Remote Installation Services — RIS).
Сертификаты. В версии Web Edition не поддерживаются службы сертификатов (Certificate Services), и компьютер под управлением этой версии не может выступать в роли центра сертификации С А.
Службы терминалов. В версии Web Edition можно организовывать два сеанса удаленного доступа в целях администрирования, но эта операционная система не может выступать в роли полноценного сервера терминалов, работающего в режиме приложений.
Версии Windows Server 2003 R2
Операционная система Windows Server 2003 R2 выпущена для всех основных изданий Windows Server 2003, кроме Web Edition. Это связано с тем, что все нововведения R2 не затрагивают компоненты IIS, так что в Web Edition улучшать нечего. Таким образом, существуют Windows Server 2003 R2 Standard Edition, Windows Server 2003 R2 Enterprise Edition и Windows Server 2003 R2 Datacenter Edition.
Все три основных издания Windows Server 2003 R2 доступны для 32-битовой платформы х86 и 64-битовой х64 (также известная как AMD64 или Intel ЕМТ64). Также для платформы х64 впервые выпущены издания Windows Storage Server и запланирован выпуск Small Business Server. Версии Windows Server 2003 R2 для платформы Intel Itanium не существует. Поддержка этой платформы будет реализована в серверной операционной системе Longhorn.
Рекомендации по выбору
аппаратных средств
Операционная система Windows Server 2003 может работать на совершенно различных аппаратных платформах. Один и тот же код может работать как на простом Pentium 600, так и на многопроцессорном сервере. Основная сложность заключается в создании системы, на платформе которой операционная система Windows Server 2003 будет работать надежно.
Существует старая история об изобретателе шахмат. Китайский император, научившийся этой игре, предложил изобретателю любую награду. Изобретатель попросил простую награду: на первую шахматную клетку необходимо было положить одно зерно риса, на вторую -• два, на третью — четыре и т.д. Таким образом, на последнюю, 64-ю, клетку императору пришлось
бы положить 184 467 440 673 709 551 616 зерен риса (не считая зерен, которые пришлось бы положить на все остальные шахматные клетки). Император решил, что проще и дешевле казнить изобретателя шахмат...
В зависимости от опыта в установке решений на основе Windows Server 2003, общаясь с поставщиком аппаратного обеспечения, можно прийти к такому же решению.
Ни одна книга не может начинаться с описания миллионов комбинаций проблем при совместимости аппаратных средств и программного обеспечения, которые могут возникнуть при развертывании Windows Server 2003. В этой главе приводятся советы ио выбору конфигурации аппаратного обеспечения, которые позволят сократить количество потенциальных проблем или хотя бы сделать число проблем меньшим числа 184 467 440 673 709 551 616.
Список совместимых аппаратных средств
Современные компьютеры работают на самых высоких скоростях, но многие согласятся, что системные администраторы предпочитают надежность, совместимость и качественную поддержку чистой производительности и новым возможностям. Это значит, что стоит приобретать системы и компоненты, которые сертифицированы для работы под управлением операционной системы Windows Server 2003.
Поставщики аппаратного обеспечения взаимодействуют с компанией Microsoft в процессе тестирования и сертификации собственных систем и компонентов. Поставщики сообщают о результатах тестирования в лабораторию тестирования качества аппаратных средств Microsoft (Windows Hardware Quality Lab — WHQL) и предоставляют образцы аппаратных средств и исходные коды драйверов. Техники и инженеры проверяют результаты тестирования, перезапуская тесты. Дополнительная информация об этой программе приводится на сайте Microsoft по адресу www.microsoft. com/hwtest.
Компания Microsoft поддерживает список сертифицированных систем и компонентов, который называется список совместимых аппаратных средств (Hardware Compatibility List), илй HCL. Последняя версия HCL доступна по адресу www.microsoft. com/hcl. Обращаясь к HCL, основное внимание уделите версии операционной системы, которая планируется к использованию, и ожидаемой аппаратной конфигурации. Особое внимание уделите версиям аппаратных компонентов. Бывают ситуации, когда определенные контроллеры SCSI сертифицированы для работы только в определенных системах.
Очень подробная информация о процессе разработки и тестирования приводится по адресу www.microsoft.com/hwdev. Рекомендации компании Microsoft поставщикам аппаратных средств приводятся в Hardware Design Guide. Последняя информация о разработке драйверов содержится на сайте Open System Resources по адресу www.osr.com. На этом сайте доступна информация, предоставленная инженерами, которые занимаются обучением специалистов для Microsoft.
Поддержка сертифицированных аппаратных средств
С точки зрения системного администратора, основной причиной приобретения аппаратных средств с определенным логотипом является поддержка, которая предоставляется вместе с логотипом. Если в работе сервера возникла проблема, которую не смог решить оператор службы поддержки в компании Microsoft, проблема будет передана инженерам поддержки, которые постараются повторить проблему на таких же аппаратных средствах с использованием таких же драйверов.
Как было сказано ранее, миллионы серверов, которые не указаны в HCL, без проблем поддерживают работу серверных продуктов на основе Windows. Главное условие надежной кон-
фигурации заключается в наличии поддержки, производителя. Если планируется модернизация существующей системы до Windows Server 2003 или приобретается новая система с установленной более ранней версией серверной операционной системы Windows, убедитесь, что производитель готов оказывать поддержку во время модернизации и после нее. Особенно важно это для устаревших компьютеров, которые могут работать нестабильно или не обладать всеми возможностями под управлением Windows Server 2003.
Использование неподдерживаемых аппаратных средств
Компонент (или система) считается “поддерживаемым”, если удовлетворяется следующий ряд условий.
Производитель и модель компонента явно указаны в HCL
Для управления компонентом используется указанный компанией Microsoft драйвер
Аппаратный компонент используется в той же конфигурации, в которой проходило тестирование
Если аппаратный компонент не указан в HCL, представитель службы поддержки компании Microsoft все равно постарается решить проблему, понимая, что удовлетворяющее клиента решение не гарантируется. По опыту автора этой книги, технический персонал компании Microsoft заметно выходит за очерченные пределы поддержки, помогая решать возникающие проблемы в случае использования неподдерживаемых аппаратных средств. Скорее всего, клиенту помогут при отказе сервер» DNS, если используется неподдерживаемая сетевая карта. С другой стороны, скорее всего, полная поддержка при постоянных повреждениях базы данных окажется невозможной, если в системе используется неподдерживаемый контроллер RAID.
Вне зависимости от места приобретения системы, обратитесь на сайт производителя и убедитесь, что для каждого компонента установлены последние драйверы для операционной системы Windows Server 2003. Советы по выбору конфигураций можно найти в базе знаний Microsoft и в открытых группах новостей Microsoft. Всегда стоит выполнить быстрый поиск в группах новостей, посвященных серверным версиям Windows. Информация о некорректно работающих драйверах распространяется очень быстро. Есть ли смысл наступать на те же грабли, на которые наступают сотни других администраторов? Лучше найти новые грабли и наступить на них первым.
Кэш-память второго уровня
При модернизации аппаратного обеспечения для перехода на операционную систему Windows Server 2003 обратите особое внимание на спецификации кэш-памяти второго уровня центрального процессора (L2). В более новых процессорах реализованы значительные улучшения в архитектурах кэш-памяти, расположенной на кристалле (первого уровня), и кэш-памяти, подключенной к шине (второго уровня). Подсистема управления памятью Windows Server 2003 активно использует кэш-память второго уровня, поэтому наличие этого типа кэш-памяти значительно влияет на общий уровень производительности системы.
В большинстве случаев файловые службы и службы печати удовлетворительно работают при 256 Кбайт кэш-памяти, установленной на процессорах уровня Pentium Ill. В то же время серверы приложений получают значительный прирост производительности при использовании большого объема кэш-памяти, работающей на частоте шины (такая кэш-память устанавливается на процессоры Xeon). С увеличением объема установленной кэш-памяти увеличивается и цена процессора, но при этом существует прямая зависимость для роста производительности. Например, компания Dell опубликовала показатели производительности для
своих серверов PowerEdge при различных объемах кэш-памяти второго уровня. Дополнительная информация приводится на сайте по адресу www.dell. com/us/en/gen/topics/ power_ps4q99-L2cache.htm.
Приобретая системы на основе архитектуры IA64, обратите внимание на процессоры Itanium 2 (McKinley), работающие совместно с наборами микросхем, которые поддерживают весь объем оперативной памяти, адресуемый процессором. В таких процессорах устанавливается небольшой объем кэш-памяти второго уровня, но объем кэш-памяти третьего уровня может достигать 3 Мбайт. При этом кэш-память третьего уровня работает на полной частоте ядра процессора.
Чипсеты, материнские платы и BIOS
В журналах часто публикуются диаграммы, на которых показано соотношение цены и производительности для различных компьютеров, оснащенных процессорами сопоставимой мощности. Это соотношение не в последнюю очередь зависит от набора микросхем (чипсета), использованного в материнской плате компьютера. Компания Intel является ведущим производителем наборов микросхем. В числе других заметных производителей можно перечислить следующих.
VIA. На данный момент самый быстроразвивающийся производитель высокоскоростных чипсетов для процессоров Intel и AMD (www. via. com. tw).
SiS. Лидер с точки зрения цен. В основном, специализируется на наборах микросхем для процессоров AMD, хотя новые наборы микросхем с поддержкой DDR (Double Data Rate) выглядят многообещающими (www. s i s. с от. t w).
Micron Technologies. Компания более известна как производитель SDRAM и других типов оперативной памяти (включая DDR RAM). Компания Micron совершила прорыв со своим новым набором микросхем Copperhead DDR (www. micron. com).
Основным источником информации по материнским платам и чипсетам является сайт Tom’s Hardware, который можно найти по адресу www.tomshardware.com. Не сомневайтесь, что информация этого сайта не содержит надуманных рейтингов, которые появляются в журналах, когда поставщик дает рекламный проспект на два разворота журнала. Еще одним источником новостей и обзоров по аппаратным средствам является сайт Earthweb System Optimization Information, доступный по адресу www. sysopt. com.
После выбора производителя материнских плат поработайте с продуктами этого производителя некоторое время. Со временем выявятся все их особенности, и в случае проблем про- , ще будет выполнять устранение неисправностей.
Убедитесь, что прошивка обновлена до последней версии. В противном случае при реали- [ зации возможностей Windows Server 2003 можно столкнуться с проблемами.!
Память
Выбирая аппаратные средства для нового сервера, не заказывайте менее 512 Мбайт опера- f тивной памяти. Добавление памяти к устаревшему компьютеру часто причиняет неудобства, | поэтому при модернизации существующего сервера под управлением Windows NT не заказы- 1 вайте память до завершения модернизации и оценки производительности. Может оказаться, что под управлением операционной системы Windows Server 2003 сервер работает так же быстро или даже быстрее, чем под управлением Windows NT. Это связано с улучшениями в ко- J де, позволяющими отказаться от установки дополнительного объема оперативной памяти.
При добавлении оперативной памяти на сервер, работающий под управлением операци- i онной системы Windows Server 2003, может оказаться, что нет точно таких же модулей в про- : даже. В таком случае можно вынуть все установленные модули DIMM и установить на их ме- . I
сто новые модули. Таким образом можно гарантированно избежать несовместимости модулей по временным характеристикам. Такая несовместимость может приводить к небольшим сбоям и даже к выходу системы из строя.
Подсистема хранения
Используемые приводы и контроллеры приводов могут оказать значительно большее влияние на производительность и надежность, чем процессор и оперативная память. Если бюджет требует сокращения расходов на аппаратные средства сервера, стоит сначала обратить внимание на улучшение производительности подсистемы ввода-вывода и только после этого рассматривать более мощные процессоры.
Выбор компонентов подсистемы хранения ограничен только содержимым кошелька. Обычно необходимо выбирать тип привода, объем, конфигурацию массива RAID и файловую систему.
Тип привода
Выбор привода для сервера обычно сводится к выбору между интерфейсами SCSI и IDE/АТА. За последние несколько лет производительность и объем дисков IDE/АТА значительно выросли. В компьютерном магазине можно приобрести привод объемом 180 Гбайт примерно за 100 долларов с пиковой пропускной способностью интерфейса, равной 133 Мбайт/с.
Приводы SCSI предоставляют большую пиковую пропускную способность (до 320 Мбайт/с по текущей версии спецификации), но такие приводы стоят заметно дороже, а высокопроизводительный адаптер интерфейса SCSI стоит несколько сотен долларов.
Несмотря на привлекательную цену, приводы IDE/АТА имеют значительно худшие показатели производительности, поскольку в определенный момент в очереди на выполнение в контроллере шины может находиться только одна команда, вне зависимости от количества устройств, подключенных к шине. Это делает контроллеры шины IDE узким местом производительности сервера, на который приходится высокая нагрузка. Кроме этого, спецификация АТА допускает не более двух дисков на один контроллер, поэтому для добавления дисков к компьютеру придется установить дополнительные контроллеры.
На данный момент активно разрабатывается интерфейс Serial АТА, сопоставимый по цене с интерфейсом АТА и позволяющий получить более высокие показатели производительности. Фактический прирост скорости невелик и зависит от контроллера. Основное преимущество интерфейса Serial АТА заключается в уменьшении размера и веса кабелей, а также в возможности подключить к одному контроллеру более двух дисков.
Выбор между SCSI и АТА не является просто выбором типа интерфейса. Многие производители указывают для своих дисков SCSI большее среднее время наработки на отказ (mean time between failure — MTBF). Кроме этого, самые быстрые диски выпускаются только с интерфейсом SCSI. Поэтому если надежность и производительность важнее всего, стоит выбирать SCSI. Если средств достаточно, обратите внимание на приводы и контроллеры Fibre Channel. Текущая спецификация Fibre Channel поддерживает полнодуплексную передачу данных со скоростью 400 Мбайт/с (именно мегабайтов, а не мегабитов), а новая спецификация должна поддерживать скорости до 500 Мбайт/с.
Объем диска
Выделите для операционной системы как минимум 3 Гбайт на жестком диске (желательно — 4 Гбайт). Особое внимание обратите на размер системного тома на сервере службы Terminal Services, работающем в режиме приложений. В последнем случае системный том часто быстро переполняется временными файлами Интернета и пользовательскими файлами, сохраненными для локального профиля.
Если системный раздел оказался слишком маленьким или он заполнен посторонними файлами, можно осуществить фрагментацию главной таблицы файлов NTFS-диска, которую называют MET (Master File Table). Фрагментация MFT значительно снижает производительность. Обычно для MFT выделяется буферная зона размером 25 % от размера тома, но система не уведомляет об использовании пространства из MFT-зоны, поэтому о существовании проблемы можно не подозревать до попытки дефрагментации диска, когда вдруг окажется, что MFT разбита на несколько фрагментов.
В операционной системе Windows Server 2003 отсутствуют многие проблемы фрагментации MFT, которые существовали в предыдущих версиях операционной системы. Для этого загрузочный раздел непосредственно форматируется в файловую систему NTFS, а не преобразовывается в NTFS после копирования файлов.
Конфигурация диска
Безотказность работы является основным критерием при создании сервера. Для подсистемы хранения это означает максимально широкое использование устойчивых к отказам дисковых подсистем. В число таких решений входят зеркалирование, чередование (striping) RAID 5 и чередование/зеркалирование RAID 0+1.
Версии NTFS
В операционной системе Windows Server 2003 используется обновленная версия файловой системы NTFS, в которой для увеличения производительности была изменена последовательность заголовков записи. При этом все прошлые версии утилит работы с образами и разделами являются несовместимыми. Убедитесь, что используются последние версии утилит для работы с файловой системой.
В операционной системе Windows Server 2003 используется файловая система NTFS версии 3.1. Это внутренний номер версии, указанный в метаданных. Кроме этого, такой номер версии выдается дисковыми утилитами, например утилитой f sut i 1. В документации иногда версии файловой системы NTFS нумеруются в соответствии с версией операционной системы, например 5.2. Это не совсем правильно, но такой подход иногда используется.
Ранее использовались такие версии файловой системы NTFS.
Windows NT 3.51 — NTFS 1.1
Windows NT 4.x — NTFS 1.2
Windows 2000 — NTFS 3.0
Windows XP — NTFS 3.1
В операционной системе Windows Server 2003 для управления отказоустойчивыми дисками используется диспетчер логических дисков (Logical Disk Manager — LDM) по лицензии компании Veritas. Подсистема LDM поддерживает зеркалирование RAID 1 и чередование с распределенной четностью RAID 5. Кроме этого, поддерживаются две конфигурации, которые нельзя назвать отказоустойчивыми: чередование RAID 0 и составные тома. LDM не поддерживает конфигурацию RAID 0+1.
В одном массиве дисков можно одновременно использовать диски SCSI и IDE, но так делать не рекомендуется, поскольку снижается общая производительность массива.
Одним из самых заметных изменений в Windows Server 2003 по сравнению с операционной системой Windows 2000 является полное отсутствие поддержки устаревших отказоустойчивых дисковых массивов (FT). В операционной системе Windows 2000 существует возможность преобразования устаревших дисковых массивов FT в динамические диски и добавления их в базу данных Logical Disk Manager (LDM). В операционной системе Windows Server 2003 перед модернизацией придется удалить все отказоустойчивые массивы дисков (FT). В главе 2, “Модернизация и автоматизированная установка”, содержится дополнитель-
ная информация об этой процедуре. Утилита ftonline позволяет восстановить дисковый массив FT, если он не был удален до модернизации.
В большинстве случаев лучше использовать аппаратный массив RAID, а не LDM. Хороший контроллер RAID поддерживает “горячую” замену приводов, резервирование и динамическое расширение массива. Ни одна из этих возможностей не поддерживается подсистемой LDM. Кроме этого, аппаратные контроллеры RAID намного лучше справляются с обнаружением каскадных отказов секторов. К тому же наиболее мощные контроллеры RAID поддерживают массивы RAID 0+1 или зеркалированные массивы с чередованием. При этом сохраняются преимущества обоих классов массивов: скорость RAID 0 и отказоустойчивость зеркалирования, присущая RAID 1. Правда, при этом придется потратить больше на размещение приводов.
Какие выводы можно сделать? При наличии достаточной суммы используйте аппаратный массив RAID, в противном случае можно использовать программный массив RAID. Если выбрать программный RAID, то большей производительности можно добиться при использовании дисков SCSI, а не IDE, так как интерфейс SCSI обладает большими возможностями при работе в многозадачной среде. Кроме этого, большей производительности можно добиться при использовании нескольких каналов SCSI вместо подключения всех дисков к одной шине.
Файловая система
Операционную систему Windows Server 2003 можно установить в раздел, отформатированный для файловой системы FAT, FAT32 или NTFS. Операционная система Windows Server 2003 не поддерживает установку в разделы файловых систем HPFS, NetWare, UNIX и Linux.
Многим понравится возможность непосредственного форматирования раздела для файловой системы NTFS (без предварительного форматирования в файловую систему FAT и последующего преобразования), которая является частью процедуры установки. Это позволяет устранить многие проблемы фрагментации, которые возникали в предыдущих версиях операционной системы. Кроме этого, существует возможность быстрого форма гировани я. [[ри этом в процессе форматирования не выполняется сканирование секторов.
Рекомендуется использовать файловую систему NTFS для всех разделов на сервере. Эго позволяет добиться безопасности, стабильности и масштабирования. Файловая система FAT32 предоставляет большую производительность, чем NTFS (с точки зрения скорости поиска в небольших разделах), но эта скорость не компенсирует неустойчивости файловой системы и проблем с фрагментацией. В процессе установки файловую систему FAT или FAT32 можно преобразовать в файловую систем)' NTFS. При форматировании раздела для файловой системы FAT или FAT32 с помощью программы установки Windows Server 2003 утилита преобразования предоставляет возможность выбора размера кластера.
ERD Commander 2002
Консоль восстановления (Recovery Console) в операционной системе Windows Server 2003 работает так же, как программа ERD Commander, созданная легендарными Марком Руссино- вичем (Mark Russinovich) и Броюсом Когсвеллом (Bryce Cogswell). Программа ERD Commander 2002 предоставляет интерфейс, напоминающий интерфейс Windows Explorer. Этот интерфейс позволяет менять пароли учетных записей и выполнять другие модификации параметров системы. Ознакомительную версию утилиты ERD Commander можно получить по адресу www.sysinternals.com. Платная версия поддерживает редактирование файлов системного реестра и редактирование паролей учетных записей в локальной базе SAM (Security Account Manager — диспетчер учетных записей системы безопасности.
Некоторые администраторы стараются избегать файловой системы NTFS из-за сложностей в загрузке компьютера с помощью гибких дисков для доступа к файлам. Операционная
система Windows Server 2003 предоставляет Recovery Console (Консоль восстановления), которая поддерживает загрузку посредством командной строки и позволяет получать доступ к дискам с файловой системой NTFS. Имея доступ к консоли восстановления, можно навсегда распрощаться с файловой системой FAT.
Сменные носители (CD-RW и DVD-RAM)
Операционная система Windows Server 2003 поддерживает непосредственную запись на сменные носители, поддерживающие чтение/запись, например на перезаписываемые компакт- диски и диски DVD-RAM. В механизме записи компакт-дисков используется технология, работающая на уровне файлов. Этот подход отличается от программ для записи компакт-дисков, действующих на уровне пакетов, например программы EZ CD Creator от компании Roxio (www. roxio. com), cdrwin от компании Goldenhawk Technologies (www. goldenhawk. com) и программы Nero от компании Ahead Software (www.nero. com) (компания Microsoft лицензировала часть механизма записи компакт-дисков у компании Roxio; компания Roxio является подразделением компании Adaptec, Inc.).
Операционная система Windows Server 2003 впервые предоставляет новый интерфейс записи образов, IMAPI, который предназначен для использования таких сменных носителей, как компакт-диски, поддерживающие однократную и многократную запись, а также диски DVD-RAM. Дополнительная информация об этом интерфейсе приводится по адресу www.microsoft.com/hwdev. Общая информация по технологии однократной записи компакт-дисков доступна на сайте www.cdrfaq.org. Это отличный сайт с актуальной информацией по данной теме.
Кроме этого, в операционной системе Windows Server 2003 поддерживается расширение стандарта ISO 9660, которое называется Joliet. Это расширение предназначено для поддержки длинных имен файлов. Если используются диски DVD-RAM, то система в состоянии отформатировать диск с помощью файловой системы FAT32, что позволяет значительно расширить возможности использования носителя. Также DVD-диски можно форматировать с помощью файловой системы UDF 1.5, которая является промышленным стандартом форматирования дисков DVD.
Программа установки операционной системы Windows Server 2003 не поддерживает загрузку с гибких дисков, поэтому для установки операционной системы необходимо иметь привод компакт-дисков, поддерживающий спецификацию El Torito “no emulation boot”.
Настройка подсистемы хранения на компьютерах архитектуры IA64
Если операционная система Windows Server 2003 устанавливается на компьютер на основе архитектуры IA64, необходимо подготовить загрузочный диск, использующий таблицу разделов GUID (GUID Partition Table) или GPT. Метод форматирования GPT является частью спецификации расширяемого программно-аппаратного интерфейса EFI (Extensible Firmware Interface) от компании Intel. Таблица разделов GUID заменила собой метод форматирования главной загрузочной записи (Master Boot Record — MBR), который использовался в классических компьютерах Intel.
Для каждого раздела на загрузочном диске GPT выделяются глобальный уникальный идентификатор GUID (Globally Unique Identifier) и дескриптор типа. Скрытых разделов и специальных дисковых структур не существует, как не существует странных правил для логических дисков в расширенном разделе и загадочных махинаций для поддержки скрытых утилит от производителя.
Диски GPT хранят небольшую таблицу разделов в начале диска и ее копию в конце диска. В отличие от классической таблицы разделов MBR, которая не может содержать более четы-
рех записей, таблица разделов диска GPT может содержать до 128 разделов. Это предоставляет огромные возможности по структурированию больших дисков и дисковых массивов. Типичный загрузочный диск будет содержать такие разделы.
Системный раздел EFI (EFI System Partition — ESP). В этом разделе хранятся файлы, необходимые, для загрузки операционной системы. Если на диске находится несколько разделов, в которых установлены различные операционные системы, для загрузочных файлов каждой операционной системы в разделе EFS выделяются отдельные каталоги. Размер раздела ESP равен 1% от размера физического диска, но не может быть менее 100 Мбайт и более 1 Гбайт. Раздел ESP форматируется с использованием файловой системы FAT. На диске может существовать только один раздел ESP. Невозможно создать копию раздела ESP. Раздел ESP не отображается в оснастке Disk Management (Управление дисками) и не отображается в окне Explorer (Проводник).
Зарезервированный раздел Microsoft (Microsoft Reserved Partition — MSR). На каждом загрузочном диске должен быть один раздел MSR. В этом разделе хранится база данных диспетчера логических дисков (Logical Disk Manager — LDM) на случай, если будет принято решение перейти от разделов GPT к использованию динамических дисков. Раздел MSR должен находиться сразу же после раздела ESP (на незагрузочных дисках раздел ESP может отсутствовать; в этом случае раздел MSR является первым разделом). Размер раздела MSR зависит от размера диска. На дисках размером до 16 Гбайт раздел MSR составляет 32 Мбайт. На дисках размером более 16 Гбайт раздел MSR составляет 128 Мбайт. Раздел MSR также форматируется на основе файловой системы FAT. Этот раздел нельзя увидеть в окне Explorer (Проводник), но он отображается в оснастке Disk Management (Управление дисками).
Раздел OEM. Производители часто поставляют собственные утилиты диагностики и настройки в составе своих систем. Такие утилиты часто хранятся в скрытых разделах, которые очень мешают администраторам, желающим перераспределить дисковое пространство между разделами. При использовании дисков GPT производители могут создать собственные разделы OEM, в которых размещаются все необходимые утилиты. Раздел OEM также не отображается в окне Explorer (Проводник), но его можно увидеть с помощью оснастки Disk Management (Управление дисками).
Раздел данных Microsoft. Этот тип раздела используется операционными системами Windows Server 2003 и Windows ХР для создания разделов общего назначения.
Управление файлами, хранящимися в разделе ESP
В архитектуре EFI начальная загрузка выполняется непосредственно из прошивки аппаратного обеспечения, а не из загрузочных файлов на жестком диске. Раздел ESP не содержит копий файлов ntldr, ntdetect. com и boot. ini по следующим причинам.
Аппаратные проверки, которые выполняются утилитой Ntdetect.com, не нужны, поскольку операционная система может получить эту информацию непосредственно у микропрограммы прошивки.
Просмотр содержимого раздела ESP
Обычно содержимое раздела ESP нельзя просмотреть или изменить с помощью средств операционной системы. Управление файлами осуществляется из командного интерпретатора EFI (EFI Shell) еще до загрузки операционной системы.
Но операционные системы Windows Server 2003 и Windows ХР предоставляют параметр / s утилиты mountvol, который позволяет создать буквенное обозначение диска для раздела EFS. Необходимо воспользоваться следующей командой: mount vol г: /в. Многие файлы раздела ESP являются скрытыми.
Меню загрузчика хранится в энергонезависимой памяти (Non-Volatile RAM — NVRAM), поэтому отдельный файл boot. ini не требуется, а записи загрузочного меню отображаются средствами диспетчера загрузки EFI (EFI Boot Manager). Записи, выдаваемые при загрузке операционной системы Windows, можно изменить с помощью окна System Properties (Свойства системы) или утилиты bootcfg во время работы операционной системы Windows Server 2003.
Вторичный загрузчик операционной системы Windows Server 2003 хранится в файле Ia641dr.efi. Он расположен в разделе ESP в каталоге \EFI\Microsoft\WINNT50. Также в этом каталоге находится файл fpswa. ef i. Это обработчик Floating Point Software Assistance, в котором перечислены исключения при работе с числами с плавающей запятой, необходимые операционной системе. Дополнительная информация по этому вопросу доступна на сайте по адресу developer.intel.com/design/itanium/downloads/ 245415 .htm.
Если на компьютере установлено несколько копий операционной системы Windows Server 2003 и Windows ХР, то для каждой копии в разделе ESP выделяется отдельный каталог. Например, для второй копии будет создан каталог \EFl\Microsoft\wiNNT50.0, а для третьей копии — каталог \EFI\Microsoft\WINNT50.1 ит.д.
Диспетчер загрузки EFI (EFI Boot Manager) хранит путь к разделу операционной системы и связанному с ним вторичному загрузчику. Вот пример меню, которое отображается диспетчером загрузки EFI.
EFI Boot Manager ver 1.02 [12.36А]
Please select a boot option:
Microsoft Windows Server 2003 Standard Edition
Acpi(PNP0A03,0)/Pci{5|0)/Mac(0003478991556)
EFI Shell [Built-in]
Boot option maintenance menu
Каждая запись представляет собой путь к загрузочному файлу или рабочему командному интерпретатору. Ниже приводится описание этих записей.
Запись, обозначенная Acpi (PNP0A03,0)/Pci(5I0) /Мас (0003478991556), загружает дозагрузочную среду выполнения (Preboot Execution Environment — РХЕ), которая используется для загрузки установочного образа с сервера служб удаленной установки (RIS-сервер).
Вариант загрузки EFI Shell позволяет загрузить среду командного интерпретатора, в которой можно перемещаться по различным разделам на дисках и запускать выполняемые файды EFI.
Вариант Boot Option Maintenance Menu позволяет получить доступ к утилите управления содержанием меню.
Записи, соответствующие операционным системам, например Windows Server 2003 , Standard Edition, в данном случае представляют компактное значение в энергонезависимой памяти, которое декодируется в следующую запись.
Loadidentifier = Microsoft Windows Server 2003, Standard Edition OsLoadOptions =
EfiOsLoaderFilePath = HardDiskVolumel\EFl\Microsoft\WlNNT50\ia641dr.efi
OsLoaderFilePath = HardDiskVolume2\WINDOWS
Отдельные записи из энергонезависимой памяти не видимы непосредственно из командного интерпретатора EFI. Компания Microsoft предоставляет утилиту Nvrboot .efi, хранящуюся в системном разделе EFI, которая предназначена для управления записями в энергонезависимой памяти. Работа этой утилиты рассматривается в главе 3, “Добавление аппаратных средств”.
Резервное копирование данных энергонезависимой памяти
Если запись в энергонезависимой памяти случайно была перезаписана или повреждена, простого способа восстановить запись операционной системы в меню загрузчика не существует. Именно по этой причине программа установки при создании записи операционной системы для меню загрузчика сохраняет резервную копию меню загрузчика в файле Boot0004, который хранится в разделе ESP в том же каталоге, что и файл ia641dr. ef i (\efi\m1crosoft\ WINNT50).
Если на компьютере установлено несколько копий операционной системы Windows Server 2003 или Windows ХР, копия записи в меню загрузчика получает следующий порядковый номер (например, BootOOOS). Этот файл сохраняется в каталоге в разделе ESP, в котором содержится вторичный загрузчик данного экземпляра операционной системы.
Например, файл Ia641dr.efi для третьей копии операционной системы Windows будет сохранен в каталоге \EFi\Microsoft\wiNNT50.1, а запись меню загрузчика будет сохранена в этом каталоге в файле Boot0007.
В случае потери или перезаписи оригинальной записи операционной системы в энергонезависимой памяти можно воспользоваться пунктом Import утилиты Nvrboot. efi, что позволит импортировать содержимое файла BootOOO# в энергонезависимую память. Таким образом создается новая запись меню загрузчика без перезаписи существующих записей.
Размеры дисков GPT
Диски GPT могут содержать до 264 логических блоков. Логический блок обычно содержит один сектор, или 512 байт, что позволяет достигать невероятной суммарной емкости 8зеттабайт (таблица приставок доступна по адресу physics.nist.gov/cuu/Units/ prefixes. html.) Но операционная система Windows Server 2003 устанавливает предельный размер тома на уровне 16 эксабайт (Эбайт), что соответствует максимальному размеру раздела, поддерживаемому файловой системой NTFS. Это даже не кажется ограничением, но подождите выхода следующей версии Microsoft Office1!
Совместимость с MBR
Диски GPT не могут быть прочитаны стандартными утилитами, предназначенными для работы с дисками MBR. Это может привести к проблемам при использовании утилит, выполняющих автоматические операции над неразмеченными дисками.
Для защиты дисков GPT от повреждения такими утилитами спецификация GPT включает в себя специальную версию MBR. Эта запись расположена в секторе 0 и содержит таблицу разделов, описывающую весь диск, как один большой раздел, занимающий весь диск (или имеющий максимальный поддерживаемый MBR размер, в зависимости от того, какая величина меньше). Даже если утилита внесет изменения в эту структуру, это не помешает серверу на основе архитектуры IA64 получить доступ к томам на диске.
Разбиение дисков GPT на разделы
Разбиение дисков GPT выполняется с помощью прошивки EFI в системе или средствами операционной системы Windows Server 2003 или Windows ХР для архитектуры IA64. Стандартные версии операционных систем Windows Server 2003 и Windows ХР для архитектуры IA32 не в состоянии читать или записывать информацию на диски GPT. Версии для архитектуры IA64 позволяют читать и записывать информацию на диски MBR, но загрузка операционной системы может осуществляться только с дисков GPT. Более ранние версии операционных систем Windows не позволяют выполнять чтение, запись и загрузку с дисков GPT.
’ Приставка “зетта” соответствует К?’, а приставка “экса” (Э) — 10'*. — Примеч. ред.
Сменные носители не могут быть разбиты на разделы, как диски GPT. В архитектуре IA64 поддерживаются разделы для сменных носителей большого объема, например Jaz, Zip и Orb, а также магнитооптические диски и гибкие диски с повышенной плотностью записи. Последний тип дисков может содержать только один раздел, отформатированный с помощью файловой системы FAT, FAT32 или NTFS.
Подключаемые диски, например диски с интерфейсом Universal Serial Bus (USB) или IEEE 1394 или диски SCSI/Fibre Channel, установленные в кластер, должны форматироваться, как диски MBR, а не как диски GPT.
Порядок действий при установке
В большинстве случаев установка операционной системы Windows Server 2003 проходит без проблем. Но перед началом установки стоит представить себе наиболее вероятные проблемы. Предосторожность позволяет избежать серьезных проблем на более поздних этапах установки. В данном случае предполагается, что выполняется установка на пустой диск, а не модернизация существующей системы. Порядок действий, выполняемых при модернизации операционной системы, приводится в главе 2, “Модернизация и автоматизированная установка”.
Настройка компонентов
Одним из значительных отличий операционной системы Windows Server 2003 является использование технологии Plug and Play (РпР). И Windows Server 2003, и Windows 2000, кроме данных РпР BIOS, получают информацию РпР с помощью интерфейса ACPI (Advanced Configuration and Power Interface — усовершенствованный интерфейс конфигурирования системы и управления энергопитанием). Это может привести к конфликтам при распределении ресурсов и потенциальной несовместимости. Ниже изложено несколько подготовительных процедур, которые можно выполнить перед установкой или модернизацией операционной системы Windows Server 2003.
Прошивка. Полностью убедитесь, что используется самая последняя версия BIOS и самые последние версии прошивок компонентов.
ACPI. Если в системе используется материнская плата, которая выпущена более двух лет назад, убедитесь, что эта материнская плата указана в списке HCL. Если это не так, некоторые записи в таблице ACPI BIOS могут оказаться несовместимыми с операционной системой Windows Server 2003. В случае архитектуры IA64 компания Microsoft требует, чтобы компьютер соответствовал требованиям ACPI версии 2.0. Все системы, указанные в HCL, соответствуют этому требованию.
Отключите подсистему Plug and Play. Учитывая, что операционная система Windows Server 2003 поддерживает технологию Plug and Play, этот шаг может показаться странным, но перед началом установки стоит отключить поддержку РпР в BIOS. Для операционной системы Windows Server 2003 лучше использовать интерфейс ACPI, а не РпР BIOS.
Отключите последовательные подключения к блокам бесперебойного питания. Если используется программа слежения за блоком бесперебойного питания (UPS), например UPS support для операционных систем Windows NT и Windows 2000, или утилита от третьей фирмы, например PowerChute от компании АРС, отключите кабель последовательной линии перед запуском программы установки. Это позволит избежать длительных пауз в процессе обнаружения устройств. После завершения процедуры установки можно опять подключить кабель.
Отключите аппаратное кэширование дисков. Аппаратное кэширование дисков можно включать только в том случае, если компьютер специально проектировался для поддержки аппаратного кэширования под управлением операционной системы Windows Server 2003. Многие случаи массового повреждения данных в итоге сводились к использованию неподдерживаемого аппаратного кэширования дисков.
Подготовьте устройства мультимедиа. Настройка мультимедийных устройств может отнять удивительно много времени. Удостоверьтесь, что все устройства имеют драйверы для операционной системы Windows Server 2003, а также что названия и модели устройств указаны в списке HCL. Еще раз проверьте, нет ли на сайте производителя новых драйверов. И даже после этого, возможно, придется потратить половину дня на борьбу с незначительной (на первый взгляд) ошибкой.
Установите последовательность загрузки. Если планируется локальный запуск программы установки, то потребуется загрузка с установочного компакт-диска Windows Server 2003. Установочные гибкие диски не поддерживаются. Удостоверьтесь, что в параметрах BIOS загрузка с компакт-диска указана перед загрузкой с жесткого диска.
Подготовьтесь к использованию двух мониторов. Операционная система Windows Server 2003 поддерживает использование двух мониторов. Если в системе установлено два видеоадаптера, подсистема РпР определит оба видеоадаптера. Один из видеоадаптеров будет использоваться BIOS для вывода текстовой части процесса загрузки. Если подсистема РпР решит определить второй адаптер как основной, графический вывод будет осуществляться на втором адаптере. То есть, если в системе установлено два видеоадаптера и в процессе установки операционной системы на мониторе исчезло изображение, переключите монитор на второй видеоадаптер.
Используйте сетевые адаптеры с возможностью управления шиной. Используйте только самые качественные сетевые адаптеры с возможностью управления шиной PCI (busmastering). Такие адаптеры стоят немного дороже адаптеров, использующих программируемый ввод-вывод (Programmed I/O), но работают значительно лучше. При прочих равных характеристиках компьютер с высокой загрузкой сетевой подсистемы больше выиграет от установки сетевого адаптера с поддержкой управления шиной, чем от установки более быстрого процессора.
Установите параметры EFI на серверах IA64. На компьютерах на основе архитектуры IA64 для разбиения жестких дисков и подготовки другого аппаратного обеспечения используется интерфейс Extensible Firmware Interface. Диски должны быть подготовлены для использования GPT (GUID Partition Table), а не MBR (Master Boot Record).
В компьютерах на основе архитектуры IA64 используйте 64-разрядные адаптеры PCI. Использование 32-разрядных адаптеров в компьютерах на основе архитектуры IA64 невозможно. Удостоверьтесь, что в список расходов включены любые новые периферийные устройства, которые придется приобрести. И обязательно убедитесь, что 64-разрядный адаптер входит в список HCL для систем на основе архитектуры IA64, а не только для систем на основе архитектуры IA32.
Настройка подсистемы хранения
Проведите следующие проверки, чтобы убедиться, что система готова хранить системные файлы операционной системы Windows Server 2003.
Используйте новейшие драйверы подсистемы массового хранения. Если драйверы устройств SCSI, RAID и АТА не предоставляются в составе операционной системы Windows Server 2003 или предоставляемый в составе системы драйвер не является новейшим, получите последнюю версию драйвера и скопируйте драйвер на гибкий диск. В начале рабо-
ты программы установки нажмите клавишу <Е6>. Это заставит программу установки приостановить процесс установки и запросить драйвер устройства массового хранения.
Отключите дополнительные устройства от шины SCSI. Если в системе установлены такие устройства, как сканеры, устройства хранения информации на магнитной ленте и другие периферийные устройства, которые подключены к той же шине, что и устройство массового хранения, отключите эти устройства до завершения процедуры установки. Это позволит избежать потенциального конфликта, который приведет к “зависанию” программы установки.
Проверьте подключение кабелей SCSI. Если используются жесткие диски SCSI, операционная система Windows Server 2003 налагает более жесткие ограничения на время задержки, чем операционная система Windows NT. Если используется кабель SCSI максимально допустимой длины (согласно спецификации), то после модернизации системы возможно повреждение данных.
Используйте стандартный доступ к диску. Для дисков IDE/АТА убедитесь, что в параметрах BIOS указан тип доступа Standard, а не 32-bit или Enhanced. Операционная система Windows Server 2003 не поддерживает прерываний INT13, которые используются расширенными интерфейсами.
Приводы сменных носителей. Можно выполнить установку операционной системы Windows Server 2003 на сменный носитель, например, Iomega Jaz или Castlewood Orb. Для корпоративной системы это кажется не самым подходящим вариантом^ но зато позволяет моделировать различные условия работы. Если по какой-либо причине сменный носитель нельзя сделать загрузочным, можно загрузиться с фиксированного диска и разместить системные файлы на сменном носителе.
NASISAN. Убедитесь, что оборудование одобрено для использования вместе с операционной системой Windows Server 2003. Прошивка должна быть доступна для Virtual Disk Services. Получите информацию у поставщика оборудования.
Настройка сетевых адаптеров
Надежность и производительность сетевых подключений обычно оставляется “на потом’’ до завершения процедуры установки, пока компьютер не станет работать медленно или нестабильно. Выделите пару минут на меры предосторожности, чтобы избежать потенциальных проблем:
Убедитесь, что сетевой адаптер указан в списке HCL. Компания Microsoft официально Отказалась от поддержки нескольких сетевых адаптеров в операционной системе Windows Server 2003. В основном, это адаптеры Token Ring. Отказ от поддержки остальных адаптеров вызван тем, что драйверы этих устройств приводили к проблемам в работе операционной системы Windows 2000 или бета-версий операционной системы Windows Server 2003. В числе таких адаптеров оказались многие недорогие адаптеры и так называемые “белые ящики”.
Исключите потенциальные конфликты распределения ресурсов. Для обнаружения всех сетевых адаптеров в операционной системе Windows Server 2003 использует подсистему РпР. Эта подсистема попытается определить устаревший сетевой адаптер и загрузить подходящий драйвер. Если используется устаревший сетевой адаптер, убедитесь, что известны ресурсы, которые использует этот адаптер. Могут использоваться следующие ресурсы.
IRQ
Адрес порта ввода-вывода
Адрес оперативной памяти. (Этот ресурс необходим, только если адаптер использует адресацию памяти. Адресацию памяти используют все сетевые адаптеры PC
Card. В операционной системе Windows Server 2003 поддерживается 16-разрядная адресация памяти; отображается оперативная память на 32-разрядное адресное пространство. В данном случае конфликт возможен, только если несколько сетевых адаптеров используют один адрес оперативной памяти.)
Канал DMA для адаптеров, поддерживающих управление шиной
Для устаревших адаптеров выделите IRQ в параметрах BIOS, чтобы диспетчер РпР не назначал этот ресурс другим устройствам.
Всегда избегайте назначать устаревшему адаптеру линию запроса прерывания IRQ 9. Операционная система Windows Server 2003 использует это прерывание для управления линиями запроса прерывания (IRQ Steering) — специальной таблицы в BIOS, в которой перечислены ресурсы PCI и соответствующие им линии запроса прерывания. Эта таблица выступает в роли маршрутизатора прерываний, настраиваемого операционной системой для выбора различных запросов на прерывание. В операционной системе Windows Server 2003 механизм IRQ Steering отключить невозможно.
Совместно используемые прерывания. Совместно используемые прерывания могут стать причиной конфликта в зависимости от материнской платы и набора микросхем. Одни системы в состоянии обслуживать до шести или семи устройств, совместно использующих одну линию запроса прерывания. В других системах при использовании только двух устройств с одним прерыванием одна за другой возникают критические ошибки уровня ядра. Если программа установки “зависает” в процессе определения драйверов сетевых адаптеров, это можно рассматривать как признак потенциальных проблем при совместном использовании ресурсов.
Создание системы с двойной загрузкой
В системах на основе архитектуры IA32 загрузчик операционной системы Windows Server 2003 Ntldr в состоянии загрузить операционную систему WindowsNT 4.0, Windows 2000, Windows ХР и Windows Server 2003 с любого диска или раздела. Определенное в файле Boot. ini меню загрузчика описывает путь к загрузочным файлам каждой операционной системы. В системах на основе архитектуры IA64 выбором операционной системы для загрузки управляет загрузчик EFI.
Загрузчик Ntldr позволяет загружать только одну альтернативную операционную систему с помощью механизма использования альтернативого загрузочного сектора. Загрузчик Ntldr хранит альтернативный загрузочный сектор в файле Bootsect. dos, который расположен в корневом каталоге загрузочного раздела. При выборе альтернативной операционной системы из меню загрузчика загрузчик Ntldr переключает процессор обратно в реальный режим, загружает в память по смещению 0x700h (это смещение используется стандартным вызовом INT13) образ загрузочного сектора из файла Bootsect. dos и передает управление выполняемому коду внутри образа.
Если необходимо загружать более двух операционных систем и одна из систем не является системой Windows, воспользуйтесь диспетчером разделов, например, Partition Manager или System Commander. Если на компьютере планируется поддерживать загрузку нескольких операционных систем, стоит обратить внимание на следующие возможные проблемы.
Несовместимость версий NTFS. Операционная система Windows Server 2003 выполняет преобразование всех обнаруженных томов NTFS в тома NTFS версии 3.1. Если на компьютере одновременно используются операционные системы Windows Server 2003 и Windows NT 4.0, для операционной системы Windows NT 4.0 должен быть установлен Service Pack версии 6а, что позволит избежать возникновения критической ошибки режима ядра 0x00000007d, Inaccessible Boot Device.
VMWare
Если необходимо создать тестовую среду, в которой одновременно работают операционные системы Windows и Linux, обратите внимание на пакет VMWare (www.vmware.com). Сеанс VMWare позволяет поддерживать работу операционной системы Linux и любой версии операционной системы Windows внутри виртуальной машины. При этом можно даже моделировать добавление дополнительных дисков.
Динамические диски. В состав операционной системы Windows Server 2003 входит служба LDM (Logical Disk Manager — диспетчер логических дисков), которая поддерживает динамическое конфигурирование отказоустойчивых томов. Только операционные системы Windows 2000 и Windows Server 2003 в состоянии читать базу данных LDM. Использование других операционных систем одновременно с динамическими дисками невозможно.
Отдельные разделы для систем Windows. Компания Microsoft настоятельно рекомендует использовать отдельные разделы для каждой 32-разрядной версии операционной системы Windows в конфигурациях с множественной загрузкой. Различные версии операционной системы Windows стали слишком подобны, чтобы их можно было хранить в одном разделе.
Пакеты обновлений для операционной системы Windows NT 4.0 перезаписывают основные системные файлы. Если установить пакет обновлений для операционной системы WindowsNT 4.0 или Windows 2000 на компьютер с загрузкой двух операционных систем, версия загрузчика Ntldr операционной системы Windows Server 2003, находящегося в корневом каталоге загрузочного диска, будет перезаписана. При этом станет невозможной загрузка операционной системы Windows Server 2003. Перед установкой альтернативного пакета обновлений скопируйте файлы Ntldr и Ntdetect. com. Скопируйте эти файлы обратно после установки пакета обновлений.
Дисковые утилиты. Не стоит запускать дисковые утилиты, не сертифицированные для операционных систем Windows Server 2003 и Windows ХР. Несовместимость утилит может привести к повреждению файлов операционной системы.
Обзор возможностей программы установки Windows Server 2003
В данном разделе подробно рассматривается, что происходит в процессе установки операционной системы Windows Server 2003. Здесь рассматриваются основные этапы установки, которые являются основой для принятия решений о конфигурации. Пошаговые инструкции приводятся в разделе “Установка операционной системы Windows Server 2003” этой главы.
Программа установки операционной системы Windows Server 2003 действует, как опытный моряк, швартующий корабль к пирсу. Моряк бросает легкий линь на берег для подтягивания более тяжелого линя. Более тяжелый линь закрепляется на блоке и используется для переброса еще более тяжелого линя. И уже самый тяжелый линь используется для закрепления корабля на пирсе.
Программа установки “закрепляет” операционную систему Windows Server 2003 на компьютере с помощью трех отдельных процедур копирования файлов, которые выполняются в два этапа, а в ходе третьего этапа выполняется окончательная настройка системы.
Текстовый этап. Этот этап начинается с загрузки с установочного компакт-диска операционной системы Windows Server 2003. Во время этого этапа с помощью небольшого набора файлов создается мини-сеанс Windows Server 2003. В течение этого сеанса выполняются разбиение и форматирование устройства массового хранения, создание системных каталогов, монтирование компакт-диска и копирование файлов, необходимых для под-
держки следующего этапа установки. В отличие от предыдущих версий, в которых была только возможность выбора форматирования тома операционной системы с помощью файловой системы NTFS, программа установки на самом деле выполняет форматирование в файловую систему NTFS, а не начинает с форматирования FAT/FAT32 с последующим преобразованием в NTFS. После этого этапа выполняется перезагрузка компьютера.
Графический этап. На этом этапе программа установки обнаруживает и проводит инвентаризацию аппаратных средств, получает конфигурационную информацию от пользователя и копирует окончательный набор файлов с компакт-диска для получения драйверов, необходимых для завершения установки операционной системы и настройки служб. После этого этапа выполняется перезагрузка операционной системы.
Этап конфигурирования. Этот этап начинается после регистрации нового пользователя. Начинается последний проход обнаружения устройств РпР, которые не были обнаружены в ходе графического этапа установки. Пользователю может быть выдан запрос на предоставление драйверов, если эти драйверы не были обнаружены в составе операционной системы. Кроме этого, запускаются мастер настройки сервера (Server Configuration Wizard), позволяющий настроить дополнительные параметры, и мастер активации продукта Windows (Windows Product Activation Wizard), который позволяет получить ключ активации. В зависимости от добавленных компонентов и выделенных ресурсов системе может потребоваться дополнительная перезагрузка. После этого система готова к работе.
В следующих разделах кажый этап процедуры установки рассматривается более подробно.
Текстовый этап
Этот этап начинается с загрузки с установочного компакт-диска операционной системы Windows Server 2003. Кроме этого, можно подключиться к совместно используемому ресурсу с установочным образом и запустить программу установки вручную: winnt позволит запустить программу установки под управлением операционной системы DOS; winnt 32 позволит запустить программу установки под управлением операционных систем Windows NT и Windows 2000. Дополнительная информация о запуске программы установки с сетевых дисков представлена в главе 2, “Модернизация и автоматизированная установка”.
Загружаемые выполняемые файлы программы установки
Установочный компакт-диск для архитектуры IA32 содержит загрузочный образ, который соответствует стандарту El Torito “non-emulation”. В этот образ входят файлы, необходимые для создания мини-сеанса Windows Server 2003, который выступает в роли отправной точки для основной программы установки. Выполняемый код загрузочного образа ищет файл Setupldr.bin, который содержит загрузчик программы установки операционной системы Windows Server2003. На самом деле файл Setupldr.bin является копией стандартного вторичного загрузчика операционной системы Windows Server 2003, Ntldr, в который внесены некоторые изменения для поддержки процедуры установки.
Управлять текстовым этапом установки можно с помощью сценария, который хранится в файле Txt setup. sif. Этот сценарий сообщает программе установки следующую информацию:
где найти загрузочные файлы;
какие каталоги разместить в загрузочном разделе;
какие файлы скопировать в системный и загрузочный разделы;
какие драйверы загружать с самого начала;
что делать с существующими файлами;
какие разделы включить в базовый реестр для поддержки графического этапа установки.
Начальное обнаружение аппаратных средствI
Компьютеры на основе архитектуры IA32 не имеют прошивки для распознавания аппа- ; ратных средств, как на компьютерах IA64, поэтому загрузчик Setupldr. bin загружает про- | граммный анализатор аппаратных средств Ntdetect. com. На этом этапе отображается со- | общение о том, что программа установки исследует аппаратные средства компьютера (SetupJ
is inspecting your computer’s hardware configuration).i
Анализатор Ntdetect. com обнаруживает информацию об аппаратном обеспечении, не- j обходимую для ядра установки операционной системы Windows Server 2003 Ntkrnlmp. exe;
и библиотеки уровня аппаратных абстракций (Hardware Abstraction Layer — HAL) Hal. dll.г,
Программа установки всегда использует многопроцессорное ядро и HAL. Если обнаружива- ; ется, что на компьютере установлен только один процессор, устанавливается однопроцессор- г ная версия ядра. Если материнская плата поддерживает эту возможность, второй процессор ‘ можно добавить позднее. Операционная система Windows Server 2003 автоматически затру- ( жает файлы многопроцессорного ядра, как только обнаруживает дополнительный процессор.
Проверки на совместимость ACPIJ
Интерфейс ACPI развивался несколько лет до появления версии 2 в 1999 году. Это зна- | чит, что появившиеся до 1999 года компьютеры использовали различные возможности ин- f терфейса ACPI. Для операционной системы Windows Server 2003 требуется полная поддерж-|
ка компьютером стандарта интерфейса ACPI версии 2, но вместо отказа в поддержке уста-[
ревших компьютеров компания Microsoft собрала оперативную информацию о множестве [ платформ и на основе этой информации внесла исправления для набора функций ACPI.|
Теперь, когда интерфейс ACPI прошел проверку временем, более старый стандарт АРМ ' (Advanced Power Management — усовершенствованное управление энергопотреблением) под-■
держивается все реже. И в этом случае для поддержки обратной совместимости компанияI
Microsoft сохранила поддержку устаревшего стандарта АРМ, но такая поддержка использует- ся, только если интерфейс ACPI не обнаруживается.I
В главе 3, “Добавление аппаратных средств”, рассматривается поддержка устаревших pea- j лизаций интерфейса ACPI в операционной системе Windows Server 2003. Если в компьютере I возникают проблемы с реализацией интерфейса ACPI (о которых можно судить по следую- ; щим признакам: необъяснимые “зависания", аварийное завершение работы, нестабильная ра- ' бота), то можно воспользоваться ядром Standard PC. Это необходимо сделать в самом начале текстовой фазы процесса установки, когда выдается предложение нажать клавишу <Е6> для установки альтернативного драйвера устройства массового хранения. Нажмите клавишу <Е7> для отказа от использования ядра ACPI и установки ядра Standard PC. Сменить ядро ACPI без переустановки системы невозможно.
Специальные клавиши для процесса установки
В течение первых секунд процесса установки доступно несколько специальных параметров установки. Доступ к этим параметрам осуществляется с помощью следующих функциональных клавиш.
<F2>. После нажатия этой клавиши при появлении окна приглашения запускается процедура автоматического восстановления системы (Automatic System Recovery — ASR), которая позволяет быстро восстановить систему с магнитной ленты. Дополнительная информация приводится в главе 21, "Восстановление после отказов системы".
<F5>. Позволяет выбрать альтернативный тип ядра. В числе доступных вариантов можно назвать ACPI, Standard PC, I486 C-stepping и SGI MP.
<F6>. Позволяет загрузить драйвер устройства массового хранения, отсутствующий на установочном компакт-диске операционной системы Windows Server 2003.
<F7>. Пропускает загрузку ядра ACPI и загружает ядро для стандартного ПК.
<F10>. При нажатии этой клавиши во время отображения экрана приглашения запускается консоль восстановления. Дополнительная информация содержится в главе 21, "Восстановление после отказов системы".
При нажатии клавиш <F5> и <F6> системе потребуется некоторое время для выполнения ответных действий. Подождите несколько минут, пока не появятся соответствующие меню.
Если необходимо выполнить автоматизированную установку, измените файл Txt setup. inf для отключения ACPI. Вот фрагмент файла Txtsetup. inf.
[ACPIOptions]
ACPIEnable = 2
ACPIBiosDate = 01,01,1999
Измените значение параметра ACPIEnable с 2 на 0 и переустановите операционную систему Windows Server 2003.
Присвоение дискам буквенных обозначений
Давным-давно в далекой галактике для идентификации дисковых разделов компания Microsoft решила использовать буквы, а не идентификаторы файловой системы в стиле UNIX. Предполагалось, что это позволит создать дружественные имена для интерфейсов файловой системы. Без сомнений, буквы для обозначения дисков сделали файловые системы проще для конечных пользователей, но они же стали источником нескончаемых проблем для системных администраторов.
Служба Mount Manager (Диспетчер монтирования), MountMgr, отвечает за инвентаризацию дисков и присвоение дискам буквенных обозначений. Процесс инвентаризации может отличаться в зависимости от того, проводится ли установка операционной системы Windows Server 2003 на чистый жесткий диск или выполняется модернизация. Случай модернизации рассматривается в главе 2, “Модернизация и автоматизированная установка”.
При установке операционной системы Windows Server 2003 на чистый винчестер на компьютере уже могут существовать разделы, которые хотелось бы сохранить, поэтому программа установки сканирует диски и назначает буквы существующим разделам. При этом раздел не обязательно должен содержать поддерживаемую файловую систему. Буквенные обозначения дисков могут быть присвоены разделам HPFS и Linux.
Сначала программа установки проверяет наличие динамических дисков и использует буквы, описанные в базе данных LDM. Это делается с целью поддержки приложений, которые могут ссылаться на эти буквы дисков. Разделы делятся на две категории.
Аппаратные разделы (hard-linked partition). Если диск был преобразован из базового в динамический, устаревшая таблица разделов остается на месте, чтобы ее могла читать BIOS системы для обнаружения активного раздела и загрузки загрузочного сектора из этого раздела. Это так называемый аппаратный раздел, так как нет необходимости в загрузочном коде в MBR, который будет читать базу данных LDM для поиска загрузочного раздела.
Таблицы программных разделов (soft-linked partition). Если диск никогда не разбивался, как базовый, он не содержит устаревшей таблицы разделов. Разделы определяются только в базе данных LDM и поэтому называются программными разделами.
В процессе сканирования динамических дисков программа установки использует следующие критерии для присвоения дискам буквенных обозначений.
Динамические диски с аппаратными разделами. Сначала программа установки опрашивает базу данных LDM, чтобы определить буквы дисков, назначенные аппаратным разделам. Если никакие буквы не назначены дискам, то разделу назначается первая свободная буква.
Динамические диски с программными разделами. После назначения букв для дисков аппаратным разделам программа установки запрашивает в базе данных LDM информацию о буквах дисков, назначенных программным разделам. Такие буквы назначаются повторно, если они не вступают в конфликт с буквами дисков, назначенными для аппаратных разделов. Если конфликт возникает или если не назначена ни одна буква диска, диску назначается следующая доступная буква.
Если на динамическом диске необходимо изменить букву логического диска, программа установки создает новые буквы в базе данных LDM. После сканирования и назначения букв разделам на динамических дисках программа установки переходит к обработке базовых дисков.
На рис. 1.1 изображена схема назначения букв для дисков в компьютере с двумя приводами жестких дисков. Один из приводов имеет интерфейс IDE, а другой — SCSI. Оба диска являются базовыми. В процессе сканирования дисков встроенный интерфейс IDE определяется ранее интерфейса SCSI. Контроллеры Ultra-DMA АТА рассматриваются в данном случае как контроллеры SCSI, поэтому их сканирование выполняется после сканирования встроенных контроллеров. Буквы дисков назначаются следующим образом.
Активные разделы. Программа установки сканирует диски, пытаясь обнаружить основной раздел, отмеченный как активный (Active). Предполагается, что динамические диски в системе отсутствуют, поэтому буква С назначается первому активному разделу на первом диске в последовательности сканирования. Если диск не содержит активного раздела, программа установки присваивает следующую букву для первого основного раздела диска.
ДискСДискСДискЕДискЕДискЕДискЕДискиДискиДиск КДиск КДиск IDEДиск IDEЛогический диск 1Логический диск 1Логический диск 2Логический диск 2Основной раздел 2Основной раздел 2Основной раздел 1 - АРаздел 2 • РасширенныйОсновной раздел 1 - АРаздел 2 • Расширенный|— Диски |~ ДискМ Р ДискС | ДискН | ДискР|— Диски |~ ДискМ Р ДискС | ДискН | ДискРДиск SCSIОсновной раздел 1Основной раздел 2Раздел 2 - РасширенныйДиск SCSIОсновной раздел 1Основной раздел 2Раздел 2 - РасширенныйОсновной раздел 3Основной раздел 3Логический диск 2Логический диск 2Логический диск 1Логический диск 1Основной раздел 3 - АОсновной раздел 3 - А
ДискС
ДискС
ДискЕ
ДискЕ
ДискЕ
ДискЕ
Диски
Диски
Диск К
Диск К
Диск IDE
Диск IDE
Логический диск 1
Логический диск 1
Логический диск 2
Логический диск 2
Основной раздел 2
Основной раздел 2
Основной раздел 1 - А
Раздел 2 • Расширенный
Основной раздел 1 - А
Раздел 2 • Расширенный
|— Диски |~ ДискМ Р ДискС | ДискН | ДискР
|— Диски |~ ДискМ Р ДискС | ДискН | ДискР
Диск SCSI
Основной раздел 1
Основной раздел 2
Раздел 2 - Расширенный
Диск SCSI
Основной раздел 1
Основной раздел 2
Раздел 2 - Расширенный
Основной раздел 3
Основной раздел 3
Логический диск 2
Логический диск 2
Логический диск 1
Логический диск 1
Основной раздел 3 - А
Основной раздел 3 - А
Рис. 1.1. Схема назначения букв дисков для системы с одним приводом с интерфейсом ГОЕ и одним приводом с интерфейсом SCSI. Основные разделы, помеченные буквой А, являются активными
Расширенные разделы и приводы сменных носителей. Программа установки сканирует диски еще раз, на этот раз пытаясь обнаружить логические диски в составе расширенных разделов и приводы сменных носителей, например, Jaz или Orb. При этом буквы диска назначаются, начиная с первой свободной.
Основные разделы. Программа установки выполняет еще одно сканирование дисков, на этот раз пытаясь обнаружить оставшиеся основные разделы. Буквы дисков назначаются последовательно, начиная с первой свободной.
Приводы компакт-дисков и дисков DVD. Наконец программа установки назначает буквы дисков приводам компакт-дисков и приводам DVD. Буквы назначаются последовательно таким образом, что привод компакт-дисков, подключенный к первому контроллеру IDE, получит букву диска раньше, чем привод компакт-дисков, подключенный ко второму контроллеру IDE, а привод компакт-дисков, подключенный к контроллеру SCSI, получит букву диска в последнюю очередь.
Установленные буквенные обозначения дисков записываются в системный реестр, чтобы сохранить соответствие букв для дисков после перезагрузки. При этом буквы для дисков оказываются “закрепленными”, что очень важно при установке приложений и создании ссылок или других соединений OLE.
После завершения установки можно изменить буквы, назначенные для любого раздела, кроме букв для загрузочного и системного разделов. Это позволяет избежать потенциального конфликта, когда согласно записям в системном реестре необходимые системные файлы хранятся на диске, для которого установлена определенная буква. Не пытайтесь изменить назначенные буквы дисков с помощью изменения данных системного реестра. Это работало в операционной системе Windows 2000, но в Windows Server 2003 это приведет к отказу программы Windows Product Activation предоставить доступ, что потребует переустановки операционной системы.
Установочные файлы
Загрузчик Setupldr.bin использует установочные файлы из загрузочного образа для создания мини-версии операционной системы Windows Server 2003. В число этих файлов входят драйверы видеоадаптера, драйверы клавиатуры, драйверы устройств массового хранения и драйверы файловой системы. Ниже перечислены важные драйверы и их назначение.
Atapi.sys. Это драйвер IDE/EIDE. Прежний драйвер, Atdisk. sys, больше не используется. Отсутствует поддержка дисков ESDI/WD1003.
Disk.sys, Class2.sys и Classpnp.sys. Это драйверы интерфейса устройств массового хранения и соответствующего нумератора устройств РпР.
Dmboot.sys, Dmio.sys и Dmload.sys. Этот набор драйверов поддерживает работу LDM (Диспетчер логических дисков).
Floppy.sys. Драйвер мини-порта привода гибких дисков.
Уровень аппаратных абстракций (Hardware Abstraction Layer — HAL). Существует несколько драйверов уровня аппаратных абстракций. Конкретный драйвер выбирается программой установки в зависимости от типа аппаратного обеспечения.
Расширители ввода-вывода. Это шинные драйверы WDM, которые работают совместно с РпР Manager для определения маршрутов прохождения данных в системе. Существуют расширители для РСМС1Д, PCI IDE, Toshiba IDE, VIA IDE, IBM Thinkpad IDE, Intel IDE и контроллеров гибких дисков.
I2Omp.sys и I2Omgmt.sys. Этот набор драйверов служит для поддержки подсистемы 12О. Это позволяет загружать систему посредством контроллеров Intelligent Input/Output.
I8042prt.sys. Драйвер клавиатуры является виртуализацией BIOS контроллера 8042, а также управляет мышью стандарта PS/2. Если при нажатии клавиш на экране появляются бессмысленные символы или мышь работает некорректно, есть вероятность, что драйвер клавиатуры не совместим с клавиатурой, мышью или интерфейсом PS/2, установленным на материнской плате.
Isapnp.sys. Нумеризатор РпР для шины ISA. Этот драйвер известен еще со времен операционной системы WindowsNT4.0. Он предоставлялся в каталоге \Support на установочном компакт-диске операционной системы WindowsNT 4.0. Такие производители устройств мультимедиа, как Creative Labs, используют этот драйвер для более простой установки устройств ISA, например звуковых адаптеров и игровых интерфейсов.
Kbdclass.sys и Kbdus.dll. Это драйвер клавиатуры и драйвер отображения клавиатуры. При использовании дешевых комплектующих эти два драйвера могут привести к возникновению проблем. Если постоянно возникают ошибки при использовании клавиши <Caps Lock> или скорость повтора удерживаемой клавиши оказывается нестабильной, возмож-
но, придется заменить клавиатуру. Загрузочный образ содержит полный набор динамически загружаемых библиотек международных клавиатурных раскладок.
Ksecdd.sys. Это драйвер безопасности ядра. Он работает с драйверами ввода-вывода для открытия и чтения дескрипторов безопасности объектов.
Mountmgr.sys, Ftdisk.sys и Partmgr.sys. Этот набор драйверов поддерживает базовые конфигурации дисков и классические отказоустойчивые массивы дисков.
Поддержка национальных языков (National Language Support — NLS). В этих файлах находится информация о региональных стандартах, наборах символов, символах пунктуации и т.д. Для языка “Английский (США)” программа установки загружает кодовые страницы C_1252.NLS и C_437.NLS. Кроме этого, загружается основной файл языка L_INTL.NLS.
Ntdll.dll. Библиотека функций Windows Server 2003 API.
Ntfs.sys, Fastfat.sys и Cdfs.sys. Драйвер файловой системы NT, драйвер файловой системы FAT и драйвер файловой системы CD. Драйвер Fastfat.sys поддерживает как FAT16, так и FAT32. На установочном компакт-диске операционной системы Windows Server 2003 содержатся драйверы и других файловых систем, но на данном этапе программе установки они не нужны.
Openhci.sys, Uhcd.sys, Usbd.sys, Usbhub.sys и Hidusb.sys. Драйверы интерфейса USB (Universal Serial Bus). Эти драйверы работают с набором драйверов Human Interface Device (HID) для поддержки устройств USB.
Scsiport.sys. Это драйвер шины SCSI. Вместе с ним предоставляется несколько драйверов мини-порта для различных адаптеров SCSI.
Serial.sys и Serenum.sys. Контроллер последовательной шины и нумератор (enumerator) устройств РпР. Эти два драйвера работают совместно с целью поиска устройств РпР и устаревших устройств, подключенных к портам RS232. Этот процесс может длиться достаточно долго из-за небольшой скорости передачи данных по интерфейсу RS232. Именно по этой причине в стандартном файле boot. ini содержится параметр / fastdetect, который откладывает инвентаризацию устройств, подключенных к последовательной шине, до завершения загрузки системы.
Setupreg.hiv. Небольшой файл системного реестра с записями для инициализации драйвера уровня ядра Windows Server 2003, setupdd. sys. Этот драйвер используется для загрузки всех остальных драйверов. Содержимое файла setupreg. hiv можно просмотреть после установки, загрузив этот файл в редактор системного реестра.
Smss.exe. Драйвер подсистемы диспетчера сеансов (Session Manager Subsystem). Диспетчер сеансов отвечает за загрузку и инициализацию системных драйверов.
Vga.sys, Videoprt.sys и Vgaoem.fon. Стандартные драйверы видеоадаптера VGA и один шрифт для отображения на экране.
Выбор формата диска
После того как файл setupldr.bin загрузил драйверы в память, выполняется инициализация диспетчера драйверов ядра ntkrnlmp.exe. Этот диспетчер работает совместно с Session Manager (Диспетчер сеансов) ssms . ехе для инициализации операционной системы.
На этом этапе программа установки предлагает выполнить создание разделов на устройстве массового хранения и выбрать файловую систему NTFS или FAT. Предоставляется возможность быстрого форматирования или стандартного форматирования. В случае быстрого форматирования удаляется текущая файловая система и создается новая, но' сканирование секторов не выполняется. Стоит использовать быстрое форматирование только для тех дисков, которые были предварительно проверены с помощью другой утилиты.
В отличие от операционных систем Windows NT и Windows 2000, при выборе файловой системы NTFS программа установки на самом деле выполняет форматирование в эту файловую систему, а не форматирует сначала файловую систему FAT/FAT32 с последующим преобразованием в NTFS. Это позволяет избежать фрагментации MFT. Если выбрать форматирование в FAT или FAT32, полученная после преобразования файловая система NTFS сохранит размер кластера исходной файловой системы. В операционных системах Windows NT и Windows 2000 преобразование всегда приводило к возникновению кластеров размером 512 байт.
Если выбрать файловую систему FAT для раздела, размер которого превышает 2 Гбайт (это предел для разделов DOS с размером кластера 32 Кбайт), программа установки автоматически выполнит форматирование в файловую систему FAT32. Операционные системы Windows Server 2003 и Windows 2000 не поддерживают форматирование разделов FAT32 размером более 32 Гбайт. Если необходим загрузочный раздел размером более 32 Гбайт на основе файловой системы FAT32, подготовьте этот раздел до запуска программы установки с помощью утилиты от третьего производителя. Вообще, не рекомендуется использование больших загрузочных разделов, особенно с файловой системой FAT32.
После форматирования загрузочного и системного разделов необходимые для графического этапа установки файлы копируются с установочного компакт-диска. После завершения копирования файлов автоматически выполняется установка. Запись в файле boot. ini сообщает загрузчику nt Idr, где можно найти файлы, необходимые для продолжения установки.
Графический этап
После перезагрузки компьютера программа установки продолжает свою работу. Как говорила Дороти, уезжая из старого доброго Канзаса, мы можем сказать текстовому режиму “Пока!”. Система переключается в графический режим.
В ходе графического этапа установки происходит намного больше операций, но й на экран выдается больше информации, поэтому объяснений требуется меньше. Существует несколько моментов для принятия критически важных решений. Решения касаются лицензирования, настройки серверов имен, установки пароля администратора, настройки рабочих групп или доменов, а также установки системного времени.
Определение загрузочного и системного разделов
При использовании терминов загрузочный и системный разделы автор этой книги старается полностью следовать традиции их применения в компании Microsoft. Их определение может показаться несколько запутанным.
Системный раздел. Это раздел, в котором содержатся файлы, необходимые для загрузки операционной системы Windows. Для платформы Intel это файлы ntldr, boot. ini, ntdetect.com, bootsect.dos и ntbootdd.sys (если на устройстве SCSI отсутствует встроенная BIOS). Системный раздел должен быть отмечен в таблице разделов как активный (или загрузочный). Файлы должны находиться в корневом каталоге загрузочного диска. Программа установки предполагает, что загрузочным является первый диск на первом контроллере IDE. Если раздел на этом диске не отмечен как активный, программа установки отметит его как активный.
Загрузочный раздел. Этот раздел содержит файлы, необходимые для работы операционной системы. По умолчанию для операционной системы Windows Server 2003 программа установки размещает эти файлы в каталоге \windows (в операционных системах Windows 2000 и Windows NT файлы размещались в каталоге \ winnt). Загрузочный раздел может находиться на любом диске. Если разместить загрузочный раздел не на загрузочном диске, программа установки предложит создать небольшой системный раздел на загрузочном диске. Системный раздел может иметь размер менее 1 Мбайт. Главное, чтобы хватило места для хранения файлов ntldr, ntdetect. com, boot. ini и ntbootdd. sys.
Лицензирование
Приобретенная лицензия на операционную систему Windows Server 2003 не всегда означает наличие лицензии на подключение клиентов к серверу. Для этого необходимо приобрести клиентские лицензии на доступ (Client Access License — CAL). Клиентская лицензия представляет собой лист бумаги стоимостью в пределах от 15 до 40 долларов в зависимости от количества лицензий и наценки продавца. Этот документ предоставляет право на подключение клиентов к серверу под управлением Windows Server.
В цену Windows Server обычно включена стоимость пяти или более клиентских лицензий, но существуют Stock Keeping Units (SKU), которые вообще не включают в себя клиентские лицензии, поэтому, заказывая операционную систему, стоит внимательно читать позиции каталога. Сертификаты клиентских лицензий необходимо хранить в надежном месте, так как они понадобятся при проверке компанией Software Publishers Association (SPA) или внутрикорпоративными аудиторами.
При модернизации операционной системы Windows 2000 до Windows Server 2003 необходимо также провести модернизацию клиентских лицензий. В лицензионном соглашении четко записано, что номер версии клиентской лицензии на доступ должен совпадать с номером версии сервера, к которому подключается клиент. Именно стоимость модернизации наиболее высока. Модернизация SKU для Windows Server 2003 Standard Edition может стоить около 500 или 400 долларов, но модернизация клиентских лицензий может стоить от 10 до 20 долларов за лицензию.
Операционная система Windows Server 2003 предлагает два типа лицензирования клиентского доступа: на устройство (Per Device); на пользователя (Per User) и на сервер (Per Server). Обе формы лицензирования требуют приобретения клиентских лицензий на доступ, но количество приобретаемых лицензий и метод их подсчета отличаются.
Лицензия на сервер
Этот метод лицензирования напоминает традиционное лицензирование, которое применялось в операционных системах NetWare и Banyan. Лицензия на сервер заключается в выдаче лицензий на одновременное подключение. Например, если приобрести копию Windows Server 2003 вместе с 25 клиентскими лицензиями, то в процессе установки количество лицензий на сервер необходимо установить равным 25. Если к серверу одновременно подключены 25 пользователей, двадцать шестому пользователю будет отказано в доступе. Если одновременно к серверу должны подключаться более 25 пользователей, придется приобретать дополнительные клиентские лицензии на доступ и использовать утилиту License Manager (Диспетчер лицензий) для увеличения разрешенного количества лицензированных подключений. Утилиту можно запустить из меню Start (Пуск), выбрав Starts All Programs^ Administrative Tools^License Manager (Пуск^Все программы^Администрирование^Диспетчер лицензий).
Клиентские лицензии на доступ и серверы приложений
Если сервер используется как платформа для приложения типа "клиент/сервер", то не требуется приобретать клиентские лицензии на доступ для Windows Server 2003. Например, если под управлением операционной системы Windows Server 2003 работает служба Lotus Notes, для подключения клиентов Notes к службе Notes клиентские лицензии не требуются. Но если для запуска клиента Notes по сети клиент подключает сетевой диск с сервера под управлением Windows Server 2003, клиентская лицензия на доступ необходима. Если приложение использует возможности подсистемы безопасности операционной системы Windows Server 2003 для аутентификации подключений, приобретение клиентских лицензий также необходимо.
Восстановление после лицензионной блокировки
Иногда пользователи остаются подключенными к серверу, даже если ресурсы сервера не используются. При этом продолжают использоваться лицензии на подключение, что может привести к блокировке, при которой новые подключения становятся невозможными. При такой блокировке допускается подключение пользователя с привилегиями администратора для обновления текущего количества лицензий или отключения пользователей.
При установке второго сервера под управлением Windows Server 2003 при лицензировании на сервер необходимо приобрести еще один набор клиентских лицензий для тех же пользователей, которые подключаются к первому серверу, чтобы они могли легально подключаться ко второму серверу. Если в организации используется несколько серверов, лицензирование на сервер может оказаться достаточно дорогим.
В основном, лицензирование на сервер имеет смысл только при различных клиентах для каждого сервера или при минимальном совпадении пользователей, работающих на нескольких серверах. В противном случае намного дешевле использовать лицензии на рабочее место (Per Seat).
Лицензия на устройство и/или на пользователя
Операционная система Windows Server 2003 использует схему лицензирования, отличающуюся от лицензирования в предыдущих версиях Windows или Windows NT. Вместо лицензии на рабочее место система предлагает лицензию на устройство или на пользователя. При классической схеме выдачи лицензии на рабочее место для каждого устройства нужна клиентская лицензия на доступ. Если на рабочем столе разработчика находилось пять компьютеров, для соответствия лицензионному соглашению необходимо было приобрести пять клиентских лицензий.
При лицензии на устройство или на пользователя разработчику с пятью компьютерами потребуется единственная клиентская лицензия на доступ “на пользователя”. Точно так, если рабочие одной смены используют 10 переносных компьютеров для доступа к сети и рабочие каждой смены используют одни и те же переносные компьютеры, потребуется приобрести только 10 клиентских лицензий доступа “на устройство”.
Иначе говоря, если существуют сотни персональных компьютеров и дюжина пользователей, потребуется приобретать только 12 клиентских лицензий “на пользователя". Если существуют сотни пользователей и дюжина персональных компьютеров, то придется приобретать только 12 клиентских лицензий “на устройство”. Если сотрудник использует и переносной компьютер для работы со складом, и рабочую станцию для фиксации рабочего времени, то потребуется приобрести или две клиентские лицензии “на устройство”, или клиентскую лицензию “на устройство” и клиентскую лицензию “на пользователя”. Подсчет наиболее удобного числа лицензий может потребовать больших затрат времени и сил, но при наличии большого количества нерегулярно работающих пользователей это поможет сохранить много денег.
Любое подключение с помощью сетевой службы, кроме анонимных Web-подключений для лиц, не являющихся сотрудниками компании, требует клиентской лицензии “на пользователя” или клиентской лицензии “на устройство”. В число таких сетевых служб входят и службы NFS, и службы FTP.
Можно выполнить переход от лицензирования “на сервер” к лицензированию “на устройство" или “на пользователя”, но обратный переход невозможен. Такой переход имеет смысл, когда организация выросла до состояния, при котором приобретение отдельных лицензий для нескольких серверов перестает иметь смысл.
Лицензии сервера терминалов
В отличие от Windows NT 4.0 в Windows Server 2003 службы терминалов (Terminal Services) являются частью операционной системы. По умолчанию службы терминалов предоставляются с помощью службы Remote Desktop (Удаленный рабочий стол). Только администраторы
могут подключаться к серверу с помощью Remote Desktop, и даже в этом случае существует ограничение — два одновременных подключения. Если необходимо, чтобы обычные пользователи получали доступ к серверу с помощью сеансов служб терминалов, придется установить Terminal Services (Службы терминалов) для включения режима Application Services (Службы приложений).
Лицензирование сеансов служб терминалов может оказаться дорогостоящим и длительным процессом. Необходимо заплатить не только за клиентские лицензии для сетевого подключения, но и за клиентские лицензии Terminal Services или за лицензию на операционную систему Windows ХР Professional. Это связано с тем, что сеанс службы терминалов приравнивается к запуску копии операционной системы Windows ХР. За большое количество клиентских лицензий Terminal Services можно получить скидки, которые значительно снижают стоимость лицензирования.
Существует еще один подводный камень, о котором следует помнить при управлении лицензиями сервера терминалов. Лицензии выдаются на клиентское аппаратное обеспечение, а не на пользователей. Как только клиент создает подключение к удаленному рабочему столу на сервере терминалов, клиенту выдается клиентская лицензия службы терминалов, которая встраивается в реестр или в энергонезависимую память. При переустановке операционной системы клиент получит другую клиентскую лицензию. Если доступ к клиентской лицензии не осуществлялся в течение 120 дней, она возвращается в пул лицензий с возможностью повторного использования. Клиенты под управлением операционных систем Windows 2000 или Windows ХР не используют лицензию при подключении к серверу терминалов на основе Windows Server 2003.
Многие администраторы предпочитают использовать Citrix MetaFrame, который является многопользовательским интерфейсом поверх служб терминалов. MetaFrame поддерживает большое количество функций, которые не входят в состав Terminal Services, например подключение клиентов, работающих на альтернативных операционных системах, индивидуальная публикация приложений и более управляемые крупные (состоящие из нескольких серверов) Web-серверы. Если планируется развертывание MetaFrame поверх операционной системы Windows Server 2003, все равно нужно оплатить клиентские лицензии служб терминалов, кроме лицензий за клиентское и серверное программное обеспечение Citrix.
Отслеживание лицензий на пользователя
Служба License Manager (Диспетчер лицензий) на каждом сервере отслеживает всех пользователей, подключающихся к серверу. При этом учитываются файловые службы, службы печати, сетевая аутентификация и т.д.
Если служба License Manager сообщает, что 5000 различных клиентов подключались к компьютеру в то или иное время, придется показать аудитору 5000 клиентских лицензий на доступ. Если есть несколько пользователей, которые получают доступ к одному и тому же компьютеру (например, в лаборатории’или в киоске регистрации рабочего времени), то License Manager сообщит, что для компьютера требуется только одна клиентская лицензия на доступ.
Служба License Manager (Диспетчер лицензий) использует три файла.
Cpl.cfg. Этот файл содержит информацию об истории приобретений. Файл хранится в каталоге \Windows\System32.
Llsuser.lls. Этот файл содержит информацию о пользователях и подключениях. Файл хранится в каталоге \Windows\System32 \Lls.
Llsmap.lls. Этот файл содержит информацию License group. License group используется для идентификации пользователей, которые получают доступ к одним и тем же компьютерам и не требуют отдельных лицензий CAL. Файл хранится в каталоге \windows\ System32\Lls.
Отслеживание клиентских лицензий на доступ при лицензировании “на рабочее место” для отдельных серверов в сети может потребовать серьезных усилий. В операционной систе-
ме Windows Server 2003 можно упростить этот процесс, предоставляя возможность создания License Server (Сервер лицензий). В пределах каждого узла можно создать центральный сервер лицензий, который будет собирать информацию о лицензировании. Такой сервер, в основном, предназначен для отслеживания лицензий Terminal Server (Сервер терминалов), но может использоваться и для сбора другой лицензионной информации.
Лицензии Windows Server 2003 R2
Ключ -
Расшифровка
Дистрибутив
Количество активаций
Количество дней на активацию
Особенности
Retail
FPP
Full Packaged Product
1
30
—
MSDN
EPP
Full Packaged Product
10
60
—
Eval
Eval
Evaluation
1
14
Работает 180 дней
OEM
OEM
Original Equipment Manufacturer
2
30
Не позволяет делать обновление
Upgrade
CCP
Compliance
Checking Program
2 .
30
Устанавливается только как обновление
Volume
VL
Volume License
—
—
Не требует активации экземпляров
В условиях лицензирования пользователям предоставляется право запускать сразу до четырех экземпляров Windows Server R2 на одной хост-машине R2 Enterprise Edition. Никаких дополнительных лицензий приобретать для этого не нужно. Ознакомиться же со всем широчайшим спектром вариантов лицензирования Windows Server и ценами можно по адресу www.microsoft.com/windowsserver2003/howtobuy/licensing/default.mspx.
Присвоение имен серверам
Одним из решений, которые необходимо принять в процессе установки, является присвоение имени серверу или рабочей станции. Правила именования проистекают из старых стандартов NetBIOS, которые возникли в давние времена — в середине 1980-х годов. Именно тогда компании Microsoft и IBM в сотрудничестве с другими компаниями разрабатывали стандарты сетевого взаимодействия персональных компьютеров. В операционной системе Windows Server 2003 не используется протокол NetBIOS, но ограничения на правила назначения имен сохранились. Вот эти ограничения.
Длина имени. Имя компьютера или пользователя не может превышать 15 символов. На самом деле максимальная длина составляет 16 символов, но последний символ добавляется операционной системой и пользовательским интерфейсом этот символ не отображается. Этот символ используется для идентификации службы NetBIOS, которая использует имя. Например, служба Workstation (Рабочая станция) на компьютере RUMPLESTILTSKIN будет иметь полное имя NetBIOS RUMPLESTILTSKIN [03 ], где [ 03 ] является шестнадцатеричным идентификатором службы Workstation (Рабочая станция). Более короткие имена дополняются до 15 символов.
“Плоское" пространство имен. Имя NetBIOS должно быть уникальным в пределах сети. Два компьютера под управлением Windows в пределах одного широковещательного домена и одной подсети IP или зарегистрированные на одном сервере WINS не могут иметь одинаковые имена. Служба Active Directory также использует “плоское" пространство имен в пределах одного домена. Несмотря на то что можно создать иерархию доменов
Active Directory с различными именами доменов, все равно стоит реализовать соглашение по именованию, в соответствии с которым в пределах организации компьютеры имеют уникальные имена.
Специальные символы. Протокол NetBIOS допускает использование таких специальных символов, как пробел, символы валют, символ процента и т.д. Поскольку в операционной системе Windows Server 2003 поддерживается служба DNS, не стоит использовать специальные символы, не поддерживаемые DNS. Следует избегать использования символов подчеркивания, если необходимо добиться полной совместимости с DNS, хотя согласно последним изменениям стандарта DNS, можно использовать символ подчеркивания. Кроме этого, не стоит использовать символы подчеркивания при установке серверов SQL, так как это приводит к проблемам при обработке запросов SQL.
Изменение имени компьютера
Имя изолированного сервер» или члена домена можно изменить с помощью окна System Properties (Свойства системы). В операционной системе Windows Server 2003 имя контроллера домена можно изменить с помощью параметра renamecomputer утилиты netdom. Для этого контроллер домена должен работать под управлением операционной системы Windows Server 2003 на уровне максимальных функциональных возможностей. Дополнительная информация приводится в главе 9, “Развертывание доменов Windows Server 2003”.
Переименование сервера требует от пользователей повторного подключения сетевых дисков и повторного создания ярлыков, которые содержат имя сервера. Обычно такое переименование выливается в мучительный процесс как для пользователей, так и для администраторов. Часть проблем можно обойти, создав псевдоним в службах WINS и DNS.
Кроме этого, можно воспользоваться распределенной файловой системой (Distributed File System — DFS), которая позволяет представить ресурсы сервера как элемент виртуального дерева каталогов. Распределенная файловая система позволяет переименовывать серверы и ресурсы, не изменяя созданных пользователями смонтированных разделов. Дополнительную информацию можно получить в главе 16, “Управление совместно используемыми ресурсами”.
Управление паролями администратора
Во всех операционных системах Windows Server есть встроенная учетная запись Administrator (Администратор). Учетная запись администратора обладает полными привилегиями на конкретном компьютере. В процессе установки для учетной записи Administrator назначается пароль. Назначенный пароль 'сохраняется в локальной базе данных SAM (Security Account Manager — Диспетчер учетных записей безопасности).
Назначая пароль для учетной записи администратора, постарайтесь сделать его длинным, уникальным и сложным для взлома. Не забудьте установленный пароль. Если сервер является членом домена, без этого пароля можно будет загрузиться с помощью доменной учетной записи, но учетная запись Administrator из локальной базы данных SAM может оказаться единственным способом для локального входа в систему. Если пароль учетной записи Administrator утерян (забыт или сервер получен без пароля учетной записи), можно воспользоваться утилитой ERD Commander, доступной по адресу www. sysinternals . com, которая позволяет изменить любой пароль в локальной базе данных SAM. Существует две версии этой утилиты: условно бесплатная и платная. Только платная версия предоставляет возможность изменения паролей.
Домены и рабочие группы
Операционная система Windows Server 2003 и классическая Windows NT используют два термина, которые не связаны один с другим, но часто вызывают затруднения у администраторов: “домены” и “рабочие группы". Вот как определяются эти термины.
Домен является элементом системы безопасности. Члены домена проходят аутентификацию с помощью специальных серверов, которые называются контроллерами домена.
Рабочая группа является элементом системы распределения ресурсов. Члены рабочей группы находят друг друга с помощью специальных серверов, которые называются браузерами.
Все, кто, как и я, пережили “холодную войну”, поймут, где лежит источник этой путаницы. Помните Хрущева или Брежнева? Каждый из них имел неограниченную власть в СССР, так как каждый из них занимал два поста — Председателя Верховного Совета и Генерального секретаря Коммунистической партии. Точно так основной контроллер домена (Primary Domain Controller — PDC) делает домены и рабочие группы подобными друг другу, потому что на PDC хранятся одновременно база данных системы безопасности и база данных браузера.
Использование рабочих групп
Если устанавливается сервер, который не должен взаимодействовать с другими серверами, его можно сделать изолированным сервером — членом рабочей группы. Клиенты в той же рабочей группе в той же подсети IP используют один и тот же браузер, чтобы найти сервер. Пользователи будут проходить аутентификацию с помощью локальной базы данных SAM на сервере при каждом подключении по сети.
Даже при наличии домена иногда имеет смысл устанавливать изолированные серверы. Например, такой сервер может быть установлен в пределах демилитаризованной зоны, компьютеры в которой не должны передавать информацию о регистрации обратно через брандмауэр.
Присоединение к домену
Если надежности базы данных аутентификации на сервере недостаточно, сервер необходимо ввести в состав домена. При этом сервер становится членом домена.
Члены домена Active Directory выполняют аутентификацию пользователей с помощью протокола Kerberos. Это позволяет добиться высокого уровня безопасности и получить быстрый механизм аутентификации. Кроме этого, такой механизм аутентификации содержит информацию об авторизации, которая необходима для создания локального контекста безопасности пользователя.
Члены классического домена Windows NT осуществляют аутентификацию пользователей с помощью протокола NT LanMan Challenge-Response. При этом от сервера требуется наличие прямой линии связи с резервным контроллером домена.
В операционной системе Windows NT для добавления компьютера в домен требовалось предоставить аутентификационные данные администратора. В операционной системе Windows Server 2003 (и Windows 2000) любой аутентифицированный пользователь в состоянии добавить компьютер в домен. Возможность добавления компьютеров в домен определяется групповой политикой для организационной единицы контроллеров домена (Domain Controllers Organization Unit) в Active Directory. Изменив эту групповую политику, можно ограничить круг пользователей, которым разрешено добавлять компьютеры в домен.
Дата и время
Одним из последних этапов работы программы установки является настройка даты и времени на компьютере. Простая, на первый взгляд, операция оказывается очень важной по нескольким причинам.
Метки времени файлов
При создании, модификации и доступе к файлам файловая система меняет метку времени в записи файла. Метка времени устанавливается на основе часов сервера, а не часов клиента. Для создания метки времени используется код универсального времени. При просмотре метки вре-
мени клиентом время корректируется в соответствии с часовым поясом клиента. Если время клиента не синхронизировано со временем сервера, у пользователя возникнут трудности при сортировке похожих файлов на различных серверах при поиске файлов по дате модификации.
Ограничения на добавление компьютеров в домен аутентифицированными пользователями
В операционной системе Windows Server 2003 члены группы Authenticated Users (Аутентифицированные пользователи) имеют право присоединять компьютер к домену. Но на это право налагаются ограничения. Максимальное количество компьютеров, которые можно добавлять в домен, задается с помощью атрибута ms-DS-MachineAccountQuota объекта Active Directory Domain для пользователей, которые не являются администраторами. По умолчанию для этого атрибута установлено значение 10.
Как только пользователь, входящий в группу Authenticated Users (Аутентифицированные пользователи), но не входящий в группу Domain Admin (Администраторы домена), добавляет компьютер к домену, к объекту Computer в Active Directory добавляется новый атрибут ms- DS-CreatorSiD. Как только пользователь пытается подключить к дрмену еще один компьютер, система подсчитывает количество объектов Computer с идентификатором безопасности этого пользователя в качестве значения атрибута ms-DS-CreatorSiD. Как только это число превышает значение ms-DS-MachineAccountQuota, равное 10, пользователю выдается сообщение об отказе в доступе. Для изменения значения ms-DS-AccountQuota можно воспользоваться редактором ADSI Editor, который входит в состав Resource Kit. Кроме этого, можно удалить группу Authenticated Users (Аутентифицированные пользователи) из групповой политики Add Computer to a Domain.
Метки времени Kerberos
Операционная система Windows Server 2003 использует мандаты (tickets), выданные службой Kerberos для управления доступом к домену и к серверам, входящим в домен. В мандатах Kerberos записывается метка времени для отслеживания злоумышленников, которые могут скопировать мандат и воспользоваться им позднее, чтобы выдать себя за пользователя. Если часы на клиентском компьютере не будут синхронизированы с часами на контроллере домена, клиентские мандаты Kerberos окажутся некорректными.
Синхронизация времени
Операционная система Windows Server 2003 поддерживает синхронизацию времени между контроллерами домена или членами домена с помощью службы Windows Time Service (WTS). На самом деле служба называется W32Time.
На каждом компьютере под управлением операционной системы Windows 2000, Windows ХР и Windows Server 2003 служба W32Time устанавливается по умолчанию. После'добавления сервера или рабочей станции к домену Windows Server 2003 служба W32Time начинает работ}', чтобы компьютер мог синхронизировать время с регистрационным сервером.
Служба W32Time использует протокол Simple Network Time Protocol (SNTP). Эталоном времени для домена Windows Server 2003 является эмулятор основного контроллера домена (PDC Emulator). Обычно в роли эмулятора PDC выступает первый контроллер домена. Эталоном времени для леса доменов Windows Server 2003 является эмулятор PDC первого домена леса, который иногда называется корнем леса.
Этап конфигурирования
После завершения графического этапа установки происходит перезагрузка компьютера. Фактически это завершение процесса установки как особого режима работы сервера. Но с
практической точки зрения необходимо выполнить еще несколько операций. Пользователь должен зарегистрироваться на консоли сервера и настроить компьютер перед тем, как он будет готов к использованию в рабочих условиях.
Первая регистрация пользователя
После перезагрузки компьютера в конце графического этапа установки отображается экран приветствия, на котором пользователю предлагается нажать комбинацию клавиш <Ctrl+Alt+Del> и зарегистрироваться. Эта комбинация известна как Secure Attention Sequence (SAS). Комбинация SAS снижает вероятность использования троянских программ для подмены окна аутентификации и перехвата аутентификационных данных пользователя.
Winlogon
Процесс регистрации на консоли управляется службой, которая называется Winlogon. ехе. Служба Winlogon работает совместно с LSA (Local Security Authority — локальные средства безопасности) для аутентификации пользователя с помощью набора поставщиков аутентификации. В домене Windows Server 2003 основным поставщиком является Kerberos. Протоколы безопасности NTLM (NT LanMan Challenge-Response) и LM (LanMan Challenge- Response) также поддерживаются для обеспечения обратной совместимости с клиентами под управлением операционных систем WindowsNT и Windows'Эх и для использования на изолированных компьютерах.
Окно для ввода аутентификационной информации отображается библиотекой графической идентификации и аутентификации (Graphical Identification and Authentication library), которая хранится в файле msgina .dll. Часто эту библиотеку называют GINA. Третьи фирмы могут заменять эту библиотеку собственной версией GINA. Например, компания Novell вместо окна GINA применяет собственное окно, в котором, кроме стандартной регистрационной информации Windows, требуется вводить параметры NDS, сведения об установленных привязках и параметры сценариев.
Если компьютер был добавлен в домен в процессе установки, то в регистрационном окне присутствует раскрывающийся список с доступными именами доменов и локальным именем компьютера. Это позволяет пользователю выбирать — регистрироваться в домене или в локальной базе данных SAM.
Окончательная инвентаризация устройств РпР
Подсистема Plug and Play пользуется первым сеансом регистрации пользователя для обнаружения всех устройств, которые не были найдены по тем или иным причинам в процессе установки, и отчета о них. Если подсистема РпР не смогла обнаружить драйверы самостоятельно, драйверы запрашиваются у пользователя. В зависимости от устройства, тина используемых драйверов и необходимых ресурсов для работы этого устройства от пользователя может потребоваться перезагрузка компьютера.
Например, подсистема РпР может не обнаружить драйверы для видеоадаптера, поэтому в процессе установки часто устанавливаются драйверы стандартного адаптера VGA. При первой регистрации пользователь получает запрос на замену драйверов. Системе можно предложить найти необходимые драйверы на сайте Windows Update. Это требует коммутируемого или постоянного подключения к Интернету.
На этом обзор процесса установки завершается. Пришло время реальных действий. В следующем разделе этой главы приводятся пошаговые инструкции по установке операционной системы Windows Server 2003 на новый компьютер.
Отличия в установке на компьютер на основе архитектуры IA64
Как было сказано ранее, загрузка компьютеров на основе архитектуры IA64 выполняется с помощью меню загрузчика, сохраненного в прошивке, а не в файле boot. ini на жестком диске. Кроме этого, загрузочный диск должен содержать определенные разделы, в которых хранятся код загрузки и специальные структуры данных Microsoft.
При наличии разрешения администратора операционная система Windows Server 200,3 автоматически вносит изменения в меню загрузчика, хранящемся в прошивке, и создает необходимые разделы. Если жесткий диск уже подготовлен поставщиком для установки, стоит убедиться, что на жестком диске присутствуют следующие разделы:
EFI System Partition (ESP);
Microsoft Reserved Partition (MSR);
OEM partition (не обязательно);
■ один или несколько разделов данных (не обязательно).
Для проверки наличия разделов можно воспользоваться командным интерпретатором EFI (EFI Shell).
EFI Shell
Оболочка EFI является одним из пунктов меню загрузчика. Вот пример такого меню:
#EFI Boot Manager ver 1.02 [12.36A]
Please select a boot option:
Microsoft Windows Server 2003, Standard Edition
Acpi(PNP0A03,0)/Pci(5|0)/Mac(0003478991556)
BFI Shell [Built-in]
Boot option maintenance menu
При выборе пункта EFI Shell система запускает операционную среду с полным доступом к разделам FAT и FAT32, а также с небольшим набором команд для управления файлами и настройки системы.
При первой загрузке EFI Shell отображается список доступных разделов дисков. Еще раз вывести этот список можно с помощью команды тар из командной строки. Ниже представлен пример результата выполнения команды тар на компьютере с несколькими разделами: Device mapping table
fsO : VenHw(Unknown Device:80)/
HD(Parti,SigBDlClA20-685C-01Cl-507B-9E5P8078P531)
fsl : VenHw(Unknown Device:80)/
HD(Part5,SiglFD4472C-D516-llD5-8473-806D6172696F)
fs2 : VenHw(Unknown Device:FF)/CDROM(Entryl)
blkO : VenHw(Unknown Device:00)
blkl : VenHw(Unknown Device:80)
blk2 : VenHw(Unknown Device:80)/
HDfPart 1 ,SigBDlClA20-685C-01Cl-507B-9E5F8078F531)
blk3 : VenHw(Unknown Device:80)/
^ HD(Part2,SiglFD44720-D516-llD5-8473-806D6172696F)
blk4 : VenHw(Unknown Device:FF)
blk5 : VenHw(Unknown Device:FF)/CDROM(Entryl)
Многозначное число в каждой записи представляет собой идентификатор GUID, назначенный разделу. Каждый раздел идентифицируется порядковым номером Ык1 Разделы с читаемыми файловыми системами (FAT, FAT32 и Joliet CD-ROM) обозначены псевдонимом f s#.
Доступ к блокам разделов осуществляется после ввода имени блока и двоеточия в командной строке EFI, например ЫкЗ :. Точно так осуществляется переход между логическими дисками в приглашении командной строки операционной системы. С помощью команды di г или 1 s можно просмотреть список файлов и каталогов в каждом разделе.
С помощью команды ? можно получить сокращенный список команд, доступных для командного интерпретатора EFI. Полный список команд доступен на Web-сайте по адресу cedar, intel.com.
Обратите внимание, что для доступа в EFI не требуется знание пароля. Обеспечение физической безопасности сервера является единственным способом защиты параметров прошивки сервера на основе архитектуры IA64.
Диспетчер обслуживания для загрузчика EFI
В меню загрузчика EFI присутствует Диспетчер обслуживания (Boot Maintenance Manager), который позволяет вносить изменения в пункты меню. Использование этой утилиты для изменения записей Windows Server 2003 не обязательно. Все записи загрузчика Windows Server 2003 управляются средствами операционной системы с помощью окна System Properties (Свойства системы) или с помощью команды bootcf д.
Но иногда возникают ситуации, когда с помощью Boot Maintenance Manager требуется изменить порядок загрузки нескольких операционных систем. Ниже приведены доступные варианты использования этой утилиты:
■ Загрузка из файла. Эта функция позволяет перейти в раздел, включая привод компакт- дисков или привод гибких дисков, и запустить загрузчик. Эту функцию можно использовать для инициализации загрузчика setupldr.efi на установочном компакт-диске Windows Server 2003 для запуска консоли восстановления (Recovery Console). Дополнительная информация приводится в главе 21, “Восстановление после отказов системы".
■ Добавление/удаление записи загрузчика. Эта функция позволяет изменить меню загрузчика. Каждый пункт меню загрузчика связан с разделом и загрузчиком.
■ Управление параметром BootNext. Эта функция позволяет выбрать, какие записи могут быть загружены автоматически.
■ Установка времени до автоматической загрузки. Эта функция позволяет установить интервал задержки перед загрузкой пункта, соответствующего значению параметра BootNext. По умолчанию используется задержка в 30 секунд. Использование окна System Properties (Свойства системы) для изменения этого параметра в операционной системе Windows Server 2003 также приводит к изменению значения в энергонезависимой памяти.
■ Консольные устройства. Эта функция позволяет указать стандартные консольные устройства вывода, ввода и вывода информации об ошибках. Эти параметры можно использовать для перенаправления ввода и вывода консоли на один из последовательных портов. Это напоминает функцию Emergency Management Services (EMS) в версии для архитектуры IA32, которая позволяет определить в файле boot. ini последовательный порт, на который будет выдаваться вывод.
■ “Холодная” перезагрузка. Этот пункт позволяет перезагрузить компьютер так же, как при отключении питания.
Загрузка программы установки операционной системы Windows Server 2003 с помощью EFI
В случае установки соответствующей последовательности загрузки в параметрах BIOS компьютеры на основе архитектуры IA32 загружаются с компакт-диска в формате El Torito автоматически. Компьютеры на основе архитектуры IA64 не распознают компакт-диски в формате El Torito. Из-за этого программу установки необходимо запускать вручную с помощью командного интерпретатора EFI.
Для этого выберите EFI Shell в меню загрузчика и перейдите к псевдониму f s#, который соответствует установочному компакт-диску. Обычо это f s0, если на компьютере не установлены другие операционные системы. Запустите загрузчик программы установки, setupldr. ef i, который хранится в корневом каталоге компакт-диска. В файлах с расширением . efi содержится выполняемый код, совместимый с командным интерпретатором EFI.
При запуске программы установки операционной системы Windows Server 2003 на компьютере на основе архитектуры IA64 единственным отличием будет разбиение загрузочного диска. Если загрузочный диск уже содержит системный раздел EFI (EFI System Partition — ESP), программа установки сообщит о необходимости создания раздела Microsoft Reserved Partition (MSR) и автоматически создаст этот раздел. Если на диске отсутствуют разделы, программа установки автоматически создаст разделы ESP и MSR, выполнит форматирование и запросит у пользователя разрешения на создание разделов для файлов операционной системы.
Установка операционной системы Windows Server 2003
В этом разделе приводятся пошаговые инструкции по установке операционной системы Windows Server 2003 с установочного компакт-диска. Предполагается, что установка выполняется на чистый жесткий диск, который не содержит данных. Если выполняется модернизация существующего диска, обратитесь к главе 2, “Модернизация и автоматизированная установка”.
Текстовый этап установки
Установив компакт-диск Windows Server 2003 в привод компакт-дисков, переходите к процедуре 1.1.
Процедура 1.1. Установка операционной системы Windows Server 2003 на новый компьютер
Включите компьютер, установив загрузочный компакт-диск в привод. Желательно начинать установку с “холодной” перезагрузки, так как некоторые компьютеры не в состоянии обновить сведения об аппаратном обеспечении без отключения питания.
Нажмите клавишу после запроса. После загрузки всех драйверов и инициализации подсистемы Windows Server 2003 Executive отображается экран приветствия (рис. 1.2).
Можно выбрать один из трех вариантов. Пункт Recovery Console (Консоль восстановления) рассматривается в главе 21., “Восстановление после отказов системы”. Нажмите клавишу <Enter> для продолжения установки.
Отображается экран лицензионного соглашения операционной системы Windows Server 2003. На этом экране отображается лицензионное соглашение с конечным пользователем продукта EULA (End User License Agreement).
В случае согласия с условиями лицензионного соглашения нажмите клавишу <F8>. После этого отображается экран управления разделами (рис. 1,3). При установке операционной системы на новый сервер все диски отмечены как Unpartitioned Space.
Рис. 1.2. Текстовый этап установки. Экран приветствия
Рис. 13. Управление разделами
Если на дисках присутствуют разделы, которые необходимо удалить, выделите интересующий раздел и нажмите клавишу <D>. Программа установки выдаст два экрана подтверждения удаления раздела. Первый экран подтверждения отображается только в случае, если удаляемый раздел является системным (помечен как активный в таблице MBR). Нажмите клавишу <Enter> для удаления активного раздела. На втором экране подтверждения предлагается нажать клавишу <L>.
После удаления всех разделов выделите запись Unpartitioned Space и нажмите клавишу <С> для создания раздела. Если выбрать раздел, не отмеченный в таблице MBR как активный, программа установки предложит создать'системный раздел, с помощью которого можно выполнить загрузку. Достаточно раздела размером 1 Мбайт.
При создании раздела программа установки запрашивает размер раздела в мегабайтах. Выделите для операционной системы не менее 3 Гбайт, а по возможности 4 Гбайт.
После создания раздела программа установки возвращается на экран управления разделами. Выделите созданный раздел и нажмите клавишу <Enter> для установки в этот раздел операционной системы Windows Server 2003.
После этого программа установки предложит отформатировать раздел с помощью файловой системы NTFS или файловой системы FAT (рис. 1.4). На выбор предлагаются стандартное и быстрое форматирование. При быстром форматировании не выполняется сканирование секторов диска.
Рис. 1.4. Форматирование системного раздела
Выберите тип форматирования и щелкните на клавише <Enter>. В процессе форматирования программа установки отображает индикатор текущего состояния.
После завершения форматирования программа установки копирует файлы с установочного компакт-диска в только что созданный раздел.
Завершив копирование, программа установки перезагружает компьютер. Запись в файле boot. ini позволяет автоматически перейти к графическому этапу установки.
Графический этап установки
После перезагрузки компьютера выполняются загрузка операционной системы и переключение в графический режим. После переключения в графический режим отображается экран приветствия. Далее следуйте инструкциям, приведенным в процедуре 1.2.
Процедура 1.2. Продолжение графического этапа установки
Щелкните на кнопке Next (Далее) на экране приветствия или подождите, пока программа установки перейдет к следующему этапу автоматически. Откроется окно Installing Devices (Установка устройств) и начнется инвентаризация устройств РпР.
Этот этап требует много времени. Иногда может возникать ощущение, что компьютер “завис” на несколько минут. Если потерять терпение и перезагрузить компьютер, программа установки вернется к началу и инвентаризация устройств начнется с самого начала. Сохраняйте терпение.
Если установка устройств прошла без ошибок и “зависаний”, программа установки отображает окно Regional and Language Settings (Региональные и языковые параметры). Здесь предоставляется возможность изменения региональных параметров и параметров клавиатуры.
Региональные параметры определяют загружаемые программой установки файлы National Language Support (NLS). С помощью этих файлов определяются такие параметры, как язык вывода сообщений, внешний вид десятичной точки, название денежной единицы и т.д.
В окне Keyboard Settings (Параметры клавиатуры) можно настроить раскладки клавиатуры и специальные функции работы с клавиатурой.
Щелкните на кнопке Next (Далее). В открывшемся окне Personalize Your Software (Настройка принадлежности программ) заполните поля Name (Имя) и Organization (Организация). Эти записи служат только для информационных целей. Имя не используется для создания учетных записей, а название компании не учитывается при лицензировании. Программа установки просто записывает данные в системный реестр. При этом нельзя ввести слова Admini st га t or и Gues t.
Совет no использованию системного реестра: изменение имени зарегистрированного владельца
Стоит отказаться от использования реального имени в окне Personalize Your Software. Это позволит избежать проблем, когда имя бывшего администратора появляется при установке приложений через много лет после его увольнения. Информацию о зарегистрированном владельце можно изменить в системном реестре в следующей записи:
Раздел:HKLM\Software\Microsoft\Windows NT\CurrentVersion
Запись: RegisteredOwner
Щелкните на кнопке Next (Далее). Откроется окно Product Key (Ключ продукта). Введите ключ продукта, состоящий из 25 символов. Ключ можно найти на коробке компакт-диска или на другой упаковке программного обеспечения. Если используется главная лицензия или соглашение о массовой закупке, введите ключ для этого конкретного соглашения.
Щелкните на кнопке Next (Далее). Откроется окно Licensing Modes (Режимы лицензирования), как показано на рис. 1.5. Дополнительная информация о выборе режима лицензирования была представлена ранее в этой главе.
Щелкните на кнопке Next (Далее). Откроется окно Computer Name and Administrator Password (Имя компьютера и пароль администратора). Советы по выбору имени сервера и пароля администратора приводятся выше в этой главе, в разделе “Управление паролями администратора”.
Щелкните на кнопке Next (Далее). Если на сервере установлен модем, откроется окно Modem Dialing Information (Сведения о модеме). Введите код области и префикс выхода на внешнюю линию, например 9 или 19. Эта информация используется для создания записей в разделе системного реестра HKLM\System\Software\Microsof t\Windows\ CurrentVersion\Telephony.
Щелкните на кнопке Next (Далее). Откроется окно Date and Time Settings (Настройка времени и даты). В этом окне можно установить дату, время и часовой пояс. Дополнительная информация по этой теме приводится в разделе “Дата и время” выше в этой главе.
Щелкните на кнопке Next (Далее). На этом этапе программа установки выполняет дополнительные проверки, чтобы определить состояние сети и способ настройки аппаратного обеспечения. Стек TCP/IP загружается всегда. Если программа установки обнаружит широковещательные пакеты SAP, которые сопровождают трафик IPX/SPX, то будут загружены и драйверы транспортного протокола NWLINK.
Обратите внимание, что при наличии устаревших сетевых адаптеров, которые не были корректно настроены на этапе установки устройств, в этот момент компьютер может “зависнуть”. Несмотря на это, выделите программе установки достаточно времени для завершения настройки сетевой подсистемы.
5 WindowsWindow* Se tup5 WindowsWindow* Se tupLicensing ModesWindows Server 2003 supports two licensing modesLicensing ModesWindows Server 2003 supports two licensing modes^ Ргаб-згд. .Д-ТЙ^ЙП^ Ргаб-згд. .Д-ТЙ^ЙП...JoKWdttonО DytUOMC. Update...JoKWdttonО DytUOMC. UpdateQ Preparmy . .m&faHaltonQ Preparmy . .m&faHaltonirtup will «лмрМс; : 33 «^^irtup will «лмрМс; : 33 «^^flurdwtdflurdwtd
5 Windows
Window* Se tup
5 Windows
Window* Se tup
Licensing Modes
Windows Server 2003 supports two licensing modes
Licensing Modes
Windows Server 2003 supports two licensing modes
^ Ргаб-згд
. .Д-ТЙ^ЙП
^ Ргаб-згд
. .Д-ТЙ^ЙП
...JoKWdtton
О DytUOMC. Update
...JoKWdtton
О DytUOMC. Update
Q Preparmy . .m&faHalton
Q Preparmy . .m&faHalton
irtup will «лмрМс
; : 33 «^^
irtup will «лмрМс
; : 33 «^^
flurdwtd
flurdwtd
Puc. 15. Программа установки операционной системы Windows Server 2003. Окно Licensing Modes (Режимы лицензирования)
После загрузки драйверов сетевых адаптеров открывается окно Networking Settings (Сетевые параметры). На выбор предоставляется два варианта: Typical settings (Обычные настройки) л Custom settings (Дополнительные настройки), как показано на рис. 1.6.
Рис. 1.6. Окно Networking SettingsРис. 1.6. Окно Networking Settings
Рис. 1.6. Окно Networking Settings
Рис. 1.6. Окно Networking Settings
Вариант Typical settings указывает программе установки настроить получение IP-адреса и других параметров у сервера DHCP. Если сервер DHCP оказывается недоступным, драйвер TCP/IP выберет случайный адрес из диапазона 169.254.0.0. Эта возможность называется APIPA (Automatic Private IP Addressing — автоматическая адресация частных IP-адресов).
Выберите параметр Custom settings (Дополнительные настройки) и щелкните на кнопке Next (Далее). Откроется окно Networking Components (Сетевые компоненты), показанное на рис. 1.7. Это окно можно использовать для точной настройки сетевых служб и протоколов.
■ Windows
ООСаЙег.Ьнд informationСаЙег.Ьнд information(windows Setup(windows SetupооDynamic UpdateDynamic UpdateооPreparing in^aftationPreparing in^aftationBiSetup will completeBiSetup will completeарртохн*г*е^¥-30 e6nut*$арртохн*г*е^¥-30 e6nut*$^Network Load Balancing^Network Load Balancingv ^Рйе and Printer Sharing for Microsoft Networksv ^Рйе and Printer Sharing for Microsoft NetworksУ Internet Protocol (TCP/IP)У Internet Protocol (TCP/IP)inst^attoinst^attoNetworking CowponenteClick on the checkbox to enable a networking component lot this device T о add a component, click Instal.Networking CowponenteClick on the checkbox to enable a networking component lot this device T о add a component, click Instal.F* deer ЛИ? ИЖТ П** Ft! ENnmmI A»#* ”4"v' 1Ыи#1^*^шмсшF* deer ЛИ? ИЖТ П** Ft! ENnmmI A»#* ”4"v' 1Ыи#1^*^шмсшРис. 1.7. Окно Networking ComponentsРис. 1.7. Окно Networking Components
О
О
СаЙег.Ьнд information
СаЙег.Ьнд information
(windows Setup
(windows Setup
о
о
Dynamic Update
Dynamic Update
о
о
Preparing in^aftation
Preparing in^aftation
Bi
Setup will complete
Bi
Setup will complete
арртохн*г*е^¥-
30 e6nut*$
арртохн*г*е^¥-
30 e6nut*$
^Network Load Balancing
^Network Load Balancing
v ^Рйе and Printer Sharing for Microsoft Networks
v ^Рйе and Printer Sharing for Microsoft Networks
У Internet Protocol (TCP/IP)
У Internet Protocol (TCP/IP)
inst^atto
inst^atto
Networking Cowponente
Click on the checkbox to enable a networking component lot this device T о add a component, click Instal.
Networking Cowponente
Click on the checkbox to enable a networking component lot this device T о add a component, click Instal.
F* deer ЛИ? ИЖТ П** Ft! ENnmmI A»#
* ”4"v' 1Ыи#1^*^шмсш
F* deer ЛИ? ИЖТ П** Ft! ENnmmI A»#
* ”4"v' 1Ыи#1^*^шмсш
Рис. 1.7. Окно Networking Components
Рис. 1.7. Окно Networking Components
Щелкните два раза мышью на пункте Internet Protocol (TCP/IP), и откроется окно Properties (Свойства). Воспользуйтесь этим окном для ввода IP-адреса, принятого по умолчанию адреса шлюза, адреса DNS-сервера, а также дополнительных параметров службы WINS и таких настроек безопасности, как фильтрация TCP/IP и IPSec.
После завершения настройки сетевой подсистемы щелкните на кнопке ОК чтобы закрыть окно и вернуться в окно Networking Settings (Сетевые параметры).
Щелкните на кнопке Next (Далее). Откроется окно (рис. 1.8) Workgroup or Computer Domain (Рабочая группа или компьютер в составе домена). Если компьютер предназначен для включения в состав рабочей группы, оставьте выбранный ио умолчанию параметр и введите имя рабочей группы.
Если компьютер должен быть добавлен в состав домена, выберите пункт Yes. Make This Computer A Member Of The Following Domain (Да, сделать этот компьютер членом следующего домена) и введите имя домена. Если после этого появится сообщение об ошибке Unable to Locate Domain Control! er, проблема, скорее всего, заключается в работе служб WINS и DNS.
Щелкните на кнопке Next (Далее). После этого программа установки начнет копирование файлов с установочного компакт-диска.
■ Windows■ WindowsООооооDynamic UpdateDynamic UpdateWockspoup <w Computer DomainA workgroup is a coleciion of computers that have the same workgroup name. A domain is a colection of computers defined by a network administrator.Wockspoup <w Computer DomainA workgroup is a coleciion of computers that have the same workgroup name. A domain is a colection of computers defined by a network administrator.Collecting informationCollecting informationPreparing iiKtallatronPreparing iiKtallatron-nv atewri-nv atewriSetup will complete1 approximately:
■ Windows
■ Windows
О
О
о
о
о
о
Dynamic Update
Dynamic Update
Wockspoup <w Computer Domain
A workgroup is a coleciion of computers that have the same workgroup name. A domain is a colection of computers defined by a network administrator.
Wockspoup <w Computer Domain
A workgroup is a coleciion of computers that have the same workgroup name. A domain is a colection of computers defined by a network administrator.
Collecting information
Collecting information
Preparing iiKtallatron
Preparing iiKtallatron
-nv atewri
-nv atewri
30 minutes
•^WORKGROUP•^WORKGROUPPuc. 1.8. Окно Workgroup or Computer Domain
•^WORKGROUP
•^WORKGROUP
После завершения копирования откроется окно Performing Final Tasks (Окончательная настройка системы), и программа установки начнет настройку установленных служб и компонентов.
После завершения окончательной настройки программа установки выводит окно Completing the Windows Server 2003 Setup Wizard (Завершение работы мастера установки Windows Server 2003). Если пользователь не предпринимает никаких действий, компьютер автоматически перезагружается.
Заключительная настройка системы
После перезагрузки система отображает окно регистрации, доступное после нажатия комбинации клавиш <Ctrl+Alt+Del>. Зарегистрируйтесь в системе и завершите настройку компьютера.
При регистрации в домене Windows Server 2003 или Windows 2000 аутентификация выполняется средствами службы Kerberos. Дополнительная информация о транзакциях Kerberos приводится в главе И, “Безопасность доступа по сети и протокол Kerberos". Служба userinit. ехе настраивает рабочую среду пользователя, создает пользовательский профиль и запускает Explorer (Проводник) в контексте зарегистрированного пользователя.
При регистрации на новом сервере отображается окно Configure Your Server (Настройка сервера). Это окно предоставляется мастером настройки сервера (Server Configuration Wizard), код которого хранится в файле srvwiz .dll. Этот мастер является компонентом mshta.exe, утилиты восстановления Internet Explorer. Параметры работы мастера настройки сервера устанавливаются в разделе системного реестра HKCU\Software\Microsoft\ Windows NT\CurrentVersion\Setup\Welcome\Srvwiz.
Мастер настройки сервера последовательно отображает несколько Java-окон, которые используются для выбора интересующих возможностей сервера с последующей автоматической установкой выбранных возможностей. На рис. 1.9 показан пример работы мастера. Результаты работы мастера заносятся в файл журнала \Windows\суs. log.
Server RoteYou can set up this server to perform one or more specfic roles. If you want to add more than one role to this server, you can run ths wizard again.Server RoteYou can set up this server to perform one or more specfic roles. If you want to add more than one role to this server, you can run ths wizard again.
Server Rote
You can set up this server to perform one or more specfic roles. If you want to add more than one role to this server, you can run ths wizard again.
Server Rote
You can set up this server to perform one or more specfic roles. If you want to add more than one role to this server, you can run ths wizard again.
Select a role. If the role has not been added, you can add t. If It has akeady been added, you can remove It. If the role you want to add or remove 1$ not Isted, open Add or Remove Prooryns,
— - л s я - - — — —“— - s - - - - " iFte server No i
Pmc server No Web applcetion server (IIS, ASP.NET) No Mai server (POP3, SMTP) No Terminal server No Remote access / VPN server No Domain Controter (Active Directory) No DNS server No DHCP server No Streaming meda server No WINS server No
Рис. 1.9. Мастер настройки сервера предоставляет список доступных параметров настройки сервераРис. 1.9. Мастер настройки сервера предоставляет список доступных параметров настройки сервера
Рис. 1.9. Мастер настройки сервера предоставляет список доступных параметров настройки сервера
Рис. 1.9. Мастер настройки сервера предоставляет список доступных параметров настройки сервера
Теперь можно завершить работу мастера и установить флажок, блокирующий последующий автоматический запуск мастера. Это пригодится, если администратор предпочитает настраивать сервер вручную. Если в дальнейшем возникнет желание воспользоваться мастером настройки сервера, его можно запустить, открыв Control Panel (Панель управления) с помощью аплета Configure Your Server (Мастер настройки сервера).
Отличия при настройке Web-сервера
Поскольку Web-сервер является платформой для запуска IIS, для настройки он предоставляет последовательность Web-окон.
При первой регистрации после завершения установки система предлагает пройти аутентификацию для работы с Web-службами. Если для учетной записи администратора установлен пустой пароль, такая регистрация оказывается невозможной, так как Web- службы в Windows Server 2003 требуют ввода какого-либо пароля. На рис. 1.10 показана страница приветствия.
В этом окне предоставляется две панели навигации. Верхняя панель позволяет получать доступ к основным разделам администрирования, например Status, Network, Disk, Users и т.д. Каждый раздел содержит вторичную навигационную полосу, которая предоставляет доступ к информационным и конфигурационным страницам. На рис. 1.11 показан пример страницы Interfaces в разделе Network.
Любая задача администрирования, реализованная с помощью этих страниц, может быть выполнена с помощью стандартного интерфейса ММС в операционной системе Windows Server 2003. Сами страницы являются частью Web-сайта Administration, установленного на порту 8098. По умолчанию доступ к этому порту осуществляется посредством Secure Sockets Layer (SSL). Порт 8099, для которого не используется шифрование, существует только для перенаправления на порт SSL или для выдачи сообщения об ошибке, если порт SSL не используется.
3Server Administration Micnwft Internal (иркл-ег
s» <#;Ш5иШяОяОВЯ1в111В®11^♦ ь
^<^N6ttigi8g,y$yeggR^^ligg8g;^
,^»oti|^)hltpi:yA3:e09e/admln/tasks.a5P?labl-TabsWeko<re6^5APaoeK4y-F2670AEAAt)EK4e8XEC4BOMS97eAK:1^^3^11®^'
a* » Windows ■
Take a Tour < Set Server Name ? Set Administrator Password 1 Set Default Page ! Microsoft Communities |
Welcome
weirone t.- the ^'eb i's*- ftVe<f»ce for Microsoft V/inho.v; Sen-et adtnruy-arjon, Ute the ro/bwing ’Laths to Sart '.’ting №» terver.
Щ Set Server Name
Choose i плте so that client i.ompute's can connect to the serve,
Q Set Default Page
*” Choc*:» which page the server dismays
Д * 4 total nbsnet
Puc. 1.10. Страница приветствия Web-сервера
' Ad*a6sSjhltps://s3:e09e/«*iih/netv«xk/mcinlerfaceJxop.a5P?Tabl-Tab4NetwrkaTab2-TabsHetworUnterlaces№eturTiURL-t5«%2Easp4V);^;g|4v: 11Г*Г ^
S3#
лWindows
Wetorhe ' Stilus . ^^ ’ l*-frh Vrw ЯМЯИД pr-t:- i.^^; ■ i^siMwaww m&v:?
। Identification 1 Global Settings ! interfaces Administrator I Administration Web Site I Telna^ | j InteAcee
Description
■ ; Local J...J Connectio.
Type
3Com30920 Integrate
JP Confluurstion Status !A Tadca
192 168.0 3 StaticConnected Rename
IP
DNS
WINS
Puc. 1.11. Пример конфигурационной страницы Web-сервера
Настройка после установки
Если нет никаких признаков некорректной работы и система функционирует нормально, настройку можно считать завершенной и администратор может позволить себе неделю отдыха. Если процесс установки не завершился или завершился с заметными ошибками, обратитесь к разделу “Устранение проблем во время установки операционной системы” в этой главе.
Каждый администратор может выполнить несколько процедур для окончательной настройки системы после процесса установки. Далее описаны дополнительные действия, которые стоит выполнить.
Активация продукта
Лицензионное соглашение, предоставляемое вместе с любым продуктом из линейки Microsoft Windows, ясно и четко указывает, что операционная система является такой же неотъемлемой частью компьютера, как и чипсет или BIOS. Именно поэтому большинство продаваемых в розницу версий операционной системы Windows называются “модернизациями”, и предполагается, что предыдущая версия операционной системы Windows получена вместе с аппаратным обеспечением сервера (конечно, это не всегда так, потому что существует возможность приобрести сервер без операционной системы или с альтернативной операционной системой, например, Linux или NetWare).
При установке продаваемой в розницу версии операционной системы Windows Server 2003 администратору предоставляется 30 дней на активацию продукта. Для этого можно воспользоваться мастером активации продуктов Windows (Windows Product Activation — WPA). Выполняемый файл этого мастера называется msoobe. ехе, что расшифровывается как MS Out-Of-Box Experience. В составе WPA можно выделить три основных компонента.
Ключ продукта, состоящий из 25 символов и предоставляемый на коробке компакт-диска или на другой упаковке для системы Windows.
Идентификатор инсталляции (Installation ID), который генерируется исходя из аппаратного обеспечения сервера, используемого на момент активации. Если вас интересует, какие аппаратные компоненты используются для генерации идентификатора инсталляции, обратитесь на сайт немецкой фирмы Fully Licensed по адресу www.licenturion.com/ хр/ f ully-licensed-wpa. txt, где приводятся результаты анализа работы мастера WPA.
Идентификатор подтверждения (Confirmation ID), который генерируется компанией Microsoft и предоставляется по Интернет, с помощью модема или телефона. Этот номер используется для активации конкретной копии операционной системы Windows Server 2003.
Если сервер не имеет непосредственного подключения к Интернет, но на сервере установлен модем, можно установить коммутируемое подключение к одному из центров активации продуктов Microsoft (Microsoft Product Activation Centers), воспользовавшись телефонным номером, предоставленным мастером WPA. Если модем на сервере не установлен, можно непосредственно позвонить в Product Activation Center и запросить идентификатор подтверждения. Центры поддержки существуют в каждой стране. Каждый центр доступен круглые сутки семь дней в неделю. Оператор не получает пользовательскую информацию. Оператор может попросить назвать имя, но только из соображений вежливости. Компания Microsoft настаивает на отсутствии записей о личности пользователя.
Если принято решение об активации по телефону, мастер WPA отображает окно с идентификатором инсталляции (Installation ID), который можно сообщить представителю компании Microsoft. Пример такого окна показан на рис. 1.12.
Если переустановить операционную систему Windows Server 2003, воспользовавшись тем же ключом продукта, на тот же компьютер с тем же аппаратным обеспечением, существующую активацию придется только подтвердить по Интернет с помощью телефона или модема. Количество подтверждений не ограничено.
Если заменить заметную часть аппаратного обеспечения, операционная система потребует повторной активации. Какие именно изменения в аппаратном обеспечении потребуют повторной активации Windows, является закрытой информацией, которую компания Microsoft публиковать не собирается. Розничные версии операционной системы Windows ХР допускают
изменения в удивительно больших пределах. Если компьютер использует ту же BIOS, повторный процесс активации не потребуется.
-|.~| Х1-|.~| Х1Activate Windows by phoneActivate Windows by phone»S»SJust W steps, dftdyou'rextotte..Just W steps, dftdyou'rextotte..Stepl:Stepl:Step 2:Step 2:wstomAt seivK* ropje.5,45^wstomAt seivK* ropje.5,45^1 Step 3:1 Step 3:pf ^ »^e<ts^^upf ^ »^e<ts^^uStop 4:Stop 4::г<е th-? fu-3i'?'W;;ervKv renresen’atrye yvi!hi)'PiGl!l£№fn^tr-&alfat^003415 -721705-976691-9Ш8б-171932-595894^50Э30.6^:-4l lick Change product key univifrenvestHp^. do ro riftf^ си-Мшпе» s^htte e.:г<е th-? fu-3i'?'W;;ervKv renresen’atrye yvi!hi)'PiGl!l£№fn^tr-&alfat^003415 -721705-976691-9Ш8б-171932-595894^50Э30.6^:-4l lick Change product key univifrenvestHp^. do ro riftf^ си-Мшпе» s^htte e.Puc. 1.12. Окно активации операционной системы Windows. Активация по телефонуPuc. 1.12. Окно активации операционной системы Windows. Активация по телефонуМастер WPA относится только к розничным версиям продукта. Ключ продукта, который предоставляется вместе с главным лицензионным соглашением (Master License Agreement — MLA) или массовым лицензионным соглашением (Volume Purchase Agreement — VPA), не поддерживает активацию каждого экземпляра. На данный момент требуется приобретение достаточно небольшого количества лицензий для заключения VPA. Текущие требования можно узнать у локального посредника.Мастер WPA относится только к розничным версиям продукта. Ключ продукта, который предоставляется вместе с главным лицензионным соглашением (Master License Agreement — MLA) или массовым лицензионным соглашением (Volume Purchase Agreement — VPA), не поддерживает активацию каждого экземпляра. На данный момент требуется приобретение достаточно небольшого количества лицензий для заключения VPA. Текущие требования можно узнать у локального посредника.Проверка журнала событийСтоит проверить содержимое журнала событий и убедиться в отсутствии ошибок в процессе установки и первой загрузки. Журналы событий хранятся в каталоге \windows\ System32\Config вместе с разделами (hive) системного реестра. Содержимое журналов событий можно просматривать с помощью оснастки Event Viewer (Просмотр событий), eventvwr. msc, или с помощью утилиты Event Viewer (Просмотр событий), eventvwr. ехе.Активация и регистрацияПроцесс активации под названием Windows Product Activation совершенно не относится к регистрации продукта. Регистрация позволяет компании Microsoft узнать информацию о пользователе, что позволяет пользователю получать техническую поддержку, информацию о модернизации продуктов и большой объем электронной почты с информацией о продуктах третьих фирм.При активации не передается никакой информации, которая связывает определенного пользователя или организацию с определенной лицензией на операционную систему Windows Server 2003. С другой стороны, при регистрации передается бойьшой объем информации о пользователе и организации. Для активации регистрация не требуется.Проверка журнала событийСтоит проверить содержимое журнала событий и убедиться в отсутствии ошибок в процессе установки и первой загрузки. Журналы событий хранятся в каталоге \windows\ System32\Config вместе с разделами (hive) системного реестра. Содержимое журналов событий можно просматривать с помощью оснастки Event Viewer (Просмотр событий), eventvwr. msc, или с помощью утилиты Event Viewer (Просмотр событий), eventvwr. ехе.Активация и регистрацияПроцесс активации под названием Windows Product Activation совершенно не относится к регистрации продукта. Регистрация позволяет компании Microsoft узнать информацию о пользователе, что позволяет пользователю получать техническую поддержку, информацию о модернизации продуктов и большой объем электронной почты с информацией о продуктах третьих фирм.При активации не передается никакой информации, которая связывает определенного пользователя или организацию с определенной лицензией на операционную систему Windows Server 2003. С другой стороны, при регистрации передается бойьшой объем информации о пользователе и организации. Для активации регистрация не требуется.
-|.~| Х1
-|.~| Х1
Activate Windows by phone
Activate Windows by phone
»
S
»
S
Just W steps, dftdyou'rextotte..
Just W steps, dftdyou'rextotte..
Stepl:
Stepl:
Step 2:
Step 2:
wstomAt seivK* ropje.5,45^
wstomAt seivK* ropje.5,45^
1 Step 3:
1 Step 3:
pf ^ »^e<ts^^u
pf ^ »^e<ts^^u
Stop 4:
Stop 4:
:г<е th-? fu-3i'?'W;;ervKv renresen’atrye yvi!hi)'PiGl!l£№fn^tr-&alfat^
003415 -721705-976691-9Ш8б-171932-595894^50Э30.6^:-
4l lick Change product key univifrenvestHp^. do ro riftf^ си-Мшпе» s^htte e.
:г<е th-? fu-3i'?'W;;ervKv renresen’atrye yvi!hi)'PiGl!l£№fn^tr-&alfat^
003415 -721705-976691-9Ш8б-171932-595894^50Э30.6^:-
4l lick Change product key univifrenvestHp^. do ro riftf^ си-Мшпе» s^htte e.
Puc. 1.12. Окно активации операционной системы Windows. Активация по телефону
Puc. 1.12. Окно активации операционной системы Windows. Активация по телефону
Мастер WPA относится только к розничным версиям продукта. Ключ продукта, который предоставляется вместе с главным лицензионным соглашением (Master License Agreement — MLA) или массовым лицензионным соглашением (Volume Purchase Agreement — VPA), не поддерживает активацию каждого экземпляра. На данный момент требуется приобретение достаточно небольшого количества лицензий для заключения VPA. Текущие требования можно узнать у локального посредника.
Мастер WPA относится только к розничным версиям продукта. Ключ продукта, который предоставляется вместе с главным лицензионным соглашением (Master License Agreement — MLA) или массовым лицензионным соглашением (Volume Purchase Agreement — VPA), не поддерживает активацию каждого экземпляра. На данный момент требуется приобретение достаточно небольшого количества лицензий для заключения VPA. Текущие требования можно узнать у локального посредника.
Проверка журнала событий
Стоит проверить содержимое журнала событий и убедиться в отсутствии ошибок в процессе установки и первой загрузки. Журналы событий хранятся в каталоге \windows\ System32\Config вместе с разделами (hive) системного реестра. Содержимое журналов событий можно просматривать с помощью оснастки Event Viewer (Просмотр событий), eventvwr. msc, или с помощью утилиты Event Viewer (Просмотр событий), eventvwr. ехе.
Активация и регистрация
Процесс активации под названием Windows Product Activation совершенно не относится к регистрации продукта. Регистрация позволяет компании Microsoft узнать информацию о пользователе, что позволяет пользователю получать техническую поддержку, информацию о модернизации продуктов и большой объем электронной почты с информацией о продуктах третьих фирм.
При активации не передается никакой информации, которая связывает определенного пользователя или организацию с определенной лицензией на операционную систему Windows Server 2003. С другой стороны, при регистрации передается бойьшой объем информации о пользователе и организации. Для активации регистрация не требуется.
Проверка журнала событий
Стоит проверить содержимое журнала событий и убедиться в отсутствии ошибок в процессе установки и первой загрузки. Журналы событий хранятся в каталоге \windows\ System32\Config вместе с разделами (hive) системного реестра. Содержимое журналов событий можно просматривать с помощью оснастки Event Viewer (Просмотр событий), eventvwr. msc, или с помощью утилиты Event Viewer (Просмотр событий), eventvwr. ехе.
Активация и регистрация
Процесс активации под названием Windows Product Activation совершенно не относится к регистрации продукта. Регистрация позволяет компании Microsoft узнать информацию о пользователе, что позволяет пользователю получать техническую поддержку, информацию о модернизации продуктов и большой объем электронной почты с информацией о продуктах третьих фирм.
При активации не передается никакой информации, которая связывает определенного пользователя или организацию с определенной лицензией на операционную систему Windows Server 2003. С другой стороны, при регистрации передается бойьшой объем информации о пользователе и организации. Для активации регистрация не требуется.
Для доступа к оснастке Event Viewer (Просмотр событий) из меню Start (Пуск) выберите Starts Programs^ Administrative Tools^Event Viewer (Пуск^Программые>Администрирова- ние^Просмотр событий). На рис. 1.13 показан пример использования оснастки Event Viewer (Просмотр событий) для просмотра системного журнала. Администратора операционной системы Windows NT 4.0 приятно удивит то, что стрелки навигации теперь указывают, в какую сторону будет перемещаться курсор.
e= * Г©:®"# ф ®Г(|"Л ■e= * Г©:®"# ф ®Г(|"Л ■Ы Evert Viewer (Loco.)HI AppkationЫ Evert Viewer (Loco.)HI Appkation,ioi xi,ioi xiDirectory ServiceHj DNS Server 1^1 Hie Repkation ServiceDirectory ServiceHj DNS Server 1^1 Hie Repkation ServiceJ№ Ф Information ^Information Q ErrorS WarningInformation ф Information ^Warning ф Error ^Information Ф Information ^Information e WarningInformation ^Information ^InformationJ№ Ф Information ^Information Q ErrorS WarningInformation ф Information ^Warning ф Error ^Information Ф Information ^Information e WarningInformation ^Information ^Information.Jwfct...—2/21/20022/21/20022/21/20022/21/20022/21/20022/21/20022/21/20022/21/20022/21/20022/21/20022/21/20022/21/20022/21/20022/21/20022/21/2002.Jwfct...—2/21/20022/21/20022/21/20022/21/20022/21/20022/21/20022/21/20022/21/20022/21/20022/21/20022/21/20022/21/20022/21/20022/21/20022/21/2002I »y ...... Jiara.— ... —11:19:10... Service Control Manager11:19:10... Service Control ManagerI »y ...... Jiara.— ... —11:19:10... Service Control Manager11:19:10... Service Control Manager11:12:21 ...11:12:21 ...11:12:13...11:11:51 ...11:11:43...11:11:42...11:11:40...11:11:04 ...11:09:08...11:09:02...11:12:21 ...11:12:21 ...11:12:13...11:11:51 ...11:11:43...11:11:42...11:11:40...11:11:04 ...11:09:08...11:09:02...W32Trne W32TTne DHCPServer WINS DHCPServer DHCPServer 5MTP5VC BrowserdtekW32Trne W32TTne DHCPServer WINS DHCPServer DHCPServer 5MTP5VC Browserdtek11:09:34... eventlog11:09:34... eventlog11:08:11 ... eventlog11:09:34... eventlog11:09:34... eventlog11:08:11 ... eventlog(Dlrftwmattan 2/21/2002(Dlrftwmattan 2/21/200211:07:56 ...11:07:56 ...I Category I Evant I L *1I Category I Evant I L *1NoneNoneNoneNone NoneNoneNoneNoneNoneNoneNone NoneNoneNone70357035281210444097105610144005801510703570352812104440971056101440058015105 S5 SККJJ6005 К6009^6006^tew s60052 fe6005 К6009^6006^tew s60052 fe
e= * Г©:®"# ф ®Г(|"Л ■
e= * Г©:®"# ф ®Г(|"Л ■
Ы Evert Viewer (Loco.)
HI Appkation
Ы Evert Viewer (Loco.)
HI Appkation
,ioi xi
,ioi xi
Directory Service
Hj DNS Server 1^1 Hie Repkation Service
Directory Service
Hj DNS Server 1^1 Hie Repkation Service
J№ Ф Information ^Information Q Error
S Warning
Information ф Information ^Warning ф Error ^Information Ф Information ^Information e Warning
Information ^Information ^Information
J№ Ф Information ^Information Q Error
S Warning
Information ф Information ^Warning ф Error ^Information Ф Information ^Information e Warning
Information ^Information ^Information
.Jwfct...—
2/21/2002
2/21/2002
2/21/2002
2/21/2002
2/21/2002
2/21/2002
2/21/2002
2/21/2002
2/21/2002
2/21/2002
2/21/2002
2/21/2002
2/21/2002
2/21/2002
2/21/2002
.Jwfct...—
2/21/2002
2/21/2002
2/21/2002
2/21/2002
2/21/2002
2/21/2002
2/21/2002
2/21/2002
2/21/2002
2/21/2002
2/21/2002
2/21/2002
2/21/2002
2/21/2002
2/21/2002
I »y ...... Jiara.— ... —11:19:10... Service Control Manager11:19:10... Service Control Manager
I »y ...... Jiara.— ... —11:19:10... Service Control Manager11:19:10... Service Control Manager
11:12:21 ...
11:12:21 ...
11:12:13...
11:11:51 ...
11:11:43...
11:11:42...
11:11:40...
11:11:04 ...
11:09:08...
11:09:02...
11:12:21 ...
11:12:21 ...
11:12:13...
11:11:51 ...
11:11:43...
11:11:42...
11:11:40...
11:11:04 ...
11:09:08...
11:09:02...
W32Trne W32TTne DHCPServer WINS DHCPServer DHCPServer 5MTP5VC Browser
dtek
W32Trne W32TTne DHCPServer WINS DHCPServer DHCPServer 5MTP5VC Browser
dtek
11:09:34... eventlog
11:09:34... eventlog
11:08:11 ... eventlog
11:09:34... eventlog
11:09:34... eventlog
11:08:11 ... eventlog
(Dlrftwmattan 2/21/2002
(Dlrftwmattan 2/21/2002
11:07:56 ...
11:07:56 ...
I Category I Evant I L *1
I Category I Evant I L *1
None
None
None
None None
None
None
None
None
None
None None
None
None
7035
7035
28
12
1044
4097
1056
1014
4005
8015
10
7035
7035
28
12
1044
4097
1056
1014
4005
8015
10
5 S
5 S
К
К
J
J
6005 К
6009^
6006^
tew s
60052 fe
6005 К
6009^
6006^
tew s
60052 fe
Puc. 1.13. Использование оснастки Event Viewer (Просмотр событий) для просмотра записей журнала System (Системные события) после установки операционной системы Windows Server2003
Существует несколько журналов событий.
Журнал приложений (Application). В этом журнале регистрируются события пользовательских процессов.
Системный журнал (System). В этом журнале регистрируются события драйверов и процессов Executive
Журнал безопасности (Security). Используется только при включенном Auditing (Аудит).
Журнал службы каталогов (Directory Services). Применяется только на контроллерах доменов.
Журнал службы репликации файлов (File Replication Service). Применяется только на контроллерах доменов.
DNS. Устанавливается только на серверах DNS.
Стоит ознакомиться с записями журналов событий, характерными для нормальной работы системы. Одни ошибки возникают всегда, даже при нормальной работе системы. Другие должны обратить на себя внимание администратора. Каждая запись в журнале событий содержит описание события, которое может содержать подсказку для устранения неисправности. На рис. 1.14 показано, как сообщение об ошибке сохраняется в журнале событий.
Рис. 1.14. Пример записи об ошибке в журнале событий
Перемещение и настройка файла подкачки страниц
Файл подкачки страниц содержит страницы памяти, которые были вытеснены из оперативной памяти. Эти страницы сохраняются в системном файле, который называется pagefile.sys. Файл хранится в корневом каталоге системного раздела. По умолчанию минимальный размер файла подкачки устанавливается равным 150 % от объема оперативной памяти. Максимальный размер файла подкачки равен 300 % от объема оперативной памяти.
Для небольших систем с объемом оперативной памяти до 256 Мбайт файл подкачки можно оставить в системном разделе. Но для больших систем с несколькими гигабайтами оперативной памяти стоит принять меры по изменению размера и расположения файла подкачки страниц.
Перемещение файла подкачки на другой диск
Общая прюизводительность системы может возрасти, если файл подкачки страниц разместить на “быстром” диске, который не связан с диском операционной системы. Система может использовать до 16 файлов подкачки, расположенных на различных логических дисках. Рост прюизводительности будет не заметен, если файлы подкачки не разместить на различных физических дисках.
Стоит оставить небольшой файл подкачки на загрузочном диске. Это связано с тем, что файл подкачки используется системой для хранения дампа памяти, создаваемого после критической ошибки на урювне ядра (пресловутого “синего экрана смерти"). Сначала дамп памяти создается в файле подкачки, после чего при следующей перезагрузке копируется в специальный файл. Именно поэтому файл подкачки должен находиться в корневом каталоге системного раздела. Выполняемый файл, который осуществляет копирование, не имеет доступа к файловой системе и должен использовать непосредственные вызовы INT13, которые предоставляют доступ только к корневому каталогу загрузочного диска.
Необходимость создания дампа памяти может заставить администратора выделить очень большой участок дискового пространства (в случае, если на сервере установлен большой объем
оперативной памяти). Как вариант можно настроить создание только той памяти, которая используется операционной системой. При этом можно сэкономить достаточно большой объем дискового пространства, а технические специалисты компании Microsoft получат более компактный файл для диагностики отказа системы. Можно даже включить создание дампа только стека (кучи). При этом размер дампа не превышает 64 Кбайт. Настройка этого параметра рассматривается в процедуре 1.3.
Как показывает опыт автора этой книги, в большинстве ситуаций дампа стека (кучи) оказывается достаточно для получения информации о нормально работающих серверах. Если отказы сервера происходят достаточно часто, может потребоваться создание дампа памяти операционной системы или дампа всего пространства памяти. Скорее всего, на этом этапе придется связаться со службой поддержки продуктов Microsoft (Product Support Services Microsoft), и уже сотрудники этой службы сообщат, какой тип информации им нужен.
Процедура 1.3. Настройка системы для создания дампа памяти ядра
В Control Panel (Панель управления) откройте аплет System (Система).
Перейдите на вкладку Advanced (Дополнительно).
Щелкните на кнопке Settings (Параметры) в разделе Startup and Recovery (Загрузка и восстановление).
В разделе Write Debugging Information (Запись отладочной информации) выберите параметр Kernel Memory Dump (Дамп памяти ядра) или Small Memory Dump (Малый дамп памяти), как показано на рис. 1.15.>
Предотвращение фрагментации файла подкачки страниц
Файл подкачки зачастую фрагментируется, что значительно снижает производительность системы. Поиск страниц в фрагментированном файле подкачки требует больших вычислительных ресурсов. Кроме этого,- поскольку файл подкачки является системным, программе дефрагментации приходится предпринимать дополнительные действия для дефрагментации обычных файлов, не трогая файл подкачки.
Для защиты файла подкачки от фрагментации выполните дефрагментацию диска перед созданием файла подкачки и сделайте одинаковыми максимальный и минимальный размеры файла подкачки. Это заставит операционную систему выделить пространство для файла подкачки за один проход. При этом файл подкачки не будет менять размер и будет не подвержен фрагментации. Удостоверьтесь, что для файла подкачки выделено достаточно дискового пространства. Если планируется поддержка Terminal Services, выделите для файла подкачки размер, в два раза больший объема оперативной памяти, но не более 4 Гбайт.
Функциональное описание процесса загрузки операционной системы Windows Server 2003
Компьютеры похожи на самолеты: основное количество аварий происходит при взлете и посадке. Здесь приводится подробный анализ процесса загрузки операционной системы Windows Server 2003, результатами которого можно воспользоваться для диагностики проблем при установке и модернизации.
Ниже приводится информация о процессе загрузки для архитектуры IA32. Процесс загрузки для архитектуры IA64 происходит значительно проще, так как EFI обнаруживает и запускает вторичный загрузчик, ia641dr. ef i с помощью информации, которая хранится в энергонезависимой памяти. Если используется компьютер на основе архитектуры IA64, сразу переходите к разделу “Ядро системы” далее в этой главе.
Начальная загрузка
При включении любого компьютера на основе архитектуры IA32 система начинает выполнение процедуры POST (Power On Self Test — самотестирование при включении питания). Последовательность действий во время POST зависит от конкретного компьютера. Короткий звуковой сигнал свидетельствует об успешном завершении процесса тестирования. В случае компьютеров на основе архитектуры IA64 процесс POST включает в себя полную проверку системы средствами расширяемого программно-аппаратного интерфейса Extensible Firmware Interface (EFI).
Завершающим этапом процедуры POST на компьютерах на основе архитектуры IA32 является передача управления процедуре INT13 в BIOS, которая используется для проверки наличия устройств, поддерживающих загрузку. В компьютерах на основе архитектуры IA64 загрузчик обнаруживается средствами EFI с помощью информации, которая хранится в энергонезависимой памяти.
В зависимости от параметров BIOS процедура загрузки сначала проверяет привод А, после чего проверяется привод, определяемый в BIOS как загрузочный. Это или ведущий диск на основном интерфейсе IDE, если такой диск существует, или диск SCSI, определенный как загрузочный в BIOS контроллера SCSI. Загрузка с диска SCSI при наличии диска IDE невозможна. С выбранного диска система загружает запись Master Boot Record (MBR).
В записи MBR присутствует выполняемый код, который в состоянии просканировать таблицу разделов в конце записи и определить сектор и/или смещение активного загрузочного раздела. Если этот код не в состоянии найти необходимые записи в таблице разделов, отображается сообщение об ошибке Invalid Partition Table. Если таблица разделов найдена, но начало активного раздела не обнаружено, отображается сообщение об ошибке Error Loading Operating System или Missing Operating System.
Вторичная загрузка
После того как код в записи MBR обнаружил начало активного раздела, он загружает первый сектор (512 байт) в память по адресу 0x700b. Это загрузочный сектор раздела или просто загрузочный сектор. Загрузочный сектор содержит код, предназначенный для поиска и размещения в памяти вторичного загрузчика. Выполняемый код в загрузочном секторе не в состоянии читать файловую систему, поэтому вторичный загрузчик должен находиться в корневом каталоге загрузочного диска.
На компьютере под управлением операционной системы DOS вторичный загрузчик хранится в файле io. sys. В операционных системах Windows Server 2003, Windows ХР, Windows 2000 и Windows NT для архитектуры IA32 вторичным загрузчиком является Ntldr. Если загрузчик Ntldr отсутствует или не загружается в память, код загрузочного сектора выводит сообщение об ошибке, например, А disk read error has occurred или Ntldr is missing, или Ntldr is compressed. В любом случае в сообщении об ошибке предлагается нажать комбинацию клавиш <Ctrl+Alt+Del> для перезагрузки компьютера.
Ntldr
При запуске загрузчика Ntldr видеоадаптер переводится в режим 80x25 с черным цветом фона. После этого процессор переходит в защищенный режим работы для поддержки 32-разряд- ной адресации и выполняется инициализация небольших драйверов файловой системы NTFS и FAT, которые встроены в код загрузчика Ntldr. Этих драйверов достаточно, чтобы Ntldr мог загрузить все необходимые файлы операционной системы Windows Server 2003.
Послр этого Ntldr находит файл boot. ini, который содержит меню загрузчика операционной системы Windows Server 2003. Дополнительная информация о записях в файле boot. ini приводится в разделе “Настройка boot. ini” в этой главе. Если Ntldr не в состоянии найти файл boot, ini, отображается сообщение Windows Server 2003 could not start because the following file is missing or corrupt: Boot.ini. Если файл boot. ini найден, но в нем отсутствуют корректные записи, может быть выдано любое количество сообщений об ошибках. Обычно это указывает на проблему с принятым по умолчанию путем ARC (Advanced RISC Computing — вычисления в среде усовершенствованных RISC-компьютеров).
Если в файле boot. ini присутствует только одна запись, операционная система Windows Server 2003 использует эту запись, игнорируя установленное время задержки до загрузки операционной системы. Если в файле присутствует несколько записей, по умолчанию используется задержка длительностью 30 секунд.
Версии загрузчика Ntldr
Загрузчик Ntldr для операционной системы Windows Server 2003 в состоянии загружать операционные системы Windows 2000 и Windows NT 4.0, но не наоборот. Помните об этом, устанавливая пакет обновлений или выполняя восстановление на компьютере с несколькими операционными системами. После перезаписи устаревшая версия загрузчика Ntldr не позволит загрузиться в операционную систему Windows Server 2003. Если Ntldr окажется случайно перезаписанным, его можно скопировать с другого компьютера под управлением Windows Server 2003. В операционных системах Windows Server 2003 и Windows ХР используется одна и та же версия загрузчика Ntldr.
Если операционная система Windows Server 2003 устанавливается совместно с другой установленной операционной системой, например Windows Эх или DOS, загрузочный сектор существующей операционной системы сохраняется в файле bootsect .dos. При этом в меню загрузчика предоставляется возможность загрузки альтернативной операционной системы.
Если выбрать загрузку альтернативной операционной системы, Ntldr загрузит содержимое файла bootsect. dos в память по смещению 7 00h, переключится в реальный режим работы процессора и передаст управление выполняемому коду образа загрузочного сектора.
И на компьютерах с архитектурой IA32, и на компьютерах с архитектурой IA64 время ожидания до загрузки, заданное для загрузчика, можно изменить с помощью утилиты bootcfg из состава операционной системы Windows Server 2003. Для этого необходимо воспользоваться командой bootcfg /timeout #, где #— количество секунд. Установив задержку равной 0, можно полностью отказаться от появления меню с обратным отсчетом времени и вариантами выбора операционной системы.
На компьютерах на основе архитектуры IA32 можно вручную отредактировать файл boot. ini и установить длительность задержки равной -1, что заставит загрузчик отображать меню бесконечно долго, пока пользователь не выберет один из пунктов. На компьютерах на основе архитектуры IA64 такого же результата можно добиться с помощью утилиты Boot Manager Maintenance.
Утилита ntdetect. com
Перед передачей управления образу ядра Ntldr должен получить информацию об используемом аппаратном обеспечении. Для этого используется утилита Ntdetect. com, которая собирает на компьютерах IA32 ту же информацию, которую EFI получает от прошивки на компьютерах IA64.
Не путайте Ntdetect с диспетчером Plug and Play (Plug and Play Manager). Инвентаризация устройств PnP выполняется на более позднем этапе процесса загрузки. Утилита Ntdetect определяет следующие параметры аппаратной конфигурации (тип центрального процессора и математического сопроцессора определяются позднее средствами ntoskrnl. ехе и hal. dl 1):
идентификатор компьютера (Machine ID); ■ порт связи;
тип шины и/или адаптера; ■ параллельный порт;
видеоадаптер; ■ привод гибких дисков;
клавиатура; ■ мышь.
Альтернативный драйвер SCSI
Если загрузка выполняется с жесткого диска SCSI, загрузочное устройство определяется средствами SCSI BIOS. Если BIOS на контроллере SCSI отсутствует или отключен, идентификатор SCSI (SCSI ID) загрузочного диска указывается в пути ARC в файле boot. ini. Это значит, что программа Ntldr должна иметь возможность сканирования шины SCSI в поисках соответствующего SCSI ID.
Если программа установки определяет, что на контроллере SCSI отсутствует работающая BIOS, драйвер мини-порта SCSI копируется в корневой каталог загрузочного раздела и переименовывается в ntbootdd. sys. Программа Ntldr загружает файл ntbgotdd.sys и использует драйвер мини-порта для связи с дисками. Файл ntbootdd. sys должен находиться в корневом каталоге диска, поскольку для его выявления Ntldr непосредственно использует вызовы INT13.
Утилита Ntdetect использует эту информацию для создания в памяти структуры данных, которая в дальнейшем используется драйвером ядра для создания в системном реестре раздела Hardware.
Ядро системы
Если выбрать операционную систему Windows Server 2003 в меню загрузчика, вторичный загрузчик (Ntldr для архитектуры IA32 и Ia641dr в случае архитектуры IA64) загружает ядро операционной системы, ntoskrnl. ехе, связанную с ним библиотеку уровня аппаратных
абстракций hal .dll (Hardware Abstraction Layer — HAL), а также драйвер видеоадаптера, bootvid .dll. Образы файлов ядра размещаются в памяти, но управление этим образам пока не передается. Сначала выполняется загрузка драйверов служб.
Если вторичный загрузчик не может найти файл ntoskrnl. ехе, выдается сообщение об ошибке Windows Server 2003 could not start because the following file is missing or corrupt: \<systemroot>\system32\Ntoskrnl.ехе. Наиболее вероятной причиной этой ошибки является неправильно указанное имя файла в меню загрузчика, хотя причиной может быть и повреждение файловой системы тома.
Если файл boot. ini отсутствует, загрузчик Ntldr обращается к диску, на котором расположен системный раздел, и пытается найти раздел, в котором находится файл ntoskrnl. ехе. В меню загрузчика эта запись обозначена как Default.
Драйверы служб
Вторичный загрузчик открывает раздел системного реестра System и в разделе Select пытается найти раздел Currentcontrolset. После этого сканируется раздел Services, который находится в разделе CurrentControlSet. При этом выполняется поиск устройства со значением записи Start, равным 0, что указывает на Service_Boot_Start, и 1, что указывает на Service_System_Start. Эти драйверы загружаются в последовательности, указанной в значении записи Group в разделе Control, Service Group Order.
На этом этапе на консоли отображаются сообщение Starting Windows Server 2 003 (Запуск Windows Server 2003) и индикатор состояния процесса, который изменяется соответственно загрузке драйверов. После завершения этого процесса выполняется инициализация ntoskrnl. ехе и вторичный загрузчик передает образы драйверов, загруженных в память.
Инициализация ядра
После запуска ntoskrnl.exe выполняется инициализация библиотек hal.dll и bootvid.dll. Программа установки переключается в графический режим. Ядро ntoskrnl инициализирует системные драйверы и использует информацию, полученную от nt de tec t. com (IA32) или EFI (IA64) для создания раздела системного реестра Hardware. После этого вызывается Session Manager (Диспетчер сеансов) smss . ехе.
Диспетчер сеансов
Session Manager (Диспетчер сеансов) читает собственный раздел HKLM\System\ CurrentControlSet\Control\Session Manager в пределах раздела System и пытается обнаружить записи в разделе BootExecute. По умолчанию при этом используется утилита autochk —версия утилиты chkdsk, предназначенная для использования во время загрузки, и настраивается файл подкачки страниц pagefile. sys. После завершения предварительной подготовки Session Manager (Диспетчер сеансов) одновременно выполняет два следующих действия.
Загружает службу регистрации на консоли winlogon.exe, которая запускает процесс проведения аутентификации. Служба Winlogon запускает подсистему LSA (Local Security Authority — локальные средства защиты), lsass.exe, и службу спулера печати, spoolss . ехе, совместно с соответствующими библиотеками функций поддержки.
Загружает Services Controller screg.exe, который завершает загрузку оставшихся устройств и служб.
В операционной системе Windows NT пользователей удивляла длительная задержка между моментом ввода регистрационных данных и появлением рабочего стола. В операционной системе Windows 2000 компания Microsoft решила не выводить окно регистрации, пока не будут инициализированы драйверы служб. В операционной системе Windows Server 2003 для ускорения доступа к консоли пользователю разрешена регистрация еще до инициализации многих служб. Если регистрационные данные пользователя правильны, можно убедиться в удачном завершении загрузки. Пользователь слышит музыкальное приветствие.
Если screg. ехе не в состоянии запустить устройство или службу, то выполняются действия, которые определены в соответствующем разделе системного реестра. При этом может быть выдано простое сообщение в журнал событий или выполнена остановка системы при возникновении критической ошибки. Если проблема не препятствует дальнейшей работе системы, screg.exe выдает на консоль сообщение, в котором пользователь уведомляется о существовании проблемы и предлагается проверить журнал событий. Такое сообщение выдается не всегда, поэтому при запуске сервера всегда стоит проверять содержимое журнала событий. Необходимо расследовать информацию о некорректном запуске и исправить обнаруженную проблему.
Совет по использованию реестра: устранение проблем с помощью autochk
Обычно утилита autochk запускается в режиме "только для чтения", поэтому наличие проблемы подтверждается, но попыток исправления не предпринимается. Утилиту autochk можно заставить исправлять обнаруженные ошибки (как при запуске команды chkdsk /f), добавив параметр /р в конец записи в системном реестре:
Раздел: HKLM\System\CurrentControlSet\Control\Session Manager
Запись: BootExecute
Значение: Autochk * /р
Задержка регистрации на локальной консоли
Записи системного реестра для драйверов служб хранятся в разделе control Set. По умолчанию существует два раздела control Set, которые называются Control Set 1 и Control Set 2. Как будет продемонстрировано в главе 21, "Восстановление после отказов системы", одним из действий Session Manager (Диспетчер сеансов) после успешной регистрации является копирование использованного при загрузке раздела Control Set в раздел control Set 2 и объявление этой копии Last Known Good Control Set
Иногда проблема возникает спустя некоторое время после успешной регистрации. К этому моменту слишком поздно перезагружать компьютер с помощью Last Known Good Control Set. Во избежание этой проблемы можно подключиться к серверу по сети (не с помощью удаленного рабочего стола) и проверить наличие ошибок в системном журнале событий еще до регистрации на консоли.
Настройка файла boot. ini
На компьютерах на основе архитектуры IA32 для поиска загрузочного раздела и папки, содержащей загрузочные файлы Windows Server 2003 вторичный загрузчик Ntldr использует файл boot. ini. Если при загрузке после модернизации или после добавления новых устройств массового хранения наблюдается странное поведение, обратите внимание на содержимое файла boot. ini. Дополнительная информация о формате записей меню загрузчика для компьютеров на основе архитектуры IA64 приводится в главе 3, “Добавление аппаратных средств”. Ниже представлен пример файла boot. ini для системы, в которой присутствует раздел DOS:
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\Windows
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\Windows=”Windows Server 2003,
^ Standard Edition" /fastdetect•
c: \="MS/DOS”
Длинная запись в разделе [operating systems] является путем Advanced RISC Computing (ARC). Путь ARC указывает загрузчику Ntldr, где искать раздел Windows Server 2003. При формировании пути ARC используется следующий синтаксис:
controller()disk()rdisk()partition()\systemroot="menu listing"
В следующих разделах рассматривается смысл каждого элемента записи.
controller (). Тип интерфейса
Существуют три варианта этого элемента.
multi(). Указывается при использовании приводов IDE или контроллеров SCSI с установленной BIOS. Номер в скобках соответствует идентификатору контроллера SCSI или IDE. Если операционная система Windows Server 2003 установлена на диск, подключенный ко вторичному контроллеру IDE, запись будет иметь вид multi (1).
scsi(). Указывается при использовании контроллера SCSI без установленной BIOS или с отключенной BIOS. Эта запись использовалась в операционной системе Windows NT, она не применяется в операционной системе Windows Server 2003.
signature(). Используется, когда диск недоступен при помощи стандартных вызовов INT13 и требуется специальный набор действий со стороны Ntldr. Номер в скобках является сигнатурой, которая записывается в MBR диска при операции создания разделов средствами программы установки.
Системные атрибуты файлов и скрытые файлы
Для файла boot. ini по умолчанию установлены атрибуты System (Системный) и Read-only (Только чтение). Это предотвращает. возможность модификации и удаления этого файла обычным пользователем. Если необходимо внести изменения в файл boot. ini, воспользуйтесь командой attrib для снятия атрибута Read-only (Только чтение).
Для остальных системных файлов, например ntldr, ntdetect.com и ntbootdd. sys, установлены атрибуты System (Системный) и Hidden (Скрытый). Такие файлы считаются полностью скрытыми (superhidden) и не видны пользователю, даже если в пользовательском интерфейсе задано отображение скрытых файлов. Суперскрытые файлы можно увидеть с помощью команды dir /А.
Если в качестве типа контроллера указывается signature () и жесткий диск подключен к контроллеру SCSI, который не оборудован BIOS, загрузчик Ntldr использует драйвер минипорта SCSI из файла ntbootdd. sys для чтения дисков и поиска соответствующей сигнатуры.
disk(). Идентификатор SCSI
Элемент disk () используется совместно с элементом sc si () для нахождения идентификатора SCSI жесткого диска, на котором хранятся загрузочные файлы. Поскольку элемент signature () уникально идентифицирует диск и без идентификатора использования SCSI, в операционной системе Windows Server 2003 использование этой записи не требуется. Если используется элемент multi (), значение disk () всегда равно 0.
rdisk (). Относительное расположение диска
Компонент rdisk () используется вместе с компонентом multi () для индикации относительного расположения диска. Для дисков IDE относительное расположение диска определяется по подключению как один из двух вариантов: основной или подчиненный (master/slave). Например, для подчиненного (slave) диска на первом контроллере IDE будет использоваться запись вида multi (0)disk(0) rdisk (1).
Для приводов SCSI относительное расположение диска определяется сканированием устройств, которое выполняется SCSI BIOS во время процедуры POST. Обычно порядок сканирования соответствует порядку идентификаторов SCSI. Если BIOS сообщает о трех подключенных к шине дисках, то указатель на третий диск будет выглядеть как multi (0) disk (0) rdisk (2) независимо от значения идентификатора SCSI. Если в качестве загрузочного не выбрать диск 0, то относительное расположение диска изменится.
Если для выбора контроллера используется signature (), элемент rdisk () всегда будет иметь значение 0, поскольку для поиска диска используется сигнатура в MBR.
partition (). Порядковый номер загрузочного раздела
Это порядковый номер загрузочного раздела. Обратите внимание, что в данном случае счет начинается с 1, а не с 0. Интересные особенности изменения номеров разделов приводятся во врезке “Автоматическое изменение номеров разделов”.
Системный каталог Windows Server 2003 \systemroot
По умолчанию в операционной системе Windows Server 2003 системным каталогом является каталог \Windows. Это имя каталога используется во всех примерах в этой книге. В процессе установки может быть задано другое имя каталога. Имя системного каталога хранится в переменной среды %systemroot%. В любом разделе должен присутствовать только один корневой каталог системы. Компания Microsoft настоятельно рекомендует не устанавливать несколько операционных систем Windows в один раздел, так как операционная система создает несколько файлов, которые хранятся вне каталога, заданного в %systemroot%.
Текстовое меню
Текст, указанный в кавычках, отображается в виде пункта меню загрузчика. Этот текст можно изменить, если это поможет пользователям выбирать правильный пункт меню; в обычных условиях пользователю вообще не стоит видеть меню.
Примеры путей ARC z
Предположим, что на компьютере установлено несколько версий операционных систем Windows Server 2003 и Windows NT с альтернативной загрузкой в DOS. Соответствующие этой ситуации характеристики дисков и разделов приведены в табл. 1.2.
Таблица 1.2. Пример таблицы разделов
SCSI ID #
Диск#
Раздел #
Операционная система
IDO
C
1
DOS
IDO
D
2
Windows NT Workstation 4.0
ID 1
E
1
Windows NT Server 4.0
ID 2
F
1
Windows XP Professional
ID 2
G
2
Windows Server 2003 Standard Edition
Автоматическое изменение номеров разделов
Существует несколько особенностей назначения путей ARC. Можно даже спровоцировать изменение нумерации разделов, ничего об этом не подозревая. Операционная система Windows Server 2003 учитывает такие изменения и соответствующим образом автоматически изменяет пути ARC в файле boot. ini. Вот как это происходит.
Базовый диск на компьютере IA32 может содержать до четырех основных разделов. Разделы пронумерованы по порядку. Например, если операционная система Windows Server 2003 устанавливалась во второй основной раздел, запись ARC будет выглядеть как partition (2).
Кроме основных разделов, привод может содержать один расширенный раздел, который позволяет создавать любое количество логических дисков. Логические диски также рассматриваются как разделы при создании путей ARC. Например, если установить операционную систему Windows Server 2003 во второй логический диск и на диске присутствуют другие основные разделы, запись ARC выглядит как partition (3).
При подсчете разделов для создания пути ARC операционная система Windows Server 2003 сначала считает основные разделы, после чего считает логические диски в составе расширенного раздела. Этот метод является противоположностью метода инвентаризации разделов при назначении букв дисков в процессе установки, поэтому он способен вызвать затруднения у некоторых администраторов.
Предположим, что на компьютере с множественной загрузкой с основным разделом и расширенным разделом, в котором присутствует один логический диск, операционная система Windows Server 2003 установлена на логический диск. И опять запись ARC будет выглядеть как partition(3).
Если за пределами расширенного раздела присутствует несколько гигабайтов свободного дискового пространства, туда можно установить операционную систему Windows Server 2003, создав еще один основной раздел (расширенный раздел создать не удастся, поскольку на диске может существовать только один расширенный раздел). Для этого экземпляра операционной системы путь ARC выглядит как partition(2), так как основные разделы при назначении порядковых номеров учитываются прежде логических дисков.
При установке второго экземпляра операционной системы первая запись ARC оказывается некорректной. Теперь она должна быть partition (4). Операционная система Windows Server 2003 автоматически обходит эту проблему и вносит изменения в запись ARC, которая продолжает соответствовать реальному расположению раздела.
Это новая особенность операционной системы Windows Server 2003 и она не всегда срабатывает. Иногда требуется изменение записей ARC вручную.
Содержимое файла boot. ini можно редактировать с помощью утилиты bootcfg. Эта утилита доступна как для архитектуры IA64, так и для архитектуры IA32. Администратору предоставляется несколько возможностей по автоматизации изменений файла boot. ini. Кроме этого, служба Help and Support Center (Помощь и центр поддержки) предоставляет утилиту с графическим интерфейсом, которая называется System Configuration Utility (утилита настройки конфигурации системы), или msconf ig. ехе, и позволяет упростить внесение изменений в файл boot. ini.
Ниже приведены записи ARC для каждого загрузочного раздела:
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Windows NT Workstation Version 4.0".
multi(0)disk(0)rdisk(1)partition(1)\WINNT="Windows NT
^ Server Version 4.0"
multi(0)disk(0)rdisk(2)partition(1)\WINNT="Windows XP
^ Professional" /fastdetect
multi(0)disk(0)rdisk(2)partition(2)\WINNT="Windows Server 2003
^ Standard Edition" /fastdetect
c:\="MS/DOS"
Параметры файла boot. ini
Вот несколько основных параметров, используемых в файле boot. ini.
Timeout. Значение параметра Определяет длительность задержки перед загрузкой операционной системы, принятой по умолчанию. По умолчанию задержка составляет 30 секунд.
Default. Параметр определяет раздел, который будет использован для загрузки операционной системы при отсутствии действий со стороны пользователя.
[Operating Systems]. Раздел содержит список разделов, поддерживающих загрузку и соответствующие пути ARC.
/ЗОВ. Параметр меняет распределение виртуальной памяти, выделяя 3 Гбайт пользовательским процессам и 1 Гбайт системе. Этот параметр доступен только в версиях Enterprise и Datacenter Edition.
/bootlog. Включает запись журнала загрузки в файл ntbtlog. txt, хранящийся в каталоге \Windows.
/cmdcons. Используется при загрузке Recovery Console (Консоль восстановления).
/fastdetect. Параметр отключает инвентаризацию устройств РпР для последовательных интерфейсов до графического этапа загрузки операционной системы.
/шахтеш. Используется для диагностики проблем, связанных с работой памяти. Этот параметр ограничивает объем оперативной памяти, используемой системой. Если есть подозрение, что один из банков памяти поврежден, установите значение параметра таким образом, чтобы второй банк памяти не использовался. Если проблема исчезла, замените модуль памяти. Также этот параметр можно использовать для диагностики проблем производительности, связанных с объемом оперативной памяти.
/рае и /порае. В версиях Enterprise Edition и Datacenter Edition параметр /рае позволяет включить технологию расширения физических адресов (РАЕ — Physical Address Extensions) для доступа к памяти выше 4 Гбайт. Параметр /порае позволяет отключить эту возможность для проведения диагностики неисправностей.
/pcilock. Отключает большую часть функций библиотеки аппаратных абстракций (HAL) по автоматическому распределению ресурсов. Это не дает HAL вносить изменения в результаты распределения ресурсов, полученные с помощью РпР BIOS. Чаще всего параметр используется для исправления “зависаний” системы.
/redirect. Параметр используется для перенаправления консольного вывода на серверах без видеоподсистемы.
/safeboot. Заставляет операционную систему загружаться в Safe mode (Безопасный режим). Параметр используется совместно с такими обозначениями режима: minimal или network, или dsrepair, например /safeboot:minimal. Эти параметры соответствуют пунктам меню, отображающегося при нажатии клавиши <F8> в процессе загрузки.
/safeboot :minimal(alternateshell). Дополнительный параметр позволяет загрузиться в командный интерпретатор, который определяется записью HKLM\System\Current ControlSet\Control\Safeboot\AlternateShell. По умолчанию используется командный интерпретатор cmd. ехе. При необходимости этот командный интерпретатор можно заменить другим, например progman. ехе.
/scsiordinal :х. Используется для обозначения различий между двумя идентичными контроллерами SCSI. Если после добавления второго контроллера операционная система в процессе загрузки выдает экран с сообщением об ошибке, драйвер SCSI осуществляет привязку не к тому контроллеру. Если файлы Windows Server 2003 находятся на диске, подключенном ко второму контроллеру, установите для параметра х значение 1.
/sos. Выводит имя драйверов в процессе загрузки, а также результаты сканирования autochk, которое выполняется при каждой загрузке операционной системы. Этот параметр можно расшифровать как “Show Our System” (“Показать нашу систему”).
/win95dos и /win.95. Эти параметры позволяют эмулировать возможности двойной загрузки операционной системы Windows 9х. Параметры используются совместно с файлами bootsect. dos, в которых содержится загрузчик операционной системы Windows 95.
Дополнительные параметры boot. ini используются для сервера без видеоподсистемы и для отладки режима ядра. Дополнительная информация о работе сервера без видеоподсистемы приводится в главе 2, “Модернизация и автоматизированная установка”. Информация об отладке в режима ядра дана в главе 21, “Восстановление после отказов системы”..
Специальные пути ARC(
Для поиска загрузочного диска и файлов в корневом каталоге загрузочного раздела загрузчик Ntldr использует вызовы INT13 функций фиксированного диска.'Существует несколько ситуаций, в которых стандартного пути ARC недостаточно для использования программой Ntldr вызова INT13.
. Отсутствие поддержки расширений INT13 "
В классической операционной системе Windows NT размер загрузочного раздела не мог превышать 7,8 Гбайт, а последним цилиндром загрузочного раздела был цилиндр 1024. Это было связано с ограничениями вызова функций INT13.
Оригинальная спецификация INT13 предполагала набор определенных ограничений на использование схемы CHS (Cylinder/Head/Sector — Цилиндр/Головка/Сектор). Ограничения были пересмотрены с увеличением объема жестких дисков. Спецификация РС97 описывала набор расширений INT13, которые поддерживали диски большего объема. В операционной системе Windows 2000 поддерживаются расширения INT13, поэтому загрузочный раздел может быть больше 7,8 Гбайт.
Если конкретная операционная система не поддерживает расширений INT13 и размер загрузочного раздела превышает 7,8 Гбайт (или раздел лежит за пределами цилиндра 1024), загрузчику Ntldr потребуется другой способ доступа к загрузочному диску.
Нет BIOS на контроллере SCSI•
Контроллер SCSI поддерживает вызовы INT13 с помощью специальных интерфейсов в BIOS контроллера. Если на контроллере BIOS не установлена или отключена, загрузчику Ntldr потребуется другой способ доступа к загрузочному диску. В классической операционной системе Windows NT для этого использовался драйвер мини-порта SCSI, хранящийся в файле ntbootdd. sys. Загрузчик использовал этот драйвер для сканирования шины. Путь ARC содержал записи scsi () disk (), которые сообщали загрузчику Ntldr порядковый номер контроллера SCSI и идентификатор SCSI загрузочного диска.
Поскольку операционная система Windows Server 2003 использует подсистему Plug and Play, существует возможность изменения порядкового номера контроллера SCSI. Такое изменение мешает загрузчику Ntldr находить загрузочный диск с помощью пути ARC. Именно по этой причине загрузчик Ntldr требует более надежного, чем использование идентификатора SCSI (SCSI ID), способа обнаружения загрузочного диска.
Компонент signature ()
В операционной системе Windows Server 2003 (и Windows 2000) отсутствие поддержки INT13 компенсируется компонентом signature () в записи пути ARC. Вот пример пути ARC, в котором используется эта запись.
signature(ealaa9c7)disk(0)rdisk(0)partition(1)\WINNT="Microsoft
Windows Server 2003” /fastdetect
Число в скобках, ealaa9c7, является случайным числом, записанным в главную загрузочную запись загрузочного диска в процессе установки. Иногда это число называют отказоустойчивой загрузочной сигнатурой (это термин из классической операционной системы Windows NT).
Если загрузчик Ntldr обнаруживает в пути ARC компонент signature (), выполнятся сканирование устройств массового хранения в попытке обнаружить диск, содержащий в MBR соответствующую сигнатуру. Для дисков IDE загрузчик использует вызовы INT13. Для дисков SCSI загружается драйвер мини-порта ntbootdd. sys. Сигнатура уникально идентифицирует загрузочный диск независимо от порядкового номера контроллера SCSI.
Ограничения signature ()
Использование компонента signature () для идентификации загрузочных дисков в файле boot. ini имеет определенные недостатки. Если сигнатура диска окажется перезаписанной вирусом или в результате повреждения записи MBR, загрузчик Ntldr не сможет найти загрузочный диск и выдаст сообщение об ошибке windows Server 2003 could not start because of a computer disk hardware configuration problem.
Если возникла такая ошибка, ее можно исправить с помощью процедуры 1.4.
Процедура 1.4. Исправление потерянных сигнатур дисков
Устраните причину повреждения сигнатуры в главной загрузочной записи MBR. Для создания новой записи MBR можно воспользоваться Recovery Console (Консоль восстановления). Дополнительная информация приводится в главе 21, “Восстановление после отказов системы”.
Воспользуйтесь утилитой Disk Probe (или подобной) из состава Resource Kit для записи в MBR новой отказоустойчивой сигнатуры. Физическое расположение сигнатуры рассматривается в главе 3, “Добавление аппаратных средств”. Подойдет любое число из четырех байтов.
Воспользовавшись информацией из главы 3, “Добавление аппаратных средств”, создайте отказоустойчивый загрузочный диск. Измените путь ARC в файле boot. ini, указав новое значение параметра signature (). Загрузите систему с помощью созданного загрузочного диска.
После загрузки системы исправьте путь ARC в файле boot. ini на загрузочном диске.
Устранение проблем во время установки операционной системы
Установка и настройка сервера может отнять половину дня. Если повезет, можно успеть домой на ужин. Если нет, то можно воспользоваться этими советами и попытаться успеть к вечерним новостям.
В первую очередь, необходимо выяснить, что произошло. Программа установки ведет несколько журналов о том, что делается и как делается. Если компьютер работает в течение некоторого времени, обратите внимание на содержимое следующих файлов из каталога \Windows.
setuplog.txt. Содержит подробное описание каждого загруженного драйвера и службы, а также каждой библиотеки DLL, зарегистрированной за время текстового этапа установки.
setupact.log. Описывает операции с файлами, которые выполняются в ходе графического этапа установки.
setuperr.log. Содержит сведения об ошибках, которые возникли при инициализации служб и устройств во время процедуры установки. Если в этом журнале записаны хоть какие-то данные, программа установки предлагает показать содержимое журнала после завершения установки.
Кроме этого, предоставляется возможность загрузки с использованием параметра Boot Log. При этом выводится список драйверов, которые загружаются Ntldr и SCREG. Для включения этого параметра нажмите клавишу <F8> в меню загрузчика и выберите Boot Logging (Протоколирование загрузки). При этом в каталоге \Windows будет создан файл Ntbtlog.txt.
Останов 0x0000007b Inaccessible_Boot_Device
Иногда при первой загрузке после установки отображается экран с сообщением об ошибке на уровне ядра с кодом ошибки 0x0000007b, Inaccessible_Boot_Device. Эта проблема возникает при несовпадении параметров MBR и конфигурации CHS (Цилиндр/Головка/Сектор), полученной от BIOS. Часто единственным способом восстановления системы является форматирование диска и повторная установка. Исследовать причину проблемы можно с помощью отчета о состоянии разделов, предоставляемого, например, программами System Commander и Partition Magic.
Информация о системе
Администраторы операционной системы WindowsNT будут обрадованы доступностью утилиты winmsd с помощью команды Run (Выполнить). В операционной системе Windows Server 2003 команда winmsd запускает альтернативный выполняемый файл, msinfo32 . ехе, который хранится в каталоге \Program Files\Common Files\Microsoft SharedXMSInfo. В свою очередь, этот файл запускает компоненты Help and Support Center (Помощь и Центр поддержки), предназначенные для отображения информации, полученной с помощью интерфейса WMI (Windows Management Instrumentation — средства управления Windows). Пример использования этой утилиты показан на рис. 1.16.
«1Я13£|«1Я13£|
«1Я13£|
«1Я13£|
® Hardware Resourcesф Components® Software Environment® Internet Setthgs® Hardware Resourcesф Components® Software Environment® Internet SetthgsOS NameOS Manufacturer Activation Status System Name System Manufacturer System Model System Type ProcessorBIOS Versicn/Date SMBIOS Version V/ndows Directory System Directory Boot Device LocateHardware Abstraction L^er User NameTimeZone T olai Physical Memory Available Physical Memory Total Virtual Memory Avaiabte Virtual Memory Page Fie Space Page FieOS NameOS Manufacturer Activation Status System Name System Manufacturer System Model System Type ProcessorBIOS Versicn/Date SMBIOS Version V/ndows Directory System Directory Boot Device LocateHardware Abstraction L^er User NameTimeZone T olai Physical Memory Available Physical Memory Total Virtual Memory Avaiabte Virtual Memory Page Fie Space Page FieГ' Beech sateiNd cateoom аг* Г* Seeche*MX»iwwcriuГ' Beech sateiNd cateoom аг* Г* Seeche*MX»iwwcriuРис. 1.16. Окно утилиты System InformationРис. 1.16. Окно утилиты System Information
® Hardware Resources
ф Components
® Software Environment
® Internet Setthgs
® Hardware Resources
ф Components
® Software Environment
® Internet Setthgs
OS Name
OS Manufacturer Activation Status System Name System Manufacturer System Model System Type Processor
BIOS Versicn/Date SMBIOS Version V/ndows Directory System Directory Boot Device Locate
Hardware Abstraction L^er User Name
TimeZone T olai Physical Memory Available Physical Memory Total Virtual Memory Avaiabte Virtual Memory Page Fie Space Page Fie
OS Name
OS Manufacturer Activation Status System Name System Manufacturer System Model System Type Processor
BIOS Versicn/Date SMBIOS Version V/ndows Directory System Directory Boot Device Locate
Hardware Abstraction L^er User Name
TimeZone T olai Physical Memory Available Physical Memory Total Virtual Memory Avaiabte Virtual Memory Page Fie Space Page Fie
Г' Beech sateiNd cateoom аг* Г* Seeche*MX»iwwcriu
Г' Beech sateiNd cateoom аг* Г* Seeche*MX»iwwcriu
Рис. 1.16. Окно утилиты System Information
Рис. 1.16. Окно утилиты System Information
SSbZHZ—-
Microsoft Windows .NET Enterprise Server 5.1.3690 Bl*I 3690 Microsoft Corporation
Activation Pending (11 days remaining)
SERVER1
Del Computer Corporation 0ptiPtexGX110 X86-basedPC x96 Family 6 Model 9 Stepping 3 Genuinelntel "665 Mhz d Del Conner Corporation A02,1/29/2000 2.3 C:\WINNT
C:\WINNT\System32 \Device\HarddttkVolume1 United States
Version -"5.1.3690.0 (main. 011110-1652]* SU9SIDIARY\adrin1 US Mountain Standard Time 384.00 MB 142.29 MB 1.27 GB 864.25 MB 920.16MB C:\pagefite.sys
Еще одним способом получения информации о системе является использование утилиты systeminfo с интерфейсом командной строки. Ниже представлен пример использования этой утилиты:
Host Name:
SERVERI
OS Name:
Microsoft Windows Server 2003
OS Version:
Enterprise Edition
5.1.3690 Build 3690
OS Manufacturer:
Microsoft Corporation
OS Configuration:
Primary Domain Controller
OS Build Type:
Uniprocessor Free
Registered Owner:
Admin
Registered Organization:
Company
Product ID:
55039-985-0023054-00576
Original Install Date:
2/21/2002, 11:06:47 AM
System Up Time:
3 Days, 11 Hours, 32 Minutes, 41 Seconds
System Manufacturer:
Dell Computer Corporation
System Model:
OptiPlex GX150
System type:
Processor(s):
X86-based PC
1 Processor(s) Installed. [01]: x86 Family 6 Model 8
t>
BIOS Version:
Stepping 3 Genuinelntel.665 Mhz
DELL - 7
Windows Directory:
C:\Windows
System Directory:
C:\Windows\System32
Boot Device:
\Device\HarddiskVolumel
System Locale:
en-us;English (United States)
Input Locale:
en-us;English (United States)
Time Zone:
(GMT-07:00) Arizona
Total Physical Memory:
382 MB
Available Physical Memory:
146 MB
Virtual Memory: Max Size:
Virtual Memory: Available:
1,302 MB
867 MB
Virtual Memory: In Use:
43 5 MB
Page File Location(s):
C:\pagefile.sys
Domain:
company.com
Logon Server:
\\SERVERI
Network Card(s):
1 NIC(s) Installed.
[01] :
3Com 3C920 Integrated Fast Ethernet
Connection Name:
Controller(3C905C-TX Compatible) Local Area Connection
DHCP Enabled:
No
IP address(es) [01]:
192.168.0.1
"Зависание" программы установки
Из всех возможных проблем в процессе установки “зависания” оказываются самыми неприятными, поскольку больше никакие явные симптомы проблемы администратору не доступны. Программа установки просто доходит до определенного момента и “задумывается”. И думает. И думает. И продолжает думать, как участник шоу Кто хочет стать миллионером?, а администратор сидит напротив, как ведущий шоу, пытающийся поддержать приятную беседу, поглядывая на часы.
Первое правило поведения при “зависаниях” — “ничего не делать”. Постарайтесь переждать задержку. Задержки, продолжительность которых измеряется часами, вполне реальны. Обычно такие задержки заканчиваются и стоит подождать выхода системы из этого состояния.
Если серьезное “зависание” произошло на этапе обнаружения устройств в ходе графического этапа установки, нажмите комбинацию клавиш <Shift+F10> для получения доступа
к консоли и просмотрите содержимое файла setuplog.txt. Если в файле присутствуют записи, можно сделать вывод, что что-то случилось. Если в течение нескольких часов индикатор выполнения установки не сменил положения и в файл не были добавлены записи, можно сдаваться.
Ожидая завершения задержки, обратитесь к документации по поводу сведений об известных несовместимостях аппаратных средств. Стоит обратиться к следующим источникам.
Сопроводительные документы (release notes) и файлы readme, предоставленные на установочном компакт-диске Windows Server 2003
База знаний Microsoft по адресу www.microsoft. com/technet
Сайты производителей аппаратных средств
Если принимается решение о прерывании процедуры установки и перезагрузке компьютера, выполните несколько предварительных действий, чтобы не повторить опять многочасовое ожидание. Забудьте о научном подходе, главное — заставить компьютер работать под управлением Windows Server 2003. Конкретную причину проблемы можно будет выяснить позднее. Вот несколько советов.
Просмотрите список действий, которые стоит предпринять перед установкой операционной системы (приводится в начале этой главы) и удостоверьтесь, что ничего не пропущено, например модернизация прошивки, отключение сетевого кабеля блока бесперебойного питания, отключение Plug and Play или настройка устаревших компонентов. Все перечисленные проблемы являются основными причинами “зависаний” при установке.
Удалите сетевой адаптер.
Удалите все адаптеры устройств мультимедиа.
Отключите инфракрасные устройства.
Просмотрите файл txt setup, sif и закомментируйте (с помощью точки с запятой) все ненужные драйверы. В этом случае процедура установки должна запускаться с сетевого диска.
Если в компьютере установлено два видеоадаптера, удалите один. '
Удалите устаревшие адаптеры ISA.
Переставьте адаптеры PCI в другие разъемы.
Если на компьютере присутствует несколько шин PCI, попробуйте подключить все адаптеры к одной шине.
Если к компьютеру подключены специальные компоненты SCSI, например сканеры или ленточные приводы, отключите их от шины.
Если к компьютеру подключены компоненты FireWire, отключите их от шины.
Для портативных компьютеров извлеките адаптеры PCMCIA и отключите компьютер от док-станции.
Отключите компоненты USB (воспользуйтесь клавиатурой PS/2, если на компьютере установлен разъем PS/2).
После этого еще раз запустите программу установки. Если она все еще “зависает”, еще раз проверьте оборудование по списку совместимости HCL. Если оборудование в списке присутствует, демонтируйте все оборудование компьютера, кроме стандартного адаптера VGA, клавиатуры и мыши. В параметрах BIOS отключите все, что хотя бы напоминает расширенную функцию. Повторите попытку установки. Если программа установки все еще “зависает”, попытайтесь установить Windows Server 2003 на аналогичный компьютер. Если “зависание” удалось повторить, пришло время обращаться к производителю за поддержкой.
Отказы некоторых устройств
Если операционная система загружается, но некоторые функции оказываются недоступными, возможной причиной является отказ некоторых устройств или конфликт ресурсов. Для диагностики проблем такого типа можно использовать Device- Manager (Диспетчер устройств). Существует несколько способов его запуска.
Щелкните правой кнопкой мыши на пиктограмме Му Computer (Мой компьютер) и откройте консоль Computer Management (Управление компьютером), выбрав из контекстного меню команду Manage (Управление). Интересующий компонент находится в разделе дерева System Tools^Device Manager (Служебные программы1^Диспетчер устройств).
Щелкните правой кнопкой мыши на пиктограмме Му Computer (Мой компьютер) и выберите из контекстного меню команду Properties (Свойства), перейдите на вкладку Hardware (Оборудование) и щелкните на кнопке Device Manager (Диспетчер устройств).
Откройте окно Run (Выполнить), введите devmgmt.msc и нажмите клавишу <Enter> (это любимый способ автора книги).
Если напротив устройства отображается знак вопроса или пиктограмма X красного цвета, выполните двойной щелчок на устройстве для просмотра информации о конфликте. Некоторые ошибки в работе устройств более распространены, чем остальные. Дополнительная информация о диагностике проблем в работе аппаратного обеспечения и подсистемы РпР приводится в главе 3, “Добавление аппаратных средств”.
Иногда, чтобы запустить Device Manager (Диспетчер устройств), может потребоваться загрузка в безопасном режиме. В меню загрузчика нажмите клавишу <Е8> и выберите Safe Mode (Безопасный режим) из списка вариантов загрузки.
Проблема при копировании файлов
на жесткий диск
Иногда операционная система Windows отказывается распознавать жесткий диск. Если жесткий диск отсутствует на экране управления разделами в начале установки, то Ntdetect по какой-то причине не распознал этот диск. Существует несколько возможных причин.
Проверьте все разъемы для подключения кабелей. Кроме этого, убедитесь, что кабели вообще подключены, не говоря уже о наличии самого диска, если речь идет о новом компьютере. Загрузитесь в операционную систему DOS и проверьте видимость диска с помощью утилиты fdisk.
Убедитесь, что в параметрах BIOS отключены теневая память и кэш-память обратной записи. Аппаратное кэширование часто является причиной возникновения критических ошибок в режиме ядра и повреждений данных. Обычно все кэширование обрабатывается средствами Windows Server 2003. Большая производительность и большая надежность могут быть получены и без аппаратного кэширования, если кэш-память не сертифицирована для работы с операционной системой Windows Server 2003.
Поддерживаемые преобразования дисков. Убедитесь, что диски не настраивались с помощью диспетчеров дисков, которые не совместимы с Windows Server 2003. Некоторые уникальные типы отображения секторов не поддерживаются. Если диск использует программу преобразования цилиндров, например, OnTrack, удостоверьтесь, что программа сертифицирована для работы совместно с операционной системой Windows Server 2003.
Диск с интерфейсом IDE распознается BIOS. Если используется жесткий диск IDE большого объема, убедитесь, что в параметрах BIOS указана правильная конфигурация диска.
Проведите сканирование на присутствие вирусов. Операционная система Windows Server 2003 не устанавливается на зараженный жесткий диск. Проведите сканирование диска с помощью утилиты, предназначенной для операционной системы DOS или Windows.
Проверьте правильность MBR. Главная загрузочная запись MBR может оказаться поврежденной. В операционной системе DOS запустите команду fdisk /mbr для создания новой загрузочной записи.
Терминаторы на шине SCSI. Если в системе присутствует жесткий диск с интерфейсом SCSI, убедитесь в правильности подключения терминаторов шины. Даже если в операционных системах DOS и Windows жесткий диск работал правильно, в операционной системе Windows Server 2003 возможны отказы, поскольку используется другой тип драйвера SCSI. Кроме этого, убедитесь, что жесткий диск, на который устанавливалась операционная система, все еще присутствует в списке дисков SCSI при сканировании подключенных к шине устройств во время перезагрузки.
Параметры загрузки SCSI. Удостоверьтесь в правильности параметров загрузочного устройства SCSI. Может сложиться впечатление, что загрузка выполняется с одного диска, а на самом деле для загрузки используется другой диск.
Проблемы в работе интерфейсных адаптеров Ultra-DMA АТА. В случае использования производительного интерфейса массового хранения АТА обратитесь к производителю за самой актуальной версией драйвера. Эта технология претерпевает постоянные изменения. Кроме этого, убедитесь, что диск подключен к интерфейсному адаптеру с помощью 80-проводного интерфейсного шлейфа. Только такой тип подключения позволяет получить максимальную производительность.
Удалите тома, сжатые с помощью DriveSpace. Удостоверьтесь, что том, на который устанавливалась операционная система, не был сжат с помощью программы DriveSpace или DoubleSpace.
Отсутствие устаревших технологий динамического разбиения на разделы. К отказу программы установки могут приводить утилиты, которые создают собственные скрытые разделы или позволяют динамически менять размер разделов. В операционной системе Windows Server 2003 изменилась версия файловой системы NTFS, что привело к невозможности использования старых версий утилит.
Отсутствующие или некорректные
приводы компакт-дисков
Если операционная система раз за разом предлагает вставить в привод установочный компакт-диск Windows Server 2003, то можно считать, что привод компакт-дисков не поддерживается или настроен неправильно. Воспользуйтесь следующим списком как отправной точкой для устранения проблемы.
Убедитесь, что привод поддерживается. Некоторые приводы компакт-дисков в операционной системе Windows Server 2003 не поддерживаются. Особенно это справедливо для устаревших моделей приводов с собственными интерфейсами. Не поддерживаются некоторые приводы, которые поддерживались в операционной системе Windows NT 4.0. Как и в случае с другими компонентами оборудования, убедитесь, что привод компакт-дисков указан в списке HCL.
Проблемы с временем доступа. Приводы компакт-дисков, которые работали под управлением операционных систем DOS/Windows 9х, иногда отказываются работать под управлением операционной системы Windows Server 2003, так как к ним предъявляются высокие требования с точки зрения задержек доступа. Если используется интерфейс SCSI или модифицированный интерфейс SCSI, воспользуйтесь процедурами BIOS для поверки устройства.
Терминаторы SCSI. При использовании привода компакт-дисков с интерфейсом SCSI проверьте список устройств при инициализации контроллера SCSI. Если привод отсутствует в списке, проверьте правильность подключения кабелей питания, интерфейсных кабелей, терминаторов шины и правильность назначения идентификаторов SCSI. Если напротив идентификатора SCSI в списке не отображается название привода или производителя, то, возможно, что привод не поддерживается BIOS контроллера SCSI или работает неправильно.
Конфигурация интерфейса IDE. Если привод компакт-дисков подключен к тому же контроллеру IDE, что и жесткий диск, проверьте правильность настройки основного и/или подчиненного устройства. Проверьте параметры BIOS и убедитесь в том, что соответствующий контроллер IDE включен.
Отсутствующие или неработающие
сетевые адаптеры
Сетевые адаптеры являются частой причиной “зависаний" процесса установки и отказов подсистемы РпР. Воспользуйтесь следующим списком как отправной точкой для устранения проблемы.
Некорректное распределение ресурсов. Используйте Device Manager (Диспетчер устройств) для проверки правильности выделения ресурсов. Если возник конфликт, возле объекта адаптера будет отображаться желтый круг со знаком восклицания или красный круг с символом “X”. Выполните двойной щелчок на пиктограмме сетевого адаптера. Откроется окно Adapter properties (Свойства адаптера). Перейдите на вкладку Resources (Ресурсы).
Некорректное совместное использование ресурсов PCI. Для адаптеров PCI редко возникают конфликты при выделении памяти, но если распределением ресурсов занимается BIOS или библиотека HAL вносит изменения в параметры шины PCI, иногда возникают конфликты с использованием адресов ввода-вывода и конфликты назначения IRQ (запросы прерываний). Если такая проблема возникает в работе устаревшего адаптера, отключите РпР в параметрах BIOS и проведите распределение ресурсов вручную. В данном случае стоит обдумать выделение материальных средств на модернизацию адаптера.
Проверьте физический уровень. Если сетевые драйверы загружаются, а сеть остается недоступной, адаптер может оказаться просто испорченным. Проверьте, можно ли отправить тестовый эхо-пакет на адрес интерфейса обратной петли 127.0.0.1. Такая проверка позволяет убедиться в функционировании стека IP до МАС-драйвера NDIS. Успешное завершение этой проверки предполагает, что контроллер Ethernet работает правильно. В таком случае проблема может быть связана с приемопередатчиком, кабелями и разъемами, а также коммутаторами. Воспользуйтесь заведомо работающим кабелем или проверьте исправность кабеля на другом компьютере. Удостоверьтесь, что не используется перекрестный кабель, в которюм переставлены контакты 1-2 и 3-6. Такой кабель используется для подключения коммутаторов друг к другу.
Неодинаковые настройки дуплексного режима. Очень распространенной проблемой при использовании сетевых адаптеров 10/100 является несовпадение параметров дуплексного режима на адаптерах и коммутаторе. При использовании полнодуплексного режима передачи данных обнаружение конфликтов (collision detection) должно быть отключено. Это позволяет порту коммутатора и сетевому адаптеру одновременно отправлять и принимать данные. Если коммутатор продолжает работать в полудуплексном режиме, полнодуплексная передача будет рассматриваться как конфликт и кадр отбрасывается. Скорость работы сети значительно снижается, а количество ошибок CRC/выравнивания на коммутаторе резко возрастает. Если используется сетевой адаптер 10/100, поддерживающий автоматическую настройку, удостоверьтесь в правильности настроек коммутатора. Не доверяйте индикаторам на передней панели коммутатора. Подключите к этому порту другой компьютер.
Проблемы в работе видеоадаптера
Если программа установки не в состоянии определить производителя и модель видео- - адаптера, будет использован драйвер стандартного адаптера VGA. Проблемы в работе видеоадаптера являются еще одной распространенной причиной “зависаний" программы установки операционной системы. Кроме этого, такие проблемы могут приводить к критическим ошибкам режима ядра. Обратитесь к списку HCL и убедитесь, что видеоадаптер поддерживается операционной системой. Воспользуйтесь следующим списком как отправной точкой для устранения проблемы.
Потеря синхронизации видеосигнала. Если после изменения параметров видеоадаптера изображение исчезает, ничего не делайте. Система автоматически вернется к старым параметрам через 15 секунд. Если этого не произошло, перезагрузите компьютер и нажмите клавишу <Е8> в меню загрузчика. Из раздела Advanced Options (Дополнительные параметры) выберите Safe Mode (Безопасный режим). В этом режиме загружается драйвер стандартного видеоадаптера VGA, что позволяет задать другие параметры работы видеоадаптера или установить другие драйверы. Избегайте использования пункта VGA MODE (Режим VGA). В этом случае также используются драйверы стандартного видеоадаптера, но при этом создаются постоянные записи в системном реестре, а не временные, как в Safe Mode (Безопасный режим).
Невозможность получить доступ ко всем возможностям видеоадаптера. Для обнаружения видеоадаптера и монитора операционная система Windows Server 2003 полностью полагается на подсистему РпР. Если подсистема РпР выбирает неправильный драйвер или драйвер на компакт-диске устарел, то некоторые из вариантов разрешающей способности и качества цветопередачи могут оказаться недоступными. Обратитесь к производителю видеоадаптера за обновленными драйверами.
Утилиты интерактивной отправки отчетов об ошибках
Если в процессе работы возникают ошибки защиты или отказы системы, операционная система собирает информацию об ошибке и отправляет ее компании Microsoft. Эта функциональная возможность предназначена исключительно для сбора статистической информации. Отправка подобного отчета не приведет к звонку из службы поддержки. Дополнительная информация о формате файлов и назначении интерактивной отправки отчетов приводится в главе 3, “Добавление аппаратных средств".
Резюме
Ниже представлен краткий список советов по установке, приведенных в этой главе.
Убедитесь, что система и все ее компоненты перечислены в списке поддерживаемого оборудования HAL (Hardware Compatibility List).
По возможности выполняйте установку на “чистый” компьютер, без установленной операционной системы.
Убедитесь, что скорости центрального процессора, объема оперативной памяти и объема подсистемы хранения достаточно для удовлетворения минимальных требований к аппаратному обеспечению.
Получите актуальные версии всех прошивок, программ BIOS и драйверов.
Для форматирования разделов сервера используйте только файловую систему NTFS.
Смонтируйте диски на всех сменных носителях.
Сначала установите минимальную систему с последующим добавлением необходимых служб.
Для максимальной производительности и надежности используйте аппаратные массивы RAID.
Для удаления всех разделов на динамических дисках воспользуйтесь утилитой fdisk. После этой процедуры динамические диски преобразовываются в базовые.
На компьютерах с альтернативной загрузкой устанавливайте каждую операционную систему Windows в собственный раздел.
Приобретайте операционные системы Windows Server 2003 и Windows ХР на условиях Volume Purchase Agreement, что позволяет избежать активации каждого экземпляра операционной системы.
Для компьютеров на основе архитектуры IA64 необходимо соблюдать порядок создания разделов GPT.
Если’в процессе установки операционной системы возникают проблемы, удалите все пе- риферийные устройства, которые не являются абсолютно необходимыми.
Разместите файл или файлы подкачки страниц на различных дисках, что позволит увеличить производительность. Оставьте небольшой файл подкачки на загрузочном диске для создания дампа стека или кучи (мини-дампа).
Приобретите дисковые утилиты, сертифицированные для работы в операционной системе Windows Server 2003 и Windows ХР (и поддерживающие работу с файловой системой NTFS 5.1).
В следующей главе
Установка любой новой операционной системы любого типа оказывается более простой процедурой, если выполнять ее с “чистого листа”. Процедура модернизации всегда намного сложнее. В следующей главе рассматривается модернизация операционной системы Windows NT 4.0 или Windows 2000 до Windows Server 2003. Кроме этого, рассматривается автоматизированная установка операционной системы Windows Server 2003 с использованием сценариев и службы удаленной установки RIS (Remote Installation Service).
Модернизация и автоматизированная установка
П
одводные камни” модернизации операционной системы на сервере хорошо известны тем, кто переезжал в новый дом. В домах небольшие “щели от усадки” оказываются результатом поражения термитами. По отношению к серверам “редкие" синие экраны критических ошибок оказываются результатом деятельности драйвера контроллера RAID, который (как можно подумать) только и ждет подходящего момента для повреждения данных.
В большинстве случаев значительно лучше и надежнее установить операционную систему на новый компьютер, как рассказывалось в главе 1, “Установка и настройка Windows Server 2003”. Но одно дело — говорить о переустановке операционной системы на каждом сервере организации и совсем другое — потратить дни и даже недели рабочего времени на переустановку. Если сервер под управлением операционной системы Windows NT или Windows 2000 работает стабильно, разумным подходом является модернизация с целью сохранения параметров существующих приложений.
В этой главе описаны способы экономии времени при развертывании операционной системы Windows Server 2003. Рассматриваются модернизация существующих серверов и автоматизация установки с помощью сценариев, дисковых образов, а также комбинации этих способов. В главе приводится обзор процесса модернизации операционных систем Windows NT 4.0 и Windows 2000, а также описывается пошаговая процедура модернизации.
Новые возможности операционной системы Windows Server 2003
В этой главе рассматриваются новые возможности операционной системы Windows Server 2003, которые относятся к поддержке автоматизированной установки.
Диспетчер установки (Setup Manager). Эта утилита используется для создания сценариев автоматической установки. Усовершенствования этой утилиты, доступные в операционной системе Windows Server 2003, упрощают создание сценариев и поддерживают шифрование пароля локального администратора Кроме этого, утилита может использоваться для создания сценариев установки для служб удаленной установки RIS (Remote Installation Services) и сценариев мини-установки, которые используются совместно с утилитой sysprep.
Улучшения в работе утилиты sysprep. Несколько улучшений в утилите sysprep позволяют выполнять модификацию базового образа sysprep с помощью установки оригинального пакета, внесения изменений и повторной упаковки пакета. Также предоставляется возможность управления операциями по настройке устройств РпР.
Службы удаленной установки (Remote Installation Services — RIS). Улучшения для служб RIS включают в себя поддержку серверов RIS и более широкие возможности создания сценариев RIS.
Работа сервера без локальной консоли. Можно устанавливать операционную систему Windows Server 2003 на компьютер без клавиатуры, мыши и видеоадаптера. Такая функциональная возможность позволяет просматривать консоль запуска и экран критической ошибки после отказа системы, что невозможно при использовании Remote Desktop (Удаленный рабочий стол) или программ удаленного управления.
Обзор процесса модернизации операционной системы Windows NT 4.0
При модернизации операционной системы Windows NT 4.0 до Windows Server 2003 от программы установки можно ожидать следующих действий.
Сохранения идентификатора безопасности (Security ID) компьютера и членства компьютера в домене.
Преобразования пользовательских профилей в формат Windows Server 2003. Профили не перемещаются и остаются в каталоге \Winnt\Prof lies, хотя в операционной системе Windows Server 2003 профили обычно хранятся в каталоге \Documents and Settings. Новые профили также создаются в каталоге \ winnt \ Profiles.
Сохранения параметров приложений и драйверов в системном реестре, если параметры совместимы с операционной системой Windows Server 2003.
Удаления записей приложений и драйверов из системного реестра, несовместимых с новой операционной системой.
Сохранения содержимого баз данных SAM и LSA на изолированных серверах и рабочих станциях, а также на компьютерах, входящих в домен. Это позволяет сохранить локальных пользователей и членство в группах, а также параметры безопасности, назначенные этим учетным записям.
Для основных контроллеров домена (Primary Domain Controller — PDC) Windows NT — копирования содержимого баз данных SAM (Security Account Manager) и Security в базу данных Active Directory. После модернизации резервные контроллеры домена (Backup Domain Controller) игнорируют собственную копию базы данных SAM и выполняют репликацию базы данных Active Directory с обновленного PDC.
Сохранения существующих параметров безопасности файловой системы NTFS, а также параметров безопасности системного реестра. Это означает, что на модернизированном сервере будут отсутствовать дополнительные ограничения безопасности, которые обычно применяются в операционной системе Windows Server 2003.
Сохранения существующих разделов FAT. При желании такие разделы можно преобразовать в файловую систему NTFS. В отличие от предыдущих версий операционная система Windows Server 2003 сохраняет размер кластера файловой системы FAT и после преобразования (если размер кластера не превышает 4096 байт).
Преобразования существующих разделов NTFS для использования файловой системы NTFS версии 3.1 (в операционной системе Windows 2000 применялась файловая система версии 3.0, а в операционной системе Windows NT 4.0 применялась файловая система NTFS версии 1.2). Необходимо обновить утилиты работы с дисками, предназначенные для дефрагментации, создания образов и управления разделами, до версий, совместимых с операционной системой Windows Serve 2003.
Модернизации драйверов сетевых адаптеров в соответствии со спецификацией ND IS (Network Driver Interface Specification — спецификация стандартного интерфейса сетевых адаптеров) версии 5.1, если такие драйверы доступны. При этом должны быть сохранены параметры транспортного драйвера, адреса IP и IPX, подключения дисков и принтеров, а также конфигурации удаленного доступа. Если новые драйверы недоступны в составе операционной системы, программа установки запросит новые драйверы у администратора и продолжит установку без сетевой подсистемы, если такие драйверы не будут предоставлены.
Модернизации таких служб, как DNS, DHCP, WINS, Internet Explorer (IE), IIS, Services for Macintosh (SFM), Certificate Services и т.д. При модернизации сохраняются все параметры служб, кроме тех случаев, когда параметры несовместимы с операционной системой Windows Server 2003. Интерфейсы управления модернизируются до оснасток ММС.
Модернизация операционной системы
Windows 2000
При модернизации операционной системы Windows 2000 до Windows Server 2003 от программы установки можно ожидать следующих действий.
Сохранения пользовательских профилей и места хранения этих профилей одновременно с модернизацией командного интерпретатора для получения нового интерфейса, характерного для операционной системы Windows Server 2003. Оболочка практически идентична оболочке старой версии,
Сохранения параметров приложений и драйверов в системном реестре при условии их совместимости с новой версией операционной системы.
Сохранения записей базы данных LDM (Logical Disk Manager) для всех динамических дисков.
Сохранения параметров доступа к файлам в файловой системе NTFS, а также разрешений доступа к системному реестру, заданных в операционной системе Windows 2000. Эти параметры несколько отличаются от параметров, принятых по умолчанию в операционной системе Windows Server 2003. Дополнительная информация приводится в главе 15, “Управление файловыми системами”.
Модернизации существующих разделов NTFS 3.0 до версии 3.1. В новой версии формат записей изменился, что делает файловую систему несовместимой с утилитами работы с дисками и образами, созданными для работы в операционной системе Windows 2000.
Модернизации Internet Explorer до версии 6.0 одновременно с модернизацией медиаслужб, которые взаимодействуют с Internet Explorer.
Модернизации IIS до версии 6.0. Основным преимуществом новой версии является полное изменение служб, на которых основано это приложение. При этом принимались во внимание требования по разделению процессов и усилению безопасности.
Перехода сетевых интерфейсов на драйвер NDIS 5.1. Эта версия поддерживает более эффективное управление устройствами, более эффективно использует память и поддерживает беспроводные адаптеры IEEE 802.11b.
Варианты модернизации
Операционная система Windows Server 2003 версий Standard Edition и Enterprise Edition не поддерживает модернизацию операционных систем Windows Эх, Windows ME и любой версии WindowsNT Professional (4.0, 3.51, 3.50). Ниже приводятся доступные методы модернизации этих систем.
Модернизация операционных систем Windows NT 3.1, Windows NT 3.51 и Windows NT 3.50 выполняется в два этапа. Сначала выполняется модернизация до WindowsNT 4.0, после чего выполняется модернизация до Windows Server 2003.
Поддерживается непосредственная модернизация до Windows Server 2003 перечисленных далее версий операционной системы Windows NT 4.0 (для всех версий требуется установка Service Pack 6а).
Windows NT 4.0 Server. Эта версия поддерживает модернизацию до Windows Server 2003, Standard Edition или Windows Server 2003, Enterprise Edition. Модернизация до Windows Server 2003 Web Edition не поддерживается.
Windows NT 4.0 Server, Enterprise Edition. Для сохранения всех функциональных возможностей требуется модернизация до Windows Server 2003, Enterprise Edition.
Windows NT 4.0 Server, Terminal Services Edition. При использовании Citrix MetaFrame непосредственная модернизация до Windows Server 2003 невозможна. Сначала необходимо удалить программу MetaFrame, выполнить модернизацию и уже после модернизации установить современную версию MetaFrame. Дополнительная информация приводится на сайте компании Citrix по адресу www. citrix. com.
Windows NT 4.0 Small Business Server. Поддерживается модернизация до Windows Server 2003, Small Business Server Edition с момента появления этого продукта на рынке. При этом сохраняется доступ ко всем службам с ограничением в 50 пользователей. Также поддерживается модернизация до полной версии Windows Server 2003 и BackOffice.
Все возможности Windows NT 4.0 Option Pack встроены в базовую версию Windows Server 2003. Это справедливо и для служб маршрутизации и удаленного доступа (Routing and Remote Access Service — RRAS) Windows NT 4.0, хотя эти возможности реализованы иначе и управление коммутируемыми соединениями претерпело серьезные изменения. Дополнительная информация по этой теме содержится в главе 20, “Управление удаленным доступом и маршрутизацией”.
Условия модернизации
Требования к установке, описанные в главе 1, “Установка и настройка Windows Server 2003”, для установки на “чистую” систему, полностью справедливы и для модернизации. Если в системе присутствует несовместимое оборудование или приложения не сертифицированы для работы в операционной системе Windows Server 2003, следует ожидать проявления проблем. Проведите инвентаризацию оборудования и проверьте его соответствие требованиям HCL. Это особенно важно для старых компьютеров, которые были выпущены до появления второй версии стандарта ACPI.
Резервное копирование
Создание надежной резервной копии сервера перед модернизацией даже не должно требовать отдельного напоминания. К потере данных может привести множество событий. Если на магнитной ленте созданы резервные копии, но в последнее время попыток полного восстановления не предпринималось, сделайте это еще до модернизации. В качестве теста, как минимум, восстановите файл или папку с самой последней ленты.
Если используется утилита или агент резервного копирования от стороннего производителя, удостоверьтесь в их совместимости с операционной системой Windows Server 2003. Восстановление данных на сервере может потребоваться и после модернизации.
Совместимость приложений
В процессе модернизации программа установки проведет сканирование системы на предмет потенциально несовместимого программного обеспечения и драйверов. Это сканирование можно выполнить заранее, запустив из командой строки следующую команду:
winnt32 /checkupgradeonly
Эту команду также можно запустить, просто вставив установочный компакт-диск в привод, подождав открытия окна автозапуска и выбрав Perform Additional Tasks^Check System Compatibility (Выполнить дополнительные задачи1^Проверить совместимость).
При сканировании выполняется приведенная ниже последовательность действий.
Утилита связывается с Web-сайтом Microsoft Update для получения дополнений к базе данных совместимости.
Проводится сканирование системы на предмет потенциально несовместимых приложений или драйверов.
Выводятся результаты сканирования и предоставляется возможность их сохранения в файле.
Не все потенциально несовместимые приложения обнаруживаются при сканировании. Не стоит предполагать, что нормально работающее под управлением операционной системы Windows NT 4.0 приложение будет так же хорошо работать и под управлением операционной системы Windows Server 2003. Обратитесь за поддержкой к производителю и проведите полное внутреннее тестирование. Дополнительная информация о запуске устаревших приложений в операционной системе Windows Server 2003 приводится в разделе “Проверка совместимости приложений” далее в этой главе.
Свободное пространство
Для модернизации в разделе операционной системы должен быть минимум 1 Гбайт свободного дискового пространства. Если модернизация выполняется по сети, добавьте еще 400 Мбайт для хранения временных файлов.
Программа установки определяет объем необходимого дискового пространства, используя записи в файле SIF (Setup Information File) txt setup, sif, и хранится в каталоге \I3 86 на установочном компакт-диске. Записи расположены в разделе [DiskSpaceRequirements]. Размер необходимого дискового пространства отличается в зависимости от размера кластера, который используется в файловой системе системного раздела.
Дефрагментация системного раздела
И при использовании в системном разделе файловой системы NTFS, и при использовании файловой системы FAT необходимо выполнить полную дефрагментацию раздела перед модернизацией операционной системы. Программа установки создает большое количество временных файлов, меняя практически каждый файл операционной системы. Это приводит к фрагментации даже в самых идеальных условиях.
Если файл подкачки расположен в системном разделе, переместите его на другой диск (если в системе присутствует еще один диск). Это позволит уменьшить время фрагментации системного раздела.
Если системный раздел использует файловую систему FAT и рассматривается возможность перехода на файловую систему NTFS, отложите переход до завершения модернизации.
Это позволит выполнить преобразование более совершенными средствами. Кроме этого, можно воспользоваться новой возможностью утилиты convert, которая обеспечивает хранение данных во временнрй области на другом диске во время перехода, и уменьшить фрагментацию главной файловой таблицы MFT (Master File Table). Дополнительная информация приводится в главе 15, “Управление файловыми системами”.
Удалите программные массивы RAID Windows NT 4.0
В отличие от Windows 2000, операционная система Windows Server 2003 не поддерживает классические отказоустойчивые дисковые массивы Windows NT (также эти массивы часто называют массивами дисков FT или массивами Ftdisks; название происходит от названия драйвера Windows NT 4.0, который используется для управления программными массивами дисков).
Если системный раздел операционной системы Windows NT 4.0 в данный момент расположен на зеркалированном диске, перед модернизацией зеркало придется уничтожить. Если этого не сделать, программа установки откажется запускаться. После модернизации диски можно преобразовать в динамические и создать зеркало заново.
Если в системе используются и другие массивы дисков FT, например массивы с чередованием, массивы с чередованием и четностью и тома, то перед модернизацией необходимо выполнить резервное копирование данных и удалить такие массивы. Диск в составе массива не может быть преобразован в динамический диск. Удостоверьтесь, что утилита резервного копирования совместима с операционной системой Windows Server 2003. В противном случае восстановление данных окажется невозможным.
Если используется зеркалированный системный раздел операционной системы Windows 2000, перед модернизацией зеркало необходимо уничтожить. После модернизации зеркало можно будет создать повторно. В процессе модернизации база данных диспетчера логических дисков LDM (Logical Disk Manager) сохраняется, и преобразование в базовые диски (с удалением всех томов) не требуется.
Отключите последовательные подключения к блокам бесперебойного питания
Диспетчер устройств Plug-and-Play (Plug-and-Play Manager) в операционной системе Windows Server 2003 в процессе модернизации пытается провести инвентаризацию всех устройств на всех шинах. Этот диспетчер не в состоянии правильно определить блок бесперебойного питания, подключенный к последовательному порту. Это может привести к “зависанию” программы установки на несколько часов. Отключите кабель от последовательного порта до начала модернизации. Удаление службы UPS не требуется, так как она будет модернизирована.
Удалите программы антивирусного сканирования
Программа установки вносит значительные изменения в системные файлы, а также меняет загрузочный сектор раздела. Программы антивирусного сканирования расценивают такое поведение, как атаку, и пытаются вмешаться.
Лучше удалить такие программы, а не просто отключить. Это гарантированно не даст программе сканирования запуститься в процессе завершения модернизации и вмешаться в работу системы. Если антивирусная программа совместима с операционной системой Windows Server 2003, ее можно заново установить после завершения модернизации.
Очистка системного реестра
Операционная система Windows Server 2003 вносит в системный реестр значительные изменения. Если в реестре присутствуют несовместимые записи, это может вызвать проблемы в работе программы установки или привести к некорректной работе после модернизации.
Перед модернизацией стоит воспользоваться утилитой очистки системного реестра. Это может быть коммерческая утилита или бесплатная утилита от компании Microsoft — Regclean4.1а. Эта утилита доступна по адресу www.microsoft.com/downloads/release. asp?ReleaseID=18924.
После использования утилиты Regclean можно провести сжатие разделов системного реестра. Для этого можно воспользоваться утилитой от компании Executive Software или утилитой Registry Defragmentation, доступной по адресу www. sysinternals. com.
Назначение букв для дисков
При модернизации системы программа установки пытается сохранить установленные буквы для дисков. В зависимости от типа диска для этого используется два источника информации.
■ Базовые диски. Буквы дисков для разделов на базовых дисках сохраняются в разделе системного реестра HKLM\System\Mounted Devices. В этом разделе хранится информация о буквах, назначенных логическим дискам внутри расширенного раздела. При модернизации важные элементы системного реестра копируются в однородный файл, который называется migrate, inf. В итоге,этот файл превращается в файл сценария программы установки операционной системы Windows Server 2003. Перечень установленных для дисков букв является одним из элементов этого файла.
■ Динамические диски. Управление динамическими дисками возложено на службу диспетчера логических дисков (Logical Disk Manager — LDM). Служба LDM хранит свою базу данных в конце каждого динамического диска. Эта база данных описывает конфигурацию каждого динамического диска на компьютере (зеркалированный, с чередованием RAID 5 и т.д.). Также в базе данных хранится информация о буквах, назначенных каждому тому. Программа установки в состоянии прочесть базу данных LDM и пытается сохранить сохраненное в базе данных назначение букв для дисков.
“Горячие исправления”
В ответ на актуальные проблемы совместимости аппаратных средств и при появлении новых типов атак через Интернет компания Microsoft выпускает “горячие исправления” (hotfix). Часто такие исправления выпускаются в течение нескольких часов после обнаружения проблемы. Скорость выпуска исправлений не оставляет времени на всеобъемлющее тестирование операционной системы и приложений.
Иногда возникают ситуации, в которых “горячее исправление” становится источником проблем во время модернизации до Windows Server 2003. Перед модернизацией зайдите на сайт компании Microsoft и на сайт Technet и проверьте нет ли сообщений о проблемах, связанных с конкретным исправлением. После модернизации можно воспользоваться службой Windows Update для автоматической загрузки и подготовки исправлений к установке.
Подготовка к возможным остановкам служб
При модернизации сервера, поддерживающего работу большого количества сетевых служб, стоит создать копию сервера, который будет поддерживать хотя бы некоторые из этих служб на. время процедуры модернизации. Небольшая ошибка в процессе модернизации может сделать сервер недоступным в течение длительного периода времени.
Перемещение служб может потребовать определенных усилий, связанных с изменением IP-адреса на клиентских компьютерах. Именно поэтому стоит создать сервер с таким же именем и такими же службами, отключенный от сети, пока не начнется процедура модернизации первого сервера. Если возникла необходимость в использовании резервного сервера, удалите старый сервер из домена и добавьте в домен новый сервер, что позволит получить новую учетную запись компьютера.
Модернизация операционной системы Windows NT 4.0 или Windows 2000 Server
В этом разделе рассматривается процесс модернизации. Здесь подробно описываются последовательность действий и происходящее с сервером. Прочитав этот раздел, администратор сможет подготовиться к потенциальным проблемам и провести диагностику проявившихся неисправностей. Модернизация проводится в два этапа.
Начальная оценка. На этом этапе утилита управления установкой операционной системы Windows Server 2003 winnt32 . ехе запрашивает у пользователя информацию о будущем сервере и собирает в системном реестре информацию о текущем экземпляре операционной системы. Результатом работы утилиты на этом этапе модернизации является SIF-файл, который называется winnt. sif и используется в качестве сценария установки.
Реализация модернизации. На этом этапе программа установки выполняет копирование компонентов в соответствии с файлом сценария winnt.sif и-еодержимым системного реестра.
Операционная система поддерживает запуск программы модернизации с установочного компакт-диска или с сетевого диска. Если для модернизации используется установочный компакт-диск, на жесткий диск Копируются только те файлы, которые необходимы для завершения модернизации. Файлы копируются в каталог \$win_nt$ . -bt. Это те же файлы, которые используются для загрузки программы установки с компакт-диска. Объем файлов составляет 6 Мбайт.
Если для модернизации используется сетевой диск, утилита winnt3 2 копирует с сетевого диска на локальный жесткий диск файлы программы установки и все файлы операционной системы. Файлы копируются в каталог \$win_nt$ . - Is. По умолчанию этот каталог расположен в системном разделе. Кроме свободного дискового пространства, необходимого для модернизации, на диске должно быть еще 300 Мбайт свободного дискового пространства для хранения этого каталога.
Начальная оценка
Для проведения модернизации необходимо обладать правами администратора. Если сервер является членом домена, администратор должен быть зарегистрирован в домене, а не в локальной базе данных SAM. Это позволяет обеспечить полный доступ ко всем файлам NTFS и разделам системного реестра. После регистрации следуйте процедуре 2.1.
Процедура 2.1. Начальная оценка при модернизации Windows NT 4.0
Вставьте установочный компакт-диск Windows Server 2003 в привод. Автоматически запустится приложение setup , ехе. Название утилиты может ввести в заблуждение. Эта программа просто управляет установочным компакт-диском Windows Server 2003. На самом деле процедура модернизации выполняется утилитой winnt 3 2.
Чтобы начать модернизацию, щелкните на ссылке Install Microsoft Windows Server 2003 (Установить Microsoft Windows Server 2003). Программа установки запустит утилиту winnt32 . ехе. Откроется экран приветствия Windows. На этом экране предоставляется два варианта выбора: Upgrade (Модернизация) и New Installation (Новая установка).
При выборе варианта Upgrade to Windows Server 2003 (Модернизация до Windows Server 2003) собирается информация о текущей операционной системе. Эта информация и используется для создания сценария установки Windows Server 2003.
При выборе варианта New Installation (Новая установка) начинается полная установка операционной системы, описанная в предыдущей главе. Если указать программе установки другой раздел, будет создана конфигурация системы с двойной загрузкой.
Щелкните на кнопке Next (Далее). Отображается окно с лицензионным соглашением. На этом экране можно только щелкнуть на кнопке I Accept This Agreement (Я принимаю это соглашение). Утилита winnt32 не позволит продолжить модернизацию, если администратор не принял лицензионного соглашения.
Щелкните на кнопке Next (Далее). Откроется окно Product Key (Ключ продукта). Введите ключ продукта, являющийся последовательностью из 25 символов, записанной на коробке компакт-диска. Позднее служба активации продуктов Windows (Windows Product Activation — WPA) создаст комбинацию из ключа продукта и идентификатора установки, сгенерированного на основе установленного аппаратного обеспечения сервера, и отправит эту информацию компании Microsoft для получения идентификатора подтверждения (Confirmation ID), который активизирует установленный экземпляр (WPA не используется вместе с продуктами, полученными по Master License или на основе Volume License Agreements).
Щелкните на кнопке Next (Далее). Если компьютер подключен к Интернету, откроется окно Performing Dynamic Update (Выполнить динамическое обновление). Щелкните на кнопке Yes (Да) для подключения к сайту Windows Update и загрузки актуальных файлов программы установки. На этой стадии модернизации проводится сканирование готовности системы к модернизации. Если в системе обнаружены несовместимые драйверы или программное обеспечение, эта информация предоставляется администратору утилитой winnt32. В таком случае стоит прервать процедуру модернизации и удалить приложения перед продолжением модернизации.
Если в момент модернизации компьютер не подключен к Интернету, откроется окно Directory of Applications (Каталог приложений). В этот момент администратор может подключиться к Интернет и просмотреть главную базу данных совместимости приложений на сайте компании Microsoft.
Щелкните на кнопке Next (Далее). Утилита Winnt32 скопирует загрузочные файлы Windows Server 2003 в каталог \$win_nt$ . -bt, который находится в корневом каталоге загрузочного раздела. Кроме этого, утилита Winnt32 вносит изменения в файл boot. ini для включения указанного каталога в список доступных для загрузки пунктов с использованием загрузочного сектора bootsect.dat. В этом загрузочном секторе содержится выполняемый код для следующей фазы модернизации, которая начинается после перезагрузки.
Реализация модернизации
После перезагрузки программа установки действует без вмешательства пользователя. Второй этап состоит из четырех стадий.
Установка устройств. Программа установки выполняет инвентаризацию устройств РпР и копирует необходимые драйверы с компакт-диска или из каталога \$win_nt $ . -1 s.
Установка сети. Программа установки выполняет дополнительное сканирование сетевых устройств и протоколов, после чего устанавливает и инициализирует соответствующие драйверы.
Установка компонентов. Для выбора компонентов и драйверов программа установки использует сценарий winnt. si f из системного реестра Windows NT 4.0.
Завершающие задачи. Программа установки устанавливает меню Start (Пуск), регистрирует компоненты, сохраняет окончательные параметры и Удаляет временные файлы.
После завершения модернизации проводится последняя перезагрузка компьютера, после которой на компьютере можно зарегистрироваться. Членство компьютера в домене будет таким же, как и до модернизации, поэтому для регистрации можно будет воспользоваться стандартными данными учетной записи.
Модернизация до версии Windows Server 2003 R2
R2 представляет собой обновление, которое устанавливается поверх Windows Server 2003 Service Pack 1. В комплект входят два компакт-диска; один из них содержит все компоненты R2, а на другом Microsoft разместила свой Windows Server 2003 SP1.
После установки в привод второго компакт-диска (R2) выполняются следующие задачи.
Обновляется окно Add or Remove Windows Components (Мастер компонентов Windows) с целью добавления в него возможности выбора новых функциональных возможностей Windows Server 2003 R2..
Обновляется диалоговое окно настройки сервера Manage Your Server и окно мастера Configure Your Server. Среди доступных ранее ролей появляется еще одна, позволяющая ввести в действие новые возможности R2.
Консоль ММС (Microsoft Management Console — управляющая консоль Microsoft) обновляется с версии 2.0 до версии 2.1/3.0 (компания Microsoft использует эти номера версий . как взаимозаменяемые). Дополнительная информация о новых возможностях ММС 3.0 доступна во врезке “Управляющая консоль ММС 3.0”.
На рабочем столе создается ярлык для документа, в котором хранится информация с описанием новых возможностей Windows Server 2003 R2.
Управляющая консоль ММС 3.0
Оснастки, разработанные для ММС 3.0, имеют более богатые функциональные возможности. Кроме того, следующие усовершенствования доступны при использовании всех оснасток с ММС 3.0.
Action рапе (Панель действий) отображается в правой части оснастки. Она содержит список доступных в данный момент действий, основанный на том, какие выбраны объекты в дереве или на Results Рапе (Панель результатов).
' Чтобы отобразить или скрыть панель действий, щелкните на кнопке Show/Hide Action Рапе (Отобразить/скрыть Панель действий), которая находится на панели инструментов и похожа на кнопку Show/Hide Console Tree (Отобразить/скрыть дерево консоли).
Новое диалоговое окно Add or Remove Snap-in (Добавить или удалить оснастку). Новое диалоговое окно упрощает добавление, упорядочивание и удаление оснасток. Вы можете определять, какие оснастки доступны и следует ли автоматически включать оснастки, которые могут быть установлены позднее. Можно вкладывать оснастки друг в друга и перемещать их в дереве.
Улучшенная обработка ошибок. ММС 3.0 уведомляет об ошибках в оснастке, которые могут вызвать сбой в работе консоли, а также предлагает несколько вариантов действий при наличии таких ошибок.
Сценарии установки Windows Server 2003 R2
Существует пять основных сценариев установки Windows Server 2003 R2, и все они сводятся к выполнению трех правил.
Последовательно должна быть выполнена установка следующих компонентов.
la) Windows Server 2003 (с исходного дистрибутива или первого диска R2)
16) Windows Server 2003 Service Pack 1 (вместе с n. la в случае интегрированного дистрибутива или отдельно из другого источника)
1 в) Windows Server 2003 R2 (со второго диска R2)
Пп. 1а и 16 могут быть выполнены одновременно в случае использования интегрированного дистрибутива. Его можно как подготовить самостоятельно, так и использовать в уже готовом виде.
Если в п. 1а был указан ключ для Windows Server 2003 (без поддержки R2), то ключ для R2 будет затребован в п. 1в.
2 а) Если в п. 1а используется интегрированный дистрибутив с SP1 или первый диск из дистрибутива R2, то можно сразу указать ключ для R2.
2 6) Если в п. 1а используется интегрированный дистрибутив с SP1 или первый диск из дистрибутива R2, то можно указать ключ для Windows Server 2003 (без поддержки R2).
2 в) Если в п. 1а используется дистрибутив без SP1, то можно указать ключ только для Windows Server 2003 (без поддержки R2).
Ключ для Windows Server 2003 R2 должен совпадать по изданию и типу лицензии с дистрибутивом, использовавшимся в п. 1а.
В табл. 2.1 показаны возможные последовательности действий при установке и модернизации системы до версии Windows Server 2003 R2 (одна строка — один сценарий; переходить между строками по вертикали нельзя, следующий этап начинается на той же строке, где был предыдущий)).
Таблица 2.1. Сценарии установки Windows Server 2003 R2
Этап установки
Сценарий установки
1 а
1 б
1 в
Windows Server 2003
SP1
R2
2а
Используется ключ для R2
Используется интегрированный дистрибутив Windows Server 2003 с SP1 или первый диск из дистрибутива R2
После того, как обычная установка будет завершена, войдите в систему. Вас попросят вставить второй диск или указать другое расположение установочных файлов. Ввод ключа не потребуется, так как ключ для R2 уже был указан в п. 1а
26
Установка с нуля или модернизация с Windows МТ/ Windows 2000
2 в
Используется дистрибутив Windows Server 2003 без интегрированного SP1
Установите SP1 из любого источника
Используйте второй диск из дистрибутива R2 и укажите серийный номер для R2, соответствующий типу лицензии вашей установленной Windows
26
Обновление установленной Windows Server 2003
Использовался дистрибутив Windows Server 2003 с интегрированным SP1
Окончание табл. 2.1
Сценарий установки
1 а Windows Server 2003
Этап установк
1 б
SP1
и
1 в
R2
2 в
(Этот этап уже выполнен)
Если SP1 еще не установлен, установите его
Проверки после модернизации
После регистрации убедитесь в работоспособности всех служб, которые работали под управлением операционной системы Windows NT 4.0. Для этого можно воспользоваться оснасткой Services (Службы). Проще всего для открытия этой оснастки ввести в командной строке services.msc. Также можно воспользоваться меню Start (Пуск) и выбрать Start1* Programs1*Administrative Tools1*Services (Пуск1*Программы1*Администрирование1*Службы).
Если перед модернизацией часть служб была отключена, включите эти службы и проверьте их работоспособность. Удостоверьтесь, что служба совместима с операционной системой Windows Server 2003, иначе система будет работать с ошибками.
Убедитесь, что уже запущенные службы работают без ошибок. Для этого воспользуйтесь Event Log (Журнал событий). Откройте оснастку Event Viewer (Просмотр событий) из меню Administrative Tools (Администрирование) или введите eventvwr.msc в командной строке. Допускается наличие нескольких предупреждений, но критических ошибок быть не должно.
Проверка совместимости приложений
Теперь пришло время проверить работоспособность приложений, установленных на сервере. Если будет найдено приложение, отказывающееся работать под управлением операционной системы Windows Server 2003, можно попытаться запустить это приложение с помощью Application Compatibility Tool, apcompat. Эта утилита устанавливается отдельно. Установочный пакет Act20 находится на установочном компакт-диске Windows Server 2003 в каталоге \ Support\Tools. На рис. 2.1 показано окно программы apcompat.
Start the Ымпд froe«m
JcAprogrem fifes 1оИарр.екеJcAprogrem fifes 1оИарр.екеOpening vtwn<~ Vrxiowt jOOO Г Wrdow«T4SP3 Г Window NT4Sf4Opening vtwn<~ Vrxiowt jOOO Г Wrdow«T4SP3 Г Window NT4Sf4Г wkdowHT4SP5<* w«xbw»ae WindowiSГ wkdowHT4SP5<* w«xbw»ae WindowiS
JcAprogrem fifes 1оИарр.еке
JcAprogrem fifes 1оИарр.еке
Opening vtwn
<~ Vrxiowt jOOO Г Wrdow«T4SP3 Г Window NT4Sf4
Opening vtwn
<~ Vrxiowt jOOO Г Wrdow«T4SP3 Г Window NT4Sf4
Г wkdowHT4SP5
<* w«xbw»ae WindowiS
Г wkdowHT4SP5
<* w«xbw»ae WindowiS
lf»»^»egмmdoesnoln^n|»ope*лetedcneol^w^lllowllg, check,f7 Bn*l«H«epMerngemWhdww2IXB,P 8йцвй!Й!>^1 t ,P Cgeea*k«pac»*<edtinfo<2-G8»dA««lf»»^»egмmdoesnoln^n|»ope*лetedcneol^w^lllowllg, check,f7 Bn*l«H«epMerngemWhdww2IXB,P 8йцвй!Й!>^1 t ,P Cgeea*k«pac»*<edtinfo<2-G8»dA««Г M*»*i*ewcleokboiie*gipmei«n*tГ M*»*i*ewcleokboiie*gipmei«n*ti ok i gm t »li ok i gm t »lPuc. 2.1. Программа Application Compatibility используется для запуска приложений, для которых требовались особые функции предыдущей версии операционной системыPuc. 2.1. Программа Application Compatibility используется для запуска приложений, для которых требовались особые функции предыдущей версии операционной системы
lf»»^»egмmdoesnoln^n|»ope*лetedcneol^w^lllowllg, check,
f7 Bn*l«H«epMerngemWhdww2IXB,
P 8йцвй!Й!>^1 t ,
P Cgeea*k«pac»*<edtinfo<2-G8»dA««
lf»»^»egмmdoesnoln^n|»ope*лetedcneol^w^lllowllg, check,
f7 Bn*l«H«epMerngemWhdww2IXB,
P 8йцвй!Й!>^1 t ,
P Cgeea*k«pac»*<edtinfo<2-G8»dA««
Г M*»*i*ewcleokboiie*gipmei«n*t
Г M*»*i*ewcleokboiie*gipmei«n*t
i ok i gm t »l
i ok i gm t »l
Puc. 2.1. Программа Application Compatibility используется для запуска приложений, для которых требовались особые функции предыдущей версии операционной системы
Puc. 2.1. Программа Application Compatibility используется для запуска приложений, для которых требовались особые функции предыдущей версии операционной системы
Если удалось обнаружить режим работы приложения, в котором приложение способно работать, с помощью флажка Make Permanent (Зафиксировать) можно зафиксировать параметры системного реестра.
Программа apcompat позволяет найти решение в ситуациях, когда разработчик приложения жестко закодировал в приложении определенную версию Windows. Эта программа не обеспечивает приложению возможность получать непосредственный доступ к аппаратным средствам (это запрещено во всех операционных системах семейства Windows NT), и приложению не разрешается запускать библиотеки VxD. Дополнительные рекомендации по использованию расширенных возможностей программ из пакета Act20 для обеспечения совместимости приложений представлены в главе 19, “Управление операционной средой пользователя”.
Проверки безопасности
Одной из последних операций во время полной установки или модернизации является установка разрешений на доступ к системному реестру и доступ к файлам в файловой системе NTFS. Шаблоны для установки этих разрешений содержатся в каталоге \Windows\Inf. Конкретные разрешения описываются в следующих файлах.
defltdc.inf. Стандартные параметры безопасности для контроллера домена.
defirst.inf. Дополнительные параметры безопасности, устанавливаемые для первого контроллера домена в дереве.
dcup.inf. Параметры безопасности, устанавливаемые для контроллера домена после модернизации Windows NT 4.0.
dcupS.inf. Параметры безопасности, устанавливаемые для контроллера домена после модернизации Windows 2000.
defltsv.inf. Стандартные параметры безопасности, которые устанавливаются для сервера.
dsup.inf. Параметры безопасности, устанавливаемые после модернизации сервера под управлением операционной системы любой предыдущей версии до Windows Server 2003.
dsupt.inf. Параметры безопасности, устанавливаемые после модернизации Windows NT 4.0 Terminal Services Edition или сервера Windows 2000, на котором работали службы терминалов в режиме приложений.
Параметры доступа к файловой системе NTFS и системному реестру, которые задаются с помощью этих сценариев, играют важную роль в управлении доступом к серверу или контроллеру домена. Очень важно, чтобы сценарии были выполнены от начала и до конца. Иногда ошибка или внешняя причина заставляет прекратить выполнение сценария до его завершения. В этом случае в журнал событий заносится соответствующая запись.
При использовании этих сценариев можно обнаружить, что жесткие ограничения безопасности Windows Server 2003 при модернизации не устанавливаются. Если модернизированный сервер должен иметь те же ограничения, что и сервер, установленный на новый компьютер, эти параметры доступа можно установить вручную. В главе И, “Безопасность доступа по сети и протокол Kerberos”, приводится дополнительная информация о содержимом шаблонов безопасности и применении этих шаблонов на сервере.
Автоматизированная установка
Windows Server 2003
Компьютеры должны служить человеку, правда? Тогда почему администраторы должны тратить бесконечные часы, повторяя операции по установке и доводя своих помощников до состояния, в котором они окажутся способными помогать? Если приходится устанавливать или модернизировать более одного сервера, можно попытаться автоматизировать процесс. Существует три основных типа автоматизированной установки:
клонирование дисков;
сценарии установки;
службы удаленной установки (Remote Installation Services — RIS)
В этом разделе подробно рассматривается каждый метод.
Клонирование дисков
Из трех методов автоматизированной установки клонирование дисков является самым быстрым. Но этот метод чаще всего приводит к возникновению проблем совместимости из-за различий в аппаратных средствах между сервером, ставшим прообразом, и сервером, на который этот образ устанавливается.
Клонирование имеет смысл при наличии нескольких однотипных рабочих станций, когда одинаковое оборудование используется на многих компьютерах. При установке операционной системы на серверы автор рекомендует более тесно привязываться к конкретной платформе. Однако клонирование диска оказывается исключительно полезным для создания моментальных снимков сервера перед внесением изменений. Если изменение приводит к полету сервера в космос (образно говоря), то, воспользовавшись созданным образом, этот сервер можно быстро восстановить.
Процедура клонирования предполагает использование утилиты создания образа диска (компания Microsoft такой утилиты не предоставляет), которая создает посекторный моментальный снимок содержимого системного диска. Полученный образ сохраняется в файле. Этот образ можно установить на тот же компьютер или на другой компьютер. Если аппаратные средства другого компьютера не слишком отличаются от аппаратных средств первого компьютера, получится идентичная копия операционной системы. Если в аппаратных средствах есть различия, полученная копия может работать необычно. Увидеть пример такого странного поведения можно в фильме Множество (Multiplicity) с Майклом Китоном (Michael Keaton) в главной роли.
Существуют три основные программы для создания дисковых образов:
Norton Ghost от компании Symantec (www. Symantec . com/ghost);
Drive Image Pro от компании PowerQuest (www. powerquest. com/dr iveimagepro);
True Image от компании Acronis (www. acronis . com).'
Все эти продукты поддерживают быстрое создание образа диска, восстановление образа и даже внесение изменений в фрагменты образа, не затрагивая остальных фрагментов.
Проблемы, связанные с созданием образов дисков
Установка операционной системы, основанная на использовании дисковых образов, значительно усложняется, если речь идет о нескольких аппаратных платформах. Благодаря подсистеме Plug and Play операционная система Windows Server 2003 в состоянии справиться с небольшими различиями в наборе периферийных устройств, но малейшие отличия в критических системных компонентах могут привести к отказу установленного образа или к странному поведению такого экземпляра. В число таких критических отличий входят модель центрального процессора, версия прошивки, набор микросхем материнской платы, конфигурация оперативной памяти и версия интерфейса ACPI.
Если изменить один из основных компонентов аппаратной платформы, например материнскую плату, или разместить образ на другом компьютере, диспетчер Plug and Play может не найти допустимого решения и откажется распознавать интерфейсы дисков или оперативную память. Удостоверьтесь, что клонированная конфигурация тестировалась на каждом наборе аппаратных средств, чтобы эта проблема не оказалась неожиданной.
Также применение образов дисков может оказаться затруднительным при использовании розничных версий операционной системы Windows Server 2003, требующих активации конкретного экземпляра. Поскольку образ имеет тот же ключ продукта, что и оригинал, активация нового сервера окажется невозможной. Если планируется развертывать серверы с помощью клонирования дисков, приобретайте операционную систему по лицензии Volume Purchase Agreements.
Создание образов дисков с помощью утилиты sysprep
Части проблем, связанных с несовместимостью аппаратных средств и активизацией продукта, можно избежать, если из образа удалить информацию, связанную с конкретным компьютером. Задача очистки системного реестра от такой информации решается с помощью утилиты sysprep.
Утилита sysprep значительно упрощает и ускоряет создание образа сервера, избавляя от проблем с совместимостью и идентификатором безопасности (Security ID). Далее в этой главе рассматриваются преимущества утилиты sysprep по сравнению с методами установки операционной системы на основе сценариев. Использование этой утилиты позволяет сохранить параметры системного реестра, а также специальные настройки, предназначенные для конкретных серверов.
Утилита sysprep не является панацеей от проблем совместимости аппаратных средств. Если на сервере-прототипе образа sysprep использовалось другое устройство массового хранения, то использование образа приведет к возникновению критической ошибки уровня ядра. Это связано с тем, что операционная система не сможет найти загрузочные файлы.
Утилита sysprep входит в состав пакета deploy. cab, который хранится в каталоге \Sopport\Tools на установочном компакт-диске операционной системы Windows Server 2003. С помощью Windows Explorer (Проводник) можно извлечь эту утилиту из САВ- файла и запустить ее из любого каталога. После запуска утилиты sysprep выводится окно, показанное на рис. 2.2.
Рис. 22. Окно выбора параметров для утилиты System Preparation Tool
Кроме этого, утилиту sysprep можно запустить из командной строки. Для выведения списка доступных параметров введите sysprep /?. Вот пример использования утилиты sysprep:
sysprep -quiet -noreboot -mini -pnp
Эта команда запускает утилиту sysprep без дополнительных сообщений, отключает компьютер без перезагрузки и подготавливает сокращенную программу установки с инвентаризацией устройств РпР во время установки.
Результат работы утилиты sysprep можно использовать для создания образа диска средствами программ Ghost и Drivelmage. Образ содержит полный экземпляр операционной системы Windows Server 2003 и копии всех приложений, которые были установлены при создании образа. Но в системном реестре этого экземпляра операционной системы отсутствует информация, соответствующая конкретной аппаратной конфигурации.
При загрузке сервера с помощью образа, полученного после использования утилиты sysprep, создается новый идентификатор безопасности (Security ID) и сокращенная программа установки начинает сбор данных о текущей аппаратной конфигурации. В образ, созданный с помощью утилиты sysprep, можно добавить сценарий, автоматизирующий сокращенную установку. Дополнительную информацию можно получить в разделе “Установка по сценарию” далее в этой главе.
Аудит образа sysprep
Иногда возникает необходимость проверки правильности конкретного образа sysprep. Ндпример, может быть создано несколько образов для различных типов серверов. В таком случае администратор сталкивается с той же проблемой, что и фермер на птицеферме. Как проверить, есть ли в яйце цыпленок, не разбив яйца и не убив при этом цыпленка?
Эта проблема решается с помощью параметра -nosidgen. Этот параметр позволяет повторно создать образ, сохранив параметры конфигурации, созданные при первом запуске утилиты sysprep. При использовании параметра -nosidgen компьютер можно перезагружать столько раз, сколько необходимо. Доступный в графическом интерфейсе параметр Audit Shutdown, позволяет добиться того же результата.
При аудите образа не стоит менять файлы. При использовании параметра -nosidgen утилита sysprep не проверяет наличие изменений в файлах и системном реестре.
Параметры утилиты sysprep для массового распространения
Производители компьютеров используют утилиту sysprep для создания образов, которые клонируются на сотни систем. Параметр - factory позволяет производителю создать образ с измененными параметрами, предназначенными для определенной модели аппаратных средств.
Параметр -factory зависит от содержимого файла сценария winbom. inf. Чтобы воспользоваться параметром - factory, необходимо вручную создать этот сценарий. Файл интерактивного справочного руководства ref. chm предоставляется вместе с утилитой sysprep и содержит полный список параметров файла winbom. inf и синтаксиса этих параметров. Утилита sysprep выполняет поиск этого файла на гибком диске, и при его обнаружении изменения вносятся в созданный образ.
Параметр -factory позволяет работнику на конвейере (или администратору, создающему множество серверов) с помощью одного образа и нескольких гибких дисков создавать системы с различными параметрами конфигурации.
После запуска утилиты sysprep с параметром -factory можно установить дополнительные драйверы или внести изменения в автоматизированную установку. Для подготовки компьютера к окончательной установке запустите утилиту sysprep с параметром -reseal.
Дополнительные параметры утилиты sysprep
Если планируется создание образа на основе контроллера домена, важно сохранить идентификатор безопасности, который уникально идентифицирует контроллер в пределах домена Active Directory. Для сохранения текущего идентификатора безопасности необходимо воспользоваться параметром -nosidgen.
Если на сервере присутствуют устаревшие аппаратные средства, т.е. сервер не поддерживает стандарт Plug and Play, можно воспользоваться параметром -рпр для принудительного полного сканирования установленных устройств. Не пользуйтесь этим параметром в тех случаях, если на сервере используется современное оборудование, так как при этом увеличивается время работы программы мини-установки.
Ограничения утилиты sysprep
Образ sysprep невозможно создать на основе сервера, который является контроллером домена или членом домена. Подключиться к домену можно в процессе мини-установки при первом запуске компьютера с помощью образа. Для создания полностью автоматизированной установки можно добавить к образу соответствующий сценарий.
На сервере, который используется в качестве основы для образа sysprep, не должно быть зашифрованных файлов. Это ограничение связано с изменением идентификатора безопасности, что сделает недействительными все учетные записи, а значит, и ключи для шифрования файлов.
На конкретном компьютере утилиту sysprep можно запустить только три раза. Это сделано специально, чтобы предотвратить обход процедуры активации с помощью утилиты sysprep после окончания периода, в течение которого активация не требуется.
Сервер не может быть членом кластера. Также сервер не может выступать в роли центра сертификации (Certification Authority). В обоих случаях экземпляру операционной системы требуется информация о компьютере, идентификаторе безопасности и аппаратных средствах. Например, ни один администратор не хотел бы, чтобы с помощью утилиты sysprep был создан клон Certification Authority, который будет использоваться для распространения поддельных сертификатов.
Установка по сценарию
При запуске программы установки в интерактивном режиме администратору приходится отвечать на множество простых вопросов, чтобы программа установки могла перейти к копированию файлов и настройке системы. Создав специальный сценарий с ответами на эти вопросы, можно добиться полностью автоматизированной установки.
Поскольку обычно сервер имеет характерные отличительные свойства (имя, IP-адрес, членство в домене и т.д.), установка операционной системы с помощью сценария на сервер оказывается немного сложнее, чем аналогичный процесс для рабочих станций. Несмотря на это, в сценарий можно включить параметры, идентифицирующие сервер, что позволит администратору прикладывать минимальные усилия при установке серверной операционной системы.
Установка сервера с помощью сценария позволяет обеспечить копирование файлов из единой точки распространения. Если в дальнейшем потребуется установка новой службы, операционная система Windows Server 2003 сможет обратиться к серверу распространения и получить необходимые файлы. Пакеты обновлений операционной системы Windows Server 2003 позволяют интегрировать пакет обновления в установочный образ, хранящийся на сервере распространения файлов. В этом случае пакет обновлений устанавливается совместно с базовой операционной системой. Получить дополнительные сведения по этому вопросу можно в разделе “Интеграция пакета обновлений в установочный образ”.
В процедуре 2.2 приведен краткий список операций при создании сценария автоматической установки и развертывании операционной системы.
Процедура 2.2. Установка с помощью сценария
Создайте сценарий автоматизированной установки, в котором содержатся ответы на вопросы программы установки.
Скопируйте файлы установочного компакт-диска операционной системы Windows Server 2003 в каталог на сервере распространения файлов и сделайте этот каталог общедоступным.
Создайте загрузочный диск, позволяющий клиенту подключиться к сетевому каталогу с установочным образом.
Воспользуйтесь сценарием автоматизированной установки для развертывания операционной системы Windows Server 2003 на нужном сервере.
Создание сценария автоматизированной установки
В этом разделе рассматривается создание сценария автоматизированной установки с помощью утилиты Setup Manager (Диспетчер установки). Эта утилита содержится в сжатом архиве deploy.cab, который хранится в каталоге \Support\Tools на установочном компакт-диске операционной системы Windows Server 2003. Для извлечения файла из архива можно использовать Windows Explorer (Проводник).
Кроме создания сценария установки, утилита Setup Manager (Диспетчер установки) поддерживает автоматизированное создание центра распространения установочных файлов. Для этого утилиту Setup Manager (Диспетчер установки) необходимо запускать на консоли сервера, который будет центром распространения установочных файлов. После разархивирования утилиты переходите к процедуре 2.3.
Процедура 2.3. Использование утилиты Setup Manager для создания сценария автоматизированной установки
Запустите утилиту setupmgr. Откроется окно Setup Manager Wizard (Мастер установки).
Щелкните на кнопке Next (Далее). Откроется окно New or Existing Answer File (Новый или существующий файл). Выберите New (Новый).
Щелкните на кнопке Next (Далее). Откроется окно Type of Setup (Тип установки). Выберите один из вариантов автоматизированной установки.
Unattended Setup (Установка без сопровождения). Позволяет создать текстовый сценарий, который содержит записи параметров текстового и графического этапов установки.
Sysprep Setup (Установка с помощью Sysprep). Предоставляет возможность создать сценарий INF, который позволяет автоматизировать мини-установку, запускающуюся при использовании образа, который был предоставлен утилите sysprep.
Remote Installation Services (RIS) (Удаленные службы установки). Позволяет создать файл SIF, который используется при развертывании образа RIS.
Щелкните на кнопке Next (Далее). Откроется окно Product (Система). Выберите Windows Server 2003 или Windows ХР в зависимости от того, какая операционная система устанавливается (сценарий автоматизированной установки операционной системы Windows Server 2003 отличается от сценария автоматизированной установки операционной системы Windows 2000 и замена одного из этих сценариев другим недопустима).
Щелкните на кнопке Далее (Next). Откроется окно User Interaction (Взаимодействие с пользователем), показанное на рис. 2.3. Выбрав пункт Fully Automated (Полностью автоматически), можно создать сценарий полностью автоматической установки. Если к устанавливаемой операционной системе не предъявляется специальных требований, выбирайте именно этот пункт.
Щелкните на кнопке Next (Далее). Откроется окно Distribution Share (Общедоступный дистрибутив). Выберите Select a New Distribution Share (Выбрать новый). Это позволит скопировать содержимое компакт-диска в общедоступный сетевой каталог.
7. Щелкните на кнопке Next (Далее). Откроется окно Location of Setup Files (Расположение файлов установки). Укажите источник копирования файлов (компакт-диск или другой источник). Возможно выбрать место расположения файлов пригодится при интеграции различных пакетов обновлений в центр распространения файлов по сети.
Ueer Interaction
Select the type of user interaction you want.
You provide defaiJt options in Iha answer Ba. end the end user can change any of them... ■ ■ ■■■
You pnrnde al raqurod antwen in Де answer Be, and the end user it not prsmptadfarthem.-
Г Hidden pages ■ -1■" Г ■ . ; ■ /■■
You provide anwwt fa e*P pages Mae hidden from the and шаг.
Bead or*
; YouprovidaalreqwecfaniwerainlheahswerfiiB. Theandusercansee the options but cannot change diem.
Г qui attended ■'•■ .
^sQ||tiBWiiii№|i^^
norm*, promplxiglhe end user at each page.
<fiack || Cancat |
■Cancel |
Puc. 2.3. Окно User Interaction мастера Windows Setup Manager
8. Щелкните на кнопке Next (Далее). Откроется окно Distribution Share Location (Расположение общедоступного дистрибутива), показанное на рис. 2.4. Введите путь и имя папки, а также имя используемого ресурса. Это необходимо сделать на сервере распространения. Мастер не в состоянии создать совместно используемый ресурс по сети.
Dietribution Share Location
The distribution share contains the ОРК tods, the Windows files, and your configuration sets.
Browse... |
.»LJ2£!
^^liiilfciailili^
distribution share tocation:
|cA*incist«..... .... -
< flack | №> |
Puc. 2.4. Мастер Windows Setup Manager — окно Distribution Share Location
Щелкните на кнопке Next (Далее). Откроется окно License Agreemen (Лицензионное соглашение). Это окно позволяет администратору подтвердить, что автоматизированная установка выполняется в соответствии с лицензионным соглашением. Без этого в сценарии
будет отсутствовать соответствующий параметр и программа установки остановится и выдаст на экран запрос относительно согласия с лицензионным соглашением. Выберите пункт I Accept the Terms of the License Agreement (Я принимаю условия лицензионного соглашения).
Щелкните на кнопке Next (Далее). Мастер завершает свою работу, оставляя открытым окно Setup Manager (Диспетчер установки).
*J_1*1*J_1*1В отличие от предыдущих версий диспетчера установки, в операционной системе Windows Server 2003 предоставляется дерево доступных параметров, что позволяет администратору быстро выбрать интересующие параметры без последовательного просмотра экранов программы установки. Пример нового дерева параметров показан на рис. 2.5.
*J_1*1
*J_1*1
f^ Setup Manager
9» 11*
:-• General SettrigsNww*dOie«*RDisplay Settrig»T me ZoneProduct Kyi to Network SettingsUcensrig Mode: Computer Names Admirnstratof Password: Netwcxkng Components Workgroup or Domain Si -Advanced Settings■ • Windows Components Telephony Regnnal Settings LanguagesBrowser and She! Settrigs I nstalatron FolderInstal Printers Run Once Addrtional Commands:-• General SettrigsNww*dOie«*RDisplay Settrig»T me ZoneProduct Kyi to Network SettingsUcensrig Mode: Computer Names Admirnstratof Password: Netwcxkng Components Workgroup or Domain Si -Advanced Settings■ • Windows Components Telephony Regnnal Settings LanguagesBrowser and She! Settrigs I nstalatron FolderInstal Printers Run Once Addrtional Commands^geriueott jcomparel^geriueott jcomparelwmU»jm Й you iowo these boreswmU»jm Й you iowo these bores
:-• General Settrigs
Nww*dOie«*R
Display Settrig»
T me Zone
Product Kyi to Network Settings
Ucensrig Mode
: Computer Names Admirnstratof Password
: Netwcxkng Components Workgroup or Domain Si -Advanced Settings
■ • Windows Components Telephony Regnnal Settings Languages
Browser and She! Settrigs I nstalatron Folder
Instal Printers Run Once Addrtional Commands
:-• General Settrigs
Nww*dOie«*R
Display Settrig»
T me Zone
Product Kyi to Network Settings
Ucensrig Mode
: Computer Names Admirnstratof Password
: Netwcxkng Components Workgroup or Domain Si -Advanced Settings
■ • Windows Components Telephony Regnnal Settings Languages
Browser and She! Settrigs I nstalatron Folder
Instal Printers Run Once Addrtional Commands
^geriueott jcomparel
^geriueott jcomparel
wmU»jm Й you iowo these bores
wmU»jm Й you iowo these bores
Puc. 25. Окно Setup Manager, в котором показано дерево параметров установки
Для нескольких параметров требуется задать определенные значения, поэтому дерево не поддерживает полностью произвольный доступ. Некоторым параметрам необходимо уделить особое внимание.
■ Параметр Computer Names (Имена компьютеров) позволяет указать имя или заставить программу установки автоматически сгенерировать такое имя. Сгенерированное имя является комбинацией из имени, введенного в окне Personalize This Computer (Идентификация компьютера), дефиса и случайной последовательности символов. Если имя необходимо указать вручную, придется добавить Unattended Difference File (UDF), в котором указывается имя каждого сервера. Имя сервера должно указываться в качестве параметра утилиты winnt или Winnt32 при запуске программы установки.
Параметр Administrator Password (Пароль администратора) позволяет задать пароль локальной учетной записи администратора (рис. 2.6). Диспетчер установки вносит этот пароль в сценарий установки. В операционной системе Windows Server 2003 предоставляется возможность шифрования этого пароля для повышения безопасности. Если шифрование не используется, пароль записывается в сценарий открытым текстом.
Параметр Workgroup or Domain (Рабочая группа или домен) позволяет подключить компьютер к домену. Подключение к домену часто оказывается необходимым, но использование этого параметра открывает брешь в системе безопасности, поскольку данные об учетной записи домена записываются в сценарии открытым текстом. Дополнительная информация содержится во врезке “Подключение к домену при автоматизированной установке”.
i^ Windows Setup Manageri^ Windows Setup ManagerRte N*Rte N*-" General Settings Customize the Software‘ Display Settings TimeZone Providing the Product KeyS Network SettingsLicensing Mode: Computer Names Adrohtettatoc Password Networking Components Workgroup or DomainS Advanced S ettingsh TelephonyRegional SettingsLanguagesBrowser and She! Settings Installation Folder; Instal Printers Run Once Additional Commands-" General Settings Customize the Software‘ Display Settings TimeZone Providing the Product KeyS Network SettingsLicensing Mode: Computer Names Adrohtettatoc Password Networking Components Workgroup or DomainS Advanced S ettingsh TelephonyRegional SettingsLanguagesBrowser and She! Settings Installation Folder; Instal Printers Run Once Additional CommandsChoose howtos* Ite Adwxstratai password on the «neuters you nMtaot*>Choose howtos* Ite Adwxstratai password on the «neuters you nMtaot*>6 U*lh«l*i^A*W»ata|>№»™dnZ7che*w1mamuml
i^ Windows Setup Manager
i^ Windows Setup Manager
Rte N*
Rte N*
-" General Settings Customize the Software
‘ Display Settings TimeZone Providing the Product Key
S Network Settings
Licensing Mode
: Computer Names Adrohtettatoc Password Networking Components Workgroup or Domain
S Advanced S ettings
h Telephony
Regional Settings
Languages
Browser and She! Settings Installation Folder
; Instal Printers Run Once Additional Commands
-" General Settings Customize the Software
‘ Display Settings TimeZone Providing the Product Key
S Network Settings
Licensing Mode
: Computer Names Adrohtettatoc Password Networking Components Workgroup or Domain
S Advanced S ettings
h Telephony
Regional Settings
Languages
Browser and She! Settings Installation Folder
; Instal Printers Run Once Additional Commands
Choose howtos* Ite Adwxstratai password on the «neuters you nMtaot*>
Choose howtos* Ite Adwxstratai password on the «neuters you nMtaot*>
Pewent
Co*mNwwt< p"™
P Encrypt trimgMtMtapenwQri^
P When»wO«ixl*sterti.Mtaa*lx:*tagoresAd^
Nta**e#6iwi6eutotegon p ^
Puc. 2.6. Окно Administrator Password мастера Windows Setup Manager
После ввода значений всех параметров щелкните на кнопке Next (Далее). Диспетчер установки запросит имя и место хранения сценария автоматизированной установки. По умолчанию сценарий записывается в файл unattend. txt.
Разместите этот файл в каталоге 13 86, в котором хранятся установочные файлы. Если центр распространения файлов создается средствами Setup Manager, то сценарий автоматизированной установки будет скопирован автоматически.
Подключение к домену при автоматизированной установке
Чтобы во время автоматизированной установки компьютер подключить к домену, сначала необходимо создать учетную запись компьютера в Active Directory. Если используется автоматическая генерация имен компьютеров, создание учетной записи компьютера может усложниться, поскольку имя заранее не известно.
Если учетная запись должна создаваться во время автоматизированной установки, то для обеспечения безопасности можно ограничить доступ к каталогу, в котором хранятся установочные файлы, с помощью разрешений файловой системы NTFS. Пользователям должна быть предоставлена возможность запуска файлов из этого каталога, но просмотр содержимого файлов должен быть запрещен.
Еще один вариант заключается в создании учетной записи, для которой предоставлены права на добавление компьютеров к домену. Кроме этого, такая учетная запись не должна иметь никаких административных привилегий. Для обеспечения безопасности стоит периодически менять пароль этой учетной записи.
Третьим вариантом является запуск сценария автоматизированной установки из пакетного файла, вся необходимая информация которого предоставляется специалистом, занимающимся установкой операционных систем.
Операционная система Windows Server 2003 позволяет любому аутентифицированному пользователю подключать компьютер к домену. Но не совершите ошибку, просто введя учетную запись пользователя в сценарий автоматизированной установки. Для учетных записей без привилегий администратора разрешается подключать компьютеры к домену не более десяти раз. После этого данная возможность блокируется для конкретной учетной записи.
Пример сценария автоматизированной установки
Рассмотрим пример сценария автоматизированной установки, созданного средствами мастера установки. Записи, выделенные полужирным шрифтом, заслуживают особого внимания.
;SetupMgrTag
[Data]
AutoPartition=l
MsDosInitiated="0"
UnattendedInstall="Yes"
[Unattended]
UnattendMode=FullUnattended
OemSkipEula=Yes /Это позволяет обойтись без вывода окна с лицензионным соглашением.
OemPreinstall=No
TargetPath=\WINDOWS
DriverSigningPolicy = ignore ; /Добавьте этот параметр вручную для ^отказа от сообщений об ошибках при установке неподписанных драйверов.
[GuiUnattended]
AdminPassword=b267df22cb945e3eaad3b435b51404ee36aa83bdcab3c9 4> fdaf321ca42a31c3fс
BncryptedAdminPassword=Yes / При шифровании используется обратимый пароль.
AutoLogon=Yes ; Параметр позволяет автоматически зарегистрироваться от имени учетной записи Administrator
AutoLogonCount=1 ; Этот параметр позволяет ограничить количествоавтоматических регистраций.
TimeZone=85
OemSkipWe1come=1
[UserData]
FullName=Admin ; He используйте Administrator или Guest 1>в качестве значения этого параметра.
OrgName=Company
ComputerName=* ; Включение автоматического назначения имен для компьютера.
[LicenseFilePrintData]
AutoMode=PerSeat
[Identification]
JoinDomain=Company.com
DomainAdmin=CompAddAccount
DomainAdminPassword=JabBorE# ; Пароль домена открытым текстом.
Ц>Защитите файл средствами файловой системы NTFS.
[Networking]
InstallDefaultComponents=Yes;
Пример пакетного файла для автоматизированной установки
Утилита Setup Manager (Диспетчер установки) создает пакетный файл (batch file), который используется для запуска автоматизированной установки. Клиент подключается к сетевому каталогу с установочными файлами и запускает пакетный файл. Ниже представлен пример такого файла.
@rem SetupMgrTag @echo off
rem
rem Это пример сценария пакетного файла, созданного Setup Manager.
rem При копировании этого файла в другой каталог может rem потребоваться модификация.
rem
set AnswerFile=.\unattend,txt set SetupFiles=\\Sl\netsvrdist
\\Sl\netsvrdist\winnt32 /s:%SetupFiles% /unattend:%AnswerFile%
Этот файл использует утилиту winnt32 (32-разрядная утилита управления установкой). Если клиент подключается к сетевому диску с помощью сетевого загрузочного диска DOS, придется использовать 16-разрядную утилиту управления установкой winnt. В этом случае в командную строку необходимо добавить параметр /Ь, указывающий на отсутствие установочного диска, поддерживающего загрузку, и заменить слово unattend параметром и, как показано ниже: \\Sl\netsrvdist\winnt /Ь /s:%SetupFiles% /u.:%AnswerFile%
Если для установки Windows Server 2003 необходимо указать локальный диск, который отличается от загрузочного диска, принятого по умолчанию, воспользуйтесь этой последовательностью команд:
set AnswerFile=.\unattend.txt set SetupFiles=\\Sl\netsrvdist set TargetDrive=c
\\Sl\netsrvdist\winnt /s:%SetupFiles% /u:%AnswerFile% /t:%TargetDrive%
Модификация сценария автоматизированной установки
Файл сценария автоматизированной установки, сгенерированный средствами диспетчера установки, описывает только базовые драйверы и файлы операционной системы. Если необходимо установить дополнительные драйверы или приложения, придется модифицировать сценарий автоматизированной установки и скопировать необходимые установочные файлы в центр распространения.
Список параметров сценария автоматизированной установки, а также соответствующее описание каждого параметра содержатся в файле помощи deploy.chm, упакованном в архивном файле deploy.cab на установочном компакт-диске в каталоге \Support\Tools. Стоит запомнить стандартные каталоги для размещения файлов с параметрами, а также распространенные параметры для сценариев установки. Вот эти параметры.
$ОЕМ$. Каталог верхнего уровня, в котором хранятся файлы с заданными параметрами. Этот каталог должен быть расположен в корне центра распространения файлов.
$OEM$\Textmode. Этот каталог содержит драйверы и сценарии INF для любых компонентов, которые загружаются во время текстового этапа установки. Например, если контроллер RAID использует драйверы, отсутствующие в поставке Windows Server 2003, то файлы драйвера и сценарий oemsetup. inf должны быть расположены в этом каталоге. Это же относится к файлам ядра ОЕМ-версий.
$ОЕМ$\$$. В этом каталоге содержатся драйверы и файлы, которые должны быть расположены в каталоге %systemroot%. Обычно это каталог С: \ Windows. Например, в этот каталог могут быть скопированы драйверы компонентов, которые отсутствуют в поставке Windows Server 2003. В каталоге $ $ могут содержаться подкаталоги.
$ОЕМ$\$1. В этом каталоге находятся драйверы и файлы, которые должны находиться в корневом каталоге системного диска. Это относится к драйверам, которые должны загружаться до полной инициализации системы. В каталоге $ 1 могут содержаться подкаталоги.
$OEM$\C,D и т.д. В этих каталогах содержатся файлы, которые будут скопированы на различные логические диски после назначения букв для дисков.
Автоматический ввод ключа продукта
Для автоматического ввода ключа продукта (состоящего из 25 символов) можно воспользоваться следующим фрагментом сценария автоматизированной установки: ■
[UserData]
ProductID="aaaaa-bbbbb-ccccc-ddddd-eeeee"
Этот фрагмент можно использовать только в случае, если операционная система приобреталась по лицензии VPA или МРА. В противном случае для успешной активизации для каждого экземпляра сервера придется указывать уникальный ключ.
Автоматическая активация
Возвращаясь к теме активации, можно заметить, что при наличии доступа к Интернет можно провести автоматическую активацию, не требующую вмешательства пользователя. Если компьютер находится за брандмауэром или подключен к прокси-серверу, в сценарии необходимо указать параметры прокси-сервера. Следующий фрагмент сценария автоматизированной установки позволяет автоматически выполнить активацию экземпляра операционной системы:
[Unattended]
AutoActivate=Yes
ActivateProxy=Yes
[Proxy]
Proxy _Enable=l
Use_Same_Proxy=l
HTTP_Proxy_Server=proxy-name:80
Proxy_Override=<local>
Расширение системного раздела
При установке по сети операционной системы Windows Server 2003 программа установки сначала копирует установочные файлы в существующий раздел на локальном жестком диске. Это значит, что для хранения файлов должен существовать подготовленный раздел. Раздел должен быть отформатирован на основе файловой системы FAT или FAT32. Для получения подходящего размера кластера придется создать раздел минимального размера, что для операционной системы Windows Server 2003 составляет около 1,5 Гбайт.
В процессе автоматизированной установки можно расширить этот раздел для предоставления большего дискового пространства для операционной системы. При этом придется воспользоваться файловой системой NTFS (т.е. выполнить преобразование раздела). В сценарии автоматизированной установки должно присутствовать две записи:
[Unattendent]
ExtendOEMPartition=l
FileSyste=ConvertNTFS
Если на компьютере установлен жесткий диск объемом 30 Гбайт, скорее всего, для операционной системы будет выделен не весь объем диска. Указав размер раздела (в мегабайтах), можно ограничить выделяемый операционной системе объем дискового пространства. Вот пример использования такого параметра:
[Unattendent]
ExtendOEMPartition=l 2048
FileSyste=ConvertNTFS
Запуск сценария в процессе автоматизированной установки
Самым простым способом установки приложений во время автоматизированной установки является копирование установочных файлов в подкаталог каталога $ОЕМ$ и запуск пакетного файла и сценария, запускающего автоматическую установку приложений. Для
большинства приложений потребуются похожие (если не одинаковые) фрагменты сценария unattend, txt.
Для автоматического запуска сценарии необходимо разместить в подкаталоге каталога $ОЕМ$, а имена сценариев необходимо указать в файле cmdlines. txt, который должен находиться в каталоге $ОЕМ$.
Файл cmdlines. txt создается вручную. Для того чтобы программа установки прочитала содержимое этого файла, в сценарий автоматизированной установки unattend.txt необходимо добавить следующий фрагмент:
[UNATTEND]
OEMPREINSTALL = Yes
Файл cmdlines. txt должен иметь следующий формат:
[COMMANDS]
".\cscript script.vbs"
".\batch.cmd"
". \app.exe"
Сценарию, пакетному или выполняемому файлу, который запускается из файла cmdl ines. txt, должно быть присвоено короткое имя. Если для сценария используется длинное имя и изменить его невозможно, сценарий можно запустить из другого пакетного файла, имя которого необходимо указать в файле cmdlines. txt.
Поскольку содержимое файла cmdlines . txt запускается еще до регистрации пользователей, сценарии выполняются в контексте безопасности Local System. Это значит, что сетевые подключения к другим компьютерам не поддерживаются. Записываемая в системный реестр информация сохраняется в разделе Default User.
Установка компонентов
Кроме управления установкой, сценарий автоматизированной установки может использоваться и для установки конкретных компонентов после установки операционной системы. Например, для установки сервера IIS требуется использовать сценарий, так как в этом случае можно указать расположение Web-файлов, отличное от расположения загрузочного диска. Кроме этого, при таком способе установки проще перечислить необходимые для работы Web-службы.
Утилита для автоматической установки компонентов операционной системы Windows называется sysocmgr. Создайте текстовый файл со сценарием установки компонентов и передайте имя файла в качестве параметра утилиты sysocmgr. Ниже приведен пример использования этой утилиты для файла iis.txt.
Sysocmgr /i: %windier%\inf\sysoc.inf /и:с:\iis.txt
Ниже представлен пример сценария, который автоматически устанавливает только Web- службы и размещает каталоги с Web-файлами на диске D.
[Components]
iis_common = On
iis_inetmgr = On
iis_www = On
iis_ftp = Off
iis_nntp = Off
iis_nntp_docs = Off
iis_pwmgr = Off
iis_smtp = Off
iis_smtp_docs = Off
iis_htmla = Off
iis_w3samp = Off
■ iis_doc_common = Off
iis_doc_ismcore = Off
iis_doc_asp = Off
iis_doc_sdk = Off
iis_doc_mm = Off
[Internetserver]
PathFTPRoot=D:\Inetpub\Ftproot
PathWWWRoot=D:\Inetpub\Wwwroot
Интеграция пакета обновлений в установочный образ
В классической операционной системе WindowsNT установка операционной системы была только половиной работы. После этого требовалась установка “второй операционной системы”, которая состояла из пакетов обновлений, содержащих сотни и даже тысячи файлов с исправлениями.
Начиная с операционной системы Windows 2000, компания Microsoft упростила этот этап установки, предоставив возможность установки файлов исправлений из пакета обновления одновременно с установкой оригинальных файлов. Для этого обновления интегрируются в каталог с установочными файлами. Интеграция обновлений описывается в процедуре 2.4.
Процедура 2.4. Интеграция файлов из пакета обновлений
Смонтируйте компакт-диск пакета обновлений или скопируйте содержимое компакт- диска в отдельный каталог.
Перейдите в каталог \ 13 8 6 \Upda t е, в котором находятся файлы с исправлениями.
Запустите команду update -s:е:\softdistro, где e:\softdistro— каталог, в котором расположены установочные файлы операционной системы Windows Server 2003. Обратите внимание, что указывается каталог, в котором содержится каталог 1386 с установочными файлами (т.е. каталог 13 86 является подкаталогом этого каталога).
После обновления установочных файлов при установке операционной системы одновременно будут устанавливаться и обновления.
Все пакеты обновлений формируются по принципу добавления исправлений, поэтому сохранение предыдущей версии не требуется. При обновлении заменяется каталог, используемый системой защиты файлов Windows (Windows File Protection). В новой версии каталога указываются сигнатуры обновленных версий файлов. Кроме этого, устанавливается дополнительный файл САВ, в котором хранятся драйверы, обновленные или добавленные с момента выхода операционной системы Windows Server 2003.
Для установки пакетов обновлений на работающие серверы можно воспользоваться групповыми политиками. Дополнительная информация по использованию групповых политик содержится в главе 12, “Управление групповыми политиками”.
Создание диска сетевой загрузки
Для установки образа операционной системы Windows Server 2003, подготовленного с помощью утилиты sysprep, или установки операционной системы на компьютер без операционной системы, необходимо обеспечить возможность загрузки компьютера и подключения компьютера к сетевому диску с установочными файлами.
Создание диска для загрузки по сети операционной системы Windows не является простой задачей. Компания Microsoft использует закрытый стандарт сетевых драйверов, который называется NDIS (Network Driver Interface Specification — спецификация стандартного интерфейса сетевых адаптеров). Можно встретить другую расшифровку этой аббревиатуры, Network Device Interface Specification — спецификация стандартного интерфейса сетевых устройств. Допустимы обе расшифровки.
Загрузрчные диски с Web-сайта
[ Для полной автоматизации создания загрузочных дисков можно порекомендовать обратиться | ■ на сайт Boot Disks, который доступен по адресу www.nu2 .nu/bootdisk. На этом сайте нахо- | дится набор файлов САВ, содержащих загрузочные файлы, сетевые файлы и конфигурацион- Е ные файлы, которые используются при создании загрузочных гибких дисков и компакт-дисков.
i Драйвер NDIS для работы в реальном режиме с поддержкой протокола TCP/IP требует I целого “хора" файлов поддержки.
[ На установочном компакт-диске Windows Server 2003 предоставляются файлы, необхо- I димые для создания сетевого клиента на основе операционной системы DOS, но для извлече- [ ния и настройки файлов предоставляется утилита, созданная более восьми лет назад. Если Е вам удастся запомнить все файлы реального режима NDIS и содержимое различных конфи- I гурационных файлов, необходимых для создания загрузочного диска, можете смело называть [ себя настоящим Windows-rypy.
| Администраторы, знакомые с операционной системой Windows NT 4.0, могут помнить, что I компания Microsoft предоставляла в составе операционной системы Windows NT 4.0 Server ути- I литу ncadmin, которая поддерживала создание загрузочных дисков. Компания Microsoft переЕ стала предоставлять эту утилиту с момента выхода операционной системы Windows 2000. Для f создания загрузочного диска можно воспользоваться утилитой ncadmin, полученной с устано- [ вочного компакт-диска операционной системы WindowsNT4.0 Server, так как эта утилита от- I лично работает даже под управлением операционной системы Windows Server 2003.
| Если есть возможность и желание потратить немного денег, можно обратиться к крупным I производителям программного обеспечения для работы с образами, например к Symantec или I PowerQuest. Эти производители предоставляют программы создания загрузочных дисков. Для I создания загрузочного диска эти программы используют файлы поддержки реального режима [ NDIS с установочного компакт-диска Windows Server 2003, а драйверы NDIS 2.0 извлекаются из I диска поддержки сетевого адаптера. Рекомендуем использовать именно эти утилиты.
Службы удаленной установки
[ Все методы автоматизации, которые рассматривались до этого момента, все-таки требуют I личного вмешательства администратора. Самым оптимальным методом автоматизации была I бы полностью автоматическая установка, при которой компьютер сам обнаруживает сервер [ распространения установочных файлов, копирует эти файлы на локальный жесткий диск, [ выполняет установку и загружается. Именно с этой целью создавалась подсистема службы Е удаленной установки (Remote Installation Services — RIS). '
i В службах RIS совмещается гибкость использования сценариев, независимых от аппаратных : средств, с простотой использования образов. При применении служб удаленной установки j можно создать “образ” на уровне файлов, который будет устанавливаться с сервера полностью L автоматически без вмешательства администратора. Это все равно что получить на ужин пиво и [ десерт. К сожалению, перед этим придется съесть постный салат. Службы удаленной установки Г могут оказаться сложными в управлении и настройке. К счастью, затраты полностью окупаются.
5 Функциональный обзор служб удаленной установки
[ Службы удаленной установки состоят из серверного компонента и клиентского компонента. I Серверный компонент представлен непосредственно службами удаленной установки, работаю- [ щими на сервере Windows 2000, входящем в домен или являющемся контроллером домена.
t 1 Службы удаленной установки управляют доступом к файловым “образам”, находящимся Е на сервере. Файлы этих образов могут создаваться на основе установочных файлов с ком- I пакт-диска или на основе “образов” операционной системы, подготовленных с помощью ути-
литы riprep. Дополнительная информация приводится в разделе “Создание образов RIS с помощью утилиты riprep” далее в этой главе.
Службы удаленной установки зависят от множества других служб. При этом каждая служба должна быть настроена правильно. Это немного усложняет начальную настройку. Ниже приведен краткий список служб, которые требуют особого внимания. Использование этих служб подробно будет рассмотрено далее.
Preboot Execution Environment (РХЕ)
DHCP
Boot Information Negotiation Layer (BINL)
Мастер установки клиентов
SIS Groveler хранилища единственных копий (Single Instance Storage — SIS)
Сценарии установки средствами RIS
Кроме этого, из-за зависимости служб удаленной установки от Active Directory и в связи с изменениями Active Directory в операционной системе Windows Server 2003 после модернизации домена до Windows Server 2003 также придется выполнить модернизацию RIS-серверов.
Preboot Execution Environment
Клиент RIS должен быть в состоянии создать небольшую операционную среду, обладающую достаточными возможностями для загрузки установочных файлов с сервера, как это сделал бы оператор-человек. Самым сложным моментом является создание такой среды на клиенте. Технология управления созданием такой среды называется Preboot Execution Environment, или РХЕ.
Клиент РХЕ знает, как найти сервер с загрузочным образом, который необходимо загрузить и запустить для создания операционной среды. Он называется предзагрузочным (pre-boot), поскольку клиент РХЕ загружается до операционной системы.
В компьютерах, основанных на архитектуре IA32 и соответствующих стандарту РС97 или более поздней версии стандарта, присутствует встроенная в BIOS поддержка РХЕ. Для использования этой поддержки необходимо включить использование этой возможности в параметрах BIOS и настроить порядок загрузки. Компьютеры на основе архитектуры IA64 содержат пункт меню загрузчика, позволяющий запустить РХЕ.
Даже если в компьютере не поддерживается РХЕ в BIOS, многие сетевые адаптеры поддерживают РХЕ, если выполняемый код доступен в оперативной памяти или на гибком диске. Адаптеры РХЕ должны использовать шину PCI. Это исключает портативные компьютеры, оборудованные сетевыми адаптерами для шины PCMCIA (кроме случаев эмуляции шины PCI поверх шины PC Card).
Загрузочный диск РХЕ создается с помощью утилиты RBFG (Remote Boot Floppy Generator — генератор диска удаленной загрузки), которая хранится в каталоге \RemoteInstall\Admin на сервере RIS. Дополнительная информация об использовании этой утилиты приводится в разделе “Создание загрузочных дисков РХЕ” далее в этой главе.
DHCP
Клиенты РХЕ в качестве транспортного протокола используют TCP/IP. Из-за этого до подключения к серверу RIS клиент РХЕ должен получить IP-адрес. Для клиента, полностью находящегося в памяти, назначение статического IP-адреса невозможно. Чтобы получить IP-адрес, клиент должен обратиться к серверу DHCP.
Протокол DHCP можно описать в терминах покупки пива на стадионе. Имя продавца неизвестно, поэтому достаточно крикнуть “Эй, продавец, что у тебя есть?”. Продавец выкрикивает список товаров, покупатель соглашается с предложением и получает холодное пиво. Рассмотрим типичные транзакции протокола DHCP.
Клиент РХЕ отправляет широковещательный запрос DHCP Discovery.
Сервер DHCP отвечает на запрос, отправляя широковещательное сообщение DHCP Offer.
В ответе содержится IP-адрес. На этом этапе IP-адрес клиенту еще не назначен, поэтому непосредственная связь между клиентом и сервером невозможна.
Клиент отправляет широковещательный запрос DHCP Request, в котором содержится IP-адрес, полученный от сервера в ответе DHCP Offer.
Сервер DHCP отправляет непосредственно клиенту ответ DHCP АСК, подтверждая вы-, деление IP-адреса. В завершающем ответе АСК сервер предоставляет конфигурационную информацию, например адрес шлюза, принятого по умолчанию, суффикс домена DNS, интервал обновления сведений о подтверждении “аренды” IP-адреса и т.д.
Если сервер DHCP находится не в той подсети, в которой расположен клиент, промежуточные маршрутизаторы должны быть настроены на передачу широковещательных запросов DHCP с помощью ретрансляции DHCP/BOOTP. При настройке ретрансляции сервер получает один или несколько IP-адресов работающих серверов DHCP. Ретранслятор передает запросы и ответы DHCP между клиентами и сервером. Читая следующий раздел, не забывайте об этой полезной функции.
В процессе загрузки РХЕ на консоли клиента отображается слово “DHCP” и последовательность точек. После получения клиентом адреса IP конфигурационная информация отображается на консоли и сообщение DHCP заменяется на BINL, что указывает на переход к следующему этапу загрузки.
Boot Information Negotiation Layer (BINL)
На этом этапе клиенту РХЕ уже назначен IP-адрес. Теперь клиент должен получить информацию о сервере, на котором находится загрузочный образ. В клиенте РХЕ для обнаружения сервера RIS используется такой же процесс, как и при общении с сервером DHCP. Сервер RIS поддерживает специальную службу, которая называется Boot Information Negotiation Layer, или BINL. Эта служба обрабатывает специальные запросы DHCP. Рассмотрим, как эта служба работает.
При отправке первого запроса DHCP Discovery клиент РХЕ отправляет глобально уникальный идентификатор (Globally Unique Identifier — GUID), записанный в ROM РХЕ. Если ROM РХЕ не используется и для загрузки использовался гибкий диск, в качестве глобально уникального идентификатора отправляется МАС-адрес клиента, дополненный в начале 20 нулями.
Как только сервер RIS обнаруживает пакеты DHCP Discovery с вложенным идентификатором, служба BINL отвечает собственным пакетом DHCP Offer. В этом ответе поле Client IP специально оставлено пустым, чтобы показать, что это не предложение IP-адреса. В ответе содержится копия глобально уникального идентификатора клиента.
Сначала клиент игнорирует ответ BINL. На этом этапе клиент больше заинтересован в получении IP-адреса. После получения IP-адреса клиент связывается с сервером BINL через порт 4011 по протоколу UDP и отправляет второй запрос DHCP Request.
Сервер отвечает пакетом DHCP АСК, который содержит имя и путь к загрузочному образу. Этот образ называется startrom.com. Дополнительная информация приводится во врезке “Возможные проблемы при использовании службы BINL”.
Теперь клиент отправляет запрос GET по протоколу ТЕТР (Trivial File Transfer Protocol — упрощенный протокол передачи файлов) для копирования файла startrom. com.
В ответ на запрос сервер передает файл startrom. com клиенту.
На этом этапе на экране клиента отображаются его IP-адрес и МАС-адрес. Перед переходом к Client Installation Master (Мастер установки клиентов) можно заметить сообщение TFTP. Мастер установки клиентов рассматривается в следующем разделе.
Мастер установки клиентов
К этому моменту подготовительный этап практически завершен. Клиент запускает образ startrom.com. Образ содержит инструкции по получению еще двух файлов с помощью протокола TFTP.
Ntldr. Вторичный загрузчик операционной системы Windows Server 2003.
Winnt.sif. Стандартный сценарий установки операционной системы Windows Server 2003.
Возможные проблемы при использовании службы BINL
Службы удаленной установки состоят из множества компонентов, и требуются серьезные усилия для создания конфигурации, при которой соответствующие клиенты получают IP-адреса от соответствующих серверов.
Не забывайте, что служба DHCP основана на широковещательных запросах и на маршрутизаторах необходимо установить ретрансляторы запросов DHCP/BOOTP. В большинстве случаев RIS-сервер должен работать на том же компьютере, что и сервер DHCP. Это позволяет организовать более надежный обмен пакетами.
С другой стороны, при наличии более чем одного RIS-сервера важно не устанавливать RIS-сервер на сервер DHCP. Это связано с тем, что клиенты РХЕ игнорируют дополнительные пакеты BINL Offer, если первый пакет Offer поступил от сервера DHCP.
Если на маршрутизаторах используются ретрансляторы DHCP/BOOTP, их необходимо настроить на ретрансляцию запросов и на сервер RIS (добавив его IP-адрес в перечень адресов). И даже после этого иногда система может не работать. В этом случае приходится размещать отдельный сервер RIS в каждой подсети.
Поскольку BINL использует DHCP, сервер RIS должен быть авторизован в Active Directory, как и обычный сервер DHCP под управлением операционной системы Windows Server 2003. Если сервер BINL не авторизован, он не будет отвечать на запросы DHCP Discovery и клиенты РХЕ не дождутся ответа. Для авторизации сервера загрузите оснастку DHCP Manager (Диспетчер DHCP), щелкните на имени сервера правой кнопкой мыши и выберите из контекстного меню команду Authorize (Авторизовать).
Еще одним источником проблем при работе BINL является передача файлов по протоколу ТЕТР. Для копирования файлов с клиента на сервер можно воспользоваться командой TFTP put. Это позволяет разместить на сервере программу типа "троянский конь", которая заменяет собой образ startrom.com или один из файлов поддержки. Компания Microsoft подтверждает существование такой опасности, но на момент написания этой книги решение проблемы предложено не было.
После этого клиент запрашивает нажатие клавиши <F12>, что приведет к запуску мастера CIW (Client Installation Wizard — Мастер установки клиентов). Во врезке “Альтернативные файлы startrom” описываются методы устранения обязательного нажатия клавиши <F12>. На рис. 2.7 показан экран приветствия мастера CIW.
Задачей мастера CIW является аутентификация лица, выполняющего установку, и вывод списка образов, доступных для загрузки. Этот список называется OS Chooser (OSC). После выбора образа мастер установки клиентов загружает файлы этого образа и начинает установку операционной системы Windows Server 2003 с помощью полученных файлов.
1
Рис. 2.7. Экран приветствия мастера установки клиентов (Client Installation Wizard)
Информация, которую мастер установки клиентов выводит на экран, извлекается из файлов OSC, расположенных на сервере RIS в каталоге \Remotelnstall\OS Chooser\ English. Это простые текстовые файлы в формате HTML 2.0. Можно открыть любой из этих файлов с помощью редактора Notepad (Блокнот) и внести необходимые изменения.
В файлах OSC поддерживается только ограниченное подмножество тегов стандарта HTML 2.0, что оставляет небольшой простор для творчества, но нет ничего сложного в добавлении новых команд в существующие OSC-файлы или в создании собственных файлов OSC. Например, можно создать файл OSC, который позволяет администратору определить имя компьютера и организационную единицу (Organization Unit — OU) еще до начала установки. Дополнительная информация приводится в разделе “Изменение экранов мастера установки клиентов" далее в этой главе.
После экрана приветствия мастер установки клиентов отображает экран login.osc, в котором пользователь должен ввести регистрационные данные. Пример такого экрана показан на рис. 2.8.
Рис. 2.8. Экран регистрации мастера установки клиентов
В операционной системе Windows Server 2003, как и в операционной системе Windows 2000, пользователь, который прошел процедуру аутентификации, может выполнить установку операционной системы. Пользователям без привилегий разрешается выполнять не более десяти установок. С помощью групповых политик можно ограничить круг пользователей, которым разрешено выполнять установку. Для аутентификации используются протокол BINL (UDP- порт 4011) и механизм “запрос-ответ” протокола NTLM.
После этого мастер установки клиентов предоставляет пользователю ряд последовательных экранов OSC-файлов, последним из которых является choices. osc (рис. 2.9). На этом экране перечислены образы, доступные на сервере RIS.
Рис. 2.9. Экран OS Choices мастера установки клиентов
При выборе образа из списка мастер установки клиентов загружает сценарий SIF для выбранного образа из каталога \RemoteInstall\Setup\English\lmages\WINDOWS\i386\ templates. В этом сценарии определяются путь размещения файлов и имя компьютера а также описываются другие параметры устанавливаемого экземпляра операционной системы. Если один из этих файлов отсутствует или имеет неправильную структуру, мастер установки клиентов выдаст сообщение об ошибке.
На последнем экране мастера установки клиентов, который называется install .osc, отображаются имя компьютера, глобально уникальный идентификатор и имя сервера RIS. На рис. 2.10 показан пример такого экрана.
Используя эту информацию, мастер установки клиентов создает учетную запись компьютера в Active Directory. По умолчанию учетная запись создается в контейнере Computer, но это расположение можно изменить. Дополнительная информация приводится в разделе “Настройка сервера RIS” далее в этой главе.
Хранилище единственных копий и SIS Groveler
Название этого раздела звучит, как дешевый английский рассказ о любви, а не как техническое описание, но эта тема важна с точки зрения служб удаленной установки.
Сервер RIS может содержать несколько образов. На сервере может храниться образ операционной системы Windows 2000 Professional, образ Windows ХР Professional, образ Windows Server 2003 Standard Edition, а также образ Windows Server 2003 Enterprise Edition. Кроме этого, как будет показано в разделе “Создание образов RIS с помощью утилиты riprep’’, можно воспользоваться утилитой riprep и создать образ существующего сервера или рабочей станции, что увеличивает количество образов, доступных на сервере RIS.
Рис. 2.10. Экран Installation Information мастера установки клиентов
Альтернативные файлы startrom
Загрузочный образ, который используется клиентом RIS, обычно называется startrom.com. Этот файл хранится на сервере RIS в каталоге \Remoteinstall\OSChooser\l386. Именно это имя файла и путь выдаются клиенту РХЕ службой BINL.
В этом каталоге могут существовать альтернативные файлы startrom. Для одного из них, файла startrom.п12, не требуется нажатие клавиши <F12> при установке. Переименовав оригинальный образ startrom.com и заменив его альтернативным, можно заставить клиента РХЕ перейти к мастеру установки клиентов сразу после подтверждения BINL.
Если на сервере RIS присутствует только один образ, мастер установки клиентов пропускает экран OS Chooser и переходит непосредственно к экрану install. osc. При правильной настройке для установки операционной системы от администратора потребуется только нажатие клавиши <Enter>.
Каталог \RemoteInstall\OSChooser\l386 содержит четыре альтернативных образа startrom, которые используются при установке операционной системы на компьютер без клавиатуры, мыши и видеоадаптера. Дополнительная информация приводится в разделе "Использование RIS для установки на серверы без локальной консоли".
Несложно представить, сколько места занимают такие файловые образы. Информация многих файлов дублируется, поэтому для сокращения потребляемого объема на жестком диске компания Microsoft предоставила подсистему SIS (Single Instance Storage — хранилище единственных копий), которая позволяет использовать одну копию файла одновременно в нескольких образах. Служба называется SIS Groveler1, или groveler. exe.
Служба SIS Groveler работает отдельно от RIS. В корневом каталоге раздела с файлами RIS поддерживается каталог, который называется SIS Common Store. Для этого каталога установлены атрибуты Hidden (Скрытый) и System (Системный), что делает этот каталог су- перскрытым. Определенный набор групповых политик позволяет запретить пользователям просматривать суперскрытые файлы.
При установке на сервер RIS двух и более образов в моменты простоя сервера служба SIS Groveler анализирует файлы в поиске идентичных копий образов. Сначала файлы система-
’ Иногда в документации на русском языке встречается альтернативное название службы SIS Groveler — “агент гровелера", однако в этой книге мы будем использовать английское название этой службы.
тизируются по имени и для каждого файла подсчитывается хеш (hash), который используется в качестве сигнатуры. Алгоритм хеширования очень чувствителен к различиям в содержимом файлов. Если файлы отличаются хотя бы на один бит, сигнатура будет совершенно другой.
После этого служба SIS выбирает идентичные файлы и выполняет побайтовое сравнение. Если сравнение подтверждает идентичность файлов, они копируются из обоих образов в SIS Common Store. Файлы переименовываются, и новое имя имеет формат GUID, что делает каждое имя файла уникальным. В этом же каталоге содержится база данных, в которой описывается оригинальное расположение файла.
Определение точек функционального монтирования
Для определения, является ли файл точкой функционального монтирования (так называемой reparse point), можно воспользоваться утилитой fsutil. Команда имеет следующий синтаксис: fsutil reparsepoint <имя_файла>
К сожалению, утилита fsutil не поддерживает использование шаблонов в качестве параметра и не поддерживает проверку целых каталогов. Более подходящим инструментом является утилита RSDIR (Remote Storage File Analysis), которая входит в состав Resource Kit. Эта утилита предназначена для поиска точек функционального монтирования, связанных с системой управления иерархией запоминающих устройств (Hierarchical Storage Management — HSM), но эта утилита позволяет находить точки функционального монтирования, связанные и с SIS. Просто запустите утилиту RSDIR в интересующем каталоге, и утилита выдаст список файлов с их атрибутами. Листинг может выглядеть следующим образом:
non-HSM АP--Z 078716 NA lanma256.bmp
Символ Р указывает, что файл является точкой функционального монтирования, а символ Z указывает на разреженный файл (sparse file). Файл имеет логический размер 78 716 байт, но реальный размер файла равен нулю.
Наконец, подсистема SIS заменяет файл в исходной папке точкой функционального монтирования (reparse point) с тем же именем. Точки функционального монтирования используют специальные структуры файловой системы NTFS для указания на целевой файл или папку. При просмотре точки функционального монтирования в оболочке Explorer (Проводник) отображается содержимое файла или папки. Замененные файлы настраиваются как разреженные (sparse). Логический размер разреженного файла не зависит от физического дискового пространства, выделенного для хранения файла. Дополнительная информация о разреженных файлах и точках функционального монтирования приводится в главе 15, “Управление файловыми системами".
Служба SIS Groveler рассчитывает объем доступного для анализа времени пониженной нагрузки. Начальный анализ занимает несколько часов, поэтому не стоит ожидать активности сразу после установки службы RIS. Если результат необходимо получить сразу, можно принудительно запустить службу SIS в качестве обычного процесса. Для этого можно воспользоваться утилитой grovctrl. Утилита имеет синтаксис grovctrl f.
Утилита grovctrl не устанавливается по умолчанию. Ее необходимо извлечь из файла grovctrl. ех_, хранящегося в каталоге 1386 на установочном компакт-диске операционной системы Windows Server 2003. Кроме этого, утилиту можно использовать для запуска сканирования тома, приостановки и продолжения сканирования, а также для остановки и запуска службы.
Служба SIS и восстановление файлов
Важно помнить, что активность службы SIS Groveler оказывает влияние на планирование резервного копирования и восстановления данных. Только утилиты резервного копирования, которые используют API резервного копирования для операционных систем Windows Server 2003 и Windows 2000, могут работать с точками функционального монтирования и смонтированными файлами. Кроме этого, для правильной обработки файлов SIS компания Microsoft
предоставляет специальную динамическую библиотеку фильтра, которая предоставляет функции для резервного копирования и восстановления файлов из каталога SIS Common Files. Утилита резервного копирования должна обладать информацией о существовании этой библиотеки и уметь использовать функции этой библиотеки для доступа к файлам SIS.
Кроме этого, очень важно запустить службу SIS Groveler до того, как восстанавливать файлы RIS в разделе. Эта служба координирует работу с библиотекой для обеспечения правильной установки точек функционального монтирования. Если перенос образов на другой сервер выполняется с помощью восстановления с магнитной ленты, можно установить службу RIS и после этого запустить утилиту risetup -check для создания структуры каталогов RIS и запуска SIS Groveler.
Сценарии установки RIS
Для управления установкой образов службы RIS используют сценарии Setup Information File (SIF). Файл сценария имеет такую же структуру, как и сценарий автоматизированной установки, а также содержит несколько разделов, характерных для RIS.
Сценарий, который управляет определенным образом, хранится в подкаталоге образа, расположенном в каталоге \Remotelnstall\Setup\English\Images\WINDOWS\i386\ templates. Для создания дополнительных сценариев SIF можно воспользоваться диспетчером установки (или редактором Notepad (Блокнот)), но для этого нужно знать структуру и синтаксис сценария. Например, можно создать один сценарий для компьютеров в отделе программистов и другой сценарий для компьютеров обычных пользователей.
Мастер установки клиентов перечисляет все сценарии, обнаруженные в каталоге templates. Для предоставления информации о сценарии используются записи Description и Help. После выбора сценария администратором сценарий копируется в каталог \Remotelnstall\tmp и переименовывается с использованием алгоритма GUID для обеспечения уникальности имени. Клиент загружает этот сценарий вместе с установочными файлами и использует сценарий для управления процессом установки.
Кроме изменения содержимого сценария с помощью Setup Manager (Диспетчер установки), для ввода дополнительной информации в сценарий можно воспользоваться окнами мастера установки клиентов. В сценарии можно определить до 64 переменных, значения которых будут определены во время работы мастера установки клиентов.
Например, предположим, что для установки Windows Server 2003 Standard Edition используется служба RIS. Это значит, что в сценарий нельзя включить ключ продукта, поскольку ключ отличается для каждого экземпляра операционной системы. Можно создать собственный файл OSC, который будет запрашивать ключ продукта в одном из окон мастера установки клиентов. Введенные пользователем данные будут сохраняться в одной из переменных. После этого в сценарии значение переменной можно присвоить параметру Product ID, например:
[UserData]
ProductID = %Ключ_продукта%
Дополнительная информация по использованию Setup Manager (Диспетчер установки) приводилась в разделе “Создание сценария автоматизированной установки”. Если для создания сценария RIS используется Setup Manager (Диспетчер установки), мастер предоставляет возможность выбора файла SIF (Setup Information File text). Выберите этот пункт для редактирования параметров Description и Help, значения которых отображаются в окне мастера установки клиентов.
Изменение экранов мастера установки клиентов
Поскольку экраны мастера установки клиентов, которые отображаются в ходе установки с помощью RIS, представляют собой простые текстовые файлы OSC, их можно изменить, адаптировав для конкретных потребностей. Язык разметки, который используется для создания файлов OSC, называется OSCML (OS Chooser Markup Language).
Язык OSCML является сокращенным вариантом языка HTML 2.0. Как и в языке HTML, в языке OSCML можно определять переменные, но некоторые имена переменных были зарезервированы. Список зарезервированных имен приводится во врезке “Зарезервированные переменные языка OSCML”. Ниже приводится пример использования таких переменных.
По умолчанию при создании учетной записи компьютера для клиента RIS мастер установки клиентов размещает учетную запись в контейнере cn=Computers. В списке параметров сервера RIS можно указать другой контейнер, принятый по умолчанию, но тогда все учетные записи компьютеров будут создаваться в этой организационной единице (OU).
Для выбора организационной единицы в процессе установки можно создать новый файл OSC, который называется chooseou. osc, хотя подойдет любое имя, соответствующее формату 8.3. Воспользуйтесь в качестве шаблона другим файлом OSC и в качестве тела файла вставьте небольшую форму, которая запрашивает у пользователя ввод данных:
<form action="warning">
Организационная единица, в которой создается учетная запись 'Ъ компьютера: cinput name="machineou” maxlength=255>
</form>
Введенные пользователем данные, предоставленные с помощью команды Input, сохраняется в переменной machineou. Введенные пользователем данные передаются на экран warning.osc. На этом экране выдается предупреждение о стирании содержимого жесткого диска. Экр^н warning. osc отображается до экрана install.osc, после которого начинается процедура установки. Изменив файл install. osc для вывода значения переменной machineou, можно увидеть результат работы файла chooseou. osc.
Зарезервированные переменные языка OSCML
Ниже приведен список переменных языка OSCML, зарезервированных для специального использования.
Language: определяет язык файлов OSC
Suberror: используется для обработки ошибок
Machineou: контейнер, в котором будет создана учетная запись компьютера
Machinename: видимое имя учетной записи компьютера в Active Directory, например serveri
Netbiosname: имя учетной записи SAM, которое присваивается компьютеру. Соответствует имени компьютера с добавлением символа $, например serveri $
Servername: имя сервера RIS
Serverdomain: домен, в котором находится сервер RIS
Machinedomain: домен, к которому пытается подключиться сервер RIS
Bootfile: путь к файлу startrom.com на сервере
Siffile: путь к файлу SIF; по умолчанию это временный файл, скопированный из папки шаблонов
Options: переменная для хранения результата выполнения команды Enum, которая перечисляет файлы SIF в указанном каталоге
Syspreppath: путь к источнику образов Riprep
Sysprepdrivers: путь к драйверам Riprep, которые используются подсистемой РпР
Installpath: путь к каталогу, в котором хранятся файлы образа начальной установки; иногда этот образ называется "плоским" (flat)
МАС: МАС-адрес клиента
GUID: глобально уникальный идентификатор клиента; для клиентов RBFG идентификатор будет состоять из двадцати нулей и МАС-адреса
Machinetype; аппаратные средства клиента; для компьютеров Intel переменная имеет значение 1386
Username, Password, Userdomain: используется для аутентификации; пароль не сохраняется на сервере и перезаписывается в памяти клиента
Timezone: часовой пояс сервера
На рис. 2.11 показано окно мастера установки клиентов, в котором используется несколько показанных выше переменных.
Рис. 2.11. Экран, использующий переменные OSCML мастера установки клиентов
Кроме этого, результаты на экране install. о sc можно проверить, открыв на контроллере домена оснастку Active Directory — Users and Computers (Active Directory — Пользова- ( тели и компьютеры). В этой оснастке можно убедиться, что учетная запись компьютера создана в указанной организационной единице.
Создание образов RIS с помощью утилиты riprep
Службы удаленной установки предоставляют хорошую возможность установки операционной системы, но при этом на администратора возлагается ответственность за установку приложений. Для облегчения этой задачи администратора в составе RIS предоставляется утилита riprep. Эта утилита создает образ существующего сервера или рабочей станции, который можно скопировать на сервер RIS и предоставить как один из пунктов экрана OS Chooser. Как и в случае sysprep, в образе riprep сохраняются файлы приложений и соответствующие записи системного реестра.
Утилита riprep создает образы на уровне файлов, а не на уровне секторов, как это делают программы Ghost и Drivelmage. Основным преимуществом таких образов (кроме цены) является независимость образа от аппаратных средств. По той же причине образы riprep превосходят образы еще одной утилиты для создания файловых образов, sysprep. Единственной зависимой от аппаратных средств частью является драйвер уровня аппаратных абстракций (Hardware Abstraction Layer — HAL). Образ, созданный на компьютере с ACPI HAL,
не может устанавливаться на компьютер, требующий другой библиотеки HAL. Операционная система Windows Server 2003 может определить подходящую для клиента библиотеку HAL и внести в образ riprep необходимые изменения.
Причиной гибкости образов riprep является использование файлов со стандартного установочного образа на компакт-диске. Так называемый “плоский" образ содержит дополнительные файлы, необходимые для использования на компьютерах с другой аппаратной конфигурацией.
Использование утилиты riprep
Начните с создания и настройки сервера (или рабочей станции) в том виде, в котором он должен работать по мнению администратора. Установите все необходимые приложения. Все файлы должны находиться в том же разделе, который содержит системные файлы Windows (каталог \Windows или \winnt). Утилита riprep поддерживает создание образов только на основе системного раздела.
Кроме этого, по умолчанию службы удаленной установки рассматривают загрузочный диск как раздел операционной системы. Диск для установки образа riprep должен быть не меньше исходного диска. Для операционной системы потребуется 2 Гбайт дискового пространства. Добавьте к этому необходимый объём дискового пространства для установки приложений. Не создавайте образ в разделе, который окажется слишком большим для остальных серверов.
После подготовки исходного компьютера можно создавать образ riprep, как изложено в процедуре 2.5.
Процедура 2.5. Использование утилиты riprep для создания образа операционной системы Windows Server 2003
На сервере, который будет использован в качестве оригинала образа, подключите сетевой диск REMINST, расположенный на сервере RIS.
Перейдите в каталог\Admin\I386.
Запустите утилиту riprep. Откроется Remote Installation Preparation Wizard (Мастер подготовки удаленной установки).
Щелкните на кнопке Next (Далее). Откроется окно Server Name (Имя сервера). Введите полностью определенное имя сервера DNS (если преобразователь имен добавит подходящий домен DNS, можно указать “плоское” имя).
Щелкните на кнопке Next (Далее). Откроется окно Folder Name (Имя каталога). Введите имя каталога на сервере RIS, на котором должен находиться создаваемый образ. Не вводите полное имя, поскольку задача его определения возложена на сервер RIS.
Щелкните на кнопке Next (Далее). Откроется окно Friendly Description and Help Text (Описание и дополнительная информация). Введите удобное для описания имя образа, которое поможет другому администратору выбрать образ в окне мастера установки клиентов.
Щелкните на кнопке Next (Далее). Откроется окно Report System Compatibility (Отчет о совместимости). В этом окне выводятся компоненты образа, которые не могут корректно взаимодействовать с RIS. Решите все указанные проблемы и начните создание образа сначала.
Щелкните на кнопке Next (Далее). Откроется окно Stop Services (Остановка служб). В этом окне перечисляются локальные службы, которые должны быть остановлены при создании образа RIS. Список создается на основе файла riprep. inf, который хранится в том же каталоге, что и утилита riprep.
Щелкните на кнопке Next (Далее). В окне Stop Services (Остановка служб) будет отображен процесс остановки служб. Если в процессе возникнет ошибка, она будет записана в файл riprep.log, хранящийся в каталоге \RemoteInstall\Setup\English\Images\ <образ_г!ргер>\1386.
Если в системе открыты приложения, появится окно Programs or Services Running (Запущенные программы и службы) с предложением завершить работу приложений.
Щелкните на кнопке Next (Далее). Откроется окно Review Settings (Просмотр параметров). Убедитесь, что все параметры указаны правильно.
Щелкните на кнопке Next (Далее). Утилита riprep обработает запрос и начнет копирование файлов на сервер RIS. В зависимости от пропускной способности в сети это может занять некоторое время.
Сценарии утилиты riprep
При создании образа диска утилита создает каталог с именем, соответствующим имени образа. Вложенный каталог Mirror 1 в основном каталоге содержит установочные файлы. Кроме этого, утилита riprep создает каталог Templates, в котором содержится файл riprep. sif, выступающий в роли мини-сценария для установки образа.
Для модификации процесса установки образа в этот,сценарий можно внести изменения. Если необходимо внести изменения в сам образ, установите образ на компьютере, внесите изменения в файлы и создайте образ повторно.
Требования утилиты riprep
Ниже приведен сведенный воедино список требований утилиты riprep, упоминавшихся в этом разделе.
Поддержка создания образа только на основе загрузочного раздела. Основой для образа может служить только раздел с системными файлами Windows (каталог \Windows или \winnt). Если для хранения данных выделен отдельный раздел, такие разделы необходимо обрабатывать отдельно.
“Плоский” образ, существующий заранее. При выполнении начальных функций на компьютере службы RIS зависят от установочных файлов из “плоского” образа. Нельзя использовать riprep без созданного “плоского” образа с компакт-диска той же операционной системы.
Размер диска. Размер жесткого диска, на который происходит установка операционной системы, должен быть не менее размера жесткого диска компьютера, использованного для создания образа. Это связано с тем, что в образе хранится копия загрузочного сектора исходного компьютера. Службы RIS могут расширить раздел, сделав его большим, чем указано в загрузочном секторе, но меньшим раздел сделать невозможно.
Совпадение уровня аппаратных абстракций. Компьютер, на который происходит установка операционной системы, должен использовать тот же уровень аппаратных абстракций (HAL), что и исходный компьютер.
Создание загрузочных дисков РХЕ
Загрузка с помощью РХЕ поддерживается только компьютерами, основанными на стандарте РС97 или более поздней версии этого стандарта. При наличии более старого компьютера для загрузки с помощью РХЕ можно воспользоваться контроллером Ethernet, поддерживающим РХЕ, или сетевым адаптером, на котором установлен совместимый с РХЕ контроллер Ethernet.
Для создания загрузочного диска РХЕ можно воспользоваться утилитой RBFG (Remote Boot Floppy Generator), которая хранится в каталоге \RemoteInstall\Admin\l386. На рис. 2.12 показан пример интерфейса RBFG. Щелчок на кнопке Adapters (Адаптеры) приводит к открытию окна со списком поддерживаемых адаптеров.
В методе применения загрузочного гибкого диска РХЕ вместо настоящего сеанса РХЕ средствами BIOS существует один подводный камень. Сетевой адаптер не имеет глобально
уникального идентификатора, поэтому учетная запись компьютера получит идентификатор, состоящий из МАС-адреса, дополненного слева двадцатью нулями. Это значит, что при переносе сетевого адаптера на другой компьютер и попытке использования служб RIS будет получена ошибка “дублирование GUID”.
Рис. 2.12. Основное окно утилиты Remote Boot Disk Generator
Если это произошло, удалите объект первого компьютера. Если объект все еще используется первым компьютером, но был заменен сетевой адаптер, можно воспользоваться редактором ADSI из пакета Support Tools. Этот редактор позволяет изменить значение атрибута RemoteBoot-GUlD таким образом, чтобы оно соответствовало новому адресу МАС. Для получения МАС-адреса можно воспользоваться командой ipconfig /all.
Требования к тому RIS
Как и любые службы удаленной загрузки, службы RIS зависят от файла образа, загружаемого по сети на удаленный клиент. Для хранения образов службы RIS предъявляют определенные требования.
Том не может использоваться для хранения системных файлов Windows Server 2003.
Том должен быть отформатирован с помощью файловой системы NTFS.
На томе должно быть 800-1000 Мбайт свободного дискового пространства.
Если том не удовлетворяет этим требованиям, службы RIS не смогут правильно работать и придется начинать настройку сначала.
Установка служб RIS
Для установки драйверов RIS выполните последовательность действий, описанную в процедуре 2.6.
Процедура 2.6. Установка служб удаленной установки
Выберите сервер, на котором будут храниться загрузочные образы RIS. Сервер не обязательно является контроллером домена, но он обязательно должен входить в домен Windows Server 2003.
В Control Panel (Панель управления) откройте окно Add/Remove Programs (Установка и удаление программ).
Щелкните на кнопке Configure Windows (Установка компонентов Windows). Откроется окно Add or Remove Windows Components (Мастер компонентов Windows).
Щелкните на кнопке Components (Компоненты). Откроется окно Windows Server 2003 Components (Компоненты Windows Server 2003).
Выберите Remote Installation Services (Службы удаленной установки) и щелкните на кнопке Next (Далее). После завершения установки будет выдан запрос на перезагрузку. Перезагрузите компьютер.
Описанная последовательность действий приводит к установке только службы и файлов поддержки. После этого необходимо установить и настроить образ RIS.
Настройка образа RIS
После установки RIS необходимо настроить образ удаленной установки. Для этого выполните последовательность действий, описанную в процедуре 2.7.
Процедура 2.7. Настройка образа служб удаленной установки
Вставьте установочный компакт-диск операционной системы, образ которой необходимо создать. В число поддерживаемых операционных систем входят Windows 2000 Professional, Windows 2000 Server и Windows 2000 Advanced Server. Также в число поддерживаемых систем входят Windows ХР Professional и Windows Server 2003 Enterprise Edition.
Запустите Start* Programs* Administrative Tools* Remote Installation Services (Пуск1* Программы* Администрирование1* Инсталляция служб удаленной установки). Это приводит к запуску мастера Remote Installation Wizard, Risetup (Мастер удаленной установки Risetup).
Откроется окно приветствия. Если сервер не входит в домен Windows Server 2003 или не может найти контроллер домена с помощью DNS, мастер установки Risetup не сможет продолжить работу и выдаст сообщение об ошибке обнаружения домена. При неправильной настройке каталога для сервера RIS клиент не сможет найти сервер RIS и выдаст похожее сообщение об ошибке.
Щелкните на кнопке Next (Далее). Откроется окно Remote Installation Services Options (Параметры служб удаленной установки). Выберите Add a new OS Image То This Remote Installation Server (Добавить новый образ ОС к этому серверу RIS).
Щелкните на кнопке Next (Далее). Откроется окно Installation Source Files Location (Расположение установочных файлов). Введите букву диска, соответствующую приводу компакт-дисков.
Щелкните на кнопке Next (Далее). Откроется окно Windows Installation Image Folder Name (Название каталога для установочного образа Windows). Введите имя каталога, в котором хранится образ на RIS-сервере, например Adv_Srvr.
Управление службами RIS
Если в сети присутствуют клиенты удаленной загрузки или еще один сервер RIS, службы RIS стоит отключить до начала установки.
Кроме этого, перезапуск служб RIS требуется при любом изменении образа или конфигурации RIS. Сначала приходится вносить множество изменений, поэтому до полной готовности службу лучше отключить.
Щелкните на кнопке Next (Далее). Откроется окно Friendly Description and Help Text (Описание и дополнительная информация). Введите имена, позволяющие идентифицировать образы в списке мастера установки клиентов. ,
Щелкните на кнопке Next (Далее). Если на сервере уже присутствуют образы RIS, будет выдан запрос о дальнейшем использовании экранов CIW. Если изменение этих экранов не планируется, выберите Use The Old Client Installation Screens (Использовать предыдущие экраны установки клиента).
Щелкните на кнопке Next (Далее). Откроется окно Review Settings (Обзор параметров). Если в одном из предыдущих окон была допущена ошибка, именно в этом окне ее можно исправить.
Щелкните на кнопке Finish (Готово). Утилита risetup скопирует файлы с установочного компакт-диска в каталог RIS. При этом будет выведен список действий, описывающий текущее состояние копирования. Последним элементом списка является Starting the Remote Installation Services (Запустить службу RIS).
Настройка сервера RIS
Отдельной оснастки ММС, предназначенной для настройки службы RIS, не существует. Все настройки параметров выполняются с помощью,объекта компьютера из Active Directory. Процесс настройки сервера рассматривается в процедуре 2.8.
Процедура 2.8. Настройка сервера RIS (Remote Installation Services —
Службы удаленной установки)
Загрузите оснастку Active Directory — Users and Computers (Active Directory — Пользователи и компьютеры), выбрав ее из меню Starts Programs1* Administrative Tools (Пуск1* Программы1* Администрирование).
Найдите пиктограмму компьютера, соответствующую серверу RIS.
Щелкните на пиктограмме правой кнопкой мыши и выберите Properties (Свойства) из контекстного меню. Откроется окно Properties (Свойства).
Перейдите на вкладку Remote Install (Удаленная установка).
Щелкните на кнопке Advances Settings (Дополнительные параметры). Откроется окно Remote Installation Services Properties (Свойства служб удаленной установки), которое показано на рис. 2.13.
SERVER 1 -R emote-Instalia» mn bri vw «•»
NewCfarte | imagee | То* ,|
Select «computer netting fantit for new сбег* computers, andt
Mt foe kcation in the drectory service where cient computer accounts wi be created.
- Client computer naming format
f Generate cient computer nanws using:;
Cuitomee... I i
j EmopIk John Smith’s computer wouHbo named:
i pOHNSMlii Л'' I :
Dent account location - -
; location:
f* Defaultdrectoiyservicelocation
i <* The fofov^ directory servfce location:
Puc. 2.13. Свойства служб RIS. Окно, открывающееся после щелчка на кнопке Advances Settings (Дополнительные параметры)
Рис. 2.14. Окно Computer Account Generation (Генерация учетной записи компьютера)
На вкладке New Clients (Новые клиенты) в разделе Automatic Computer Naming (Автоматическое назначение имен) щелкните в раскрывающемся списке Generate Client Computer Names Using (Генерировать имена клиентских компьютеров) (рис. 2.14). Дополнительная информация о пунктах этого списка приводится во врезке “Собственные имена компьютеров и RIS”.
В разделе Computer Account Location (Место расположения учетной записи компьютера) выберите Specific Directory Service Location.
Щелкните на кнопке Browse (Обзор) и выберите контейнер, в котором будут создаваться объекты компьютеров, созданных сервером RIS.
Перейдите на вкладку OS Images (Образы ОС). В списке указаны имена образов, настроенных с помощью утилит ri setup, riprep или с помощью собственных файлов SIF, созданных средствами диспетчера установки.
Если необходимо добавить новый “плоский” образ, вставьте установочный компакт-диск Windows Server 2003 в привод компакт-дисков и щелкните на кнопке Add (Добавить).
Щелкните на кнопке ОК, чтобы вернуться на вкладку Remote Install (Удаленная установка) в окне Properties (Свойства).
Щелкните на кнопке ОК, чтобы сохранить все изменения и закрыть окно.
Перейдите в командную строку. Перезапустите службу binlsvc, как показано ниже:
net stop binlsvc net start binlsvc
Собственные имена компьютеров и RIS
Службы RIS предоставляют несколько вариантов автоматической генерации имен компьютеров. Иногда генерируемое имя компьютера назначается в зависимости от имени пользователя. В крупной организации, где компьютеры часто переходят от одного пользователя к другому, такой подход не всегда оправдан. Более предпочтительным вариантом является использовде ние МАС-адреса. Это позволяет гарантированно получить уникальное имя, которое не изменится до смены сетевого адаптера.
По умолчанию в качестве формата именования используется МАС-адрес, дополненный слева буквами NP. Символьный префикс важен для некоторых утилит TCP/IP, например ping. Такие утилиты не работают, если имя узла начинается с цифры.
Вместо префикса NP можно использовать две или три буквы, описывающие расположение рабочей станции. Для изменения префикса щелкните на кнопке Advanced (Дополнительно). Префиксы позволяют классифицировать рабочие станции в списке Browse (Обзор), но для самого обзора префиксы не обязательны, поскольку обычно рабочие станции размещаются в локальных контейнерах. Несмотря на это, до полного перехода на Active Directory необходимо сохранить механизмы поддержки обзора, характерного для Windows NT.
Управление доступом к образу RIS
Маловероятно, что каждому пользователю или посетителю разрешено случайно или намеренно создавать образ компьютера или устанавливать образ на компьютер. На компьютере не следует выполнять загрузку с помощью РХЕ, пока не откажут другие носители, но в реальном мире случается всякое.
Можно предпринять несколько мер для защиты образов от случайной загрузки. Для начала для образов необходимо установить разрешения, позволяющие видеть образы только членам определенной группы. Если в окне OS Chooser отсутствуют доступные образы, мастер установки клиентов выдаст сообщение об ошибке. Установка разрешений описывается в процедуре 2.9.
Процедура 2.9. Настройка разрешений на доступ к образу RIS
Перейдите в Start^Programs1^ Administrative Tools (Пуск1^Программы^Администрирование) и запустите оснастку Active Directory — Users and Computers (Active Directory — Пользователи и компьютеры).
Найдите пиктограмму компьютера, соответствующую серверу RIS.
Щелкните правой кнопкой мыши на пиктограмме и выберите из контекстного меню команду Properties (Свойства). Откроется окно Properties (Свойства).
Перейдите на вкладку Remote Install (Удаленная установка).
Щелкните на кнопке Advanced Settings (Дополнительные параметры).
Перейдите на вкладку Images (Образы).
Выберите образ и щелкните на кнопке Properties (Свойства). Откроется окно Properties (Свойства), соответствующее файлу SIF выбранного образа.
Щелкните на кнопке Permissions (Разрешения) и перейдите на вкладку Security (Безопасность).
Установите разрешения на доступ к образу. Образ будет невидимым для всех, кому не разрешен доступ к файлу SIF.
Кроме этого, можно ограничить распространение образов только компьютерами, подготовленными для установки с помощью RIS. Это позволяет проявлять избирательность при выборе компьютеров, на которые устанавливается образ. Например, на определенный класс компьютеров образы устанавливаться не должны. Отказавшись от предварительной подготовки таких компьютеров, можно обеспечить безопасность для данных, хранящихся на жестких дисках этих компьютеров.
Предварительная подготовка подразумевает указание “управляемых” объектов компьютеров в Active Directory. При этом в Active Directory записываются объекты и соответствующие GUID компьютеров, которым будет отправляться пакет предложения BINL.
Самым простым способом предварительной подготовки является проход по всем экранам мастера установки клиентов до экрана install. osc, на котором выводится информация об
имени компьютера, имени сервера RIS и GUID компьютера. При этом мастер установки клиентов создаст объект компьютера и соответствующий ему GUID, сформированный на основе сетевого интерфейса РХЕ. После этого компьютер можно выключить и разместить в одной сети с сервером RIS, который настроен на принятие запросов только от “управляемых” клиентов.
В качестве альтернативного решения можно скопировать GUID из энергонезависимой памяти компьютера, создать объект компьютера и ввести GUID вручную в окне свойств объекта.
Проверка конфигурации сервера RIS
В окне свойств сервера RIS в Active Directory есть кнопка Verify Server (Проверка сервера). Эта кнопка запускает утилиту ri setup, которая проверяет содержимое каталогов верхнего уровня сервера RIS и запускает связанные с RIS службы binlsvc и SIS Groveler. При этом проверка каталогов с образами и файлов OSC не выполняется. Того же результата можно достичь, запустив из командной строки команду risetup -verify.
Управление RIS с помощью групповых политик
Как будет показано в главе 12, “Управление групповыми политиками”, практически любой элемент системы может управляться теми или иными средствами групповых политик. Одни групповые политики влияют на записи системного реестра. Другие могут вносить изменения в базы данных безопасности, управляющих разрешениями и привилегиями на компьютере. Одна из групповых политик управляет элементами мастера установки клиентов. Доступ к политике описывается в процедуре 2.10.
Процедура 2.10. Доступ к групповой политике Remote Installation (Удаленная установка)
Откройте оснастку Active Directory — Users and Computers (Active Directory — Пользователи и компьютеры).
Щелкните правой кнопкой мыши на пиктограмме домена и выберите пункт Properties (Свойства) из контекстного меню.
Перейдите на вкладку Group Policy (Групповые политики).
Выполните двойной щелчок на кнопке Default Domain Policy (Политика по умолчанию для домена) для запуска оснастки Group Policy Editor (Редактор групповой политики).
Перейдите в раздел User Configuration^Windows Settings ^Remote Installation Services (Конфигурация пользователям Параметры WindowsMСлужбы удаленной установки).
На правой панели выполните двойной щелчок на пиктограмме Choice Options (Параметры выбора). Откроется окно Choice Options Properties (Свойства).
Групповая политика Remote Installation (Удаленная установка) предоставляет четыре параметра, каждый из которых применяется в зависимости от расположения объекта пользователя в Active Directory. Поскольку была открыта политика Default Domain, указанные здесь параметры будут относиться к каждому пользователю домена. Вот эти параметры.
Automatic Setup (Автоматическая установка). Эта функциональная возможность Client
Installation Wizard используется по умолчанию. Пользователь получает параметры, определенные в Active Directory для сервера RIS. Отключение этой политики означает, что при запуске Client Installation Wizard (Мастер установки клиента) пользователь увидит окно Custom Setup (Установка по требованию).
Custom Setup (Установка по требованию). Этот параметр позволяет вывести дополнительное окно, в котором администратор может ввести имя компьютера и название организационной единицы. Введенные значения имеют для сервера RIS больший приоритет, чем параметры в Active Directory.
■ Restart Setup (Перезапуск установки). Этот параметр позволяет пользователю проводить транзакцию RIS на основе введенных данных, полученных до обрыва связи. Этот параметр не оказывает влияния на графический этап установки. Если текстовый этап установки завершен и выбран этот параметр, все загруженные до этого файлы будут перезаписаны. Именно поэтому данный параметр по умолчанию отключен.
■ Tools (Средства). Компания Microsoft и другие компании могут разрабатывать утилиты, способные работать в реальном режиме среды РХЕ. Например, компания ЗСот предоставляет ряд утилит, предназначенных для модификации меню RIS. Это дает возможность менять параметры адаптера и записывать BIOS компьютера средствами RIS. Для использования этих утилит политика Tools должна быть установлена в состояние Enabled (Включено).
Использование RIS для установки операционной системы на серверы без локальной консоли
На сервере без локальной консоли нет мыши, клавиатуры и видеоадаптера. Такой сервер расположен в стойке и незаметно выполняет свою функцию, мерцая одним или двумя индикаторами.
В большинстве серверных комнат для экономии места и энергии несколько серверов подключены к одному набору из мыши, клавиатуры и монитора. Для переключения серверов используется специальный коммутатор клавиатуры, мыши и видео (Keyboard/Video/Mouse — KVM). Многие производители встраивают в свои коммутаторы KVM дополнительные возможности.
Идеальный вариант не предполагает использования коммутатора KVM. Серверы без локальной консоли предназначены именно для такого варианта. Все управление сервером осуществляется с помощью служб терминалов (в операционной системе Windows Server 2003 эта служба называется Remote Desktop (Удаленный рабочий стол) или через терминалы командной строки, например telnet. Операционная система Windows Server 2003 проектировалась в том числе и для использования на серверах без локальной консоли. В составе операционной системы присутствует множество утилит, предназначенных для работы в интерфейсе командной строки, и интерфейсов, позволяющих использовать утилиты в сценариях.
Несмотря на это, администратор должен решить проблему “курицы и яйца”. Как загрузить операционную систему на сервере без локальной консоли? Конечно, на компьютер можно установить видеоадаптер и подключить сервер к коммутатору KVM, чтобы запустить RIS или утилиту sysprep, но эта идея звучит как-то пораженчески, не правда ли? Сервер без локальной консоли должен оставаться таким сервером с самого начала.
Операционная система Windows Server 2003 поддерживает установку на сервер без локальной консоли средствами RIS. Кроме этого, предоставляется набор возможностей, которые имеют общее название Emergency Management Services (EMS). Одной из возможностей служб EMS является перенаправление текстового вывода с консоли на последовательный порт. К последовательному порту можно подключить модем (или порт классического последовательного сервера терминалов) и создать внеочередное подключение к серверу вне потока данных (Out-of-Band — ООВ). При таком подключении можно воспользоваться мастером установки клиентов и запустить установку операционной системы средствами RIS.
Настройка R1S для серверов без локальной консоли
Помните, что клиент РХЕ запускает сеанс RIS автоматически при отсутствии в операционной системе устройств со сменными носителями. В таком случае достаточно сообщить клиенту РХЕ, что вывод должен перенаправляться на последовательный порт. Для этого требуется специальный образ startrom. com.
Откройте каталог \Remotelnstall\OS Chooser\l386 на сервере RIS и обратите внимание на список файлов. Можно заметить четыре файла, которые начинаются со строки hdls. Эти файлы предназначены для серверов без локальной консоли. Файл hdlscoml. com предназначен для перенаправления вывода на порт СОМ1. Файл hdlscom2 . com делает то же для порта COM2. Версия *. п12 позволяет пропустить нажатие клавиши <F12>. Это иногда необходимо, поскольку некоторые эмуляторы терминалов не знают, как передать сведения о нажатии <F12> на сервер. Для запуска установки средствами RIS на сервере без локальной консоли выполните последовательность действий, описанную в процедуре 2.11.
Процедура 2.11. Установка операционной системы на сервер без локальной консоли средствами RIS
Подключите управляющий компьютер к серверу без локальной консоли с помощью нуль- модемного кабеля.
На сервере RIS переименуйте образ startrom. com и скопируйте образ hdlscoml ,п12 в файл startrom.com.
Запустите консоль эмулятора терминала на управляющем компьютере, логически или физически подключенном к первому последовательному порту, и подключитесь к серверу.
После установки подключения запустите сервер без операционной системы на загрузочном носителе (если сервер поддерживает удаленное управление аппаратными средствами или истинную функциональную возможность Wake-On-LAN, то такой запуск можно выполнить удаленно).
В консоли будут выводиться загрузочные сообщения клиента РХЕ. После этого, когда сервер свяжется с сервером DHCP и RIS, на консоль будет выведен экран приветствия мастера установки клиентов (нет необходимости нажимать <F12>, поскольку используется специальная версия образа startrom.com).
“Пройдите” по всем экранам мастера установки клиентов (CIW). После завершения подготовки установки нажмите клавишу <Enter> и наблюдайте за автоматической установкой.
На консоли эмулятора терминала будет видна только текстовая часть установки. На определенном этапе контакт с сервером будет утрачен (как с космическим кораблем при входе в атмосферу). Если все пройдет нормально (т.е. сценарий RIS настроен правильно и нет ошибок в работе аппаратного обеспечения), то через 30-40 минут установка будет завершена.
Все операционные системы Windows Server поддерживают два сеанса Remote Desktop (Удаленный рабочий стол) в качестве стандартной возможности операционной системы. Для использования одного из этих сеансов необходимо зарегистрироваться с помощью учетной записи Administrator (Администратор). После завершения установки и последней перезагрузки к компьютеру можно подключиться с помощью Remote Desktop (Удаленный рабочий стол) и провести окончательную настройку.
Административный режим служб терминалов
В операционной системе Windows 2000 только администраторы могли использовать терминальное подключение для управления сервером. В операционной системе Windows Server 2003 для управления доступом к этой возможности используется группа Remote Desktop Users. Все пользователи, входящие в эту группу, могут получать доступ к серверу при наличии достаточных привилегий.
Краткое резюме по службам RIS
Если установить множество серверов и рабочих станций с различными конфигурациями аппаратных средств, время на настройку служб удаленной установки окупится с лихвой. Можно перечислить следующие распространенные проблемы в работе этих служб.
Отсутствие авторизации сервера RIS в Active Directory. Без авторизации служба BINL не будет отвечать на запросы Discovery.
Наличие маршрутизаторов без ретрансляторов между клиентами и серверами RIS и DHCP.
Отсутствие соответствующего “плоского” образа на основе установочного компакт-диска перед запуском утилиты riprep.
Ошибка при резервном копировании и восстановлении файлов SIS.
Попытка использования устаревших клиентов РХЕ. Версия РХЕ должна быть не младше версии .99.
Попытка использовать утилиту riprep для создания образов нескольких разделов.
Попытка установить образ riprep в раздел, размер которого меньше размера оригинального раздела.
Изменение групповой политики RIS без уведомления коллег, на которых влияет это изменение.
В следующей главе
В книге последовательно описывается процесс развертывания операционной системы Windows Server 2003 в пределах предприятия. Установка операционной системы на сервер является только началом. Сделать после этого остается еще много. Необходимо настроить такие службы TCP/IP, как DNS и DHCP, настроить параметры безопасности, развернуть домены Active Directory, предоставить ресурсы для совместного доступа, организовать управление пользователями, а также запланировать действия на случай выхода системы из строя.
Перед тем как переходить ко всем этим процедурам, рассмотрим еще один аспект, который касается установки. В следующей главе рассматриваются изменение конфигурации аппаратных средств после установки операционной системы и диагностика проблем, возникающих при таком изменении.
3
Добавление аппаратных средств
С
оздание стабильно работающего корпоративного сервера требует значительного времени. Большую часть процесса установки и тестирования можно автоматизировать, но к моменту завершения подготовки массива RAID, установки операционной системы, разбиения и форматирования дисков для хранения данных, установки приложений, настройки прав доступа и проверки соответствия системы запросам пользователей пройдет половина рабочего дня.
Даже если во внимание принимались будущие запросы пользователей, неизбежно наступает момент добавления или замены компонентов аппаратных средств, а также обновления драйверов. Иногда модернизация заключается в установке дополнительного процессора для ускорения работы сервера SQL или дополнительного жесткого диска, на котором можно будет разместить растущие объемы данных. Также это может быть установка сетевого адаптера с несколькими интерфейсами, что позволяет ускорить работу сервера терминалов. Эти операции требуют определенного планирования, особенно если их приходится выполнять на работающем сервере. Ни одному администратору не позволят проводить мероприятия по обслуживанию во время работы пользователей и уж тем более не позволят создавать ситуации, при которых сервер не возвращается в рабочее состояние после внесения изменений.
Каждый аппаратный компонент обладает характерными особенностями, на которые каждый сервер реагирует совершенно уникальным образом. Все возможные варианты поведения предусмотреть невозможно. В этой главе архитектура Windows Server 2003 рассматривается в контексте работоспособности аппаратных средств. Кроме этого, рассматриваются установка новых устройств и диагностика ошибок после установки. Также в главе рассматривается управление устройствами и возможности платформы IA64 по обеспечению совместимости; эти возможности сравниваются с аналогичными возможностями архитектуры IA32.
Новые возможности операционной системы Windows Server 2003
Наиболее значительные отличия в поддержке аппаратных средств характерны для операционной системы Windows Server 2003 для платформы IA64. Среди них можно перечислить:
новую архитектуру управления памятью для поддержки большего адресного пространства;
поддержку архитектур 64-разрядных устройств, например PCI-Х (поддержка такой архитектуры характерна и для дорогих систем IA32);
усовершенствованные возможности разбиения дисков средствами таблиц разделов GUID (GUID Partition Table — GPT) вместо устаревшего механизма главной загрузочной записи MBR;
взаимодействие приложений на основе эмулятора Windows32-on-Windows64 (WOW64);
взаимодействие системного реестра и системных файлов для одновременной работы 32- и 64-разрядных версий приложения.
Windows Server 2003 не только поддерживает полностью новую аппаратную платформу, но и обладает более совершенными средствами поддержки и восстановления работоспособности.
Защита драйверов. В операционной системе Windows Server 2003 появилась новая база данных, содержащая список потенциально некорректных драйверов. Пытаясь установить устройство с помощью одного из этих драйверов, можно получить предупреждение системы и отказ в установке устройства. Для поддержания актуальности списка используется служба Windows Update. Дополнительная информация о списке потенциально некорректных драйверов доступна на Web-странице по адресу www.microsoft. com/hwdev/ driver/drv protect.htm.
Windows Update. Эта возможность впервые стала доступна в операционной системе Windows 2000. С появлением Windows Server 2003 эта служба стала еще лучше. Подписанные цифровой подписью Microsoft обновления можно загружать автоматически, а можно вручную загрузить на центральный сервер для предварительной оценки и тестирования. Служба обновления аппаратных средств (Software Update Service — SUS) от компании Microsoft позволяет автоматизировать загрузку обновлений на центральный сервер, с которого обновления могут устанавливаться после тестирования.
Откат драйверов. Если при модернизации драйвера устройства устройство работает нестабильно, можно воспользоваться функцией отката драйвера (Driver Rollback) для возврата предыдущей версии. Это расширение функции Last Known Good Configuration, которая позволяла восстановить предыдущую версию системного реестра, но не поддерживала откат отдельного драйвера.
Больший раздел системного реестра. Размер системного реестра в операционной системе Windows Server 2003 ограничен только дисковым пространством системного тома. Предыдущие версии операционной системы Windows, включая Windows 2000, ограничивали системный реестр с помощью параметра Registry Size Limit (RSL), значение которого составляло примерно 80% от пула памяти со страничной организацией. Такое изменение значительно улучшает масштабируемость серверов терминалов, в которых каждый пользователь загружает копию пользовательского профиля в оперативную память.
Новая структура системного реестра. Связанные разделы системного реестра (которые называются ячейками (cells)-) хранятся ближе друг к другу. Улучшена поддержка ячеек большого размера. Такие изменения позволяют ускорить операции поиска и загрузки.
Улучшенная отладка. Изменения в ядре и в утилитах отладки режима ядра позволили разработчикам сделать код более компактным. Положительный момент для администраторов заключается в возможности использования тех же инструментов для диагностики.
Улучшенный механизм использования памяти. Изменения в механизме выделения страничной памяти в операционной системе Windows Server 2003 позволяют значительно сократить расход памяти и поддерживают обработку очень больших файлов во время резервного копирования. Кроме этого, теперь для выделения идентичных страниц памяти объемом 4 Кбайт система использует назначение (assignment), а не копирование (coping).
Это не дает таким приложениям, как Web-службы, выделять большие объемы памяти, предоставляя множеству клиентов одинаковые данные. Удвоено общее количество смежных страниц памяти, что благотворно сказывается на серверах терминалов и приложениях, требующих использования больших наборов данных.
Поддержка драйверов большого размера. Объем доступной для драйверов памяти был увеличен с 200 Кбайт в Windows 2000 до 1 Гбайт в операционной системе Windows Server 2003. Это улучшение особенно радует производителей видеоадаптеров.
Поддержка оперативного добавления памяти. Отказоустойчивые серверы Stratus ftServers и серверы на основе технологии IBM Summit позволяют администраторам добавлять оперативную память, не выключая питания. Операционная система Windows Server 2003 поддерживает оперативное увеличение объема оперативной памяти. Но обратите внимание, что обратная операция не поддерживается. Для извлечения модуля оперативной памяти сервер придется отключить.
Улучшенная поддержка многопроцессорной обработки. Процессоры в классических серверах SMP (Symmetrical Multiprocessing — симметричная многопроцессорная обработка) подключены к единственной шине. Шина в такой архитектуре выступает в роли узкого места. Более новые серверы для совместного использования процессоров используют технологию ccNUMA (cache-coherent Non-Uniform Memory Allocation). По технологии ccNUMA процессоры связываются с оперативной памятью, которая расположена физически рядом с процессором. Такие комбинации процессора и памяти соединены друг с другом быстрыми линиями связи, как города Южной Калифорнии соединены бесплатными автомобильными дорогами. Операционная система Windows Server 2003 поддерживает архитектуру ccNUMA, корректно управляя распределением обращений к памяти между “близкой" памятью и “далекой" памятью и обеспечивая близость процессов и данных в памяти.
Усовершенствованная обработка прямого доступа к памяти. Если в системе установлены усовершенствованные приводы АТА, которые используют обеспечиваемые интерфейсом UltraDMA скорости передачи, операционная система Windows Server 2003 сможет намного точнее определить поддерживаемый режим UltraDMA, чем это делали предыдущие версии операционной системы Windows. Кроме этого, операционная система Windows Server 2003 динамически оценивает производительность прямого доступа к памяти и переключает устройство в режим РЮ, если режим DMA приводит к частым ошибкам в передаче данных. Такая функциональная возможность позволяет обеспечить нормальную работу устаревших приводов компакт-дисков.
Улучшенная поддержка отключения устройств. Хотя извлечение компонентов работающего сервера не является стандартной задачей, в системе могут присутствовать сменные носители или периферийные устройства для шины USB. При правильном отключении сначала уведомляется операционная система, но неожиданные отключения являются скорее правилом, чем исключением. Для подготовки к неожиданному извлечению операционная система Windows Server 2003 отключает кэширование записи на всех сменных носителях, кроме приводов с интерфейсом IEEE 1394 FireWire.
Новые возможности управления оборудованием на удаленных серверах. В версию Windows Server 2003 R2 добавлена возможность под названием Hardware Management (Управление оборудованием). Теперь можно использовать WinRM (Windows Remote Management — удаленное управление Windows) для управления аппаратным обеспечением сервера, который находится за брандмауэром, а также следить за состоянием серверов, отключённых от сети.
Функциональное описание архитектуры Windows Server 2003
Заглянем за кулисы архитектуры операционной системы Windows Server 2003. Здесь рассматриваются компоненты архитектуры Windows Server 2003, влияющие на стабильность и производительность системы, включая выделение памяти, поддержку устаревших приложений, защиту памяти, защиту процессов, обработку ввода-вывода и подсистему Plug-and- Play. В каждом разделе рассматриваются различия реализаций для архитектур IA32 и IA64 в системах Windows Server 2003.
Управление памятью в архитектуре IA32
Версия Windows Server 2003 для архитектуры IA32 может непосредственно адресовать до 232 байт памяти, или около 4 Гбайт. Варианты операционной системы Enterprise и Datacenter расширяют поддерживаемое адресное пространство. Этот механизм рассматривается ниже.
Адресное пространство размером 4 Гбайт разделяется на две части по 2 Гбайт. Одна часть выделяется для операционной системы и называется памятью ядра (kernel memory). Вторая часть выделяется для приложений и называется пользовательской памятью (user memory). Разделение памяти позволяет предотвратить выход системы из строя при некорректной работе приложений.
На большинстве серверов не установлен максимально поддерживаемый объем оперативной памяти 4 Гбайт, что не мешает операционной системе использовать все адресное пространство. Процесс VMM (Virtual Memory Manager — диспетчер виртуальной памяти) из подсистемы Executive использует специальные возможности процессора х86 для преобразования виртуальных адресов в физические адреса.
Диспетчер виртуальной памяти действует, как хитрый агент по продаже земельных участков, продавая один участок по нескольку раз. Каждому потоку выделяется собственное адресное пространство размером 4 Гбайт. В каждом виртуальном адресном пространстве сохраняется разделение: половина памяти ядру, половина — приложению. Диспетчер виртуальной памяти в состоянии “подделывать документы”, загружая и выгружая процессы из оперативной памяти и заставляя процессы игнорировать друг друга.
Если бы от диспетчера виртуальной памяти требовалось выделение памяти фрагментами размером в один байт, виртуальная память работала бы слишком медленно и неэффективно. Именно поэтому память выделяется страницами (pages) по 4 Кбайт. Кроме этого, операционная система Windows Server 2003 специально для некоторых приложений и драйверов поддерживает страницы памяти большего размера. Размер больших страниц памяти задается в системном реестре. По умолчанию такие страницы имеют размер 4 Мбайт.
Если работающему процессу требуется выделить пространство физической оперативной памяти, диспетчер виртуальной памяти просматривает страницы других процессов и выбирает не использовавшиеся некоторое время страницы. Эти страницы выгружаются из памяти в один или несколько файлов подкачки на жесткий диск. Операционная система Windows Server 2003 поддерживает до 16 файлов подкачки, хранящихся на разных логических дисках.
Windows Server 2003 поддерживает максимальный размер файла подкачки — 16 Тбайт (именно так: терабайт). По умолчанию размер файла подкачки составляет 150 % от объема оперативной памяти. Размер файла подкачки вычисляется в процессе установки и при дальнейшем добавлении памяти динамически не меняется. При добавлении на сервер модулей памяти следует изменить и размер файла подкачки — это необходимо, если после появления голубого экрана критической ошибки необходимо сохранить дамп всей оперативной памяти. Дополнительная информация приводится в главе 21, “Восстановление после отказов системы”.
Управление памятью в архитектуре IA64
Операционная система Windows Server 2003 для архитектуры IA64 теоретически позволяет адресовать 2“ байт, или 16 эксабайт (16 миллионов терабайтов). Процессоры Itanium и McKinley имеют 44-разрядную адресную шину, что позволяет ограничить виртуальную память максимальным объемом 16 Тбайт (если это можно назвать ограничением).
Физическая память компьютеров на основе процессора Itanium ограничена объемом 16 Гбайт на процессор, что связано с ограничениями чипсета 460GX. Процессор McKinley и соответствующий ему чипсет 870 не имеют таких ограничений. Кроме поддержки большего объема памяти, процессор McKinley имеет шину шириной 128 разрядов, работающую на частоте 400 МГц (сравните с частотой 266 МГц и шириной 64 разряда у процессора Itanium). Кроме этого, кэш-память третьего уровня интегрирована в ядро процессора McKinley, что позволяет добиться пропускной способности 32 Гбит/с (сравните с 12 Гбит/с у процессора Itanium).
Как и для архитектуры IA32, 16 Тбайт адресуемого пространства памяти делятся на две части. Операционной системе выделяется 8 Тбайт и 8 Тбайт выделяется приложениям. Такой объем может показаться избыточным, но через пять или шесть лет даже объема 8 Тбайт может оказаться недостаточно.
На диспетчер виртуальной памяти для архитектуры IA64 возложены те же задачи, что и для архитектуры IA32; он отображает 16 Тбайт виртуального адресного пространства каждого процесса в физическую оперативную память. Конвейерная архитектура процессора IA64 позволяет обрабатывать большое количество инструкций за такт, поэтому способность загруз- ки/выгрузки содержимого памяти оказывается еще более важной, чем в архитектуре IA32. Именно по этой причине версия операционной системы Windows Server 2003 для архитектуры IA64 для подкачки использует страницы размером 8 Кбайт. Архитектура IA64 также поддерживает страницы большого размера.
Операционная система Windows Server 2003 обязательно требует наличия файла подкачки, даже если на компьютере установлено несколько гигабайтов оперативной памяти. Максимальное количество файлов подкачки —16, такое же, как и в архитектуре IA32, но максимальный объем составляет 512 Тбайт. Размер файла подкачки по умолчанию также составляет 150 % от объема оперативной памяти.
Поддержка устаревших приложений в архитектуре IA32
В операционной системе Windows Server 2003 для архитектуры IA32 16-разрядные приложения DOS поддерживаются с помощью специального приложения, которое называется NT Virtual DOS Machine, или ntvdm. exe. NTVDM — это 32-разрядное приложение, которое создает виртуальную 16-разрядНую среду, эмулирующую вызовы BIOS и обработку памяти, характерные для компьютера под управлением операционной системы DOS. Кроме этого, виртуальная машина предоставляет 16-разрядный интерпретатор команд, command, который дополняет 32-разрядный интерпретатор CMD.
Для поддержки 16-разрядных приложений Windows используется подсистема Windows16- on-Windows32 (WOW), wowexe.exe, которая работает внутри виртуальной среды DOS, созданной с помощью NTVDM. Подсистема WOW перехватывает 16-разрядные вызовы Winl6 и выполняет их преобразование в вызовы Win32. Результат преобразования передается подсистеме Windows, в которой результат выполнения вызова передается обратно в подсистему WOW.
По умолчанию каждое 16-разрядное приложение DOS работает в отдельном экземпляре NTVDM, получая собственное адресное пространство. Не забывайте об этом, используя пакетные файлы, которые запускают связанные друг с другом приложения DOS.
С другой стороны, отдельные 16-разрядные приложения Windows по умолчанию работают под управлением единственного экземпляра wowexe. Для запуска каждого приложения в собственном адресном пространстве можно изменить свойства ярлыка. Откройте Properties (Свойства) соответствующего ярлыка, перейдите на вкладку Shortcut (Ярлык) и щелкните на кнопке Advanced (Дополнительно). Откроется окно Advanced Properties (Дополнительные свойства), которое показано на рис. 3.1. Установите флажок Run in separate memory space (Запускать в отдельной области памяти).
Если 16-разрядное приложение запускается в собственном адресном пространстве, для каждого экземпляра приложения будут созданы собственные экземпляры приложений NTVDM и wowexe. Естественно, что это приводит к потреблению дополнительных ресурсов. Кроме этого, использующие общие участки памяти приложения должны работать под управлением одного экземпляра wowexe.
Рис. 3.1. В окне Advanced Properties (Дополнительные свойства) для ярлыка 16-разрядного приложения установлен флажок Run in separate memory space (Запускать в отдельной области памяти)
Поддержка устаревших приложений в архитектуре IA64
Операционная система Windows Server 2003 для архитектуры IA64 не поддерживает запуск 16-разрядных приложений DOS и Windows. Не существует исключений для правила “никакого 16-разрядного кода”, но операционная система Windows Server 2003 содержит обходные механизмы для двух программ установки: программы установки acme от компании Microsoft и программы установки installshield. Эти программы установки используют 16-разрядный код для проверки версии операционной системы. Версия Windows для архитектуры IA64 подставляет исправленную 32-разрядную версию Setupl6 для программы установки acme и Setup для installshield, которые вызываются в момент проверки. Исправленные файлы находятся в каталоге \Windows\SysWOW64.
WOW64
Операционная система Windows Server 2003 для архитектуры IA64 поддерживает запуск 32-разрядных приложений. Эмулятор Windows32-on-Windows64 (WOW64) создает в памяти среду, которая имитирует 32-разрядное адресное пространство и страницы памяти размером 4 Кбайт, которые используются в архитектуре IA32. Кроме этого, подсистема WOW64 перехватывает 32-разрядные вызовы функций и преобразует их в 64-разрядные эквиваленты, перенаправляя их подсистеме Windows.
В отличие от пары приложений NTVDM/wowexe для архитектуры IA32 эмулятор WOW64 не отображается в Task Manager (Диспетчер задач) как отдельный процесс. Эмулятор реализован в виде набора библиотек DLL. Основная задача эмулирования операционной среды возложена на библиотеку wow64 .dll, преобразование вызовов выполняется с помо-
щью wow64cpu.dll, а связь с ядром подсистемы Windows (win32k. sys) осуществляется с помощью библиотеки wow64win.dll. Для облегчения диагностики библиотека wow64exts.dll загружает набор отладочных расширений.
Предоставление полной операционной среды Win32 в совершенно другой операционной системе требует целого ряда служб поддержки. Это значит, что работающее внутри WOW64 32-разрядное приложение потребляет больше памяти и требует большей доли времени центрального процессора. Например, рассмотрим работу приложений Help and Support Center (Центр справки и поддержки) (HelpCtr. ехе и HelpSvs. ехе) под управлением операционной системы Windows Server 2003. Эти два приложения не были полностью перенесены на платформу IA64.
На компьютере с архитектурой IA32 эти приложения совместно потребляют около 10 Мбайт оперативной памяти. На компьютере IA64 эти же приложения потребляют 60 Мбайт оперативной памяти и 82 Мбайт виртуальной памяти.
Такая же разница характерна для всех 32-разрядных приложений. Кроме этого, запуская четыре экземпляра одного приложения, приходится мириться с непроизводительными расходами, кратными количеству экземпляров. Из-за этого архитектура IA64 является подходящим решением только для сервера терминалов с 64-разрядными приложениями (игры в операционной системе для архитектуры IA64 скомпилированы в 64-разрядный код, поэтому начальству можно сказать, что игры используются для тестирования).
Отображение системного реестра
Подсистема WOW64 позволяет решить проблемы различий в системном реестре для 32- и 64-разрядных приложений. Например, очередь сообщений и распределенное отслеживание транзакций поддерживается только для 64-разрядных приложений, поэтому соответствующие разделы системного реестра должны быть невидимыми для 32-разрядных приложений.
Для обеспечения необходимых модификаций системного реестра операционная система Windows для архитектуры IA64 использует прием, применявшийся в сказке Белоснежка и семь гномов. Операционная система создает зеркало, которое всегда говорит правду, но только ту часть правды, которую хочет услышать владелец. Вот как это работает.
Системный реестр на компьютере с архитектурой IA64 содержит специальный подраздел в разделе HKLM\Software. Этот подраздел называется Wow6432Node и содержит копию раздела HKLM\Sof tware со специальными элементами, подходящими для использования в 32- разрядных приложениях. Подсистема WOW64 реализует функцию Registry reflector (отображение реестра), которая поддерживает соответствие данных между разделами HKLM\Sof tware и HKLM\Software\Wow6432Node.
Перенаправление файловой системы
Папка с системными файлами для архитектуры IA64 называется System32, как и в операционной системе для архитектуры IA32. Кроме этого, большинство файлов операционной системы имеют те же имена, хотя и скомпилированы в 64-разрядный код.
Это ставит 32-разрядные приложения в сложное положение. Любая попытка подключить системную библиотеку завершится неудачно. 32-битовые приложения не могут использовать 64-разрядные библиотеки, и наоборот. В каталоге \Windows\SysWOW64 система предоставляет полный набор 32-разрядных библиотек операционной системы. При попытке доступа к файлам поддержки через функции API приложения перенаправляются в этот каталог.
Эффективность такого подхода для эмуляции можно будет определить со временем. Компания Microsoft будет вынуждена выпустить пакет обновлений IA64, который исправит как код IA64, так и код IA32, который используется в эмуляторе. В приложениях IA64 могут быть обнаружены ошибки в системе безопасности. Исправление этих уязвимых мест потребует внесения изменений в смежные файлы IА32, а это еще больше усложнит создание исправлений.
Все 32-разрядные версии файлов операционной системы хранятся на установочном компакт-диске операционной системы Windows Server 2003 в каталоге 13 8 6. Файлы для архитектуры IA64 хранятся в каталоге IA64. По наличию буквы W в начале имени файла можно легко отличить 32-разрядные версии файлов от их 64-разрядных аналогов. При копировании файлов в каталог \Windows \ Sy SWOW6 4 буква w из имени файла удаляется.
Неподдерживаемые возможности и приложения, отсутствующие в поставке
Несколько приложений и некоторые возможности, доступные для архитектуры IA32, не предоставляются вместе с операционной системой Windows Server 2003 для архитектуры IA64. Можно перечислить такие возможности и приложения.
Активация операционной системы Windows. Компания Microsoft предполагает, что этот продукт не будет распространяться нелегально.
Удаленный помощник. Удаленное управление обеспечивается с помощью приложения Remote Desktop (Удаленный рабочий стол), но пользователь архитектуры IA64 не может отправить “приглашение” для удаленного помощника.
32-разрядные элементы управления ActiveX. Браузер Internet Explorer для архитектуры IA64 не поддерживает использование 32-разрядных библиотек и надстроек.
Возможности, ориентированные на настольный компьютер. Среди этих возможностей можно перечислить возможность записи компакт-дисков, Windows Media Player (WMP), Windows Messenger, интегрированную поддержку файлов для устройств Zip, а также копирование настроек пользователей. Загрузив с сайта Microsoft последнюю версию, на компьютер можно установить 32-разрядную версию WMP или Windows Messenger.
Возможности работы в сети. Среди отсутствующйх возможностей можно назвать службу Network Bridge (Сетевой мост), поддержку модемов с инфракрасным портом, службу Internet Connection Sharing (общий доступ к подключению Internet) и Home Networking Wizard (Мастер установки домашней сети).
Edlin. Почтим смерть этого текстового редактора минутой молчания и вставанием.
Пулы памяти
Для предотвращения отказа операционной системы при чрезмерном потреблении памяти пользовательскими процессами некоторая часть оперативной памяти выделяется исключительно для нужд процессов, выполняющихся в ядре. Эта память выделяется в виде двух пулов: выгружаемого (paged) и невыгружаемого (non-paged).
Выгружаемый пул памяти. Память выгружаемого пула может быть выгружена в файл подкачки. При использовании архитектуры IA32 выгружаемый пул ограничен объемом 470 Мбайт. В архитектуре IA64 максимальный размер выгружаемого пула памяти составляет 128 Гбайт. Увеличенный объем выгружаемого пула позволяет избежать ситуаций, когда система начинает работать нестабильно и выводит сообщения об ошибке Out of Resource и сообщения об ошибках службы RPC при исчерпании ресурсов выгружаемого пула памяти. Наиболее распространенной причиной растраты ресурсов выгружаемого пула памяти является чрезмерное увеличение размера системного реестра, но для операционной системы Windows Server 2003 эта проблема не характерна, поскольку для системного реестра не используется память выгружаемого пула.
Невыгружаемый пул памяти. Память из невыгружаемого пула должна полностью и постоянно находиться в физической оперативной памяти. Размер выделяемой для невыгру-
жаемого пула памяти зависит от размера выгружаемого пула. В архитектуре IA32 размер невыгружаемого пула ограничен объемом 256 Мбайт. В архитектуре IA64 максимальный размер невыгружаемого пула составляет 128 Гбайт. Невыгружаемый пул памяти является ценным ресурсом системы, поэтому разработчикам программ рекомендуется использовать минимальный объем невыгружаемого пула, но иногда возникают ситуации, когда страницы памяти должны находиться за пределами файла подкачки. Например, зашифрованная файловая система хранит ключи шифрования в невыгружаемом пуле памяти.
Объем физической и виртуальной памяти, выделенной для процесса, а также объем выделенного пула памяти ядра можно узнать с помощью Task Manager (Диспетчер задач). Перейдите на вкладку Processes (Процессы). Выберите команду меню View1^ Select Columns (Вид1^ Выбрать столбцы) и выберите столбцы, которые появятся на странице процессов диспетчера задач. На рис. 3.2 показан пример окна Task Manager (Диспетчер задач) для архитектуры IA32, а на рис. 3.3 — для архитектуры IA64.
Рис. 3.2. Окно диспетчера задач с информацией о потреблении памяти запущенными процессами
При выделении слишком большого объема из выгружаемого или невыгружаемого пула памяти для приложения или драйвера устройства может произойти отказ системы в результате одной операции, но чаще всего такая аномальная ситуация возникает в результате длительной утечки памяти. Операционная система Windows Server 2003 имеет улучшенную защиту от ошибок подобного типа. Такая защита обеспечивается благодаря мониторингу некорректных выделений памяти.
0045,936 К0042,800 К0042,792 К0034,416 К0027,184 К0021,840К0017,280К0016,264К0016,016К0014,112К0013,936К0013,856К0212,632К0012,536К0011,056К007,568К007,416К006,256К003,856К001,240К00296К9656К0045,936 К0042,800 К0042,792 К0034,416 К0027,184 К0021,840К0017,280К0016,264К0016,016К0014,112К0013,936К0013,856К0212,632К0012,536К0011,056К007,568К007,416К006,256К003,856К001,240К00296К9656К14,584 К159 К10,328 К116 К8,216 К109 К10,112 К101 К77,592 К 68,695 К3,824 К83К6,416 К54 К4,592 К81 К9,888 К125 К3,448 К63 К2,448 К74 К2,344 К70 К1,904 К70К2,160 К44 К2,024 К65 К1,056 К52 К1,896 К63 К6,296 К84 К2,720 К29 К384 КЮК64К0К0К0К14,584 К159 К10,328 К116 К8,216 К109 К10,112 К101 К77,592 К 68,695 К3,824 К83К6,416 К54 К4,592 К81 К9,888 К125 К3,448 К63 К2,448 К74 К2,344 К70 К1,904 К70К2,160 К44 К2,024 К65 К1,056 К52 К1,896 К63 К6,296 К84 К2,720 К29 К384 КЮК64К0К0К0К
0045,936 К
0042,800 К
0042,792 К
0034,416 К
0027,184 К
0021,840К
0017,280К
0016,264К
0016,016К
0014,112К
0013,936К
0013,856К
0212,632К
0012,536К
0011,056К
007,568К
007,416К
006,256К
003,856К
001,240К
00296К
9656К
0045,936 К
0042,800 К
0042,792 К
0034,416 К
0027,184 К
0021,840К
0017,280К
0016,264К
0016,016К
0014,112К
0013,936К
0013,856К
0212,632К
0012,536К
0011,056К
007,568К
007,416К
006,256К
003,856К
001,240К
00296К
9656К
14,584 К159 К
10,328 К116 К
8,216 К109 К
10,112 К101 К
77,592 К 68,695 К
3,824 К83К
6,416 К54 К
4,592 К81 К
9,888 К125 К
3,448 К63 К
2,448 К74 К
2,344 К70 К
1,904 К70К
2,160 К44 К
2,024 К65 К
1,056 К52 К
1,896 К63 К
6,296 К84 К
2,720 К29 К
384 КЮК
64К0К
0К0К
14,584 К159 К
10,328 К116 К
8,216 К109 К
10,112 К101 К
77,592 К 68,695 К
3,824 К83К
6,416 К54 К
4,592 К81 К
9,888 К125 К
3,448 К63 К
2,448 К74 К
2,344 К70 К
1,904 К70К
2,160 К44 К
2,024 К65 К
1,056 К52 К
1,896 К63 К
6,296 К84 К
2,720 К29 К
384 КЮК
64К0К
0К0К
f*Or.e*Я*Й6*:
svchost.exeSYSTEM
explorer, exeAdministrator
IEXPLORE.EXEAdrrrtstrator
mmc.exeAdministrator
HelpSvc.exeSYSTEM
HelpHost.exeAdministrator
services.exeSYSTEM
spoolsv.exeSYSTEM
wriogon.exeSYSTEM
cmd.exeAcininistrator
svchost.exeSYSTEM
svchost.exeLOCAL SERVICE
teskmgr.exeAdministrator
wmiprvse.exeSYSTEM
svchost.exeNETWORK SERVICE
notepad.exeAcininistrator
csrss.exeSYSTEM
lsass.exeSYSTEM
cmd.exeAdministrator
smss.exeSYSTEM
Sv$TemSYSTEM
System Ide Process SYSTEM
г SssasassisEMieS.{
««esses: 23 OMUIsejeZ* CeeaCChaiige: Э1ЭН/ММ*~” . .
Рис. 3.3. Список процессов в окне Task Manager (Диспетчер задач) с информацией о потреблении памяти для архитектуры IA64
Специальные функции по работе с памятью для архитектуры IA32
“Плоское” адресное пространство объемом 16 Тбайт, характерное для архитектуры IA64, а также возможность непосредственной адресации многих гигабайтов физической оперативной памяти делают данную платформу привлекательной для крупных баз данных. Для использования расширенных возможностей адресации приложение должно быть откомпилировано в 64-разрядный код. Максимальный размер адресного пространства для 32-разрядного приложения, запущенного на компьютере с архитектурой IA64, составляет 2 Гбайт. Пока не будут выпущены популярные приложения специально для платформы IA64, сохраняется необходимость в специальных механизмах расширения адресного пространства для архитектуры IA32. На данный момент существует несколько таких механизмов.
4GB Memory Tuning (4GT)
Разделение памяти на память для процессов и память для ядра по 2 Гбайт является полностью произвольным. Такое разделение позволяет использовать простой алгоритм “знакового бита” для определения принадлежности страницы той или иной половине памяти.
Хотя до определенного момента на серверы не устанавливали больше 2 Гбайт оперативной памяти, на момент написания книги по данным компании Pricewatch (www. pricewatch. com) модули памяти DDR DIMM объемом 512 Мбайт стоят около 70 долларов, а это значит, что установка на сервер 4 Гбайт оперативной памяти абсолютна реальна. Главным ограничением является не цена, а количество разъемов для установки модулей DIMM на материнской плате и возможности чипсета по поддержке установленного объема оперативной памяти.
Если на сервере установлено 4 Гбайт оперативной памяти, операционная система не будет использовать больше 1 Гбайт из выделенных ей 2 Гбайт. Если на компьютере с архитектурой IA32 работает приложение, способное использовать более 2 Гбайт оперативной памяти, в операционной системе Windows Server 2003 доступна возможность 4GB Memory Tuning (4GT), которая позволяет передать 1 Гбайт виртуальной памяти от операционной системы приложению. Для этого используется другой метод маркировки страниц.
Для включения функции 4GT добавьте параметр /3GB в путь ARC, согласно которому операционная система выбирается из файла boot. ini. Самым простым способом является непосредственное редактирование файла. Утилита bootcfg не имеет параметра для добавления необходимой последовательности символов (/3GB). Ниже показан пример внесения необходимых изменений.
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Standard Edition" /fastdetect /3GB
В операционной системе Windows 2000 функция 4GT поддерживалась только в версиях Advanced Edition и Datacenter Edition. В операционной системе Window's Server 2003 эта возможность поддерживается во всех версиях для архитектуры IA32. В версиях для архитектуры IA64 эта функция не поддерживается.
При использовании функции 4GT Tuning существуют некоторые подводные камни. Например, не стоит использовать параметр /3GB для версии Datacenter Edition, работающей на компьютере с оперативной памятью объемом 16 Гбайт. Кроме этого, параметр /3GB сокращает объем оперативной памяти, выделенный для выгружаемого пула памяти, а это приводит к проблемам в работе серверов терминалов. При использовании сервера Exchange 2000 стоит добавлять параметр /3GB, даже если на компьютере установлен только 1 Гбайт оперативной памяти. В этом случае появляется возможность использования больших образов файлов в памяти.
Address Windowing Extension (AWE)
В конце сказки Волшебник страны Оз (Волшебник изумрудного города?) Дороти узнала, что башмачки в любой момент могут вернуть ее в Канзас; достаточно только знать, как ими воспользоваться. Точно такое же ощущение посещает многих администраторов, когда они узнают, что процессоры семейства Pentium начиная с Pentium Pro могли адресовать больше 4 Гбайт оперативной памяти. Этот процессор имеет 36-разрядную шину памяти, что позволяет адресовать 236 байт или 64 Гбайт оперативной памяти.
Компания Intel различными способами использовала возможности адресации 36-разрядной шины. Последним решением является архитектура Extended Server Memory Architecture, которая предоставляет набор Page Size Extensions с помощью режима процессора PSE36. Для использования 36-разрядной адресации памяти в версиях Enterprise и Datacenter операционной системы Windows Server 2003 используют API А ИТ (Address Windowing Extensions — расширение окон адресации).
При помощи AWE приложение перемещает страницы памяти из области за пределами 4 Гбайт в область, где приложение может изменить содержимое страницы. Таким приложениям, как SQL Server, это позволяет использовать большие наборы данных с управлением наборами в оперативной памяти, а не через медленный файл подкачки.
Приложение должно поддерживать интерфейс AWE и использовать соответствующие вызовы функций. Установка на сервере более 4 Гбайт оперативной памяти не имеет смысла, если на сервере не работает поддерживающее интерфейс AWE приложение и операционная
система Windows Server 2003 не поддерживает функции РАЕ (Physical Address Extensions — расширение физических адресов).
Операционная система Windows Server 2003 Standard Edition не поддерживает функции РАЕ и, таким образом, не поддерживает оперативную память объемом более 4 Гбайт. Операционная система Windows Server 2003 Enterprise Edition позволяет использовать РАЕ, но для поддерживаемого объема оперативной памяти искусственно установлено ограничение на уровне 32 Гбайт. Операционная система Windows Server 2003 Datacenter Edition поддерживает механизм РАЕ в полном объеме, позволяя использовать до 64 Гбайт оперативной памяти. Компьютеры на основе архитектуры IA64 технологию РАЕ не используют.
Для активизации технологии РАЕ добавьте параметр /рае в строку пути ARC в файле boot. ini. Утилита bootcfg не имеет параметра, позволяющего добавить необходимую последовательность символов, поэтому файл boot. ini необходимо отредактировать вручную. Если загрузка сервера завершается неудачно, значит, на данной платформе механизм РАЕ не поддерживается. Перезагрузите компьютер в Safe Mode (Безопасный режим) и восстановите соответствующую строку в файле boot. ini.
Защита процессов
В операционной системе Windows Server 2003 используются аппаратные элементы защиты, предоставляемые архитектурами IA32 и IA64. Получающие непосредственный доступ к аппаратным ресурсам компьютера операции с высокими привилегиями запускаются только из кода, который выполняется в пределах подсистемы Windows Executive (рис. 3.4).
Рис. 3.4. Схема подсистемы Windows Executive
Подсистема Executive состоит из драйвера ядра, ntoskrnl. ехе, который связан с библиотекой функций уровня аппаратных абстракций (Hardware Abstraction Layer — HAL) hal. dll. Эта библиотека работает вместе с целым набором системных служб и драйверов. Для поддержки механизма адресации РАЕ используется дополнительный драйвер ядра ntkrnlpa.ехе.
Загружаемая программой установки версия ядра зависит от аппаратных средств компьютера. Если материнская плата использует интерфейс ACPI, программа установки загружает ядро, поддерживающее ACPI. Если материнская плата ACPI не поддерживает, загружается ядро Standard PC. Для сервера на основе процессора Itanium всегда используется ядро с поддержкой ACPI.
В процессе установки всегда используется ядро с поддержкой нескольких процессоров. Если ядро определяет, что на компьютере установлен один процессор, для постоянного использования загружается однопроцессорная версия ядра.
Структура подсистемы Windows Executive
Кроме ядра и уровня аппаратных абстракций, остальные службы подсистемы Executive группируются по используемым или контролируемым структурам данных или процессам. За некоторыми исключениями такие группы служб называются диспетчерами (manager).
Все службы Executive работают в режиме ядра, свободно обмениваясь данными друг с другом. Версия для архитектуры IA64 использует ту же структуру подсистемы Executive, что и версия для архитектуры IA32. Ниже приведен список диспетчеров и других поставщиков служб, входящих в состав подсистемы Executive операционной системы Windows Server 2003.
Поддержка служб Executive. Службы, предоставляющие выделение пула памяти, а также специальную обработку очереди и потоков, которая не предоставляется драйвером ядра.
Диспетчер Plug and Play. Службы инвентаризации и определения возможностей аппаратных средств.
Диспетчер управления питанием. Службы, определяющие политики спящего режима, режима ожидания и пробуждения для различных устройств.
Диспетчер ввода-вывода. Службы управления потоком данных на внешние устройства хранения и на сетевые устройства. В состав диспетчера входят драйверы устройств, непосредственно получающие доступ к аппаратным средствам в обход ядра или уровня аппаратных абстракций.
Диспетчер объектов. Службы управления символическими ссылками и структурами данных из пространства имен объектов.
Монитор ссылок безопасности. Службы управления доступом к объектам Windows Server 2003.
Диспетчер процессов. Службы структурной обработки потоков устройств.
Диспетчер конфигурации. Эта служба отвечает за структуру и компоненты системного реестра.
Механизм локального вызова процедур. Интерфейс клиент/сервер высокого уровня между пользовательскими процессами и системными службами.
Диспетчер виртуальной памяти. Службы, отображающие виртуальную память на физическую и управляющие выделением непрерывных участков памяти.
Win32K. Службы управления графической подсистемой и управления окнами. В состав этого компонента входят драйверы, непосредственно работающие с аппаратными средствами видеоадаптеров и принтеров в обход ядра и уровня аппаратных абстракций.
В операционной системе Windows Server 2003 больше нет подсистем OS/2 и POSIX. Поддержка POSIX может быть предоставлена вместе с отдельным продуктом, который называется Interix. Продукт стоит около 80 долларов. Дополнительная информация доступна по адресу www.microsoft.com/windows2000/interix (Interix работает как под управлением операционной системы Windows 2000, так и под управлением операционной системы Windows Server 2003).
Разделение процессов
Приложениям не разрешено непосредственно использовать системные службы подсистемы Executive. Вместо этого приложения используют вызовы API, которые обрабатываются подсистемой Windows. (Подсистема Windows раньше называлась Win32. Теперь, когда есть версия операционной системы для архитектуры IA64, компания Microsoft выбрала более универсальный термин.)
Подсистема Windows состоит из компонентов ядра (файл win32k.sys), набора компонентов для работы на стороне пользователя, Client/Server Runtime Subsystem (CSRSS) и динамически подключаемых библиотек, преобразовывающих пользовательские вызовы API в вызовы ядра библиотек DLL. Приложениям пользовательского режима не разрешено работать в привилегированном адресном пространстве подсистемы Executive и даже запрещено непосредственно обращаться к подсистеме Executive. В отличие от политических систем, разделение руководителей и рабочих делает систему очень устойчивой к авариям и нестабильностям.
Интерактивные отчеты о неисправностях
Если работа приложения приводит к ошибке защиты, стек и информация о процессе сохраняются с помощью утилиты DrWatson. Существует два варианта этой утилиты: drwatson. ехе для 16-разрядных приложений и drwt$n32 . ехе для 32-разрядных приложений.
Программа DrWatson сохраняет информацию об отказавшем приложении в файле журнала в профиле All Users в каталоге \Application Data\Microsoft\DrWatson (на компьютерах с архитектурой IA64 в названии утилиты присутствует пробел — Dr Watson.)
Кроме этого, после завершения работы утилиты DrWatson запускается утилита dwwin, которая создает файлы отчета в пользовательском каталоге Тетр. Для сбора информации о состоянии компьютера непосредственно перед отказом эта функция использует службу ERSvc (Error Reporting Service — Служба регистрации ошибок). После этого у пользователя запрашивается разрешение на отправку отчета об ошибке компании Microsoft.
Собранная службой ERSvc информация сохраняется в виде базы данных XML и в упакованном виде отправляется компании Microsoft через защищенное соединение (обеспеченное с помощью Secure Sockets Layer) по протоколу HTTP. В интерактивный отчет об ошибке включен большой объем информации, например имя каждого загруженного в момент ошибки приложения и драйвера. Если по ряду причин эта информация не должна выходить за пределы организации, отключите интерактивные отчеты об ошибках. Это можно сделать несколькими способами.
Отключите интерактивные отчеты об ошибках, щелкнув правой кнопкой мыши на пиктограмме Му Computer (Мой компьютер), расположенной на рабочем столе, и выбрав в контекстном меню пункт Properties (Свойства). Перейдите на вкладку Advanced (Дополнительно), щелкните на кнопке Error Reporting (Отчет об ошибках) и установите переключатель Disable Error Reporting (Отключить отчет об ошибках), как показано на рис. 3.5.
Отключите службу ERSvc в оснастке Services (Службы) консоли Computer Management (Управление компьютером).■
Включите групповую политику Disable Error Reporting (Отключить отчет об ошибках) в объекте групповой политики подразделения или контейнера, содержащего интересующий сервер. ■"■
Драйверы устройств
В большинстве случаев операционная система защищена от вредоносных действий пользовательских приложений. Этого нельзя сказать о драйверах устройств. Драйверы могут работать в режиме ядра, где они получают доступ ко всем привилегированным процессам в под-
системе Executive. Если драйвер потребляет слишком большой объем памяти или пытается получить доступ к памяти, выделенной для другого процесса, или пытается воспользоваться процессором, когда он занят более важными задачами, сервер может “зависнуть” или выдать ошибку исключения, что приводит к появлению bugcheck, известного, как “синий экран смерти”. В главе Ошибка! Источник ссылки не найден, приводится дополнительная информация о причинах появления таких сообщений об ошибках и методах их диагностики.
Рис. 3.5. Настройка параметров службы Error Reporting (Отчет об ошибках) как части параметров системы для сервера
К счастью, в операционной системе Windows Server 2003 количество неожиданных аварий из-за созданных с ошибками драйверов должно уменьшиться. Для этого предназначена новая функция Windows Driver Protection (Защита драйверов Windows). Она препятствует установке драйверов устройств, содержащих ошибки, т.е. драйверов, которые могут стать причиной непредсказуемого поведения системы (“зависания”) или неожиданного завершения работы (“синего экрана”). Чтобы определить, какие драйверы не следует загружать или устанавливать, используется поддерживаемая корпорацией Microsoft база данных драйверов, содержащих ошибки. При попытке загрузки такого драйвера система выдает предупреждение о возможной несовместимости и перенаправляет администратора на соответствующую страницу Help and Support Center (Центр справки и поддержки), на которой описывается причина возможной несовместимости. Компания Microsoft регулярно обновляет эту базу данных и предоставляет обновленные версии драйверов с помощью службы Windows Update.
Можно догадаться, что производитель драйвера будет недоволен, если его драйвер окажется в перечне опасных драйверов Microsoft. Одним из предполагаемых положительных результатов программы защиты драйверов является дополнительное повышение внимания производителей при создании драйверов. Список драйверов доступен по адресу www.microsoft.com/hwdev.
Кроме этого, операционная система Windows Server 2003 намного лучше справляется с задачей выбора наиболее подходящего драйвера из нескольких альтернативных вариантов (драйверы могут храниться в каталоге INF, на компакт-диске, на гибких дисках и на сайте Windows Update). Если для устройства найдено несколько драйверов, они сортируются в соответствии со следующими критериями.
Драйверы с цифровой подписью устанавливаются до драйверов без подписи, даже если первые только “совместимы” с устройством, а вторые точно соответствуют устройству.
Драйверы без цифровой подписи, для которых присутствует соответствующий для Windows NT раздел в сценарии INF, устанавливаются до аналогичных драйверов без такого раздела.
Обработка ввода-вывода
Операционная система Windows Server 2003 поддерживает многозадачность, но даже Билл Гейтс и Энди Грувс не в состоянии преодолеть фундаментальное ограничение современных компьютеров: один центральный процессор в любой момент времени может выполнять только одну задачу. Операционная система Windows Server 2003 может только создать ощущение одновременного выполнения нескольких задач, как кинопленка дает ощущение движущегося изображения.
При распределении тактов процессора между различными процессами операционная система Windows Server 2003 использует вытесняющую многозадачность. Каждому потоку поочередно выделяется время процессора. Выделенное время зависит от временного интервала, или кванта времени (quantum timeslice). На рабочих станциях используются короткие интервалы времени, а на серверах устанавливаются более длинные интервалы.
Приблизительное значение временного интервала можно задать даже через пользовательский интерфейс. Этот параметр доступен на вкладке Advanced (Дополнительно) окна System Properties (Свойства системы). Это окно можно открыть, если воспользоваться Control Panel (Панель управления) или щелкнуть правой кнопкой на пиктограмме Му Computer (Мой компьютер) и выбрать из контекстного меню команду Properties (Свойства). Пример этого окна показан Иа рис. 3.6. Приблизительный размер временного интервала можно задать в разделе Processor Scheduling (Распределение времени процессора). При этом можно выбрать большую производительность для приложений (Applications) или для служб, работающих в фоновом режиме (Background Services). Для предпочтительного использования приложений устанавливается меньший размер временного интервала. При выборе фоновых служб используется больший размер временного интервала. Кроме этого, в окне System Properties (Свойства системы) можно выбрать предпочтение при выделении памяти (для программ или системного кэша).
Рис. 3.6. В окне System Properties (Свойства системы), на вкладке Advanced (Дополнительно), можно установить значения для параметров Processor Scheduling и Memory Usage
Для координации действий в подсистеме Windows Executive используется обработчик прерываний. Обработчик перехватывает прерывания из двух источников: программного обеспечения и аппаратных средств. Аппаратные прерывания генерируются устройствами, которым требуется время центрального процессора. Программные прерывания генерируются
приложениями, которые запрашивают центральный процессор после завершения обработки другого события.
Каждый поток работает на определенном уровне запроса прерывания или IRQL. Например, определенный поток может запросить IRQL, равный 7, на котором он был запущен (существует 32 уровня IRQL, где больший номер соответствует большему приоритету). Поток в течение выделенного для него временного интервала может быть прерван только пото- 'ками с уровнем запроса прерывания 8 или выше.
В большинстве случаев установка приоритетов для потоков находится вне контроля администратора. В то же время команда start позволяет запросить определенный уровень приоритета. Существует четыре класса приоритета (Low, Normal, High, Realtime), а также два уровня для повышения и уменьшения приоритета в рамках одного класса (Abovenormal и Belownormal). Если приложение должно работать с высоким приоритетом, опытные пользователи могут воспользоваться следующей командой:
start /High /Abovenormal АРР.EXE
Стоит отметить, что автор этой книги долго экспериментировал с различными приоритетами IRQL и параметрами команды start и так и не обнаружил пользы от изменения приоритетов. Производительность возрастает только тогда, когда диспетчеру потоков не хватает циклов центрального процессора и диспетчер начинает сортировку потоков. До такого состояния пользователи доводят свои рабочие станции очень редко. Обычно в такой ситуации вместо поиска способов запуска пожирающих ресурсы приложений просто завершают работу одного или более приложений.
Аппаратные прерывания
Для получения процессорного времени устройства используют аппаратные прерывания (IRQ). Без аппаратных прерываний процессор не смог бы получать информацию от системных часов, сетевых адаптеров, мыши, клавиатуры и других периферийных устройств.
Аппаратные прерывания вызывают процессор, как дворецкого вызывают в старых английских домах. Шнур в углу каждой комнаты проходит через все стены дома и заканчивается на кухне, где подключается к одному из множества небольших колокольчиков. Как только в бильярдной дергают за шнур, дворецкий слышит звонок и смотрит, какой колокольчик звенит. После этого дворецкий берет карточку размером 3x5, которая называется “Бильярдная” и содержит инструкции “Доставить скотч и сигары в бильярдную”. Дворецкий прерывает текущее занятие (полировку серебра, просмотр журнала или другую деятельность) и выполняет полученные инструкции.
Существует вероятность, что процедура обработки прерывания (инструкция, связанная с прерыванием) начнет работу в неподходящее время, когда более одного устройства пытаются получить прерывание. Интерфейс ACPI обеспечивает решение этой проблемы, создавая таблицу маршрутизации линий запроса прерывания. Это позволяет нескольким устройствам использовать одно прерывание. На сайте www.tssc.de компания APSoft предлагает программу PCIScope, позволяющую просматривать такие элементы интерфейса ACPI, как таблица маршрутизации IRQ. На рис. 3.7 показан пример окна этой программы.
Для просмотра устройств и назначенных им ресурсов можно воспользоваться оснасткой Device Manager (Диспетчер устройств), файл devmgmt. msc. В этой оснастке также легко определить совместно используемые IRQ. Из меню выберите View^Devices by Туре (Видс> Устройства по типу). На рис. 3.8 показан список IRQ ресурсов. Обратите внимание на значительное количество устройств, которые используют прерывание IRQ 9.
Все современные компьютеры оборудованы контроллером Advanced Programmable Interrupt Controller (APIC), который при поддержке Windows Server 2003 позволяет назначать устройствам прерывания выше 15. На рис. 3.9 показан список устройств компьютера на основе Pentium 4 и набора микросхем Intel 850.
iwel «**•» •*, ■*•!•• te-euf ■ Uiwel «**•» •*, ■*•!•• te-euf ■ U-.а1 X-.а1 X:Vl^i1*VWiWCi:8w::>ti*Vy 3^■П/црУ ' I:Vl^i1*VWiWCi:8w::>ti*Vy 3^■П/црУ ' I■ 01 ЛО Intel Corporation -82850/82960 (950/860) Processor to AGP Bridge (MCH)■ IE:00 Intel Corporation - 82801BA (ICH2) PG BridgeS W Multfunctional device (Intel Corporation)I ■ 1F;OO Intel Corporation-92801BA (ICH2) LPC InterfaceControler: ■ IF:01 Intel Corporation - 62Я01ВА (ICH2) LXraDMAjlOO IDE Controler■ IF:02 Intel Corporation - 92801BA/BAM (ICH2) USB Urtversai Host ControlerM 1F:O3 intel Corporation - 82801BA/BAM (ICH2) SMBus Controler■ 1F>(H Intel Corporation - 92801BA/BAM (ICH2) USB Universe Host ControlerЙ 9 SuaOlh- ■ 00:00 Nvida Corp-GeForce2 MX [Wil]r:^Bu$02hУ fill Mukfuictionai device (Creative Labs)* 07:00 Geative L4e - EMU10K1 Audo O*set■ 07:01 Creatively* - PCI Gameport Joystick■ 09:00 ЭСОМ Corp, Networking Division - ЭС905С-ТХ Fast Etherink for PC Managen*■ 01 ЛО Intel Corporation -82850/82960 (950/860) Processor to AGP Bridge (MCH)■ IE:00 Intel Corporation - 82801BA (ICH2) PG BridgeS W Multfunctional device (Intel Corporation)I ■ 1F;OO Intel Corporation-92801BA (ICH2) LPC InterfaceControler: ■ IF:01 Intel Corporation - 62Я01ВА (ICH2) LXraDMAjlOO IDE Controler■ IF:02 Intel Corporation - 92801BA/BAM (ICH2) USB Urtversai Host ControlerM 1F:O3 intel Corporation - 82801BA/BAM (ICH2) SMBus Controler■ 1F>(H Intel Corporation - 92801BA/BAM (ICH2) USB Universe Host ControlerЙ 9 SuaOlh- ■ 00:00 Nvida Corp-GeForce2 MX [Wil]r:^Bu$02hУ fill Mukfuictionai device (Creative Labs)* 07:00 Geative L4e - EMU10K1 Audo O*set■ 07:01 Creatively* - PCI Gameport Joystick■ 09:00 ЭСОМ Corp, Networking Division - ЭС905С-ТХ Fast Etherink for PC Managen*
iwel «**•» •*, ■*•!•• te-euf ■ U
iwel «**•» •*, ■*•!•• te-euf ■ U
-.а1 X
-.а1 X
:Vl^i1*VWiWCi:8w::>ti*Vy 3^■П/црУ ' I
:Vl^i1*VWiWCi:8w::>ti*Vy 3^■П/црУ ' I
■ 01 ЛО Intel Corporation -82850/82960 (950/860) Processor to AGP Bridge (MCH)
■ IE:00 Intel Corporation - 82801BA (ICH2) PG Bridge
S W Multfunctional device (Intel Corporation)
I ■ 1F;OO Intel Corporation-92801BA (ICH2) LPC InterfaceControler
: ■ IF:01 Intel Corporation - 62Я01ВА (ICH2) LXraDMAjlOO IDE Controler
■ IF:02 Intel Corporation - 92801BA/BAM (ICH2) USB Urtversai Host Controler
M 1F:O3 intel Corporation - 82801BA/BAM (ICH2) SMBus Controler
■ 1F>(H Intel Corporation - 92801BA/BAM (ICH2) USB Universe Host Controler
Й 9 SuaOlh
- ■ 00:00 Nvida Corp-GeForce2 MX [Wil]
r:^Bu$02h
У fill Mukfuictionai device (Creative Labs)
* 07:00 Geative L4e - EMU10K1 Audo O*set
■ 07:01 Creatively* - PCI Gameport Joystick
■ 09:00 ЭСОМ Corp, Networking Division - ЭС905С-ТХ Fast Etherink for PC Managen*
■ 01 ЛО Intel Corporation -82850/82960 (950/860) Processor to AGP Bridge (MCH)
■ IE:00 Intel Corporation - 82801BA (ICH2) PG Bridge
S W Multfunctional device (Intel Corporation)
I ■ 1F;OO Intel Corporation-92801BA (ICH2) LPC InterfaceControler
: ■ IF:01 Intel Corporation - 62Я01ВА (ICH2) LXraDMAjlOO IDE Controler
■ IF:02 Intel Corporation - 92801BA/BAM (ICH2) USB Urtversai Host Controler
M 1F:O3 intel Corporation - 82801BA/BAM (ICH2) SMBus Controler
■ 1F>(H Intel Corporation - 92801BA/BAM (ICH2) USB Universe Host Controler
Й 9 SuaOlh
- ■ 00:00 Nvida Corp-GeForce2 MX [Wil]
r:^Bu$02h
У fill Mukfuictionai device (Creative Labs)
* 07:00 Geative L4e - EMU10K1 Audo O*set
■ 07:01 Creatively* - PCI Gameport Joystick
■ 09:00 ЭСОМ Corp, Networking Division - ЭС905С-ТХ Fast Etherink for PC Managen*
Рис. 3.7. Программа PCIScope позволяет просматривать таблицу маршрутизации ACPI, таблицу маршрутизации BIOS и информацию заголовка PCI для каждого устройства
j»e.3E5SSS*S5t
$ Ml Direct memory access (DMA)
a Ml Inpa/oUput (10)
В Ml Interrupt request (IRQ)
Ш(БА)0 Systemtimer
i 3(BA) t Standard 101/102-Key or Mkrosoft Natural PS/2 Keyboard
! ^(ISA)3 Commuiications Port (COM2)
?^(ISA)4 Commutations Port (COMt)
^ (ISA) 6 Standard floppy dsk controler
■ (ISA) 8 System CMOS/reai time dock
- Ж (ISA) 9 Mcrosoft ACPI-Complant System
: □ (BA) 12 PS/2 Compattie Mouse
2| (ISA)13 Numeric data processor
, - ® (BA) IS Secondary IDE Channel
V 9 (Pd) 9 3Com 3C920 Integrated Fast Ethernet Controler (3C9O5C-TX Compatfcle)
- i A (PCI) 9 Adaptec AHA-2940U/AHA-2940UW PCI SCSI Controler
гф(Ра)9 SoundMAX Integrated Digital Audb
; A (PCD 9 Standard Urtverstf PCI to USB Host Controler
^(PQ)9 Standard Universal PCI to USB Host Controler
№w f emory]
Рис. 3.8. Назначение IRQ на компьютере, не поддерживающем расширенные прерывания после IRQ 15Рис. 3.8. Назначение IRQ на компьютере, не поддерживающем расширенные прерывания после IRQ 15
Рис. 3.8. Назначение IRQ на компьютере, не поддерживающем расширенные прерывания после IRQ 15
Рис. 3.8. Назначение IRQ на компьютере, не поддерживающем расширенные прерывания после IRQ 15
Компьютеры архитектуры IA64 имеют еще больше линий запроса на прерывание, позволяя полностью отказаться от их совместного использования разными устройствами. На рис. 3.10 показан список ресурсов рабочей станции HP 12000.
Неправильная расстановка приоритетов IRQ может стать причиной нестабильной работы сервера. Центральный процессор постоянно получает аппаратные запросы на прерывание и определение приоритета возлагается на интерфейс ACPI. Номер разъема PCI является одним из критериев назначения IRQ. Именно поэтому при некорректной работе устройства стоит переставить его в другой разъем PCI. Дополнительная информация о шине PCI предоставляется на сайте PCI SIG по адресу www. pels ig. сот/tech/index.html.
8b Dew d*
«laiai«laiai*® s_ai
«laiai
«laiai
Э Д SERVERI
®Direct memory access (DMA)
%Lnput/output CO)
EiInterrupt request (IRQ)
• ^ (ISA) 0 System timer
(ISA) 4 Communications Port (COM 1}
^ (ISA) 6 Standard floppy ctoc controler r ^ (ISA) 6 System CMOS^eai time dock У (ISA) 9 Microsoft ACPI-Convkant System 8 (ISA) 13 Numeric data processor ^ (ISA) 14 Pnmary IDE Channe!
?
(ISA) 15 Second»? IDeOwwid
(PCI) ID Intel(R) 82801BA.6AM 94Bus Controler - 2443
(PCI) 16 Creative SB Uve1 Value (WDM)
§ (PCI) 16 NVIDIA GeFefCe2M)QMX 400
ф 0*0) 18 3Com Etheriunk 10/100 PG For Complete PC Management NIC (3C90SC-TX) ф (PCI) 19 Broadcom4jnelO(tm}NetworicAdaptef
Рис.3.9. Назначение ресурсов на компьютере, поддерживающем прерывания выше 15Рис.3.9. Назначение ресурсов на компьютере, поддерживающем прерывания выше 15A (PCI) 19 Lnte!(r‘8280IBAflAM USB Levers* Host Controfer-2442 ^ (PQ) 23 Intd(r) 32801BA/BAM USB Universal Host Controler • 2444
Рис.3.9. Назначение ресурсов на компьютере, поддерживающем прерывания выше 15
Рис.3.9. Назначение ресурсов на компьютере, поддерживающем прерывания выше 15
V W Intxit/output (IO)V W Intxit/output (IO)
V W Intxit/output (IO)
V W Intxit/output (IO)
-■Interrupt request (IRQ)
<6> (ISA) 1 Standard 101/102-Key or Mkrosoft Natural PS/2 Keyboard ; ^ (ISA) 4 Communications Port (COM!)
Jj (ISA) 9 Mcrosoft ACPI-Complant System
; ■ ^ (ISA) 12 PS/2 Compatible Mouse
; Q (ISA) 14 Primary IDE Channel
: Ie (PG) 5 Intel 82372FB System Management Bus Controler =-ф(РО)19 QLogkQLA12l6064btPGDUAL 160MSCSIHBA i ф(РС)44 InteKR) 82559 Fast Ethernet LAN on Motherboard . ^ (PG) 45 Crystal SoundFuston(tm) CS4281 WDM Audo > ^(PG)4 7 InteKr) 82372FB PG to USB Universal Host Controler
8 (PCI) 55 NVIDIA QuadroZ Pro
® Ml Memory
Puc. 3.10. Отсортированные no номеру IRQ устройства компьютера на основе Itanuim
Прямой доступ к памяти
Обычная передача данных между устройством и оперативной памятью требует аппаратного прерывания для каждого буфера с данными. Этот метод передачи называется PIO (Programmed I/O — программируемый ввод-вывод) и является крайне неэффективным. Более сложные устройства для передачи данных без участия процессора используют прямой доступ к памяти DMA (Direct Memory Access) и управление шиной.
Каждое устройство DMA получает канал (channel), который играет роль идентификатора для обработки транзакций передачи данных. Распределение каналов осуществляется через интерфейс ACPI. Контроллеры АТА/IDE используют прямой доступ к памяти для обеспечения высокой скорости передачи данных без участия центрального процессора. Сущест-
вует несколько версий DMA, обеспечивающих разную скорость передачи данных. Для определения подходящего режима DMA операционная система Windows Server 2003 использует интерфейс ACPI и собственные процедуры.
Некоторые компьютеры не поддерживают прямого доступа к памяти на удаленных от процессора разъемах PCI. Если контроллер в удаленном разъеме не работает или работает очень медленно, стоит переставить контроллер ближе к центральному процессору.
.' " Device Manager.' " Device ManagerНа рис. 3.11 показано назначение каналов DMA на шине первичного контроллера IDE. Устройства могут использовать различные версии DMA или комбинацию DMA и РЮ. Соответствующие параметры доступны в оснастке Device Manager (Диспетчер устройств) в окне свойств контроллера IDE (первичного или вторичного).
.' " Device Manager
.' " Device Manager
'j® a6”™1 **.®*’'_ИЯй1ОвШ
S! M Direct memory access (PMA)
^ 2 Standard floppy dtek controler^ 4 Direct memory access controler
S W Intxtioutn* (10) ♦ w Interrupt request (IRQ)
* W Memory
Рис.3.11. Назначение каналов прямого доступа к памяти для устройств IDE
Из-за более широкой шины передачи данных производительность компьютеров на основе архитектуры IA64 еще больше зависит от прямого доступа к памяти. В таких компьютерах используется 64-разрядная шина PCI. Иногда драйвер устройства может использовать 32-разрядную адресацию. В таком случае операционная система Windows Server 2003 использует двойную буферизацию ввода-вывода. Это отрицательно сказывается на производительности, поэтому всегда проверяйте соответствие драйвера критериям компании Microsoft по 64-разрядной адресации и однократной буферизации.
Для приводов DVD и CD-RW режим прямого доступа к памяти включается по умолчанию. Фактический режим доступа к памяти можно определить в окне свойств устройства в оснастке Device Manager (Диспетчер устройств).
Обзор подсистемы Plug and Play
В операционной системе Windows Server 2003 предоставляется та же поддержка технологии Plug and Play (РпР), что и в операционной системе Windows 2000. Для поддержки РпР в подсистеме Windows Executive присутствуют две службы: Plug and Play Manager (Диспетчер Plug and Play) и Power Manager (Диспетчер управления питанием).
Plug and Play Manager (Диспетчер Plug and Play). Обнаруживает устройства РпР в процессе инвентаризации (enumeration). Этот диспетчер после обнаружения устройства загружает соответствующий драйвер и создает записи реестра на основе файла INF, созданного компанией Microsoft или производителем оборудования. Кроме этого, на основе полученной через интерфейс ACPI информации диспетчер Plug and Play назначает такие ресурсы, как IRQ, адреса ввода-вывода и каналы прямого доступа к памяти.
Power Manager (Диспетчер управления питанием). Управляет динамическим взаимодействием с устройствами с целью сохранения энергии батарей и сокращения износа компонентов. Например, диспетчер управления питанием может быть настроен на остановку шпинделя жесткого диска при отсутствии активности пользователя в течение определенного периода.
Успешная инвентаризация зависит от наличия сценария INF, содержащего то же имя, которое выдает устройство. Если диспетчер Plug and Play не в состоянии найти соответствующий устройству сценарий INF, транзакция не будет завершена, даже если на компьютере присутствует подходящий драйвер. Драйверы хранятся в каталоге \windows\System32\Drivers. Сценарии INF хранятся в каталоге \Windows\lnf.
Загрузка 32-разрядных драйверов на компьютере IA64 невозможна, так как эмулятор WOW64 работает только для пользовательского режима. При этом один и тот же сценарий INF может быть использован для загрузки как 32-разрядного, так и 64-разрядного драйвера. Это позволяет производителю распространять один сценарий INF и два набора драйверов. Для загрузки только 64-разрядного драйвера расширение файла INF может быть изменено на Лаб4. Такое расширение заставляет операционную систему искать только 64-разрядные драйверы.
Использование Device Manager (Диспетчер устройств)
Рассмотрим предоставленную компанией Microsoft оснастку ММС, которая предназначена для просмотра информации об установленных в системе устройствах. Эта оснастка называется Device Manager (Диспетчер устройств), файл devmgmt ,msc. Обычно при проблемах в работе устройств или.при настройке сначала необходимо запустить эту оснастку. Существует несколько методов ее запуска.
Щелкните правой кнопкой мыши на пиктограмме Му Computer (Мой компьютер) на рабочем столе и выберите команду Manage (Управление) из контекстного меню. Раскройте дерево System Tools\Device Manager (Служебные программы\Диспетчерустройств).
Щелкните правой кнопкой мыши на пиктограмме Му Computer (Мой компьютер), выберите команду Properties (Свойства) из контекстного меню и перейдите на вкладку Hardware (Оборудование). Щелкните на кнопке Device Manager (Диспетчер устройств).
Любимым способом автора этой книги является использование окна Run (Выполнить). Введите devmgmt.msc и нажмите клавишу <Enter>.
На рис. 3.12 показан пример окна Device Manager (Диспетчер устройств) с деревом устройств.
Для просмотра конфигурационной информации определенного устройства щелкните на пиктограмме устройства правой кнопкой мыши и выберите пункт Properties (Свойства) из контекстного меню. Если заведомо присутствующее устройство в списке не указано, устройство может быть неправильно настроено или не обнаружено диспетчером РпР. Устаревшие устройства можно установить вручную, открыв на Control Panel (Панель управления) аплет New Hardware (Установка оборудования).
Восклицательный знак или знак вопроса возле пиктограммы устройства указывает, что в работе устройства возникли проблемы. Большой символ “X” показывает, что серьезность проблемы заставила систему отключить устройство.
В окне Properties (Свойства) можно оценить проблему. Обратите внимание на описание ошибки на вкладке General (Общие) в разделе Device Status (Состояние устройства). Если в описании указывается на конфликт ресурсов, воспользуйтесь вкладкой Resource (Ресурсы) для просмотра списка устройств, претендующих на те же ресурсы.
jd»Zi
:®:»i^La„
Q ^ Computer
- § Advanced Configuration and Power Interface (ACPI) PC ® »w» Disk drives
3 5 Display adapters
: § InteKr) 82815 Graphics Controler
DVD/CD-ROM drives
$ ад Floppy dkk controlers
Ш 5 Floppy dkk drives
@ ^ IDE ATA/ATAPI controlers
@ t> Keyboards
® О Mke ^ °tber P0**1^ devices
a -Monitors
3-ад Network adapters,
NP 3Com3C92O Inteyated Fast Ethernet Controler(3C9G5C-TX Compatible)
H J Forts (COM &IPT)
^ Communications Port (COM1>
_У Communications Port (COM2)
Jj* ECP Printer Port (LPT1) a* Processors
• 1Ц1 Intel(r) Pentlum(r)in Processor а ад SCSI and RAID controlers (Б ад Sound, video and game controlers Si- System devices
& T*® dr^es
' ^| HP CIS37A SCSI Sequential Device a d^ Universal Serial Bus controlers
Puc. 3.12. Диспетчер устройств с деревом устройств
Для устранения конфликта удалите устройство и перезагрузите компьютер. Это заставит диспетчер РпР пересмотреть решение о выделении ресурсов. Кроме этого, адаптер можно установить в другой разъем PCI, что заставит интерфейс ACPI выделить устройству другие ресурсы.
Если конфликт в распределении ресурсов возник для устаревшего устройства, перейдите на вкладку Resources (Ресурсы) и возьмите управление ресурсами на себя, сбросив флажок Use Automatic Settings (Автоматическая настройка). Для устройств PCI этот флажок остается неактивным. После выделения вручную ресурсов для устаревшего устройства перезагрузите компьютер и проверьте, не исчез ли конфликт и не конфликтует ли устройство с другим устройством.
Дополнительные инструменты для инвентаризации устройств
Хотя Device Manager (Диспетчер устройств) является самым простым инструментом для просмотра сведений об аппаратных средствах компьютера, консолидированный отчет о драйверах, функциях и ресурсах с его помощью не получить. Для этих целей наиболее подходящим решением является утилита System Information (Информация о системе), которую можно запустить из окна Run (Выполнить) с помощью команды winmsd.
И в операционной системе Windows 2000, и в операционной системе Windows Server 2003 команда winmsd немедленно запускает другую утилиту— msinfo32. Эта утилита расположена в каталоге \ Program Files\Common FilesXMicrosoft SharedXMsinfо. Программа winmsd закрывается сразу же после запуска утилиты Msinf о32.
В операционной системе Windows 2000 утилита msinfo32 собирает часть информации и запускает оснастку МНС System Information (Информация о системе). Это та же оснастка, которая используется в консоли Computer Management (Управление компьютером) для отображения информации об операционной системе Windows 2000 и об установленном оборудовании.
В операционной системе Windows Server 2003 оснастки System Information (Информация о системе) не существует. Вместо этого утилита msinfo32 запускает Help and Support Center (Центр справки и поддержки) с выводом полученной через интерфейс Windows Management Instrumentation (WMI) информации о системе (рис. 3.13).
Непосредственно в Help and Support Center (Центр справки и поддержки) информация о системе выводится в более удобной форме. Из основного окна Support Center выберите Tools'^ General^System Information^My Computer Information (Средства^Общие^Информация о систе- ме^Сведения об этом компьютере), как показано на рис. 3.14.
» Я № То* Н*» Я № То* Н*"A Hardware Resources® Components® Software Environment Й Internet Settings"A Hardware Resources® Components® Software Environment Й Internet SettingsOS Manufacture Activation Statue System Name System Manufacturer System Model System Type ProcessorBIDS Veision/D ate SMBIOS Version Windows Directory System Drectory Boot Device LocaleOS Manufacture Activation Statue System Name System Manufacturer System Model System Type ProcessorBIDS Veision/D ate SMBIOS Version Windows Directory System Drectory Boot Device LocaleMicrosoft CorporationActivation Fencing (1 days remainrig)SERVER1Del Computer CorporationDptPlexGX150XBfrbasedPCx86 Family 6 Model 8 Stepping 10 Genuinelntel "931 MhzDel Computer Corporation A06,6/26/20012.3CAWINDOWSCAWIN.DOWS^yslem32VDeviceSHafddskVolumelUntied StatesMicrosoft CorporationActivation Fencing (1 days remainrig)SERVER1Del Computer CorporationDptPlexGX150XBfrbasedPCx86 Family 6 Model 8 Stepping 10 Genuinelntel "931 MhzDel Computer Corporation A06,6/26/20012.3CAWINDOWSCAWIN.DOWS^yslem32VDeviceSHafddskVolumelUntied StatesRnd*h* ।Г Seech selected category or* Г SrachoMgo^Mmaa*Rnd*h* ।Г Seech selected category or* Г SrachoMgo^Mmaa*
» Я № То* Н*
» Я № То* Н*
"A Hardware Resources
® Components
® Software Environment Й Internet Settings
"A Hardware Resources
® Components
® Software Environment Й Internet Settings
OS Manufacture Activation Statue System Name System Manufacturer System Model System Type Processor
BIDS Veision/D ate SMBIOS Version Windows Directory System Drectory Boot Device Locale
OS Manufacture Activation Statue System Name System Manufacturer System Model System Type Processor
BIDS Veision/D ate SMBIOS Version Windows Directory System Drectory Boot Device Locale
Microsoft Corporation
Activation Fencing (1 days remainrig)
SERVER1
Del Computer Corporation
DptPlexGX150
XBfrbasedPC
x86 Family 6 Model 8 Stepping 10 Genuinelntel "931 Mhz
Del Computer Corporation A06,6/26/2001
2.3
CAWINDOWS
CAWIN.DOWS^yslem32
VDeviceSHafddskVolumel
Untied States
Microsoft Corporation
Activation Fencing (1 days remainrig)
SERVER1
Del Computer Corporation
DptPlexGX150
XBfrbasedPC
x86 Family 6 Model 8 Stepping 10 Genuinelntel "931 Mhz
Del Computer Corporation A06,6/26/2001
2.3
CAWINDOWS
CAWIN.DOWS^yslem32
VDeviceSHafddskVolumel
Untied States
Rnd*h* ।
Г Seech selected category or* Г SrachoMgo^Mmaa*
Rnd*h* ।
Г Seech selected category or* Г SrachoMgo^Mmaa*
Puc. 3.13. Информация о системе в Help and Support Center, запущенном из msinfo32 через winmsd
SupportSupport*Др1хУ*Др1хУi-> C' Help and Support Center ji-> C' Help and Support Center j□ Ask a friend to help□ Get help from Microsoft□ Ask a friend to help□ Get help from Microsoft□ Go to a Windows Web site forum□ Go to a Windows Web site forumSee AbeSee Abe□ About Support□ My Computer Information□ About Support□ My Computer Information□ Advanced System Information□ Advanced System InformationQ System Configuration UtilityQ System Configuration Utility2.18 GB2.18 GB2.69 GB2.69 GBCTX 1765CTX 1765Color:Color:Resolution:Resolution:1024x 7681024x 768ActiveActiveManufacturer: UnknownManufacturer: UnknownI n< nl Disk (non parliUoneil) WDI WDr UORb /t-ДПА II n< nl Disk (non parliUoneil) WDI WDr UORb /t-ДПА I. Video r ard. Video r ardTrue Color (24 В»)True Color (24 В»)Model:InteKr) 82815Model:InteKr) 82815ControlerControler(Ci) Capacity -4.88 GB(Ci) Capacity -4.88 GB□ Used: : ^ □ ;□ Used: : ^ □ ;My Computer Information - HardwareRefresh screenMy Computer Information - HardwareRefresh screenType:Type:iBlxntS.sys Wednesday, February 27, 2002 SupportediBlxntS.sys Wednesday, February 27, 2002 Supported
Support
Support
*Др1хУ
*Др1хУ
i-> C' Help and Support Center j
i-> C' Help and Support Center j
□ Ask a friend to help
□ Get help from Microsoft
□ Ask a friend to help
□ Get help from Microsoft
□ Go to a Windows Web site forum
□ Go to a Windows Web site forum
See Abe
See Abe
□ About Support
□ My Computer Information
□ About Support
□ My Computer Information
□ Advanced System Information
□ Advanced System Information
Q System Configuration Utility
Q System Configuration Utility
2.18 GB
2.18 GB
2.69 GB
2.69 GB
CTX 1765
CTX 1765
Color:
Color:
Resolution:
Resolution:
1024x 768
1024x 768
Active
Active
Manufacturer: Unknown
Manufacturer: Unknown
I n< nl Disk (non parliUoneil) WDI WDr UORb /t-ДПА I
I n< nl Disk (non parliUoneil) WDI WDr UORb /t-ДПА I
. Video r ard
. Video r ard
True Color (24 В»)
True Color (24 В»)
Model:InteKr) 82815
Model:InteKr) 82815
Controler
Controler
(Ci) Capacity -4.88 GB
(Ci) Capacity -4.88 GB
□ Used: : ^ □ ;
□ Used: : ^ □ ;
My Computer Information - Hardware
Refresh screen
My Computer Information - Hardware
Refresh screen
Type:
Type:
iBlxntS.sys Wednesday, February 27, 2002 Supported
iBlxntS.sys Wednesday, February 27, 2002 Supported
Рис. 3.14. Служба Help and Support Center отображает информацию о системе
Интерфейс ACPI
Хотя компания Microsoft называет операционные системы Windows Server 2003, Windows ХР и Windows 2000 системами Plug-and-Play, на самом деле эти системы используют интерфейс ACPI. Стандарт ACPI определяет механизмы передачи информации о возможностях и ресурсах, которая в виде таблиц сохраняется во временной памяти микросхемы. Операционная система просматривает таблицы и на основе полученной информации принимает решения о распределении ресурсов и управлении питанием.
В соответствии с доступной по адресу www. acpi .info спецификацией ACPI 2.0 инфраструктура ACPI предоставляет следующие службы.
Управление питанием компьютера
Управление питанием устройств
Управление питанием процессора
У правление производительностью устройств и процессора
Plug and Play
Системные события
Управление батареей
У правление датчиками температуры
Управление встроенными контроллерами
Управление контроллером шины SMBus (SMBus — это спецификация шины управления компьютером (System Management bus), которая предлагается компанией Intel)
Интерфейс ACPI является неотъемлемой частью компьютера, поэтому компания Microsoft решила интегрировать поддержку ACPI непосредственно в ядро операционной системы посредством уровня аппаратных абстракций (Hardware Abstraction Layer — HAL).
Несложно заметить, что операционные системы Windows Server 2003 и Windows ХР используют интерфейс ACPI для управления питанием и для использования подсистемы Plug and Play. Не путайте эти возможности управления питанием с устаревшей, спецификацией АРМ (Advanced Power Management — усовершенствованное управление питанием), которая несколько лет являлась стандартом для персональных компьютеров. Для управления состоянием компьютера в спецификации АРМ предлагались вызовы функций в системной BIOS. Устаревшие вызовы АРМ поддерживаются только в операционной системе Windows ХР. В операционной системе Windows Server 2003 поддержка таких функций отсутствует.
Для проверки наличия АРМ в Control Panel (Панель управления) в окне Printers and Other Hardware (Принтеры и другое оборудование) щелкните на ссылке Power Options (Электропитание). Если в окне Power Options (Электропитание) присутствует вкладка АРМ, компьютер оборудован АРМ BIOS. Поддержку АРМ имеет смысл включать только при отсутствии других альтернативных интерфейсов управления питанием. Так бывает при отсутствии функциональных возможностей ACPI в HAL.
Использование утилиты apmstat
В состав Windows Server 2003 Support Tools входит утилита apmstat. Утилита позволяет проверить наличие АРМ BIOS. Вот пример отчета, полученного при использовании параметра -v (подробный отчет).
C:\Program Files\Resource Kit>apmstat -v
This computer appears to have an АРМ legal HAL
This machine has an АРМ bios present that looks OK, and it is not on the list of machines known to have АРМ problems.
Check the power applet in the control panel to see if АРМ is enabled АРМ Registry Data Dump
• Major = 0001 Minor = 0002
InstallFlags = 0003
Codel6Segment = fOOO Codel6Offset = 56c4 DataSeg = 0040
Signature = АРМ
Valid = 0001
Detection Log Data:
44 45 54 4c 4f 47 31 00 00 00 00 00 00 00 00 00 D E T L О G 1
При поддержке интерфейса ACPI утилита apmstat выдает следующее сообщение:
This is an ACPI machine. АРМ is NOT relevant on this machine.
Совместимость c ACPI
При установке операционной системы Windows Server 2003 на компьютер, соответствующий спецификации ACPI v2, проблем быть не должно. Иногда возникают проблемы с компьютерами, которые создавались во время развития стандарта ACPI. Такие компьютеры могут не предоставлять некоторых функций управления питанием, а также периодически “зависать” или приводить к появлению критических ошибок.
Компания Microsoft в качестве пограничной даты выбрала 1 января 1999 года, предположив, что все произведенные после этой даты компьютеры соответствуют спецификации ACPI 2.0. Исключения из этого правила перечислены в файле txtsetup. si f, хранящемся на установочном компакт-диске операционной системы Windows Server 2003. Соответствующий раздел называется [NWACL ], что расшифровывается как Non- Windows A CPI Compliance List.
Для идентификации интерфейса ACPI на компьютере программа установки запрашивает две таблицы ACPI: Fixed ACPI Description Table (FACP), в которой содержатся строки с описанием производителя, и Root System Description Table (RSDT), в которой содержится буквенноцифровое значение, назначенное производителем и описывающее модель компьютера. Запись в разделе [NWACL] описывает источник идентификации. Например, компьютеры Toshiba portege 3300 и Fujitsu Sprint входят в список NWACL. Ниже приведен фрагмент раздела [NWACL] из файла txtsetup.sif.
# [ToshibaPortege3300]
AcpiOemId="FACP","TOSHIB"
AcpiOemTableId="FACP","750"
AcpiOemRevision="<=","FACP",1
[FujitsuSPRINT]
AcpiOemId="RSDT","FUJ
AcpiOemTableId="RSDT","SPRINT "#
В файле также перечислены созданные до 1 января 1999 года компьютеры, имеющие совместимую реализацию ACPI. Такие компьютеры перечислены в разделе [GoodACPlBios ].
Кроме этого, существует список “хороших, но только при внесении исправлений” компьютеров, который находится в файле biosinf о. inf в каталоге \1386 на установочном компакт-диске операционной системы Windows Server 2003. В этом списке перечислены компьютеры, работающие только после отключения определенных функций ACPI. Ниже приведен пример такого списка.
; workaround for BIOS bug in Dell Dimension 8100, Precision 220, /and Precision 420 using National PC87364 SuperlO chipsets.
/Parallel port is configured in a way that does not
; work on Win2k or WinXP
[DellNationalPC87364WorkAround]
AddReg=DellNationalPC873 64WorkAroundAddReg
[DelINat ionalPC87364WorkAroundAddReg]
HKLM,SYSTEM\CurrentControlSet\Services\Parport\Parameters, 1>DellNationalPC87364,0x00010001,1'
Если компьютер создан на основе материнской платы, которая была выпущена до 1 января 1999 года и отсутствует в списке заведомо работающих компонентов, но есть уверенность в правильности ее работы вместе с ядром ACPI, значение параметра ACPlEnable можно установить равным 1 (значение параметра устанавливается в файле txt:setup. sif). Это значение параметра заставит программу установки загрузить ядро ACPI. Кроме экспериментальных целей, использование этого параметра не рекомендуется, поскольку компьютер может работать непредсказуемо.
Возможности управления питанием
В зависимости от полученного во время установки содержимого таблиц ACPI операционные системы Windows Server 2003 и Windows ХР предоставляют ряд параметров в окне Power Options (Управление питанием), доступном из Control Panel (Панель управления). На рис. 3.15 показано окно Power Options (Управление питанием) операционной системы Windows ХР, запущенной на портативном компьютере. На рис. 3.16 показано это же окно, но для операционной системы Windows Server 2003.
Рис. 3.15. Окно Power Options Properties (Управление питанием) в операционной системе Windows ХР, запугценной на портативном компьютереРис. 3.15. Окно Power Options Properties (Управление питанием) в операционной системе Windows ХР, запугценной на портативном компьютереPowter Options Properties
Рис. 3.15. Окно Power Options Properties (Управление питанием) в операционной системе Windows ХР, запугценной на портативном компьютере
Рис. 3.15. Окно Power Options Properties (Управление питанием) в операционной системе Windows ХР, запугценной на портативном компьютере
RxwSehemM jA^rnsdl Hibernate | UPS |RxwSehemM jA^rnsdl Hibernate | UPS |«jl Setect the power tcheme with the mort appropriate settings for ’'^ IhtceritK* Note that change the Mtbngt beiew vd mod^ the selected scheme.«jl Setect the power tcheme with the mort appropriate settings for ’'^ IhtceritK* Note that change the Mtbngt beiew vd mod^ the selected scheme.I5ам»Ак. | Delete | II5ам»Ак. | Delete | ISiting» far Home/Qffice Desk power scheme ■: Turnoff|дкеГ2(Гп^Turnoff harddekr'3Siting» far Home/Qffice Desk power scheme ■: Turnoff|дкеГ2(Гп^Turnoff harddekr'3' Sjnierntlandby (Never^J
RxwSehemM jA^rnsdl Hibernate | UPS |
RxwSehemM jA^rnsdl Hibernate | UPS |
«jl Setect the power tcheme with the mort appropriate settings for ’'^ IhtceritK* Note that change the Mtbngt beiew vd mod^ the selected scheme.
«jl Setect the power tcheme with the mort appropriate settings for ’'^ IhtceritK* Note that change the Mtbngt beiew vd mod^ the selected scheme.
I5ам»Ак. | Delete | I
I5ам»Ак. | Delete | I
Siting» far Home/Qffice Desk power scheme ■
: Turnoff|дкеГ2(Гп^
Turnoff harddekr'3
Siting» far Home/Qffice Desk power scheme ■
: Turnoff|дкеГ2(Гп^
Turnoff harddekr'3
| OK 3 Cancat |
Puc. 3.16. Окно Power Options Properties (Управление питанием) в операционной системе Windows Server 2003
После определения возможностей ACPI программой установки полученная информация записывается в уровень аппаратных абстракций (HAL). Если параметры ACPI изменить в настройках BIOS, операционную систему придется переустановить. Не забывайте об этом, копируя операционную систему с помощью образов.
Модель драйверов Windows
Главным преимуществом слияния корпоративной и потребительской линеек продуктов Windows является возможность использования одинаковых драйверов для всей линейки продуктов. Схема для создания драйверов называется WDM (Windows Driver Model — модель
драйверов Windoms). Вот несколько источников информации по архитектуре драйверов WDM и по принципам их разработки.
Programming the Microsoft Windows Driver Model Уолтера Они (Walter Oney). Это отличная книга для системных администраторов. В книге описываются принципы работы драйверов, а также архитектурная модель драйверов.
Developing Windows NT Device Drivers: A Programmers’s Handbook Эдварда Деккера (Edward Dekker) и Джозефа Ньюкамера (Joseph Newcomer). Это еще одна отличная книга. В ней содержится большой объем информации для тех, кто хочет окунуться в детальное изучение свойств Windows.
Windows NT Device Driver Development Питера Вискаролы (Peter Viscarola) и Энтони Мейсона (Anthony Mason). Это основополагающий труд по разработке драйверов для операционной системы Windows NT. В основном, книга ориентирована на более старую модель драйверов Windows NT, но в ней подробно рассматривается WDM.
Windows Server 2003 Driver Development Kit (DDK). В составе инструментария содержится краткая документация, но, несмотря на краткость, это самый авторитетный источник информации. Раньше DDK предоставлялся компанией Microsoft бесплатно, но теперь за него приходится платить.
В операционной системе Windows Server 2003 подсистемы WDM и РпР связаны неразрывно. Ниже приводится краткое описание WDM, чтобы ввести читателя в курс дела.
Шина
Ввод-вывод для WDM начинается с шины. Шина является интерфейсом, который управляет одним или несколькими устройствами. Например, контроллер IDE является шиной, поскольку контроллер предоставляет интерфейс к одному или нескольким жестким дискам. В числе других шин можно перечислить следующие.
Шина Personal Computer Interface (PCI)
Последовательный интерфейс RS-232
Параллельный порт
Интерфейс ACPI
Интерфейс SCSI
Шина PC Card (ранее'— шина PCMCIA)
Шина USB (Universal Serial Bus — универсальная последовательная шина)
IEEE 1394 FireWire
Драйверы шины
Шина управляется драйвером шины. Драйвер шины управляется диспетчером Plug and Play, который общается с устройствами с помощью вызова функций HAL.
Драйвер шины выполняет инвентаризацию устройств на собственной шине и для каждого найденного устройства создает объект физического устройства (Physical Device Object — PDO), Объект физического устройства используется для “виртуализации” устройства и его превраще» ния в цифровой объект, который может реагировать на команды подсистемы Executive. В числе других задач драйвера шины можно выделить наблюдение за вестибюлем, доставку чемоданов, прием посетителей и управление лифтом. Другими словами, на драйвер возлагаются такие задачи.
Отслеживание событий на шине и сообщение о событиях диспетчеру Plug and Play.
Ответ на пакеты запроса ввода-вывода (I/O request packets — IRP) от диспетчера Plug and Play и диспетчера управления питанием.
Ускорение операций ввода-вывода с помощью мультиплексирования запросов на доступ к шине.
Выполнение административных действий по поддержке нормальной работы шины.
Объекты функционального устройства
Драйвер шины обычно не поддерживает непосредственную связь с устройствами на шине, если устройство не использует низкоуровневый ввод-вывод данных (raw I/O). Вместо этого драйвер еще больше “виртуализирует” объект физического устройства в структуру данных, которая называется объект функционального устройства (Functional Device Objects — FDO). Эти объекты управляются драйвером функций (function driver). Драйвер функций для каждого устройства загружается диспетчером Plug and Play.
Драйверы функций
Драйверы функций реализованы в виде наборов драйверов: драйвера класса (class driver), мини-драйвера (minidriver) и одного или нескольких фильтрующих драйверов (filter driver).
Драйвер класса. Предоставляет базовые функциональные возможности для определенного типа устройств, например для мыши, сканера или жесткого диска. Обычно драйверы класса создаются компанией Microsoft.
Мини-драйвер. Определяет специальные функции. Мини-драйвер создается производителем конкретного оборудования.
Фильтрующий драйвер. Этот драйвер можно представить как уровень над или под драйвером функций, предоставляющий дополнительные возможнбсти. Компания Microsoft рекомендует производителям создавать фильтрующие драйверы, а не абсолютно новые мини-драйверы.
Пример использования WDM
Вот пример инвентаризации и загрузки устройства с драйвером WDM.
Вставьте в разъем PCMCIA адаптер PC Card SCSI, к которому подключен привод Jaz.
Драйвер PCMCIA обнаруживает новый адаптер и создает для адаптера объект физического устройства. Диспетчер Plug and Play получает уведомление о создании объекта PDO.
Диспетчер Plug and Play находит подходящий драйвер для созданного объекта физического устройства (PDO), загружает драйвер и передает объект PDO драйверу SCSI.
Драйвер SCSI создает объект функционального устройства (FDO) и подключает jro к стеку драйверов шины PC Card.
Диспетчер Plug and Play заставляет драйвер SCSI выполнить инвентаризацию устройства ■ на шине.
Драйвер SCSI выполняет инвентаризацию устройства на шине, находит привод SCSI и создает объект PDO для привода.
Диспетчер Plug and Play находит подходящий драйвер для нового объекта PDO, загружает его и передает управление над объектом PDO новому драйверу.■
Драйвер диска создает объект функционального устройства (FDO) и подключает созданный объект к стеку драйверов шины SCSI.
Теперь драйверы файловой системы в диспетчере ввода-вывода могут осуществлять взаимодействие с диском по интерфейсу шины SCSI.
Одним из результатов обнаружения устройств РпР, инвентаризации и создания объектов является создание разделов системного реестра в разделе HKLM\System\CurrentControlSet\ Епшп. Это дерево называется Enum и используется в качестве ссылки для запуска служб во время загрузки.
На этом обзор архитектуры аппаратных средств для Windows Server 2003 завершается. Пришло время добавлять устройства.
Установка и настройка устройств
У таких специалистов, как автор этой книги, всегда возле рабочего места лежит гора каталогов с предложениями персональных компьютеров. У меня есть толстые тома от Ingram Micro, Tech Data и Gates Arrow, а также книги от десятка других продавцов готовых компьютеров. Это не считая массы писем от магазинов и сотен рекламных писем от посредников и производителей.
Нет такой книги, в которой можно подробно описать установку всех этих компонентов. Процедуры установки, описанные в этом разделе, дают представление о реакции системы на добавление нового устройства, а также дают ссылку на инструменты настройки уже установленных устройств. Раздел об устранении неисправностей в конце главы содержит советы по исправлению вероятных проблем.
Если операционная система приобреталась не по оптовому соглашению или главной лицензии, некоторые действия по исправлению проблем могут вызвать повторную активацию Windows. Обычно повторная активация инициируется при замене материнской платы или при переносе жесткого диска на другой компьютер (что по сути то же самое). Такая же ситуация возникает при замене некоторых компонентов. В главе 1, “Установка и настройка Windows Server 2003”, приводится дополнительная информация об устройствах, участвующих в процессе оценки WPA.
В этом разделе приводятся следующие инструкции по установке.
Использование службы Windows Update
Добавление или замена центрального процессора
Добавление жесткого диска с интерфейсом IDE
Установка адаптера SCSI и подключение к нему жестких дисков
Добавление приводов сменных носителей
Добавление сетевого адаптера и настройка привязок
Использование нескольких мониторов
Использование службы Windows Update
Отслеживание изменений в приложениях й драйверах остается постоянной проблемой. В операционной системе Windows Server 2003 для службы Windows Update создан более простой интерфейс, чем в операционной системе Windows 2000.
Самой распространенной причиной установки “заплат” и исправлений является устранение уязвимых мест в системе безопасности. По сравнению с операционными системами Windows NT и Windows 2000 с выходом операционной системы Windows Server 2003 количество таких исправлений уменьшится, но они не исчезнут совсем. Существует несколько методов тестирования для поиска уязвимых мест в системе безопасности. Самый простой из этих методов заключается в использовании утилиты hfnetchk, которая распространяется компанией Microsoft под названием Baseline Security Analyzer.
Для обновления драйверов на определенном сервере достаточно запустить службу Windows Update из аплета Help and Support Center (Центр справки и поддержки). В главном окне
Help and Support Center присутствует ссылка на сайт Windows Update, который находится по адресу v4.windowsupdate.microsoft.com. Сайт отображается в окне Help and Support Center. При первом посещении сайта будет предложено загрузить элемент управления ActiveX, который управляет обновлениями сервера.
На сайте Windows Update можно найти обновленные версии драйверов устройств, установленных на компьютере. Если необходимо загрузить драйверы для другой пользовательской системы, воспользуйтесь инструкциями из процедуры 3.1.
Процедура 3.1. Загрузка драйверов для другого компьютера с помощью службы Windows Update
В окне Windows Update щелкните на ссылке Personalize Windows Update (Настроить Windows Update).
Выберите Display The Link To The Windows Update Catalog (Отобразить ссылку на каталог Windows Update).
Щелкните на Save Settings (Сохранить установки).
В разделе See Also (Смотри также) в левой части окна щелкните на Windows Update Catalog (Каталог Windows Update).
В основном окне щелкните на Find Driver Updates for Hardware Devices (Найти обновления для аппаратных устройств). Это приведет к открытию страницы со ссылками на различные типы устройств. Пример страницы показан на рис. 3.17.
©Help and Support Center
a. ^ - j U ..." У 51 zl
Rock ■" Це» т*х Pyortss War* suppet дай»
jdoiasi
® Help and Support Center
Windows Update
Иоте | WindtMve Catalog| OHvr«i U|uJ*te I Windows Update Wwtixvide
Microsoft
Windows Update Catalog
□ Welcome
Hardware Drivers
Pick a hardware category, and search for the latest iodates to keep your devices working properly.
Find Microsoft Windows 'Updates
Co to Download Basket
Other Option#
View download history
See Also
Windows Update
About Windows Update
Support Information
Video
Video cards, motherboard video chipsets, DVD decoder, video capture cards, TV tuners...
Speakers, microphones, portablemedte players, soundcards, synthesizers... e Printers
Photo-printer, laser, dot-matrix, sold Ink, accessories.., e Modems■ ■
External, modem card, ISDN, DSL, cable,.,
Cameras Digital sti image camera, DV (Digital Video) camera, video/Web camera,...
Scanners
Flatbed, scroi fed, handheld... e Monitors
CRT, LCD flat panel, LED, plasma, projectors...•
Networking
LAN, wireless, ISDN, HPNA, IrDA, WAN, ATM (esynchronous transfer mode)...1
Input Devices■
Mouse, keyboard, game controlers, trackbal, microphones, touch pads, light pens...
Storage adapters and controlers, CD-DVD drives, hard dtek drives, removable media drives,—.
RAID, tape drives...
Puc. 3.17. Страница Hardware Drivers на сайте Windows Update Catalog
Эту процедуру можно использовать для загрузки драйверов на центральный сервер в сети. После этого администраторы или пользователи рабочих станций могут получать драйверы с сервера.
Если сервер должен получать обновления автоматически, настройте эту возможность в окне System Properties (Свойства системы) на вкладке Automatic Updates (Автоматическое обновление) как показано на рис. 3.18.
[System Properties
Рис. 3.18. Параметры автоматических обновлений на вкладке Automatic Updates (Автоматическое обновление) окна System Properties (Свойства системы)Рис. 3.18. Параметры автоматических обновлений на вкладке Automatic Updates (Автоматическое обновление) окна System Properties (Свойства системы)Benetai | Computer Name | Hardware Advimced Г~ RemoteWindow* can find the nictates you need and d*er them drect^to your computerP. Keep my computer to to date. W#i tHt totting enefatad, Windows Update software may be automatical tpdated prior to applying ary etew tpdatet.Loam «юге about й|даййа$$й$мг $•*•»'" " * '<* N^mebteom download^ any updates arrfro^ before netting teem on my computer| ^'QteHdWtteeupd^artemalicatyartdnQlfyi»'tea* to be instated: г Aytomaticate downfeed the iodates. and instal them on teejschaduteteal I sperilyj |b*(-.i^ 1э- |W AM jj•■ Lamnmoteteboteschaduipdr^jpaBenetai | Computer Name | Hardware Advimced Г~ RemoteWindow* can find the nictates you need and d*er them drect^to your computerP. Keep my computer to to date. W#i tHt totting enefatad, Windows Update software may be automatical tpdated prior to applying ary etew tpdatet.Loam «юге about й|даййа$$й$мг $•*•»'" " * '<* N^mebteom download^ any updates arrfro^ before netting teem on my computer| ^'QteHdWtteeupd^artemalicatyartdnQlfyi»'tea* to be instated: г Aytomaticate downfeed the iodates. and instal them on teejschaduteteal I sperilyj |b*(-.i^ 1э- |W AM jj•■ Lamnmoteteboteschaduipdr^jpaI « II « ICancel |Cancel |
Рис. 3.18. Параметры автоматических обновлений на вкладке Automatic Updates (Автоматическое обновление) окна System Properties (Свойства системы)
Рис. 3.18. Параметры автоматических обновлений на вкладке Automatic Updates (Автоматическое обновление) окна System Properties (Свойства системы)
Benetai | Computer Name | Hardware Advimced Г~ Remote
Window* can find the nictates you need and d*er them drect^to your computer
P. Keep my computer to to date. W#i tHt totting enefatad, Windows Update software may be automatical tpdated prior to applying ary etew tpdatet.
Loam «юге about й|даййа$$й$м
г $•*•»'" " * '
<* N^mebteom download^ any updates arrfro^ before netting teem on my computer
| ^'QteHdWtteeupd^artemalicatyartdnQlfyi»
'tea* to be instated
: г Aytomaticate downfeed the iodates. and instal them on tee
jschaduteteal I sperily
j |b*(-.i^ 1э- |W AM jj
•■ Lamnmoteteboteschaduipdr^jpa
Benetai | Computer Name | Hardware Advimced Г~ Remote
Window* can find the nictates you need and d*er them drect^to your computer
P. Keep my computer to to date. W#i tHt totting enefatad, Windows Update software may be automatical tpdated prior to applying ary etew tpdatet.
Loam «юге about й|даййа$$й$м
г $•*•»'" " * '
<* N^mebteom download^ any updates arrfro^ before netting teem on my computer
| ^'QteHdWtteeupd^artemalicatyartdnQlfyi»
'tea* to be instated
: г Aytomaticate downfeed the iodates. and instal them on tee
jschaduteteal I sperily
j |b*(-.i^ 1э- |W AM jj
•■ Lamnmoteteboteschaduipdr^jpa
I « I
I « I
Cancel |
Cancel |
В любом случае служба Windows Update является простым средством автоматического получения обновлений, но нет гарантии, что установка определенного набора обновлений не приведет к нестабильной работе сервера. Автор этой книги рекомендует вручную просматривать список обновлений и не доверять автоматической загрузке.
Software Update Service (SUS)
В июле 2002 года компания Microsoft выпустила службу, поддерживающую централизованное распространение исправлений с локального сервера вместо многократного обращения к службе Windows Update. Эта служба входит в состав операционной системы Windows Server 2003.
Служба SUS предоставляет несколько преимуществ.
Каждое обновление можно проверить до установки на работающие серверы.
Обновления могут устанавливаться на серверы, не подключенные к Интернет. ■
Можно создать шаблон для серверов, определив список устанавливаемых обновлений.
Создание спецификации на сервере SUS позволяет централизованно управлять процессом развертывания обновлений.
Обновления могут распространяться на серверы с помощью групповых политик.
Компания Microsoft постоянно улучшает службу SUS. Последние обновления и инструкции доступны на сайте www.microsoft.com.
Обновления безопасности
Обычно для установки “заплат” достаточно службы Windows Update или Software Update Service (SUS). Но иногда возникает необходимость вручную установить определенное исправление или “заплату” для тестирования и оценки. Для этого исправление необходимо запустить в консоли сервера.
Утилита qchain, доступная на сайте Microsoft, позволяет избежать нескольких перезагрузок при локальной установке более одного исправления.
Добавление или замена центрального процессора
В операционных системах Windows NT и Windows 2000 добавление центрального процессора было связано с трудностями, поскольку программа установки выбирала однопроцессорное ядро, даже если материнская плата поддерживала установку нескольких процессоров.
В операционной системе Windows Server 2003 достаточно установить второй процессор в соответствии с инструкциями производителя и загрузить компьютер. Обнаружив второй процессор, операционная система меняет версии системных драйверов на многопроцессорные.
Убедиться в использовании двух процессоров можно в окне Task Manager (Диспетчер задач). На вкладке Performance (Производительность) отображается график производительности для каждого процессора. Если график для вторюго процессора отсутствует, удостоверьтесь, что процессор правильно установлен в разъем и в параметры BIOS внесены все необходимые изменения. Кроме этого, проверьте правильность установки параметров напряжения и других настроек материнской платы.
Все немного сложнее, если приходится менять ядро, выбранное программой установки. Если изначально операционная система Windows Server 2003 устанавливалась с использованием ядра ACPI, но в процессе работы выяснилось, что система работает нестабильно и ядро необходимо заменить на Standard PC, для замены ядра потребуется полная переустановка операционной системы.
Основной причиной является различие в способах хранения информации в разделе системного реестра HKLM\Hardware. Способы хранения параметров для различных версий ядра несовместимы. Если в BIOS отключить поддержку ACPI, то загрузка ядра ACPI приведет к стоп-ошибке (“синему экрану смерти”).
Установка жестких дисков IDE
Самым сложным этапом добавления жесткого диска IDE является правильная установка перемычек для выбора главного и подчиненного дисков. Если в параметрах BIOS новый диск отображается с правильными значениями геометрии и размера, операционная система Windows Server 2003 сможет без проблем использовать существующие драйверы IDE. Новый диск отображается в консоли Computer Management (Управление компьютером) в оснастке Disk Management (Управление дисками). Для запуска консоли Computer Management (Управление компьютером) воспользуйтесь командой Start^Programs^Administrative Tools1* Computer Management (Пуск^Программы^Администрирование^Управление компьютером). Настройка нового диска и выделение дискового пространства рассматриваются в главе 14, “Настройка подсистемы хранения данных”.
Если для получения чередования по методу RAID 0 второй жесткий диск подключается к тому же контроллеру IDE, прироста производительности не произойдет. Интерфейс IDE поддерживает работу только одного устройства в один момент времени. Для создания массива с чередованием дисков эти диски необходимо подключать к разным контроллерам или к выделенному контроллеру АТА/IDE RAID. То же самое относится к зеркалированным
дискам. Если в операционной системе сформировать зеркало из двух дисков, подключенных к одному контроллеру IDE, производительность системы снизится.
Подключая устройства с поддержкой UltraDMA (UDMA), убедитесь, что система правильно определила поддерживаемый режим DMA. Режим DMA показан в окне Properties (Свойства) контроллера IDE, доступном из Device Manager (Диспетчер устройств). Перейдите на вкладку Advanced Settings (Дополнительно). Обычно для параметра Device Туре (Тип устройства) задано значение Auto Detection (Автоматическое определение), поэтому причины неправильного определения режима UDMA необходимо выяснять у производителя.
Установка контроллеров и дисков SCSI
Сменив интерфейс IDE на SCSI, можно значительно увеличить производительность сервера. Отчасти это связано с тем, что шина SCSI работает быстрее, хотя интерфейсы АТА133 и UltraDMA 6 вплотную приблизились к производительности интерфейса SCSI. Но важнее то, что шина SCSI использует асинхронную передачу, позволяя выполнять мутиплексирование пакетов с данными от нескольких устройств. Контроллеры IDE/АТА могут одновременно работать только с одним устройством. Кроме этого, контроллеры SCSI потребляют меньше ресурсов центрального процессора в пересчете на переданный мегабайт, поэтому интерфейс работает более эффективно и предоставляет большую общую производительность.
При установке адаптера SCSI и загрузке компьютера диспетчер Plug and Play обнаруживает новый адаптер и загружает подходящие драйверы. Если подсистема РпР определяет, что добавлено новое оборудование, но подходящие драйверы отсутствуют, операционные системы Windows Server 2003 и Windows 2000 запросят драйверы у администратора.
Если к контроллеру подключен диск, на который планируется установка операционной системы и для этого диска нет драйверов в мини-версии операционной системы Windows Server 2003, которая загружается с помощью программы установки, то в начале текстового этапа установки можно нажать клавишу <Е6> и загрузить подходящий драйвер с гибкого диска.
Подключение нового диска к компьютеру на основе архитектуры IA64 не требует никаких дополнительных действий по настройке аппаратных средств. При создании разделов диска средствами консоли Disk Management (Управление дисками) создаются соответствующие разделы GPT.
Точно так же не требуется аппаратная настройка компьютера с архитектурой IA64 при замене загрузочного диска и попытке установки Windows Server 2003. В главе 1, “Установка и настройка Windows Server 2003”, описывается использование расширяемого программноаппаратного интерфейса EFI для перехода на установочный компакт-диск и запуска установки Windows Server 2003. Программа установки автоматически создает EFI System Partition, Microsoft Reserved Partition и универсальные разделы для данных операционной системы.
Подключая новые устройства к шине SCSI, особое внимание обратите на назначение идентификаторов SCSI (SCSI ID) и установку терминаторов для шины. 90% всех проблем в работе шины SCSI происходит из-за этих двух ошибок. Современные контроллеры SCSI неплохо справляются с определением активной терминации в устройствах, но всегда желательно точно определить, выступает ли устройство в роли активного терминатора на шине.
Если при подключении диска к шине с загрузочным диском меняется порядок инвентаризации устройств, компьютер может не загрузиться. Такая ситуация возможна даже тогда, когда SCSI BIOS настроен на загрузку с правильного диска. Такая проблема возникает из-за использования в пути ARC в файле boot. ini нумерации, соответствующей порядку инвентаризации устройств на шине. Например, возьмем простой путь ARC:
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Standard Edition" ^ /fastdetect
Если в результате смены порядка сканирования загрузочный диск стал вторым и ему соответствует параметр rdisk (1) или третьим (rdisk (2 ) ), загрузчик NTLDR не сможет найти загрузочный диск и выдаст сообщение Unable to Locate Ntoskrnl.exe.
Всегда перед использованием дисков SCSI проводите их низкоуровневое форматирование. Это позволяет обеспечить совпадение адресных таблиц на контроллере и на диске. Еще более важным такое совпадение оказывается при формировании массивов RAID. При несовпадении адресных таблиц иногда могут возникать трудно диагностируемые ошибки. Низкоуровневое форматирование может занять некоторое время, поэтому, рассчитывая время на замену или добавление жесткого диска SCSI, добавьте пару часов.
Поддержка дисками технологии S.M.A.R.T. позволяет значительно упростить диагностику проблем в работе дисков. Дополнительная информация об этой технологии приводится по адресам www.pcguide.com/ref/hdd/perf/qual/ featuresSMART-c.html иwww.storagereview.com/guide2000/ref/hdd/perf/qual/ featuresSMART.html.
Использование дисковых утилит EFI
Программа установки Windows Server 2003 сохраняет несколько утилит в каталоге MSUtil на EFI System Partition. Эти утилиты можно использовать для создания разделов и управления ими, хотя обычно удобнее пользоваться инструментами операционной системы, чем командным интерпретатором EFI.
Утилиты работы с дисками EFI предоставляют хорошие возможности управления процессом разбиения дисков на разделы, но за такие возможности приходится платить высокую цену. Эти утилиты слишком легко позволяют уничтожить один или даже все разделы на диске. Использование командного интерпретатора EFI Shell рассматривается в главе 2, “Модернизация и автоматизированная установка”. Перед использованием описанных здесь утилит обязательно воспользуйтесь утилитой тар для проверки номеров блоков разделов и псевдонимов монтирования.
diskpart.efi
Утилита Diskpart. ef i работает так же, как утилита diskpart в операционной системе Windows Server 2003. Утилита может использоваться для создания EFI System Partition, нового раздела Microsoft Reserved Partition и новых разделов для хранения данных еще до установки операционной системы. Использовать эту утилиту совсем не обязательно, поскольку программа установки также предоставляет возможности по разбиению и подготовке дисков, но описание возможностей утилиты приводится здесь на случай разбиения диска без установленной операционной системы.
При использовании для создания раздела утилита Diskpart. ef i создает идентификаторы GUID автоматически. Установка имени для раздела возлагается на администратора. Кроме этого, администратор должен указать размер раздела в мегабайтах. Например, параметр size=1024 позволяет создать раздел размером 1 Гбайт. Создание раздела описано в процедуре 3.2.
Процедура 3.2. Использование утилиты Diskpart. ef i для создания нового раздела с данными
Откройте командный интерпретатор EFI.
Перейдите в каталог f sO: \MSUtil.
Запустите утилиту diskpart.
Введите команду List для просмотра списка управляемых дисков компьютера.
Введите команду Select #, где # — идентификатор диска, взятый из списка, полученного в результате выполнения команды List.
Введите команду Symbols для получения списка типов разделов. Существует три типа разделов: MSRES (Microsoft Reserved), EFISYS (EFI System) и MSDATA. В данном случае х для создания раздела будет использоваться тип MSDATA.
Введите команду Create пате=имя„раздела type=msdata size=1024 ver. Параметр ver предназначен для создания подробного отчета. Ниже представлен пример успешного результата создания раздела.
CmdCreate arguments:
SelectedDisk = О
Name=PARTITION_NAME
TypeGuid = EBD0A0A2-B9E5-4433
TypeName = MSDATA
Requested OffsetlnBlocks = 0
Requested SizelnMegabytes = 1024
Attributes = 0
Resulting Size In Blocks = 2097152
Resulting Size In Bytes = 1073741824
Кроме этого, утилиту diskpart можно использовать для очистки диска с помощью команды Clean с последующей подготовкой новой таблицы разделов GUID с помощью команды New GPT. В результате все данные на диске будут потеряны, поэтому такие команды стоит использовать только для подготовки нового диска (возможно, снятого с другого компьютера). В случае с дисками SCSI для этого необходимо воспользоваться низкоуровневым форматированием (одновременно произойдет синхронизация таблиц трансляции между диском и контроллером).
Fdisk.efi
Утилита Fdisk. ef i предназначена для выполнения только одцой функции. Она создает EFI System Partition на чистом диске. При использовании этой утилиты на диске с существующими разделами все разделы и содержащиеся в них данные будут уничтожены.
Format.efi
Утилита Format.efi предназначена исключительно для форматирования EFI System Partition, созданного с помощью Fdisk.efi. Эта утилита поддерживает форматирование в файловые системы FAT и FAT32. Перед использованием Format раздел, созданный с помощью Fdisk, необходимо смонтировать. Для этого нужно воспользоваться командой mount, например mount blk4 fs8.
После монтирования раздела можно выполнить быстрое форматирование с помощью следующей команды: format fs8 /fs:fat /q.
Nvrbqot.efi *
Если запись, указывающая на раздел операционной системы Windows Server 2003, была случайно удалена из энергонезависимой памяти, для ее восстановления можно воспользоваться утилитой Nvrboot. efi. Также эту утилиту можно использовать для изменения записей в меню загрузчика вместо применения EFI Boot Menu Management.
Утилита Nvrboot позволяет изменить содержимое записей, добавленных средствами операционных систем Windows. Для изменения других записей, например EFI Shell или РХЕ, необходимо использовать Boot Menu Management.
Утилита Nvrboot позволяет использовать следующие команды.
Display. Эта команда позволяет вывести полный текст записи в меню загрузчика.
Modify. Эта команда позволяет изменить значение переменных Loadidentifier и OsLoadOptions для выбранной записи. Изменить пути для множественной загрузки невозможно,
Export. Эта команда позволяет создать резервную копию одной или всех записей из энергонезависимой памяти. Это отличный способ сохранения записей на случай их ошибочного
изменения. Файл с копией экспортированных записей можно записать на гибкий диск, с которого копию можно восстановить при повреждении содержимого энергонезависимой памяти.
Import. Эта команда позволяет импортировать одну или несколько записей в энергонезависимую память.
Сору. Эта команда используется для создания копии записи перед внесением изменений.
Erase. Эта команда используется для удаления ненужных записей из меню загрузчика.
Используйте эту команду с осторожностью. Система позволяет удалить все записи при использовании универсального символа звездочки (*).
Добавление приводов сменных носителей
Операционная система Windows Server 2003 предоставляет новую службу, которая называется RSM (Removable Storage Manager — управление сменными носителями). Служба RSM упрощает управление сменными носителями при использовании больших библиотек компакт-дисков с автоматической сменой диска и роботизированных библиотек магнитных лент. В то же время использование этой службы может усложнить управление такими простыми интерфейсами, как магазин из нескольких компакт-дисков.
В классической Windows NT каждому диску в библиотеке присваивалось собственное буквенное обозначение. Это значительно затрудняло работу с библиотеками компакт-дисков, поскольку букв просто не хватало на библиотеку из ста компакт-дисков. Служба RSM позволяет преодолеть такое ограничение, назначая букву устройству и обрабатывая замену носителей в фоновом режиме.
Для небольших приводов на 4 или 6 дисков отдельные буквы упрощали использование таких систем. Если пользователю требовался доступ к конкретному компакт-диску, он мог использовать соответствующую букву. Дорогие “магазинные” приводы поддерживали кэширование содержимого компакт-дисков и не требовали перемонтирования диска при каждом обращении. При использовании службы RSM это невозможно. Каждый диск должен быть смонтирован по имени с помощью команды mount. Для этого необходимо знать логический идентификатор носителя, установленный для компакт-диска службой RSM. Эта информация доступна в оснастке RSM консоли Computer Management (Управление компьютером).
Приводы сменных носителей бывают трех основных типов.
Быстрые приводы гибких дисков большого размера: Zip, Sony и т.д.
М едленные жесткие диски небольшого размера: J az, Shark и т.д.
Приводы с поддержкой записи на пластиковые носители: CD-R, CD-RW и магнитооптические приводы.
Большинство приводов подключается к параллельному порту или к шине SCSI. Все основные производители предоставляют драйверы для операционной системы Windows 2000, которые также работают в операционной системе Windows Server 2003. Диспетчер Plug and Play определяет привод во время инвентаризации и загружает соответствующий драйвер. После этого управление приводом передается службе RSM. Привод отображается в Explorer (Проводник) в виде пиктограммы привода сменных носителей.
Если привод сменных носителей подключен к шине SCSI, выберите идентификатор SCSI, который не будет вступать в конфликт с идентификаторами других устройств на шине. Кроме этого, не забывайте, что результат сканирования шины- SCSI определяет относительное расположение дисков для пути ARC в файле boot .ini. Если значение идентификатора привода сменных носителей меньше значения идентификатора основного диска, привод сменных носителей при сканировании окажется выше загрузочного диска, что приведет к ошибке Unable to Locate Ntoskrnl.exe.
Сменные носители не поддерживают разбиение на разделы. Это касается гибких дисков повышенной плотности LS120/240, дисков DVD-RAM, дисков Castlewood Orb и других приводов сменных носителей большого объема.
Если на сервере установлены приводы сменных носителей, назначение букв дисков может заметно усложниться. В процессе начальной стадии установки диски и разделы дисков сканируются в таком порядке.
Системному разделу на загрузочном диске назначается буква “С”.
Загрузочному разделу, если он находится на другом диске, назначается буква “D”.
Следующие по алфавиту буквы назначаются логическим дискам в расширенном разделе и сменным носителям.
Для базовых разделов на фиксированных дисках буквы назначаются в последнюю очередь.
Такой порядок сканирования означает, что приводы сменных носителей получают буквы для дисков раньше разделов на фиксированных дисках. Иногда такой порядок назначения букв нежелателен. После завершения установки можно изменить установленные буквенные обозначения.
Если привод сменных дисков подключается после установки операционной системы, это не окажет никакого влияния на уже назначенные буквы для дисков. Привод получит следующую по алфавиту свободную букву. Например, если существуют разделы Е, F и М, привод сменных носителей получит букву “G”.
Если в системе присутствует два или больше приводов сменных носителей, при отключении и переустановке они могут меняться друг с другом буквенными обозначениями дисков.
Если в системе подключен сетевой диск, которому назначена буква диска, то привод сменных носителей получит эту букву диска, а сетевой диск получит следующую букву. LanMan Server пытается использовать букву диска и выводит сообщение об ошибке The Local Device Name Is Already In Use. Система должна быть настроена на разрыв сетевого соединения и повторное подключение с использованием другой буквы диска.
Добавление сетевого адаптера
Даже если не рассматривать остальные функции подсистемы Plug and Play, то ее возможности значительного упрощения установки и настройки сетевых адаптеров делает ее достойной пристального внимания.
Выбирая сетевые адаптеры для сервера, рассматривайте только дорогие модели от известных производителей. Компания Microsoft отказалась от поддержки многих адаптеров для настольных компьютеров и программных адаптеров. Кроме этого, возможность распределения нагрузки процессора в соответствии со спецификацией Network Driver Interface Specification (NDIS) 5.0 позволяет увеличить производительность сервера. Дополнительная информация приводится по адресу www.microsoft. com/hwdev/tech/network/taskoffload. asp.
Драйверы NDIS для операционной системы Windows имеют заслуженную репутацию сложных в использовании. Подсистема РпР вместе с правильно подготовленным файлом с расширением . inf и драйвером, созданным профессиональными разработчиками драйверов WDM, значительно упрощает установку сетевого адаптера, вплоть до полного невмешательства администратора.
Диспетчер Plug and Play обнаруживает новое устройство во время инвентаризации устройств на шине при загрузке компьютера. Если сервер поддерживает “горячую” замену адаптеров PCI и эту возможность поддерживают сетевые адаптеры, подсистема РпР обнаружит устройство сразу после освобождения программной блокировки шины PCI.
Для назначения ресурсов подсистема РпР использует информацию от интерфейса ACPI, который получает информацию из заголовков PCI, предоставленных устройством. Кроме
этого, подсистема РпР обнаруживает устаревшие сетевые адаптеры, хотя таких адаптеров осталось немного и их использования стоит избегать. Если выделенные устаревшему адаптеру ресурсы конфликтуют с устройствами РпР, диспетчер Plug and Play постарается назначить устройству РпР другие ресурсы. Сведения о таких конфликтах обычно записываются в журнале событий.
По умолчанию новые сетевые интерфейсы настроены на использование протокола DHCP (Dynamic Host Configuration Protocol). Для изменения параметров TCP/IP на статические значения или для установки дополнительных транспортных протоколов, клиентов или служб в окне Network Connections (Сетевые подключения) откройте окно Properties (Свойства соединения).
Если в сети отсутствует сервер DHCP, новый интерфейс будет получать адрес с помощью технологии, которая называется APIPA (Automatic Private IP Addressing — автоматическая адресация частных IP). Этот механизм позволяет назначать адреса из диапазона 169.254.0.0/16. Владельцем этого диапазона адресов является компания Microsoft, и она выбрала для этого диапазона именно такое назначение.
Клиент APIPA выбирает случайный адрес из 65 535 адресов, доступных в этом диапазоне. После этого на выбранный адрес отправляются тестовые эхо-пакеты, определяющие, не назначен ли этот адрес другому клиенту. Перед выдачей на консоль сообщения об ошибке такая процедура повторяется три раза. После получения адреса с помощью механизма APIPA клиент продолжает поиск сервера DHCP каждые пять минут.
Если два сетевых интерфейса подключены к одному сегменту сети, будет выдано сообщение об ошибке Duplicate Computer Name. Это связано с тем, что второй адаптер попытается зарегистрировать то же имя NetBIOS, которое было закреплено за первым адаптером. Устанавливая несколько сетевых адаптеров, необходимо или настраивать несколько подсетей IP или использовать Network Bridge.
Диагностика проблем в работе сети
Дополнительная вкладка Task Manager (Диспетчер задач) в операционной системе Windows Server 2003 позволяет контролировать загрузку сети. На этой вкладке можно быстро получить оценку производительности интерфейса.
Информация о состоянии интерфейса, доступная после открытия окна Network Connections (Сетевые подключения) или выбора значка интерфейса в Notification Area (Область уведомлений), предоставляет возможность Repair (Исправить), которая позволяет получить новый адрес от сервера DHCP (если такой сервер существует) и выполнить другие действия по настройке работы в сети.
Скрытые сетевые адаптеры
Если ранее с сервера был удален сетевой адаптер, при попытке установки нового адаптера может быть выдано сообщение об ошибке. Это связано с неполным удалением интерфейса из системы и сокрытием интерфейса в окне Device Manager (Диспетчер устройств). Откройте оснастку Device Manager (Диспетчер устройств) и выведите список скрытых устройств с помощью команды View^Show Hidden Devices (Вид^Показать скрытые устройства). После этого удалите старый сетевой адаптер.
При наличии более сложных проблем воспользуйтесь окном Network Diagnostics (Диагностика сети) из Help and Support Center (Центр справки и поддержки). В этом окне выводятся параметры, полученные с помощью интерфейса WMI (Windows Management Instrumentation). В окне отображается текущее состояние сетевого интерфейса.
Кроме этого, существует полезная утилита с интерфейсом командной строки, netdiag, которая выполняет те же проверки и выводит отчет на консоль. Эта утилита удобна при соз-
Дании сценариев и файлов пакетной обработки для получения периодических моментальных снимков состояния системы. .
В операционной системе Windows Server 2003 для команды netsh появился новый параметр, который можно использовать при диагностике неисправностей. Это параметр -diag. Использование этого параметра совместно с командой show позволяет получить краткий список установленных в данное время параметров и статистику для всех сетевых интерфейсов и таких сетевых служб, как DHCP и WINS.
Использование нескольких мониторов
Оператор или дизайнер продукта CAD обычно работает с большим монитором с диагональю размером 21 дюйм или с двумя мониторами. Операционные системы Windows 2000 и Windows Server 2003 поддерживают использование нескольких экранов, но, кроме этого, операционные системы Windows Server 2003 и Windows ХР поддерживают видеоадаптеры DualView, которые позволяют выводить разные фрагменты изображения на разные экраны.
Адаптеры DualView выпускаются небольшим количеством производителей. Для настольных компьютеров можно использовать линейку адаптеров от компании Matrox (Gxxx), поддерживающих технологию Dual Head. Такие адаптеры позволяют выводить полноэкранное изображение фильма DVD на один монитор и графические приложения — на другой. Такая конфигурация иногда оказывается полезной, если во время работы с электронными таблицами возникает желание посмотреть Шрек. Основными производителями контроллеров DualView для портативных компьютеров являются Trident Microsystems и SiS.
Покупая второй видеоадаптер для компьютера, оборудованного видеоадаптером AGP, старайтесь не покупать такую же модель, но для шины PCI. Для таких видеоадаптеров используются другие драйверы, которые, однако, имеют такие же имена, как AGP-драйверы.
Процедура настройки системы с двумя видеоадаптерами совпадает с процедурой настройки одного видеоадаптера с поддержкой технологии DualView. Экраны настраиваются с помощью окна Display Properties (Свойства экрана), к которому можно получить доступ, щелкнув правой кнопкой мыши на рабочем столе и выбрав команду Properties (Свойства) из контекстного меню. В таком случае на вкладке Settings (Настройки) будут отображены два монитора.
На экране Primary (Основной) определяется, на каком мониторе будут отображаться меню Start (Пуск) и панель задач. Параметры операционной системы не влияют на параметры BIOS, поэтому результат тестирования POST при загрузке компьютера будет отображаться на обоих мониторах. -
По умолчанию логические мониторы расположены рядом на одном уровне. Характеристики мониторов можно изменить. Для каждого монитора можно указать собственную частоту обновления экрана и разрешение, но это может привести к искажению изображений при переносе с одного монитора на другой.
Hardware Management
(Управление оборудованием)
Новая возможность операционной системы Windows Server 2003 R2 предоставляет поддержку интерфейса IPMI (Intelligent Platform Management Interface) с помощью драйвера и поставщика, которые позволяют Windows взаимодействовать с инструментарием IPMI на материнской плате для сбора разнообразной информации об аппаратных средствах (например о температуре центрального процессора). Это взаимодействие с материнской платой позволяет реплицировать содержимое системного журнала событий, что позволяет выполнять мониторинг и предупреждать о возникновении опасных ситуаций с аппаратными средствами.
Эта новая функция Windows Server 2003 R2 реализована с использованием WS-Manage- ment — основанного на веб-службах протокола, являющегося отраслевым стандартом. WS-Management использует для безопасной передачи информации протокол HTTPS, что обеспечивает работу через брандмауэр.
WinRM предоставляет интерфейс командной строки для типичных задач управления, а также прикладной программный интерфейс (API)-для написания сценариев администрирования, основанных на Windows Script Host.
Используя WinRM, вы можете создавать сценарии, взаимодействующие с Baseboard Management Controller (ВМС, контроллером управления материнской платой) для отслеживания состояния аппаратного обеспечения сервера и контроля над ним. ВМС — это отдельный микроконтроллер с собственным сетевым адаптером, который подключается к системной плате сервера и может отслеживать его состояние, даже если сервер выключен или функционирует некорректно. Поставщик WMI (Windows Management Interface — инструментарий управления Windows) для IPMI предоставляет шесть новых классов для доступа к информации ВМС с помощью сценариев.
По умолчанию WinRM не устанавливается при установке Windows Server 2003 R2. Чтобы добавить его, на Control Panel (Панель управления) откройте оснастку Add or Remove Programs (Установка и удаление программ) и выберите Add/Remqve Windows Components (Установка/удаление компонентов Windows).
Диагностика неисправностей при подключении новых устройств
При подключении нового устройства высока вероятность нарушения стабильной работы сервера. Для исправления ситуации иногда достаточно выполнить простые профилактические действия. При возможности верните сервер в предыдущее состояние и проверьте, осталась ли проблема. Если проблема не исчезла, начните анализ внесенных изменений и выясните их связь с наблюдаемыми проблемами. В этом разделе рассматриваются популярные утилиты, предназначенные для диагностики проблем, которые появляются при установке новых аппаратных компонентов.
Обновление и откат драйверов устройств
Проще всего для обновления драйвера использовать оснастку Device Manager (Диспетчер устройств). Сначала получите драйвер устройства для операционной системы Windows Server 2003, Windows ХР или Windows 2000 и связанный с ним файл INF, после чего следуйте инструкциям процедуры 3.3.
Процедура 3.3. Обновление драйвера устройства
Щелкните правой кнопкой мыши на пиктограмме устройства и выберите команду Update Driver (Обновить драйвер). Запустится Hardware Update Wizard (Мастер обновления оборудования).
Выберите пункт Install from a List or Specific Location (Установка из указанного места).
Щелкните на кнопке Next (Далее). Откроется окно Please Choose Your Search (Задайте параметры поиска и установки). Выберите пункт Don't Search (Не выполнять поиск).
Щелкните на кнопке Next (Далее). Откроется окно Select Network Adapter (Выберите драйвер для этого устройства). (Конечно, открывшееся окно зависит от выбранного устройства.)
Щелкните на Have Disk (Установить с диска). Просмотрите список в открывшемся окне навигации и найдите драйвер и связанный с ним файл INF.
Выберите соответствующий сценарий INF. Система выдаст строки из этого сценария. Убедитесь, что выбранное значение соответствует устанавливаемому устройству.
Щелкните на кнопке Next (Далее) для установки драйверов.
Щелкните на кнопке Finish (Готово) для завершения работы мастера.
На этом этапе в окне Properties (Свойства) для соответствующего устройства выводятся данные о новом драйвере. Если компьютер начал работать нестабильно или операционная система аварийно завершила работу, загрузитесь в Safe Mode (Безопасный режим) для отката драйвера устройства до выяснения причины нестабильности. Для этого следуйте инструкциям, приведенным в процедуре 3.4.
Процедура 3.4. Откат драйвера устройства
, Откройте окно Properties (Свойства) для соответствующего устройства.
Перейдите на вкладку Driver (Драйвер), как показано на рис. 3.19.
Щелкните на кнопке Roll Back Driver (Откатить).
Система запросит подтверждение действия. Щелкните на кнопке ОК для завершения отката драйвера.
Рис. 3.19. Окно свойств драйвера устройства и кнопка Roll Back Driver (Откатить)
Старый драйвер будет извлечен из библиотеки драйверов и установлен поверх нового. В окне Properties (Свойства) теперь восстановлена информация для прежнего драйвера.
Создание загрузочного диска Windows Server 2003
Часто при добавлении новых устройств или интерфейсов массового хранения компьютер отказывается загружаться. Обычно это происходит из-за изменения пути ARC к загрузочному разделу Windows Server 2003 после добавления нового диска или интерфейса. В числе других причин ошибок при загрузке можно назвать следующие.
Повреждение или удаление системных файлов Windows Server 2003 в корневом каталоге загрузочного раздела.
Повреждение вирусом загрузочного сектора.
При попытке настроить альтернативную загрузку запуск пользователем утилиты SYS на диске С.
Отказ основного диска в зеркалированном массиве (только в программных массивах RAID).
На компьютере с интерфейсом SCSI без BIOS повреждение или удаление файла ntbootdd.sys.
Во всех перечисленных ситуациях с файлами из каталога \Windows, скорее всего, ничего не случилось; главное — обойти поврежденные файлы и дисковые структуры, расположенные в начале загрузочного диска. На компьютере с архитектурой IA32 для этой цели можно воспользоваться гибким диском с теми же файлами, которые расположены в корневом каталоге загрузочного диска Windows Server 2003. Такой гибкий диск называется спасательным загрузочным диском (fault tolerant boot disk).
На компьютерах на основе архитектуры IA64 использовать спасательный загрузочный диск нет смысла и возможности. Для выбора загрузочного раздела используется командный интерпретатор EFI. Дополнительная информация по этому вопросу содержится в главе 1, “Установка и настройка Windows Server 2003”.
При создании спасательного загрузочного диска важно, чтобы гибкий диск был отформатирован на компьютере под управлением операционной системы Windows Server 2003 или Windows ХР. Системные файлы из этих операционных систем поддерживают загрузку более ранних операционных систем Windows NT, но не наоборот. Загрузка операционной системы Windows Server 2003 с помощью спасательного загрузочного диска Windows 2000 невозможна.
. Создание спасательного загрузочного диска Windows Server 2003 описывается в процедуре 3.5.
Процедура 3.5. Создание спасательного загрузочного диска
Воспользуйтесь утилитой attrib, чтобы снять атрибуты Read-only (Только для чтения) и Hidden (Скрытый) для следующих системных файлов в корневом каталоге загрузочного диска: ntldr
ntdetect.com
boot.ini
ntbootdd. sys (если такой файл присутствует)
Вставьте пустой гибкий диск в привод гибких дисков и отформатируйте его. Если диск не содержит дефектов, можно воспользоваться функцией Quick Format (Быстрое форматирование).
После завершения форматирования скопируйте на гибкий диск файлы, перечисленные в п. 1 этой процедуры.
Откройте текстовый редактор Notepad (Блокнот) и отредактируйте файл boot. ini на гибком диске.
Измените значение параметра Time Setting на -1. Это позволит отключить функцию обратного отсчета времени (делать это не обязательно, но лично автору этой книги намного проще проводить диагностику при отключенном таймере).
Сохраните изменения и закройте редактор Notepad (Блокнот).
Перезагрузите компьютер с помощью спасательного загрузочного диска.
После появления меню загрузчика выберите пункт, соответствующий разделу с операционной системой Windows Server 2003. Нажмите клавишу <Enter>.
Путь ARC в файле boot. ini сообщает загрузчику Ntldr расположение загрузочных файлов на жестком диске. Дальнейший процесс загрузки должен пройти без проблем. На этом этапе гибкий диск больше не нужен. Извлеките его из привода.
Держите наготове копию спасательного загрузочного диска для загрузки рабочих станций и серверов. Если размер загрузочного раздела составляет более 7,8 Гбайт, этот раздел имеет нестандартную геометрию или расположен на диске, подключенном к контроллеру SCSI без BIOS, в пути ARC должен быть указан параметр signature (). Значение в скобках записывается в главную загрузочную запись (MBR) загрузочного диска. Файл boot. ini для такого компьютера нельзя будет использовать для загрузки других компьютеров. Пометьте загрузочный диск и храните его в безопасном месте.
Решение проблем в работе интерфейса SCSI
Если диспетчер Plug and Play не распознал контроллер или подключенный к контроллеру диск; если возникает повреждение данных или заметное количество связанных с устройствами SCSI ошибок в журнале событий, то самой вероятной причиной этого является неправильная оконечная нагрузка (termination) шины или превышение допустимой длины кабеля. Ниже перечисляются возможные причины неправильной оконечной нагрузки.
Одновременное использование активных и пассивных терминаторов.
Одновременное использование кабелей различных типов, что приводит к проблемам из-за несовпадения задержек и сопротивления.
Наличие слишком большого количества терминаторов, например, когда контроллер SCSI в центре шины выступает в роли активного терминатора и по одному терминатору установлено на каждом из концов шины.
Отсутствие необходимого блока сопротивлений.
Подключение блока сопротивлений при включенной активной оконечной нагрузки.
Предположительное включение активного терминатора на устройстве, в то время как соответствующая перемычка установлена в неправильное положение.
Предположительное отключение активного терминатора на устройстве, в то время как соответствующая перемычка установлена в правильное положение (и активный терминатор включен).
Конкретная комбинация кабеля и терминатора могла работать в операционной системе Windows NT 4.0, но операционная система Windows Server 2003 налагает большие ограничения на минимальную производительность жесткого диска. Компоненты с низкой производительностью быстро выходят из строя. Замените интерфейс на указанный в HCL. Если контроллер встроен в материнскую плату, установите адаптер PCI и отключите встроенный контроллер.
Если в компьютере уже присутствует адаптер SCSI и необходимо добавить точно такой же адаптер (совпадают производитель и модель), для предотвращения конфликтов может потребоваться отключение BIOS на втором адаптере. На работу операционной системы Windows Server 2003 это не оказывает никакого влияния. Но если операционную систему Windows Server 2003 установить на диск, подключенный ко второму адаптеру, программа установки скопирует драйвер мини-порта SCSI в корневой каталог раздела и назовет его ntbootdd. sys, чтобы загрузчик Ntldr мог его использовать для сканирования шины SCSI.
Отказ основного диска
Если отказывает основной зеркалированный диск, для загрузки с вторичного диска можно воспользоваться спасательным загрузочным гибким диском. Если зеркалированный диск является вторым на шине SCSI, то путь ARC будет выглядеть, как multi (0) disk (0) rdisk (1) partition(1)\WINNT.
Кроме этого, программа установки для идентификации диска воспользуется параметром signature () для идентификации диска в файле boot. ini. Значение в скобках представляет собой специальную сигнатуру, которая записывается программой установки в MBR.
После подключения второго контроллера SCSI может быть выдано сообщение об ошибке Unable to Locate Operating System. Виновата в этом шина PCI. В большинстве случаев адаптер SCSI с меньшим по значению адресом lOBase рассматривается как загрузочный. В системах, поддерживающих стандарт Plug and Play, чем ближе разъем к процессору, тем меньший адрес lOBase предоставляется адаптеру. Таким образом, если второй адаптер подключается немного ближе к процессору, порядок выбора загрузочного диска изменяется. Попробуйте поменять старый и новый адаптеры местами. Диспетчер Plug and Play назначает идентификаторы устройств в соответствии с номером разъема PCI; поменяв местами адаптеры, можно спровоцировать новую инвентаризацию устройств Plug and Play.
Исправление "зависаний" на компьютерах, не поддерживающих РпР
Если компьютер “зависает” в момент запуска утилиты ntdetect, проблема может быть связана с материнской платой, оперативной памятью или интерфейсом жесткого диска. Утилита ntdetect предназначена для инвентаризации аппаратных компонентов. Если это невозможно, утилита “зависает”.
Пока не станет ясно, какой компонент приводит к появлению ошибки, проблему исправить не удастся. Существует несколько методов поиска такого компонента. Одним из вариантов является нажатие клавиши <Е8> в меню загрузчика и включения протокола загрузки. При этом протокол записывается на жесткий диск. Однако если не удается загрузить компьютер, то невозможно и прочитать журнал.
Второй способ предполагает использование отладочной версии утилиты ntdetect. com, имя файла которой — ntdetect.chk. Файл ntdetect.chk расположен на установочном компакт-диске Windows Server2003 в каталоге \Support\Debug\l386. Использование утилиты Ntdetect. chk рассматривается в процедуре 3.6.
Процедура 3.6. Использование Ntdetect. chk
Средствами операционной системы Windows Server 2003 создайте “спасательный" загрузочный гибкий диск.
Скопируйте утилиту ntdetect. chk на созданный гибкий диск.
Переименуйте ntdetect. com на ntdetect. old.
Переименуйте ntdetect. chk на ntdetect. com.
Загрузите компьютер с помощью созданного диска.
Отладочная версия утилиты ntdetect работает так же, как обычная, но она выдает на экран список обнаруженных устройств. В момент “зависания” системы компонент, показанный на экране последним, является причиной “зависания”. Обычно причиной “зависания” являются конфликты в распределении номеров IRQ и lOBase.
Отслеживание используемого объема памяти ядра
Стоит хранить долговременную статистику по использованию памяти ядром, что позволяет сразу замечать ненормальные тенденции. Самым удобным инструментом для такого мониторинга является Performance Monitor (Монитор производительности). Для его запуска воспользуйтесь командой Starts Programs^ Administrative Tools1* Performance (Пуск^Прог- pa ммы ■* Администрирование ■* Производительность ).
На консоли Performance Monitor содержатся две оснастки. Оснастка System Monitor (Системный монитор) представляет собой элемент управления ActiveX, который предназначен для графического вывода счетчиков производительности. Оснастка Performance Logs and Alerts (Журнал производительности и уведомления) предназначена для сбора статистики о производительности с последующей записью в журнал и отправкой предупреждений на консоль или в журнал событий. Журналы предоставляют возможность сбора долговременной статистики по производительности. Настройка журнала на сбор статистики об использовании памяти ядра описывается в процедуре 3.7.
Рис. 320. Консоль Performance Monitor (Монитор производительности)
Процедура 3.7. Настройка монитора производительности на сбор статистики об использовании памяти ядра
Откройте дерево в оснастке Performance Logs and Alerts (Журнал производительности и уведомления) и выделите Counter Logs (Журналы счетчиков).
Щелкните правой кнопкой мыши на пустой области в правой панели и выберите из контекстного меню команду New Log Settings (Новые параметры журнала). Откроется окно New Log Settings (Новые параметры журнала).
Введите название журнала, например, Long-Term kernel Memory Use (Долговременное использование памяти ядра).
Щелкните на кнопке ОК. Откроется окно управления журналом. Название окна совпадает с названием журнала, которое вводилось в п. 3.
Щелкните на кнопке Add Counters (Добавить счетчики). Откроется окно Select Counters (Добавить счетчики).
В группе Performance Object (Объект) выберите Memory (Память) из открывающегося списка.
Выберите переключатель All Counters (Все счетчики). Долговременная статистика требует создания моментальных дампов памяти через большие интервалы времени, например каждый час, поэтому сбор статистики для всех счетчиков не окажет заметного влияния на производительность сервера.
Щелкните на кнопке Add (Добавить) для добавления счетчиков в журнал. Щелкните на кнопке Close (Закрыть) для возврата в основное окно управления журналом.
Установите параметр Sample Data Every (Снимать показания каждые) равным 1 Hour (1 Час).
Откройте вкладку Log Files (Файлы журнала). По умолчанию журнал хранится в подкаталоге \ Per flog корневого каталога системного раздела. Для изменения каталога щелкните на кнопке Browse (Настроить).
По умолчанию в качестве имени файла журнала используется название журнала с добавлением шестизначного числа. Если в нижней части окна установить параметр Log File Size Limit (Размер файла журнала), после достижения журналом указанного объема файл журнала закрывается и создается новый файл журнала.
Щелкните на кнопке ОК, чтобы сохранить параметры и вернуться на консоль Performance Monitor (Монитор производительности).
Статистические данные имеет смысл собирать несколько дней. Содержимое журнала можно просматривать с помощью оснастки System Monitor (Системный монитор). Для этого выберите файл журнала в качестве источника данных для диаграммы, как описано в процедуре 3.8.
Процедура 3.8. Создание графика на основе журнала производительности
Щелкните на значке System Monitor (Системный монитор). В правой панели появится пустая диаграмма.
Щелкните правой кнопкой мыши на диаграмме и выберите из контекстного меню команду Properties (Свойства). Откроется окно Properties (Свойства).
Откройте вкладку Source (Источник).
Выберите переключатель Log File (Файлы журнала).
Щелкните на кнопке Browse (Обзор) для запуска утилиты Select Log File (Выбор файла журнала). Утилита автоматически переходит в каталог \ Perflog.
Дважды щелкните мышью на выбранном журнале.
Щелкните на кнопке ОК для сохранения выбора, закройте окно и возвращайтесь в основное окно Performance (Производительность). Пока нет никакого результата.
Щелкните правой кнопкой мыши на правой панели и выберите из контекстного меню пункт Add Counter (Добавить счетчик). Откроется окно Add Counters (Добавление счетчика).
Выберите переключатель All Counters (Все счетчики) и щелкните на кнопке Add (Добавить). После этого щелкните на кнопке Close (Закрыть). На диаграмме будут показаны значения всех счетчиков. Если на диаграмме не видна интересующая информация, удалите некоторые счетчики.
На диаграмме показана статистика, собранная при записи журнала. Может быть показано до ста точек данных. Для включения выделения нажмите комбинацию клавиш <Ctrl+H>. После этого каждый выбранный в нижней части окна счетчик на диаграмме будет выделен белой линией.
В следующей главе
Теперь, когда операционная система Windows Server 2003 установлена на нескольких серверах, пришло время сделать с ней что-нибудь полезное. Но сервер невозможно использовать, если его нельзя найти. В следующих двух главах рассматриваются преобразование имен и поиск служб.
Х
отя операционная система Windows Server 2003, без сомнения, предназначена для работы с протоколом TCP/IP, несколько призраков ее предшественниц из эпохи NetBIOS все еще бродят в уголках системы. Эти призраки проявляются при попытке преобразования имени компьютера или службы в IP-адрес, когда необходимо подключить сетевой диск или воспользоваться другой возможностью Windows для работы в сети.
Например, рассмотрим конфигурацию домена, показанную на рис. 4.1. Если клиент Windows не в состоянии определить соответствующий домену и контроллеру домена 1Р-адрес, аутентификация клиента или пользователей окажется невозможной. Если преобразование имен серверов невозможно, доступ клиентов к сетевым ресурсам окажется закрытым. Таким образом, преобразование имен является очень важной задачей. Перед началом промышленного развертывания операционной системы Windows Server 2003 стоит создать устойчивую инфраструктуру преобразования имен.
В этой главе рассматривается классическое преобразование имен NetBIOS, применяемое для поддержки низкоуровневых клиентов и приложений, которые все еще используют имена NetBIOS. В главе 5, “Управление службой DNS”, рассматривается преобразование имен на основе DNS. Операционная система Windows Server 2003 поддерживает использование обоих методов в зависимости от ситуации и параметров настройки.
Поскольку преобразование имен является элементом реализации сетевых протоколов, в этой главе рассматривается подсистема работы в сети Windows Server 2003 и особое внимание уделяется адресам и портам, которые используются для преобразования имен. После этого рассматривается реализация системы преобразования имен, а конкретно мы изучим следующие вопросы.
Утилиты диагностики работы в сети
Преобразование имен NetBIOS с помощью широковещательных запросов, с помощью Lmhosts и с помощью службы WINS
Установка службы W IN S
Настройка репликации WINS и управление ею
Отключение преобразования имен NetBIOS
Company.comИмя NetBIOS: COMPANYCompany.comИмя NetBIOS: COMPANYSVR1SVR1Рис. 4.1. Простая сеть для изучения классического метода преобразования именРис. 4.1. Простая сеть для изучения классического метода преобразования именДомен Windows NT Имя NetBIOS: EASTДомен Windows NT Имя NetBIOS: EASTИмя NetBIOS:PDC-EASTИмя NetBIOS:PDC-EASTКлиент под управлением Windows NT 4.0Клиент под управлением Windows NT 4.0
Company.com
Имя NetBIOS: COMPANY
Company.com
Имя NetBIOS: COMPANY
SVR1
SVR1
Рис. 4.1. Простая сеть для изучения классического метода преобразования имен
Рис. 4.1. Простая сеть для изучения классического метода преобразования имен
Домен Windows NT Имя NetBIOS: EAST
Домен Windows NT Имя NetBIOS: EAST
Имя NetBIOS:
PDC-EAST
Имя NetBIOS:
PDC-EAST
Клиент под управлением Windows NT 4.0
Клиент под управлением Windows NT 4.0
Новые возможности операционной системы Windows Server 2003
По сравнению с операционной системой Windows 2000 в операционной системе Windows Server 2003 не появилось никаких новых функций по отношению к преобразованию имен. Была только усовершенствована оснастка WINS для упрощения выбора, сортировки и просмотра записей базы данных.
Обзор сетевой подсистемы
Windows Server 2003
В этом разделе рассматриваются различные методы определения адресов и портов на каждом сетевом уровне в операционной системе Windows Server 2003. В качестве основы здесь рассматривается стандартная модель OSI (Open System Interconnection — взаимодействие
открытых систем), показанная на рис. 4.2. Сетевая подсистема Windows не совсем точно соответствует модели OSI, но структура сетевой подсистемы достаточно близка к модели OSI, чтобы позволить провести параллели.
OSI Windows 2000
ПрикладнойПрикладнойФайлы LanManServer.dll и Srv.sys (Сервер)LanManWorkstation.dll иMrxsmb.sys(Клиент)Afd. sys (Сокеты)
Прикладной
Прикладной
Представления данныхПредставления данныхHe реализован отдельноHe реализован отдельноСеансовыйСеансовыйТранспортныйТранспортныйСетевойСетевойTdi. sys (Интерфейс транспортного драйвера) Tcpip. sys (TCP/IP, включает ARP, ICMP, IGMP) Netbt. sys (NetBIOS поверх TCP/IP)Tdi. sys (Интерфейс транспортного драйвера) Tcpip. sys (TCP/IP, включает ARP, ICMP, IGMP) Netbt. sys (NetBIOS поверх TCP/IP)Подуровень управлениялогическим соединениемПодуровень управлениялогическим соединениемКанальныйКанальныйПодуровень управления доступом к средеПодуровень управления доступом к средеNdis. sys (Network Driver Interface Specification — спецификация интерфейса сетевого драйвера) <minlport>. sys (Драйвер сетевого адаптера)Ndis. sys (Network Driver Interface Specification — спецификация интерфейса сетевого драйвера) <minlport>. sys (Драйвер сетевого адаптера)Рис. 4.2. Схема модели OSI по сравнению с сетевой подсистемой Windows Server 2003Рис. 4.2. Схема модели OSI по сравнению с сетевой подсистемой Windows Server 2003Netbios. sys (Эмулятор NetBIOS)
Представления данных
Представления данных
He реализован отдельно
He реализован отдельно
Сеансовый
Сеансовый
Транспортный
Транспортный
Сетевой
Сетевой
Tdi. sys (Интерфейс транспортного драйвера) Tcpip. sys (TCP/IP, включает ARP, ICMP, IGMP) Netbt. sys (NetBIOS поверх TCP/IP)
Tdi. sys (Интерфейс транспортного драйвера) Tcpip. sys (TCP/IP, включает ARP, ICMP, IGMP) Netbt. sys (NetBIOS поверх TCP/IP)
Подуровень управлениялогическим соединением
Подуровень управлениялогическим соединением
Канальный
Канальный
Подуровень управления доступом к среде
Подуровень управления доступом к среде
Ndis. sys (Network Driver Interface Specification — спецификация интерфейса сетевого драйвера) <minlport>. sys (Драйвер сетевого адаптера)
Ndis. sys (Network Driver Interface Specification — спецификация интерфейса сетевого драйвера) <minlport>. sys (Драйвер сетевого адаптера)
Рис. 4.2. Схема модели OSI по сравнению с сетевой подсистемой Windows Server 2003
Рис. 4.2. Схема модели OSI по сравнению с сетевой подсистемой Windows Server 2003
Уровень данных
В модели OSI уровень данных определяет методы упаковки данных, передаваемых по физической среде передачи. Согласно стандарту IEEE 802.1, в модели OSI уровень данных разделяется на уровень Media Access Control (МАС) и уровень Logical Link Control (LLC).
Сетевая подсистема Windows не имеет отдельной реализации уровней управления доступом к среде и управления логическим соединением. Вместо этого управление логическим соединением обрабатывается драйверами сетевого транспорта, а управление доступом к среде обеспечивается драйвером NDIS (Network Driver Interface Specification), файл Ndis. sys, который работает совместно с драйверами мини-порта и драйверами фильтрации, предоставленными производителями оборудования. Драйверы мини-порта адаптера предоставляются в виде драйверов SYS, которые хранятся в каталоге \Windows\Drivers. Драйвер устанавливается при помощи соответствующего сценария INF, который хранится в каталоге \Windows\inf.
Имена сценариев INF, соответствующих драйверам сетевых адаптеров, начинаются с последовательности символов NET. '
Для распределения передаваемых данных по кадрам драйверы NDIS и драйверы минипорта адаптеров взаимодействуют с микросхемой контроллера. Метод передачи зависит от используемой физической среды передачи данных. Это может быть сеть Ethernet, Token Ring, сеть, соответствующая беспроводному стандарту IEEE 802.11, или другой метод связи.
В кадре передачи данных требуется наличие МАС-адреса, который указывает на интерфейс получателя. Драйвер NDIS не в состоянии определить этот адрес. Этот адрес предоставляется протоколом более высокого уровня.
Компоненты адреса МАС ,
МАС-адрес записан в ПЗУ адаптера. Адрес представляет собой уникальное число размером 6 байт. Первые три байта идентифицируют производителя адаптера (например, компьютер автора этой книги оборудован сетевым адаптером NetGear, и в качестве идентификатора производителя в адресе МАС использовалась строка символов 00A0CC). Большинство основных производителей используют несколько идентификаторов МАС. Последние три байта МАС-адреса задаются производителем как порядковые номера.
Сетевой и транспортный уровни .
Немного выше в стеке протоколов OSI находятся сетевой уровень, который управляет передачей данных, и транспортный уровень, который управляет соединениями. В стеке протоколов TCP/IP функция сетевого уровня возлагается на протокол IP (Internet Protocol), а функция транспортного уровня реализуется с помощью протокола TCP (Transport Control Protocol) или UDP (User Datagram Protocol). Для реализации обоих протоколов в операционной системе Windows Server 2003 используется единственный драйвер tcpip. sys.
На сетевом уровне для адресации используются IP-адреса — 32-разрядные числа, которые обычно записываются в виде последовательности чисел, разделенных точками, например 10.1.50.233. Каждый IP-пакет, кроме широковещательных и многоадресных пакетов (multicast), должен содержать IP-адрес получателя. Ключевой задачей драйвера tcpip.sys как раз и является определение IP-адреса получателя.
На транспортном уровне в качестве адресов используются номера портов. Многие сетевые приложения для протокола TCP/IP используют хорошо известные номера портов. Например, служба FTP использует ТСР-порт 21, а служба HTTP — ТСР-порт 80. Номера портов и соответствующих им служб приведены в документе RFC 1700, “Assigned Numbers”.
Комбинация IP-адреса и номера порта называется сокетом (socket). Приложение более высокого уровня предоставляет драйверу tcpip. sys номер сокета. Драйвер, в свою очередь, “разбирает” сокет на составляющие и использует полученную информацию для создания дейтаграмм и пакетов.
Некоторые высокоуровневые приложения не используют протоколы UDP и TCP. Это так называемые чистые (raw) приложения IP, которые работают непосредственно на уровне протокола IP. Операционная система Windows Server 2003 поддерживает чистые приложения IP, если приложения используют стандартные вызовы API для получения идентификатора узла. Почетный член сообщества Интернет, Стив Гибсон (Steve Gibson), высказал опасения, что возможность непосредственного использования протокола IP может привести к атакам типа “отказ в обслуживании” и атакам на основе подмены адреса отправителя. Резюме данной работы мистера Гибсона можно найти по адресу grc . com/dos/xpsummary. htm.
Сеансовый уровень
Сеансовый уровень в модели протоколов OSI отвечает за управление сеансами связи, ориентированными на установку соединений. Такая связь напоминает общение людей. Два человека встречаются взглядами, пожимают друг другу руки и поддерживают внимание друг друга, пока один или другой высказывает свое мнение и выслушивает мнение собеседника.
Поддержка протокола IPv6 в операционной системе Windows Server 2003
На пути расширения глобальной сети возникает преграда из-за использования 32-разрядных адресов протокола IP, поскольку количество сетей и хостов при таких адресах довольно ограничено. Протокол IPv6, предназначенный для замены протокола IP и поддерживающий 128-разрядные адреса, стал стандартом уже несколько лет назад но широкого распространения не получил. Для поддержки новой версии протокола требуется модернизация устаревших аппаратных средств, а распространение стандарта NAT (Network Address Translation— трансляция сетевых адресов) позволило отказаться от необходимости немедленной модернизации протокола. Спецификация протокола IPv6 содержится в документе RFC 2460 "Internet Protocol Version 6 (IPv6) Specification".
Для включения поддержки протокола IPv6 в операционной системе Windows Server 2003 воспользуйтесь командой ipv6 install или щелкните на кнопке Install (Установить) в окне свойств интерфейса. Все управление протоколом IPv6 осуществляется с помощью утилиты ipv6. На одном компьютере можно одновременно использовать адресные пространства IPv4 и IPv6.
Вместо создания нового драйвера для сеансового уровня в стеке протоколов TCP/IP сеансовый уровень реализован средствами протокола TCP. В протоколе TCP каждому подключению назначается номер сеанса, дейтаграммы передаются последовательно и протокол гарантирует доставку дейтаграмм. Обычно для высокоуровневых приложений поддержка сеансов осуществляется посредством протокола TCP, но приложение может воспользоваться собственными средствами управления сеансами.
В приложениях, в которых не используется поддержка сеансов, один компьютер принимает данные только тогда, когда второму компьютеру “есть что сказать”. Если установка сеансов не требуется, высокоуровневые приложения используют протокол UDP. Этот протокол поддерживает упаковку данных в одну дейтаграмму, доставка которой не гарантируется. Обычно приложения используют протокол UDP для широковещательной и/или многоадресной рассылки информации и отправки коротких сообщений. Одним из примеров такого приложения является служба DNS.
Уровень представления данных
Функциональные возможности уровня представления данных, например шифрование и передача данных, в операционной системе Windows Server 2003 в виде отдельного набора драйверов не реализована. Реализация этих функциональных возможностей возлагается на приложения.
Прикладной уровень
Над всеми остальными уровнями модели OSI находится прикладной уровень. Именно на этом уровне работают сетевые службы операционной системы Windows Server 2003, например служба LAN Manager Workstation и связанный с ней драйвер файловой системы, mrxsmb. sys. Служба рабочей станции связывается со службой LAN Manager Server и соответствующим драйвером файловой системы srv. sys.
Сетевые приложения могут использовать любой метод идентификации других компьютеров. Компоненты сетевой подсистемы Windows, например, LAN Manager Workstation и LAN Manager Server используют имена компьютеров. Нередко такие имена компьютеров называют именами NetBIOS, поскольку командный протокол более низкого уровня, Server Message Block (SMB), создавался на основе протокола NetBIOS. Дополнительная информация приводится в разделе “SMB и имена NetBIOS”.
Имя NetBIOS состоит из 15 символов и еще одного символа идентификатора службы. Если в имени содержится меньше 15 символов, то перед завершающим символом идентификатора службы имя дополняется до 15 символов. Например, служба Messenger на компьютере SRV3 будет идентифицироваться как SRV3 <03>. Число в угловых скобках является идентификатором службы.
Ограничения имен NetBIOS
Имена NetBIOS часто называют “плоскими” именами из-за отсутствия иерархической структуры. “Плоские” имена должны быть уникальны в пределах домена Windows. Кроме этого, если узлы находятся в одном сегменте сети, “плоские” имена должны быть уникальны, даже если узлы принадлежат различным доменам или рабочим группам. Например, компьютер в домене LOX, IP-адрес которого — 10.1.1.1/16, не может иметь такое же имя, что и компьютер в домене BAGEL с IP-адресом 10.1.1.2/16. Эти ограничения не распространяются на протокол TCP/IP. Служба DNS совершенно спокойно ответит: “Вот мой брат Да- релл, а вот еще один мой брат Дарелл”.
Область видимости NetBIOS
Некоторое время назад компании Microsoft и IBM решили ввести схему иерархического именования доменов NetBIOS, которая называлась scope options (области видимости). Реализация областей видимости частично повторяла идею службы DNS, была слишком сложна в использовании и так и не стала популярной.
Имена NetBIOS могут содержать любые символы из набора ANSI, включая пробелы, за исключением символов /,\, [,],",;,:, I ,<,>,+,=,, ,?,*. В качестве примеров допустимых имен NetBIOS можно назвать следующие:
MYSUPERCOMPUTER MY_COMPUTER
MY COMPUTER MY-COMPUTER
MY#1COMPUTER MY!COMPUTER
Некоторые символы можно использовать в именах NetBIOS, но они не допустимы в именах DNS. Дополнительная информация приводится в документах RFC 952, “DOD Internet Host Table Specification", и RFC 1123, “Requirements for Internet Hosts — Application and Support”. Поскольку компьютеры под управлением операционной системы Windows Server 2003 часто одновременно поддерживают как стандарт TCP/IP, так и спецификацию NetBIOS, то лучше избегать использования символов, не поддерживаемых службой DNS. Символ подчеркивания часто используется в именах Windows и теперь включен в стандарт DNS, но старые версии серверов DNS все еще не поддерживают использование символа подчеркивания в именах компьютеров.
SMB и имена NetBIOS
NetBIOS является сетевым интерфейсом высокого уровня. Название интерфейса появилось в те времена, когда его реализация полностью осуществлялась аппаратными средствами. Сетевое приложение NetBIOS создает структуру данных, которая называется NCB (Network
Control Block — сетевой управляющий блок) и вызывает функцию BIOS для передачи содержимого NCB сетевому адаптеру. Для поддержки таких приложений в операционной системе Windows Server 2003 используется эмулятор NetBIOS. Эмулятор перехватывает вызовы BIOS и выполняет их преобразование в вызовы сетевых функций.
Приложения с поддержкой NetBIOS используются все реже. Приложения SMB, например LanMan Workstation и LanMan Server, используют систему имен NetBIOS, но приложениями NetBIOS не являются. Одинаковые системы именования появились в результате общей истории развития этих протоколов. Компания IBM разрабатывала протокол NetBIOS совместно с компанией Sytek. Созданный протокол стал стандартом де-факто для сетевых интерфейсов персональных компьютеров. В то же время компании IBM и Microsoft работали совместно с компанией ЗСот для разработки языка сетевых команд, а конечным результатом этой работы стало появление SMB. Более ранние версии приложений SMB использовали в качестве сетевого интерфейса NetBIOS, а в качестве транспортного протокола использовался NETBEUI (NetBIOS Extended User Interface).
От операционной системы Windows NT Advanced Server (и версий операционной системы OS/2 LAN Manager и Warp от компании IBM) протокол SMB развился до командного языка, независимого от транспортного протокола. Поскольку SMB и NetBIOS разрабатывались совместно, для обратной совместимости некоторые соглашения NetBIOS сохранились в SMB. Были сохранены система имен и преобразование имен из NetBIOS.
Службы NetBIOS
Последний символ в имени NetBIOS указывает на конкретную службу, например Browser, Domain Controller (контроллер домена) и т.д. Комбинация имени компьютера, которое записано в первых 15 символах, и идентификатора службы в последнем, 16-м, символе, формирует уникальный идентификатор сокета. На рис. 4.3 представлен список типов записей NetBIOS, управляемых службой WINS. Дополнительная информация об использовании консоли WINS приводится в разделе “Установка службы WINS” далее в этой главе.
Тип имени NetBIOS определяется по комбинации имени NetBIOS и идентификатору службы. Драйвер netbt. sys использует типы имен NetBIOS для управления регистрацией имен. Ниже рассмотрены методы управления регистрацией.
Unique (Уникальный). Указанная комбинация имени/службы может быть установлена только для одного IP-адреса. Если другой компьютер попытается зарегистрировать ту же комбинацию для другого IP-адреса, возникнет конфликт. Если для одного компьютера под управлением Windows Server 2003 назначено имя BORIS, то второму компьютеру регистрировать службу NetBIOS с таким же именем будет запрещено.
Group (Групповой). Несколько компьютеров могут использовать комбинацию имени и идентификатора службы. Тип Group используется драйвером netbt. sys для определения групп рассылки. Например, в сообщении SMB для групповой рассылки (многоадресного сообщения), отправленном в сеть 10.1.0.0, будет указан адрес групповой рассылки 10.1.255.255. С помощью групповой рассылки снижается нагрузка на компьютеры в сети, поскольку только члены группы получают соответствующие пакеты.
Multihomed. Такая комбинация имени/службы должна быть уникальной, но может быть связана с несколькими IP-адресами. Драйвер Netbt. sys использует тип Multihomed для описания служб на компьютере с несколькими сетевыми адаптерами. Комбинация имени/службы для данного компьютера регистрируется для каждого IP-адреса.
Internet. Эта специальная группа используется для обозначения основного и вторичного контроллеров домена. Основной контроллер домена (PDC) обычно выполняет репликацию на вторичный контроллер домена (ВВС), используя для эффективности групповую рассылку. Некоторые маршрутизаторы блокируют многоадресные пакеты, поэтому в таких
случаях используется служба WINS. Сервер WINS принимает многоадресные пакеты с данными репликации и направляет их в виде обычных пакетов через промежуточные маршрутизаторы к соответствующему контроллеру ВВС.
Reeorf Mapping | fteoeidOww» flecadTjpe» jReeorf Mapping | fteoeidOww» flecadTjpe» j.Display Records.Display RecordsSafectAI |OmAI ]SafectAI |OmAI ]Enabtig mA cethhg make» «йЬиФEnabtig mA cethhg make» «йЬиФD*phy *eee record types.И [OOh] WorkstationИ [03hJ MessengerИ [06h| RAS ServerИ [1Bh| Domain Master BrowserИ [1Ch| Domain Control»И [1Eh| Normal Group NameИ [1Fh| NetsDDEИ [20h] File ServerИ ГВ Ehl Network Monitor AgentD*phy *eee record types.И [OOh] WorkstationИ [03hJ MessengerИ [06h| RAS ServerИ [1Bh| Domain Master BrowserИ [1Ch| Domain Control»И [1Eh| Normal Group NameИ [1Fh| NetsDDEИ [20h] File ServerИ ГВ Ehl Network Monitor Agent^1*1'^1*1'Umi* inch «igrovedi the sprefitcorbyaLniquBownetUmi* inch «igrovedi the sprefitcorbyaLniquBownet
Reeorf Mapping | fteoeidOww» flecadTjpe» j
Reeorf Mapping | fteoeidOww» flecadTjpe» j
.Display Records
.Display Records
SafectAI |
OmAI ]
SafectAI |
OmAI ]
Enabtig mA cethhg make» «йЬиФ
Enabtig mA cethhg make» «йЬиФ
D*phy *eee record types.
И [OOh] Workstation
И [03hJ Messenger
И [06h| RAS Server
И [1Bh| Domain Master Browser
И [1Ch| Domain Control»
И [1Eh| Normal Group Name
И [1Fh| NetsDDE
И [20h] File Server
И ГВ Ehl Network Monitor Agent
D*phy *eee record types.
И [OOh] Workstation
И [03hJ Messenger
И [06h| RAS Server
И [1Bh| Domain Master Browser
И [1Ch| Domain Control»
И [1Eh| Normal Group Name
И [1Fh| NetsDDE
И [20h] File Server
И ГВ Ehl Network Monitor Agent
^1*1'
^1*1'
Umi* inch «igrovedi the sprefitcorbyaLniquBownet
Umi* inch «igrovedi the sprefitcorbyaLniquBownet
Puc. 43. Консоль WINS, на которой отображаются типы записей NetBIOS
Сетевые службы и преобразование имен
В табл. 4.1 представлены адреса, порты и имена, которые используются на каждом из уровней модели OSI согласно конфигурации, в которой эта модель реализована в операционной системе Windows Server 2003. Запущенные на каждом уровне процессы связываются с процессами такого же уровня на других компьютерах с помощью адресов, портов и имен.
Рассмотрим стек модели OSI и обратим внимание на преобразование имени NetBIOS в адрес, позволяющий связаться с процессом того же уровня на другом компьютере.
УровеньПротоколИмя или адресПриложенийSMBТранспортный,TCP или UDPСетевойIPКанальныйNDISИмя NetBIOS Номер порта IP-адрес МАС-адрес *УровеньПротоколИмя или адресПриложенийSMBТранспортный,TCP или UDPСетевойIPКанальныйNDISИмя NetBIOS Номер порта IP-адрес МАС-адрес *Таблица 4.1. Адреса и имена, которые используются на каждом сетевом уровне операционной системы Windows Server 2003Таблица 4.1. Адреса и имена, которые используются на каждом сетевом уровне операционной системы Windows Server 2003
УровеньПротокол
Имя или адрес
ПриложенийSMB
Транспортный,TCP или UDP
СетевойIP
КанальныйNDIS
Имя NetBIOS Номер порта IP-адрес МАС-адрес *
УровеньПротокол
Имя или адрес
ПриложенийSMB
Транспортный,TCP или UDP
СетевойIP
КанальныйNDIS
Имя NetBIOS Номер порта IP-адрес МАС-адрес *
Таблица 4.1. Адреса и имена, которые используются на каждом сетевом уровне операционной системы Windows Server 2003
Таблица 4.1. Адреса и имена, которые используются на каждом сетевом уровне операционной системы Windows Server 2003
Регистрация имени NetBIOS для компьютера с несколькими сетевыми интерфейсами и одним сетевым адаптером
Тип имени NetBIOS Multihomed не назначается комбинации имени/службы, соответствующей компьютеру с одним сетевым адаптером и несколькими IP-адресами. В службе WINS регистрируется только первый IP-адрес, который связан с сетевым адаптером, но подключение SMB
I
может создаваться для любого IP-адреса в перечне созданных привязок. В операционной системе Windows NT разрешалось создавать подключение только к самому верхнему IP-адресу в перечне привязок.
Прикладной уровень и протокол SMB
Перенаправители (redirector) клиентов и серверы Windows используют протокол SMB для связи друг с другом. Существует несколько “диалектов” протокола SMB, которые соответствуют различным этапам развития протокола. Одно из первых действий в транзакции SMB заключается в определении общего диалекта. Операционная система Windows Server 2003 использует диалект NT LM 0.12.
Несколько лет назад компания Microsoft изменила название протокола SMB на Common Internet File System (CIFS — обгцая файловая система Интернет). Новое имя имело только маркетинговый смысл. Диалект CIFS/SMB, используемый в Windows Server 2003, использовался и во всех версиях Windows NT, начиная с Windows NT 3.51.
При отсутствии службы преобразования имен, например WINS или DNS, приложения SMB для поиска других компьютеров используют широковещательные запросы. Этот механизм работает, как радио в диапазоне СВ. Если служба Workstation на одном компьютере желает связаться со службой Server на другом компьютере, служба Workstation отправляет широковещательный пакет, содержимое которого можно представить следующим образом: “Это служба Workstation на компьютере PRO1, ищу службу Server на компьютере SVR13. Ответь, SVR13 Server”. После получения запроса службой Server на компьютере SVR13, она отвечает: “Это служба SVR13 Server. Прием”. Две службы “договариваются” об используемом диалекте, назначают сеансу уникальный идентификатор и устанавливают соединение.
Если входящий в домен компьютер под управлением Windows устанавливает сеанс связи SMB с контроллером домена, дополнительно устанавливается безопасное подключение Remote Procedure Call (RPC). В сеансе RPC тоже используется протокол SMB, но предоставляется возможность шифрования передаваемых данных. Шифруется даже информация, передаваемая в процессе аутентификации.
Пароль компьютера сохраняется в локальной базе данных Security Account Manager (SAM) и в базе данных службы Active Directory. Если член домена не в состоянии преобразовать имя контроллера домена в IP-адрес, то безопасный канал RPC не будет установлен и пользователи не смогут зарегистрироваться в домене.
Транспортный уровень
Протокол SMB ориентирован на установление соединений. До обмена сообщениями приложения SMB на разных компьютерах должны установить соединение друг с другом. Именно поэтому данные протокола SMB всегда передаются средствами протокола TCP.
SMB и системная интеграция
Протокол SMB является общим для различных сетевых операционных систем, не только для операционной системы Windows Server 2003. Этот протокол используется во всех версиях операционной системы Windows, начиная с Windows for Workgroups и заканчивая Windows 9х и Windows NT. Протокол SMB используется в операционной системе OS/2 Warp, поскольку операционные системы Warp и Windows NT являются потомками одной операционной системы OS/2 UXN Manager. Протокол SMB также используется в Samba, клоне SMB для операционных систем Unix. Существуют реализации Samba для операционных систем NetWare и VMS.
Различные приложения SMB могут взаимодействовать друг с другом, хотя не всегда удается добиться полной поддержки всех функциональных возможностей. Такое взаимодействие бу-
дет напоминать разговор итальянского туриста и португальского продавца. Общие идеи донести легко, но как только дело касается деталей, возникают сложности перевода. Чаще всего для приложений SMB при их запуске на платформах, отличных от платформы Windows, возникают проблемы аутентификации.
Стандартным портом для протокола SMB является ТСР-порт 139. Этот порт используется вспомогательным модулем NetBIOS-over-TCP, Netbt. sys, который по сути создает 8МВ-“тоннель” поверх протокола TCP. Операционные системы Windows Server 2003 и Windows 2000 могут передавать команды SMB непосредственно с помощью протокола TCP. Такая “непосредственная передача’’ команд SMB осуществляется через ТСР-порт 445. При этом ТСР-порт 139 используется для обмена командами SMB с клиентами более ранних версий. Дополнительная информация о преимуществах непосредственной передачи команд SMB приводится в разделе “Отключение службы преобразования имен NetBIOS-over-TCP/IP” в конце этой главы.
Компьютеры под управлением операционной системы Windows способны обмениваться данными без создания сеанса. В качестве примера можно назвать транзакции преобразования имен/регистрации, а также широковещательные запросы NetBIOS. Поскольку для таких запросов не требуется установка сеанса и размер сообщений обычно очень мал, для их передачи используется протокол UDP. Для преобразования имен/регистрации NetBIOS в операционной системе Windows используется UDP-порт 137. Для широковещательных запросов и однонаправленной передачи данных используется UDP-порт 138. Например, при использовании команды net send для вывода сообщений на консоль пользователя данные передаются через UDP-порт 138.
Службы, основанные на протоколе TCP, ожидают запросов на соединение к определенному TCP-порту. Для получения списка открытых TCP-портов на сервере можно воспользоваться утилитой netstat. Обычно для этой цели используется команда netstat -а. Если номер порта определен в файле Services из каталога С: \Windows\System32\drivers\etc, вместо номера порта выдается зарегистрированное имя. Полный список стандартных номеров портов и соответствующих им служб доступен на сайте www. iana. org.
В операционной системе Windows Server 2003 утилита netstat приобрела новую возможность — показывать процесс, связанный с каждым открытым портом. Это позволяет обнаружить вредоносные процессы и значительно упрощает процедуру диагностики. Рассмотрим пример использования этой возможности.
C:\>netstat -ао
Active Connections
Proto
Local Address
Foreign Address
State
PID
TCP
LAPTOP:http
LAPTOP.company.com:0
LISTENING
1420
TCP
LAPTOP:epmap
LAPTOP.company.com:0
LISTENING
976
TCP
LAPTOP:https
LAPTOP.company.com:0
LISTENING
1420
TCP
LAPTOP:microsoft-ds
LAPTOP.company.com:0
LISTENING
4
Соответствие между идентификаторами процессов (PID) и названиями служб предоставляется в Task Manager (Диспетчер задач) или выдается новой утилитой tasklist. Ниже приведен пример использования утилиты tasklist с параметром /svc, позволяющим получить список служб для каждого процесса.
svchost.ехе svchost.ехеsvchost.ехе svchost.ехе976 RpcSs
svchost.ехе svchost.ехе
svchost.ехе svchost.ехе
1000 AudioSrv, Browser, CryptSvc, Dhcp, dmserver, ERSvc, Eventsystem, helpsvc, lanmanserver, lanmanworkstation, Messenger, Netman, Nia, RasMan, Schedule, seclogon, SENS, ShellHWDetection, srservice, TapiSrv, TermService, Themes, TrkWks, uploadmgr, W32Time, winmgmt, WmdmPmSp, wuauserv, WZCSVC
svchost.exe svchost.exe spoolsv.exe inetinfo.exesvchost.exe svchost.exe spoolsv.exe inetinfo.exe1164 Dnscache
svchost.exe svchost.exe spoolsv.exe inetinfo.exe
svchost.exe svchost.exe spoolsv.exe inetinfo.exe
1188 LmHosts, RemoteRegistry, SSDPSRV, WebClient
1280 Spooler
1420 IISADMIN, W3SVC
Еще одной великолепной утилитой для диагностики использования портов TCP является утилита FPORt от компании Foundstone (www. foundstone.com). Ниже приведен пример результата ее работы.
D: \>fport
FPort v2 . О - TCP/IP Process to Port Mapper
Copyright 2000 by Foundstone, Inc.
http://www.foundstone.com
Pid Process Port Proto Path
1420 inetinfo -> 80 TCP
C: \WINDOWS\System32\inetsrv\inetinfo.exe
976svchost->135TCPC:\WINDOWS\system32\svchost.exe
4System->139TCP
1420inetinfo->443TCP
C:\WINDOWS\System32\inetsrv\inetinfo.exe
4System->445TCP
1000svchost->1025TCPC:\WINDOWS\System32\svchost.exe
1420inetinfo->1027TCP
C:\WINDOWS\System32\inetsrv\inetinfo.exe
Сетевой уровень
Протокол IP принимает дейтаграммы UDP и TCP и упаковывает их для передачи драйверу NDIS, который расположен на уровне МАС. Кроме этого, протокол IP передает так называемый “низкоуровневый” (raw) IP-трафик для приложений, которые работают в обход протоколов TCP и UDP.
Драйвер tcpip. sys отвечает за определение IP-адреса получателя. Этот адрес определяется по имени NetBIOS в сообщении SMB. Драйвер tcpip. sys может воспользоваться внутренним распознавателем DNS, а может воспользоваться вспомогательным модулем NetBIOS-over-TCP/IP, netbt.sys, который обеспечивает преобразование имен NetBIOS. Драйвер tcpip. sys предоставляет следующие механизмы преобразования имен.
Lmhosts. В этом файле перечислены имена NetBIOS и соответствующие им IP-адреса.
Hosts. В этом файле перечислены имена хостов DNS и соответствующие им IP-адреса.
Широковещательные запросы. Для этого метода используются дейтаграммы UDP, которые отправляются как многоадресные IP-пакеты и которые содержат запрос на получение ответа от станции, имя которой указано в качестве адреса получателя дейтаграммы. В ответе на такую дейтаграмму должен содержаться IP-адрес хоста получателя.
WINS. Это центральная база данных, в которой содержатся имена NetBIOS, идентификаторы служб и IP-адреса.
Блокирование трафика SMB на брандмауэре
Если необходимо ограничить использование протокола SMB только локальной сетью, настройте брандмауэр или фильтр TCP/IP на блокирование ТСР-порта 139 и UDP-портов 138 и 137. Для блокирования протокола SMB в операционных системах Windows Server 2003, Windows ХР и Windows 2000 на брандмауэре дополнительно необходимо заблокировать ТСР-порт 445.
Кэш имен NetBIOS. Во время преобразования имени NetBIOS результат преобразования кэшируется для ускорения последующих ответов.
DNS. Это центральная база данных иерархических имен узлов и соответствующих им IP-адресов.
Кэш распознавателя DNS. Во время преобразования имени DNS результат кэшируется для ускорения последующих ответов.
Простым способом запоминания порядка преобразования имен в протоколе TCP/IP является фраза “Can We Buy Large Hard Drives?”. Первые буквы слов обозначают такой порядок: кэш, WINS, широковещательный запрос (broadcast), файл Lmhost s, файл hosts, служба DNS.
Уровень управления доступом к среде
К тому моменту, когда сообщение SMB поступает в сетевой адаптер, оно уже практически полностью обработано. Недостает только одного компонента. Драйвер NDIS и уровень МАС ничего не знают об именах NetBIOS, портах TCP/UDP или IP-адресах. Здесь, на нижнем уровне стека протоколов модели OSI, значение имеет только одна информация — МАС-адрес, соответствующий физическому устройству. Драйвер tcpip. sys должен предоставить драйверу NDIS МАС-адрес, чтобы драйвер NDIS мог сформировать кадр передачи. Для поиска МАС-адреса драйвер tcpip. sys использует протокол Address Resolution Protocol (ARP).
Работа протокола ARP заключается в отправке широковещательного пакета с запросом IP-адреса узла получателя и ожидании ответа. Все сетевые интерфейсы в локальной подсети принимают этот широковещательный запрос, но отвечает только узел с указанным IP-адресом. , В ответе содержится МАС-адрес интересующего физического устройства.
Драйвер tcpip. sys извлекает МАС-адрес из ответа ARP и предоставляет его драйверу NDIS. Драйвер NDIS использует МАС-адрес для создания заголовка кадра передачи. Драйвер tcpip. sys кэширует комбинацию IP/М АС-адресов, что позволяет на определенный промежуток времени не запрашивать МАС-адрес для этого IP-адреса. Запись удаляется из кэща через 10 минут по окончании последнего использования или через 2 минуты, если запись не использовалась.
Широковещательные запросы ARP поддерживаются даже в маршрутизируемых сетях. Маршрутизаторы IP программируются таким образом, чтобы отвечать на запросы ARP для IP-адресов собственной подсети. В ответе маршрутизатора предоставляется МАС-адрес интерфейса маршрутизатора, используемого для обслуживания подсети, в которой работает компьютер с запрошенным IP-адресом. При этом хост-отправитель считает, что общается с узлом-получателем. После этого маршрутизатор перенаправляет пакет и отправляет его в сеть назначения (если она присутствует в таблице маршрутизации) или в собственный шлюз для последующей обработки.
Протокол Internet Control Management Protocol (ICMP)
Драйвер tcpip. sys реализует еще один протокол — Internet Control Management Protocol (ICMP).
Самыми известными приложениями протокола ICMP являются утилиты ping и tracert. При использовании утилиты ping хосту-получателю отправляется пакет запроса ICMP Echo Request, а узел-получатель отвечает пакетом ответа ICMP Echo Reply.
Кроме этого, протокол ICMP используется для обмена информацией о проблемах сетевого взаимодействия между устройствами на физическом уровне. Например, если размер 1Р-пакета превышает значение параметра Maximum Transmission Unit (MTU— максимальная единица передачи) интерфейса маршрутизатора, то маршрутизатор откажется принимать пакет и ответит ICMP-сообщением с указанием предельного значения параметра MTU.
МАС-адрес, полученный с помощью протокола ARP, можно просмотреть несколькими способами. Одним из способов является отправка на узел тестового эхо-пакета с последующим просмотром содержимого кэша ARP с помощью команды агр -с. Но лучше воспользоваться появившейся в операционной системе Windows Server 2003 утилитой getmac. Рассмотрим пример использования этой утилиты.
D:\>getmac /s 192.168.0.1
Physical Address Transport Name
00-02-3A-2A-3C-DC \Device\Tcpip_(CDB02354-574F-4FEE-8CFF- AFBCE6CC1511}
Для просмотра МАС-адресов сетевых адаптеров своего компьютера можно воспользоваться командой ipconfig /all. Кроме МАС-адресов, выводится дополнительная информация об интерфейсах. Ниже приведен пример использования этой команды.
C:\>Ipconfig /all
Windows Server 2003 IP Configuration
Host Name:PRO1
Primary DNS Suffix :Company.com
Node Type:Hybrid
IP Routing Enabled:No
WINS Proxy Enabled:No
Ethernet adapter Local Area Connection 2:
Connection-specific DNS Suffix . : Company.com Description :NETGEAR FA310TX
Fast Ethernet Adapter (NGRPCI)
Physical Address:OO-AO-CC-AA-AA-AA
DHCP Enabled:No
IP Address:10.1.200.1
Subnet Mask :255.255.0.0
Default Gateway :10.1.1.254
DNS Servers:10.1.1.1
Утилиты сетевой диагностики
Перед подробным описанием преобразования сетевых имен стоит обратить внимание на'не- сколько утилит сетевой диагностики, доступных в операционной системе Windows Server 2003 и в Resource Kit (эти утилиты доступны и в операционной системе Windows 2000). С помощью этих утилит можно просматривать и изменять содержимое различных кэшей преобразования имен. Это утилиты ipconfig, netstat, tracert, pathping, nbtstat nnetdiag.
Утилита ipconfig
Для настройки параметров IP сетевого интерфейса можно использовать окно Network and Dial-up Connections (Сеть и подключения к Интернету). В командной строке эту же информацию можно получить с помощью утилиты ipconfig. Для вывода подробного отчета о каждом доступном интерфейсе воспользуйтесь командой ipconfig /all.
Рассмотрим пример использования этой утилиты.
Ethernet adapter :
Host Name: : PR01.company.com
Description : NETGEAR FA310TX
'Ъ Fast Ethernet Adapter (NGRPCI). Physical Address: 08-00-09-AA-AA-AA
DHCP Enabled:Yes
IP Address:10.1.60.1
Subnet Mask :255.255.0.0
Default Gateway :10.1.254.254
Primary WINS Server :10.1.100.254
Secondary WINS Server :10.1.100.253
Lease Obtained:Saturday, December 16, 2001
3:35:06 AM Lease Expires: Sunday, December 24, 2001
3:35:06 AM
Для утилиты ipconfig доступны следующие параметры командной строки.
ipconfig /release. Если адаптер настроен на использование протокола DHCP, этот параметр заставляет интерфейс освободить предоставленные адреса. Этот параметр можно использовать, чтобы забрать у клиента адрес, который должен быть предоставлен другому клиенту.
ipconfig /renew. Если адаптер настроен на использование протокола DHCP, то с помощью этого параметра DHCP-серверу отправляется запрос на повторное распределение адресов. В большинстве случаев клиент получит тот же адрес, который был назначен ранее. Этот параметр можно использовать для загрузки нового пакета настроек DHCP.
ipconfig /displaydns. С помощью этого параметра можно отобразить записи локального кэша DNS.
ipconfig /flushdns. С помощью этого параметра осуществляется очистка локального кэша DNS.
ipconfig /registerdns. Этот параметр позволяет зарегистрировать клиент в службе Dynamic DNS.
ipconfig /showclassid. С помощью этого параметра выводится перечень доступных для сетевого интерфейса идентификаторов класса DHCP.
ipconfig /setclassid. Этот параметр позволяет изменить идентификатор класса DHCP.
Утилита net stat
Воспользовавшись этой утилитой, можно получить данные о доступных на компьютере сетевых интерфейсах TCP/IP. Рассмотрим параметры этой утилиты.
netstat -а. Выводит информацию о текущих сеансах TCP и UDP, установленных через сетевой интерфейс. Этот параметр можно использовать для быстрого обнаружения атак или других сетевых программ, которые создают большое количество TCP-сеансов и открывают большое количество портов, ожидающих запросов на соединение.
TCP
DCOl:3269
DC01.subsidiary.com:0
LISTENING
TCP
DCOl:6548
DC01.subsidiary.com:0
LISTENING
TCP
DC01:nbsession
DC01.subsidiary.com:0
LISTENING
TCP
DCOl:389
DC01.subsidiary.com:1065
ESTABLISHED
TCP
DCOl:389
DC01.subsidiary.com:1095
ESTABLISHED
TCP
DCOl:389
DC01.subsidiary.com:1103
ESTABLISHED
Графическая утилита для настройки протокола IP
Некоторые пользователи предпочитают графический интерфейс для настройки параметров протокола IP. Такой интерфейс использовался в утилите winipcfg в операционных системах Windows 9х. Такой же интерфейс доступен в операционной системе Windows Server 2003, ес-
ли щелкнуть правой кнопкой мыши на пиктограмме подключения и выбрать команду Status (Состояние) из контекстного меню. После этого откроется окно Status (Состояние) с информацией о данном подключении. Откройте вкладку Support (Поддержка), на которой содержится информация о конфигурации протокола IP. Пример такого окна показан на рис. 4.4. С помощью этого окна можно освобождать и повторно получать IP-адреса у сервера DHCP.
Рис. 4.4. Окно состояния локальных подключений, в котором предоставляется информация о настройках протокола IP
Если в панели задач не выводится пиктограмма подключения, в окне свойств подключения установите флажок Show Icon In Taskbar Notification Area When Connected (При подключении вывести значок в области уведомлений).
netstat -е. Предоставляет статистику обмена информацией по сети Ethernet, включая сведения о блокированных пакетах.
Received 870327 6729 23450 0 0Received 870327 6729 23450 0 0Sent 956984710074725 0'2Sent 956984710074725 0'2Interface Statistics
Received 870327 6729 2345
0 0 0
Received 870327 6729 2345
0 0 0
Sent 9569847
10074
725 0'
2
Sent 9569847
10074
725 0'
2
Bytes
Unicast packets
Non-unicast packets
Discards
Errors
Unknown protocols
netstat -n. Позволяет отобразить локальные адреса и номера портов различных сеансов и служб, ожидающих установки соединения.
Active Connections
Proto
Local Address
Foreign Address
State
TCP
10.1.100.1:445
10.1.1.1:1160
ESTABLISHED
TCP
10.1.100.1:445
10.2.1.1:1313
ESTABLISHED
TCP
10.1.100.1:445
10.3.1.2:1047
ESTABLISHED
TCP
10.1.100.1:2261
10.1.1.254:3389
ESTABLISHED
■ netstat -р [tcp] [udp] [ip]. To же, что и-n, но выводит имена хостов. В списке перечисляются все сеансы для выбранного протокола. Ниже приведен результат выполнения команды netstat -р tcp (aamicbmicrosof t-ds соответствует TCP-порту 445).
Proto
Local Address
Foreign Address
State
TCP
srvl:microsoft-ds
DC01:1160
ESTABLISHED
TCP
srvl:microsoft-ds
DC02 : 1313
ESTABLISHED
TCP
srvl:microsoft-ds
DC03:1047
ESTABLISHED
TCP
srvl:2261
NT401:3389
ESTABLISHED
netstat -г. Позволяет отобразить содержимое локальной таблицы маршрутизации. Кроме этого, в отчете указываются открытые порты.
Interface List
0x1 Internal loopback interface for 127.0.0.0 network
0x2 Internal RAS Server interface for dial in clients
0x3 ...08 00 09 aa aa aa NETGEARFA310TX Adapter (NGRPCI)
Active Routes:
Network Destination
Netmask
Gateway
Interface
Metr
ic
10.1.0.0
255.255.0.0
10.1.30.1
10.1.30.1
1
10.1.30.1
255.255.255.255
127.0.0.1
127.0.0.1
1
10.255.255.255
255.255.255.255
10.1.30.1
10.1.30.1
1
127.0.0.0
255.0.0.0
127.0.0.1
127.0.0.1
1
127.0.0.1
255.255.255.255
127.0.0.1
127.0.0.1
1
224.0.0.0
224.0.0.0
10.1.30.1
10.1.30.1
1
255.255.255.255
255.255.255.255
10.1.30.1
10.1.30.1
1
netstat -s. С помощью этого параметра можно просмотреть статистические сведения для каждого протокола. Для выбора конкретного протокола воспользуйтесь параметром -р.
TCP Statistics
Active Opens
= 1103
Passive Opens
= 1204
Failed Connection Attempts
= 1
Reset Connections
= 34
Current Connections
= 22
Segments Received
= 23942
Segments Sent
= 27209
Segments Retransmitted
= 134
Утилита tracert
Эта утилита подобна UNIX-утилите traceroute. С ее помощью можно узнать IP-адрес и имя каждого интерфейса, который расположен между клиентом и указанным сервером. Если доставка тестового эхо-пакета завершается неудачей, то утилита tracert позволяет определить точку, в которой прекращается передача пакета.
Утилита tracert отправляет последовательность ICMP-запрсов Echo на хост получателя подобно утилите ping. Но, в отличие от утилиты ping, утилита tracert изменяет значение параметра TTL (Time-to-Live — время жизни) отправляемых пакетов. Это позволяет получить ответ от каждого промежуточного маршрутизатора.
Утилита tracert отправляет первый ICMP-запрос, в котором для параметра TTL установлено значение 1. Первый маршрутизатор сообщает о получении пакета, а второй маршрутизатор отвечает сообщением об ошибке TTL Exceeded in Transit (Время жизни истекло). В следующем ICMP-пакете для параметра TTL уже устанавливается значение 2, затем —Зи т.д., пока не будет достигнут интересующий узел. Каждый запрос повторяется три раза и отчет утилиты содержит последовательность имен хостов и IP-адресов. По умолчанию для определения имени узла утилита tracert использует запрос DNS-адреса и его преобразование в IP-адрес. Ниже приведен пример использования утилиты tracert.
C:\Documents and Settings\Admin>tracert www.google.com Tracing route to www.google.com [216.239.35.100] over a maximum of 30 hops:
11ms1ms<1ms192.168.0.254
213ms12ms12ms12.48.12.1
316ms58ms77ms12.0.121.81
421 ms 29 ms
15 ms
cl-pos4-l.phnxazl.home.net
[24.7.76.173]
521 ms 19 ms
19 ms
cl-pos2-0.sndgcal.home.net
[24.7.65.134]
625 ms 57ms
23 ms
cl-posl-0.anhmcal.home.net
[24.7.64.69]
723 ms 26 ms
25 ms
cl-posl-0.Isancal.home.net
[24.7.65.169]
830 ms 26 ms
2 5 ms
cl-pos2-0.snbbcal.home.net
[24.7.65.174]
931 ms 29 ms
30 ms
c2-pos3-0.snjscal.home.net
[24.7.64.49]
1030 ms 32 ms
32 ms
above-athome.sj c2 .above.net
[208.185.175.133]
1132 ms 36 ms
31 ms
core4-core3-oc48.sjc2.above
.net.
^ [208.184.102.198]
1232 ms 64 ms
32 ms
core2-sjc2-oc48. s jc3.above.
net
[208.184.233.50]
1331 ms 31 ms
63 ms
mainlcolo56-core2-oc48. s jc3
.above.net
[208.185.175.198]
1431 ms 31 ms
32 ms
sjnil-gige-2-1.google.com
^ [216.239.47.18]
1538 ms 75 ms
40 ms
192.168.254.86
1638 ms 30 ms
40 ms
www.google.com [216.239.35.
100]
Trace complete.
Рассмотрим доступные параметры утилиты tracert.
tracert -d. Отключает преобразование имен узлов. Это значительно ускоряет отслеживание маршрута (рекомендуется).
tracert -h. Увеличивает максимальное количество промежуточных маршрутизаторов. По умолчанию этот параметр имеет значение 30.
tracert - j <перечень хостов>. Этот параметр используется для принудительного использования конкретных промежуточных маршрутизаторов.
tracert -w. Параметр позволяет увеличить время максимальной задержки ответного пакета.
Утилита pathping
Утилита tracert может достаточно долго создавать список промежуточных узлов, поскольку она должна получить ICMP-пакет Echo Response от хоста-получателя. С помощью утилиты pathping можно быстрее исследовать маршрут передачи сообщения. Эта утилита отправляет набор ICMP-запросов Echo Request с последовательно увеличивающимся значением параметра TTL так же, как это делает утилита tracert, но адреса промежуточных узлов выводятся немедленно, вплоть до ответа от хоста-получателя, после чего выполняется подсчет статистики. Подсчет статистики занимает длительное время, поэтому иногда его стоит прервать с помощью комбинации клавиш <Ctrl+C>.
Утилита nbtstat
После преобразования имени NetBIOS клиент TCP/IP под управлением операционной системы Windows кэширует результат в таблице NetBIOS Name Cache. По умолчанию запись остается в кэше в течение 600 секунд (10 минут). Для просмотра и редактирования таблицы NetBIOS Name Cache можно использовать утилиту nbtstat. Рассмотрим доступные параметры утилиты nbt s t a t и их назначение.
nbtstat -с. Этот параметр позволяет отобразить содержимое локального кэша имен. Воспользуйтесь этим параметром для проверки правильности IP-адреса, занесенного в кэш.
В следующем отчете приведен пример содержимого кэша имен. В столбце Туре содержится двухбайтовый шестнадцатеричный идентификатор службы NetBIOS. Первые три записи
были предварительно загружены из локального файла Lmhosts, что означает хранение этих записей в течение 60 секунд, а не 600 секунд, как принято по умолчанию.
Life [sec]Life [sec]Node IpAddress: [10.1.1.10] Scope Id: [] NetBIOS Remote Cache Name Table
Life [sec]
Life [sec]
DC02
<03>
UNIQUE
10.1.1.20
60
DC02
<00>
UNIQUE
10.1.1.20
60
DC02
<20>
UNIQUE
10.1.1.20
60
NTS 01
<00>
UNIQUE
10.1.1.101
600
Name
Type
Host Address
nbtstat -а. Выводит содержимое кэша имен на удаленном компьютере, который указывается с помощью имени NetBIOS. Кроме этого, с помощью данного параметра отображается МАС-адрес удаленного сетевого адаптера. Пример синтаксиса этой команды: nbtstat -a dcOl.
nbtstat -А. С помощью этого параметра утилита nbtstat выводит содержимое кэша на удаленном компьютере, который указывается с помощью IP-адреса. Кроме этого, отображается МАС-адрес удаленного сетевого адаптера. Пример синтаксиса этой команды: nbtstat -А 10.1.1.1.
nbtstat -п. Параметр позволяет просмотреть имена NetBIOS, используемые для локального компьютера. При этом отображаются все имя компьютера с запущенными службами, имена локально вошедших в систему пользователей с запущенными ими службами, рабочая группа или домен компьютера и все запущенные службы браузеров.
Node IpAddress: [10.1.10.3] Scope Id: []
NetBIOS Local Name Table
Name
Type
Status
PRO1
<00>
UNIQUE
Registered
PRO1
<03>
UNIQUE
Registered
PRO1
<20>
UNIQUE
Registered
COMPANY
<00>
GROUP
Registered
COMPANY
<1E>
GROUP
Registered
. .MSBROWSE.
<01>
GROUP
Registered
nbtstat -г. Параметр предоставляет список имен из кэша и отображает сведения о том, как выполнялось преобразование имени. Эта возможность оказывается полезной для определения типа преобразования при получении IP-адреса.
NetBIOS Names Resolution and Registration Statistics
Resolved By Broadcast=2
Resolved By Name Server=5
Registered By Broadcast=32
Registered By Name Server=8
NetBIOS Names Resolved By Broadcast
00>00><00><00>DC01
00>
00>
<00>
<00>
DC01
nbtstat -R. Параметр позволяет очистить кэш и выполняет предварительную загрузку (#PRE) из файла Lmhosts. Дополнительная информация предоставляется в разделе “Преобразование имен NetBIOS с помощью файла Lmhosts” далее в этой главе.
nbtstat -S. Предоставляет сведения о текущих сеансах на локальном компьютере, показывая IP-адреса компьютеров, с которыми установлено соединение. Этот параметр очень удобен для составления списка служб, имеющих активные соединения.
NetBIOS Connection Table
Local Name State In/Out Remote Host Input Output
PRO1 <03> Listening
PRO1 Connected In 10.1.100.3 2KB 3KB
ADMINISTRATOR <03> Listening
nbtstat -s. To же, что и -s, но вместо IP-адресов выводятся имена компьютеров, с которыми установлено соединение.
NetBIOS Connection Table
Local Name State In/Out Remote Host Input Output
PRO1 <03> Listening
PRO1 Connected In SRV1 2KB 3KB
ADMINISTRATOR <03> Listening
nbtstat -RR. Отменяет регистрацию имени в службе WINS и регистрирует имя повторно. Параметр впервые появился в операционной системе Windows NT 4.0 SP4. Этот параметр оказывается исключительно полезным для исправления ошибок службы WINS. Из службы WINS имя можно удалить вручную, а затем клиент может повторно зарегистрировать имя с помощью этого параметра.
Если в результате исследования локального компьютера с помощью рассмотренных утилит окажется, что в локальной сети только этот компьютер работает неправильно, откройте окно Network Connections (Сетевые подключения) и обратите внимание на значок состояния подключения. Если поверх пиктограммы выводится большой символ “X”, значит, соединение с сетью разорвано. Просмотрите журнал событий и найдите сообщение, в котором описана причина отключения от сети.
Совет по работе с реестром: расположение разделов управления кэшем NetBIOS
Параметр реестра, в котором хранятся конфигурационные параметры NetBIOS (время хранения записи в кэше, количество широковещательных запросов и т.д.), расположен в разделе HKLM\System\CurrentControlSet\Services\NETBT системного реестра.
Утилита netdiag
Эта утилита позволяет полноценно протестировать практически все сетевые функции. Отчет утилиты слишком велик, чтобы читать его с консоли и приводить здесь. Перенаправьте вывод утилиты в файл для последующей обработки.
Если проблема в работе сети отличается от простых ошибок подключения, утилита netdiag должна первой использоваться для диагностики. Утилита указывает непосредственно на источник проблемы или предоставляет достаточный объем информации для дальнейшей диагностики. На полный анализ отчета может потребоваться значительное время, но зато в нем практически наверняка можно найти источник проблемы.
Утилита netsh
Утилита Network Shell является основной утилитой командной строки для управления сетевыми интерфейсами и базовыми службами TCP/IP, кроме службы DNS. Появившийся в операционной системе Windows Server 2003 параметр Di ад позволяет получить информацию о состоянии сетевых интерфейсов. Для полного тестирования сетевых интерфейсов воспользуйтесь командой netsh>diag now test.
Преобразование имен NetBIOS с помощью широковещательных запросов
Метод использования широковещательных запросов является первым в истории сетей методом для преобразования имен хостов в IP-адреса. Преобразование имен с помощью широковещательных запросов напоминает помощь соседа в небольшом городе. В таком городе можно высунуть голову из окна и крикнуть: “Джон Генри, когда будет минутка, заходи в гости!”. Для того чтобы такая схема преобразования имен работала, в городе должен быть только один Джон Генри. Если сервер Windows запрашивает адрес компьютера SRV1, то в сети должен находиться только один компьютер с таким именем. Именно поэтому компьютеры под управлением операционной системы Windows используют широковещательные запросы для регистрации собственных имен. Такой метод регистрации обеспечивает уникальность имен. Механизм широковещательной регистрации рассматривается в процедуре 4.1.
Процедура 4.1. Процесс преобразования имен NetBIOS с помощью широковещательных запросов
При загрузке операционной системы компьютера PRO1 прежде всего выполняется проверка, что в сети нет компьютера с таким же именем. Для этой цели служит широковещательный запрос NetBIOS Name Registration. Широковещательный запрос прикладного уровня на сетевом уровне преобразуется в многоадресный IP-пакет, который отправляется в подсеть клиента.
Например, клиент, IP-адрес которого —10.1.3.150, а маска подсети — 255.255.0.0, отправляет запрос на регистрацию имени по адресу 10.1.255.255. Хосты в пределах многоадресной рассылки, не входящие в подсеть 10.1.0.0, игнорируют этот запрос.
Если другой компьютер с именем PRO1 получает многоадресный пакет, он отправляет ответ “Это мое имя и вот мой 1Р-адрес”.
Новый компьютер не сразу проходит регистрацию. Сначала проверяется идентичность отправившего запрос компьютера его IP- адресу с помощью ARP-запроса. Если на запрос ARP ответ не приходит, “новичку” предоставляется выбранное имя. Если на ARP-запрос приходит ответ, то компьютер не может использовать выбранное имя и выдает пользователю сообщение о наличии компьютера с таким именем в локальной сети. Кроме этого, в журнал событий заносится соответствующее уведомление.
Если имя оказалось уникальным, протоколы уровня приложений, например, Workstation, Server и Browser устанавливают привязку со стеком TCP/IP и выполняется инициализация сетевых драйверов.
Как только сетевой адаптер оказывается подключенным к сети, перенаправитель SMB (в случае операционной системы Windows Server 2003 это LanMan Workstation) начинает подготовку для соединения с сервером, например, SRV1. Служба LanMan Workstation создает пакет SMB, предназначенный для компьютера SRV1, и передает его драйверу tcpip. sys.
После получения SMB-сообщения драйвер tcpip. sys использует драйвер netbt. sys для отправки группового пакета NetBIOS Name Resolution, предназначенного для поиска IP-адреса сервера SRV1. Драйвер netbt. sys отправляет пакет три раза через каждые полсекунды. Если после трех попыток ответ не получен, преобразование имени считается неудачным.
Если сервер SRV1 получает многоадресный пакет, он отправляет ответ с собственным IP-адресом. Ответ отправляется непосредственно клиенту, поскольку адрес клиента (имя NetBIOS, IP-адрес, МАС-адрес) известен серверу из группового запроса.
Драйвер tcpip. sys извлекает IP-адрес из ответа сервера и отправляет ARP-ответ, который подтверждает адрес. После подтверждения драйвер netbt. sys кэширует имя и IP-адрес на сервере в таблице имен NetBIOS. Кэшированное имя и адрес могут использоваться в последующих транзакциях.
Такой метод “выкрикивания" имен и ожидания ответа не очень хорошо работает в ярком свете больших городов, которыми являются маршрутизируемые сети TCP/IP. В таких сетях маршрутизаторы и коммутаторы Layer 3, а также интеллектуальные мосты настроены на блокирование широковещательных пакетов и пакетов групповой рассылки. В следующих двух разделах рассматривается использование файла Lmhosts и службы WINS для преобразования и регистрации имен в маршрутизируемых сетях.
Преобразование имен NetBIOS с помощью файла Lmhosts
В начале развития протокола NetBIOS компания Microsoft позаимствовала из операционной системы UNIX идею преобразования имен с помощью статического файла. В операционной системе UNIX для преобразования имен использовался файл hosts. Поскольку компания Microsoft в то время работала над операционной системой OS/2 Lan Manager, файл преобразования имен NetBIOS назвали Lmhosts. Ни тот, ни другой файл не имеет расширения имени.
Место хранения файлов, связанных с протоколом TCP/IP
Пример файла Lmhosts (Lmhosts . sam) расположен в каталоге \Windows\System32\ Drivers\etc. Можно создать собственный файл Lmhosts, а можно переименовать файл примера и внести в него необходимые изменения. Каталог, в котором система ищет файл Lmhosts, определяется в системном реестре в такой записи:
Раздел:HKML\System\CurrentControlSet\Services\Tcpip\Parameters
Запись: DataBasePath
В каталоге \windows\System32\Drivers\etc содержатся и другие файлы, связанные с протоколом TCP/IP.
Hosts. Используется для поиска имен хостов по стандарту TCP/IP.
Services. Файл содержит номера TCP- и UDP-портов, а также названия стандартных служб, которые запускаются на этих портах.
Protocol. Файл содержит список IP-протоколов, которые используются на компьютере в соответствии с документом RFC 1060.
Networks. Файл содержит список сетевых имен и IP-адреса соответствующих шлюзов.
Quotes. Поддерживает популярный протокол Quote of the Day. В основном, содержит цитаты из Джорджа Бернарда Шоу и Чарльза Диккенса, но администратор может добавить собственные цитаты.
Настройка файла Lmhosts
Смысл использования файла Lmhosts заключался в преобразовании имен NetBIOS средствами драйвера netbt. sys без широковещательных запросов. Файл Lmhosts является обычным текстовым файлом, в котором перечислены имена узлов и IP-адреса. Рассмотрим пример этого файла с информацией о трех серверах, два из которых являются контроллерами домена COMPANY.
# Lmhosts file for Domain COMPANY
10.1.1.10
10.1.1.20
10.1.1.30
10.1.1.100
DC01 DC02 PRO3 PRO4
#PRE
#PRE #PRE #PRE
#DOM:COMPANY
#DOM:COMPANY
#BEGIN_ALTERNATE
#INCLUDE\\PR03\PUBLIC\ETC\Lmhosts
INCLUDE\\DC02\PUBLIC\ETC\Lmhos t s
#END_ALTERNATE
Символ “диез” (#) выполняет две функции.
Используется перед стандартными параметрами файла Lmhosts (#PRE, #DOM и #INCLUDE).
Воспринимается, как начало комментария, если после символа не указан параметр.
Рассмотрим стандартные параметры для файла Lmhosts. Параметр должен быть записан в верхнем регистре. В противном случае он считается комментарием.
#PRE. Этот параметр заставляет систему загружать соответствующую запись в кэш имен NetBIOS в процессе загрузки. Это позволяет ускорить начальные преобразования имен.
#DOM. Этот параметр отмечает запись как соответствующую контроллеру домена. Имя домена указывается после двоеточия. Если файл Lmhosts используется в домене, такой параметр необходим, поскольку сообщает локальному клиенту адреса серверов аутентификации.
#INCLUDE. Этот параметр заставляет драйвер tcpip. sys загружать файл Lmhosts с другого компьютера. Параметр #INCLUDE позволяет поддерживать единственную центральную копию файла Lmhosts, которую будут использовать все рабочие станции в пределах рабочей группы. Запись имеет формат UNC, например \ \SRV1 \Public, где Public — имя ресурса. Стоит обратить внимание на ловушку, существующую в данном механизме. В имени формата UNC записано имя NetBIOS, поэтому это имя должно быть записано в локальном файле Lmhosts.
#BEGIN_ALTERNATE и #END_ALTERNATE. Эти параметры используются для разделения нескольких записей в пределах параметра # INCLUDE. Если в файле присутствует только один параметр # INCLUDE, эти параметры не нужны.
Использование файла Lmhosts
Файл Lmhosts должен использоваться только в качестве последнего средства. Такие статические записи становятся бомбами замедленного действия и преследуют администратора, как крокодил преследовал капитана Крюка. Однажды администратор забывает о созданной записи, и бах — она сработала в неподходящий момент.
Как было сказано ранее, существует несколько распространенных применений файла Lmhosts. Например, некоторые администраторы используют файл Lmhosts для преобразования имен при коммутируемых соединениях. При коммутируемом соединении можно воспользоваться преобразованием WINS, но часто такое преобразование оказывается недостаточно эффективным и требует слишком больших усилий по настройке. Короткая запись в файле Lmhosts на клиенте коммутируемого соединения позволяет сохранить информацию о контроллерах домена и серверах, постоянно используемых клиентом при установке соединений.
Вместо использования файла Lmhosts для преобразования имени в подключенном диске можно указать IP-адрес непосредственно в имени UNC. Например, вместо подключения ресурса с именем \\Srvl\Users\LLuthor и использования файла Lmhosts для преобразованиям \Srvl в 10.1.1.43 можно указать имя \ \ 10.1.1.43 \Users\LLuthor. При изменении IP-адреса сервера пользователям придется повторно подключить сетевой ресурс, но обычно это проще, чем внесение изменений в файл Lmhosts.
Преобразование имен NetBIOS средствами WINS
Древняя служба Windows Internet Name Service (WINS) является альтернативой статическому методу преобразования имен в IP-адреса с помощью файла Lmhosts. Служба WINS поддерживает базу данных имен NetBIOS и соответствующих им IP-адресов. База данных используется клиентами WINS для регистрации собственных служб NetBIOS и поиска IP-адресов служб, работающих на других клиентах WINS.
Служба WINS основана на протоколах и службах, описанных в документах RFC 1001, “Protocol Standard For A NetBIOS Service On A TCP/UDP Transport: Concepts and Methods”, и RFC 1002, “Protocol Standard For A NetBIOS Service On A TCP/UDP Transport: Detailed Specifications”. Это открытые стандарты, но служба Microsoft WINS является практически единственной коммерческой службой преобразования имен NetBIOS.
Преобразование имен для коммутируемых соединений
Служба RRAS (Routing and Remote Access Service — служба маршрутизации и удаленного доступа) в операционной системе Windows Server 2003 может быть настроена на поддержку широковещательных запросов преобразования имен для коммутируемых соединений. Это отменяет необходимость использования файла Lmhosts и специальных процедур подключения ресурсов при использовании коммутируемого соединения (как минимум в небольших сетях). Для маршрутизируемых сетей, где хост-получатель может находиться за маршрутизатором, придется использовать файл Lmhosts.
Без сомнений, служба WINS является наиболее частой причиной возникновения проблем в работе сетей Windows NT. Управление службой WINS в большой сети оказывается одной из самых сложных задач администратора операционных систем Windows NT. Однако благодаря распространению службы Dynamic DNS устраняется необходимость в использовании WINS.
В этом разделе приводится описание установки, настройки и диагностики службы WINS в операционной системе Windows Server 2003.
Обзор функциональных возможностей службы WINS
При использовании службы WINS одни клиенты обращаются к службе WINS для регистрации собственных имен NetBIOS, а другие могут запрашивать у службы WINS преобразование имен NetBIOS в IP-адреса. Сначала рассмотрим процедуру регистрации.
Ниже приведена стандартная последовательность действий при регистрации клиента на сервере WINS.
При входе в сеть клиент WINS отправляет запрос на регистрацию собственного имени своему серверу WINS. Клиент отправляет отдельный регистрационный запрос для каждой службы SMB. Например, если клиент поддерживает работу служб Server, Workstation и Messenger, серверу WINS будет отправлено три регистрационных запроса.
Если на клиенте установлено несколько сетевых адаптеров (так называемый multihomed- клиент WINS), регистрационный запрос будет отправлен для каждой службы на каждом сетевом адаптере.
Если база данных WINS на сервере не содержит записей для этого имени или IP-адреса, сервер WINS выдает положительный ответ на регистрацию (positive name registration
response) и заносит в базу данных запись с интервалом обновления (renewal interval). По умолчанию интервал обновления составляет шесть дней.
Если база данных WINS на сервере содержит записи с тем же именем, но другим IP-адресом, сервер WINS предлагает клиенту подождать некоторое время (пять минут), пока сервер отправляет запрос преобразования имени (name query request) клиенту, который зарегистрировал это имя раньше. Если существующий клиент отвечает на запрос, сервер WINS возвращает отрииртельный ответ на регистрацию (negative name registration response).
Если существующий клиент не отвечает на запрос преобразования имени, сервер WINS возвращает положительный ответ и вносит изменения в запись в базе данных. Кроме этого, запись получает новый интервал обновления.
По истечении половины интервала обновления клиент отправляет серверу WINS запрос на обновление для каждой зарегистрированной службы. Сервер отвечает на запросы, и интервал обновления сбрасывается в начальное значение.
Если клиент WINS отключается от сети с помощью стандартной процедуры отключения, ■ серверу WINS отправляется сообщение об освобождение имени (name release).
Сервер отмечает связанные с клиентом записи как свободные и назначает интервал удаления (extinction interval) для освобожденных записей. В течение интервала удаления освобожденная запись не подпадает под процедуру репликации. Сервер-владелец может свободно передавать имя или адрес другому клиенту, но другим серверам это запрещено. Использование интервала упрощает повторную регистрацию, когда клиент опять подключится к сети.
Вкратце процесс регистрации имени для клиента WINS можно представить в виде следующих этапов:
запрос на регистрацию, после которого приходит ответ с подтверждением о присвоении имени клиенту;
период активного состояния, в течение которого клиент периодически возобновляет регистрацию;
запрос на освобождение, после которого следует ответ с подтверждением об освобождении имени;
период освобожденного состояния, в течение которого поддерживается быстрая повторная перерегистрация.
Ответы для заданных доменов
Иногда возникает необходимость исключения определенного домена NetBIOS. Обычно это происходит при объединении доменов или миграции с доменов Windows NT на домены Windows Server 2003. При удалении домена в базе данных WINS все равно остаются записи. Такой домен можно отфильтровать из записей, которые предоставляются сервером WINS. Сервер возвращает отказ в регистрации вместо бесполезной записи о домене.
Обработка ошибок при регистрации имен
Процесс регистрации имен на сервере WINS предоставляет несколько возможностей по обработке распространенных ошибок.
Ошибка при перерегистрации. Если клиент освобождает зарегистрированное имя и не запрашивает перерегистрацию, сервер ожидает окончания интервала удаления и при этом устанавливает для этой записи состояние “заморожена” (tombstoned). Такие записи копируются на другие серверы WINS, которым сообщается, что указанное имя и IP-адрес можно предоставлять для других клиентов. “Замороженной” записи назначается интервал
удаления, который составляет шесть дней. По истечении интервала удаления запись удаляется из базы данных в процессе сборки “мусора”.
Ошибка при возобновлении. Если клиент не возобновляет регистрацию за период срока возобновления (интервал удаления), запись помечается как освобожденная (released).
Ошибка при освобождении. Если клиент не освобождает регистрационную запись во время срока возобновления, запись освобождается автоматически. Сервер назначает записи интервал удаления, после которого запись помечается как “замороженная"
Невозможно установить соединение с основным сервером WINS. Если основной сервер WINS недоступен во время попытки возобновления, клиент может попытаться возобновить запись на вторичном сервере, если такой сервер был настроен. Это может привести к ситуации, когда на основном сервере присутствует активная запись, а на вторичном сервере присутствует освобожденная запись. Для предотвращения таких ситуаций при освобождении регистрационной записи на сервере WINS, который не является владельцем этой записи, для записи сразу же устанавливается состояние “замороженная”.
Выход клиентского компьютера из строя. Сервер WINS не оснащен механизмом определения работоспособности клиентов, пока не завершен срок возобновления. Даже при аварийном отключении клиента от сети запись клиента остается активной и сервер продолжает выдавать IP-адрес клиента в ответ за запросы преобразования имени. Если клиент получает адрес клиента, компьютер которого вышел из строя, то попытка соединения завершится неудачей. Результат неудачного подключения сообщается серверу WINS, который определяет состояние клиента с помощью запроса на преобразование имени. Если сервер WINS не получает ответа клиента, запись освобождается по истечении интервала удаления.
В небольших сетях с одним сервером WINS такой простой процедуры достаточно для поддержки целостности базы данных, обеспечения уникальности имен и предоставления быстрых ответов на запросы преобразования имен. В больших сетях с несколькими серверами WINS, настроенными на репликацию базы данных, ситуация значительно усложняется. Дополнительную информацию по этой теме можно прочесть в разделе “Репликация WINS” далее в этой главе. Сначала рассмотрим процедуру преобразования имен.
Преобразование имен с помощью службы WINS
Если клиенту WINS необходимо преобразовать имя NetBIOS, связанное со службой, драйвер netbt. sys отправляет запрос преобразования имени (name lookup query) серверу WINS. Если имя содержит точку или имеет больше 16символов, драйвер tcpip.sys рассматривает его как имя узла DNS и использует механизм преобразования имен DNS, а не распознаватель netbt."
После получения запроса на преобразование имени сервер WINS находит запись в базе данных Jet, которая содержит регистрационные данные. Если запись существует и отмечена как активная (active), сервер WINS возвращает ответ преобразования имени (name lookup response), содержащий IP-адрес для указанного компьютера.
Если клиент настроен на использование двух серверов WINS, основного и дополнительного, клиент отправит запрос дополнительному серверу, если основной окажется недоступным.
Варианты преобразования имен
Клиент под управлением операционной системы Windows может быть настроен на регистрацию и преобразование имен NetBIOS одним из двух способов: с помощью широковещательных запросов или средствами службы WINS. Существует несколько комбинаций этих двух методов. Применяемая комбинация определяется типом узла NetBIOS. Существует четыре типа узлов.
b-node (b-тип, широковещательные запросы). Драйвер Netbt использует многоадресные IP-пакеты для регистрации и преобразования имен. Если между клиентом и сервером в сети присутствует маршрутизатор, коммутатор 3-го уровня или интеллектуальный мост, регистрация широковещательными запросами будет работать только в пределах локальной подсети. В этом случае от пользователя будут поступать жалобы наподобие “В окне Мое сетевое окружение отображаются серверы в пределах нашего здания, но серверы из здания 303 недоступны”. Если служба WINS не включена, тип b-узел используется по умолчанию.
p-node (p-тип, точка-точка). При этом методе используется исключительно служба WINS. Если клиент p-типа не может найти сервер WINS, все попытки регистрации и запросы на преобразование имен завершатся неудачно.
■ m-node (m-тип, смешанный). Этот метод позволяет обойти ошибки в работе службы WINS. В этом случае для преобразования имени в локальной подсети сначала используется широковещательный запрос. Служба WINS используется в случае отрицательного результата широковещательного запроса.
■ h-node (h-тип, гибридный). Этот метод не определен в документах RFC 1001 и RFC 1002. Компания Microsoft стала применять этот метод для сокращения количества широковещательных пакетов, создаваемых узлами типа m-node. Клиент h-типа сначала обращается к серверу WINS, после чего пытается использовать широковещательные запросы (в случае неудачного подключения к серверу WINS). При включении службы WINS этот тип используется по умолчанию.
Выбор типа узла позволяет добиться баланса между удобством, отказоустойчивостью и стабильностью работы. Тип b-node не рекомендуется использовать нигде, кроме самых маленьких сетей. Если в сети присутствует сервер под управлением операционной системы Windows, его следует настроить как сервер WINS.
Тип m-node не рекомендуется по той же причине. Зачем использовать широковещательные запросы, если в сети присутствует сервер WINS? Но иногда возникают ситуации, когда в организации используется удаленный сервер WINS, доступный через медленное подключение WAN. Если большинство используемых клиентами ресурсов находятся- в пределах локальной подсети, стоит изменить тип узла с h-node на m-node, что ускорит доступ к локальным ресурсам.
В реальных ситуациях обычно приходится выбирать между p-типом и h-типом. В этом случае приходится внимательно оценивать альтернативы. Тип h-node кажется подходящим вариантом; но на практике клиенты h-типа часто генерируют широковещательные запросы даже при доступном сервере WINS. Кроме этого, для клиентов h-типа характерны длительные задержки при завершении работы, поскольку клиент почему-то настаивает на отмене регистрации как на сервере WINS, так и средствами широковещательных запросов.
С другой стороны, клиенты p-типа не генерируют широковещательных запросов и четко отключаются от сети после отмены регистрации на сервере WINS (при этом отмена регистрации выполняется очень быстро). Основной проблемой клиентов p-типа является невозможность преобразования имен NetBIOS в случае недоступности сервера WINS.
Если в сети присутствует дополнительный сервер WINS и администратор в состоянии быстро отреагировать на отказ сервера, стоит выбирать тип p-node. Если в сети присутствует один сервер WINS и преобразование имен должно быть доступно постоянно, даже если сервер WINS окажется недоступен, выбирайте тип h-node.
Репликация WINS
Теоретически возможно с помощью одного не слишком дорогого сервера WINS (Pentium 400, ОЗУ — 64 Мбайт, сетевой адаптер —10 Мбит/с) осуществлять преобразование имен для целого предприятия. Такой сервер сможет обрабатывать тысячи регистраций в минуту, чего достаточно для сети из 30 000 компьютеров.
Не стоит упускать из виду вопросы отказоустойчивости и объема данных, передаваемых по внешним каналам. Обычно серверы WINS следует устанавливать в каждом крупном офисе или локальной сети. Если предприятие состоит из сотен небольших сетей, например точек розничной продажи, сервер WINS в каждой сети не требуется. Вместо этого серверы WINS распределяются по региональному признаку и регистрация и/или преобразование имен выполняется через внешние каналы.
На каждом сервере WINS поддерживается база данных регистрационных записей, запрашиваемых клиентами. Сервер является владельцем (owner) этих записей. Сервер WINS может реплицировать записи базы данных на другие серверы WINS, которые настроены как партнеры по репликации. Каждый сервер поддерживает единую базу данных, в которой каждая запись отмечена идентификатором владельца. При добавлении нового партнера по репликации его записи добавляются к существующим записям базы данных.
Служба WINS использует два режима репликации — принудительная и по запросу.
Принудительная. Как только объем изменений достигает определенного уровня, сервер WINS связывается с партнерами по репликации и отправляет им обновления базы данных. Принудительная репликация выполняется в ответ на событие.
По запросу. Партнеры по репликации периодически опрашивают сервер WINS относительно обновлений. Репликация по запросу выполняется по расписанию.
Зарегистрированные имена в базах данных WINS партнеров реплицируются на каждый сервер с накоплением определенного объема изменений и в определенные моменты времени. Клиенты WINS могут использовать любой из серверов или оба сервера, один из которых настроен как основной, а второй — как дополнительный.
Совет по работе с реестром: настройка типа узла Netbt
Тип узла Netbt можно задать двумя способами. Если используется сервер DHCP, установите параметр области 44 - WINS/NBNS Servers, указав один или несколько серверов WINS, и параметр 46 - WINS/NBT Node Туре, указав нужный тип узла. Дополнительная информация о настройке сервера DHCP приводится в главе 5, "Управление службой DNS".
Для клиентов, не использующих сервер DHCP, тип узла указывается в локальном системном реестре следующим образом:
Раздел: HKLM\System\CurrentControlSet\NETBT\Parameters
Запись: Type
Значение: l=b-node, 2=p-node, 4=m-node, 8=h-node
По умолчанию, если клиент не использует сервер WINS, ему присваивается тип b-node. В противном случае клиенту присваивается тип h-node.
Совет по работе с реестром: параметры базы данных WINS
База данных WINS хранится в файле wins.mdb. Это база данных Jet, похожая на базы данных Access, но в другом несовместимом формате. База данных и файлы поддержки хранятся в каталоге \Windows\System32\Wins.
Место хранения базы данных WINS и другие параметры определяются в разделе системного реестра HKLM\System\CurrentControlSet\Services\WINS. В разделе Partners указываются IP-адреса и параметры партнеров по репликации.
Для репликации служба WINS использует TCP/UDP-порт 42. Изначально этот порт предназначался для службы Home Name Server (вариант расширенного файла Hosts), но эта технология была заменена службой DNS.•
Между серверами реплицируются только обновленные записи. Это позволяет минимизировать объем передаваемых по сети'данных. Каждая запись имеет идентификатор версии, который увеличивается при каждом обновлении. При принудительной репликации сервер отправляет записи, для которых указан больший идентификатор записи, чем в последнем пакете записей, отправленных данному партнеру по репликации. При репликации по запросу партнер отправляет запрос с наибольшим идентификатором версии, полученным от этого партнера. После этого партнер высылает записи с идентификатором версии, превышающим полученный в запросе.
Если репликация выполняется по медленному или дорогому (по времени подключения) внешнему соединению, то можно настроить репликацию по запросу с относительно большим интервалом. Существуют различные комбинации принудительной репликации и репликации по запросу, но в основном такие комбинации рассматриваются на экзаменах по сертификации.
При настройке репликации между несколькими серверами WINS постарайтесь создать определенную топологию репликации. Можно создать кольцо, похожее на топологию кольца репликации Active Directory, в которой каждый сервер реплицируется с соседним сервером в кольце. Также можно создать топологию типа “звезда” (hub-and-spoke), при которой данные каждого сервера WINS реплицируются на центральный сервер, распространяющий обновления на все остальные серверы. Большинство крупных организаций используют топологию типа “звезда”, поскольку она проста в управлении и сокращает количество промежуточных серверов при репликации изменений на серверы WINS. Кроме этого, можно создать топологию, при которой серверы WINS поддерживают репликацию “каждый-с-каждым". Это позволяет добиться самого быстрого обновления информации, но такая топология наиболее подвержена ошибкам в базе данных. Независимо от выбранной топологии старайтесь избегать создания замкнутых циклов репликации.
Управление службой WINS
Перейдем к установке и настройке службы WINS. Для этого потребуется установочный компакт-диск операционной системы Windows Server 2003. Служба WINS может работать на любой версии операционной системы Windows Server 2003, включая Web Server.
Если служба WINS ранее в сети не использовалась и на компьютерах сети установлены только современные версии операционной системы Windows (Windows Server 2003, Windows XP и Windows 2000), можно полностью отказаться от службы WINS. Для преобразования имен хостов и имен NetBIOS клиенты Windows Server 2003 используют службу DNS. Правда, иногда встречаются приложения, которые зависят от преобразования имен NetBIOS, и такие приложения приходится поддерживать в маршрутизируемых сетях. Для этого необходима служба WINS. Примером такого приложения может служить Exchange 5.5, который использует имена хостов для взаимодействия между серверами Exchange.
Установка службы WINS
Если в сети уже присутствует инфраструктура WINS, существующие серверы WINS под управлением операционной системы Windows NT 4.0 можно обновить до серверов под управлением операционной системы Windows Server 2003 (или Windows 2000). При этом будет автоматически модернизирована база данных WINS с сохранением текущих параметров и настроек базы данных.
При обновлении программа установки запускает утилиту jetconv для преобразования базы данных Jet в новый формат. Такое преобразование не всегда завершается успешно. Если существующие базы данных Jet повреждены или работают нестабильно, то обновление про-
вести не удастся. При неудачной попытке обновления базы данных WINS и DCHP или обеих выполните последовательность действий, описанных в процедуре 4.2.
Процедура 4.2. Восстановление после неудачного преобразования базы данных Jet
Остановите запущенную службу.
Восстановите старую базу данных с резервной копии.
Запустите утилиту j etpack. ехе для сжатия и повторной индексации базы данных.
Запустите службу. При этом автоматически запустится преобразование базы данных.
Если выполнить преобразование опять не удается, то, вероятно, база данных повреждена. Лучше всего удалить базу данных и создать ее с нуля.
Если определенный сервер WINS одновременно является контроллером домена и модернизация службы WINS не планируется с одновременным переводом домена на Active Directory, то службу WINS стоит перенести на другой сервер.
Для установки и настройки службы WINS на сервере под управлением операционной системы Windows Server 2003 выполните последовательность действий, описанную в процедуре 4.3.
Процедура 4.3. Установка службы WINS на компьютере под управлением операционной системы Windows Server 2003
На Control Panel (Панель управления) дважды щелкните на пиктограмме Add/Remove Programs (Установка и удаление программ).
В открывшемся окне щелкните на кнопке Add/Remove Windows Components (Установка компонентов Windows). Запустится мастер компонентов Windows.
Выберите Networking Services (Сетевые службы) и щелкните на кнопке Details (Состав).
Выберите пункт Windows Internet Name Service (WINS) и щелкните на кнопке ОК для возврата в основное окно.
Щелкните на кнопке Next (Далее) для продолжения установки.
После завершения загрузки драйверов мастер выводит окно с подтверждением установки. Щелкните на кнопке Finish (Готово) для завершения работы мастера и возврата в окно Add/Remove Programs (Установка и удаление программ).
Щелкните на кнопке Close (Закрыть). Служба запускается автоматически, и перезагрузка компьютера не требуется.
Служба WINS настраивается и управляется с помощью консоли ММС, файл winsmgmt. msc. Откройте консоль с помощью команды Starts Programs^ Administrative Tools^WINS (Пускс> Программы1^Администрирование1^WINS). На этом этапе настраивать нечего, так как ни один клиент не использует сервер. Создадим несколько клиентов и затем вернемся к описанию работы консоли WINS.
Настройка клиентов WINS
Любой клиент в сети Windows может быть настроен на использование сервера WINS под управлением операционной системы Windows Server 2003. Если клиент использует службу DHCP, обязательно прочтите врезку “Совет по работе с реестром: настройка типа узла Netbt”. Если клиент использует статический адрес, соответствующие параметры настраиваются локально. Настройка клиента WINS под управлением операционной системы Windows Server 2003 рассматривается в процедуре 4.4.
Процедура 4.4. Настройка клиента WINS
Щелкните правой кнопкой мыши на пиктограмме Му Network Places (Мое сетевое окружение) и выберите Properties (Свойства) из контекстного меню. Откроется окно Network and Dial-up Connections (Сеть и подключения к Интернету).
Щелкните правой кнопкой мыши на пиктограмме Local Area Connection (Подключение по локальной сети) и выберите пункт Properties (Свойства) из контекстного меню. Откроется окно Local Area Connection Properties (Подключение по локальной сети — Свойства).
Щелкните дважды на пункте Internet Protocol (TCP/IP) (Протокол Интернета (TCP/IP)). Откроется окно Internet Protocol (TCP/IP) Properties (Свойства: Протокол Интернета (TCP/IP)).
Щелкните на кнопке Advanced (Дополнительно). Откроется окно Advanced TCP/IP Settings (Дополнительные параметры TCP/IP).
Откройте вкладку WINS (рис. 4.5). Убедитесь, что выбран переключатель Enable NetBIOS over TCP/IP (Включить NetBIOS через TCP/IP). При отключении этого параметра клиент не будет использовать службу WINS, даже если адрес WINS-сервера будет указан в соответствующем поле.
Р Bi*UWOSrtl*»Р Bi*UWOSrtl*»*5*»|0HS VMS|pp^>«|MHSaM*HM.nadac*u«« -*5*»|0HS VMS|pp^>«|MHSaM*HM.nadac*u«« -Рис. 4.5. Окно Advanced TCP/IP Settings (вкладка WINS)Рис. 4.5. Окно Advanced TCP/IP Settings (вкладка WINS)
Р Bi*UWOSrtl*»
Р Bi*UWOSrtl*»
*5*»|0HS VMS|pp^>«|
MHSaM*HM.nadac*u«« -
*5*»|0HS VMS|pp^>«|
MHSaM*HM.nadac*u«« -
Рис. 4.5. Окно Advanced TCP/IP Settings (вкладка WINS)
Рис. 4.5. Окно Advanced TCP/IP Settings (вкладка WINS)
Щелкните на кнопке Add (Добавить). Откроется окно TCP/IP WINS Server (WINS-сервер TCP/IP). Введите IP-адрес сервера WINS и щелкните на кнопке Add (Добавить), чтобы сохранить изменения и вернуться в окно Advanced TCP/IP Settings. Также можно добавить адрес резервного WINS-сервера, если он существует. Клиент будет отправлять запросы резервному серверу при недоступности основного WINS-сервера.
Щелкните на кнопке ОК, чтобы сохранить изменения и вернуться в окно Internet Protocol (TCP/IP) Properties.
Щелкните на кнопке ОК для возврата в окно Local Area Connection Properties.
Щелкните на кнопке ОК для закрытия окна.
Откройте окно интерпретатора командной строки.
Введите nbtstat -rr для регистрации клиента на сервере WINS.
Повторите процедуру для каждого клиента со статическим адресом. После этого возвращайтесь к серверу WINS для проверки записей о регистрации.
Управление записями WINS
После настройки клиентов на использование сервера WINS процесс регистрации и преобразования имен происходит автоматически. Результат работы службы можно наблюдать на консоли WINS. Для открытия консоли воспользуйтесь командой Start^Programs^Adminis- trative ToolsWINS (Пуск1* Программы1* Администрирование1* WINS).
Администраторы Windows NT, привыкшие к стандартному интерфейсу управления службой WINS, могут заметить, что консоль WINS практически ничем не отличается. На правой панели выводится дерево серверов WINS в пределах организации. Эта консоль поддерживает управление серверами WINS, работающими под управлением операционной системы Windows NT. На рис. 4.6 показан пример для сети с несколькими серверами WINS.
witswits. >ua.si
wits
wits
qjwiNS3 Server StatusS И SERVERI [192.168.0.1]qjwiNS3 Server StatusS И SERVERI [192.168.0.1]' Q| Replication Partners S Й 5ERVER2 [192.168.0.2] Active Registrations ; [^ Replkation Partners ?5 @)SRV1 [192.168.0.60]•■-^ Active Registrations 1 .^t Replkation Partners' Q| Replication Partners S Й 5ERVER2 [192.168.0.2] Active Registrations ; [^ Replkation Partners ?5 @)SRV1 [192.168.0.60]•■-^ Active Registrations 1 .^t Replkation PartnersД^ Active RegistrationsД^ Active RegistrationsYou can use this space to list the corr^xrter and group records that are in the WINS database. To list the records, tick Action, and then ckk Display Records. In the Display Records dialog box, you can fifter the records in a variety of ways:
qjwiNS
3 Server Status
S И SERVERI [192.168.0.1]
qjwiNS
3 Server Status
S И SERVERI [192.168.0.1]
' Q| Replication Partners S Й 5ERVER2 [192.168.0.2] Active Registrations ; [^ Replkation Partners ?5 @)SRV1 [192.168.0.60]
•■-^ Active Registrations 1 .^t Replkation Partners
' Q| Replication Partners S Й 5ERVER2 [192.168.0.2] Active Registrations ; [^ Replkation Partners ?5 @)SRV1 [192.168.0.60]
•■-^ Active Registrations 1 .^t Replkation Partners
Д^ Active Registrations
Д^ Active Registrations
* To ftfcer records by NetBIOS name or IP address, tick the Record Mapping tab. If you ffcer by IP address, you can also Mter by subnet mask.
।।* To fiter records by owner, click the Record Owners tab.
।
।
Puc. 4.6. Управление несколькими WINS-серверами с помощью консоли WINS
В разделе каждого сервера присутствуют пункты Active Registrations (Активные регистрации) и Replication Partners (Партнеры репликации). Щелкните правой кнопкой мыши на разделе Active Registrations (Активные регистрации) соответствующего .сервера и выберите команду Display Records (Показать записи) из контекстного меню. В окне Display Records откройте вкладку Record Owners (Владельцы записей), как показано на рис. 4.7. На этой вкладке выводится список партнеров по репликации. Каждый сервер показан, как Owner, что говорит о том, что сервер владеет несколькими записями в базе данных WINS.
Многие неопытные администраторы WINS считают понятие “владелец” не совсем понятным. Как только клиент регистрируется на сервере WINS, сервер становится “владельцем" (owner) соответствующей записи. Владелец записи отвечает за репликацию информации среди партнеров по репликации.
Просматривая список серверов на консоли WINS, обратите внимание на содержимое отдельных баз данных WINS. В базе данных содержатся записи, принадлежащие серверу, а также записи, полученные от партнеров по репликации. В идеальном случае содер-
жимое баз данных каждого сервера будет совпадать с содержимым баз данных его партнеров по репликации. Так бывает, только если сервер регулярно получает обновления от владельцев записей.
Рис. 4.7. Консоль WINS. Окно Display Records, вкладка Record Owners со списком партнеров по репликации .Рис. 4.7. Консоль WINS. Окно Display Records, вкладка Record Owners со списком партнеров по репликации .
Рис. 4.7. Консоль WINS. Окно Display Records, вкладка Record Owners со списком партнеров по репликации .
Рис. 4.7. Консоль WINS. Окно Display Records, вкладка Record Owners со списком партнеров по репликации .
Для просмотра списка записей, принадлежащих конкретному серверу, щелкните на кнопке Find Now (Найти) в окне Display Records (Показать записи). Записи будут показаны в левой панели (рис. 4.8).
GmGmSERVERI [192.166.0.1]SERVERI [192.166.0.1]i^ Repkation Partners j 5ERVER2 [192.168.0.2] 3 3 SRVI [192.168.0.60]i^ Repkation Partners j 5ERVER2 [192.168.0.2] 3 3 SRVI [192.168.0.60]SERVERI SER VERIO 5ER VERIO SER VERIO 5ERVER2 5ERVER2 5ERVER2SERVERI SER VERIO 5ER VERIO SER VERIO 5ERVER2 5ERVER2 5ERVER2%SERVERS Д SER VERS %SERVERS 1 SERVER*SERVER* SERVER* SRVi SRV1 % SUBSIDIARY % SUBSIDIARY%SERVERS Д SER VERS %SERVERS 1 SERVER*SERVER* SERVER* SRVi SRV1 % SUBSIDIARY % SUBSIDIARYГа* I wwГа* I ww[20h] fife Server192.168.0.1Active192.168.0.1[OOh] Workstation192.168.0.12Active192.168.0.1[03h] Messenger192.168,0,12Released192.168.0.1[20h] fife Server192.168.0.12Released192.168.0.1[OOh] Workstation192.168.0.2Active192.168.0.2[03h] Messenger192.168.0.2Active192.168.0.2[20h] Fie Server192.16B.0.2Active192.168.0.2[OOh] Workstation192.168.0.13Active192.168.0.1[03h] Messenger192.168.0,106Active192.168.0.1[20h] file Server192.168.0,13Active192.168.0.1[OOh] Workstation192.168.0.105Active192.168.0.1[03h] Messenger192.168.0,105Active192.168.0.1[20h] fife Server192.168.0.105Active192.168.0.1[OOh] Workstation192.168.0.60Active192.168.0.60[20h] fife Server192.168.0.60Active192.168.0.60[OOh] Workycx»192,168,0.1Active192.168.0.1[ICh] Domain Contr...192.168.0.1Active192.168.0.1[lEhjNormal Group...192.168.0.1Active192.168.0.1[20h] fife Server192.168.0.1Active192.168.0.1[OOh] Workstation192.168.0.12Active192.168.0.1[03h] Messenger192.168,0,12Released192.168.0.1[20h] fife Server192.168.0.12Released192.168.0.1[OOh] Workstation192.168.0.2Active192.168.0.2[03h] Messenger192.168.0.2Active192.168.0.2[20h] Fie Server192.16B.0.2Active192.168.0.2[OOh] Workstation192.168.0.13Active192.168.0.1[03h] Messenger192.168.0,106Active192.168.0.1[20h] file Server192.168.0,13Active192.168.0.1[OOh] Workstation192.168.0.105Active192.168.0.1[03h] Messenger192.168.0,105Active192.168.0.1[20h] fife Server192.168.0.105Active192.168.0.1[OOh] Workstation192.168.0.60Active192.168.0.60[20h] fife Server192.168.0.60Active192.168.0.60[OOh] Workycx»192,168,0.1Active192.168.0.1[ICh] Domain Contr...192.168.0.1Active192.168.0.1[lEhjNormal Group...192.168.0.1Active192.168.0.133
Gm
Gm
SERVERI [192.166.0.1]
SERVERI [192.166.0.1]
i^ Repkation Partners j 5ERVER2 [192.168.0.2] 3 3 SRVI [192.168.0.60]
i^ Repkation Partners j 5ERVER2 [192.168.0.2] 3 3 SRVI [192.168.0.60]
SERVERI SER VERIO 5ER VERIO SER VERIO 5ERVER2 5ERVER2 5ERVER2
SERVERI SER VERIO 5ER VERIO SER VERIO 5ERVER2 5ERVER2 5ERVER2
%SERVERS Д SER VERS %SERVERS 1 SERVER*
SERVER* SERVER* SRVi SRV1 % SUBSIDIARY % SUBSIDIARY
%SERVERS Д SER VERS %SERVERS 1 SERVER*
SERVER* SERVER* SRVi SRV1 % SUBSIDIARY % SUBSIDIARY
Га* I ww
Га* I ww
[20h] fife Server
192.168.0.1
Active
192.168.0.1
[OOh] Workstation
192.168.0.12
Active
192.168.0.1
[03h] Messenger
192.168,0,12
Released
192.168.0.1
[20h] fife Server
192.168.0.12
Released
192.168.0.1
[OOh] Workstation
192.168.0.2
Active
192.168.0.2
[03h] Messenger
192.168.0.2
Active
192.168.0.2
[20h] Fie Server
192.16B.0.2
Active
192.168.0.2
[OOh] Workstation
192.168.0.13
Active
192.168.0.1
[03h] Messenger
192.168.0,106
Active
192.168.0.1
[20h] file Server
192.168.0,13
Active
192.168.0.1
[OOh] Workstation
192.168.0.105
Active
192.168.0.1
[03h] Messenger
192.168.0,105
Active
192.168.0.1
[20h] fife Server
192.168.0.105
Active
192.168.0.1
[OOh] Workstation
192.168.0.60
Active
192.168.0.60
[20h] fife Server
192.168.0.60
Active
192.168.0.60
[OOh] Workycx»
192,168,0.1
Active
192.168.0.1
[ICh] Domain Contr...
192.168.0.1
Active
192.168.0.1
[lEhjNormal Group...
192.168.0.1
Active
192.168.0.1
[20h] fife Server
192.168.0.1
Active
192.168.0.1
[OOh] Workstation
192.168.0.12
Active
192.168.0.1
[03h] Messenger
192.168,0,12
Released
192.168.0.1
[20h] fife Server
192.168.0.12
Released
192.168.0.1
[OOh] Workstation
192.168.0.2
Active
192.168.0.2
[03h] Messenger
192.168.0.2
Active
192.168.0.2
[20h] Fie Server
192.16B.0.2
Active
192.168.0.2
[OOh] Workstation
192.168.0.13
Active
192.168.0.1
[03h] Messenger
192.168.0,106
Active
192.168.0.1
[20h] file Server
192.168.0,13
Active
192.168.0.1
[OOh] Workstation
192.168.0.105
Active
192.168.0.1
[03h] Messenger
192.168.0,105
Active
192.168.0.1
[20h] fife Server
192.168.0.105
Active
192.168.0.1
[OOh] Workstation
192.168.0.60
Active
192.168.0.60
[20h] fife Server
192.168.0.60
Active
192.168.0.60
[OOh] Workycx»
192,168,0.1
Active
192.168.0.1
[ICh] Domain Contr...
192.168.0.1
Active
192.168.0.1
[lEhjNormal Group...
192.168.0.1
Active
192.168.0.1
3
3
Puc. 4.8. На консоли WINS отображается список регистрационных записей клиентов на указанном сервере WINS
Просмотр свойств записей WINS
Для просмотра содержимого записи WINS щелкните правой кнопкой на значке записи в правой панели и выберите из контекстного меню пункт Properties (Свойства). Откроется окно со свойствами выбранной записи. Пример такого окна показан на рис. 4.9.
Рис. 4.9. Окно свойств записи WINS
В поле Туре (Тип) отображается имя зарегистрированной службы. Это поле соответствует идентификатору службы, который указывается в конце имени NetBIOS.
В поле Record State (Состояние записи) может быть указано одно из трех значений.
Active (Действующая). Клиент WINS находится в сети и имеет текущую запись в базе данных WINS.
Released (Освобожденная). Клиент WINS сообщил серверу об отключении от сети или срок действия записи истек без своевременного возобновления.
Tombstoned (Замороженная). Срок действия записи завершился, и клиент не возобновил регистрацию.
Дата в поле Expiration (Действительна до) определяется заданным периодом удаления. По умолчанию этот период составляет шесть дней.
В поле Version ID (Идентификатор версии) указан порядковый номер записи, назначаемый ее владельцем. Сервер WINS поддерживает счетчик, который обновляет идентификатор версии при каждом изменении записи. Этот идентификатор используется при репликации записей между серверами. Сервер сообщает партнеру по репликации: “У меня есть твои записи с номером ЗА7. Предоставь записи с номером ЗА8 или выше”.
Создание статических записей WINS
Если в сети присутствует сервер под управлением операционной системы UNIX или другой узел, использующий IP-адресацию и не поддерживающий преобразование имен NetBIOS, имена хостов и IP-адреса можно предоставить с помощью статических соответствий. Этот метод эквивалентен добавлению записей на сервер DNS и позволяет поддерживать устаревшие клиенты Windows, которые поддерживают преобразование имен WINS и не поддержи-
вают DNS. Кроме этого, статические соответствия можно использовать для отображения узлов Windows в других сетях. Последовательность действий при создании статического соответствия рассматривается в процедуре 4.5.
Процедура 4.5. Добавление статического соответствия WINS
Откройте консоль WINS и найдите дерево Active Registrations (Активные регистрации).
Щелкните правой кнопкой мыши на пункте Active Registrations (Активные регистрации) и выберите из контекстного меню команду New Static Mapping (Новое статическое соответствие). Откроется окно New Static Mapping (рис. 4.10).
Рис. 4.10. В окне New Static Mapping создана статическая запись для сервера
Введите имя и IP-адрес сервера. Оставьте пустым поле NetBIOS Scope (Область NetBIOS). В поле Туре (Тип) выберите значение Unique (Уникальный).
Щелкните на кнопке ОК для сохранения записи и возврата на консоль WINS.
После этого в списке Active Registrations (Активные регистрации) будут отображаться три записи для выбранного узла: File Server, Workstation и Messenger. Это стандартные записи для всех статических соответствий.
На клиенте WINS проверьте возможность подключения к новому узлу с помощью имени NetBIOS. Если на новом узле работает служба SMB, то соединение должно быть установлено.
Удаление записей
В базе данных WINS со временем накапливаются ошибочные записи. Нередко в базе данных можно найти повторяющиеся записи, “замороженные” (tombstoned) записи и записи для уже несуществующих рабочих групп и статических соответствий удаленных клиентов. Для удаления конкретной записи щелкните на ней правой кнопкой мыши и выберите команду Delete (Удалить) из контекстного меню. Откроется окно Delete Record (Удаление записи), как показано на рис. 4.11. Рассмотрим доступные варианты.
Delete the Record Only from This Server (Удалить запись только с этого сервера). Этот вариант применяется, когда некорректная запись существует только на одном сервере. Например, на сервере возникла проблема при репликации. Проблема была решена, но сервер успел создать в базе данных несколько ошибочных записей. Этот вариант можно использовать для удаления таких записей.
Replicate Deletion of the Record to Other Servers (Tombstone) (Реплицировать удаление записи на других серверах). Этот вариант не приводит к немедленному удалению записи. Вместо этого запись помечается как поставленная в очередь на удаление — “замороженная” (tombstoned) запись. Информация о такой записи реплицируется на другие серверы, при этом запись считается недействительной. По завершении срока возобновления запись удаляется.
Лл1Лл1Рис. 4.11. В окне Delete Record (Удаление записи) можно выбрать способ удаления записи из базы данных WINSРис. 4.11. В окне Delete Record (Удаление записи) можно выбрать способ удаления записи из базы данных WINS
Лл1
Лл1
Рис. 4.11. В окне Delete Record (Удаление записи) можно выбрать способ удаления записи из базы данных WINS
Рис. 4.11. В окне Delete Record (Удаление записи) можно выбрать способ удаления записи из базы данных WINS
Настройка репликации WINS
До настройки репликации WINS стоит набросать схему предполагаемой топологии репликации. Составив такую схему, воспользуйтесь инструкциями процедуры 4.6 для настройки репликации.
Процедура 4.6. Настройка репликации WINS
Откройте консоль WINS с помощью команды Starts Programs1* Administrative Tools*WINS ( Пу ск ■* Программы * Администрирование ■* W INS ).
Щелкните правой кнопкой мыши на пункте Replication Partners (Партнеры репликации) и выберите из контекстного меню команду New Replication Partner (Новый партнер репликации).
В открывшемся окне введите IP-адрес сервера WINS, который будет выступать в роли партнера по репликации. Имя NetBIOS можно вводить только в том случае, если сервер находится в той же локальной подсети.
Щелкните на кнопке ОК для сохранения изменений.
На хосте, который является партнером по репликации, выполните такую же последовательность действий, указав первый сервер в качестве партнера по репликации.
После успешной репликации записи партнеров должны оказаться в соответствующих базах данных, а имена серверов должны появиться на вкладке Display Owners (Показать владельцев) в окне Display Records (Показать записи).
Щелкните правой кнопкой мыши на записи для партнера по репликации и выберите команду Properties (Свойства) из контекстного меню. Откроется окно Properties (Свойства).
Откройте вкладку Advanced (Дополнительно), которая показана на рис. 4.12. По умолчанию используется вариант репликации Push/Pull (Принудительная репликация/реплика-
ция по запросу). Значение интервала репликации по умолчанию равно 30 минутам. Для дорогих в использовании внешних каналов этот интервал можно увеличить.
В разделах Pull Replication (Репликация по запросу) и Push Replication (Принудительная репликация) выберите Use Persistent Connection for Replication (Использовать постоянное соединение при репликации). Этот параметр позволяет избежать проблем классической службы WINS, при которых соединение создавалось только на время репликации. Это ограничивало количество длительных соединений по внешним каналам, но увеличивало задержки при репликации. Современное оборудование для передачи данных позволяет добиться повышенного быстродействия за счет использования постоянных соединений.
Рис. 4.12. Окно для настройки свойств партнера по репликации. На вкладке Advanced (Дополнительно) можно задать тип и интервал репликации, а также параметры постоянного подключения
В разделе Push Replication (Принудительная репликация) оставьте для параметра Number of Changes in Version ID Before Replication (Количество изменений идентификатора версии до репликации) значение 0. Это позволит реплицировать записи сразу после внесения изменений.
После завершения настройки репликации для обоих партнеров проверьте системный журнал событий. В журнале должны присутствовать записи об успешном завершении репликации.
В следующем разделе содержится дополнительная информация об управлении репликацией WINS.
Управление базой данных WINS
Кроме настройки параметров просмотра записей и управления репликацией, возможности службы WINS позволяют управлять базой данных WINS и обработкой записей в этой базе. Для доступа к этим возможностям щелкните правой кнопкой мыши на пиктограмме сервера на кон-
соли WINS и выберите команду Properties (Свойства) из контекстного меню. Откроется окно Properties (Свойства), в котором отображаются заданные параметры сервера (рис. 4.13).
Флажок Automatically Update Statistics Every (Автоматически обновлять статистику каждые) установлен по умолчанию. Этот параметр определяет период обновления статистики сервера WINS. Получить статистические данные можно, щелкнув правой кнопкой мыши на значке сервера и выбрав из контекстного меню команду Display Server Statistics (Отобразить статистику для сервера). При этом откроется окно WINS Server Statistics (Статистика WINS- сервера), в котором отображается информация о репликации со всеми партнерами.
Рис. 4.13. Окно WINS Server Properties. Вкладка General (Общие)
По умолчанию флажок Back Up Database During Shutdown (Создать резервную копию базы данных при аварийном отключении) не установлен. Активизация этого параметра позволяет останавливать механизм управления базами данных Jet и копировать файл wins . mdb при каждом останове сервера. Если в системе уже организовано резервное копирование файлов с помощью другой программы, то использовать эту возможность необязательно. Убедитесь, что программа резервного копирования сертифицирована для использования под управлением операционной системы Windows Server 2003. Сертифицированная программа поддерживает резервное копирование открытой базы данных WINS.
Установка интервалов возобновления и удаления
Перейдите на вкладку Intervals (Интервалы), которая показана на рис. 4.14. На вкладке можно изменить значения четырех интервалов. В большинстве случаев наилучший результат обеспечивается принятыми по умолчанию значениями. Изменение значений без предварительного анализа их взаимосвязи может привести к нарушению целостности базы данных. Ниже приводится дополнительная информация о различных интервалах.
Renew interval (Интервал возобновления). В этом интервале клиент должен возобновить регистрацию имени. Обычно клиенты выполняют возобновление по истечении половины интервала. Кроме этого, интервал возобновления определяет частоту периодического сбора “мусора”. В процессе сбора “мусора” система удаляет записи, помеченные как “замороженные”, а также выполняет сжатие базы данных. Частая сборка “мусора” позво-
ляет предотвратить множество сбоев и увеличивает быстродействие. Сборку “мусора” можно запустить вручную. Для этого на консоли WINS необходимо щелкнуть правой кнопкой мыши на значке сервера WINS и из контекстного меню выбрать команду Scavenge Database (Собрать мусор).
Рис. 4.14. Вкладка Intervals (Интервалы) в окне свойств WINS-сервера
Extintion interval (Интервал удаления). Это значение присваивается освобожденной записи. В течение этого интервала сохраняется освобожденная запись. До окончания интервала владелец не реплицирует запись и ожидает повторной регистрации клиента. После завершения интервала при условии, что клиент не зарегистрировался повторно, запись помечается как “замороженная” (tombstoned).
Extintion timeout (Задержка удаления). Это значение присваивается записи в состоянии “замороженная”. Если клиент не затребует связанный с записью IP-адрес или имя, после завершения задержки удаления запись удаляется в процессе сборки “мусора".
Verification interval (Интервал проверки). Это значение присваивается реплицированной записи. Если в процессе сборки “мусора” “возраст” записи превышает интервал проверки, сервер запрашивает информацию о действительности записи у партнера по репликации. Если запись недействительна, то она удаляется. В противном случае запись обновляется и для нее устанавливается новый интервал проверки. По умолчанию интервал проверки составляет 24 дня.
Обеспечение целостности базы данных
Откройте вкладку Database Verification (Проверка базы данных), которая показана на рис. 4.15. В этом окне предоставляются параметры, доступные в классической службе WINS только при непосредственном редактировании системного реестра. Проверка целостности базы данных заключается в копировании ее содержимого в базу данных партнера по репликации с последующим сравнением оригинала и копии.
В поле Begin Verifying At (Начать проверку в) можно задать время начала проверки. По умолчанию проверка начинается в 2 часа ночи.
По умолчанию флажок в этом поле установлен, и, кроме случаев, когда база данных WINS оказывается слишком большой для ежедневной проверки, сбрасывать его не следует. Если размер базы данных WINS является слишком большим, выберите переключатель Randomly Selected Partners (Случайно выбираемые партнеры), что позволит ежедневно выполнять частичную проверку целостности.
Место хранения журнала и базы данных.
Преодоление пиковых нагрузок
Откройте вкладку Advanced (Дополнительно), как показано на рис. 4.16. На этой вкладке доступны три параметра.
.Я XI.Я XI
.Я XI
.Я XI
Suiting w*r Ю *шйкМ^
I? Uwco«irtm!weiei»e«c»e*lii«iifii/WM«H!<
Г ® 1. с***1 I
Рис. 4.16. Вкладка Advanced (Дополнительно) в окне свойств WINS-сервераРис. 4.16. Вкладка Advanced (Дополнительно) в окне свойств WINS-сервераРис. 4.15. Вкладка Database Verification в окне свойств WINS-сервера
Рис. 4.16. Вкладка Advanced (Дополнительно) в окне свойств WINS-сервера
Рис. 4.16. Вкладка Advanced (Дополнительно) в окне свойств WINS-сервера
При наличии установленного флажка для параметра Log Detailed Events to Windows Event Log (Записывать подробный отчет в системный журнал Windows) служба WINS будет записывать в системный журнал информацию о любом событии. При установке флажка выдается предупреждение о высокой вероятности быстрого исчерпания доступного дискового пространства. Этот параметр должен использоваться только в процессе диагностики.
Параметр Enable Bursit Handling (Позволить обработку пиковых ситуаций) позволяет выбрать способ реагирования на возникновение ситуации, когда регистрацию запрашивает несколько клиентов WINS. При первом включении сервера WINS в большую сеть несколько тысяч клиентов могут переполнить базу данных запросами на создание новой записи. Обычно при переполнении очереди запросов очередные запросы просто отбрасываются. При использовании параметра Burst Handling клиентам предоставляется положительный ответ на запрос регистрации с небольшим периодом возобновления (пять минут). Это эквивалентно ответу “Возвращайтесь, когда сервер будет не так занят" со стороны сервера WINS. Если на сервер ложится очень большая нагрузка, то клиентам выдаются ответы со все более высоким значением интервала возобновления.
С помощью четырех переключателей можно изменять значение записи BurstQueSize в разделе системного реестра HKLM\System\CurrentControlSet\Services\WINS\
Parameters. Ниже показаны предопределенные значения. Числа соответствуют предельному количеству запросов на регистрацию в очереди.
Low (Низкое)3 00
Medium (Среднее)500
High (Высокое)1000
Если используется выделенный сервер WINS с оборудованием достаточной мощности, можно выбрать переключатель Custom и установить значение 2 500?
Параметр Database Path (Сохранить как) пригодится при смене расположения базы данных WINS (для переноса базы данных из системного раздела на быстрый жесткий диск или на том с дополнительным свободным пространством). Перед перемещением базы данных не забудьте остановить службу. Вместе с базой данных следует переместить файлы журналов.
Установка принятых по умолчанию свойств консоли WINS
Некоторые параметры оказывают влияние непосредственно на консоль WINS. На консоли WINS щелкните правой кнопкой мыши на пиктограмме WINS в верхней части списка и выберите команду Properties (Свойства) из контекстного меню. Откроется окно WINS Properties (Свойства консоли WINS).
В этом окне можно выбрать способ отображения списка серверов: по имени или по IP-адресу.
Флажок в поле Show DNS Names for WINS Servers (Отображать DNS-имя для WINS- серверов) позволяет отображать полностью определенное имя DNS для каждого сервера (вместо “плоского" имени NetBIOS). Этот параметр может ввести администратора в заблуждение, поскольку полностью определенное имя создается на основе суффикса DNS в свойствах системы, а не на основе параметров протокола TCP/IP. Если сервер WINS не настроен на подключение к домену, суффикс DNS, скорее всего, будет отсутствовать.
Чтобы проверить значение суффикса DNS, откройте аплет System (Система) в Control Panel (Панели управления) и перейдите на вкладку Network Identification (Сетевая идентификация). Если в поле Full Computer Name (Полное имя компьютера) не указан суффикс DNS, щелкните на кнопках Properties (Свойства) и More (Добавить) для добавления суффикса. После добавления суффикса компьютер нужно перезагрузить.
При выборе параметра Validate Cache of WINS Servers at Startup (Проверять кэш WINS- сервера при загрузке) служба WINS будет опрашивать серверы WINS из списка партнеров. Если один или несколько серверов окажутся недоступны, то выводится предупреждающее сообщение и в журнал событий добавляется соответствующая запись.
Что можно и чего нельзя делать со службой WINS
При управлении крупной инфраструктурой WINS можно воспользоваться советом моего дедушки, старого ковбоя из Нью-Мексико. Дедушка любил говорить: “Никогда не становись перед стадом, не делай резких движений и помни, что всегда можешь застрелить нарушителя спокойствия". Вот как эти советы относятся к службе WINS.
■ Не создавайте сервер WINS в каждом сегменте локальной сети. Репликация WINS имеет заслуженную репутацию ненадежного механизма. Клиенты WINS способны находить серверы преобразования имен за несколькими маршрутизаторами. Устанавливайте серверы в стратегических точках и используйте внешние подключения для маршрутизации регистраций и запросов.
Не устанавливайте независимые серверы WINS. Репликация WINS в пределах организации должна быть хорошо скоординирована. Недоверие и критика власти приветствуется в США, но в случае службы WINS это может привести к серьезным проблемам.
Создайте полную схему топологии репликации. Внимательно следите, чтобы при репликации не возникали циклы обмена информацией.
Регулярно проверяйте статистику базы данных. Не ждите, пока повреждение базы данных застанет вас врасплох. В операционной системе Windows Server 2003 механизм управления базой данных Jet менее подвержен нарушениям в работе баз данных, чем в предыдущих версиях операционной системы, но вероятность ошибки все еще существует, поэтому не стоит терять бдительности.
Старайтесь не использовать proxy-серверы для передачи запросов WINS. Proxy-серверы используются для поддержки клиентов Windows, не имеющих стека IP от компании Microsoft. Proxy-сервер службы WINS ожидает широковещательных запросов напреобра- зование имен и передает их WINS-серверу. Ответ WINS-сервера передается клиенту. Однако ргоху-серверы WINS работают очень медленно, обладают кэшем ограниченного объема и выходят из строя. Если в сети присутствуют старые компьютеры под управлением операционной системы Windows 3.x, вместо установки ргоху-серверов WINS модернизируйте операционные системы.
При полном отказе службы удалите ее и установите заново. Если определенный сервер WINS является источником проблемы, лучше всего остановить службу WINS, удалить файлы в каталоге \windows\System32\wins и начать настройку службы заново. Это особенно справедливо при наличии партнеров по репликации. Лучше повторно создать локальную базу данных WINS и статические соответствия, чем нарушить работу всей инфраструктуры.
Отключение службы преобразования имен NetBIOS-over-TCP/IP
После завершения перехода на операционные системы Windows Server 2003 и Windows 2000 на серверах и рабочих станциях преобразование имен NetBIOS-over-TCP/IP можно отключить и использовать только преобразование имен DNS. Операционные системы Windows Server 2003 и Windows 2000 обмениваются данными SMB через ТСР-порт 445. Отказ от преобразования имен NetBIOS-over-TCP/IP позволяет значительно сократить объем данных, передаваемых по сети.
С практической точки зрения до удаления из сети всех более ранних версий операционной системы Windows избавиться от преобразования имен NetBIOS-over-TCP/IP не удастся. Классические службы Browser и Messenger для своей работы используют службы Nott. Как только переход станет возможен, выполните последовательность действий, описанных в процедуре 4.7.
Процедура 4.7. Отключение преобразования имен NetBIOS-over-TCP/IP
Откройте окно Network and Dial-up Connections (Сеть и подключения к Интернету). Для этого щелкните правой кнопкой мыши на пиктограмме Му Network Places (Мое сетевое окружение) и выберите команду Properties (Свойства).
Щелкните правой кнопкой мыши на пиктограмме Local Area Connection (Подключение по локальной сети) и выберите пункт Properties (Свойства) из контекстного меню. Откроется окно Local Area Connection Properties (Подключение по локальной сети — Свойства).
Выберите пункт Internet Protocol (TCP/IP) (Протокол Интернета (TCP/IP)) и щелкните на кнопке Properties (Свойства). Откроется окно Internet Protocol (TCP/IP) Properties (Свойства: Протокол Интернета (TCP/IP)).
Щелкните на кнопке Advanced (Дополнительно). Откроется окно Advanced TCP/IP Settings (Дополнительные параметры TCP/IP).
Откройте вкладку WINS.
Выберите переключатель Disable NetBIOS over TCP/IP (Отключить NetBIOS через TCP/IP). Обратите внимание, что этот параметр может применяться для клиентов DHCP.
Щелкните на кнопке ОК для сохранения изменений и возврата в окно Internet Protocol (TCP/IP) Properties (Свойства: Протокол Интернета (TCP/IP)).
Щелкните на кнопке ОК, чтобы вернуться в окно Local Area Connection Properties.
Щелкните на кнопке ОК, чтобы сохранить все изменения и закрыть окна.
Изменение параметров NetBIOS в системном реестре
Параметры NetBIOS, доступные через графический интерфейс, находятся в системном реестре в следующем разделе:
Раздел: HKLM\System\CurrentControlSet\Services\NETBT\Paranieters\lnterfaces\ Tcpip_{classid}
Запись: NetbiosOpt ions
Значение: 0 — используется DHCP; 1 — включено; 2 — выключено
В следующей главе
В этой главе рассматривался классический механизм преобразования имен в операционной системе Windows NT. Этот механизм предполагает использование широковещательных запросов, файла Lmhosts и службы WINS. В следующей главе рассматривается преобразование имен с помощью механизма Dynamic DNS. Кроме этого, в следующей главе описано, как организовать работу устаревших клиентов с Dynamic DNS средствами службы DHCP.
В
предыдущей главе рассматривались классические механизмы преобразования имен компьютеров в IP-адреса, которые широко использовались в операционной системе Windows NT. Операционная система Windows Server 2003 также поддерживает эти механизмы, но для преобразования имен предпочтительнее использовать службу DNS (Domain Name System).
Служба DNS является исключительно важным компонентом современных операционных систем Windows. Не будет преувеличением утверждение, что три четверти проблем в работе Active Directory или Kerberos связаны с теми или иными ошибками в настройке службы DNS. Кроме Active Directory и Kerberos, от службы DNS зависит множество других служб и возможностей.
В этой главе рассматривается работа службы DNS, предоставляемой в составе операционной системы Windows Server 2003. Рассматриваются проектирование архитектуры DNS, а также определенные этапы настройки. Кроме этого, описываются практические приемы настройки службы DNS, характерные для систем Windows промышленного масштаба, особенно в среде, где параллельно работают серверы DNS под управлением операционной системы Windows и других операционных систем.
Новые возможности операционной системы Windows Server 2003
В операционной системе Windows Server 2003 стали доступны следующие возможности службы DNS, отсутствовавшие в операционной системе Windows 2000.
Контексты именования приложений. При использовании зон, интегрированных в Active Directory, службу DNS можно настроить на хранение записей ресурсов в отдельном контексте Active Directory вместо использования контекста Domain. Такой подход позволяет упростить репликацию зон внутри большого леса. Выполняемый файл dnsadddp.exe запускается при каждой загрузке контроллера домена. Это приложение отвечает за создание разделов приложений DNS (если они не были созданы раньше). Дополнительная информация о репликации и контекстах именования DNS приводится в главе 17, “Управление шифрованием файлов”.
Зоны-заглушки DNS. Эта возможность упрощает делегирование зон. В зоне-заглушке содержатся связанные с дочерней зоной записи Start of Authority (SOA) и Name Server (NS), а также записи А для сервера преобразования имен. Такая зона-заглушка периодически опрашивает дочернюю зону и обновляет изменившиеся записи NS. Подобный механизм избавляет от необходимости вручную редактировать записи делегирования.
Перенаправление по условию. Эта возможность позволяет серверу преобразования имен выбирать сервер для перенаправления запроса на основе имени домена в клиентском запросе. До этого сервер был вынужден перенаправлять все не предназначенные конкретной зоне записи на единственный внешний сервер DNS.
Записи узлов IPv6. Для записи узлов по стандарту IPv6 используется 128-разрядное адресное пространство (в отличие от 32-разрядного адресного пространства протокола IPv4). Служба DNS в операционной системе Windows Server 2003 поддерживает записи ресурсов АААА, содержащие адреса IPv6. Эта возможность соответствует документу RFC 1886, “DNS Extensions to Support IP Version 6” (“Расширения DNS для поддержки протокола IP версии 6”). Операционная система Windows Server 2003 не поддерживает недавно предложенный тип записей Аб и реструктуризацию зон обратного преобразования IPv6, описанные в документе RFC 2874, “DNS Extensions to Support IPv6 Address Aggregation and Renumbering”.
Расширения DNS. В текущей реализации службы DNS для обмена данными между клиентом и сервером используется протокол UDP. Максимальный размер стандартных дейтаграмм UDP составляет 512 байт. Многие новые возможности DNS требуют использования дейтаграмм большего размера. На данный момент для передачи больших записей ресурсов используется создание временных сеансов TCP, что увеличивает непроизводительные расходы и усложняет механизм взаимодействия. Операционная система Windows Server 2003 позволяет клиенту и серверу преобразования имен договориться об использовании дейтаграмм большего размера, если это возможно. Эта возможность реализована на основе документа RFC 2671, “Extension Mechanisms for DNS (EDNS0)”.
Маска подсети в зоне обратного преобразования. Если используется нестандартная маска подсети, операционная система Windows Server 2003 позволяет указывать маску подсети как часть имени зоны обратного преобразования. Такая возможность позволяет выделять записи Pointer (PTR) правильным подсетям.
В состав Windows Server 2003 Resource Kit входит утилита DNSLint, которая предоставляет список функций службы DNS, необходимых для поддержки Active Directory, а также указывает на потенциальные источники проблем. Эта программа особенно удобна для диагностики неполадок при аутентификации и репликации Active Directory.
Администраторы операционной системы Windows NT обнаружат в операционной системе Windows Server 2003 множество усовершенствований, которые были заимствованы из опера-- ционной системы Windows 2000. Среди них можно перечислить следующие.
Перенос зон на основе уведомлений. Стандартная реализация службы DNS требует, чтобы вторичные серверы преобразования имен опрашивали основной сервер на предмет обновлений данных зоны. В операционных системах Windows 2000 и Windows Server 2003 реализованы возможности, позволяющие основному серверу уведомлять вторичные серверы о необходимости обновления зоны. После этого вторичные серверы выполняют немедленную репликацию, значительно сокращая время полного распространения изменений. Эта возможность реализована в соответствии с документом RFC 1996, “A Mechanism for Prompt Notification of Zone Changes”.
Инкрементные переносы зон. При стандартной репликации зон DNS основной сервер передает вторичным серверам весь файл зоны при каждом обновлении. В операционных системах Windows 2000 и Windows Server 2003 вторичный сервер способен запросить у
основного сервера только изменения, которые были внесены в файл зоны с момента последней репликации. Это позволяет использовать низкоскоростные соединения для вторичных серверов преобразования имен. Возможность реализована в соответствии с документом RFC 1995, “Incremental Zone Transfer In DNS”.
Записи обнаружения служб. Для многих служб требуется создать механизм обнаружения клиентами. В операционных системах Windows 2000 и Windows Server 2003 поддерживаются записи ресурсов Service Locator или SRV. В записи SRV указываются имя службы, используемый протокол (TCP или UDP), номер порта и сервер или серверы, предоставляющие эту службу. Эта возможность реализована в соответствии с документом RFC 2782, “A DNS RR for specifying the location of services (DNS SRV)”.
Зоны, интегрированные в Active Directory. Записи ресурсов DNS можно хранить в базе данных Active Directory и обновлять на любом контроллере домена, поддерживающем работу службы DNS. Это позволяет избавиться от узких мест в виде единственного основного сервера DNS. Эта возможность является запатентованной функцией операционных систем Windows 2000 и Windows Server 2003.
Кэширование отрицательных ответов. Все клиенты DNS кэшируют результаты запросов преобразования имен для минимизации нагрузки на серверы и сокращения объема данных, передаваемых по сети. Операционные системы Windows 2000 и Windows Server 2003 поддерживают кэширование отрицательных результатов преобразования имен. Это предотвращает повторные запросы на преобразование несуществующего имени. Эта возможность реализована в соответствии с документом RFC 2308, “Negative Caching of DNS Queries (DNS NCACHE)”.
Безопасные обновления DNS. Функция автоматического обновления Dynamic DNS Updates может быть разрешена только для доверенных клиентов. Это позволяет предотвратить атаки, рассчитанные на заполнение зон некорректными записями ресурсов и перенаправление пользовательских данных на небезопасные узлы. Существует два основных документа RFC, описывающих безопасные обновления DNS: RFC 2535, “Domain Name System Security Extensions”, и RFC 2930, “Secret Key Establishment for DNS”. В операционной системе Windows 2000 вообще не поддерживаются эти RFC, а операционная система Windows Server 2003 предоставляет только базовую поддержку. Безопасные обновления DNS в операционной системе Windows Server 2003 продолжают работать по запатентованному методу, который использовался в операционной системе Windows 2000.
Обзор доменной структуры DNS
Перед глубоким погружением в среду доменов DNS рассмотрим вызывающую множество заблуждений разницу между толкованием значения слова домен (domain) компанией Microsoft и толкованием значения этого же слова с точки зрения службы DNS.
До появления Active Directory “домен” в понимании компании Microsoft не имел ничего общего с доменом DNS. Домен DNS определяет пространство имен, например Company. com. Записи ресурсов для узлов в пределах этого пространства имен хранятся в файле зоны, который часто называется просто зоной. В классической операционной системе Windows домен определяет инфраструктуру безопасности. Учетные записи пользователей, групп и компьютеров в пределах этой структуры безопасности хранятся в узле базы данных SAM в систем* ном реестре.
С появлением Active Directory два понятия, описываемые термином домен, стали близкими (практически синонимичными). Определяемая учетными записями структура безопасности в Active Directory соответствует пространству имен, определенному службой DNS.
Пространство имен домена DNS описывает отношения между узлами. Если хост Srvl расположен в домене Company. com, его полностью определенное доменное имя (Fully Qualified Domain Name — FQDN) будет выглядеть как srvl. company. com. Другой хост Srv2 в пределах того же домена будет иметь полностью определенное имя srv2 . company. com.
Домены объединяются в виде иерархической структуры, которая основана на едином пространстве имен. Домен DNS, который называется branch.company.com, будет дочерним доменом по отношению к домену company. com. На рис. 5.1 показан пример иерархии DNS, которая содержит несколько дочерних доменов.
Домен верхнего уровня, или корневой домен (root), иерархии DNS обозначается точкой (.) в начале (справа) полностью определенного доменного имени. Точка выполняет ту же функцию, что и наклонная черта в начале пути в файловой системе, а именно: определяет корень дерева. Распознаватель DNS (DNS resolver) начинает преобразование доменного имени с крайнего слева элемента в строке доменного имени; если сервер имен из локальной зоны не в состоянии ответить на запрос, то этот запрос передается на сервер более высокого уровня. Обычно в документации по службе DNS завершающая точка корневого домена не указывается. Утилиты операционной системы Windows для работы со службой DNS добавляют эту точку автоматически, поэтому о ее существовании легко можно забыть. Но в процессе диагностики на всякий случай точку лучше добавлять.
Общедоступные пространства имен DNS
Домен на вершине иерархии DNS называется корневым доменом (root domain). Для общедоступных доменов DNS корневой домен также называется доменом верхнего уровня (Тор Level Domain — TLD).
За регистрацию имен в пространстве имен Интернета отвечает организация Internet Corporation for Assigned Names and Numbers (ICANN). Сайт организации доступен по адресу www.icann.org.
Организация ICANN заключила соглашение с компанией Network Solutions, которая работает под именем Verisign Global Registry. В соответствии с этим соглашением компания Network Solutions должна управлять серверами преобразования имен для наибольших доменов верхнего уровня: com, net и огд. Сайт компании Verisign доступен по адресу www.verisign.grs.com.
В начале 2001 года компания Verisign перенесла серверы преобразования имен трех доменов верхнего уровня на 64-разрядную платформу и расположила их в ключевых точках сети
Интернет как на территории США, так и за пределами США. На момент создания этой книги работало 12 серверов доменов верхнего уровня, поддерживаемых компанией Verisign. Серверы называются в алфавитном порядке от а . gt Id-servers . net до m. gt Id-servers .net. Аббревиатура gTLD расшифровывается как generic Top Level Domain — оригинальный домен верхнего уровня.
Остальные домены верхнего уровня, mil, gov, int и edu, расположены на серверах компании Network Solutions, но управляются другими компаниями, назначенными ICANN. Серверы верхнего уровня для этих зон называются в алфавитном порядке от а. root - servers .net flom.root-servers.net. Кроме этого, в пространстве имен .mil присутствует несколько дополнительных серверов. Сервер а . root-servers .net выдает ссылки на новые серверы верхнего уровня компании Verisign.
Организация ICANN одобрила семь новых доменов верхнего уровня, чтобы снять часть нагрузки на домены .огд и .сот. В табл. 5.1 перечислены имена новых доменов верхнего уровня, а также названия агентств и компаний, которые выступили спонсорами новых доменов.
Таблица 5.1. Новые домены верхнего уровня и их спонсоры
Название домена верхнего уровня
Спонсор'
Адрес
aero
Societe Internationale de Telecommunications Aeronautiques SC (SITA)
www.sita.com
biz
Neulevel, Inc.
www.neulevel.biz
coop
National Cooperative Business Association
www.cooperative.org
info
Afilias, LLC
www.afilias.info
museum
Museum Domain Management Assoc
muaedoma-. museum
name
Global Name Registry
www.theglobalname.org
pro
RegistryPro, Ltd.
www.registrypro.com
Кроме этого, организация ICANN отвечает за региональные домены верхнего уровня, которые используют имена в соответствии с международными кодами стран. Такие домены называются ccTLD. Например, полностью определенное имя сайта в Норвегии будет начинаться с .по, например www.sol.no. Двухбуквенные обозначения стран соответствуют стандарту ISO 3166. Дополнительная информация о регистрации определенного домена в зоне ccTLD доступна по адресу www. iana . org/cctld/cctld-whois .htm.
Частные пространства имен DNS
Использовать общедоступный домен верхнего уровня в качестве корневого домена частной сети совсем не обязательно. Можно определить собственный корневой домен, который будет использоваться только во внутренней сети. Какое-то время в сети Интернет циркулировали предложения выделить домен .local в качестве зарезервированного домена DNS для частных сетей. Рекомендация не набрала достаточного количества сторонников.
Обычно в качестве корневого домена частного пространства имен можно использовать практически любую комбинацию букв. Избегайте имен, которые уже назначены организацией ICANN. Многие организации поддерживают собственные частные пространства имен DNS, использующие тот же корневой домен, что и общедоступное пространство имен организации. Для этого необходимо создать два сервера DNS с различными зонами.
Файл Hosts
Перед отправкой запроса на преобразование доменного имени в IP-адрес клиент DNS проверяет содержимое файла Hosts. Ниже приводится пример файла Hosts. Символ “диез” (#) является началом комментария.
10.1.1.110.1.1.210.3.1.27ч>10.2.1.1210.1.1.110.1.1.210.3.1.27ч>10.2.1.12dc01.company.com #контроллер домена в Company
10.1.1.1
10.1.1.2
10.3.1.27
ч>
10.2.1.12
10.1.1.1
10.1.1.2
10.3.1.27
ч>
10.2.1.12
dc02.company.com #еще один контроллер домена в Company srvl.branchl.company.com # сервер общего назначения
# в филиале компании
web7.subsidiary.com# Web-сервер в домене филиала
Для успешного преобразования имени узла, предоставленного приложением TCP/IP, это имя должно точно совпадать с именем, которое указано в файле Hosts. Например, при использовании приведенного выше файла Hosts команда ping dcOl не даст положительного результата, но команда ping dcOl. company. com позволит получить ответ. Если имя не записано в файле Hosts, для его преобразования клиент обращается к серверу DNS.
Первичный и вторичный серверы преобразования имен
Стандартный сервер DNS хранит данные записей в файле зоны. Серверы DNS на основе операционной системы Windows хранят данные зон в файлах с расширением . dns. Например, файл зоны для домена company. com будет называться company. com. dns. Файлы зон расположены в каталоге \windows\System32\DNS. Кроме этого, зона может быть интегрирована в Active Directory. В таком случае записи ресурсов хранятся в виде объектов базы данных Active Directory.
Рассмотрим схему на рис. 5.2. В стандартной архитектуре DNS только один сервер имеет право записи в файл зоны. Этот сервер называется основным, или первичным, сервером преобразования имен (primary name server). Все изменения в данных зоны должны вноситься только на этом сервере.
Для отказоустойчивости и производительности желательно установить еще один или несколько вторичных серверов преобразования имен (secondary name server). На вторичном сервере хранится файл зоны, предназначенный только для чтения. Вторичные серверы преобразования имен получают файлы зон от первичного сервера или от других вторичных серверов.
Сервер преобразования имен, который только кэширует результаты запросов для передачи информации клиентам, называется кэширующим сервером преобразования имен (caching- only name server).
Зависимость от работоспособности единственного первичного сервера преобразования имен является одним из недостатков классической архитектуры DNS. Как будет показано далее, интегрированные в Active Directory зоны позволяют избавиться от этого недостатка, превращая в первичный сервер каждый контроллер домена, на котором запущена служба DNS.
Совет по использованию реестра: место хранения файла Hosts
Файл Hosts хранится в каталоге \Windows\System32\Drivers\Etc вместе с остальными файлами, касающимися работы протокола TCP/IP, например Lmhosts, Protocols, Networks и Services. Этот каталог указан в следующей записи системного реестра:
Раздел: HKLM\System\CurrentControlSet\Services\ТСРIP\Parameters
Запись: DataBasePath
Значение: \Windows\System32\Drivers\Etc\
Контроллер домена Windows Server 2003
Запись а первичного DNS-сервера
Запись а вторичного DNS-сервера
Кешированная запись а DNS-сервера
Запись а контроллера домена Windows
Server 2003
Рис. 5.2. Пример архитектуры DNS-cepeepa
Записи ресурсов
Файл зоны содержит набор записей ресурсов (resource records). Каждая запись содержит определенную информацию об узле или службе, доступных в пределах домена DNS. В документе RFC 1183, “New DNS RR Definitions”, стандартизировано более десяти типов записей DNS. Достаточно часто используется лишь несколько типов записей.
Если клиент DNS запрашивает информацию у сервера преобразования имен, запрашивается информация из записей ресурсов. Например, если клиенту необходим IP-адрес, соответствующий серверу с именем srvl. company. com, то клиент отправляет запрос на получение записи А. Сервер DNS обнаруживает запись А в пределах зоны и содержимое записи отправляется в качестве ответа клиенту.
Таким образом, служба DNS используется для обмена записями ресурсов между клиентами и серверами. Главным секретом правильной работы службы DNS является обеспечение обращений клиентов, к правильным серверам DNS и предоставление серверам правильной информации в виде файлов зон.
Авторитетные ответы на запросы
Когда сервер DNS получает запрос о записи ресурса, то технология поиска ответа зависит от того, хранится ли копия файла зоны с такой записью на этом сервере.
Сервер DNS, хранящий у себя копию такого файла зоны, считается авторитетным (authoritative) сёрвером для этой зоны. Поиск ответа на DNS-запрос всегда завершается на сервере DNS, авторитетном для указанного в запросе домена.
Если в запросе указано имя хоста, соответствующее записи ресурса в пределах зоны авторитетности сервера преобразования имен, сервер выполняет авторитетный поиск (authoritative lookup). Рассмотрим последовательность действий при таком поиске.
Если сервер обнаруживает необходимую запись в файле зоны, содержимое записи отправляется в ответе клиенту.
Если поиск для этой записи выполнялся недавно, сервер выдает клиенту кэшированную копию записи. Эта операция выполняется значительно быстрее, чем поиск записи на диске.
Если сервер не в состоянии найти запрошенную запись, он возвращает клиенту ответ Record Not Found (Запись не обнаружена).
Неавторитетные ответы на запросы
Если на сервере DNS нет копии файла с данными для запрошенной зоны, существует три варианта обработки запроса.
Отправляется запрос другим серверам, пока запись не будет найдена. Результат запроса выдается клиенту. '
Клиенту отправляется ссылка на сервер преобразования имен уровнем выше, который может хранить копию записи.
Клиенту отправляется кэшированная копия записи, которая была сохранена в результате более ранних запросов.
Все три метода приводят к появлению неавторитетного ответа (non-authoritative reply). Выбор между первым и вторым вариантом зависит от наличия флага search type (тип поиска), установленного в запросе клиента. Флаг может иметь два значения.
Recursive (Рекурсивный). При запросе этого типа сервер DNS должен предоставить от- ■ вет на полученный запрос в любом случае. Если серверу приходится обращаться к другим серверам DNS, он это делает автоматически. Рекурсивный запрос можно сравнить с напутствием спартанских матерей “Со щитом или на щите".
Iterative (Итеративный). При запросе этого типа сервер DNS возвращает ссылку на другой сервер DNS, на котором, возможно, хранится запрошенная запись. В таком случае задача поиска ответа возлагается на клиента, а не на сервер DNS.
Как правило, клиенты DNS устанавливают в запросах флаг рекурсивного запроса, предполагая, что сервер DNS обладает большими возможностями поиска Рекурсивные запросы от тысяч клиентов могут привести к значительной нагрузке на DNS-сервер, поэтому нередко серверы DNS отвечают отказом на рекурсивные запросы. Например, серверы доменов верхнего уровня, принадлежащие компании Verisign, настроены на отказ в рекурсивных запросах. Дополнительная информация об отключении рекурсивных запросов на сервере DNS под управлением Windows Server 2003 приводится ниже, в разделе “Настройка дополнительных параметров DNS-сервера”.
Если провайдер поддерживает сервер преобразования имен, разрешающий рекурсивные запросы, или такой сервер предоставляется другим провайдером, в соответствии с сетевым этикетом перед отправкой рекурсивных запросов стоит спросить разрешения у владельца сервера.
Обычно для поиска ответов на запросы клиентов серверы DNS используют итеративный поиск. Сервер обладает достаточными возможностями для перехода по ссылкам, поэтому нет никакого смысла нагружать серверы более высокого уровня. По умолчанию сервер DNS, работающий под управлением операционной системы Windows Server 2003, будет использовать итеративные запросы. Не предусмотрено ни одного параметра, который бы позволил изменить такой метод поиска ответа.
Списки корневых серверов
Серверы DNS в пределах “соседних” пространств имен могут использовать простой механизм ссылок для поиска в зонах друг друга. Например, сервер DNS в домене branch. region.
company . com, получивший запрос о содержимом записи А для адреса srvl. company. com, может обратиться непосредственно к серверу преобразования имен в корне пространства имен company. com. Для этого DNS-сервер должен знать адреса корневых серверов. Адреса могут предоставляться при настройке параметров сервера преобразования имен.
При получении запроса о записи ресурса, ответ на который хранится на сервере в Интернете (корневые подсказки), DNS-серверу необходимо каким-то образом получить адреса серверов, поддерживающих домены верхнего уровня. Для этого сервер DNS использует специальный файл, который называется root hints. На рис. 5.3 показано содержимое такого файла, хранящегося на DNS-сервере под управлением операционной системы Windows Server 2003.
;S[RVER1 PropeiUes
OtbutLstn' I
Root he» w wd Io tnd eHw OHS wet w toe nelwa*
|196 41 04] [12090107] [192 33412] 112881090] [192 203 230 10] [192 5 5 241] 1192112 36 4] [128 63 2 53] 1192 36148 17] [198 41 0 1 0] 1193 0 14 129] 1198 32 6412] [202 12 27 33]|196 41 04] [12090107] [192 33412] 112881090] [192 203 230 10] [192 5 5 241] 1192112 36 4] [128 63 2 53] 1192 36148 17] [198 41 0 1 0] 1193 0 14 129] 1198 32 6412] [202 12 27 33]Рис. 5.3. Стандартный файл корневых подсказок для сервера DNS, работающего под управлением операционной системы Windows Server 2003Рис. 5.3. Стандартный файл корневых подсказок для сервера DNS, работающего под управлением операционной системы Windows Server 2003sa.root servers net ,b root-servers netc root-servers netd root-servers nete root-servers netf root-servers netg root-servers neth root-servers net(.root-servers netI root-servers netk root-servers netI root-servers netm root-servers net
|196 41 04] [12090107] [192 33412] 112881090] [192 203 230 10] [192 5 5 241] 1192112 36 4] [128 63 2 53] 1192 36148 17] [198 41 0 1 0] 1193 0 14 129] 1198 32 6412] [202 12 27 33]
|196 41 04] [12090107] [192 33412] 112881090] [192 203 230 10] [192 5 5 241] 1192112 36 4] [128 63 2 53] 1192 36148 17] [198 41 0 1 0] 1193 0 14 129] 1198 32 6412] [202 12 27 33]
Рис. 5.3. Стандартный файл корневых подсказок для сервера DNS, работающего под управлением операционной системы Windows Server 2003
Рис. 5.3. Стандартный файл корневых подсказок для сервера DNS, работающего под управлением операционной системы Windows Server 2003
Файл корневых подсказок — это текстовый файл, в котором содержатся имена и IP-адреса серверов DNS, обслуживающих пространство имен доменов верхнего уровня. На DNS-серверах под управлением Windows эта информация хранится в файле cache . dns, в каталоге \windows\System32\DNS. Файл содержит устаревший список серверов верхнего уровня, а не сведения о новых серверах Verisign TLD. Временно ссылки на новые серверы выдает сервер а.root-servers.net.
Клиентские распознаватели DNS
Клиентская служба, которая отвечает за отправку запросов серверам DNS и обработку ответов, называется распознавателем (resolver). В операционной системе Windows распознаватель входит в основной драйвер протокола TCP/IP.
Когда приложение впервые запрашивает имя определенного сервера, распознаватель сначала проверяет содержимое файла Hosts. Если соответствующая запись в файле Hosts отсутствует, запрос направляется серверу DNS.
Как только распознаватель получает ответ на запрос, результат кэшируется в памяти для ускорения ответов на последующие запросы на преобразование того же имени. Сервер DNS также кэширует в памяти результат запроса.
Если результаты преобразования никогда не удалять из кэша, кэш может стать слишком большим. Кроме этого, запись может измениться, но сервер об этом не узнает, если будет ис-
пользовать только содержимое кэша. Для предотвращения подобных проблем для каждой записи ресурса DNS устанавливается значение параметра TIL (Time to Live — время жизни).
Кэширование отрицательных результатов запроса
Начиная с операционной системы Windows 2000, компания Microsoft предоставляет возможность, которая описана в документе RFC 2308, “Negative Caching of DNS Queries”. Эта возможность позволяет клиентам кэшировать отрицательные ответы и тем самым отказываться от отправки повторных запросов серверу, который уже уведомил о невозможности ответа на этот запрос. Ценность кэширования отрицательных ответов хорошо поймут родители двухлетних детей.
К сожалению, кэширование отрицательных ответов может мешать проведению диагностики. Предположим, например, что на DNS-сервере не существует записи для нового сервера. В таком случае возникнут жалобы о невозможности найти новый сервер. Администратор понимает свою ошибку и добавляет запись для сервера. Но даже после этого телефонные звонки от пользователей не прекратятся, поскольку DNS-клиент кэшировал отрицательный ответ сервера и ничего не знает о появлении нового сервера.
Выбор корневых серверов
Файл корневых подсказок содержит адреса нескольких серверов, чтобы локальный сервер DNS мог выбирать самый подходящий. Для этого последовательно проверяется каждый корневой сервер.
При отправке таких запросов DNS-сервер измеряет значение параметра RTT (Round-Trip Time — задержка ответа на запрос). Измерив значение этого параметра для каждого из корневых серверов, локальный сервер выбирает корневой сервер с минимальной задержкой ответа. Предполагается, что домен верхнего уровня с минимальной задержкой ответа является ближайшим.
Если задержка ответа выбранного сервера увеличивается, сервер DNS еще раз проверяет значение параметра RTT для всех серверов и по результатам проверки выбирает новый сервер.
Для удаления отрицательных ответов из кэша локального распознавателя DNS можно воспользоваться утилитой ipconfig. Введите следующую команду: ipconfig /flushdns
К сожалению, эта команда должна вводиться на клиентском компьютере.
Серверы также кэшируют результаты запросов, включая отрицательные ответы. Для очистки кэша на сервере DNS воспользуйтесь утилитой dnscmd. Для этого введите следующую команду: dnscmd /clearcache
Локальный кэш сервера можно очистить и с помощью консоли DNS. Для этого необходимо щелкнуть правой кнопкой мыши на пиктограмме сервера и выбрать из контекстного меню команду Clear Cache (Очистить кэш). После удаления записей из кэша сервер или клиент должен заново заполнить его результатами запросов. На некоторое время это может привести к снижению производительности.
Преобразование имен DNS и преобразование имен NetBIOS
Клиенты под управлением современных операционных систем Windows (Windows Server 2003, Windows XP и Windows 2000) используют преобразование имен NetBIOS для поддержки сетевых служб, основанных на протоколе SMB, например LanMan Workstation и LanMan Server (SMB расшифровывается как Server Message Block — блок сообщений сервера — и является командным языком, который применяется в сетях Windows).
Например, при подключении диска к общему ресурсу на сервере доменное имя сервера в формате UNC преобразовывается в IP-адрес с помощью преобразования имен NetBIOS. Если в имени содержится точка или оно состоит более чем из 16 символов, клиент использует преобразование имен DNS. Для клиента h-типа современная операционная система Windows выполняет поиск преобразования имен NetBIOS в следующем порядке.
Кэш имен NetBIOS
Запрос к службе WINS
Файл Lmho s t s
Широковещательный запрос
Файл Hosts
Запрос к службе DNS
Для приложений на основе Windows Sockets все клиенты под управлением Windows используют преобразование имен DNS (сначала используется файл Hosts, после чего отправляется запрос службе DNS). Современные клиенты под управлением операционной системы Windows используют параллельное преобразование имен NetBIOS, поэтому при несовпадении “плоского" имени в базе данных WINS и иерархического имени в службе DNS могут возникнуть сложные для диагностики проблемы.
Сервер DNS не поддерживает преобразование “плоских” имен. При отправке тестового эхо-пакета на хост с использованием “плоского” имени, например svrl, распознаватель DNS выполняет такую последовательность действий:
Если в имени нет точки и оно состоит менее чем из 16 символов (“плоское” имя), клиент добавляет к имени суффикс DNS, присвоенный компьютеру, и отправляет получившееся имя в запросе DNS-серверу.
Если в имени присутствует точка внутри, но не в конце, распознаватель добавит точку в конец имени и отправит получившееся имя DNS-серверу. Если на запрос будет получен отрицательный ответ, распознаватель добавит к имени суффикс DNS и отправит получившееся имя в запросе DNS-серверу.
Если после добавления суффикса DNS будет получен отрицательный ответ, распознаватель добавит следующий альтернативный DNS-суффикс, заданный для интерфейса.
Если добавление второго суффикса также приводит к отрицательному ответу, распознаватель отказывается от дальнейших попыток преобразовать имя в 1Р-адрес.
Обработка DNS-запросов
Перед созданием системы преобразования имен (или изменения правильно функционирующей системы) важно четко представлять, как обрабатываются DNS-запросы. В этом разделе приводится пошаговое описание обработки DNS-запросов. Существует несколько вариантов такой обработки.
Запрос обрабатывается на авторитетном сервере
Запрос обрабатывается на неавторитетном сервере
Запрос обратного преобразования
Зная технологию обработки DNS-запросов, легче проектировать систему DNS и проще интегрировать службы преобразования имен Windows Server 2003 в существующую DNS- инфраструктуру.
Обработка запроса на авторитетном сервере
Предположим, что пользователь компьютера под управлением операционной системы Windows Server 2003 в домене company. com отправляет ping-запрос на сервер srvl. В процедуре 5.1 рассматривается последовательность событий с точки зрения сервера DNS.
Процедура 5.1. Обработка запроса авторитетным сервером преобразования имен
Для создания ICMP-пакета драйверу tcpip. sys необходим IP-адрес сервера srvl. Для получения этого адреса драйвер tcpip. sys использует внутренний распознаватель DNS. Далее по тексту распознаватель описывается как отдельная служба.
Распознаватель отправляет запрос DNS-серверу. В запросе содержится следующая информация.
Полностью определенное DNS-имя компьютера-получателя (в этом случае — имя srvl. company . com).
Тип запрашиваемой записи ресурса (в данном случае выполняется простое преобразование имени узла, поэтому запрашивается запись типа А).
Запрошенный класс записи ресурса. Практически всегда это класс IN (Internet). Другие классы на практике используются очень редко.
Содержимое пакетов DNS
Просмотр содержимого DNS-пакета полезен в познавательных целях. Служба Network Monitor, которая входит в состав операционной системы Windows Server 2003, является отличным средством перехвата и просмотра пакетов, передаваемых в локальной сети. На рис. 5.4 показан результат перехвата пакета, в котором содержится отправленный авторитетным DNS-сервером ответ на запрос преобразования имени узла (запись А). Рассмотрим основные элементы этого пакета.
urosofi ^?twurk Monitor [CaphH-e: I (Det<u()|urosofi ^?twurk Monitor [CaphH-e: I (Det<u()|№№.JjQlxj jdfljxl.JjQlxj jdfljxl1 glfit ±ЖЛ в| @|=Я<У ±|±1 у® йМ 512J!*■* Г «ее| вге ме **• I •* ем 4М1 I П*|Ы I ее«г1»еив1 glfit ±ЖЛ в| @|=Я<У ±|±1 у® йМ 512J!*■* Г «ее| вге ме **• I •* ем 4М1 I П*|Ы I ее«г1»еивu • ^iwm: w» ?11.. . .u • ^iwm: w» ?11.. . .QMD:*td фру 1кф> te* »e«v«tl.«i*el*l*ry.cQMD:*td фру 1кф> te* »e«v«tl.«i*el*l*ry.c33BI 1TMRBIT: IType - Internet IP (IPv4)® IP: Protocol ■ UDP - User Detagran; Packet ID ■ 13884; Total IP Length = 84; Options = Bo OptionsBI 1TMRBIT: IType - Internet IP (IPv4)® IP: Protocol ■ UDP - User Detagran; Packet ID ■ 13884; Total IP Length = 84; Options = Bo OptionsS UDP: Src Port; Donain Важе Server (S3); Dst Port: Unknown (1473); Length ■ 64 (0x40)внеееяаемвяввиеийнвеневнеянииеяияS UDP: Src Port; Donain Важе Server (S3); Dst Port: Unknown (1473); Length ■ 64 (0x40)внеееяаемвяввиеийнвеневнеянииеяияDBS:DBS:Query Identifier ■ 141 (GxBD)Query Identifier ■ 141 (GxBD)■■S DBS: DBS Hags ■ Response, OpCode - Std Qry, AA RD RA Bits Set, RCode - BoS DBS: DBS Hags ■ Response, OpCode - Std Qry, AA RD RA Bits Set, RCode - BoDM:DM:Question Intry Count ■ 1 <0xl)Question Intry Count ■ 1 <0xl)DBS: Answer Intry Count • 1 (0x1)DBS: Answer Intry Count • 1 (0x1)DBS:DBS:DBS:DBS:Веже Server Count ■ 0 (0x0) Additional Records Count ■ 0 (0x0)Веже Server Count ■ 0 (0x0) Additional Records Count ■ 0 (0x0)Q-DBS: Question Section: serveri. subsidiary, сож. of type Host Addr on class IHIT addr. DBS: Question Bene: serveri. subsidiary, con.Q-DBS: Question Section: serveri. subsidiary, сож. of type Host Addr on class IHIT addr. DBS: Question Bene: serveri. subsidiary, con.I DBS:DBS:I DBS:DBS:Question Type ■ Host AddressQuestion Class ■ Internet ad<Question Type ■ Host AddressQuestion Class ■ Internet ad<S-DB8: Answer section: serveri. subsidiary.con. of type Host Addr on class IB1T addr.S-DB8: Answer section: serveri. subsidiary.con. of type Host Addr on class IB1T addr.?:DBS: i DBS: j DM: •DBS: i DBS: •DBS:?:DBS: i DBS: j DM: •DBS: i DBS: •DBS:Resource Важе: server1.subsidiary,еож. Resource Туре ■ Host Address Resource Class ■ Internet address class Tino To Live • 3600 (0x110) Resource Data Length ■ 4 (0x4) IP address ■ 192.168.0.1Resource Важе: server1.subsidiary,еож. Resource Туре ■ Host Address Resource Class ■ Internet address class Tino To Live • 3600 (0x110) Resource Data Length ■ 4 (0x4) IP address ■ 192.168.0.1K№«M*)K№«M*)РЖ6Л> V.РЖ6Л> V.
urosofi ^?twurk Monitor [CaphH-e: I (Det<u()|
urosofi ^?twurk Monitor [CaphH-e: I (Det<u()|
№
№
.JjQlxj jdfljxl
.JjQlxj jdfljxl
1 glfit ±ЖЛ в| @|=Я<У ±|±1 у® йМ 512J!*■* Г «ее| вге ме **• I •* ем 4М1 I П*|Ы I ее«г1»еив
1 glfit ±ЖЛ в| @|=Я<У ±|±1 у® йМ 512J!*■* Г «ее| вге ме **• I •* ем 4М1 I П*|Ы I ее«г1»еив
u • ^iwm: w» ?
11.. . .
u • ^iwm: w» ?
11.. . .
QMD:*td фру 1кф> te* »e«v«tl.«i*el*l*ry.c
QMD:*td фру 1кф> te* »e«v«tl.«i*el*l*ry.c
3
3
BI 1TMRBIT: IType - Internet IP (IPv4)
® IP: Protocol ■ UDP - User Detagran; Packet ID ■ 13884; Total IP Length = 84; Options = Bo Options
BI 1TMRBIT: IType - Internet IP (IPv4)
® IP: Protocol ■ UDP - User Detagran; Packet ID ■ 13884; Total IP Length = 84; Options = Bo Options
S UDP: Src Port; Donain Важе Server (S3); Dst Port: Unknown (1473); Length ■ 64 (0x40)
внеееяаемвяввиеийнвеневнеянииеяия
S UDP: Src Port; Donain Важе Server (S3); Dst Port: Unknown (1473); Length ■ 64 (0x40)
внеееяаемвяввиеийнвеневнеянииеяия
DBS:
DBS:
Query Identifier ■ 141 (GxBD)
Query Identifier ■ 141 (GxBD)
■
■
S DBS: DBS Hags ■ Response, OpCode - Std Qry, AA RD RA Bits Set, RCode - Bo
S DBS: DBS Hags ■ Response, OpCode - Std Qry, AA RD RA Bits Set, RCode - Bo
DM:
DM:
Question Intry Count ■ 1 <0xl)
Question Intry Count ■ 1 <0xl)
DBS: Answer Intry Count • 1 (0x1)
DBS: Answer Intry Count • 1 (0x1)
DBS:
DBS:
DBS:
DBS:
Веже Server Count ■ 0 (0x0) Additional Records Count ■ 0 (0x0)
Веже Server Count ■ 0 (0x0) Additional Records Count ■ 0 (0x0)
Q-DBS: Question Section: serveri. subsidiary, сож. of type Host Addr on class IHIT addr. DBS: Question Bene: serveri. subsidiary, con.
Q-DBS: Question Section: serveri. subsidiary, сож. of type Host Addr on class IHIT addr. DBS: Question Bene: serveri. subsidiary, con.
I DBS:
DBS:
I DBS:
DBS:
Question Type ■ Host Address
Question Class ■ Internet ad<
Question Type ■ Host Address
Question Class ■ Internet ad<
S-DB8: Answer section: serveri. subsidiary.con. of type Host Addr on class IB1T addr.
S-DB8: Answer section: serveri. subsidiary.con. of type Host Addr on class IB1T addr.
?:DBS: i DBS: j DM: •DBS: i DBS: •DBS:
?:DBS: i DBS: j DM: •DBS: i DBS: •DBS:
Resource Важе: server1.subsidiary,еож. Resource Туре ■ Host Address Resource Class ■ Internet address class Tino To Live • 3600 (0x110) Resource Data Length ■ 4 (0x4) IP address ■ 192.168.0.1
Resource Важе: server1.subsidiary,еож. Resource Туре ■ Host Address Resource Class ■ Internet address class Tino To Live • 3600 (0x110) Resource Data Length ■ 4 (0x4) IP address ■ 192.168.0.1
K№«M*)
K№«M*)
РЖ6Л> V.
РЖ6Л> V.
Puc. 5.4. В перехваченном пакете содержится ответ на запрос клиента DNS
Раздел UDP. Указывает, что для DNS-запроса используется UDP-порт 53. Это стандартный порт службы DNS.
Флаги DNS. Сервер указывает, что он является авторитетным для домена. Сервер поддерживает рекурсивные запросы, и ответ не является ошибочным.
Раздел DNS-запроса. Этот раздел содержит копию оригинального DNS-запроса на преобразование имени de01. company. com.
Раздел DNS-ответа. Ответ содержит информацию о записи типа А для имени de01. company. com, включая IP-адрес и принятое по умолчанию значение TTL из записи SOA.
Если DNS-сервер установлен за брандмауэром и необходимо отправлять запросы на сервер верхнего уровня или другой общедоступный сервер преобразования имен, на брандмауэре придется открыть UDP-порт 53 или настроить сервер DNS для поддержки службы Network Address Translation (NAT) или proxy-сервера для доступа к Интернет. В операционной системе Windows Server DNS-сервер отвечает через тот же интерфейс, на который пришел запрос на преобразование имени, поэтому открытого UDP-порта 53 достаточно для обеспечения прохождения запросов и ответов DNS.
Получив запрос, сервер DNS разбирает имя узла для выделения домена DNS, company. com. В данном случае DNS-сервер является авторитетным для запрошенной зоны, поэтому поиск запрошенной записи ресурса выполняется в зоне.
После нахождения записи А для узла srvl сервер отправляет все содержимое записи клиенту в формате DNS Query Response. Если для записи типа А не указано значение TTL, сервер вставляет минимальное значение TTL из записи SOA для данной зоны. По умолчанию присваивается для параметра TTL задается значение, равное одному часу или 3600 секундам.
Если сервер DNS не может найти запрошенную запись, он возвращает ответ Record Not Found (запись не обнаружена). Авторитетный DNS-сервер не обращается к другим серверам DNS, если запись не найдена в поддерживаемой им зоне (хотя, судя по запросу, она там должна быть). Если распознаватель получает от авторитетного сервера ответ Record Not Found, приложению возвращается ошибка без последующих попыток преобразования имени.
После того как распознаватель получил IP-адрес, драйверу tepip. sys остается сделать еще кое-что. На основе полученного адреса из записи типа А драйвер создает 1Р-пакет. С помощью протокола ARP (Address Resolution Protocol — протокол преобразования адресов) драйвер получает МАС-адрес, соответствующий этому IP-адресу. После этого пакет и МАС-адрес передаются драйверу NDIS (Network Driver Interface Specification), который взаимодействует с драйвером адаптера для создания кадра передачи, отправляемого серверу-получателю.
Кроме этого, драйвер tepip. sys передает запись А службе DNS Resolver Cache. Кэш распознавателя сохраняет запись А в течение периода, указанного в поле значения TTL.
Обработка запроса на неавторитетном сервере
Рассмотрим ситуацию, когда пользователь вместо доступа к файлу на внутреннем сервере пытается получить доступ к файлу во внешней сети, например в Интернет. Например, пользователь вводит в окне браузера адрес www. roswelInm. org. В данном случае пропустим уровень 7 стека протоколов OSI и рассмотрим непосредственно DNS-запрос (процедура 5.2).
Процедура 5.2. Обработка запроса на неавторитетном сервере
Распознаватель DNS отправляет рекурсивный запрос собственному серверу DNS на получение записи А для имени www.roswellnm.org. Рекурсивный запрос указывает серверу DNS на необходимость самостоятельного преобразования адреса.
Локальный сервер DNS в домене company. com не содержит файла зоны для домена roswellnm. org. Рекурсивный запрос означает, что запрос должен быть передан другому DNS-серверу, но какому? Именно в этой ситуации пригодится список корневых серверов, содержащийся в файле cache . dns.
После запроса адреса корневого сервера DNS-сервер отправляет итеративный запрос к серверу верхнего уровня, который можно представить в следующем виде: “Предоставьте запись А для домена www.roswellnm.org или адрес сервера, который обладает этой информацией”.
Скорее всего, сервер верхнего уровня не знает адреса, соответствующего имени www. roswellnm.org. Но сервер верхнего уровня является авторитетным для домена .org. Это значит, что у него есть запись NS, указывающая на сервер преобразования имен, авторитетный для зоны в домене .org.
Корневой сервер просматривает записи NS и находит несколько серверов преобразования имен, которые обслуживают домен roswellnm. org. Корневой сервер отправляет в ответ копию записей NS и А для каждого из этих серверов. Вот пример такой записи: dnsl. interland.net с IP-адресом 64.224.20.132.
Конкретные имена
Те читатели, кому интересно, откуда у автора конкретные имена и адреса для этого примера, могут обратиться к разделу "Просмотр зон с помощью утилиты nslookup" далее в этой главе.
После этого сервер DNS в домене company. com отправляет итеративный запрос к серверу dnsl. interland.net на получение записи А для узла www.roswellnm.org. Распознаватель на клиенте по-прежнему ожидает ответа на свой оригинальный запрос.
Служба DNS на узле dnsl. interland.net является авторитетной для домена roswellnm. org. Она выполняет поиск в файле зоны и находит запись А для хоста www. В записи а указан IP-адрес 209.3 5.62.148.,
После получения в ответе записи А для узла www.roswellnm.org сервер DNS в домене company. com передает этот ответ клиенту, который отправил первоначальный запрос. Кроме этого, копия ответа сохраняется в кэше на случай получения такого же запроса от другого клиента. Время хранения записи в кэше определяется значением параметра TTL, указанным для записи А.
Главное — запомнить, что неавторитетный сервер использует файл с адресами корневых серверов для определения имени и IP-адреса подходящего корневого сервера. Без этого файла или сервера, которому можно передать запрос, выполнение запроса завершилось бы неудачно.
Запросы обратного преобразования
Стандартная зона DNS называется зоной прямого преобразования (forward lookup zone) или прямой зоной, поскольку поиск выполняется по имени записи, пока не будет найден интересующий IP-адрес или не достигнут конец файла зоны. Но что если пользователь знает IP- адрес и хочет определить имя соответствующего хоста? Пример такого преобразования можно наблюдать при использовании команды ping с параметром -а. При этом должно отображаться имя хоста, которому отправляется ICMP-пакет Echo Reply, как показано ниже.
E:\>ping -a 10.1.1.254
Pinging router.company.com [10.1.1.254] with 32 bytes of data:
Reply from 10.1.1.254: bytes=32 timeclOms TTL=128
Это выглядит достаточно просто, но иногда такое преобразование становится сложной задачей. Зоны прямого преобразования DNS структурированы по именам хостов, а не по IP-адресам. Поиск имени хоста на основе IP-адреса при помощи зон прямого преобразования потребовал бы исключительно накладного поиска среди миллионов зон, хранящихся на DNS- серверах по всему миру.
Служба DNS избегает возникновения таких ситуаций с помощью специального отдельного файла зоны, который структурирован по IP-адресам. Такой файл называется зоной обратного преобразования или обратной зоной (reverse lookup zone). На рис. 5.5 показан пример обратной зоны. Содержимое этой зоны отображено на консоли DNS в операционной системе Windows Server 2003.
гавтявшвяжгавтявшвяжlookup ?ош*< 192 1БС.О.М Subnnt]lookup ?ош*< 192 1БС.О.М Subnnt]
гавтявшвяж
гавтявшвяж
lookup ?ош*< 192 1БС.О.М Subnnt]
lookup ?ош*< 192 1БС.О.М Subnnt]
' -: SERVERIЯ uJ Forward Lookup Zones1 ® ^ company.comВ ^ subsidary.com :® О _msdcs' -: SERVERIЯ uJ Forward Lookup Zones1 ® ^ company.comВ ^ subsidary.com :® О _msdcsI (same as parent folder) (same as parent folder) (same as parent folder) 192.168.0.1 192.168.0.60I (same as parent folder) (same as parent folder) (same as parent folder) 192.168.0.1 192.168.0.60Start of Authority (SOA)Name Server (NS) Name Server (NS) Pointer (PTR) • Pointer (PTR)Start of Authority (SOA)Name Server (NS) Name Server (NS) Pointer (PTR) • Pointer (PTR)[5], serverl.whdomah.net.... serveri .windomah.net.serveri .subskSary.com.serverl.parent.com. parent.com.[5], serverl.whdomah.net.... serveri .windomah.net.serveri .subskSary.com.serverl.parent.com. parent.com.
' -: SERVERI
Я uJ Forward Lookup Zones
1 ® ^ company.com
В ^ subsidary.com :® О _msdcs
' -: SERVERI
Я uJ Forward Lookup Zones
1 ® ^ company.com
В ^ subsidary.com :® О _msdcs
I (same as parent folder) (same as parent folder) (same as parent folder) 192.168.0.1 192.168.0.60
I (same as parent folder) (same as parent folder) (same as parent folder) 192.168.0.1 192.168.0.60
Start of Authority (SOA)
Name Server (NS) Name Server (NS) Pointer (PTR) • Pointer (PTR)
Start of Authority (SOA)
Name Server (NS) Name Server (NS) Pointer (PTR) • Pointer (PTR)
[5], serverl.whdomah.net.... serveri .windomah.net.
serveri .subskSary.com.
serverl.parent.com. parent.com.
[5], serverl.whdomah.net.... serveri .windomah.net.
serveri .subskSary.com.
serverl.parent.com. parent.com.
• SI йр europe
S £3 Reverse Lookup Zones
® {ЕЙ Event Viewer
Г
Puc. 55. Консоль DNS, на которой отображается содержимое зоны обратного преобразования
Структура зоны обратного преобразования
Зона обратного преобразования основана на специальных записях PTR. В записи PTR содержатся октеты идентификатора узла в обратном порядке. В следующем листинге показан пример записей обратной зоны для сети 10.1.0.0.
; Database file 1.10.in-addr.arpa.dns for 1.10.in-addr.arpa zone.
; Zone version: 8
; Zone records
PTRdcOl
21.1PTRsrvl2
PTRrouterOl■
Обратите внимание, что адрес сети 10.1.0.0 указан в обратном порядке, что выглядит как 1.10. Для сети с адресом 222.100.93.0 начало имени зоны выглядело бы как 93.100.222.
Такая обратная запись необходима из-за того, что в десятично-точечной записи адреса IP самый старший октет находится слева, а в записи имен DNS самое старшее поле находится справа. В соответствии с записью имен DNS, если представить инвертированный IP-адрес в виде непрерывного дерева, это дерево состояло бы из 255 корневых доменов, 255 отдельных основных серверов имен, по одному для каждого из 255 доступных адресов в первом октете десятично-точечной записи IP-адреса.
На вершине пространства имен обратного преобразования должен находиться корневой домен, поэтому организация Advanced Research Project Administration (ARPA), которая управляла Интернетом во время создания службы DNS, создала искусственный корневой домен in-addr. агра. При наличии корневого домена in-addr. агра единственный сервер верхнего уровня может хранить всю обратную зону с 255 узлами на втором уровне. Это незначительное число по сравнению с миллионами узлов в домене . сот.
Это значит, что администратор DNS должен создавать зону обратного преобразования в домене in-addr. агра для каждой сети IP, используемой в организации. Имя каждой обратной зоны будет начинаться с инвертированного идентификатора сети, после которого указывается суффикс in-addr.агра. Например, для сети 209.12.73.0 обратная зона будет иметь адрес 73.12.209. in-addr. агра. Обычно в качестве первичного сервера обратной зоны используется первичный сервер корневого домена организации.
Процесс обратного преобразования
В процедуре 5.3 рассмотрена обработка DNS-сервером запроса обратного преобразования. Предположим, что пользователь в домене company.com на компьютере с адресом 10.1.0.0 использует команду ping -а для определения имени хоста, IP-адрес которого - 209 .12 .73 . 4.
Процедура 5.3. Обработка запроса обратного преобразования
Распознаватель отправляет запрос обратного преобразования адреса 4.73.12.209. in-addr. агра DNS-серверу. Такой запрос называется DNP-запросом (Domain Name Pointer — указатель имени домена).
Сервер DNS не является авторитетным для зоны 73.12.209. in-addr. агра, поэтому запрос перенаправляется одному из корневых серверов.
Корневой сервер не имеет файла зоны для адреса 73.12.209. in-addr. агра, но он хранит запись NS для сервера имен, который содержит зону для домена 2 09. in-addr. агра.
В ответе корневого сервера содержится ссылка на соответствующий сервер имен с информацией записей NS и А.
После этого DNS-сервер домена company. com отправляет PTR-запрос серверу имен, адрес которого получен от корневого сервера. На этом сервере нет файла зоны для домена 73.12.209. in-addr. агра, но он возвращает записи № и А с информацией о сервере преобразования имен, который хранит зону 12.209. in-addr. агра.
После этого DNS-сервер домена company. com отправляет PTR-запрос серверу преобразования имен, адрес которого указан в записях NS и А. Этот сервер содержит файл зоны для домена 73.12.209. in-addr. агра. Файл зоны возвращает содержимое записи PTR для узла 4, а также соответствующую запись А, которая содержит имя узла: www. newmexico. com.
Многие администраторы DNS-серверов не создают зоны обратного преобразования, предполагая, что они используются не настолько часто, чтобы тратить время на их создание. Желательно всегда создавать зоны обратного преобразования, чтобы иметь все доступные инструменты службы DNS.
Проектирование доменов DNS
После того как мы рассмотрели компоненты службы DNS и принципы их работы, можно приступать к созданию собственной системы DNS. Как и для всех служб в распределенных сетях, главными целями при проектировании являются постоянная доступность, высокая произ-
водительность, минимальный объем передаваемых по внешним каналам данных, высокий уровень безопасности и минимальное участие в обслуживании административного персонала.
Мы уже рассказывали, где устанавливать основные и вторичные DNS-серверы для достижения отказоустойчивости. В этом разделе рассматриваются дополнительные возможности DNS.
Репликация зон
Использование внешних серверов (перенаправителей)
Развертывание в пределах существующей инфраструктуры DNS
Перенаправление запросов WINS
Динамическое обновление зон
Автоматизированная сборка мусора
Интеграция с Active Directory
Безопасные обновления DNS
Каждая из возможностей будет рассматриваться с точки зрения ее интеграции в архитектуру. Затем изучается настройка конкретной функции с помощью консоли DNS Management.
Репликация зон
Вторичный сервер преобразования имен получает копию файла зоны от первичного сервера имен или другого вторичного сервера. Для этого используется механизм переноса зоны (zone transfer).
Согласно классическому механизму переноса зоны DNS вторичный сервер опрашивает первичный сервер через регулярные промежутки времени и копирует весь файл зоны при наличии изменений. Этот метод обладает рядом недостатков. Во-первых, выполнение регулярных опросов снижает пропускную способность сети. Во-вторых, копирование всего файла зоны требует ненужных затрат пропускной способности и процессорного времени.
В операционных системах Windows 2000 и Windows Server 2003 реализовано два механизма, стандартизированных в документах RFC: уведомление об изменениях (update notification) и частичный перенос зоны (incremental zone transfer). Эти механизмы предназначены для улучшения традиционного механизма репликации DNS. Кроме этого, информация о зонах может храниться в базе данных Active Directory, вообще избавляя от необходимости использовать отдельный механизм репликации.
Уведомление об изменениях'
В стандартном механизме переноса зоны вторичный сервер преобразования имен периодически опрашивает первичный сервер, проверяя наличие изменений. Интервал опроса определяется параметром Refresh interval (Период обновления), который устанавливается в записи SOA (Start of Authority). На рис. 5.6 показан пример записи SOA.
Когда интервал обновления истекает, вторичный сервер запрашивает у первичного копию записи SOA. В этой записи указан порядковый номер, который увеличивается при каждом изменении данных зоны. Если порядковый номер в записи SOA, хранящийся на вторичном сервере, меньше порядкового номера, хранящегося в записи SOA на первичном сервере, вторичный сервер начинает перенос зоны.
В операционных системах Windows 2000 и Windows Server 2003 в службе DNS реализованы возможности, описанные в документе RFC 1996, “A Mechanism for Prompt Notification of Zone Changes” (“Механизм уведомлений об изменении зоны для вторичных серверов”). Этот документ описывает новый код DNS (команда, воспринимаемая как серверами, так и клиентами DNS), который называется DNS Notify. Принцип действия этой команды рассматривается в процедуре 5.4.
Jtl-SJJtl-SJTTLforlbietwsoed: |6’ 0 0 PDDQD.HHMM.SS)TTLforlbietwsoed: |6’ 0 0 PDDQD.HHMM.SS)| OK I Cencel I N*| OK I Cencel I N*Puc. 5.6. Окно Zone Properties (Свойства зоны), в котором открыта вкладка Start of Authority (SOA). Параметр Refresh interval (Период обновления) определяет интервал между операциями переноса зоныPuc. 5.6. Окно Zone Properties (Свойства зоны), в котором открыта вкладка Start of Authority (SOA). Параметр Refresh interval (Период обновления) определяет интервал между операциями переноса зоны
Jtl-SJ
Jtl-SJ
TTLforlbietwsoed: |6’ 0 0 PDDQD.HHMM.SS)
TTLforlbietwsoed: |6’ 0 0 PDDQD.HHMM.SS)
| OK I Cencel I N*
| OK I Cencel I N*
Puc. 5.6. Окно Zone Properties (Свойства зоны), в котором открыта вкладка Start of Authority (SOA). Параметр Refresh interval (Период обновления) определяет интервал между операциями переноса зоны
Puc. 5.6. Окно Zone Properties (Свойства зоны), в котором открыта вкладка Start of Authority (SOA). Параметр Refresh interval (Период обновления) определяет интервал между операциями переноса зоны
company.com Properties
Senerd SW a AU^t^j Mime Sever | WINS |1Я№Т«*1е-.|
Seel number
p" "Increment |
Pifrwy server< '*
- iservefl. conpany.com.SrQWM. |
fleepomtie perron pdmrusb^^
Refresh rterwt ^p5 [minutes 3
Retiyriwv*|10j minutes3
Ечмм#«[Г*[days3
MnmumfdelajyTTL:[1jhouis 3
Процедура 5.4. Выполнение стандартного переноса зоны по методу опроса
При обновлении зоны на первичном DNS-сервере этот сервер отправляет сообщение DNS Notify вторичному серверу имен. Первичный сервер должен знать IP-адреса вторичных серверов или вторичные серверы должны быть перечислены на вкладке Name Servers (Серверы имен).
Вторичные серверы отвечают на запрос DNS Notify, отправляя стандартный запрос на обновление записи SOA.
С этого момента передача зоны выполняется традиционным способом.
Отличия в механизме уведомлений по сравнению с Windows NT 4.0
В операционной системе Windows NT 4.0 службой DN5 поддерживалась операция DNS Notify, но администратор должен был вручную отправлять уведомления с помощью команды Update Server Data File (Обновить файл данных DNS-сервера) меню Properties (Свойства) соответствующей зоны. Это было необходимо, поскольку служба DNS на серверах под управлением Windows NT 4.0 использовала стандартный механизм переноса зоны с копированием всего файла зоны.
Операционные системы Windows Server 2003 и Windows 2000 поддерживают частичный перенос зоны, поэтому уведомления рассылаются автоматически и копируются, как только вторичный сервер в состоянии их принять.
Частичный перенос зоны
Стандартный перенос зоны DNS предполагает копирование всего файла зоны с первичного сервера имен на вторичные, а также между вторичными серверами в пределах иерархической структуры. Операционные системы Windows Server 2003 и Windows 2000 позволяют отказаться от копирования всего файла зоны. Для этого используется возможность, описанная в документе RFC 1995, “Incremental Zone Transfer in DNS” (“Частичный перенос зоны DNS”).
При частичном переносе зоны вторичный сервер предоставляет порядковый номер своей копии записи SOA. Первичный сервер отправляет только те обновления, для которых указан больший порядковый номер.
Если первичный сервер имен не поддерживает частичного переноса зоны, то вторичный сервер под управлением Windows Server 2003 или Windows 2000 возвращается к методу копирования всего файла зоны.
Интеграция в Active Directory
Кроме описанных ранее методов переноса зоны, определенных в соответствующих документах RFC, служба DNS из состава операционной системы Windows Server 2003 поддерживает интеграцию DNS-зоны в Active Directory. Это позволяет отказаться от обычных методов переноса зоны, поскольку репликация базы данных Active Directory выполняется собственными средствами этой службы.
К тому же интеграция в Active Directory позволяет обновлять зону на каждом контроллере домена Windows Server 2003 или Windows 2000, на котором запущена служба DNS.
Служба DNS не потребляет много ресурсов, поэтому ее можно устанавливать на каждый контроллер домена. С точки зрения производительности, использования пропускной способности и управления интеграция службы DNS в базу данных Active Directory достаточно выгодна. Но такая интеграция имеет несколько скрытых недостатков.
Не поддерживаются текстовые файлы зон. Записи ресурсов хранятся в базе данных Active Directory в виде объектов. Если необходимо использовать текстовые файлы в качестве резервных, создайте как минимум один стандартный вторичный сервер преобразования имен. Служба DNS под управлением Windows Server 2003 или Windows 2000 будет предоставлять обновления зон вторичному серверу, а вторичный сервер будет сохранять обновления в обычном текстовом файле.
Зависимость от работоспособности Active Directory. Для обнаружения контроллеров домена клиентам необходима работающая служба DNS. Поддержка службы DNS на тех же серверах, где хранится база Active Directory, означает отказ сразу нескольких служб в случае неработоспособности или недоступности сервера. Указав в параметрах TCP/IP на клиенте как минимум два сервера DNS, можно снизить вероятность такой проблемы. Кроме этого, не забывайте, что контроллер домена тоже является клиентом DNS. Для преобразования имен контроллер домена должен обращаться к самому себе.
Сервер DNS под управлением операционной системы Windows должен быть первичным сервером имен. Это может вызвать недовольство администраторов, которые в качестве первичных часто используют DNS-серверы под управлением операционных систем UNIX и NetWare и не желают переходить на платформу Windows.
Перенаправление запросов
Если сервер DNS получает запрос для преобразования имени в другой зоне и это имя отсутствует в кэше, сервер находит корневой сервер, а затем с помощью ряда итеративных запросов находит сервер, на котором хранится интересующая запись. Этот процесс подробно рассматривался в разделе “Обработка DNS-запросов" в этой главе.
Этой длительной процедуре существует альтернатива — можно обратиться к серверу, который уже провел эту процедуру. Этот процесс называется перенаправлением запроса (forwarding). Для этого DNS-серверу необходимо указать адрес переадресующего сервера (forwarder). На рис. 5.7 показан пример конфигурации DNS, в которой используются пере- адресующие серверы.
В данной ситуации (см. рис. 5.7) основной сервер настроен на использование переадресующего сервера в двух случаях.
■StRVER.1 Properties■StRVER.1 Properties^ Jiti^ Jiti
■StRVER.1 Properties
■StRVER.1 Properties
^ Jiti
^ Jiti
Когда сервер получает запрос на преобразование имени узла в домене subsidiary. com, запрос перенаправляется на какой-либо DNS-сервер домена subsidiary. com. Такой метод называют перенаправлением по условию (conditional forwarding), что является новой функцией в операционной системе Windows Server 2003.
Когда сервер получает запрос на преобразование имен за пределами собственной зоны и вне пределов домена subsidiary. com, запросы перенаправляются на сервер имен, который поддерживается провайдером.
Если во втором случае на первичном сервере сохранены адреса корневых серверов, то после отправки запроса переадресующему серверу и небольшого периода ожидания первичный сервер начинает итеративное преобразование имен. При этом высока вероятность, что переадресующий сервер ответит раньше, чем закончится итеративное преобразование имен.
Сервер, настроенный на использование переадресующих серверов для преобразования всех имен, не входящих в локальный домен, называется подчиненным (slave). Подчиненный сервер полностью полагается на переадресующий сервер. Если переадресующий сервер не в состоянии найти соответствующую запись, подчиненный сервер отправляет клиенту ответ No Record. В операционных системах Windows Server 2003 и Windows 2000 для использования службы DNS в режиме подчиненного сервера необходимо установить флажок Do Not Use Recursion for This Domain (He использовать рекурсию для этого домена) на вкладке Forwarders (Переадресация) в окне свойств сервера.
Перенаправление по условию
В операционной системе Windows Server 2003 предоставлена новая возможность, которая упрощает интеграцию службы DNS с серверами преобразования имен в других доменах. Вместо того чтобы указывать один сервер в качестве переадресующего, можно указать несколько переадресующих серверов для различных доменов. Такую настройку можно выполнить с помощью консоли DNS, изменив свойства сервера (рис. 5.8).
Рассмотрим пример использования перенаправления запросов по условию. Предположим, что подключение к внешней сети провайдера применяется для совместного использования базы данных и обмена файлами. Доменное имя сети провайдера — vendor. com. Сервер
DNS в домене vendor. com имеет IP-адрес 192.168.0.30. Ваши клиенты получают доступ к этому серверу для отправки DNS-запросов.
ПЗЕВШЖ^
DetjugLogs^ng I EwdLoggng | MantangInterfaces Fawauiets | Advanced | float Hr#
FotaKltwwraMatMcaaiMttaONStMiiMnoiarMMiadlvIhe W№ F«wed «aanfat naw n Iha foloweig DNS domre
I
Al othai DNS domainsNaw... |
Hwotwe | I
rAd^N»***itaeDNSdii*MW^«***«IPed*w below. wd»W of» Add
Pizc. 5.8. Параметры DNS-сервера, настроенного на перенаправление запросов по условию
Операционная система Windows 2000 и корневые зоны
Некоторые администраторы столкнулись со сложностями при настройке переадресующих DNS-серверов и корневых серверов (root hints) в операционной системе Windows 2000. В Windows 2000 новый DNS-сервер автоматически настраивался для работы в качестве корневого сервера, который обозначается точкой в начале имени. Это означает, что сервер находится на вершине пространства имен DNS и все поддерживаемые им домены являются доменами верхнего уровня. ■
Конечно, это абсурдно. Ни один частный сервер DNS не может быть сервером верхнего уровня. Он может являться корневым для собственного домена. Но пока существует корневая зона, сервер под управлением Windows не может использоваться как нормальный сервер DNS, не являющийся самым главным сервером в пространстве доменных имен. Это значит, что сервер откажется использовать адреса корневых серверов и не сможет быть настроен на использование переадресующих серверов.
Это "свойство" операционной системы Windows 2000 заставляло администраторов удалять корневую зону, чтобы правильно настроить инфраструктуру DNS. В операционной системе Windows Server 2003 корневая зона по умолчанию не устанавливается.
На сервере DNS можно настроить перенаправление запросов по условию, например, чтобы все запросы на преобразования имен в домене vendor. com отправлялись на сервер 192.168.0.30. Сервер DNS отправляет итеративные запросы указанному серверу DNS и передает ответы клиентам.
Зоны-заглушки
Операционная система Windows Server 2003 поддерживает специальный тип зон, который называется зона-заглушка (stub zone). Такая зона обеспечивает делегирование записей, когда сервер DNS родительской зоны отправляет ссылку на делегированные DNS-серверы в дочер-
нем домене. Дополнительную информацию по этой теме можно получить ниже, в разделе “Настройка делегирования".•
На серверах зоны-заглушки хранятся только записи SOA и NS (Name Server) для дочерней зоны, а также записи А, соответствующие серверам преобразования имен в дочернем домене (эти записи типа А необходимы для функционирования соответствующей NS-записи и называются glue records — связующие записи). Сервер зоны-заглушки периодически обновляет собственную копию записей ресурсов. Это значительно упрощает управление делегированием.
Предположим, вы — администратор зоны company.com. Зону branch.company.com необходимо делегировать другому DNS-серверу, который управляется другим администратором.
Обычно для этого создаются записи делегирования в зоне company. com, которые указывают на серверы имен в домене branch. company. com. Если администратор домена branch, company. com добавляет или удаляет сервер имен, придется вносить изменения в записи делегирования в домене company. com.
При использовании зон-заглушек вместо создания записей делегирования на DNS-сервере домена company.com создается зона-заглушка, указывающая на домен branch, company. com. При первоначальном создании зоны-заглушки происходит копирование записей SOA, NS и связующих записей А с сервера DNS в домене branch. company. com.
Если DNS-сервер в домене company. com получает запрос на предоставление записей ресурсов из домена branch. company. com, для преобразования имени он использует серверы, указанные в зоне-заглушке. Это позволяет добиться ускорения последующих запросов, поскольку сервер зоны-заглушки создает кэш записей ресурсов поддерживаемого домена.
Если администратор домена branch. company. com добавляет или удаляет сервер преобразования имен, информация в зоне-заглушке на DNS-сервере обновляется автоматически. Это избавляет администратора от внесения изменений в записи делегирования вручную.
Развертывание службы DNS на основе операционной системы Windows в пределах существующей инфраструктуры
Многие администраторы DNS-серверов не доверяют реализации службы DNS в операционной системе Windows. Если в качестве DNS-сервера используется BIND, Lucent QIP или NetWare 5.x, то не нужно переходить на Windows Server 2003 только ради взаимодействия с Active Directory. Используемые серверы DNS должны поддерживать стандарты, описанные в документах RFC 2052, “A DNS RR for Specifying the Location of Services (DNS SRV)”, и RFC 2136, “Dynamic DNS”.
При изучении службы Active Directory мы продемонстрируем, что операционная система Windows Server 2003 использует службу DNS для поддержки нового поколения доменов Windows. Объединение существующего пространства имен DNS с пространством имен Active Directory может оказаться достаточно сложным. Может потребоваться создание отдельного пространства имен для Active Directory, которое будет поддерживаться серверами DNS под управлением Windows, а не серверами BIND. На рис. 5.9 показана одна из реализаций такого разделения пространств имен.
Для данного примера использованы следующие особенности конфигурации.
Зона для домена Active Directory хранится на DNS-сервере под управлением операционной системы Windows Server 2003. Это сделано для обеспечения безопасного обновления зоны в реальном времени.
Основная корпоративная зона хранится на сервере BIND, для которого есть зона- заглушка на сервере Windows (вместо записей делегирования). Клиенты в пределах орга-
низации под управлением операционной системы UNIX получают записи ресурсов из домена Active Directory с помощью ссылок в зоне-заглушке.
DNS-cepeep провайдераDNS-cepeep провайдераDNS-cepeep BINDDNS-cepeep BINDФайловый сервер и сервер печатиФайловый сервер и сервер печатиФайловый сервер и сервер печатиФайловый сервер и сервер печатиВнутренний Web-cepeepВнутренний Web-cepeepКонтроллер домена WindowsServer 2003Контроллер домена WindowsServer 2003Зона-заглушкаAD.Company.comЗона-заглушкаAD.Company.comСерверСерверОбщедоступный первичный DNS-Общедоступный первичный DNS-серверсерверCompany.comCompany.comПериметрзащитыбрандмауэраПериметрзащитыбрандмауэраОбщедоступный файл зоныОбщедоступный файл зоныОбщедоступный DNS-серверОбщедоступный DNS-серверWeb-cepeep доступа в ИнтернетWeb-cepeep доступа в ИнтернетЗапись а для сервера электроннойЗапись мх для сервера электроннойЗапись а для сервера электроннойЗапись мх для сервера электронной
DNS-cepeep провайдера
DNS-cepeep провайдера
DNS-cepeep BIND
DNS-cepeep BIND
Файловый сервер и сервер печати
Файловый сервер и сервер печати
Файловый сервер и сервер печати
Файловый сервер и сервер печати
Внутренний Web-cepeep
Внутренний Web-cepeep
Контроллер домена Windows
Server 2003
Контроллер домена Windows
Server 2003
Зона-заглушка
AD.Company.com
Зона-заглушка
AD.Company.com
Сервер
Сервер
Общедоступный первичный DNS-
Общедоступный первичный DNS-
сервер
сервер
Company.com
Company.com
Периметрзащитыбрандмауэра
Периметрзащитыбрандмауэра
Общедоступный файл зоны
Общедоступный файл зоны
Общедоступный DNS-сервер
Общедоступный DNS-сервер
Web-cepeep доступа в Интернет
Web-cepeep доступа в Интернет
Запись а для сервера электронной
Запись мх для сервера электронной
Запись а для сервера электронной
Запись мх для сервера электронной
Рис. 5.9. Конфигурация службы DNS с отдельными пространствами имен для частной и общедоступной зоны с одним и тем же именем
Сервер DNS под управлением операционной системы Windows Server 2003 использует сервер BIND в качестве переадресующего сервера имен. Это позволяет клиентам Windows получать записи ресурсов из основной корпоративной зоны.
Сервер BIND перенаправляет все запросы для не входящих в корпоративную зону записей на сервер провайдера. Это позволяет серверам под управлением UNIX и Windows выполнять преобразование имен хостов, находящихся в Интернет.
Сервер BIND настроен как подчиненный сервер по отношению к DNS-серверу провайдера. Таким образом, сервер BIND не обращается непосредственно к корневым серверам Интернет. Такая конфигурация позволяет минимизировать объем данных, передаваемых через брандмауэр.
Сервер имен провайдера содержит первичную зону для общедоступного корпоративного домена. Таким образом, пользователи Интернет могут получать адреса серверов из корпоративной демилитаризованной зоны, не требуя доступа через брандмауэр к внутреннему DNS-серверу.
Большинство организаций используют смешанный вариант такой схемы. Например, организация может поддерживать собственный внешний DNS-сервер в демилитаризованной зоне. Кроме того, администратор может указать серверу DNS под управлением Windows перенаправлять запросы непосредственно на сервер DNS провайдера, что .позволяет отказаться от сервера BIND.
В любом случае, если DNS-серверы работают под управлением операционной системы Windows, клиенты Windows (включая серверы и контроллеры домена) должны обращаться
именно к этим DNS-серверам. При этом гарантируется, что клиенты смогут получить доступ к записям SRV, которые жизненно необходимы для поддержки работы таких важных служб, как LDAP и Kerberos.
Перенаправление запросов WINS
Рассматривая вопрос перенаправления запросов, обратим внимание на еще одну форму перенаправления запросов, которая появилась в службе DNS с выходом операционной системы Windows NT 4.0.
Серверы под управлением операционной системы Windows занимают особое место в сетевой инфраструктуре, поскольку они одновременно являются узлами TCP/IP с иерархическим именем и серверами SMB с плоским именем NetBIOS. В мире SMB серверы спокойно регистрируют имена с помощью службы WINS с минимальным участием администратора. В мире DNS кто-то должен создать записи для каждого сервера в соответствующей зоне, иначе клиенты под управлением других операционных систем не смогут их найти.
Вместо поддержки двух баз данных в операционной системе Windows NT 4.0 предложено два собственных типа записей ресурсов, WINS и WINS-R. Такие записи указывают DNS- серверу под управлением Windows, где найти сервер WINS. В этом случае DNS-сервер перенаправляет запросы серверу WINS.
Динамические обновления
Правильно настроенный вторичный сервер позволяет добиться повышения надежности и сокращения объема данных, передаваемых по внешним каналам, а это, как несложно заметить, две основные цели проектирования инфраструктуры DNS. Еще одной целью является уменьшение объема работы администратора. В этой ситуации особенно удобно использовать динамические обновления.
Операционные системы Windows 2000 и Windows Server 2003 поддерживают динамические обновления зон, описанные в документе RFC 2136, “Dynamic Updates in the Domain Name System” (“Динамические обновления в службе DNS”). В этом документе определяется новый код операции, который называется DNS Update и может использоваться для автоматического добавления записи в зону DNS. В сообщении DNS Update указываются тип добавляемой записи (например, запись А для имени хоста или запись SRV для службы контроллера домена), имя зоны, в которую добавляется запись, а также список записей, которые должны (или не должны) присутствовать в зоне. С помощью динамического обновления, выполняемого DNS-сервером, современные клиенты Windows как минимум регистрируют запись узла А для своего имени и запись PTR для обратного преобразования адреса.
Клиенты Dynamic DNS (Windows Server 2003, Windows 2000 и Windows XP) регистрируют свои записи А и PTR во время загрузки и обновляют зарегистрированные записи каждые 24 часа. Такие динамические обновления выполняются службой DHCP Client. Не отключайте эту службу, даже если сервер использует статический IP-адрес. Контроллеры домена обновляют свои DNS-записи каждый час. Процедура обновления контролируется службой Netlogon.
Клиенты, которые не поддерживают стандарт, определенный в RFC 2136, например операционные системы Windows более ранних версий, могут регистрировать свои записи средствами сервера DHCP. Дополнительную информацию по этой теме можно получить в разделе “Настройка службы DHCP для взаимодействия со службой DNS” в конце этой главы.
Для принудительной динамической регистрации в операционных системах Windows Server 2003, Windows ХР и Windows 2000 можно воспользоваться командой ipconfig /registerdns.
Не забывайте о нескольких важных особенностях, связанных с динамической регистрацией записей ресурсов.
Если клиент пытается зарегистрировать несуществующую запись, DNS-сервер добавляет запись в зону.
Если запись существует, но имеет другое имя и тот же IP-адрес, добавляется новая запись, а старая запись остается без изменений.
Если запись существует и имеет то же имя, но другой IP-адрес, оригинальная запись перезаписывается обновленной.
Хотя на первичном DNS-сервере хранится единственная копия файла зоны с правами чтения и записи, клиент DNS может обращаться к любому авторитетному для зоны серверу. Вторичные серверы передают уведомления клиентов DNS Update первичному серверу. Первичный сервер уведомляет вторичные серверы об изменении, а вторичные серверы получают обновленные записи (выполняется частичный перенос зоны).
Если клиент настроен на обращение к неавторитетному серверу, например, к кэширующему серверу, динамические обновления первичному серверу не передаются и регистрации клиента не происходит.
Динамические обновления и контроллеры домена
Контроллер домена Active Directory (Windows Server 2003 и Windows 2000) автоматически регистрирует записи А и PTR, а также записи SRV средствами службы Netlogon. Записи обновляются каждый раз при запуске сервера (обычно во время загрузки) и каждый час во время работы.
Если после изменения параметров контроллера домена необходимо немедленно обновить записи DNS, остановите и перезапустите службу Netlogon. Контроллер домена продолжит аутентифицировать клиентов с помощью Kerberos, но без службы Netlogon аутентификация клиентов более ранних версий (Windows 9х и Windows NT) невозможна.
Если контроллер домена не может найти собственный DNS-сервер или DNS-сервер не принимает динамические обновления, соответствующая ошибка будет присутствовать в журнале сообщений. Такие ошибки часто встречаются в инфраструктуре на основе сервера BIND, если динамические обновления были отключены на сервере имен.
Если необходимо сократить количество записей об ошибках и уменьшить объем передаваемых по сети неудачных запросов на обновление, можно отключить автоматическое обновление записей SRV. Для этого в системный реестр необходимо внести следующее изменение:
Раздел: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetLogon\ Parameters
Запись: DnsRegisterARecords
Значенйе: 0x0 (REG. DWORD)
Кроме этого, из каталога C:\Windows\System32\Config придется удалить файл netlogon. dnb. В этом файле хранятся записи для автоматического обновления.
Кроме этого, автоматическим обновлением DNS-записей для клиентов и контроллеров домена можно управлять с помощью групповых политик. Файл netlogon.dnb все равно придется удалить вручную.
Сборка мусора
Динамическая регистрация приводит к тому, что приведенная в полный порядок зона DNS начинает выглядеть, как огромная куча информации. Сборка мусора позволяет удалять старые и неиспользуемые записи.
Сборка мусора по умолчанию не включена. Ее можно включить для определенной зоны или для каждой зоны на сервере DNS. Сборка мусора выполняется только на первичном сервере и в зонах, интегрированных в Active Directory. Зоны на вторичных серверах предназначены только для чтения. После сборки мусора на основном сервере зоны на вторичных серверах очищаются в процессе переноса зоны.
Поскольку сборка мусора требует хранения дополнительной информации о времени создания каждой динамической записи, в формат файла зоны вносятся изменения. После изменения формата файл зоны становится несовместимым с серверами, работающими под управлением других операционных систем. Изменение формата не влияет на процесс переноса зоны, поскольку при переносе зоны служба DNS отфильтровывает временную метку создания записи, но непосредственно скопировать файл .dns с данными зоны на сервер под управлением Windows NT 4.0 или на сервер BIND невозможно.
Удаление записей осуществляется через определенный интервал времени. Есть два варианта выбора этого интервала: период без обновления (non-refresh interval) и период обновления (refresh interval). Оба интервала по умолчанию равны семи дням. Рассмотрим использование этих интервалов.
При первом динамическом создании записи служба DNS устанавливает срок устаревания записи, равный семидневному интервалу без обновления. В течение указанного периода сервер DNS не принимает обновления для этой записи. Это предохраняет сервер от огромного количества запросов на обновление при включении компьютеров каждое утро.
После завершения первого семидневного периода сервер начинает принимать запросы на обновление записи. Клиенты DNS обновляют запись в процессе загрузки или каждые 24 часа. Период обновления составляет еще семь дней. Если по истечении семи дней запись так и не обновляется, то она удаляется в процессе сборки мусора.
Сборка мусора может быть запущена вручную с помощью меню Properties (Свойства) для конкретной зоны или выполняться по расписанию, которое устанавливается в свойствах сервера (более подробную информацию по этой теме можно получить в разделе “Настройка сборки мусора” далее в этой главе).
Если пользователь уходит в отпуск больше чем на две недели и выключает компьютер, возраст записей А и PTR превысит указанные интервалы и записи будут удалены из файла зоны в процессе сборки мусора. В этом нет ничего страшного. Это никак не скажется на предоставленных правах в подсистеме безопасности и на доступных функциональных возможностях. После возращения из отпуска пользователь включит компьютер, в результате чего система повторно зарегистрируется на DNS-сервере и создаст необходимые записи ресурсов.
Безопасность службы DNS
Одной из основных целей проектирования инфраструктуры DNS является безопасность. Обеспечение безопасности службы DNS имеет несколько аспектов.
Ограничение количества администраторов, которые могут вносить изменения в содержимое зон
Запрет на предоставление содержимого зон неавторизованным лицам
Предотвращение от несанкционированного использования процедуры динамических обновлений
Ограничение административного доступа
Существует возможность изменения параметров безопасности, управляющих доступом к серверу DNS. По умолчанию полный доступ предоставляется группам Domain Admins, Enterprise Admins, DNS Admins и Administrators. Некоторые из групп можно удалить и разрешить доступ только группе DNS Admins или создать специальную новую группу.
Группа DNS Admins создается службой Active Directory по умолчанию во время установки службы DNS. В эту группу входит учетная запись Administrator. Группе предоставляются права полного доступа (Full Control) для управления любым сервером DNS в пределах домена, а также права полного доступа на управление информацией о зонах в базе данных Active Directory (для управления интегрированными зонами Active Directory).
Если создать отдельную группу для администраторов DNS, не размещайте эту группу в пределах организационной единицы (OU), в которой кто-либо с правами администратора имеет право менять членство в группах. В таком случае смысл создания группы безопасности теряется. Кроме этого, удалите группу DNS Admins из списка контроля доступа (ACL), поскольку любой пользователь с административными привилегиями для Active Directory сможет добавлять или удалять пользователей в этой группе.
При настройке параметров безопасности сервера DNS не удаляйте группу Authenticated Users (с предоставленными по умолчанию специальными правами) из списка контроля доступа. Это позволит клиентам DNS получать информацию от сервера DNS.
Предотвращение несанкционированного переноса зоны
Серверы DNS являются особенно интересными целями для атак злоумышленников. На этих серверы хранятся IP-адреса каждого узла сети, а в руках хакера эта информация может стать очень опасной. Дополнительные сведения о добавлении сервера в список авторизованных серверов или его удалении можно получить в разделе “Активизация переноса зоны и рассылки уведомлений об изменениях”.
Одним из последствий блокирования переноса зоны является невозможность использования таких диагностических утилит, как nslookup, которые позволяют просматривать содержимое файла зоны. Это связано с тем, что такие утилиты используют те же коды операций для передачи файла зоны, что и вторичные серверы DNS. Однако это не касается утилиты dnscmd, которая устанавливается вместе со службой DNS. При наличии прав администратора на DNS-сервере можно воспользоваться утилитой dnscmd и просмотреть содержимое файла зоны.
Безопасные динамические обновления
Одной из главных мер по обеспечению безопасности динамических обновлений является ограничение списка компьютеров, которым разрешено регистрировать записи ресурсов. Без адекватных мер защиты кто-то случайно или преднамеренно может внести в файл зоны ошибочную или подложную запись. Также с помощью регистрации нескольких тысяч некорректных записей может быть проведена атака отказа в обслуживании.
Современные стандарты, описывающие механизм безопасности обновлений DNS, определены в документах RFC 2535, “Domain Name System Security Extensions”, и RFC 2930, “Secret Key Establishment for DNS”. В этих документах RFC описывается стандарт DNSSec. Операционная система Windows Server 2003 не реализует транзакции DNSSec, но поддерживает новые типы записей ресурсов, которые используются в таких транзакциях.
Операционная система Windows Server 2003 позволяет ограничить динамическое обновление DNS только для аутентифицированных в домене компьютеров. Для реализации этого механизма безопасности зона DNS должна быть интегрирована в Active Directory. По умолчанию доступ на чтение и запись DNS-объектов предоставлен группе DNS Admins. Пример списка контроля доступа показан на рис. 5.10.
С рекомендациями по настройке безопасного обновления информации в зоне DNS можно ознакомиться в разделе “Управление службой Dynamic DNS” далее в этой главе.
■штввмммш^ лш
Gw>Ml( Objeet S*u*|
Ом» » потек
f Ш ^Administrates (COMPAbrr’VtiiministratorslД • •
■ r tP CREATOR OWNER
g| 5 Domain Admins (COMPANYXDomanAdmins)
йй 5 Enterprise Admins (COMPANYSEnterprise Admins)«
/’/l аЖ Г» ITrnnnirr Г>ГМ. 14 111 Г-П» l ТГ1 Cl I. I ГГ> ft. 1Й^^Д ^
Penviseone la DnaArfcrertsAlowPay
FuB Control0Q
Read0О
Write0□
Create All Child Objects0Q
■^Delete A3 Child Objects0D
< |1Special Permissions00
Ftx sneciaiiwHteeom er fcv advanced eeehei.'M«^ Г
Puc. 5.10. В списке контроля доступа для интегрированной зоны выделена группа DNSAdminsPuc. 5.10. В списке контроля доступа для интегрированной зоны выделена группа DNSAdminsctel Advanced.
Puc. 5.10. В списке контроля доступа для интегрированной зоны выделена группа DNSAdmins
Puc. 5.10. В списке контроля доступа для интегрированной зоны выделена группа DNSAdmins
Настройка клиентов DNS
Вот и пришло время установить службу DNS, но сначала настроим несколько клиентов DNS, чтобы они могли использовать сервер сразу после установки. В операционной системе Windows Server 2003 для клиентов необходимо предоставить два важных элемента информации о DNS-сервере:
IP-адрес сервера DNS, на который будут отправляться запросы на преобразование имен;
принятое по умолчанию имя домена, которое будет использоваться при отправке запросов (так называемый суффикс DNS).
IP-адрес указывается в свойствах протокола TCP/IP. Суффикс DNS указывается в двух местах: в свойствах протокола TCP/IP для сетевого интерфейса и в свойствах системы для компьютера. Эти значения хранятся в различных местах системного реестра.
Настройка параметров DNS в свойствах протокола TCP/IP
Владея всей необходимой информацией о DNS-сервере, выполните последовательность действий, приведенную в процедуре 5.5.
Использование нескольких DNS-серверов
Клиент может быть настроен на использование нескольких DNS-серверов. Если первый из настроенных серверов не отвечает, клиент обращается к следующему серверу. Если первый сервер возвращает авторитетный ответ о недоступности записи (Record Not Found), клиент не станет обращаться ко второму серверу.
Процедура 5.5. Настройка параметров DNS-сервера в свойствах протокола TCP/IP
Щелкните правой кнопкой мыши на пиктограмме Му Network Places (Мое сетевое окружение) и выберите команду Properties (Свойства) из контекстного меню. Откроется окно Network and Dial-Up Connections (Сеть и подключениям Интернету).
Щелкните правой кнопкой мыши на пиктограмме Local Connection (Подключение по локальной сети) и выберите из контекстного меню команду Properties (Свойства). Откроется окно Local Connection Properties.
В открывшемся окне дважды щелкните на записи Internet Protocol (TCP/IP) (Протокол Интернета (TCP/IP)). Откроется окно свойств протокола.
Щелкните на кнопке Advanced (Дополнительно). Откроется окно Advanced TCP/IP Settings (Дополнительные параметры TCP/IP).
Перейдите на вкладку DNS.
В группе DNS Server Addresses (Адреса DNS-серверов) щелкните на кнопке Add (Добавить). Откроется окно TCP/IP DNS Server (DNS-сервер TCP/IP).
Введите IP-адрес DNS-сервера и щелкните на кнопке Add (Добавить) для добавления адреса в список. В список можно добавить несколько серверов.
Оставьте пустым поле DNS Suffix for This Connection (DNS-суффикс подключения). He устанавливайте флажок Use This Connection's DNS Suffix in DNS Registration (Использовать DNS-суффикс подключения при регистрации в DNS). Эти параметры будут настроены в свойствах системы (рассматриваются в следующем разделе).
Щелкните на кнопке ОК, чтобы сохранить внесенные изменения и закрыть диалоговое окно.
Щелкните на кнопке ОК для возврата в окно свойств протокола TCP/IP.
Щелкните на кнопке ОК, чтобы закрыть окно и обновить записи системного реестра.
Настройка параметров DNS в окне свойств системы
Информация о DNS-суффиксе в свойствах системы используется в качестве основного суффикса при создании полностью определенного имени системы при регистрации компьютера с помощью Dynamic DNS. Лучше всего указывать суффикс DNS именно здесь, а не в свойствах протокола TCP/IP. Просмотр и изменение суффикса DNS в свойствах системы рассма тривае тся в процедуре 5.6. После изменения этого параметра необходима перезагрузка компьютера.
Процедура 5.6. Настройка параметров DNS-сервера в окне свойств системы
Щелкните на кнопке ОК для закрытия окна свойств системы. Будет выдано предупреждение о необходимости перезагрузки компьютера.
Щелкните на кнопке ОК и еще раз щелкните на кнопке ОК, чтобы закрыть окно свойств системы. После этого будет выдан запрос на перезагрузку, с которым лучше согласиться.
После завершения настройки клиента воспользуйтесь командой ipconfig /all для проверки внесенных изменений.
Установка и настройка DNS-сервера
Если уже используются DNS-серверы под управлением операционной системы Windows NT 4.0 или Windows 2000, их можно модернизировать до Windows Server 2003 с сохранением конфигурации и файлов зон. Если принято решение о модернизации, начните с первичного DNS-сервера, а уж затем выполните модернизацию вторичных серверов.
Рассмотрим действия по развертыванию службы DNS.
Составьте схему пространства имен доменов DNS, чтобы представлять себе список необходимых зон. Имена DNS оказывают влияние практически на все аспекты работы системы, поэтому не жалейте времени на полное согласование пространства имен.
Примите решение о способе интеграции службы Windows DNS в существующую инфраструктуру DNS. Если в сети используется служба WINS, необходимо выяснить, планируется ли перенаправлять запросы на сервер WINS.
Примите решение о способе преобразования адресов хостов, расположенных в Интернет. Для этого могут использоваться корневые DNS-серверы, переадресующий сервер или комбинация этих методов.
Примите решение о том, как служба преобразования имен будет работать для общедоступных зон. Поддержку DNS может предоставлять провайдер, DNS-сервер может быть установлен в демилитаризованной зоне или в брандмауэре может быть открыт канал для передачи DNS-запросов.
Примите решение о том, требуется ли поддержка преобразования имен в защищенной брандмауэром зоне для внешних DNS-доменов. В качестве внешних доменов могут выступать внешние сети и соединения с филиалами организации или другими доверенными организациям. Для преобразования имен для таких соединений можно использовать перенаправление запросов по условию и зоны-заглушки.
Определите точки, в которых необходимо установить DNS-серверы. Помните, что необходимо повысить отказоустойчивость и снизить объем данных, передаваемых по внешним каналам.
Примите решение, будет ли использована стандартная схема в виде первичного и вторичных DNS-серверов или будет выбран механизм интегрированных в Active Directory DNS- зон. При выборе варианта DNS-зон, интегрированных в Active Directory, контроллеры домена должны находиться в стратегических точках сети для поддержки службы преобразования имен, а также служб LDAP и Kerberos.
Определите, будет ли использоваться динамическая регистрация записей ресурсов. Если это так, постарайтесь интегрировать зоны в Active Directory, чтобы иметь возможность пользоваться безопасными обновлениями.
Определите необходимость настройки специальных возможностей DNS-серверов, например механизм распределения нагрузки Round Robin, выбор приоритета на основе маски подсети и проверка имен.
После оценки проекта воспользуйтесь пошаговыми инструкциями этого раздела для настройки серверов.
Установка службы DNS
Для установки службы DNS в операционной системе Windows Server 2003 потребуется установочный компакт-диск. Последовательность действий по установке изложена в процедуре 5.7.
Процедура 5.7. Установка драйверов DNS
На Control Panel (Панель управления) откройте аплет Add/Remove Programs (Установка и удаление программ).
Выберите пункт Add/Remove Windows Components (Установка компонентов Windows). Запустится мастер Windows Components Wizard (Мастер компонентов Windows).
Выделите Network Services (Сетевые службы) и щелкните на кнопке Details (Подробнее).
В открывшемся окне Network Services (Сетевые службы) выберите Domain Name System (DNS) и щелкните на кнопке ОК, чтобы сохранить изменения и вернуться в окно Windows Components.
Щелкните на кнопке Next (Далее). Откроется окно Configuring Components (Настройка компонентов) и начнется загрузка драйверов. После загрузки драйверов и завершения настройки мастер выводит окно с сообщением об успешном завершении установки. ,
Щелкните на кнопке Finish (Готово), чтобы закрыть окно и вернуться в окно Add/Remove Programs (Установка и удаление программ).
Закройте окно Add/Remove Programs (Установка и удаление программ).
После этого можно начинать настройку зон. Перезагружать компьютер не нужно.
Создание зон прямого преобразования
Сначала необходимо создать зону для корня пространства имен DNS. В общедоступном пространстве имен Company, которое используется в данном примере, первой зоной будет зона для домена company. com. Следуйте инструкциям, приведенным в процедуре 5.8.
Загрузочная информация DNS
Служба DNS автоматически запускается во время загрузки. Для останова и запуска службы можно использовать консоль DNS или команды net stop dns и net start dns.
Если служба DNS настроена как стандартный первичный или вторичный сервер, зона инициализируется с использованием записей системного реестра из раздела HKLMXSoftwareX Microsoft Windows NTXCurrentVersionXDNS ServerXZones. В операционной системе Windows 2000 информация о зонах хранилась в разделе службы DNS.
Каждая зона имеет собственный раздел с записями, определяющими имя файла базы данных. Кроме этого, записи определяют возможность динамического обновления и необходимость безопасного обновления.
Процедура 5.8. Создание зоны прямого преобразования
В меню Start (Пуск) выберите ProgramsMAdministrative ToolsMDNS (Программы^ Администрирование1^ DNS). В дереве DNS присутствует локальный сервер и две пустые ветки для зон прямого и обратного преобразований.
Щелкните правой кнопкой мыши на пиктограмме Forward Lookup Zone (Зона прямого преобразования) и выберите из контекстного меню команду New Zone (Создать зону). Запустится мастер New Zone Wizard (Мастер создания новой зоны).
Щелкните на кнопке Next (Далее). Откроется окно Zone Туре (Тип зоны), как показано на рис. 5.11. Оставьте переключатель в принятом по умолчанию положении Primary Zone (Первичная зона). Если необходимо создать стандартную первичную зону, сбросьте флажок Store the zone in Active Directory (Сохранить зону в Active Directory).
Рис. 5.11. В окне Zone Туре (Тип зоны) мастера создания новой зоны по умолчанию выбран переключатель Primary zone
Щелкните на кнопке Next (Далее). В открывшемся окне Zone Name (Имя зоны) введите имя зоны.
Щелкните на кнопке Next (Далее). Откроется окно Zone File (Файл зоны). Имя файла зоны должно совпадать с именем зоны, расширение файла — . dns. Если файл зоны уже существует, его можно импортировать с помощью команды Use This Existing File (Использовать существующий файл).
Щелкните на кнопке Next (Далее). Откроется окно Dynamic Update (Динамическое обновление). Выберите вариант обновления. Вариант Allow Only Secure Dynamic Updates (Разрешить только безопасные динамические обновления) доступен только для зон, интегрированных в Active Directory.
Щелкните на кнопке Next (Далее). Откроется последнее окно мастера.
Щелкните на кнопке Finish (Готово), чтобы завершить настройку и закрыть окно. Новая зона будет показана как папка в разделе Forward Lookup Zones (Зоны прямого преобразования) в левой панели окна. Выделив значок новой зоны, в правой панели можно просмотреть созданные для нее записи (рис. 5.12).
Создание обратных зон -
Зона прямого преобразования используется при обработке стандартных запросов, например, запросов на получение записи А или записи SRV. Зона обратного преобразования (или обратная зона) используется при обработке запросов, когда клиент по IP-адресу хочет определить имя хоста. Можно обойтись и без обратной зоны, но такие зоны очень удобны для диагностики (автор настоятельно рекомендует создавать зоны обратного преобразования). Создание обратной зоны рассматривается в процедуре 5.9.
dn^mqmt [DNS S( К VIP 1 f 01 w<h d I ookup Zones company, com J
№
: * * ©I® । x er 0 e^ ■ a a a ri '
*U3*1 udAJjJ
j^DNS
H 3 SERVERI
Я Qj Forward Lookup Zones в ^МНЯ88
<«BeWv.aei lOreedW
E»
1ЙК.
.tcp
>i U DomainDnsZones (t —J ForestDnsZones ®-^ Reverse Lookup Zones SJ ЙЯ Event Viewer>i U DomainDnsZones (t —J ForestDnsZones ®-^ Reverse Lookup Zones SJ ЙЯ Event ViewerStart of Authority (SOA)Name Server (NS)Host (A)Host (A)Start of Authority (SOA)Name Server (NS)Host (A)Host (A)
>i U DomainDnsZones (t —J ForestDnsZones ®-^ Reverse Lookup Zones SJ ЙЯ Event Viewer
>i U DomainDnsZones (t —J ForestDnsZones ®-^ Reverse Lookup Zones SJ ЙЯ Event Viewer
Start of Authority (SOA)
Name Server (NS)
Host (A)
Host (A)
Start of Authority (SOA)
Name Server (NS)
Host (A)
Host (A)
Й DomainDnsZones UJ ForestDnsZones ® (same as parent folder) щ (same as parent folder) 3 (same as parent folder)
[28], serverl.company.com,..
server 1. company. com.
192,168.0.1
192.168.0.1
Puc. 5.12. Консоль DNS и новая зона прямого преобразования
Процедура 5.9. Создание обратной зоны
Щелкните правой кнопкой мыши на значке Reverse Lookup Zone (Зона обратного преобразования) и выберите команду New Zone (Создать зону) из контекстного меню. Запустится мастер New Zone Wizard (Мастер создания новой зоны).
Щелкните на кнопке Next (Далее). Откроется окно Zone Туре (Тип зоны). Оставьте переключатель в принятом по умолчанию положении Primary Zone (Первичная зона). Если необходимо создать стандартную первичную зону, сбросьте флажок Store the zone in Active Directory (Сохранить зону в Active Directory).
Щелкните на кнопке Next (Далее). Откроется окно Reverse Lookup Zone (Зона обратного преобразования), которое показано на рис. 5.13. В поле Network ID (Идентификатор сети) введите идентификатор сети, который будет обслуживаться данной зоной. В примерах, которые представлены в этой книге, используется сеть 10 . х с 16-разрядной маской подсети, поэтому в поле будет указан идентификатор 10.1с пустыми двумя последними октетами. Каждый уникальный номер во втором октете требует создания отдельной зоны обратного преобразования.
Щелкните на кнопке Next (Далее). В открывшемся окне Zone File (Файл зоны) оставьте принятые по умолчанию значения. Имя файла зоны с расширением . dns должно совпадать с названием зоны. Если файл зоны уже существует, его можно импортировать с помощью команды Use This Existing File (Использовать существующий файл).
Щелкните на кнопке Next (Далее). В окне Dynamic Updates (Динамические обновления) выберите вариант обновления. Переключатель Allow Only Secure Dynamic Updates Updates (Разрешить только безопасные динамические обновления) доступен только для зон, интегрированных в Active Directory.
Щелкните на кнопке Next (Далее). Откроется окно завершения работы мастера.
Чтобы закрыть окно и вернуться на консоль DNS, щелкните на кнопке Finish (Готово).
После создания зоны обратного преобразования создайте несколько тестовых записей узлов, чтобы удостовериться в успешном создании связанных с ними записей PTR. После этого проверьте работу зоны со стороны клиента, отправив несколько тестовых ICMP-пакетов на хосты, указанные в тестовой зоне, и на DNS-сервер.
Mew Zone Wizard
Reverse Lookup Zone
A reverse lookup zone translates IP addresses into DNS names.
To «Mfr *• wew Ыи» w, N* »• network ID or foe name of the zone.
Il92 168 6
The network ID klhnporton of Peddresreg Ural belong ft* zone Enter Ihenehwrk JO hteremul tel №■*)«*
Ogou leedwoeidw r*w*lD.*we«epwih*e»ne«ie*. For «an* ***Ю 10*o* еп**а10*»лф«. and wiw»I0100**** zoheaiO »**»*»
r Я*1Й1*1Р16пеп*е
Fa nm aftoMton on ом* a anew laata* «nai nick HelpFa nm aftoMton on ом* a anew laata* «nai nick Help|6 1£ЙН2 >r -addr"игра', ' /. .
Fa nm aftoMton on ом* a anew laata* «nai nick Help
Fa nm aftoMton on ом* a anew laata* «nai nick Help
Puc. 5.13. Окно Reverse Lookup Zone мастера создания новой зоны
Настройка иерархических зон
После установки первого DNS-сервера и создания первой зоны можно настроить дополнительные зоны для построения иерархического пространства имен DNS. Например, можно начать с зоны company. com и настроить отдельные зоны для каждого континента, например па. company. com, eu. company. com и т.д.
При использовании отдельных зон необходимо настроить сервер преобразования имен для обработки запросов между зонами. При планировании учитывайте два аспекта.
Для обработки запросов от клиентов DNS в дочерней зоне на преобразование записей, хранящихся в родительской зоне, необходимо настроить файл с адресами корневых серверов.
Для обработки запросов от клиентов DNS в родительской зоне на преобразование записей, хранящихся в дочерней зоне, необходимо настроить делегирование.
Настройка корневых серверов
Чтобы получить возможность обрабатывать запросы на преобразование записей, хранящихся в родительской зоне, на DNS-сервере дочерней зоны необходимо создать список адресов корневых серверов. В списке должны присутствовать адреса авторитетных серверов или серверов в родительской зоне.
Сначала на двух серверах необходимо установить службу DNS и настроить зоны. Целью рассмотренных ниже действий в процедуре 5.10 является предоставление пользователю дочерней зоны возможности преобразовывать записи в родительской зоне, обращаясь только к DNS-серверу в дочерней зоне.
Процедура 5.10. Настройка адресов корневых серверов
Откройте консоль DNS.
Щелкните правой кнопкой мыши на пиктограмме DNS Server (DNS-сервер) и выберите из контекстного меню команду Properties (Свойства).
В открывшемся окне перейдите на вкладку Root Hints.
Щелкните на кнопке Add (Добавить). Откроется окно Create New Record (Создать новую запись).
В поле Server Name (Имя сервера) введите полностью определенное имя корневого сервера (можно не указывать завершающий символ точки).
В поле Server IP Addresses (IP-адреса сервера) введите IP-адрес сервера и щелкните на кнопке Add (Добавить), чтобы добавить адрес в список. Если сервер имеет несколько IP-адресов, в список можно добавить каждый адрес. Для установки приоритета адресов воспользуйтесь кнопками Up (Верх) и Down (Вниз).
Щелкните на кнопке ОК, чтобы сохранить внесенные изменения и вернуться в окно Properties (Свойства). Убедитесь, что корневой сервер находится на вершине списка.
Чтобы сохранить внесенные изменения и закрыть окно, щелкните на кнопке ОК.
Проверьте созданную конфигурацию, отправив с хоста в дочернем ДОмене тестовый эхо- пакет на хост, подключенный в родительском домене. Отправка дайта может занять некоторое время, но в итоге должна завершиться успешно.
Настройка делегирования
В предыдущем разделе рассказано, как обрабатывать запрос для хоста, находящегося выше в пространстве имен DNS. Чтобы получить возможность преобразования имен хостов, находящихся ниже по иерархии пространства имен, потребуются дополнительные усилия. Предположим, что, находясь в домене company. com, необходимо отправить тестовый эхо-пакет узлу srvl, который находится в домене branchi. company. com.
Для успешной отправки тестового эхо-пакета DNS-сервер в домене company. com должен найти запись А интересующего сервера. Но сервер DNS в домене company. com содержит файл зоны только для домена company. com. Информацию о записи придется получать из домена branchi. company. com. Этот процесс называется делегированием (delegation).
Обновление адресов корневых серверов
Список корневых серверов, предоставленный вместе с операционной системой Windows Server 2003, соответствует устаревшим серверам, которые поддерживались компанией Network Solutions. Современные серверы верхнего уровня поддерживаются компанией Verisign (которая выступает от имени компании Network Solutions). Адреса корневых серверов можно обновить вручную, воспользовавшись информацией из Verisign Global Registry Services, www.verisign-grs.com/dns/dnsfaq.html.
Как было показано в разделе “Зоны-заглушки” этой главы, самым простым способом делегирования в операционной системе Windows Server 2003 является настройка зоны-заглушки на DNS-сервере родительской зоны, которая будет указывать на один или несколько серверов в дочерней зоне. Зона-заглушка автоматически копирует записи SOA, NS и связующие записи из дочерней зоны. При этом необходима авторизация для переноса дочерней зоны. Если такая авторизация отсутствует, необходимо использовать стандартное делегирование, описанное в этом разделе.
DNS-серверы поддерживают делегирование сверху вниз, но не наоборот. Таким образом, при настройке делегирования в пространстве имен DNS начинайте с корневого домена и продолжайте, как описано в процедуре 5.11.
Процедура 5.11. Настройка делегирования
Откройте консоль DNS.
Щелкните правой кнопкой мыши на имени зоны и выберите из контекстного меню пункт New Delegation (Создать делегирование). Запустится мастер New Delegation Wizard.
Щелкните на кнопке Next (Далее). Откроется окно Delegated Domain Name (Имя домена делегирования).
В поле Delegated Domain (Домен делегирования) введите “плоское” имя дочернего домена. Полностью определенное имя создается автоматически.
Щелкните на кнопке Next (Далее). Откроется окно Name Servers (Серверы имен).
Щелкните на кнопке Next (Далее).
В открывшемся окне Resource Record (Запись ресурса) в поле Server Name (Имя сервера) введите полностью определенное имя авторитетного сервера для дочерней зоны. Почему следует указывать авторитетный сервер, рассказывается во врезке “Некорректное делегирование”.
В поле IP Address (IP-адрес) введите IP-адрес сервера имен в дочернем домене и щелкните на кнопке Add (Добавить), чтобы добавить этот адрес в список.
Для сохранения внесенных изменений щелкните на кнопке ОК. В окне Name Servers (Серверы имен) добавленный адрес сервера отображается в списке Server Name (Имя сервера).
Чтобы открыть последнее окно мастера, щелкните на кнопке Next (Далее).
Щелкните на кнопке Finish (Готово), чтобы сохранить внесенные изменения и закрыть окно мастера.
Некорректное делегирование
Распространенной ошибкой при настройке делегирования является указание сервера, не являющегося авторитетным для выбранного домена. В результате происходит некорректное делегирование (lame delegation).
Некорректное делегирование является бомбой с часовым механизмом. Система работает отлично, пока однажды неавторитетный сервер не выдаст неправильный ответ, полученный из собственного кэша. Сервер DNS в родительском домене передает ошибочный ответ клиенту и размещает ответ в собственном кэше, из которого ошибочный ответ получают другие клиенты.
Помните свои ощущения, когда оказалось, что ваши родители тоже ошибаются? Клиенты DNS, получившие неправильный ответ, чувствуют себя точно так. Проверьте, что делегирование выполняется только для авторитетных серверов.
В дереве DNS на левой панели консоли DNS дочерний домен отображается ниже родительского. На правой панели отображается запись NS для сервера имен дочернего домена. Чтобы протестировать механизм делегирования, отправьте тестовый ping-пакет с хоста в родительском домене на хост в дочернем домене.
Настройка вторичных DNS-серверов
В этом разделе рассматривается настройка вторичного DNS-сервера. На вторичном сервере хранится копия файла зоны с правами только на чтение. Файл зоны копируется с первичного сервера. Вторичные серверы являются авторитетными для соответствующих зон, но не позволяют вносить изменения в записи зон. В этом разделе также рассматривается последовательность действий по настройке первичного сервера имен, а именно — установки параметров, необходимых для удовлетворения запросов на перенос зоны от вторичных серверов и для уведомления вторичных серверов о внесении изменений.
Служба DNS для вторичного сервера устанавливается так же, как для первичного сервера. Отличается только процедура настройки зоны. Установите службу DNS, как описано в разделе “Установка и настройка DNS-сервера” выше в этой главе, и продолжайте настройку вторичного сервера с этого места.
Активизация переноса зоны и рассылки уведомлений об изменениях
Вторичный сервер не способен получать информацию зоны, пока перенос зоны и рассылка уведомлений об изменениях не будут настроены на первичном сервере имен. Для активизации этих функций выполните последовательность действий, описанную в процедуре 5.12.
Процедура 5.12. Активизация переноса зоны и рассылки уведомлений об изменениях
Откройте консоль DNS.
Щелкните правой кнопкой мыши на пиктограмме зоны и выберите из контекстного меню команду Properties (Свойства).
В открывшемся окне Properties (Свойства) перейдите на вкладку Zone Transfers (Перенос зоны). Установите флажок Allow Zone Transfers (Разрешить перенос зоны). Существует три варианта рассылки информации о зоне. ■
То Any Server (Всем серверам). Название говорит само за себя, и использовать этот вариант не рекомендуется. Выбор этого варианта позволяет любому серверу и пользователю получать зону с сервера имен. Полный список имен узлов и соответствующих IP-адресов не должен попадать в руки злоумышленников.
Only to Servers Listed in the Name Servers Tab (Только серверам, перечисленным на вкладке Серверы имен). Этот вариант ограничивает перенос зоны серверами, запись NS которых присутствует в файле зоны. Этот вариант является наиболее предпочтительным, поскольку не требует поддержки двух списков серверов (на самом деле трех списков, поскольку придется поддерживать еще и список уведомления). Но при делегировании зоны в ненадежные домены этот вариант выбирать не следует, поскольку администраторы этих ненадежных доменов смогут получать содержимое файла зоны.
Only to the Following Servers (Только следующим серверам). Этот вариант предоставляет наибольший контроль над механизмом переноса зоны. В этом случае можно указать точный список серверов, которым предоставляется право на получение зоны. Хотя злоумышленнику ничто не мешает подменить IP-адрес вторичного сервера, чтобы реализовать перенос зоны, это лучше, чем предоставлять ничем не ограниченный доступ.
Щелкните на кнопке Notify (Уведомлять). Откроется окно Notify. По умолчанию в операционной системе Windows Server 2003 уведомление об обновлениях включено. Это обеспечивает обновление информации в файлах зон на вторичных серверах. В этом окне можно настроить автоматическое уведомление серверов, которые перечислены в специальном списке или записи NS которых присутствуют в файле зоны. Если в предыдущем окне был выбран вариант Only to the Following Servers (Только следующим серверам), то вторичные серверы придется указать вручную.
Щелкните на кнопке ОК, чтобы сохранить установленные параметры уведомления и вернуться в окно Properties (Свойства).
Щелкните на кнопке ОК для сохранения параметров переноса зоны и возврата на консоль DNS.
Закройте консоль DNS.
Проверьте параметры переноса зоны и рассылки уведомления об изменениях, добавив тестовую запись на первичном сервере. После обновления содержимого консоли DNS на вторичном сервере запись должна появиться в списке. Если этого не произошло, проверьте правильность IP-адреса и заданных параметров уведомления.
Настройка вторичного сервера DNS
Авторитетный вторичный сервер имен поддерживает локальную копию файла зоны. Для обработки запросов за пределами зоны сервер использует адреса корневых серверов или пе- реадресующий сервер.
Если основной сервер преобразования имен настроен на перенос зоны только указанным вторичным серверам, необходимо добавить в список IP-адрес этого сервера. Кроме этого, новый вторичный сервер необходимо добавить в список серверов, которым рассылаются уведомления. В процедуре 5.13 рассматривается пошаговая настройка вторичного сервера.
Процедура 5.13. Настройка вторичного сервера
Откройте консоль DNS.
Щелкните правой кнопкой мыши на пиктограмме Forward Lookup Zone (Зона прямого преобразования) и выберите из контекстного меню команду New Zone (Новая зона). Запустится мастер New Zone Wizard (Мастер создания новой зоны).
Щелкните на кнопке Next (Далее). Откроется окно Zone Туре (Тип зоны). Установите переключатель в позицию Secondary Zone (Вторичная зона).
Щелкните на кнопке Next (Далее). В открывшемся окне Zone Name (Имя зоны) введите полностью определенное имя зоны, которая будет передаваться на этот сервер, например company.com.
Щелкните на кнопке Next (Далее).■
В окне Master DNS Servers (Первичный DNS-сервер) введите IP-адрес первичного сервера имен, который будет использоваться настраиваемым вторичным сервером. Щелкните на кнопке Add (Добавить) для добавления сервера в список. Зоны могут передаваться с нескольких первичных серверов.
Чтобы перейти к последнему окну мастера, щелкните на кнопке Next (Далее).
Щелкните на кнопке Finish (Готово) для завершения работы мастера и возврата на консоль DNS. Перенос зоны будет выполняться автоматически.
Обновите содержимое консоли и убедитесь в наличии записей из файла зоны. Если появятся изображение большого красного символа “X” и сообщение Zone Not Loaded (Зона не загружена), нажмите клавишу <F5> для повторного обновления. Если пиктограмма “X" не исчезнет, скорее всего, перенос зоны не разрешен на первичном сервере и вторичный сервер не добавлен в список серверов, которым разрешено получать зону.
После настройки вторичного сервера настройте клиенты на использование вторичного сервера. Проверьте его работоспособность, отправив тестовые эхо-пакеты на хосты в пределах и за пределами зоны. Если отправка пакетов за пределы зоны не работает, проверьте список корневых серверов на первичном и вторичном серверах.
Интеграция DNS-зон в службу
Active Directory
Если зона DNS интегрирована в Active Directory, вместо ASCII-файла для каждой записи создается объект Active Directory. Для интеграции зоны в Active Directory служба DNS должна быть запущена на контроллере домена. Поддерживается интеграция только первичной зоны. Последовательность действий, которые необходимо выполнить для интеграции зоны в Active Directory, рассматривается в процедуре 5.14.
276 Глава 5
Процедура 5.14. Интеграция первичной зоны в Active Directory
Откройте консоль DNS.
Щелкните правой кнопкой мыши на зоне, которая должна быть интегрирована в Active Directory, и выберите из контекстного меню команду Properties (Свойства). Откроется окно Properties (Свойства).
На вкладке General (Общие) возле поля Туре (Тип) щелкните на кнопке Change (Изменить). Откроется окно Change Zone Туре (Изменить тип зоны), которое показано на рис. 5.14.
вааЕИЕ5ЯЯяяеадян^^
Select*гопе type
Ргяпадевпе
Sta# * со» of the zone that can ba фЙЫ ***
<* Secondary zone
Stow a copy of an «mug кг*. Т1йьа>*»Мр* balance thegtoceeng bed of pw»y wvere and provides f<*tfltorance •
^ Stub zone
Siow a copy ol a мг* сотым оф NS, SOA. and ponk^ glue
A recced* A»o<vercofila»wge*6»)neienateiahoiUb#efar that иг*
P Stm№B2»nAcbveD№to9(av«M)l»bftrVDNS*en*ieatiot4anconlra*«]
| OK I Cancel |
Puc. 5.14. В окне Change Zone Type предоставляется возможность интеграции зоны DNS в Active Directory
Установите флажок Store the zone in Active Directory (Сохранить зону в Active Directory). Щелкните на кнопке ОК для сохранения внесенных изменений. Появится окно с запросом на подтверждение.
Щелкните на кнопке ОК, чтобы подтвердить свой выбор и вернуться в окно Properties (Свойства). После этого в поле Туре (Тип) будет отображаться значение Active Directory Integrated.
Щелкните на кнопке ОК, чтобы сохранить внесенные изменения, закрыть окно и вернуться на консоль DNS.
Теперь нужно убедиться, что информация зоны была скопирована в Active Directory. Последовательность действий для проверки рассматривается в процедуре 5.15.
Процедура 5.15. Проверка успешной интеграции DNS-зоны
Откройте консоль Active Directory— Users and Computer (Active Directory — пользователи и компьютеры). Для этого выберите Starts Programs1^ Administrative Tools'^ Active Directory— Users and Computer (Пуск^Программы1^ Администрирование1^Active Directory — пользователи и компьютеры).
В меню Console (Консоль) выберите пункт View^Advanced View (Вид^Дополнительно). Это позволит получить доступ к группе объектов, в число которых входит каталог Sys t ent
Перейдите в дереве к SystenAMicrosoftDNS. Файл зоны отображается как каталог с объектами dnsNode. Каждый из объектов соответствует записи ресурса (рис. 5.15).
С помощью консоли Active Directory — Users and Computers (Active Directory — пользователи и компьютеры) нельзя управлять объектами dnsNode. Для этого придется воспользоваться консолью DNS или утилитой dnscmd.
*О2£Г*О2£Геишажшш
*О2£Г
*О2£Г
_J ComPartitionSets др еопралу.см» 27«t*ds_J ComPartitionSets др еопралу.см» 27«t*dstti ^ Default Domain Policy ® _J Dfs-Configuration ® Ш DomainUpdates ® ^ F®® Replication Service ®-S FileLlnks@ £j № SecurityЗ - Г^ MeetingsВ ; 1 MicrosoftDNS$ d RootDNSServerstti ^ Default Domain Policy ® _J Dfs-Configuration ® Ш DomainUpdates ® ^ F®® Replication Service ®-S FileLlnks@ £j № SecurityЗ - Г^ MeetingsВ ; 1 MicrosoftDNS$ d RootDNSServers$ Cj RAS and IAS Servers t ®-^ RpcServicesEg ' 1 WlnsockServices / ffl£3WMiPoky$ Cj RAS and IAS Servers t ®-^ RpcServicesEg ' 1 WlnsockServices / ffl£3WMiPokyNan*8®p_gc._tcpSi _gc._tcp.Def auk-First-Site-Name,„sites8-kerberos._tcp8 „kerberos .„tcp. de. „msdes8 „kerberos.Jcp.Default-First-Site-Name, „sites8 „kerberos. _tcp. Def auft-Ar$t-Ste-Name, „sites. de. „msdes ^_kerberos._udp8 _kpas$wd,_tcp8-kpasswd._udp8 Jdap. „tcpNan*8®p_gc._tcpSi _gc._tcp.Def auk-First-Site-Name,„sites8-kerberos._tcp8 „kerberos .„tcp. de. „msdes8 „kerberos.Jcp.Default-First-Site-Name, „sites8 „kerberos. _tcp. Def auft-Ar$t-Ste-Name, „sites. de. „msdes ^_kerberos._udp8 _kpas$wd,_tcp8-kpasswd._udp8 Jdap. „tcpJ-lH" _. dnsNode dnsNode dnsNode dnsNode dnsNode dnsNode dnsNode dnsNode dnsNode dnsNode dnsNodeJ-lH" _. dnsNode dnsNode dnsNode dnsNode dnsNode dnsNode dnsNode dnsNode dnsNode dnsNode dnsNodeSi _ldap._tcp.7232e24a-677f-478c-b58a<0acbclf 18d2.domain$._m$dc$ dnsNodeSi _ldap._tcp.7232e24a-677f-478c-b58a<0acbclf 18d2.domain$._m$dc$ dnsNodeSi _ldap._tcp.dc. jnsdcsSi Jdap. _tcp. Def auk-First-Site-Name. „sitesSi _ldap._tcp.dc. jnsdcsSi Jdap. _tcp. Def auk-First-Site-Name. „sitesЛ1Л1I* in*, mi iI* in*, mi i—1—1dnsNode dnsNodednsNode dnsNode
_J ComPartitionSets др еопралу.см» 27«t*ds
_J ComPartitionSets др еопралу.см» 27«t*ds
tti ^ Default Domain Policy ® _J Dfs-Configuration ® Ш DomainUpdates ® ^ F®® Replication Service ®-S FileLlnks
@ £j № Security
З - Г^ Meetings
В ; 1 MicrosoftDNS
$ d RootDNSServers
tti ^ Default Domain Policy ® _J Dfs-Configuration ® Ш DomainUpdates ® ^ F®® Replication Service ®-S FileLlnks
@ £j № Security
З - Г^ Meetings
В ; 1 MicrosoftDNS
$ d RootDNSServers
$ Cj RAS and IAS Servers t ®-^ RpcServices
Eg ' 1 WlnsockServices / ffl£3WMiPoky
$ Cj RAS and IAS Servers t ®-^ RpcServices
Eg ' 1 WlnsockServices / ffl£3WMiPoky
Nan*
8®
p_gc._tcp
Si _gc._tcp.Def auk-First-Site-Name,„sites
8-kerberos._tcp
8 „kerberos .„tcp. de. „msdes
8 „kerberos.Jcp.Default-First-Site-Name, „sites
8 „kerberos. _tcp. Def auft-Ar$t-Ste-Name, „sites. de. „msdes ^_kerberos._udp
8 _kpas$wd,_tcp
8-kpasswd._udp
8 Jdap. „tcp
Nan*
8®
p_gc._tcp
Si _gc._tcp.Def auk-First-Site-Name,„sites
8-kerberos._tcp
8 „kerberos .„tcp. de. „msdes
8 „kerberos.Jcp.Default-First-Site-Name, „sites
8 „kerberos. _tcp. Def auft-Ar$t-Ste-Name, „sites. de. „msdes ^_kerberos._udp
8 _kpas$wd,_tcp
8-kpasswd._udp
8 Jdap. „tcp
J-lH" _. dnsNode dnsNode dnsNode dnsNode dnsNode dnsNode dnsNode dnsNode dnsNode dnsNode dnsNode
J-lH" _. dnsNode dnsNode dnsNode dnsNode dnsNode dnsNode dnsNode dnsNode dnsNode dnsNode dnsNode
Si _ldap._tcp.7232e24a-677f-478c-b58a<0acbclf 18d2.domain$._m$dc$ dnsNode
Si _ldap._tcp.7232e24a-677f-478c-b58a<0acbclf 18d2.domain$._m$dc$ dnsNode
Si _ldap._tcp.dc. jnsdcs
Si Jdap. _tcp. Def auk-First-Site-Name. „sites
Si _ldap._tcp.dc. jnsdcs
Si Jdap. _tcp. Def auk-First-Site-Name. „sites
Л1
Л1
I* in*, mi i
I* in*, mi i
—1
—1
dnsNode dnsNode
dnsNode dnsNode
Puc. 5.15. На консоли Active Directory — Users and Computers отображена информация зоны company, com в контейнере MicrosoftDNS
Настройка кэширующего сервера имен
Кэширующий сервер имен используется для ускорения обработки запросов с помощью поддержки большого кэша результатов преобразования имен. На кэширующем сервере не хранится файл зоны, и поэтому он не является авторитетным ни для одной зоны. Записи ресурсов предоставляются другими DNS-серверами, которые получают запросы пользователей от кэширующего сервера.
Кэш имен хранится в памяти, поэтому на кэширующем сервере должен быть установлен достаточный объем оперативной памяти. Чтобы быстро узнать объем памяти, выделенный для службы DNS, можно воспользоваться программой Task Manager (Диспетчер задач). Перейдите на вкладку Processes (Процессы) и найдите процесс dns. ехе. Здесь можно проследить, как изменяется потребление памяти с течением времени.
Для сброса содержимого кэша можно перезапустить службу DNS или воспользоваться утилитой dnscmd, а именно — командой dnscmd /clearcache. Стоит заметить, что очистка кэша противоречит самому назначению кэширующего сервера. Если для обеспечения необходимого уровня производительности приходится часто очищать кэш, возможно, стоит увеличить объем оперативной памяти.
Кэширующий сервер не получает файлы зон, поэтому добавлять его в список вторичных серверов не обязательно.
Начало процедуры установки кэширующего сервера аналогично последовательности действий при установке первичного DNS-сервера. Отличаются только операции по настройке, которые приведены в процедуре 5.16. Установка первичного DNS-сервера описывалась в разделе “Установка и настройка DNS-сервера” этой главы.
Процедура 5.16. Настройка кэширующего сервера имен
Откройте консоль DNS.
Щелкните правой кнопкой мыши на пиктограмме сервера и выберите команду Properties (Свойства) из контекстного меню.
В окне Properties (Свойства) перейдите на вкладку Root Hints.
С помощью кнопки Remove (Удалить) удалите из списка серверы верхнего уровня.
Щелкните на кнопке Add (Добавить). Откроется окно New Resource Record (Новая запись ресурса), в котором присутствует вкладка Name Server (NS).
Введите полностью определенное имя первичного сервера и его IP-адрес. Щелкните на кнопке Add (Добавить). В список можно добавить несколько серверов преобразования имен. При этом серверы не обязательно должны находиться в одной зоне.
Щелкните на кнопке ОК, чтобы сохранить записи и вернуться в окно Properties (Свойства).
Щелкните на кнопке ОК, чтобы сохранить информацию списка и вернуться на консоль DNS.
Закройте консоль.
Убедитесь, что кэширующий сервер работает. Для этого отправьте несколько тестовых ping-пакетов с клиента этого DNS-сервера на удаленные хосты, чтобы заполнить кэш сервера. Затем отправьте ping-пакеты на эти же хосты с другого (соседнего) клиента. Во второй раз время ответа DNS-сервера должно быть намного меньше.
Настройка DNS-сервера на использование переадресующего сервера
Можно настроить DNS-сервер таким образом, чтобы при получении запроса на преобразование имени для внешнего хоста этот запрос передавался переадресующему серверу (forwarder). Предполагается, что переадресующий сервер уже получал такой запрос и содержит адрес в кэше. Если запись в кэше отсутствует, переадресующий сервер переходит по иерархии серверов и находит интересующую клиента запись.
До настройки сервера на отправку запросов переадресующему DNS-серверу стоит уведомить об этом администратора этого внешнего сервера. На переадресующий сервер могут отправляться тысячи запросов.
Предположим, что настраивается сервер внутри локальной сети, защищенной брандмауэром, а переадресующий сервер (который и занимается преобразованием имен хостов в Интернет) находится вне зоны защиты брандмауэра. Последовательность действий по использованию переадресующего сервера изложена в процедуре 5.17.
Процедура 5.17. Настройка DNS-сервера на использование переадресующего сервера
Откройте консоль DNS.
Щелкните правой кнопкой мыши на имени сервера и выберите из контекстного меню пункт Properties (Свойства).
В открывшемся окне Properties (Свойства) перейдите на вкладку Forwarders (Переадресация).
Установите флажок Enable Forwarders (Разрешить переадресацию).
Введите IP-адрес переадресующего DNS-сервера и щелкните на кнопке Add (Добавить) для добавления этого адреса в список.
Оставьте значение параметра Forward Time-Out (seconds) (Задержка переадресации (сек)) равным пяти секундам. Переадресующий сервер должен получать ответ из собственного кэша, что не требует длительного периода ожидания. Если ответ на запрос не доставлен за указанный промежуток времени, то выполняется стандартный поиск записи.
Щелкните на кнопке ОК, чтобы сохранить заданные параметры и вернуться на консоль DNS.
Остановите и перезапустите службу DNS, щелкнув правой кнопкой мыши на пиктограмме сервера и выбрав из контекстного меню команду All Tasks^Restart (Все задачи1^Перезапустить).
Убедитесь, что переадресующий сервер обрабатывает поступающие от клиента DNS запросы на преобразование имен узлов в Интернете. Для этого отправьте тестовый ping-пакет, ответ на который должен быть получен после небольшой задержки. Если ответ не получен, то проверьте, правильно ли задан IP-адрес переадресующего сервера.
Управление службой Dynamic DNS
Поддержка актуального состояния традиционной зоны DNS требует значительного объема ручного труда. В больших сетях с тысячами серверов для управления службой DNS потребуется целый рабочий день администратора. При использовании службы Dynamic DNS клиенты и серверы автоматически регистрируют свои A-записи во время загрузки. Серверы приложений могут регистрировать записи SRV и другие специальные записи. Устаревшие записи периодически удаляются. Все действия выполняются автоматически. Служба Dynamic DNS не заменит администратора DNS, но этой службы достаточно, чтобы освободить человека от лишней работы.
В этом разделе рассматривается включение службы Dynamic DNS в операционной системе Windows Server 2003, обеспечение безопасности (чтобы только Доверенные клиенты могли регистрировать собственные записи), а также вопросы поддержки зоны и предотвращения накопления устаревших записей.
Настройка динамической зоны
После установки и настройки службы DNS под управлением операционной системы Windows Server 2003 включите Dynamic DNS для конкретной зоны, как в процедуре 5.18.
Процедура 5.18. Настройка динамической зоны
Откройте консоль DNS.
Щелкните правой кнопкой мыши на строчке зоны, которую необходимо настроить для динамического обновления, и выберите из контекстного меню пункт Properties (Свойства). Откроется окно Properties (Свойства).
В раскрывающемся списке Allow Dynamic Updates (Разрешить динамические обновления) выберите вариант Yes (Да).
Чтобы сохранить внесенные изменения и вернуться на консоль DNS, щелкните на кнопке ОК.
Проверьте работу динамической регистрации. На клиенте DNS под управлением операционной системы Windows Server 2003 откройте окно командного интерпретатора и введите команду ipconfig /registerdns. Запись узла будет добавлена в файл зоны автоматически. Для просмотра этой записи может потребоваться обновление содержимого консоли.
Обратные зоны также придется настроить на динамическое обновление. Если этого не сделать, при регистрации нового клиента служба DNS будет добавлять записи А, но не будет создавать соответствующие записи PTR.
Управление безопасностью динамической регистрации
При активизации службы Dynamic DNS без обеспечения безопасности подключившийся к сети компьютер способен переписать запись А, соответствующую уже работающему в сети компьютеру. Это может привести к нарушению работы сети. Представьте, что почтовая стан-
ция компании называется MAIN-РО. Пользователь может включить рабочую станцию MAIN- РО и служба DNS перепишет запись А, соответствующую почтовой станции. Опытный хакер при этом способен доставить массу неприятностей.
Единственный способ предотвратить подобную ситуацию заключается в интеграции зоны в Active Directory. При этом запросы динамической регистрации должны приниматься только от членов домена. Такое решение позволяет избежать перезаписи содержимого зоны, поскольку два компьютера в пределах Active Directory не могут иметь одинаковых имен.
После интеграции зоны в Active Directory записи ресурсов защищаются с помощью механизмов безопасности Active Directory. Клиенты DNS, не входящие в домен, не смогут регистрировать записи хостов. На рис. 5.16 показана запись системного журнала с сообщением об ошибке, внесенная службой dnsapi на клиенте DNS под управлением операционной системы Windows Server 2003. Ошибка возникла в результате попытки зарегистрировать запись хоста клиентом, который не является членом домена.
Недостатком такого метода обеспечения безопасности является необходимость использования новых версий операционной системы Windows на компьютерах клиентов. Ведь на клиентских компьютерах может вообще не использоваться операционная система Windows. Для автоматической регистрации клиентов DHCP придется использовать службу DHCP под управлением операционной системы Windows Server 2003 и Windows 2000. Дополнительную информацию по этой теме можно получить в разделе “Настройка службы DHCP для взаимодействия с DNS”.
Рис. 5.16. В сведениях о событии из системного журнала предоставляется сообщение об ошибке при попытке регистрации клиента, который не является членом домена
Отключение службы DNS на определенном интерфейсе
Если вы не хотите интегрировать динамическую зону в Active Directory, то, по крайней мере, можно предпринять несколько действий, чтобы запретить внешним клиентам регистрировать записи на сервере. Если на DNS-сервере установлено два сетевых интерфейса, один из
которых подключен к общедоступной сети, а второй — к локальной сети, службу DNS (а также динамическую регистрацию клиентов DNS) можно отключить на том интерфейсе, который подключен к общедоступной сети. Необходимые для этого действия рассматриваются в процедуре 5.19.
Процедура 5.19. Отключение службы DNS на определенном интерфейсе
Откройте консоль DNS.
Щелкните правой кнопкой мыши на пиктограмме сервера и выберите Properties (Свойства) из контекстного меню. В открывшемся диалоговом окне по умолчанию открыта вкладка Interfaces (Интерфейсы).
В группе Listen On (Ожидать запросов) выберите Only the Following IP Addresses (Только co следующих IP-адресов).
Воспользуйтесь кнопкой Remove (Удалить) и удалите все интерфейсы, кроме интерфейса локальной сети.
Чтобы сохранить внесенные изменения и вернуться на консоль DNS, щелкните на кнопке ОК.
Закройте консоль.
Совет по использованию реестра: динамические обновления
Значение параметра Listen On соответствует следующей записи системного реестра:
Раздел: HKLM\System\CurrentControlSet\Services\TcpIp\Parameters\Interfaces\ {QUID}
Запись: DisableDynamicUpdate
Значение: 0x1 — динамические обновления отключены; 0x0 — динамические обновления включены
Настройка сборки мусора
Динамически зарегистрированные записи могут устареть, если компьютер аварийно завершает работу или подключается к сети через неравномерные промежутки времени, как это происходит с портативными компьютерам^. При активации сборки мусора службой DNS добавляется параметр устаревания к каждой динамически зарегистрированной записи. Во время сборки мусора удаляются все записи, которые не обновлялись в течение 14 дней.
После активизации сборки мусора происходит изменение формата файла зоны с целью поддержки дополнительного параметра устаревания. Технология этого преобразования является коммерческой тайной, поэтому файл зоны не получится перенести на другой сервер, который не работает под управлением операционной системы Windows Server 2003. Стандартный вторичный сервер имен сможет получать такой файл зоны после своего запроса, поскольку при переносе зоны DNS-сервер автоматически отфильтровывает параметр устаревания записи.
Сборку мусора можно включить для одной зоны или для всех зон на сервере. Последовательность действий для активизации сборки мусора для одной зоны рассмотрена в процедуре 5.20.
Процедура 5.20. Настройка сборки мусора
Откройте консоль DNS.
Щелкните правой кнопкой мыши на пиктограмме зоны и выберите команду Properties (Свойства) из контекстного меню.
На вкладке General (Общие) открывшегося диалогового окна щелкните на кнопке Aging (Устаревание). Откроется окно Zone Aging/Scavenging Properties (Устаревание зоны/Свойст- ва сборки мусора).
Выберите Scavenge Stale Resource Records (Удалять устаревшие записи ресурсов).
Оставьте значения параметров No-Refresh Interval (Период без обновления) и Refresh Interval (Период обновления) установленными по умолчанию.
Щелкните на кнопке ОК для сохранения изменений. Будет выдано предупреждение о смене формата файла зоны.
Для подтверждения смены формата щелкните на кнопке Yes (Да).
Чтобы сохранить внесенные изменения и закрыть окно Properties (Свойства), щелкните на кнопке ОК.
С этого момента при регистрации записей устанавливается параметр устаревания. Устаревшие записи удаляютс^ при выполнении сборки мусора. В процедуре 5.21 рассказано о том, как задать периодическую сборку мусора.
Процедура 5.21. Настройка периодической сборки мусора
Щелкните правой кнопкой мыши на пиктограмме сервера и выберите команду Properties (Свойства) из контекстного меню. Откроется окно Properties (Свойства).
Перейдите на вкладку Advanced (Дополнительно), которая показана на рис. 5.17.
Выберите Enable Automatic Scavenging of Stale Records (Разрешить автоматическое удаление устаревших записей).
Оставьте установленное по умолчанию значение параметра Scavenging Period (Промежуток между сборками мусора).
Чтобы сохранить внесенные изменения и закрыть окно, щелкните на кнопке ОК.
StRVtRl PropertiesStRVtRl Properties.11*1
StRVtRl Properties
StRVtRl Properties
Debug Loggng | EwntUodv I Ма**е | 5**»Hatocet | Fowadee Advaeed | RoaHnte
Senei метаем ntfnber ^Disable recursion1
®BIND secondaries □Fai on bad if bad zone data ^Enable rouryd robin Enable netmask ordering P-Secure cache against pollution
Nweehectim: '' |Mdtibyte(UTF0]3
lbpd«**daUonst*Mx[FrornXt^ve Difecto^‘ and registry ^ 11
Sceenengpaad|7|d^3
RwatoDefed |
I' OK I Cam I Ди» (.
Рис. 5.17. На вкладке Advanced окна свойств сервера DNS можно задать автоматическую сборку мусора
Желательно регулярно проверять состояние файла зоны, чтобы убедиться, что сборка мусора работает. Если в файле присутствует много устаревших записей, которые должны быть удалены, запустите сборку мусора вручную. Если сборка мусора завершится удачно, проверьте
параметры, устанавливающие период между сборками мусора. Если попытка сборки мусора завершится неудачей, проверьте параметры сборки мусора для этой зоны.
Перенаправление WINS
Хотя перенаправление WINS не является возможностью службы Dynamic DNS, эта тема рассматривается именно здесь, поскольку по сути смысл этих служб совпадает.
В операционной системе Windows NT 4.0 для службы DNS компания Microsoft представила новые записи ресурсов DNS, WINS и WINS-R, в которых сохраняется IP-адрес сервера WINS. Сервер WINS используется при отсутствии нужной записи в локальном файле зоны. Записи WINS и WINS-R добавляются на специальной странице в окне свойств зоны. Чтобы перейти к этой странице, щелкните правой кнопкой мыши на пиктограмме зоны и выберите из контекстного меню команду Properties (Свойства). В открывшемся окне откройте вкладку WINS. Такая же страница для записи WINS-R доступна в окне Properties (Свойства) для обратной зоны. Пример показан на рис. 5.18.
По умолчанию флажок Use WINS Forward Lookup (Использовать прямое преобразование WINS) сброшен. Если его установить, будет создана запись ресурса WINS. DNS-сервер под управлением операционной системы Windows Server 2003 определяет наличие записи WINS и использует указанный адрес для перенаправления запросов серверу WINS.
При активизации перенаправления запросов на сервер WINS укажите как минимум один IP-адрес сервера WINS. После ввода адреса щелкните на кнопке Add (Добавить). Для обеспечения отказоустойчивости лучше указать несколько серверов WINS.
По умолчанию флажок Do Not Replicate This Record (He реплицировать эту запись) сброшен. Это позволяет предотвратить репликацию записи WINS на другие DNS-серверы, которые не поддерживают такой тип записи.
Настройка дополнительных параметров DNS-сервера
На вкладке Advanced (Дополнительно) в окне свойств DNS-сервера доступно несколько дополнительных параметров настройки DNS-сервера. Некоторые из них рассмотрены в других разделах этой главы. В этом разделе приводятся параметры, которые еще нигде не рассматривались. Последовательность действий, необходимая для доступа к дополнительным параметрам, описана в процедуре 5.22..
Процедура 5.22. Доступ к дополнительным параметрам DNS-сервера
Откройте консоль DNS.
Щелкните правой кнопкой мыши на пиктограмме DNS Server (DNS-сервер) и выберите из контекстного меню команду Properties (Свойства).
В открывшемся окне перейдите на вкладку Advanced (Дополнительно).
В этом окне доступны следующие параметры.
Disable Recursion (Блокировать рекурсивные запросы). По умолчанию DNS-сервер, работающий под управлением операционной системы Windows Server 2003 или Windows, принимает рекурсивные запросы. Это позволяет серверу выполнить рекурсивное преобразование для клиента и является предпочтительным режимом работы. Параметр Disable Recursion заставляет сервер DNS принимать только итеративные запросы.
BIND Secondaries (Вторичные серверы BIND). По умолчанию сервер DNS под управлением операционной системы Windows Server 2003 или Windows 2000 выполняет передачу зоны, копируя несколько записей в сжатой форме. Если в качестве вторичного сервера используется BIND 4.9.4 или более ранняя версия, включите этот параметр.
Fail On Load if Bad Zone Data (He загружаться при повреждении данных зоны). См. врезку “Запуск DNS из загрузочного файла BIND".
Enable Round Robin (Активизировать функцию Round Robin). Если для узла существует несколько записей А, служба DNS возвращает только одну запись. Если установить этот параметр, DNS-сервер сможет выдавать существующие записи по очереди, регулируя нагрузку на хост.
Enable Netmask Ordering (По маске подсети). Иногда файл зоны содержит несколько записей ресурсов, соответствующих определенному запросу. При установке этого параметра DNS-сервер сортирует ответы таким образом, чтобы в первую очередь предоставлялись адреса узлов из той же подсети, в которой расположен клиент. В противном случае ответы выдаются в порядке, в котором они указаны в файле зоны. Этот параметр отменяет действие предыдущего параметра.
Secure Cache Against Pollution (Защитить кэш от накопления мусора). Все серверы имен кэшируют результаты запросов для ускорения последующих преобразований этой записи. Одним из методов атак хакеров является использование перенаправления, которое заключается в размещении в кэше некорректной записи. После этого подложная запись в кэше приведет к перенаправлению пользователей на контролируемый хакером хост. Если пользователь переходит на сайт www.company.com и пользовательский сервер имен содержит псевдоним для www. company. com, который содержит указатель на хост www. competitor. com, то запись А для узла www. competitor. com будет добавлена в кэш локального сервера имен. Возврат записи из одного домена DNS в ответ на запрос для другого домена DNS может привести к подмене кэша (cache pollution). Установка параметра Secure Cache Against Pollution позволяет защитить кэш от сохранения подложных
записей благодаря кэшированию только тех запросов, которые совпадают с корневым доменом в запросе.
Name Checking (Проверка имен). По умолчанию служба Microsoft DNS разрешает использовать в DNS-имени хоста любой символ ANSI. Не все эти символы описаны в документе RFC 1123, “Requirements for Internet Hosts — Application and Support”. Если используются серверы имен под управлением программного обеспечения не от компании Microsoft или предполагается взаимодействие с такими серверами, выберите значение параметра Strict RFC (ANSI). Если используются только серверы под управлением программного обеспечения от компании Microsoft и необходима поддержка имен в формате Unicode, выберите значение параметра Multibyte (UTF8).
Enable Automatic Scavenging of Stale Records (Разрешить автоматическое удаление устаревших записей). Использование этого параметра было рассмотрено в процедуре 5.20 “Настройка сборки мусора”.
Запуск DNS из загрузочного файла BIND
Операционная система Windows Server 2003 поддерживает загрузку на основе информации файлов, которая используется сервером BIND. Если DNS-сервер под управлением операционной системы Windows Server 2003 необходимо загрузить с помощью загрузочного файла от сервера BIND, скопируйте файл в каталог \Windows\System32\DNS. После этого настройте метод загрузки, как показано в процедуре 5.23 (в каталоге \windows\System32\dns\ Samples сохранен пример загрузочного файла).
Процедура 5.23. Запуск DNS из загрузочного файла BIND
Откройте консоль DN S.
Щелкните правой кнопкой мыши на пиктограмме сервера DNS и из контекстного меню выберите команду Properties ( Свойства).
В открывшемся окне перейдите на вкладку Advanced (Дополнительно).
В разделе Load Zone Data on Startup (Загружать файл зоны при запуске) выберите значение From File (Из файла).
Чтобы сохранить изменения и закрыть окно, щелкните на кнопке ОК.
Закройте консоль.
Иногда в файле BIND содержатся данные, формат которых не совпадает с форматом файла зоны для DNS-сервера от компании Microsoft. Нередко, например, присутствует запись псевдонима (запись CNAME), который совпадает с именем узла. В таком случае служба DNS проигнорирует некорректную запись и внесет сообщение в журнал собьп'ий. Загрузка файла зоны продолжится. Как остановить загрузку файла зоны в случае ошибки, описано в процедуре 5.24.
Процедура 5.24. Прекращение загрузки файла зоны при возникновении ошибки
Откройте консоль DNS.
Щелкните правой кнопкой мыши на пиктограмме сервера DNS и из контекстного меню выберите команду Properties (Свойства).
В открывшемся окне перейдите на вкладку Advanced (Дополнительно).
В группе Server Options (Параметры сервера) выберите значение Fail on Load if Bad Zone (He загружаться при повреждении данных зоны).
Чтобы сохранить изменения и закрыть окно, щелкните на кнопке ОК.
Закройте консоль.
Просмотр зон с помощью утилиты ns lookup
Если в работе службы DNS возникли проблемы, для их диагностики, в первую очередь, приходится использовать утилиту ns lookup. Эта утилита позволяет реализовать частичный перенос зоны, после чего можно просмотреть сохраненные записи файла зоны. Кроме этого, с помощью утилиты nslookup можно убедиться в существовании DNS-сервера, определить, какую зону он обслуживает, проверить, хранится ли на DNS-сервере конкретная запись, а также просматривать записи ресурсов так же, как файлы каталога.
Утилита nslookup поддерживает два режима работы: интерактивный и в режиме командной строки. Для получения IP-адреса для узла www. guam. net и просмотра списка серверов, которые авторитетны для зоны, содержащей запись А для этого узла, воспользуйтесь командой nslookup, указав имя узла в качестве параметра.
С:\>nslookup www.guam.net с.root-servers.net.4.33.192.in-addr.arpa
1> nameserver = NS.PSI.NET
NS.PSI.NETinternet address = 192.33.4.10
Name:www.guam.net
Served by:
- NS.GUAM.net
198.81.233.2
GUAM.net
Для перехода в интерактивный режим введите nslookup без параметров.
При входе в интерактивный режим отображаются принятый по умолчанию сервер имен и приглашение на ввод команды (>).
U:\>nslookup
Default Server: dnsl.primenet.net
Address:206.165.5.10
В командной строке можно ввести знак вопроса (?) и получить список доступных команд утилиты nslookup.
Для просмотра принятых по умолчанию параметров утилиты nslookup введите set all (в командной строке нельзя ввести одну только команду set; в таком случае утилита nslookup воспримет set, как имя узла), например:
> set all
Default Server: dnsl.primenet.net
Address:206.165.5.10
Set options:
nodebugdefnamesearchrecurse
nod2novcnoignoretcport=53
querytype=Aclass=INtimeout=2retry=3
root=a.root-servers.net.domain=company.com
srchlist=coihpany. com
В следующих разделах рассматриваются самые распространенные параметры утилиты nslookup и команды интерактивного режима.
server
Эта команда используется для изменения DNS-сервера, к которому обращается утилита nslookup для обработки запросов. Убедитесь, что указано полностью определенное имя узла с завершающим символом точки. Например, если принятое по умолчанию имя сервера выглядит, как dnsl. company. com, и необходимо продиагностировать другой DNS-сервер, например dns 02. company. com, введите следующую команду.
> server dns02.company.com.
Default server: dns02.company.com
Address:16.5.1.10
server
Команда Iserver работает, как и команда server, но всегда использует имя сервера, принятого по умолчанию. Эта команда позволяет выйти из тупика, когда указанный в параметре команды server сервер не является авторитетным и не в состоянии преобразовать имя другого сервера. Если с помощью команды server указать сервер, на котором не хранится файл зоны, то выбрать другой сервер с помощью команды server будет невозможно, поскольку текущий сервер не сможет преобразовать имя нового сервер». Команда Iserver позволяет вернуться к первоначальному серверу DNS.
root
Эта команда работает, как и команда server. Она позволяет изменить принятый по умолчанию DNS-сервер, но выбирается первое имя сервера из списка в файле cache. dns. Обычно это общедоступный сервер верхнего уровня. Если сервер является сервером верхнего уровня в частной подсети, то в файле зоны будут записи для одного или нескольких внутренних серверов имен.
18
С помощью этой команды можно получить перечень записей ресурсов в заданной зоне. Таким образом, выполняется перенос зоны для определенного типа записей. Объем передаваемых данных можно ограничить с помощью параметра -t. Ниже приведен пример отчета о записях хостов (запись А) в зоне company. com.
> Is -t а company.com.
[dcOl.company.com]
company.com.
A
10.1.1.1
gc._msdcs.company.com.
A
10.1.1.1
dns01.branchi.company.com.
A
10.3.1.1
dcOl.company.com.
A
10.1.1.1
nt30 .company.com.
A
10.1.1.201
Если в качестве типа записи указать any или воспользоваться параметром -d, вместе с командой 1s, то утилита nslookup осуществит перенос всего файла зоны. Предупреждаем, что этот список может оказаться очень объемным. Для сохранения результатов выполнения команды 1s в файл воспользуйтесь командой перенаправления (>).
Можно подумать, что команда 1 s может стать причиной возникновения бреши в системе безопасности. Так оно и есть. Поскольку команда 1 s осуществляет перенос зоны, ее можно блокировать, указав список серверов, которым разрешено получать зону. Дополнительная информация приводится в разделе “Активизация переноса зоны и рассылки уведомлений об изменениях”.
set [по]debug
При установке параметра debug в отчет интерактивного режима добавляется “отладочная” (дополнительная) информация. Выводятся имена промежуточных серверов имен, которые используется при обработке запроса. Ниже показан результат выполнения рекурсивного запроса на преобразование имени roswelInm. org.
set debug
roswellnm.org.
Server: proxy7.az.farlap.com
Address: 24.1.208.35
Got answer:
HEADER:
opcode = QUERY, id = 2, rcode = NOERROR
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 3, additional = 3
QUESTIONS: roswellnm.org, type = A, class = IN
ANSWERS:
-> roswellnm.org
- internet address = 209.35.62.148 ttl = 900 (15 mins)
AUTHORITY RECORDS:
-> roswellnm.org nameserver = dnsl.interland.net ttl = 0 (0 secs)
ADDITIONAL RECORDS:
-> dnsl.interland.net internet address = 64.224.20.132 ttl = 900 (15 mins)
Name:roswellnm.org
Address:209.35.62.148
Этот параметр полезен при обнаружении некорректных ссылок при неправильной настройке делегирования.
set [no]d2
Этот параметр используется, если результатов, предоставленных с помощью параметра set [no] debug, недостаточно и необходимо получить точный формат самого запроса. Ниже приведена дополнительная информация о запросе на преобразование имени roswel Inm. org при установке параметра d2.
set d2
roswellnm.org.
#здесь удаленная часть листинга
SendRequest(), len 32
HEADER:
opcode = QUERY, id = 10, rcode = NOERROR
header flags: query, want recursion
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
Roswellnm.org, type = A, class = IN
set [no]defname
Можно заметить, что в конце имени каждого сервера присутствует точка. Точка указывает утилите nslookup, что это полностью определенное имя. Без точки утилита nslookup автоматически добавит вместо клиента принятое по умолчанию доменное имя. Если вы постоянно забываете ввести точку, воспользуйтесь командой set nodefname, чтобы запретить утилите nslookup добавлять доменное имя.
set [по]recurse
Если утилита nslookup должна имитировать DNS-сервер, а не клиент DNS, запросы должны выполняться итеративно, а не рекурсивно. Этот параметр используется для изменения типа запросов.
set querytype
Область действйя запроса можно изменить или ограничить. Для этого необходимо выбрать определенный тип записи. Чтобы получить только записи MX, например, воспользуйтесь следующей командой.
set type=mx
roswellnm.org.
Server:proxy7.az.farlap.com
Address: 24.1.208.35
Non-authoritative answer:
roswellnm.org MX preference = 5, mail exchanger = mail.roswellnm.org
roswellnm.org nameserver = DNS1.INTERLAND.NET
mail.roswellnm.orginternet address = 209.35.103.30
DNS1.INTERLAND.NETinternet address = 64.224.20.132
Управление службой DNS в режиме командной строки
Консоль DNS Management предоставляет графический интерфейс для работы с серверами DNS. Консоль можно использовать для подключения к любому серверу под управлением операционной системы Windows Server 2003 или Windows 2000. Если вы предпочитаете работать в режиме командной строки, воспользуйтесь утилитой dnscmd.
Эта утилита поддерживает все операции, которые поддерживаются консолью DNS. Поддерживаются удаление и добавление записей, просмотр содержимого файлов зон, сброс данных службы DNS, интеграция DNS-зоны в Active Directory, сборка мусора и очистка кэша DNS. Потратив немного времени и воспользовавшись программой для написания сценариев, можно создать набор утилит, которые выполняют все необходимые операции.
Для утилиты dnscmd предоставляется интерактивная справка по доступным параметрам командной строки. В этой интерактивной справке содержится множество примеров. Если приходится управлять несколькими серверами DNS, эту утилиту стоит хорошо изучить.
Настройка службы DHCP для взаимодействия с DNS
Если в сети установлены клиенты более старых версий, не поддерживающие регистрацию в DNS, для их регистрации можно воспользоваться службой DHCP. Такая схема позволяет включить в механизм преобразования имен большое количество настольных компьютеров и серверов.
Такая возможность службы DHCP была реализована в соответствии с документом Internet Draft draft-ietf-dhc-dhcp-dns-10.txt, “Interaction Between DHCP and DNS” (“Взаимодействие между DHCP и DNS”). Этот документ описывает принципы использования нового параметра DHCP, который называется Client FQDN и имеет номер 81. Этот параметр поддерживает новый формат сообщения, который может использоваться клиентом для передачи полностью определенного доменного имени серверу DHCP. В свою очередь, эта информация используется сервером DHCP с целью отправки сообщения DNS Update на сервер DNS для регистрации клиента.
Важно! Если планируется регистрация в DNS средствами службы DHCP, необходимо интегрировать DNS-зону в Active Directory и включить безопасные обновления. Это позво-
лит защитить записи от случайной или преднамеренной перезаписи. Не устанавливайте службу DHCP на контроллере домена. Служба DHCP работает от имени учетной записи Local System, а значит, имеет неограниченные права доступа к компьютеру. В таком случае клиент DHCP может обновить любую запись на DNS-сервере, что может привести к катастрофическим последствиям.
Установка службы DHCP
Перед установкой службы DHCP необходимо просмотреть используемые IP-адреса и определить список всех узлов, использующих статические адреса. Служба DHCP под управлением операционной системы Windows Server 2003 или Windows NT 4.0 SP4 для выявления используемых адресов использует протокол ICMP, но такая проверка не гарантирует уникальности адреса. После выбора диапазона динамически предоставляемых адресов выполните последовательность действий, описанную в процедуре 5.25.
Процедура 5.25. Установка драйверов службы DHCP
На Control Panel (Панель управления) запустите аплет Add/Remove Programs (Установка и удаление программ).
Щелкните на Add/Remove Windows Components (Установка компонентов Windows). Откроется окно Windows Components (Компоненты Windows).
В открывшемся диалоговом окне выберите пункт Networking Services (Сетевые службы) и щелкните на кнопке Details (Состав). Откроется окно Networking Services (Сетевые службы).
Выберите Dynamic Host Configuration Protocol (DHCP) и щелкните на кнопке ОК, чтобы сохранить изменения и вернуться в окно Windows Components (Компоненты Windows).
Щелкните на кнопке Next (Далее). Откроется окно Configuring Components (Настройка компонентов) и начнется загрузка драйверов.
Щелкните на кнопке Finish (Готово), чтобы завершить работу мастера и вернуться в окно Add/Remove Programs (Установка и удаление программ).
Закройте окно Add/Remove Programs (Установка и удаление программ).
После этого можно настраивать установленную службу. Перезагрузка не требуется.
Авторизация сервера DHCP
После установки драйверов службы откройте консоль DHCP. На пиктограмме сервера изображена указывающая вниз красная стрелка, а это значит, что служба не запущена. Если служба устанавливается на контроллер домена или на входящий в домен сервер, в правой панели отображается состояние Not Authorized (Не авторизована). Если служба устанавливается на компьютер, который входит в рабочую группу, нажмите клавишу <F5> для обновления содержимого консоли. Состояние сервера должно измениться на Running (Работает).
Для службы DHCP в операционной системе Windows Server 2003 появилось несколько возможностей по предотвращению атак, при которых DHCP-сервер злоумышленника подключается к сети и начинает выдавать IP-адреса. При этом требуется авторизация сервера DHCP. Для авторизованного сервера DHCP создается объект DHCPClass в базе данных Active Directory. Этот объект можно просматривать с помощью консоли Active Directory — Sites and Services (Active Directory — сайты и службы). Объект доступен в разделе Services\ NetServices (рис. 5.19).
Рис. 5.19. На консоли Active Directory — Sites and Services отображается авторизованный сервер DHCPРис. 5.19. На консоли Active Directory — Sites and Services отображается авторизованный сервер DHCPДля авторизации сервера DHCP щелкните правой кнопкой мыши на пиктограмме сервера в правой панели и выберите из контекстного меню команду Authorize (Авторизовать). Объект DHCP добавляется в базу данных автоматически. После этого нажмите клавишу <F5>. Состояние сервера изменится на Running (Запущена). На рис. 5.20 отображается работающая область DHCP с выделенным диапазоном адресов.
Рис. 5.19. На консоли Active Directory — Sites and Services отображается авторизованный сервер DHCP
Рис. 5.19. На консоли Active Directory — Sites and Services отображается авторизованный сервер DHCP
Э ^ serveri.company.com[192.168.0.1] EI 1^ Scope [192.168.0.0] Phoenix j ^ Adtkess PoolЭ ^ serveri.company.com[192.168.0.1] EI 1^ Scope [192.168.0.0] Phoenix j ^ Adtkess PoolI ®-^ Reservations 4^> Scope Options-• -^ Server OptionsI ®-^ Reservations 4^> Scope Options-• -^ Server OptionsBDC.company,com bboswel.serverlO.BDC.company,com bboswel.serverlO.192.168.0.10192.168.0.11192.168.0.12192.168.0.13192,168.0.14192.168.0.15192.168.0.16192.168.0.17192.168.0.19192.168.0.191192.168.0.20192.168,0.21 >192.168.0.22192.168.0.10192.168.0.11192.168.0.12192.168.0.13192,168.0.14192.168.0.15192.168.0.16192.168.0.17192.168.0.19192.168.0.191192.168.0.20192.168,0.21 >192.168.0.22net-pro2C.company..,, blade.server4.company.com $vr2.BDC.company.com ia64.top.comnet-pro2C.company..,, blade.server4.company.com $vr2.BDC.company.com ia64.top.comLlwfWem—— 2/29/2002 9:03:07 AM 3/1/2002 12:00:57 AM 3/5/2002 12:17:49 AM 3/5/2002 1:04:46 PM 2/28/2002 9:27:10 PM 3/6/2002 5:00:07 PM 3/2/2002 7:53:59 PM 3/6/2002 11:47:15 AM 2/27/2002 9:41:43 PM 3/5/2002 9:29:19 PM 3/7/2002 7:32:09 AM 3/5/2002 2:05:33 PM 3/5/2002 2:31:00 PMLlwfWem—— 2/29/2002 9:03:07 AM 3/1/2002 12:00:57 AM 3/5/2002 12:17:49 AM 3/5/2002 1:04:46 PM 2/28/2002 9:27:10 PM 3/6/2002 5:00:07 PM 3/2/2002 7:53:59 PM 3/6/2002 11:47:15 AM 2/27/2002 9:41:43 PM 3/5/2002 9:29:19 PM 3/7/2002 7:32:09 AM 3/5/2002 2:05:33 PM 3/5/2002 2:31:00 PMУбедитесь в том, что DHCP-сервер предоставляет адреса клиентам. Для этого обновите выделенный адрес на существующем клиенте DHCP. Если клиент находится в маршрутизируемой сети с ретрансляторами DHCP, ретрансляторы необходимо настроить на использование нового сервера DHCP. После проверки базовой работоспособности отключите сервер, удалив выделенную область адресов на период настройки параметров области.
Э ^ serveri.company.com[192.168.0.1] EI 1^ Scope [192.168.0.0] Phoenix j ^ Adtkess Pool
Э ^ serveri.company.com[192.168.0.1] EI 1^ Scope [192.168.0.0] Phoenix j ^ Adtkess Pool
I ®-^ Reservations 4^> Scope Options
-• -^ Server Options
I ®-^ Reservations 4^> Scope Options
-• -^ Server Options
BDC.company,com bboswel.
serverlO.
BDC.company,com bboswel.
serverlO.
192.168.0.10
192.168.0.11
192.168.0.12
192.168.0.13
192,168.0.14
192.168.0.15
192.168.0.16
192.168.0.17
192.168.0.19
192.168.0.19
1192.168.0.20
192.168,0.21 >192.168.0.22
192.168.0.10
192.168.0.11
192.168.0.12
192.168.0.13
192,168.0.14
192.168.0.15
192.168.0.16
192.168.0.17
192.168.0.19
192.168.0.19
1192.168.0.20
192.168,0.21 >192.168.0.22
net-pro2C.company..,, blade.
server4.company.com $vr2.
BDC.company.com ia64.top.com
net-pro2C.company..,, blade.
server4.company.com $vr2.
BDC.company.com ia64.top.com
LlwfWem—— 2/29/2002 9:03:07 AM 3/1/2002 12:00:57 AM 3/5/2002 12:17:49 AM 3/5/2002 1:04:46 PM 2/28/2002 9:27:10 PM 3/6/2002 5:00:07 PM 3/2/2002 7:53:59 PM 3/6/2002 11:47:15 AM 2/27/2002 9:41:43 PM 3/5/2002 9:29:19 PM 3/7/2002 7:32:09 AM 3/5/2002 2:05:33 PM 3/5/2002 2:31:00 PM
LlwfWem—— 2/29/2002 9:03:07 AM 3/1/2002 12:00:57 AM 3/5/2002 12:17:49 AM 3/5/2002 1:04:46 PM 2/28/2002 9:27:10 PM 3/6/2002 5:00:07 PM 3/2/2002 7:53:59 PM 3/6/2002 11:47:15 AM 2/27/2002 9:41:43 PM 3/5/2002 9:29:19 PM 3/7/2002 7:32:09 AM 3/5/2002 2:05:33 PM 3/5/2002 2:31:00 PM
Puc. 5.20. На консоли DHCP отображаются авторизованный сервер DHCP и выделенный для него диапазон адресов
Настройка области адресов DHCP
После деактивации выделенной области DHCP выберите параметры области, которые будут предоставляться в АСК-пакете DHCP, отправляемом клиенту при предоставлении IP-адреса. В списке параметров области отсутствует новый параметр 81, FQDN Client. Этот
параметр настраивается отдельно при настройке свойств области. Установка этого параметра рассматривается в следующем разделе. Сейчас нам необходимо настроить основные параметры DNS-серверов, указать имя домена DNS, а также принятого по умолчанию шлюза. Настройка выделенной области адресов DHCP рассматривается в процедуре 5.26.
Процедура 5.26. Настройка параметров области DHCP
Щелкните правой кнопкой мыши на пиктограмме сервера и выберите New Scope (Новая область) из контекстного меню. Запустится мастер New Scope Wizard (Мастер создания новой области).
Щелкните на кнопке Next (Далее). Откроется окно Scope Name (Имя области). Присвойте области имя и добавьте описание, которое позволит идентифицировать область при просмотре списка на консоли.
Щелкните на кнопке Next (Далее). В открывшемся окне IP Address Range (Диапазон IP- адресов) введите диапазон адресов и маску подсети для этой области (рис. 5.21). В данном случае указана частная сеть 10.1.0.0с маской подсети 24 бит.
Щелкните на кнопке Next (Далее). Откроется окно Add Exclusions (Добавить исключения). Здесь можно указать адреса, которые уже выделены хостам или должны быть зарезервированы как статические.
|New Scope Wizard
IP Addie»» Range
You define the scope address range by identifying a set of consecutive IP addresses.
<8ack || Cenoti |
Puc. 5.21. Окно IP Address Range (Диапазон IP-адресов) мастера создания новой зоны
Щелкните на кнопке Next (Далее). Откроется окно Lease Duration (Период аренды). По умолчанию период, на который выделяется адрес, составляет восемь дней (в операционной системе WindowsNT 4.0 этот период составлял три дня). Этого достаточно, чтобы пользователь мог уйти в отпуск на неделю и, вернувшись, воспользоваться тем же адресом. Если адресного пространства не хватает, длительность аренды может быть сокращена до восьми часов.
Щелкните на кнопке Next (Далее). Откроется окно Configure Your DHCP Options (Настройка параметров DHCP). В данном случае прекратим работу' с мастером и настроим параметры из консоли DHCP. Так получается намного быстрее. Выберите No, I Will Configure These Options Later (Нет, настроить эти параметры позднее).
Щелкните на кнопке Next (Далее). Откроется завершающее окно мастера.
Щелкните на кнопке Finish (Готово), чтобы завершить работу мастера и вернуться на консоль DHCP. Теперь на консоли можно найти области с выделенным диапазоном адресов и добавленными исключениями.
Щелкните правой кнопкой мыши на пункте Scope Options (Параметры области) и выберите из контекстного меню команду New Scope Options (Новые параметры области). Откроется окно Scope Options Options (Параметры области).
Выберите Option 006 DNS Servers (Параметр 006. DNS-серверы). Введите полностью определенное имя DNS-сервера, который будет использоваться хостами этой области. Щелкните на кнопке Resolve (Преобразовать) для получения IP-адреса (автор этой книги предпочитает использовать этот метод, поскольку он позволяет быстро убедиться в работоспособности службы DNS).
Выберите Option 015 DNS Domain Name (Параметр 015. Имя домена DNS). Введите имя домена DNS (то же, что и суффикс DNS), которое будет предоставляться клиентам области. Это имя должно существовать как зона DNS на выбранном ранее сервере.
Выберите другие параметры, которые должны предоставляться клиентам. Обычно предоставляются Option 003 Router (Параметр 003. Маршрутизатор), Option 046 WINS/NBNS Servers (Параметр 046. Серверы WINS/NBNS) и 046 WINT/NBT Node Туре (Параметр 046. Тип узла WINT/NBT).
Чтобы закрыть окно, щелкните на кнопке ОК.
Щелкните правой кношсой мыши на пиктограмме Scope (Область) и выберите Active (Предоставить). После этого служба DHCP сможет отвечать на запросы клиентов DHCP и предоставлять адреса из настроенного пула. В правой панели состояние области изменится на Active.
После получения адреса клиент DHCP получает конфигурационный пакет с адресами одного или нескольких DNS-серверов. Клиент регистрирует полученный адрес, создавая записи А и PTR. Проверить регистрацию можно с помощью консоли DNS.
Настройка DNS Update Proxy
Если клиент DHCP не поддерживает Dynamic DNS Update, как это доступно для клиентов операционной системы Windows Server 2003, регистрация полученного с помощью службы DHCP адреса окажется невозможной. Это ограничивает эффективность службы DNS как хранилища имен в одноранговой сети, особенно если планируется отказаться от службы WINS.
Службу DHCP можно настроить на обновление записей на DNS-сервере. Откройте свойства сервера и перейдите на вкладку DNS (рис. 5.22).
Пиктограммы динамических клиентов
Если выделить пиктограмму Address Leases (Арендованные адреса) и просмотреть список активных клиентов DHCP, можно заметить, что пиктограммой для динамически зарегистрированных клиентов является изображение автоматической чернильной ручки.
Установка параметра Automatically Update DHCP Client Information in DNS (Автоматическое обновление информации DHCP-клиента на DNS-сервере) означает выбор параметра 81, Client FQDN для всех адресов в области. Если сбросить этот флажок, оставшиеся параметры будут недоступны. Вот описание доступных параметров конфигурации.
чргургГsubsidiary.com [142.168.0.1}Properties
Gawd DM | Advene*! f’ ’ ' *
You con «tup ta DHCP *«■ ta automolB* Kidale eAtmitoeve DNS wvweifi •» he* (A) and gotta (РИ) tecedt of DHCP cfext
17 E>ef*DHS*e*l»dWet acea*c4Weaaergeb*w
S Dyi*B*<eeawQNSAandPTRieeadii**<«gwiiedlvIheOHCPofartt
. C A^taMta*<«Mt>D№AondPTRi*>><h
P DwedAeHdPTBw*whwNaooed*tal
Г DHWecdpiaadahDleAandPrHHCadilwDHCPiAaniathaldowlitaMti«daotEva>itate.donl>iimigVAtawNT 40)
| OK | Cancel |r
Puc. 5.22. Вкладка DNS при настройке свойств сервера DHCP
Update DNS Only if DHCP Client Requests (Обновлять DNS только при запросе DHCP- клиента). Автор этой книги рекомендует использовать этот вариант. Если клиент установил параметр Register This Connection's Addresses in DNS (Регистрировать адреса этого соединения в DNS) в свойствах протокола TCP/IP, клиент принимает на себя ответственность за обновление.
Always Update DNS (Всегда обновлять DNS). Этот вариант имеет преимущество над установленным на клиенте параметром Register This Connection's Addresses in DNS и для регистрации использует полностью определенное доменное имя клиента. Если установить этот параметр, параметр 81 запретит клиенту регистрироваться в DNS.
Discard Forward (Name-to-Address) Lookups When Lease Expires (Блокировать прямые запросы по истечении срока аренды). Этот флажок установлен по умолчанию. Он управляет удалением записей А после истечения срока аренды. То же самое происходит при сборке мусора в службе DNS, но не помешает ежедневно удалять лишние записи в зоне.
Enable Updates for DNS Clients That Do Not Support Dynamic Updates (Разрешить обновление для DNS-клиентов, которые не поддерживают динамических обновлений). Этот флажок по умолчанию не установлен. Он позволяет клиентам устаревших версий регистрировать записи ресурсов. Установите этот флажок, если вы готовы к появлению нескольких тысяч записей ресурсов в файле зоны на следующее утро.
Если установить последний флажок, который позволяет регистрировать устаревших клиентов посредством ргоху-сервера, клиенты получат пиктограммы динамической регистрации при следующем обновлении аренды. При обновлении аренды обновляется и динамическая регистрация.
В следующей главе
Перед тем как переходить к более сложным темам, стоит полностью разобраться в принципах работы службы DNS, поэтому в этой главе рассматривалось несколько обширных тем. Надежная и полностью функционирующая инфраструктура DNS совершенно необходима для успешного развертывания Active Directory.
Многие читатели наверняка устали от вступительных речей, поэтому просто встречайте главную “звезду" нашего представления — службу Active Directory.
6
Службы Active Directory
В
классической операционной системе Windows NT присутствовало множество недочетов (крупных и мелких), которые ограничивали ее масштабируемость и функциональные возможности. Источником многих недочетов была неуклюжая система управления учетными записями на основе системного реестра, представлявшего собой "плоские” файлы. В классической операционной системе Windows NT не хватало настоящей службы каталогов (directory service), которая обеспечивала бы механизм управления для сети, в которой присутствуют сотни тысяч, если не миллионы, пользователей, компьютеров, групп, принтеров, общих папок, сетевых устройств и т.д.
Главной особенностью современных операционных систем Windows является служба каталогов уровня предприятия, которая называется Active Directory. В следующих шести главах будут рассматриваться настройка, развертывание, управление Active Directory и устранение ошибок в ее работе. В этой главе рассматриваются основные компоненты службы Active Directory, а также их взаимодействие. Кроме этого, рассматриваются основные утилиты, предоставленные компанией Microsoft для доступа к содержимому базы данных Active Directory и ее модификации.
Новые возможности операционной системы Windows Server 2003
В процессе создания операционной системы Windows Server 2003 компания Microsoft внесла дополнительные усовершенствования в службу Active Directory для повышения скорости и масштабируемости, а также для исправления нескольких недостатков в ключевых возможностях системы. Некоторые из внесенных изменений могут показаться бессмысленными, пока не прочитаны следующие главы, но здесь приводится краткое описание каждого усовершенствования. Для применения трех первых возможностей операционная система Windows Server 2003 должна быть установлена на каждом контроллере домена.
Масштабируемость сайтов. Новый механизм вычисления позволяет ускорить расчет топологии репликации между сайтами. Это позволяет устранить проблему возникновения ошибки при репликации, которая возникала для организаций, управляющих сотнями сай-
тов. Ошибка заключалась в том, что расчет топологии не мог завершиться в отведенное на это время.
Репликация атрибутов ссылок. Члены групп теперь реплицируются как отдельные эле’ менты, а не как единый список членов группы. Это позволяет устранить проблему перезаписи внесенных изменений для одной группы, когда изменения в группах вносились на различных контроллерах домена в течение одного интервала репликации.
Федерации. Добавлен новый тип доверительных отношений с целью упрощения создания транзитивных доверительных отношений между корневыми доменами различных лесов. При использовании нового типа доверительных отношений можно создавать федерации (federation) независимых лесов Active Directory. Эта возможность не реализует полное взаимодействие лесов Active Directory, но упрощает обслуживание организаций, состоящих из нескольких филиалов.
Упрощенная регистрация в домене. Членство в универсальных группах может быть кэшировано на неглобальном сервере каталога. В таком случае регистрация пользователя возможна даже при отключенном глобальном сервере каталога. Такая возможность удачно дополняется возможностью операционной системы Windows ХР, согласно которой результат “домен/имя” преобразования полного доменного имени пользователя (Us^r Principal Name — UPN) кэшируется локально. Это позволяет пользователю настольного компьютера под управлением операционной системы Windows ХР проходить регистрацию с помощью имени user@company. com, даже если недоступен сервер глобального каталога.
Контексты именования приложений. Операционная система Windows Server 2003 предоставляет возможность создания новых контекстов именования для хранения объектов записей DNS в базе данных Active Directory (интегрированные зоны). Один контекст именования содержит записи доменной зоны, а второй содержит записи _msdcs, которые используются в пределах леса. Эти контексты именования позволяют направлять репликацию зон DNS только на те контроллеры домена, которые поддерживают работу' службы DNS.
Защита нового контроллера домена от чрезмерной нагрузки. При модернизации контроллера домена под управлением WindowsNT4.0 до Windows Server2003 существующие клиенты под управлением Windows 2000 и Windows ХР потенциально могут начать использовать модернизированный основной контроллер домена в качестве регистрационного сервера. В операционной системе Windows Server 2003 поддерживается настройка контроллера домена на предоставление ответа, как от классического контроллера домена под управлением Windows NT, пока в сети не появится достаточно контроллеров домена для выполнения локальной аутентификации. Эта возможность также доступна в операционной системе Window's 2000 SP2 и в более поздних версиях.
Диагностика службы DNS. Правильная настройка службы DNS крайне важна для корректной работы Active Directory. Утилита активизации контроллера домена предоставляет набор тестов для диагностики службы DNS, позволяющих убедиться в наличии DNS-сервера, на котором можно зарегистрировать записи служб, соответствующие контроллеру домена.
Меньше поводов для перестройки глобального каталога. Добавление (или удаление) атрибута в глобальный каталог больше не требует полного цикла синхронизации. Это позволяет сократить объем передаваемых по сети данных репликации при добавлении атрибута в глобальный каталог.
Улучшения на консоли управления. Консоль Active Directory — Users and Computers (Active Directory — пользователи и компьютеры) теперь позволяет реализовать операции типа “перетащить и отпустить”, а также одновременное изменение свойств нескольких объектов. Кроме этого, консоль поддерживает создание и запись собственных запросов LDAP, которые упрощают управление большим количеством объектов. Новая консоль
ММС 2.0 предоставляет возможность создания сценариев, которые полностью избавляют от использования консоли.
Поддержка LDAP в реальном времени. Добавлена поддержка функциональной возможности, описанной в документе RFC 2589, “LDAPv3: Extensions for Dynamic Directory Services”. Реализация этой возможности позволяет хранить в базе данных Active Directory информацию с временными параметрами, например текущее местоположение пользователя. Динамические записи автоматически становятся недействительными по истечении определенного промежутка времени, и если запись не будет обновляться, она будет удалена.
Расширение безопасности LDAP. Добавлена поддержка аутентификации на основе дайджеста, описанной в документе RFC 2829, “Authentication Methods for LDAP”. Это упрощает интеграцию Active Directory в среду под управлением операционных систем, отличных от Windows. Кроме этого, добавлена поддержка возможностей, описанных в документе RFC 2830, “LDAP v3: Extensions for Transport Layer Security”. Это позволяет создавать безопасные соединения при отправке LDAP-запросов (Lightweight Directory Access Protocol) контроллеру домена.
Структурные усовершенствования. Добавлена возможность связывания вспомогательных классов структуры с отдельными объектами, а не с целыми классами объектов. Такая связь может быть динамической, что позволяет временно добавлять атрибуты определенному объекту или объектам. Атрибуты и классы объектов могут быть обозначены как неработающие, что упрощает восстановление после программных ошибок.
Расширения запросов LDAP. Механизм поиска LDAP расширен для поиска отдельных значений в атрибуте характерного имени (Distinguished Name — DN), содержащего несколько записей. Это так называемые запросы в пределах атрибута (Attribute Scoped Query — ASQ). Например, запрос в пределах атрибута может быть использован для быстрого получения списка групп, членом которых является определенный пользователь. Кроме этого, была добавлена поддержка представлений виртуального списка (Virtual List Views), нового элемента управления LDAP, который позволяет просматривать большие объемы данных в определенном порядке вместо просмотра информации в случайном порядке. Это усовершенствование позволяет операционной системе Windows Server 2003 показывать отсортированные в алфавитном порядке списки пользователей и групп.
Взаимодействие. Реализована функциональная возможность, описанная в документе RFC 2798, “Definition of the interOrgPerson LDAP Object Class”. Это позволяет улучшить взаимодействие со службами каталогов Netscape и NetWare, которые используют класс объектов interOrgPerson для создания объектов User.
Ускоренный ввод в эксплуатацию контроллеров домена. Добавлена возможность заполнения базы данных Active Directory на новом контроллере домена с помощью резервной копии (магнитной ленты). Это значительно упрощает развертывание контроллеров домена в ситуациях, когда нет предпосылок для развертывания полноценного сервера.
Масштабируемость. Максимальное количество объектов, хранящихся в базе данных Active Directory, возросло более чем до одного миллиарда.
Возможность применения Active Directory в виде отдельного приложейия. Новая технология ADAM (Active Directory Application Mode — режим приложений Active Directory) предоставляет возможности службы каталога для использования приложениями без необходимости внесения изменений в схемы лесов Active Directory.
Службы ADFS (Active Directory Federation Services). В операционной системе Windows Server 2003 R2 появилась новая возможность — ADFS (Active Directory Federation Services — службы объединения Active Directory). ADFS позволяет предоставить внутренние Web-приложения для внешних пользователей (заказчиков, партнеров, поставщиков), например, благодаря разрешению партнерам использовать однократную регистра-
цию (SSO). При этом операции выполняются безопасным способом, с возможностью проверки подлинности пользователя и присвоенных прав через границы предприятий и контексты безопасности.
Недостатки системы безопасности в классической Windows NT
Первые вопросы, которые возникают при знакомстве с Active Directory, — “Что это?” и “Зачем это нужно?”. В этом разделе дается ответ на второй вопрос. В остальных разделах этой главы содержится ответ на первый вопрос.
Управление учетными записями в классической сети компьютеров под управлением Windows NT имело ряд ограничений. Среди самых важных из них можно назвать следующие.
Ограниченный размер базы данных SAM
Несколько регистрационных идентификаторов
Полная зависимость от доступности одного компьютера (основного контроллера домена)
Недостаточная производительность
Недостаточная скорость репликации
Отсутствие уровней управления
Использование различных баз данных на серверах и контроллерах домена
Отсутствие поддержки транзитивных доверительных отношений
Ниже будет рассмотрено каждое ограничение и его влияние на работу операционной системы Windows NT. Это позволит понять причину появления некоторых усовершенствований при проектировании Active Directory.
Ограниченный размер базы данных SAM
Учетные записи безопасности в классической Windows NT хранятся в базе данных Security Account Manager, или SAM. SAM представляет собой базу данных на основе текстового файла и содержит множество групп и множество пользователей. Учетные записи компьютеров также хранились в базе данных SAM как специальная пользовательская учетная запись.
Структура базы данных SAM
Обычно содержимое базы данных SAM просмотреть невозможно, поскольку доступ к базе данных разрешен только учетной записи System. Если необходимо заглянуть внутрь базы данных, установите разрешения системного реестра для предоставления прав чтения учетной записи администратора или членам группы Administrators. Сами данные хранятся в зашифрованном виде в двоичном формате, но структура базы данных доступна для просмотра, как показано на рис. 6.1.
Общее количество пользователей, компьютеров и групп в классической операционной системе Windows NT было ограничено, поскольку размер базы данных SAM не мог превышать определенного значения. Это связано с ограничением на общий объем системного реестра, которое называется предельный размер системного реестра (Registry Size Limit — RSL). Размер системного реестра может достигать 80% от выгружаемого пула памяти (paged pool memory). Выгружаемый пул памяти в операционной системе WindowsNT не может превышать 192 Мбайт, а в операционных системах Windows 2000 и Windows Server 2003 — 470 Мбайт.
Reqistry LditorReqistry Lditor? 23 HKEY_UXAL_MACH1NE : ® Q HARDWARE: sQsam? 23 HKEY_UXAL_MACH1NE : ® Q HARDWARE: sQsamаЫЬаЫЬSISSISH £3 Domains B-^ Accou* $-£3 Ateses• $-23 Groups В u3 Users - ^ 000001F4 Q 000001F5 В ^ Namesj-^ Administrator 2^ GuestH £3 Domains B-^ Accou* $-£3 Ateses• $-23 Groups В u3 Users - ^ 000001F4 Q 000001F5 В ^ Namesj-^ Administrator 2^ Guest№ ®h№ ®h
Reqistry Lditor
Reqistry Lditor
? 23 HKEY_UXAL_MACH1NE : ® Q HARDWARE
: sQsam
? 23 HKEY_UXAL_MACH1NE : ® Q HARDWARE
: sQsam
аЫЬ
аЫЬ
SIS
SIS
H £3 Domains B-^ Accou* $-£3 Ateses
• $-23 Groups В u3 Users - ^ 000001F4 Q 000001F5 В ^ Names
j-^ Administrator 2^ Guest
H £3 Domains B-^ Accou* $-£3 Ateses
• $-23 Groups В u3 Users - ^ 000001F4 Q 000001F5 В ^ Names
j-^ Administrator 2^ Guest
№ ®h
№ ®h
В Ol Ateses
Q 00000220 □ 00000221 У 00000222 CJ 00000223 Q 00000226 CJ 00000227 Cl 00000228 Cj 00000228 23 0000022C
S ^ Namesy-l&l Administrators
23 Backup Operators
■23 Guests
: |^ Network Configuration Operators ^3 Power Users ^ Print Operators
: -^ Remote Desktop UsersRepfcator
Puc. 6.1. Структуру базы данных SAM можно изучить в редакторе системного реестра после установки разрешений на чтение
Параметры системного реестра, относящиеся к пулу памяти
Во всех операционных системах Windows используемая ядром память делится на выгружаемый и невыгружаемый пул памяти. Параметры пулов памяти доступны в следующем разделе системного реестра:
HKLM\System\CurrentControlSet\Control\SessionManager\Memory Management
По умолчанию для записей установлены значения "нуль", что позволяет системе реализовать динамическое управление размером пулов памяти. Без конкретных инструкций от службы Microsoft Product Support Services менять эти значения не стоит.
В современных операционных системах Windows максимальный размер системного реестра автоматически меняется при достижении реестром установленного максимального объема. Кроме этого, максимальный размер системного реестра можно изменить из пользовательского интерфейса на консоли Computer Management (Управление компьютером). Для этого выполните такую последовательность действий.
Запустите консоль Computer Management (Управление компьютером). Для этого в окне Run (Выполнить) введите команду compmgmt. ms с.
Щелкните правой кнопкой мыши на пиктограмме Computer Management (Управление компьютером) и выберите из контекстного меню команду Properties (Свойства).
Перейдите на вкладку Advanced (Дополнительно).
Щелкните на кнопкеРегкятапсе Options (Производительность).
В группе Virtual Memory (Виртуальная память) щелкните на кнопке Change (Изменить). Откроется окно Virtual Memory (Виртуальная память).
Введите новое значение в поле Maximum Registry Size (Максимальный размер реестра).
База данных SAM является только"одним из компонентов системного реестра, поэтому ее размер ограничивается еще больше. В классической базе данных SAM хватит места для хранения около 40 000 имен пользователей с учетом групп, которые необходимы для управления. Практические соображения по управлению и репликации значительно уменьшают это количество, хотя автору этой книги известна как минимум одна компания, в одном домене которой (на основе Windows NT) работало 60 000 пользователей.
Полная зависимость от доступности одного компьютера
В классическом домене Windows NT основной контроллер домена (PDC) является единственным сервером с правами на чтение и запись базы данных SAM. Если основной контроллер выйдет из строя или возникнет разрыв линии связи, то внести изменения в базу данных домена будет невозможно. Станет невозможно добавить новых пользователей в группу или добавить компьютеры в домен. Пользователи все еще смогут регистрироваться с помощью резервного контроллера домена (ВВС), но возможности изменить пароли не будет.
Для устранения такой проблемы администратору придется “повысить” резервный контроллер домена до основного. Если резервный контроллер не сможет принять на себя нагрузку основного контроллера, снизится общая производительность в сети. Еже худшей будет ситуация, когда происходит обрыв на линии соединения, с помощью которой основной контроллер подключается к остальной части домена. В этом случае даже не пробуйте преобразовать резервный контроллер домена в основной, поскольку после восстановления внешнего соединения в домене окажется два основных контроллера с отличающимися базами данных безопасности. Это заставит администратора принять соломоново решение об удалении одного основного контроллера и сохранении второго. Если коротко, то это просто катастрофа.
Недостаточная производительность
Единственный основной контроллер домена Windows NT налагает ограничения на ежедневные операции. Предположим, что в домене Windows NT работают 30 000 пользователей. Администратор находится в Омахе, а основной контроллер главного домена безопасности установлен в Бостоне. При запуске User Manager for Domains (Диспетчер пользователей домена) для добавления нового пользователя база данных SAM извлекается из основного контроллера домена, а не из локального резервного контроллера домена. В зависимости от скорости внешнего соединения сканирование большой базы данных SAM может потребовать очень много времени. Чтобы избежать подобных задержек, администраторы больших доменов Windows NT обычно пользуются утилитами с интерфейсом командной строки.
Недостаточная скорость репликации
Схема репликации по типу “звезда” в классическом домене Windows NT налагает дополнительные ограничения, кроме ограничения на размер базы данных SAM. Большая сеть с несколькими резервными контроллерами домена создает значительную нагрузку на основной
контроллер домена в процессе репликации. По умолчанию репликация осуществляется при накоплении 200 изменений, каждые семь минут или через случайный промежуток времени в диапазоне от одной до семи минут. Если нет желания ждать, пока процедура репликации скопирует изменения на удаленный вторичный контроллер домена, для принудительной репликации можно использовать Server Manager (Диспетчер серверов). Это значит, что придется запустить еще одну утилиту и подождать еще какое-то время.
Использование различных баз данных на серверах и контроллерах домена
Базы данных SAM на классическом контроллере домена и на обычном сервере имеют разные структуры. Именно по этой причине обычный сервер не может быть непосредственно “повышен” до контроллера домена или контроллер домена “понижен” до обычного сервера. Для изменения роли безопасности требуется полная переустановка операционной системы.
Отсутствие уровней управления
Основным недостатком структуры базы данных SAM на основе “плоского” файла является невозможность иерархического управления. Администраторы имеют полные права на доступ в пределах домена. Нескольким встроенным группам, например Account Admins и Server Operators,' предоставляются специальные привилегии, но нет никаких средств для локализации административных прав или создания новых групп с ограниченными правами. Существуют утилиты от третьих фирм, которые позволяют устранить этот недостаток, но такие утилиты имеют собственные недостатки, связанные с репликацией и управлением. Кроме этого, такие утилиты стоят сравнительно дорого.
Отсутствие поддержки транзитивных доверительных отношений
Среди всех ограничений классических доменов Windows NT самым серьезным является невозможность прозрачного объединения доменов с сохранением отдельных административных ролей.
Классические домены связаны доверительными отношениями (trust relationships). Контроллеры в доверяющих доменах выполняют сквозную аутентификацию (pass-through authentication) для проверки регистрационных данных пользователей из доверенных доменов. Такие доверительные отношения основаны на записях в базе данных безопасности Windows NT, которая называется LSA Secret (LSA расшифровывается как Local Security Authority — локальный администратор по обеспечению безопасности). Пара баз данных LSA Secrets, по одной в каждой базе данных SAM, связывает два домена.
Доверительные отношения в классической операционной системе Windows NT действуют только в одном направлении. Для двусторонней аутентификации можно создать парные доверительные отношения, но каждое из них действует отдельно.
Что еще хуже, классические доверительные отношения ограничены доменами, которые являются конечными точками отношения. Например, если домен А доверяет домену В, а домен В доверяет домену С, то домен А не доверяет домену С, или наоборот. Это заставляет администратора создавать множество перекрестных доверительных отношений. Операционный центр большой сети на основе Windows NT легко определить по большой схеме на стене, на которой нарисованы окружности и стрелки в разные стороны.
Несколько регистрационных идентификаторов
В идеальном случае единственная учетная запись для сетевой регистрации предоставляет доступ ко всем серверным приложениям. В прошлом разработчики приложений не спешили использовать аутентификационные механизмы на основе классического механизма регистрации Windows NT. Частично такое нежелание было связано с недостаточными функциональными возможностями API безопасности, предоставленного компанией Microsoft. Кроме этого, свое влияние оказывала сложность изменений в базе данных SAM.
Это значит, что попытка достичь истинной однократной регистрации в Windows NT была сопряжена со значительными трудностями. Это заставляло пользователей запоминать пароли для множества различных приложений, а также для сетевых учетных записей. Поскольку для различных приложений пользователи обычно выбирали один пароль, вся система безопасности становилась настолько надежной, насколько надежным был самый ненадежный компонент.
Усовершенствования, внесенные с появлением Active Directory
Перечислив множество недостатков классических доменов WindowsNT, рассмотрим решение этих проблем в Active Directory.
База данных учетных записей Active Directory в операционной системе Windows Server 2003 поддерживает хранение миллиарда объектов. Теперь можно не бояться большого количества пользователей.
Нескольким контроллерам домена предоставлены права на чтение/запись в копии базы данных Active Directory, что позволяет решить проблемы зависимости от доступности единственного сервера и низкой производительности.
Механизм репликации Active Directory поддерживает настройку на максимальное использование доступной пропускной способности. Кроме этого, новый механизм позволяет сократить объем данных, передаваемых по внешним каналам.
Сервер под управлением современной операционной системы Windows (Windows 2000 или Windows Server 2003) может быть “повышен” до контроллера домена или “понижен” до обычного сервера без переустановки операционной системы.
База данных Active Directory поддерживает создание любого количества веток в дереве для локализации и распределения административных функций.
Домены Active Directory все еще используют доверительные отношения в качестве операционной модели, но теперь доверительные отношения предоставляют полный доступ к ресурсам и являются полностью транзитивными.
Наличие действительной службы каталогов в составе операционной системы Windows усилило интерес разработчиков к возможности однократной регистрации пользователей для доступа ко всем службам. Компания Microsoft подогрела этот интерес, упростив методы доступа к базе данных безопасности и значительно расширив интерфейсы доступа.
Теперь, когда ясно, что было раньше, можно переходить к тому, что получилось в результате. В следующем разделе рассматривается современная служба каталогов.
Интеграция с доменами Windows NT 4.0
при использовании технологии ADAM
Благодаря возможности ADAM связываться с серверами Windows NT 4.0 Server для аутентификации пользователей приложения, интегрированные с каталогом Active Directory, смогут работать не только в сетях под управлением Windows Server 2000/2003, но и в устаревших
доменах Windows NT 4.0 Server. Это, в свою очередь, позволит организациям, еще не осуществившим миграцию на новейшие серверные платформы, обойтись без этой процедуры. Более подробно технология ADAM рассмотрена в конце этой главы.
Компоненты службы каталогов
Служба каталогов хранит информацию об объектах реального мира и выдает хранящуюся информацию в ответ на соответствующим образом сформулированный запрос. Сборники “Желтые страницы” представляют собой определенный тип службы каталогов. В качестве еще одного примера можно назвать библиотечный каталог.
Обычно люди предпочитают классифицировать информацию для простого извлечения. Например, в “Желтых страницах” существуют категории “Развлекательные заведения — Кинотеатры” и “Рестораны — Высшей категории”. В каталоге библиотечных карточек пункты классифицируются по категориям “Книги — Фантастика", “Книги — Классика", “Периодические издания” и т.д.
Информация должна быть доступна для чтения. Как правило, желательно получение информации по первому запросу. С другой стороны, вся информация не должна храниться в одном месте. Такое хранение информации порождает узкие места и зависимость от единственной точки доступа. Именно по этой причине информация в службе каталогов должна быть распределена по нескольким источникам. Каждый источник информации отвечает за поддержку небольшого фрагмента распределенной базы данных.
Информация должна соответствовать определенным правилам для обеспечения целостности и надежности. В рекламных сборниках “Желтые страницы” содержится минимальная информация о компаниях. Никто не станет искать в таком каталоге актуальную котировку акций компании.
Сетевая служба каталогов содержит записи о пользователях и группах, рабочих станциях и серверах, политиках и сценариях, принтерах и очередях, коммутаторах, маршрутизаторах и практически обо всех компонентах компьютерной сети. Атрибуты этих записей описывают взаимодействие объектов с сетевыми службами. Например, регистрационные данные для аутентификации могут храниться в службе каталогов, позволяя пользователям регистрироваться везде, где есть доступ к службе каталогов.
Служба каталогов не является базой данных общего назначения. Мало кто будет использовать службу каталогов для управления системой торговых точек сети магазинов по продаже видеопродукции. Но службу каталогов можно использовать для управления персоналом, который регистрируется на терминалах в торговых точках.
Наконец, служба каталогов нуждается в обслуживающих программах. Администратору нужны инструменты для добавления (или удаления) информации в службу каталогов, а также использования существующей информации. Такие программы должны иметь глобальную область действия, быть простыми в использовании и помогать в диагностике возможных проблем.
Перечислим основные вопросы. Как работает служба каталогов? Почему она работает именно так? Как происходит сбой в работе службы каталогов? Как возобновить работу службы каталогов? И главное, как использовать службу каталогов для повышения эффективности работы администратора, чтобы не приходилось тратить личное время на настройку службы, которая должна, наоборот, уменьшать объем работы администратора?
Краткая история служб каталогов
В одной старой пословице говорится, что, не зная, где находишься, не определишь, куда идешь. Перед изучением Active Directory вспомним историю служб каталогов в целом. Это не академический интерес. Очень важно знать причины принятия решений при проектировании служб каталогов, а также знать, кто принимал эти решения.
ITU-T ■ .
История служб каталогов начинается с небольшого документа, который называется Х.500, “Data Networks and Open System Communications — Directory” (“Информационные сети и взаимодействие открытых систем — Каталог”). В создании этого документа принимали участие основные производители и стандартизирующие организации всего мира.
Главной из этих организаций является International Telecommunication Union (ITU). ITU является агентством Организации Объединенных Наций и выступает в роли форума для правительств, которые хотят достичь общего понимания глобальных телекоммуникационных проблем. В ITU входят производители и поставщики услуг из 130 стран.
Telecommunication Standardization Sector, или ITU-T, является подразделением ITU, специализирующимся на рекомендациях в вопросах проектирования служб каталогов. Раньше подразделение ITU-T называлось Comite Consulted/International Telephonique et Telegraphique (ССПТ).
ITU-T выпускает рекомендации по различным областям, от требований к широковещательным технологиям и измерительному оборудованию до стандартов на передачу факсимильных сообщений. Такие рекомендации группируются в серии, обозначенные буквами. Например, серия V описывает передачу данных по телефонным сетям и содержит такие знаменитые стандарты, как V.34, “Wideband Analog Modem Communication” (“Взаимодействие с помощью аналоговых модемов”), и V.90, “Connecting Analog to Digital Modems”.
Рекомендации из серии X, в которую входит и рекомендация Х.500 относительно служб каталогов, описывают различные сети данных и открытые технологии связи, например сети с коммутацией пакетов Х.25 и системы обмена сообщениями Х.400. Полный список рекомендаций ITU доступен по адресу www. itu. int /publications/telecom.htm.
ISO
Организация ITU-T не устанавливает стандарты; она только выпускает рекомендации. Утверждение международного стандарта требует участия International Organization for Standardization (ISO). '
История названия ISO
Некоторые удивляются, почему аббревиатура ISO не соответствует полному названию организации International Organization for Standardization. На самом деле это не аббревиатура. Название происходит от греческого слова isos, которое означает "равный". Такое название было использовано, чтобы избежать путаницы при переводе названия организации на различные языки с созданием аббревиатур из собственных заглавных букв.
В отличие от ITU, членами которой являются производители, членами ISO являются национальные учреждения по стандартизации. От США членом организации является American National Standards Institute (ANSI). Сайт организации ISO доступен по адресу www. iso.ch. Домен ch предоставлен Швейцарии. Буквенные коды стран описаны в стандарте ISO 3166.
Организация ISO отвечает за стандартизацию во всех областях человеческой деятельности, от стандартов качества ISO 9000 до стандартов на размер бумаги ISO 216. В области компьютерных сетей самым знаменитым стандартом является ISO 7498, “Information Technology — Open System Interconnection — Basic Reference Model”, более известный как сетевая модель OSI.
Стандарты ISO, которые относятся к передаче данных, часто публикуются вместе с рекомендациями ITU-T. Например, стандарт ISO, который соответствует рекомендации ITU-T Х.500 для служб каталогов, называется ISO 9594 “Information Technology — Open System Interconnection — The Directory”. Поскольку организация ISO выпускает стандарты, a ITU-T выпускает рекомендации, выражение стандарт Х.500 является некорректным, но, поскольку оба документа идентичны, такое название достаточно распространено.
IEC
Организация ISO является основным всемирным органом стандартизации, но, естественно, это не единственный такой орган. Многие агентства пытаются отхватить кусок пирога стандартизации и иногда вступают в конфликты с другими участниками процесса. В области передачи данных существует частичное совпадение между стандартами, выпущенными организацией ISO, и стандартами, выпущенными International Electromechanical Commission (IEC).
IEC занимается международной стандартизацией в области электроники, магнитных и электромагнитных полей, электроакустики, телекоммуникаций и производства/распределе- ния энергии. Организация распространяет стандарты на терминологию, обозначения, методику измерений, производительность, надежность, проектирование, разработку, безопасность и требования охраны здоровья. От США в IEC также входит институт ANSI. ISO и IEC присоединились к ITU для создания стандарта на службы каталогов. Сайт организации IEC доступен по адресу www. iec. ch.
ANSI
В США существует единственный главный орган стандартизации — ANSI. Среди обычных пользователей этот институт известен по стандартизации форматов данных для хранения символов, но он выпускает стандарты практически для любых областей деятельности. Автор этой книги работал в области ядерной промышленности, где даже шариковые ручки создавались в соответствии со стандартом ANSI. Сайт ANSI доступен по адресу www. ansi . org.
IETF
В США, где миллионы люДей звонят на телевизионные передачи, чтобы дать совершенно незнакомому человеку совет по решению его сексуальных проблем, никого не удивит появление множества организаций, дающих советы институту ANSI. Internet Engineering Tash Force (IETF) является такой организацией. Эта организация оказала значительное влияние на реализацию стандарта Х.500. Сайт этой организации доступен по адресу www. let f . org.
IETF является сплавом производителей, разработчиков, ученых, проектировщиков и архитекторов, интересующихся работой сети Интернет. Рабочие группы в пределах IETF управляют процессом разработки, который называется Internet Standards Process. Это уникальная и длительная процедура, которая предусматривает безжалостное разбивание хороших идей, пока от них не останутся достаточно мелкие осколки для переваривания коллективным разумом.
Request For Comments (RFC)
Internet Standards Process обеспечивается выпуском документов Request for Comments (RFC) и Internet Drafts. Чтобы понять, насколько длительным является процесс принятия идеи в качестве стандарта, можно отметить, что из сотен и сотен документов RFC, перечисленных в RFC 2700, “Internet Official Protocol Standards”, настоящими стандартами являются только 59. Все остальные документы находятся в процессе согласования.
Копии документов RFC, стандартов, Internet Drafts и других рабочих документов можно найти на сайте IETF, а также на множестве зеркал этого сайта по всей сети Интернет. Можно воспользоваться, например, поисковым механизмом на сайте Internet Engineering Standards Repository, www. normos . org.
Организация IETF может обойти стандарты ISO/IEC и рекомендации ITU, если распространение полезного протокола признано необходимым. Примером такого протокола является |LDAP (Lightweight Directory Access Protocol — упрощенный протокол доступа к каталогам),
который представляет собой ограниченную версию службы каталогов Х.500. Этот протокол лежит в основе Active Directory, Netscape Directory Services и других продуктов.
Стандартов ISO или рекомендаций ITU для протокола LDAP не существует. Протокол LDAP родился внутри Интернет. В Active Directory реализована третья версия протокола LDAP, которая описана в документе RFC 2251, “Lightweight Directory Access Protocol v3”. В этом документе расширяется и дополняется оригинальная спецификация протокола LDAP, появившаяся в виде документа RFC 1777, “Lightweight Directory Access Protocol”. Существует большой список документов RFC, которые расширяют различные возможности протокола LDAP.
Хотя протокол LDAP и не является точной реализацией Х.500, большая часть базовых возможностей LDAP взята из стандарта Х.500, поэтому перед более подробным рассмотрением протокола LDAP уделим немного времени оригинальному стандарту.
Общие принципы стандарта Х.500
Служба каталогов является распределенным хранилищем информации о пользователях компьютерной системы и инфраструктуре, которая используется для поддержки компьютерной системы.
Целью Х.500 было преодоление конкуренции между различными информационными хранилищами для определения единого места, из которого представители различных стран могли бы получать информацию друг о друге, узнавать о вкусах других пользователей и в итоге свободно общаться друг с другом в поисках путей вселенского мира и братской любви. Служба каталогов Х.500 предоставляет следующие базовые возможности.
Информация распределена среди множества различных серверов.
Пользователи могут отправлять запросы любому серверу и получать информацию из любого сегмента системы.
Серверы способны находить информацию на других серверах, поскольку хранят информацию друг о друге.
Компоненты Х.500
Магия Х.500 рождается в гибких методах распределения информации. Такая гибкость достигается за счет сложности — не самой последней причиной сложности является запутанная терминология, компьютерный жаргон и трехбуквенные аббревиатуры. Аббревиатуры из стандарта Х.500 часто всплывают в документации по Active Directory, поэтому рассмотрим их вкратце. Общая схема сети стандарта Х.500 показана на рис. 6.2. Ниже приводится список аббревиатур для этого стандарта.
Информация в каталоге Х.500 хранится в DIB (Directory Information Base — информационная база каталога).
Информационная база каталога разделена на фрагменты, которые объединены в иерархии DIT (Directory Information Tree — информационное дерево каталога).
Каждый фрагмент информационной базы каталога хранится на сервере, который называется DSA (Directory Service Agent — агент службы каталога).
Для получения информации из Active Directory пользователь вводит запрос с помощью интерфейса приложений, который называется DUA (Directory User Agent — агент пользователя каталога).
Агент пользователя каталога связывается с агентом служб каталога при помощи протокола, который называется DAP (Directory Access Protocol — протокол доступа к каталогу).
DAPповерх OSIDAPповерх OSI(информационная база каталога)(информационная база каталога)(информационная база каталога)(информационная база каталога)ПротоколDISPПротоколDISPDAP поверх OSIDAP поверх OSIАгент DSAАгент DSADAPповерх OSIDAPповерх OSI(DSP использует► DOP)(DSP использует► DOP)Агент DUAАгент DUAАгент DUAАгент DUAАгент DUAАгент DUAДомен DMD управляется DMOДомен DMD управляется DMOДомен DMD управляется DMOДомен DMD управляется DMO
DAP
поверх OSI
DAP
поверх OSI
(информационная база каталога)
(информационная база каталога)
(информационная база каталога)
(информационная база каталога)
Протокол
DISP
Протокол
DISP
DAP поверх OSI
DAP поверх OSI
Агент DSA
Агент DSA
DAP
поверх OSI
DAP
поверх OSI
(DSP использует► DOP)
(DSP использует► DOP)
Агент DUA
Агент DUA
Агент DUA
Агент DUA
Агент DUA
Агент DUA
Домен DMD управляется DMO
Домен DMD управляется DMO
Домен DMD управляется DMO
Домен DMD управляется DMO
Рис. 6.2. Компоненты Х.500 и связанные с ними протоколы
Агенты служб каталога связывается между собой с помощью протокола DSP (Directory System Protocol —- системный протокол каталога).
Административная информация, передаваемая между агентами служб каталога, управляется политиками, определенными протоколом DOP (Directory Operational Binding Management Protocol — протокол управления связыванием каталога).
Организация управления каталогом (Directory Management Organization — DMO) управляет доменом управления каталогом (Directory Management Domain — DMD), который содержит один или несколько агентов служб каталога DSA.
Информация из одного агента служб каталога реплицируется на другой агент служб каталога в пределах того же домена управления каталогом с помощью протокола DISP (Directory Information Shadowing Protocol — протокол синхронизации информации каталога).
Протокол доступа к каталогу, системный протокол каталога, протокол синхронизации информации каталога и другие высокоуровневые протоколы связи в Х.500 используют сетевую модель OSI, определенную в рекомендации ITU X.200/OSI-EIU Standard 7498.
Пример транзакции Х.500
Рассмотрим пример взаимодействия перечисленных компонентов Х.500 (рис. 6.3). Предположим, что продавцы подержанных автомобилей в США договорились и решили сформировать ассоциацию. Служба каталогов должна использоваться для хранения информации обо всех доступных для продажи машинах.
Информационная база каталога для этой службы каталогов содержит производителей, модели, год производства, идентификационный номер автомобиля и цены. Каждому продавцу назначается организация управления каталогом (DMO), которая управляет доменом управ-
ления каталогом (DMD). Информационная база каталога (DIB) в каждом домене управления каталогом (DMD) хранится как минимум на одном агенте служб каталога (DSA), который обменивается служебной информацией с агентами служб каталога в других доменах управления каталогов при помощи протокола управления связыванием каталога (DOP). Для магазинов в одних регионах используются отдельные агенты служб каталога (DSA), реплицирующие между собой копию DIB при помощи протокола DISP. Фрагменты DIB объединяются в единое информационное дерево каталога (DIT), корень которого расположен на агенте служб каталога в штаб-квартире ассоциации.
Домен управленияДомен управлениякаталогом (DMD)каталогом (DMD)Рис. 6.3. Схема взаимодействия по стандарту Х.500Рис. 6.3. Схема взаимодействия по стандарту Х.500Домен управленияДомен управлениякаталогом (DMD)каталогом (DMD)Информационная база каталога (DIB)Информационная база каталога (DIB)
Домен управления
Домен управления
каталогом (DMD)
каталогом (DMD)
Рис. 6.3. Схема взаимодействия по стандарту Х.500
Рис. 6.3. Схема взаимодействия по стандарту Х.500
Домен управления
Домен управления
каталогом (DMD)
каталогом (DMD)
Информационная база каталога (DIB)
Информационная база каталога (DIB)
Зачем такие сложности? Представим, что покупатель в магазине города Канкаки потребует джип “Чероки” вишневого цвета. При этом продавец может воспользоваться своим агентом DSA и запросить интересующую модель у другого локального агента DSA с помощью протокола DAP. Агент служб каталога проверит собственную копию DIB и в случае отсутствия записи воспользуется системным протоколом каталога (DSP) для отправки запроса на другие агенты служб каталога, пока не будет найдена интересующая запись или не будут проверены все варианты. Агент пользователя каталога можно запрограммировать на поиск близких альтернативных вариантов, например может быть выдано предложение приобрести кремовую Chevelle в Чикаго.
Важным моментом этой транзакции является отсутствие центрального хранилища. Каждый локальный агент служб каталога хранит собственную копию информационной базы каталога. Для распределения запросов по системе используются ссылки.
Почему LDAP, а не Х.500
Существует несколько коммерческих реализаций служб каталогов на основе стандарта Х.500, но мало из них получили широкую популярность. Проблема полной реализации стандарта Х.500 связана с непроизводительными издержками всех перечисленных протоколов. Если целая армия агентов DUA с помощью протокола DAP обращается к агентам DSA, которые, в свою очередь, перенаправляют запросы другим агентам DSA с помощью протокола DSP и одновременно копируют базу DIB на другие агенты DSA в пределах домена управления каталогом с помощью протокола DISP, то есть множество вариантов сбоя в этой системе.
В начале 1990-х годов несколько умных ребят из Мичиганского университета попытались создать службу каталогов для обработки запросов от более чем 100 000 компьютеров, используемых студентами и преподавателями. Они отказались от сложности Х.500 и создали схему с сохранением структуры каталога Х.500, но использующую для доступа стандартный протокол TCP/IP, а не модель ISO. Кроме этого, они создали упрощенный механизм ссылок и более гибкую модель безопасности и устранили фиксированный протокол репликации. Результат был назван Lightweight Directory Access Protocol, или LDAP. Все остальное, как говорится, — история. Ребята-разработчики больше не управляют развитием LDAP. В настоящее время оперативная информация о протоколе LDAP доступна по адресу www. openldap. org.
Active Directory и LDAP
Принимая решение о замене неуклюжей системы управления учетными записями на основе системного реестра в Windows NT настоящей службой каталогов, компания Microsoft вместо собственной запатентованной технологии решила воспользоваться протоколом LDAP. Что более важно для администраторов, компания Microsoft для собственной реализации LDAP решила воспользоваться двумя проверенными технологиями.
Extensible Storage Engine (ESE)
В своей основе база данных службы каталогов состоит из строк, соответствующих объектам, и столбцов, соответствующих атрибутам объектов. Различные базы данных отличаются методами управления таблицами. Диспетчер таблиц обычно называется механизмом управления базой данных (database engine).
Стандарты LDAP не навязывают определенную технологию управления таблицами. Для создания диспетчера таблиц Active Directory компания Microsoft использовала расширенную версию механизма Extensible Storage Engine (ESE), который впервые появился в Exchange. Компания Microsoft выбрала ESE вместо механизма SQL Server, так как механизм управления на основе SQL работал недостаточно эффективно с объектно-ориентированной структурой каталога LDAP. С другой стороны, механизм ESE в основном предназначен для работы с объектно-ориентированными базами данных.
Система поиска на основе службы DNS
Пользователи не смогли бы использовать информацию из службы каталогов, если не имели бы возможности найти серверы, на которых хранится информация. Компания Microsoft решила создать службу каталогов LDAP на основе системы DNS (Domain Name System). Если клиенту LDAP требуется найти сервер со службой каталогов, клиент отправляет запрос на DNS-сервер. Это позволило компании Microsoft воспользоваться новыми возможностями службы DNS для упрощения поиска.
Это касается, например, сравнительно нового типа записей SRV для размещения в службе DNS указателей на серверы, поддерживающие службы LDAP и Kerberos. Записи SRV имеют относительно сложную структуру, но компания Microsoft смогла защитить администраторов от ошибок ввода, предложив автоматическую регистрацию записей средствами Dynamic DNS.
Информационная модель LDAP
Служба каталогов может быть немного сложнее базы данных, которую вы использовали для подсчета сверхурочных выплат, потерянных после перехода на позицию внештатного администратора, но базовые принципы работы двух механизмов ничем не отличаются.
Объектно-ориентированная база данных
В терминологии Х.500 база данных службы каталогов называется информационной базой каталога (DIB). Если представить службу каталогов в виде карточной системы в старой библиотеке, то информационная база каталога представляет собой большой дубовый шкаф с рядами карточек.
Структура службы каталогов Х.500 разрабатывалась в то время, когда объектноориентированные базы данных находились на острие прогресса. Тем, кто сталкивался только с более новыми реляционными базами данных, налагаемые на объектно-ориентированные базы данных ограничения могут показаться немного странными.
В объектно-ориентированных базах данных каждая запись (объект) занимает уникальное положение в иерархическом пространстве имен. Имя и путь объекта описывают его положение по отношению к вершине пространства имен. Файловая система является примером объектно-ориентированной базы данных.
Объектно-ориентированные базы данных состоят из больших структурированных последовательных файлов, соединенных наборами индексов, которые представляют собой большие структурированные последовательные файлы. Такая технология построения баз данных называется метод последовательного индексированного доступа (Indexed Sequential Access Method — ISAM). Этот термин время от времени будет встречаться в журнале событий и в других отчетах.
Механизм управления базами данных ESE предоставляет “плоскую” структуру ISAM в виде иерархии объектов. Кроме этого, компания Microsoft широко использует технологию СОМ, представляя объекты Active Directory в виде объектов СОМ при помощи интерфейса служб Active Directory (Active Directory Services Interface — ADSI).
Классы и атрибуты
Служба каталогов хранит информацию об определенных типах объектов, например объектах User, объектах Computer и т.д. Это так называемые классы объектов. Класс представляет собой набор атрибутов. На рис. 6.4 показано отношение между классами и атрибутами.
Атрибуты и свойства
Атрибуты часто называют свойствами (property). Между этими двумя терминами существует определенная разница, но она настолько незначительна, что во многих справочниках, включая и эту книгу, они используются, как синонимы.
Атрибуты определенного класса объектов отличают его от других классов объектов. Например, объекты User имеют набор атрибутов, отличающийся от набора атрибутов класса Computer или класса IP Security. Рассматривая библиотечные карточки в качестве примера, можно сказать, что различные форматы карточек будут использоваться для предметов различных классов. Один формат используется для хранения информации о книгах, другой формат используется для хранения информации о магнитных лентах. Карточки для книг будут содержать поля Название, Автор, ISBN и т.д. Карточки для магнитных лент, кроме полей для книг, будут содержать поля Читается и Время воспроизведения.
Класс объектов является не более чем именованным набором атрибутов. В документе RFC 2256, “A Summary of the X.500(96) User Schema for use with LDAPvS”, определены 21 класс и 55 атрибутов для применения в стандартной службе каталогов LDAP. Служба каталогов Active Directory использует 200 классов объектов и 1500 атрибутов.
Классы также используются для определения области видимости базы данных службы каталогов. Никто не ожидает найти в библиотечном каталоге информацию о внедорожных автомобилях или бутербродах с двойной порцией мяса. Инженеры компании Microsoft определили начальную область видимости Active Directory, включив в нее некоторые классы обь-
ектов и атрибуты. Этот список может быть расширен другими приложениями или администраторами. Например, организация может создать атрибуты и классы для хранения номеров нагрудных знаков и номеров социального страхования в базе данных Active Directory.
Класс объекта: User
Common Name(Общее имя)
Description(Описание)
Distinguished Name (Характерное имя)
ObJectGUID
ObjectSID
UnicodePwd
SamAccountName
MemberOf
Класс объекта: DHCPCIass
Common Name(Общее имя)
Description(Описание)
Distinguished Name (Характерное имя)
ObJectGUID
DHCPUniqueKey
DHCPType
DHCPFIags
DHCPServers
Puc. 6.4. Классы и атрибуты в службе каталогов
Наследование классов
Создатели службы )<аталогов старались ограничить сложность, определив минимальное количество классов и атрибутов, необходимых для описания хранящихся в базе данных объектов.
Например, в каталоге библиотечных карточек не стоит создавать класс типа “Что-то- менее-притягивающее-чем-американские-рассказы-начала-20-века”, хотя в этот класс может попасть достаточно большое количество объектов. С точки зрения всей области видимости библиотеки такая классификация будет слишком узкой. Вместо этого лучше ввести атрибут “Скучно” с булевым значением. Этот атрибут можно добавить к классу “Книга”, чтобы объектам этого класса можно было присвоить атрибут “Скучно”, для которого доступны значения “Да”, “Нет” и не имеющий значения. Кроме этого, атрибут “Скучно” можно добавить в классы “Периодика”, “Лента” и “Видео”.
В каталоге могут присутствовать сотни классов и тысячи атрибутов. Если атрибуты каждого класса определять заново, каталог будет выглядеть не как дерево, а как пример немецкого экспрессионизма.
К счастью, атрибуты определенного класса часто пересекаются с атрибутами других классов. Например список атрибутов класса Mailbox (“Почтовый ящик”) включает в себя все атрибуты класса Mail-Recipient (“Получатель почты”) и дополнительный атрибут Delivery-Mechanism (“Механизм доставки”). Поэтому вместо отдельного определения всех атрибутов класса Mailbox протокол LDAP позволяет определить этот класс в качестве дочернего по отношению к классу Mail-Recipient. Это позволяет классу наследовать атрибуты родительского класса. Разработчику останется только добавить новый атрибут, который сделает подчиненный класс уникальным.
Атрибуты передаются в иерархии классов объектов, как гены в генеалогическом дереве семьи. На рис. 6.5 показан пример наследования для класса computer.
Все классы LDAP наследуются из класса Тор. Это позволяет определить атрибуты, общие для всех классов. Например, каждый класс должен иметь атрибут Common-Name (доменное имя). Атрибут назначается классу Тор, а остальные классы просто его наследуют. '
Класс Тор можно рассматривать в качестве режиссера, который никогда не появляется в кадре, но всегда оказывает заметное влияние на конечный результат. Класс Тор является абстрактным. Всего LDAP поддерживает три типа классов.
Абстрактный. Такие классы создаются только для наследования другими классами объектов. В Active Directory существует 14 абстрактных классов, например Top, Device, Person, Security Object.
Структурный. Такие классы используются для создания объектов базы данных Active Directory, например User, Group и Computer.
Вспомогательный. Такие классы используются для расширения определений абстрактных классов для специальных случаев использования. В Active Directory существует только шесть вспомогательных классов: Mail-Recipient, Dynamic-Object, MS-MMS Object,Sam-Domain, Sam-Domain-Base и Security-Principal.
Puc. 6.5. Схема наследования для класса объектов Сотриter
Итак, существует три типа классов, которые используются подобно роботам на конвейере для сборки “объектов”. Структурные классы являются инструментами, определяющими форму объектов. Абстрактные классы являются конструкторами, которые проектируют инструменты. Вспомогательные классы выступают в роли мастерской в конце сборочной линии, где создаются специальные версии стандартных объектов.
Экземпляры классов
Каждый объект в Active Directory является экземпляром определенного класса объектов. Каждый экземпляр класса объектов отличается от других экземпляров того же класса, имея другие значения атрибутов.
Помните фильм Человек-слон'? В один из моментов Джон Меррик стоял перед толпой и кричал “Я не слон. Я человек”. Если бы мистер Меррик проектировал службы каталогов, он бы высказал свою точку зрения в такой форме: “Я экземпляр класса Человек, а не класса Слон. Единственная разница между мной и вами заключается в другом значении одного атрибута. Поэтому отстаньте от меня”.
Определение подходящих атрибутов класса объектов может оказаться сложным процессом. Незаметные отличия могут заставить дизайнера создать новый класс. При проектировании каталога библиотечных Карточек можно создать класс “Лента" с атрибутом “Тип”, который принимает два возможных значения: “Аудио” и “Видео”. Такое решение заставляет определять атрибуты класса “Лента”, которые подходят и для аудиозаписей, и для видеозаписей. После месяцев бесплодных усилий можно понять, что аудио- и видеозаписи имеют настолько разные свойства, что для них лучше создать два отдельных класса: “АудиоЛента” и “Видеолента”. Каждый класс будет обладать собственным набором атрибутов. В Active Directory и LDAP существует множество примеров, когда два класса отличаются только одним или двумя атрибутами.
Схема
Схема базы данных определяет ее содержимое и структуру. В каталоге библиотечных карточек схема будет содержать набор процедур и правил, установленных библиотекарем. “Для книг используются зеленые карточки, — сообщает библиотекарь читателю. — Для видеозаписей используются красные карточки. В этом ящике карточки отсортированы в алфавитном порядке по названию, а в этом ящике карточки отсортированы по теме.” И так далее, и так далее. Схема службы каталогов LDAP определяет такие свойства.
Атрибуты, связанные с каждым классом
Допустимые классы объектов
Отношения наследования между классами объектов, которые определяют наследование атрибутов
Тип данных, связанный с каждым атрибутом
Физическое представление объекта в пользовательском интерфейсе
Схема может иметь форму внешней таблицы, выступающей в роли словаря данных, или внутренней таблицы, которая структурирована с использованием тех же правил, что и сама база данных. В Active Directory используется внутренняя схема. Многие ограничения проектов, описанные далее в этой главе, связаны с необходимостью постоянного поддержания целостной схемы на всех серверах, которые хранят копии базы данных службы каталогов.
Далее в этой главе будет показано, как модифицировать схему Active Directory с целью добавления новых атрибутов и классов объектов, используемых приложениями для поддержки сетевых операций.
Резюме по модели LDAP
Вот важные концепции информационной модели, которые стоит помнить, проектируя службу каталогов Active Directory для собственной организации.
В LDAP используется объектно-ориентированная база данных. В Active Directory в качестве механизма управления базой данных используется Extensible Storage Engine (ESE).
Класс объекта определяет уникальный набор атрибутов для объекта определенного типа.
Класс объектов наследует атрибуты родительского класса. Это позволяет разработчику для нового класса объектов указывать только новые атрибуты.
Каждый объект является экземпляром класса объектов. Атрибутам объекта присваивают-' ся значения, которые описывают конкретный объект.
Схема определяет содержимое и структуру базы данных LDAP. В случае Active Directory схема хранится внутри самого каталога.
Схема каталога должна сохранять целостность на каждом сервере, на котором хранится копия базы данных.
Структура пространства имен LDAP
У службы каталогов есть два основных свойства. Во-первых, информация распределяется по нескольким серверам. Во-вторых, пользователи могут получить доступ к информации из каталога, отправив запрос на любой из серверов. Для этого необходимо определить пространство имен (namespace), позволяющее быстро находить расположение каждого объекта.
Общие имена
Как было показано в предыдущем разделе, в базе данных LDAP информация хранится в форме объектов. Для объектов создаются описывающие их атрибуты. Например, объект User для пользователя Том Джонс (Tom Jones) будет иметь такие атрибуты, как регистрационное имя, пароль, номер телефона, адрес электронной почты, название отдела и т.д.
Если клиенту LDAP необходимо найти информацию об объекте, отправляется запрос с характерным именем (distinguished name — DN) объекта и списком интересующих атрибутов. Поиск информации о Томе Джонсе может быть проведен несколькими методами.
Можно вести поиск атрибутов объекта User, соответствующего Tom Jones: “Выдайте значение атрибутов для объекта cn=Tom Jones , cn=Users, dc=Company, dc=com”.
Второй вариант поиска заключается в поиске по значению атрибута, чтобы в множество обнаруженных результатов входил объект Tom Jones: “Выдайте список всех объектов, атрибут Department которых имеет значение Finance”.
В любом случае LDAP сможет найти объект Тот, поскольку назначенное объекту имя описывает его место в пространстве имен LDAP.
На рис. 6.6 показан фрагмент пространства имен LDAP в Active Directory. Каждая папка представляет собой контейнерный объект, который, в свою очередь, хранит другие объекты. Исключением является объект контроллера домена, который представляет собой организационную единицу (Organizational Unit — OU). Контроллеры домена работают в отдельных организационных единицах, чтобы использовать отдельные групповые политики. Универсальные объекты Container не могут иметь связанных групповых политик.
Для объектов User на схеме есть отличительные признаки, а конкретно они начинаются с атрибута CN. Аббревиатура CN означает доменное имя (Common Name). Атрибут CN устанавливается практически для всех типов объектов. В Active Directory используется всего два атрибута объектов (хотя в LDAP определено большее количество).
Компонент домена DC (Domain Component). Объекты с атрибутом DC представляют вершину дерева LDAP, которое для определения пространства имен использует службу DNS. Служба Active Directory является примером такого дерева LDAP. Набор атрибутов для домена Active Directory с именем company.com будет выглядеть как dc=Company, dc=com.
Рис. 6.6. Пример иерархии каталога LDAP
Организационная единица OU (Organizational Unit). Объекты OU выступают в роли контейнеров, которые хранят другие объекты. Такие контейнеры позволяют структурировать пространство имен LDAP. Организационные единицы являются единственными контейнерами общего назначения, доступными администратору Active Directory. Пример имени подразделения выглядит как ou=Accounting.
Характерное имя
Имя, содержащее полный путь к объекту начиная от корня пространства имен LDAP, называется характерным именем (distinguished name) или DN. Например, характерным имени для пользователя CSantana, объект которого хранится в контейнере cn=Users в домене Company . com, будет имя cn=CSantana, cn=Users , dc=Company , dc=com.
Отличительным свойством характерных имен LDAP является обратный порядок записи. Читая имя слева направо, можно перемещаться вверх по дереву каталога. Это прямо противоположно принципа^ назначения имен в файловой системе, где чтение слева направо обеспечивает перемещение вниз по дереву.
Относительное характерное имя
Имя объекта без указания полного пути от корня пространства имен называется относительным характерным именем (Relative Distinguished Name — RDN). Доменное имя cn=CSantana является также относительным характерным именем, как и cn=CSantana, cn=Users. Относительное характерное имя служит для той же цели, что и фрагмент пути в имени файла. Это ссылка, облегчающая перемещение по дереву.
Два объекта могут иметь одинаковые относительные характерные имена, но в LDAP существует правило, в соответствии с которым никакие два объекта не могут иметь одинаковых характерных имен. Такое ограничение становится понятным, если вспомнить о том, что используется объектно-ориентированная база данных. Два объекта с одинаковыми характерными именами попытаются занять одно и то же место в базе данных. А это невозможно.
Чувствительность к регистру в именах LDAP
Характерные имена Active Directory не чувствительны к регистру. В большинстве случаев регистр введенного значения сохраняется. Это похоже на обработку регистра в файловой системе Windows. При использовании регистра можно руководствоваться личными предпочтениями или корпоративными стандартами.
Типизированное имя
Комбинация имени объекта и атрибута LDAP называется типизированным (typeful) именем. В качестве примеров можно привести cn=Administrator и cn=Administrator, cn=Users,dc=Company,dc=com.
Некоторые приложения способны анализировать имя с помощью символа разделения (точки или точки с запятой), установленного между элементами характерного имени. Например, приложение может допускать ввод Administrator. Users . Company. com вместо полного типизированного имени. Такие имена называются нетипизированными (typeless). При вводе нетипизированного имени важно правильно расставлять символы-разделители.
Созданные компанией Microsoft программы предоставляют графический интерфейс для перемещения по пространству имен LDAP, поэтому в таких случаях необязательно задумываться об интерпретации типизированных или нетипизированных имен. Но если необходимо использовать какую-либо из многочисленных программ поддержки, которые предоставляются на установочном компакт-диске операционной системы Windows Server 2003 или в составе Resource Kit, или приходится использовать сценарии для управления Active Directory, то нужно указывать типизированные имена. После непродолжительной практики быстрый ввод длинного типизированного имени перестанет вызывать какие-либо затруднения.
Информационное дерево каталога
В LDAP, как и в Х.500, серверы с копией базы данных называются агентами служб каталога и обозначаются аббревиатурой DSA. Агент службы каталога может хранить всю базу данных или ее фрагмент. Фрагменты базы данных формируют иерархию, которая называется информационным деревом каталога. Пример показан на рис. 6.7.
dc=Company,dc=US, dc=Company, dc=comdc=Company,dc=US, dc=Company, dc=comdc=comdc=comdc=Phoenix, dc=US, dc=Company, dc=comdc=Phoenix, dc=US, dc=Company, dc=comou^Accounting,ou=Engineering,dc=Phoenix, dc=US,dc=Phoenix, dc=US,dc=Company, dc=comdc=Company, dc=comou^Accounting,ou=Engineering,dc=Phoenix, dc=US,dc=Phoenix, dc=US,dc=Company, dc=comdc=Company, dc=comou=estadsticas, dc=Oaxaca, dc=Mexico, dc=Company, dc=comou=estadsticas, dc=Oaxaca, dc=Mexico, dc=Company, dc=comou=ingenier a, dc=Oaxaca, dc=Mexico, dc=Company, dc=comou=ingenier a, dc=Oaxaca, dc=Mexico, dc=Company, dc=com
dc=Company,
dc=US, dc=Company, dc=com
dc=Company,
dc=US, dc=Company, dc=com
dc=com
dc=com
dc=Phoenix, dc=US, dc=Company, dc=com
dc=Phoenix, dc=US, dc=Company, dc=com
ou^Accounting,ou=Engineering,
dc=Phoenix, dc=US,dc=Phoenix, dc=US,
dc=Company, dc=comdc=Company, dc=com
ou^Accounting,ou=Engineering,
dc=Phoenix, dc=US,dc=Phoenix, dc=US,
dc=Company, dc=comdc=Company, dc=com
ou=estadsticas, dc=Oaxaca, dc=Mexico, dc=Company, dc=com
ou=estadsticas, dc=Oaxaca, dc=Mexico, dc=Company, dc=com
ou=ingenier a, dc=Oaxaca, dc=Mexico, dc=Company, dc=com
ou=ingenier a, dc=Oaxaca, dc=Mexico, dc=Company, dc=com
Puc. 6.7. Информационное дерево каталога
На вершине информационного дерева каталога находится единственный объект. Класс этого объекта не определен в спецификации LDAP. В Active Directory этот объект является экземпляром класса DornainDNS. Поскольку для структурирования пространства имен в Active Directory используется служба DNS, для объекта DomainDNS устанавливается атрибут DC. Например, объект на вершине дерева, показанного на рис. 6.7, будет иметь характерное имя dc=Company,dc=com.
Нетипизированные имена и символы-разделители
При создании сценария, допускающего наличие точек в именах объектов, перед точкой добавляйте обратную косую черту. Это сообщит программе-анализатору, что точка является специальным символом, а не символом разделения. Например, если имя пользователя — tom. collins, то нетипизированное имя в сценарии будет выглядеть как tom\ . coilins . Users. Company. com. Это касается и имен пользователей, которые содержат запятые и точки, например Windston н. Borntotherpurple, Jr. В запросе ADSI для такого имени придется вводить winston h\. borntotherpurple\ , Jr\.
Active Directory и корневой домен DNS
Служба Active Directory не может располагать корень в самой вершине пространства имен DNS. Предполагается, что несколько пространств имен Active Directory могут иметь общий корень. Именно по этой причине объект DomainDNS на вершине дерева всегда должен иметь как минимум два атрибута.
Дерево LDAP содержит ветки, сформированные контейнерами ниже корневого контейнера. Эти контейнеры содержат объекты, связанные друг с другом, что определено в пространстве имен. Например, в Active Directory принятым по умолчанию контейнером для объектов User является cn=Users. Для объектов Computer используется контейнер cn=Computers. Информация о групповых политиках, DNS, службах удаленного доступа и т.д. хранится в контейнере cn=System. Как будет показано при обсуждении архитектуры Active Directory в главе 8, “Проектирование доменов Windows Server 2003”, администратор может создавать организационные единицы для хранения объектов с общими требованиями к управлению и настройке.
Контексты именования
С ростом количества объектов в информационном дереве каталога база данных может стать слишком большой для эффективного хранения на одном агенте служб каталога (DSA). Кроме этого, организация может потребовать более эффективного использования пропускной способности, сохранив информацию о пользователях Северной Америки на DSA в Нью- Йорке, а информацию о европейских пользователях — на DSA в Амстердаме. .
Контексты именования и разделы
В рекомендации Х.501, "Information Technology— Open System Interconnection — The Directory: Models", термин "контекст именования" (naming context) определен как "поддерево записей, хранящихся на единственном основном агенте служб каталога". Процесс разбиения дерева на несколько контекстов именования называется разделением (partitioning).
Компания Novell воспользовалась термином раздел (partition) для определения отдельного фрагмента базы данных каталогов. В книге Understanding and Deploying LDAP Directory Services Тим Xay (Tim Howe), Марк Смит (Mark Smith) и Гордон Гуд (Gordon Good) воспользовались термином раздел вместо "контекст именования", хотя оба термина описывались как синонимы. Компания Microsoft использует оба термина.
Утилиты в составе операционной системы Windows Server 2003 и в составе Resource Kit используют термин контекст именования. Именно этот термин используется в данной книге.
Здесь становится заметной распределенная природа базы данных LDAP. Информационная база каталога может быть разбита на фрагменты, которые называются контекстами именования (Naming Context — NC). В Active Directory каждый домен представляет отдельный контекст именования. На контроллерах одного домена хранятся отдельные копии контекста именования домена. Объекты Configuration и Schema хранятся в собственных контекстах именования, как и объекты DNS Record, если DNS-зоны интегрированы в Active Directory.
После отправки запроса информации об определенном объекте система должна определить, на каком DSA хранится контекст именования, который содержит интересующий объект. Для этого используется характерное имя объекта и информация о топологии каталога.
Если агент DSA не в состоянии ответить на запрос с помощью информации из собственного контекста именования, клиенту отправляется ссылка (referral) на агент DSA, который содержит следующий контекст именования ниже или выше в пределах дерева (в зависимости от характерного имени искомого объекта). После этого клиент отправляет запрос агенту служб каталога, который указан в ссылке. Этот агент DSA отвечает на запрос, предоставляя интересующую информацию, или отправляет ссылку на другой агент служб каталога. Весь этот процесс поиска информации называется перемещением по дереву.
Агенты служб каталога, на которых хранятся копии одного и того же контекста именования, должны реплицировать изменения между собой. Об этом нужно помнить, работая с серверами Active Directory. Если используются отдельные домены, клиенты одного домена должны перейти по дереву, чтобы получить доступ к объектам Active Directory в другом домене. Если контроллеры домена находятся в различных местах и связаны внешним каналом, возможно снижение производительности. Многие решения, которые принимаются во время проектирования системы, зависят от расположения, доступности и надежности контекстов именования.
Поиск в LDAP
С точки зрения клиента, LDAP работает, как хороший отдел парфюмерии крупного магазина. В таком отделе можно подойти к продавцу и спросить “Сколько стоят духи Chanel № 5?”. Продавец ответит немедленно, особенно если в руках покупателя кредитная
карта. Это справедливо и для LDAP. Если запрос получен агентом DSA, на котором хранится копия контекста именования, где находится интересующий объект, этот агент DSA ответит на запрос немедленно.
Но если подойти в отдел парфюмерии и спросить “Где можно купить вон тот халатик, но только без пуговиц?’’, продавец, скорее всего, не сможет ответить, но отправит в отдел женской одежды. В отделе женской одежды продавец также может не знать об интересующем клиента товаре, но он скажет, где находится отдел уцененной женской одежды. Продавец отдела уцененной женской одежды может продать такой халат или извиниться за то, что его нет в продаже.
В LDAP используется такая же система ссылок для перенаправления клиента к тому агенту служб каталога, который хранит контекст именования с интересующей информацией. Эти ссылки гарантируют успешность любого поиска, пока объект существует в пределах области видимости информационной базы.
Главной особенностью процесса является перекладывание бремени поиска на клиентов LDAP. Это отличает LDAP от Х.500, где вся процедура поиска выполняется агентами DSA.
RootDSE
Если клиенту LDAP требуется информация от агента DSA, то клиент сначала должен установить привязку (bind) к службе каталогов. При этом выполняется аутентификация клиента и устанавливается сеанс связи. После этого клиент отправляет запросы на получение объектов и атрибутов в пределах каталога. Это означает, что клиент должен знать требования безопасности агента DSA, а также структуру поддерживаемой им службы каталогов.
Агент DSA “предоставляет” эту информацию, создавая специальный объект, который называется RootDSE. Объект RootDSE выступает в роли указательного столба на сельском перекрестке. Столб указывает направление к различным важным возможностям службы каталогов и предоставляет полезную информацию о службе. Клиенты LDAP могут использовать эту информацию для выбора механизма аутентификации и настройки своих запросов.
Каждый агент DSA создает собственную копию объекта RootDSE. Такая информация не реплицируется между агентами DSA. Этот объект — как глаз над пирамидой на обратной стороне долларовой банкноты: он находится за пределами структуры, но знает о ней все. Дополнительная информация об объекте RootDSE приводится далее в этой главе, там, где рассматривается использование сценариев. Запрос объекта RootDSE для получения информации об Active Directory вместо жесткого кодирования этой информации непосредственно в сценарии позволяет сделать код сценариев более переносимым.
Резюме
Подытожим вкратце особенности структуры пространства имен LDAP, которые помогут проектировать и администрировать Active Directory.
Полный путь объекта в пространстве имен LDAP называется характерным именем. Все характерные имена должны быть уникальны.
Информационное дерево каталога является распределенной базой данных LDAP, которая может храниться на нескольких серверах.
Информационное дерево каталога разделяется на фрагменты, которые называются контекстами именования. На контроллере домена может храниться более одного контекста именования.
Active Directory использует различные контексты именования для хранения информации о доменах в пределах одного информационного дерева каталога.
При поиске объектов серверы LDAP возвращают клиентам LDAP ссылки на серверы, хранящие контекст именования, в котором содержится интересующий объект. Такие ссылки создаются на основе общедоступной информации о топологии системы.
Каждый агент служб каталога создает объект RootDSE, который описывает требования к содержимому, управлению и безопасности службы каталогов. Клиенты используют эту информацию для выбора механизма аутентификации и для составления запросов.
Структура пространства имен Active Directory
Мы достаточно узнали о службе каталогов LDAP, чтобы применить полученные знания по отношению к службе Active Directory.
Начнем с того, что должно храниться в базе данных Active Directory. Необходимую информацию можно разделить на три главные категории.
Информация о сетевых объектах безопасности. В эту категорию попадают пользователи, компьютеры и группы, а также приложения, например групповые политики, DNS, RAS, СОМ и т.д.
Информация о механизмах Active Directory. В эту категорию попадают механизмы репликации, сетевые службы, права доступа и пользовательские интерфейсы.
Информация о схеме Active Directory. К этой категории относятся объекты, которые определяют классы и атрибуты Active Directory.
Компании Microsoft пришлось предусмотреть способ структурирования этой информации таким образом, чтобы сохранить обратную совместимость с LDAP, а значит, и с классической операционной системой Windows NT. В классической операционной системе Windows NT информация об объектах безопасности хранилась в базах данных SAM и SECURITY в системном реестре. Компания Microsoft называет доменом содержимое базы данных SAM. Поскольку единственным способом управления доступом к базе данных SAM является управление доступом к записям в базе данных SAM, домен определяет границы безопасности и границы управления.
Базы данных SAM в классическом домене Windows NT не могли объединяться. Чтобы создать общую область безопасности, домены необходимо было объединить, установив доверительные отношения (trust relationship). Если один домен доверял другому, члены доверенного домена могли использоваться, как объекты безопасности в доверяющем домене. В основополагающем механизме аутентификации, NT LanMan Challenge Response, эти доверительные отношения поддерживаются посредством сквозной аутентификации пользователей из доверенного домена.
Домены
LDAP предоставил компании Microsoft свободу создавать любое пространство имен. Ограничение присутствует только на вершине пространства имен, где характерное имя корневого объекта должно соответствовать имени домена DNS.
Дженис Джоплин (Janis Joplin) была права, когда считала свободу возможностью не бояться что-нибудь потерять. А компания Microsoft многое бы потеряла, если бы Active Directory была не совместима с классической Windows NT. Именно по этой причине компания Microsoft решила “построить” Active Directory вокруг классических понятий домена и доверительных отношений.
В Active Directory домен (domain) определяет отдельное пространство имен, отдельную структуру безопасности, отдельную структуру управления и отдельный контекст именования. База данных Active Directory хранится на контроллере домена. Пользователи и компьютеры являются членами (members) домена. Групповые политики хранятся в пределах определенного домена, даже если они влияют на пользователей из других доменов.
Контексты именования Active Directory
Active Directory может содержать миллиард объектов. Этого достаточно, чтобы хранить информацию об учетной записи, компьютере, почтовом ящике и членстве в группах для каждого человека в западном полушарии. Большая база данных Active Directory — как центровой в баскетбольной команде. Центровой является ключевым игроком для достижения победы, но для этого он не должен двигаться слишком быстро или слишком часто.
База данных Active Directory, файл ntds. dit, может увеличиваться в размерах очень быстро. Информационное дерево каталога для домена, содержащего 150 000 объектов, может превышать 2 Гбайт в зависимости от количества групп и количества членов в группах. Информационное дерево каталога такого размера может усложнить репликацию и управление. Кроме этого, нет смысла реплицировать информацию о пользователях с одного континента на контроллер домена, расположенный на другом континенте, если, конечно, пользователи с разных континентов не обмениваются информацией регулярно.
Контексты именования домена
LDAP позволяет разбивать каталог на различные контексты именования. Но управление интерфейсами между контекстами именования может стать немного сложным. Для достижения максимальной производительности часто необходимо создавать локальный кэш, который содержит ссылки на объекты из другого контекста именования. Для поддержки большого количества кэшей с внешними ссылками в актуальном состоянии требуются заметные усилия.
Компания Microsoft обошла сложности работы с контекстами именования, запретив создание контекстов именования в процессе работы. Администратор Active Directory имеет возможность создавать контексты именования только в двух случаях (рис. 6.8):
dc=Company,dc=comdc=Company,dc=comcn=Configuration,dc=Company,dc=comcn=Configuration,dc=Company,dc=comcn=Schema,cn=Configuration, dc=Company,dc=comcn=Schema,cn=Configuration, dc=Company,dc=comcn=DomainDNSZones, dc=Company,dc»comcn=DomainDNSZones, dc=Company,dc»comcn=ForestDNSZones, dc=Company,dc=comcn=ForestDNSZones, dc=Company,dc=comdc*Subsidiary, dc=comdc*Subsidiary, dc=comЧастичная копияЧастичная копияЧастичная копиявнешнего контекстаименования домена,хранящаяся на серверахглобального каталогаЧастичная копиявнешнего контекстаименования домена,хранящаяся на серверахглобального каталогаdc=Subsidlary,dc=comdc=Subsidlary,dc=comДвусторонние транзитивные доверительные отношенияДвусторонние транзитивные доверительные отношенияcn=ForestDNSZones, dc=Company, dc=comcn=ForestDNSZones, dc=Company, dc=comcn=DomainDNSZones, dc=Subsidiary,dc=comcn=DomainDNSZones, dc=Subsidiary,dc=comcn=Schema,cn=Configuration, dc=Company, dc=cojncn=Schema,cn=Configuration, dc=Company, dc=cojncn=Configuration, dc=Company,dc=comcn=Configuration, dc=Company,dc=com
dc=Company,dc=com
dc=Company,dc=com
cn=Configuration,dc=Company,dc=com
cn=Configuration,dc=Company,dc=com
cn=Schema,cn=Configuration, dc=Company,dc=com
cn=Schema,cn=Configuration, dc=Company,dc=com
cn=DomainDNSZones, dc=Company,dc»com
cn=DomainDNSZones, dc=Company,dc»com
cn=ForestDNSZones, dc=Company,dc=com
cn=ForestDNSZones, dc=Company,dc=com
dc*Subsidiary, dc=com
dc*Subsidiary, dc=com
Частичная копия
Частичная копия
Частичная копиявнешнего контекстаименования домена,хранящаяся на серверахглобального каталога
Частичная копиявнешнего контекстаименования домена,хранящаяся на серверахглобального каталога
dc=Subsidlary,dc=com
dc=Subsidlary,dc=com
Двусторонние транзитивные доверительные отношения
Двусторонние транзитивные доверительные отношения
cn=ForestDNSZones, dc=Company, dc=com
cn=ForestDNSZones, dc=Company, dc=com
cn=DomainDNSZones, dc=Subsidiary,dc=com
cn=DomainDNSZones, dc=Subsidiary,dc=com
cn=Schema,cn=Configuration, dc=Company, dc=cojn
cn=Schema,cn=Configuration, dc=Company, dc=cojn
cn=Configuration, dc=Company,dc=com
cn=Configuration, dc=Company,dc=com
Рис. 6.8. Контексты именования на примере леса Active Directory
на границе домена; '
создав специальный контекст именования приложения (возможность, появившаяся в операционной системе Windows Server 2003).
Контекст именования приложений имеет ограниченное применение (на данный момент он используется для поддержки службы DNS), поэтому единственным реальным способом разделения большого информационного дерева каталога является создание доменов. Кроме контекста именования доменов каждая реализация Active Directory содержит еще два контекста именования: Configuration и Schema. Каждый контроллер домена в пределах леса получает копию этих контекстов именования. Копия Schema предназначена только для чтения. Запись разрешена только контроллеру, который выбран в качестве Schema Operations Master (хозяин схемы — основной контроллер по операциям со схемой).
Контекст именования Schema
Контекст именования Schema содержит объекты ClassSchema и Attributeschema, которые представляют различные классы и атрибуты в пределах Active Directory. Это может показаться циклическим определением, но так должно быть. В отличие от служб каталогов, которые загружают схему в виде отдельного файла, схема Active Directory хранится внутри базы данных.
Каждый контроллер домена в пределах леса содержит предназначенный только для чтения контекст именования Schema. Только контроллер домена, выполняющий роль Schema Role Master обладает правом вносить изменения в схему.
Объект контейнера Schema является экземпляром класса Directory Management Domain (DMD). Это наследие Exchange, в котором для определения хранилища информации используется терминология Х.500. Поскольку объект схемы представляет границу контекста именования, он содержит и атрибуты управления репликацией, как в объекте Configuration и объекте Domain-DNS.
Просмотрев объекты в контейнере Schema, можно заметить объект Aggregate. Этот единственный экземпляр класса LDAP SubSchema имеет атрибуты AttributeTypes и Objectclasses, которые содержат имена всех классов и атрибутов в Active Directory. Клиенты LDAP запрашивают содержимое этого объекта для определения структуры каталога. Эта информация используется для формулировки запросов.
Контексты именования приложений
В операционной системе Windows Server 2003 появилась возможность создания дополнительного контекста именования, который может размещаться на определенном контроллере домена. Компания Microsoft использует эту возможность для хранения записей ресурсов DNS для зон, интегрированных в Active Directory.
Для создания интегрированной зоны необходимо установить флажок Active Directory Integrate (Хранить зону в Active Directory), как показано на рис. 6.9. Тип зоны показан на вкладке General (Общие) в окне свойств зоны, доступном на консоли DNS. Чтобы открыть окно Change Zone Туре (Изменение типа зоны), щелкните на кнопке Change (Изменить).
Если интегрировать DNS-зону в Active Directory, записи ресурсов будут скопированы из текстового файла зоны в базу данных Active Directory и будут храниться в виде объектов DNSzone. В операционной системе Windows 2000 эти объекты хранились в контейнере Mi- crosoftDNS в cn=System, <3с=<домен>, йс=<корень>. Такой механизм ограничивал свободу действий администраторов, которые пытались разворачивать интегрированные зоны в больших лесах, состоящих из большого количества доменов.
Контекст именования приложений, появившийся в операционной системе Windows Server 2003, предоставляет отсутствующую ранее гибкость. При интегрировании зоны в Active
Directory на контроллере домена под управлением операционной системы Windows Server 2003 контроллер домена создает два дополнительных контекста именования.
iChantje Zone Type
Select в zone lypy.
^ Впаду zone
Store» a copy of the zone M can bewMri *etifr
Secondary 2one
Skm • copy d an «Ning tore. life opton h*e Mance Ure precewig toad of pm* мгадк and prowtoe touk tctoMMA
** SMazor»
Storm a copy of 8 zwoantaeWMfltoNS. SOA, wdp№t**w A record». A tover cortann# aw not author***» tor
that zona
P Stare the zone rtAcfrreDrectavfcvalebleeHjii DNS server к a domain corMhr)
| OK I Оим! I
Puc. 6.9. В окне Change Zone Type можно задать интеграцию DNS-зоны co службой Active Directory
DomainDNSZones. Копия этого контекста именования хранится на контроллере домена, который поддерживает работу службы DNS. Каждый домен получает собственный контекст именования DomainDNSZones.
ForestDNSZones. Копия этого контекста именования хранится в пределах леса на контроллерах доменов, которые поддерживают работу службы DNS.
После интеграции зоны DNS в Active Directory на вкладку General (Общие) диалогового окна свойств зоны добавляется новое поле, которое называется Replication (Репликация). Щелкните на кнопке Change (Изменить), которая находится возле поля. Откроется диалоговое окно Change Zone Replication Scope (Изменение области видимости зоны репликации), которое показано на рис. 6.10.
ивявзвшояЕвяеямая^^ ■ ^
Chow how you war* zone data to be repfoetod r AIDNSservertnthBcompaqycotnAcibveDvMtovloreit
f* Al DNS reivwimihe«mfwv.dmAdMDbwtotf*m*t
Г AldomariconlroloremdtocdnipavvcomActotoftoBdtavdotMn.
Oxx^ihRopbonilhezw»hQutibekwfedbyWrttov*2ra1
Mvng on Ihe dam* cantala» m We tew damn
Г To<ldamar>oontr*i»ipecNdr*e*]op»o(t»iefc)wmgN)piDebon*8Ctaiy
3
| ак I Cancat I
Puc. 6.10. Окно для изменения области видимости зоны репликации
В этом окне доступны следующие варианты репликации.
All DNS servers in the forest (На все DNS-серверы в лесу). Если выбрать этот вариант, записи зоны будут размещены в контексте именования ForestDNSZones. Это самая широкая область видимости, следовательно, выбор этого варианта приводит к максимальному объему передаваемых данных при репликации.
All DNS servers in the domain (На все DNS-серверы в домене). В этом случае записи ресурсов размещаются в контексте именования DomainDNSZones в домене, в котором находится DNS-сервер. Например, если на DNS-сервере в домене company. com создать зону-заглушку, указывающую на branch. company. com, записи зоны-заглушки будут размещены в cn=DomainDNSZones , dc=Company, dc=com.
All domain controllers in the domain (На все контроллеры домена в домене). В этом случае записи зоны размещаются в контексте именования Domain в разделе cn=MicrosoftDNS, cn--System,бс=<домен>^с=<корень>. Такой же контейнер используется в операционной системе Windows 2000, поэтому при использовании серверов под управлением Windows 2000 для хранения интегрированных в Active Directory зон необходимо выбирать этот вариант.
All domain controllers specified in the scope of the application directory partition (На все контроллеры домена, перечисленные в области видимости раздела каталога приложений). Этот вариант позволяет выбрать конкретный контекст именования приложения.
Если используется единственный домен, хранение записей DNS в отдельных контекстах именования не дает никаких преимуществ. Выберите переключатель All Domain controllers in the domain (На все контроллеры домена в домене).
Если используется лес, состоящий из нескольких доменов и репликацию необходимо ограничить определенным доменом, выберите переключатель All DNS servers in the domain (На все DNS-серверы в домене). Такой вариант подходит для большинства зон на основе доменов.
Для всех контроллеров домена в пределах леса необходимо, чтобы были указаны записи SRV и CNAME для корневого домена леса. В нормальных условиях серверы DNS в других доменах будут получать эти записи в результате рекурсивного запроса от DNS-серверов корневого домена. Этот процесс можно немного ускорить, выбрав для области репликации корневого домена вариант All DNS servers in the forest (На все DNS-серверы в лесу).
Если кажется, что количество глобально реплицируемых записей слишком велико, то можно создать новую зону специально для записей ресурсов, которые требуют репликации в пределах всего леса. Такие записи будут храниться в корневой зоне леса в разделе _msdcs. Например, если корневой домен леса называется Company. com, можно создать новую зону _msdcs . company. com. Записи будут извлечены из зоны company. com и размещены в пределах новой зоны. Установите область репликации зоны _msdcs . company . com с помощью переключателя All DNS servers in the forest (На все DNS-серверы в лесу).
Контекст именования Configuration
Контекст именования Configuration содержит информацию о параметрах, которые управляют службами поддержки Active Directory. Каждый контроллер домена в пределах леса содержит предназначенную для чтения и записи копию контекста именования Configuration. В копии содержится восемь контейнеров верхнего уровня. Рассмотрим вкратце назначение и содержимое каждого из этих контейнеров.
Контейнер Display-Specifiers (Параметры отображения)
Этот контейнер содержит объекты, которые меняют отображаемые атрибуты других классов объектов. Это так называемое затенение (shadowing). Например, объект User-Display затеняет класс User. Параметры отображения задаются функциями локализации (localization) и контекстного меню (context menu).
Локализация заключается в создании версий приложений на языке локального пользователя. Вместо перевода содержимого каждого атрибута каждого объекта Active Directory на французский, итальянский, немецкий, испанский, русский, арабский, корейский и другие языки система запрашивает код страны, который был указан в процессе установки, и фильтрует выводимые данные с помощью соответствующего параметра отображения.
Кроме этого, параметры отображения определяют различные контекстные меню, страницы свойств и пиктограммы в зависимости от привилегий пользователя, который получает доступ к элементам управления. Например, при щелчке правой кнопкой мыши на объекте выдается контекстное меню, связанное с конкретным классом объектов. Параметры отображения фильтруют меню с целью предоставления только тех элементов, к которым разрешено получать доступ данному пользователю.
Сортировка параметров отображения
При просмотре содержимого контейнера Displayspecifiers в базе данных Active Directory можно заметить контейнер с номером вместо имени. Это шестнадцатеричный номер кодовой страницы (code page) согласно National Language Group. Английскому языку США соответствует номер 1033 или значение 409 в шестнадцатеричном формате. Кодовая страница Франции — 1036, Италии — 1040, Германии — 1031 и Испании — 1034.
Контейнер Extended Rights (Расширенные права)
Объекты службы каталогов одновременно являются объектами безопасности Windows. Это позволяет назначать права доступа для самих объектов, а также для любых свойств объектов. Объект User может иметь множество свойств. Выбор конкретных свойств и назначение им прав доступа для получения необходимого результата представляет собой достаточно трудоемкий процесс.
Расширенные права управляют доступом к объектам, собирая наборы разрешений на доступ к свойствам в едином элементе. Например, расширенное право, которое называется Membership, предоставляет возможность изменять состав членов одной группы, выбранных групп или каждой группы в контейнере или даже каждой группы в контейнере и вложенных контейнерах.
Как и параметры отображения, каждый объект расширенных прав связан со структурным объектом, которым он управляет. Например, объекты Personal-Information и Public- Information связаны с классами User и Contact.
Существует более 50 объектов расширенных прав, которые соответствуют широкому диапазону операций по управлению, например изменению паролей, изменению конфигурации домена, сбросу блокировок пользователей и управлению службами BackOffice.
Контейнер Lost and Found
Этот контейнер содержит объекты, для которых при репликации базы данных утрачена информация о родительских объектах. Например, если в течение одного цикла репликации был создан объект и удален контейнер, в котором объект создавался, объект размещается в контейнере Lost and Found. Контейнер Lost and Found существует в контекстах именования Domain и Configuration. Контекст именования Schema не нуждается в подобном контейнере, так как объект Schema не может быть удален. Дополнительная информация приводится в главе 7, “Управление репликацией Active Directory".
Контейнер Part it ions
В этом контейнере содержатся объекты перекрестных ссылок, в которых перечисляются другие домены леса. Контроллеры домена используют содержимое этого контейнера для создания ссылок на другие домены.
Контейнер Partitions исключительно важен для поддержания целостности леса. Очень плохо, если в этом контейнере появятся объекты, представляющие некорректные контексты именования. Именно поэтому только один контроллер домена в пределах леса может обновлять содержимое этого контейнера.
Контейнер Physical Locations
Этот контейнер содержит объекты Physical Locations DN, которые связаны с сетевыми технологиями по интеграции с сервисом каталогов (Directory Enabled Networking — DEN). Например, маршрутизатор, поддерживающий DEN, может разместить в этом контейнере объект- локатор. Так как DEN использует стандартные функциональные возможности LDAP, это единственный класс объектов в Active Directory, который использует атрибут Location.
Инициатива DEN была разработана в виде набора политик для управления параметрами сети, влияющих на Quality of Service (QoS), IP Security (IPSec) и другие основные сетевые функции. Все основные производители маршрутизаторов и сетевого оборудования согласились поддерживать инициативу DEN, а многие производители даже вступили в союз с компаниями Microsoft и Novell в области реализации службы каталогов для инициативы DEN. Обратитесь на сайт вашего любимого производителя и обратите внимание на продукты, поддерживающие DEN, а также на планы интеграции таких продуктов с Active Directory.
Контейнер Services
Этот контейнер доступен через консоль Active Directory — Sites and Services (Active Directory — сайты и службы) с помощью команды View^Show Services (Вид=>Показать службы). Содержимое контейнера Services можно рассматривать как системный реестр масштаба предприятия. Распределенные приложения размещают объекты в этом контейнере для предоставления объектов другим серверам, которые поддерживают работу такого же приложения.
Недостатком этого контейнера является репликация на каждый контроллер домена в пределах леса. Иногда могут использоваться приложения, объекты которых должны быть видимы только на некоторых контроллерах доменов. Именно по этой причине компания Microsoft предоставляет возможность создания отдельного контекста именования Application, который размещается на выбранных администратором контроллерах домена.
Контейнер Sites
Контейнер sites также доступен через консоль Active Directory — Sites and Services (Active Directory — сайты и службы). Объекты из этого контейнера управляют репликацией Active Directory и другими функциями, специфичными для сайтов. Сайты используются для управления репликацией между контроллерами домена.
Контейнер Well-Known Security Principals
(Известные участники системы безопасности)
Основанная на объектах система безопасности в операционных системах Windows NT и Windows Server 2003 назначает каждому участнику системы безопасности идентификатор безопасности (SID). Существует набор широко известных идентификаторов безопасности, соответствующих специальным группам. В числе этих групп можно назвать Interactive, в которую записываются пользователи, зарегистрировавшиеся на локальной консоли компьютера, Network, которая содержит пользователей, зарегистрированных в домене, и Everyone, членами которой являются все пользователи. В этом контейнере содержатся идентификаторы безопасности и названия этих групп.
Деревья и леса Active Directory
Вспомним, что домен устанавливает границы безопасности для пользователей и область управления для администраторов. Пользователи из одного домена не могут получать доступ к ресурсам в другом домене, если администратор не обеспечил возможность безопасного подключения. Если используются отдельные домены, необходим способ объединения доменов
в единую структуру безопасности. В классической операционной системе WindowsNT для этого используются главные домены (Master domain) и домены ресурсов (Resource domain). В Active Directory для этой цели используются деревья и леса.
Деревья
Для определения пространства имен в Active Directory используется служба DNS. Как было показано выше, стандартная иерархия LDAP соответствует непрерывному пространству имен, которое называется информационным деревом каталога. Непрерывное пространство имен Active Directory также называется деревом (tree). Пример дерева Active Directory показан на рис. 6.11.
dc=Quebec,dc=Canada,dc=Quebec,dc=Canada,
dc=Quebec,dc=Canada,
dc=Quebec,dc=Canada,
ou=Francophone,ou=Anglophone,
dc=Quebec,dc=Canada,dc=Quebec,dc=Canada,
dc=Companyrdc=comdc=Company,dc=com
Puc. 6.11. Дерево Active Directory
На рис. 6.11 показан один из способов согласования дерева Active Directory и стандартного пространства имен DNS. На этой схеме корневой домен Company. com содержит два дочерних домена, US и Canada. Домен Canada содержит собственный дочерний домен Quebec. В домене Quebec содержатся организационные единицы, которые разделяют объекты в зависимости от используемого языка. В домене US содержатся организационные единицы, которые разделяют объекты по географическому положению. Оба случая демонстрируют пример допустимого использования контейнеров организационных единиц.
С точки зрения LDAP эта структура дерева выглядит достаточно стандартной. Если клиент в домене Quebec запрашивает в LDAP информацию о сервере в домене US, клиент получает последовательность ссылок до вершины дерева и до контроллера домена US.
Ранее указывалось, что каждый домен представляет содержимое контекста именования. Контекст именования домена хранится на контроллере этого домена. При переходе по дереву запрос передается от одного контроллера домена к следующему. Если контроллер домена расположен в другой части глобальной сети, то на завершение транзакции может потребоваться некоторое время.
Леса
Не каждая организация может позволить себе иметь стандартную структуру дерева. Многие компании состоят из практически автономных отделений, которые используют собственные корневые домены DNS, независимый административный персонал и даже отдельные столовые. Также многие университеты состоят из нескольких институтов, в которых работает собственный персонал и применяется собственная сетевая инфраструктура.
Для поддержки таких не древовидных структур компания Microsoft немного модифицировала стандарт LDAP, чтобы разработать еще одну структуру, которая называется лес (forest). Пример такой структуры показан на рис. 6.12.
Двусторонние транзитивные доверительные отношенияДвусторонние транзитивные доверительные отношенияdc=Canada,dc=Canada,dc=US,dc=Cfompany,dc=comdc=US,dc=Cfompany,dc=comdc=Company,dc=comdc=Company,dc=comdc=Subsidiary,dc=comdc=Subsidiary,dc=comdc=BusinessUnit2,dc=Subsidiary,dc=comdc=BusinessUnit2,dc=Subsidiary,dc=com
Двусторонние транзитивные доверительные отношения
Двусторонние транзитивные доверительные отношения
dc=Canada,
dc=Canada,
dc=US,dc=Cfompany,dc=com
dc=US,dc=Cfompany,dc=com
dc=Company,dc=com
dc=Company,dc=com
dc=Subsidiary,dc=com
dc=Subsidiary,dc=com
dc=BusinessUnit2,dc=Subsidiary,dc=com
dc=BusinessUnit2,dc=Subsidiary,dc=com
Puc. 6.12. Лес Active Directory
Домены в лесу Active Directory не обязаны составлять непрерывное пространство имен. Защищенное соединение между корневыми доменами создает “коридор”, который позволяет пользователям одного домена получать доступ к ресурсам другого домена.
Глобальный каталог
При стандартном поиске LDAP, когда задействуется несколько контекстов именования, хранящихся на нескольких серверах, серверы выдают ссылки клиенту, а клиент переходит по дереву для получения необходимой информации. Такой процесс отправки запросов и получения ссылок требует времени и снижает пропускную способность сети. Если один из контроллеров домена подключен по коммутируемой линии со скоростью передачи данных 56 Кбит/с и пользователи заняли всю полосу пропускания загрузкой файлов MP3, то поиск может потребовать некоторое время.
Active Directory позволяет ускорить поиск и сократить объем данных, передаваемых по внешним каналам. Для этого содержимое различных контекстов именования Domain объединяется в единую структуру, которая называется глобальный каталог (Global Catalog — GC).
Структура глобального каталога
В глобальном каталоге содержится копия каждого контекста именования Domain в пределах леса, значит, в глобальном каталоге содержится копия каждого объекта. В крупной организации база данных может иметь очень большой размер. Нет смысла создавать отдельные домены для создания отдельных контекстов именования, чтобы потом объединить их в глобальный каталог, который должен быть доступен в любой точке сети.
Для сокращения размера глобального каталога и объема данных, передаваемых при репликации, в глобальном каталоге хранится лишь несколько распространенных атрибутов. Список атрибутов, которые хранятся в глобальном каталоге, определяется в частичном наборе атрибутов (Partial Attribute Set — PAS). В частичном наборе атрибутов перечислено около 200 атрибутов из общего числа (1700) атрибутов схемы Active Directory. Более того, частичные копии контекстов именования в пределах глобального каталога доступны только для чтения, поэтому глобальный каталог реплицируется в одном направлении, а именно с контроллеров домена, на которых хранится полная версия контекста именования.
Глобальный каталог не является отдельным элементом. На контроллере домена нет отдельного файла информационного дерева каталога для глобального каталога. Вместо этого глобальный каталог является функцией контроллера домена. Для управления этой функцией используется специальный флаг в Active Directory. При установке для флага значения FALSE на контроллере домена хранятся только три стандартных контекста именования — собственный контекст именования домена, контекст именования Configuration и контекст именования Schema. При установке для флага значения TRUE на контроллере домена дополнительно хранятся частичные копии других контекстов именования в пределах леса. Эти контексты именования хранятся в файле ntds . dit вместе с тремя стандартными контекстами именования.
Функция глобального каталога
Сервер глобального каталога отличается от стандартного контроллера домена тем, что он ожидает получения запросов LDAP на еще одном порту. Стандартный проводной протокол LDAP использует TCP/UDP-порт 389. Серверы глобального каталога принимают запросы на этом порту, но запросы ожидаются и на TCP/UDP-порту 3268. Вот три варианта обработки запроса, отправленного глобальному каталогу на порт 3268.
Если сервер глобального каталога получает запрос на поиск по одному или нескольким атрибутам, которые входят в частичный набор атрибутов, в ответ на запрос клиенту передается набор данных, состоящий из запрошенных объектов и атрибутов.
Если сервер глобального каталога получает запрос на поиск по одному или нескольким атрибутам, которые не входят в частичный набор атрибутов, но объекты входят в данный домен, в ответ на запрос предоставляется набор данных, состоящий из запрошенных объектов и атрибутов. Эта информация извлекается из полной копии контекста именования домена.
Если сервер глобального каталога получает запрос на поиск по одному или нескольким атрибутам, которые не входят в частичный набор атрибутов и соответствуют объектам из других доменов, в ответ на запрос выдается ссылка на другой домен. Клиент LDAP следует по ссылке и завершает поиск после перехода по дереву.
Серверы глобального каталога играют очень важную роль в работе Active Directory в пределах предприятия. Если используется лес из нескольких доменов, очень важно обеспечить видимость сервера глобального каталога для всех пользователей. В следующих нескольких главах работа глобального каталога и его роль в аутентификации и управлении доступом будет рассмотрена более подробно.
Глобальные каталоги и расположение контекстов именования
Обратите внимание на лес, схема которого изображена на рис. 6.12. Этот лес состоит из шести различных доменов. Предположим, что контроллер домена Canada настроен на работу одновременно в качестве сервера глобального каталога и DNS-сервера для зоны, интегрированной в Active Directory. На сервере будут храниться следующие контексты именования.
Полная копия dc=Canada, dc=Company, dc=com с правами чтения/записи.
Полная копия cn=Conf iguration, dc=Company, dc=comc правами чтения/записи.
Полная копия cn=Schema , cn=Conf iguration, dc=Company, dc=com с правом только на чтение.
Полная копия cn=ForestDNSZones, dc=Company, dc=com с правами чтения/записи.
Полная копия cn=DomainDNSZones , dc=Company, dc=com с правами чтения/записи.
Частичная копия остальных контекстов именования домена с правом только на чтение.
Доверительные отношения в Active Directory
Использование деревьев и лесов требует средств обеспечения безопасных транзакций между различными доменами. Как и в классической операционной системе Windows NT, такой защищенный канал называется отношением доверия или доверительным отношением (trust relationship).
Классические доверительные отношения Windows NT напоминают детскую сказку о двух баранах на мосту. Бараны уперлись лбами и ни один не желает пропускать другого.
Классические односторонние доверительные отношения в Windows NT ведут себя точно так. Права доступа, предоставленные на основе доверительных отношений, действуют только в одном направлении. Крупная система обеспечения безопасности на основе Windows NT с использованием перекрестных доверительных отношений между различными ресурсами и главными доменами может оказаться крайне запутанной.
Транзитивные отношения доверия Kerberos
С появлением Active Directory все становится немного проще. Если два домена Active Directory доверяют друг другу, пользователи, группы и компьютеры из одного домена могут прозрачным образом получать доступ к ресурсам из другого домена. Доверительные отношения стали двусторонними.
Кроме этого, доверительные отношения Active Directory имеют транзитивный характер, а значит, доверие распространяется на все домены, между которыми установлены доверительные отношения. Например, если пять доменов Active Directory доверяют друг другу, пользователи одного из доменов смогут получать доступ к ресурсам в остальных четырех доменах (если пользователям такой доступ разрешен).
В основе такой технологии доверительных отношений лежит механизм аутентификации Kerberos. Дополнительную информацию о принципах работы Kerberos и транзитивных доверительных отношениях можно получить в главе 12, “Управление групповыми политиками".
Типы доверительных отношений
Существует несколько способов установить доверительные отношения между доменами Active Directory. Кроме этого, существуют методы установки доверительных отношений с устаревшими доменами под управлением Windows NT. Всего существует шесть типов доверительных отношений (рис. 6.13).
Доверительные отношения между родительским и дочерним доменами (Parent/Child trusts). Доверительные отношения такого типа создаются между двумя доменами Active Directory, которые совместно используют непрерывное пространство имен DNS и принадлежат одному лесу.
Доверительные отношения между деревом и корневым доменом (Tree Root trusts). Такие доверительные отношения создаются между корнёвыми доменами в пределах одного леса, которые не используют общее пространство имен.
Прямые доверительные отношения (Shortcut trusts). Доверительные отношения такого типа создаются между двумя доменами из различных деревьев в пределах одного леса. Такие доверительные отношения используются для передачи транзакций Kerberos между доменами. После создания прямых доверительных отношений клиент может получать билет (ticket) Kerberos непосредственно от доверенного домена, минуя прохождение по дереву.
Доверительные отношения междудеревом и корневым доменомДоверительные отношения междудеревом и корневым доменомCompany.comCompany.comДоверительные отношениямежду родительским идочерним доменамиДоверительные отношениямежду родительским идочерним доменамиSubsidiary.comSubsidiary.comДоверительные отношения между сферами KerberosДоверительные отношения между сферами KerberosЦентр распределения ключей Kerberos (KDC) MlTv5Центр распределения ключей Kerberos (KDC) MlTv5Резервный контроллер домена (ВОС) NT4Резервный контроллер домена (ВОС) NT4Рис. 6.13. Схема различных типов доверительных отношений Active Directory в операционной системе Windows Server 2003Рис. 6.13. Схема различных типов доверительных отношений Active Directory в операционной системе Windows Server 2003Прямое доверительное отношениеПрямое доверительное отношение
Доверительные отношения междудеревом и корневым доменом
Доверительные отношения междудеревом и корневым доменом
Company.com
Company.com
Доверительные отношениямежду родительским идочерним доменами
Доверительные отношениямежду родительским идочерним доменами
Subsidiary.com
Subsidiary.com
Доверительные отношения между сферами Kerberos
Доверительные отношения между сферами Kerberos
Центр распределения ключей Kerberos (KDC) MlTv5
Центр распределения ключей Kerberos (KDC) MlTv5
Резервный контроллер домена (ВОС) NT4
Резервный контроллер домена (ВОС) NT4
Рис. 6.13. Схема различных типов доверительных отношений Active Directory в операционной системе Windows Server 2003
Рис. 6.13. Схема различных типов доверительных отношений Active Directory в операционной системе Windows Server 2003
Прямое доверительное отношение
Прямое доверительное отношение
Внешние доверительные отношения (External trusts). Доверительные отношения такого типа создаются между доменом Active Directory и доменом Windows NT 4.0. Кроме этого, можно создавать внешние доверительные отношения с доменами Samba. Этот тип доверительных отношений напоминает классические доверительные отношения WindowsNT. Это односторонние и нетранзитивные доверительные отношения, поэтому нельзя создать доверительные отношения между всем лесом и устаревшим доменом. Запросы на поиск по протоколу LDAP и аутентификация Kerberos не пересекают границ таких доверительных отношений.
Доверительные отношения между сферами Kerberos (Kerberos realm trusts). Такой тип доверительных отношений создается между доменом Active Directory и сферой MITv5 Kerberos. (MIT расшифровывается как Massachusetts Institute of Technology, где изобрели
протокол Kerberos.) Такие доверительные отношения могут быть транзитивными и двусторонними.
Доверительные отношения между лесами (Forest trusts). Такие доверительные отношения создаются между двумя лесами Active Directory. Эти отношения могут быть двусторонними и транзитивными. Леса не имеют общих контекстов именования Schema и Configuration. Доверительные отношения такого типа формируют федерацию лесов (federation of forests) и используются для объединения двух организаций, которые уже развернули инфраструктуру Active Directory и не считают возможным слияние всех учетных записей в один лес. Такой тип доверительных отношений появился впервые в операционной системе Windows Server 2003 и требует, чтобы все домены в пределах каждого леса работали с использованием полного набора функциональных возможностей Windows Server 2003 (не должно быть контроллеров доменов, работающих под управлением более старых версий операционной системы Windows). Для создания доверительных отношений между лесами пользователь должен входить в группу Incoming Fores t Trus t Builders.
He стоит рассматривать новый тип доверительных отношений между лесами в качестве панацеи от проблем при реструктуризации организаций. Поскольку два леса не используют общие контексты именования Schema и Configuration, они не могут совместно использовать приложения, которые требуют общей конфигурации. Характерным примером является Exchange 2000, который размещает важную информацию в контексте именования Configuration. Федерация лесов не может входить в единственную организацию Exchange, поэтому пользователи не смогут использовать общий глобальный список адресов (Global Address List) или общие списки рассылки.
Создание доверительных отношений между родительским и дочерним доменами и между деревом и корневым доменом
Доверительные отношения между родительским и дочерним доменами и между деревом и корневым доменом могут устанавливаться только в процессе создания домена. Не существует инструментов, которые позволяют связать или разорвать связь между доменами после создания леса. Каждый контроллер домена в пределах леса содержит идентичную копию контекста именования Schema. Инструментов для координации и консолидации двух схем просто не существует.
Повторим то же самое, но другими словами, так как это очень важно запомнить. Новые домены могут добавляться в лес только при создании нового контроллера соответствующего домена. После создания леса без понижения в ранге всех контроллеров интересующего домена (а значит, и без потери всей информации Active Directory) удалить домен из леса не удастся.
Внешние доверительные отношения и отношения между сферами не зависят от контекстов именования Schema и Configuration, поэтому их можно создавать и разрывать в любой момент. Если разорвать доверительные отношения, пользователи доверенного домена лишатся доступа к ресурсам другого домена. Если повторно создать доверительные отношения, пользователи опять смогут получать доступ к ресурсам.
Создание доверительных отношений между лесами
Создание доверительных отношений между лесами требует больших усилий при настройке, чем при создании стандартных доверительных отношений, использовавшихся в операционной системе Windows 2000. Хотя эти отношения являются двусторонними и транзитивными, можно выбрать домен в каждом лесу, который входит в доверительные отношения. Например, рассмотрим схему на рис. 6.14. На схеме изображены два леса в составе федерации, между которыми установлены доверительные отношения. В каждом лесу есть домены, связанные между собой доверительными отношениями между родительским и дочерним доменами.
Доверительные отношениямежду лесами могут быть повыбору транзитивными идвусторонними
Рис. 6.14. Федерация двух лесов Active DirectoryРис. 6.14. Федерация двух лесов Active Directorydc=PacRimdc=PacRimdc=Europedc=Europe
Рис. 6.14. Федерация двух лесов Active Directory
Рис. 6.14. Федерация двух лесов Active Directory
dc=PacRim
dc=PacRim
dc=Europe
dc=Europe
При полностью транзитивных доверительных отношениях пользователи из доменов US. Company. com и Canada . Company. com смогут получать доступ к ресурсам в доменах PacRim. Subsidiary. com и Europe. Subsidiary. com, и наоборот. Но иногда полностью транзитивный доступ к ресурсам нежелателен. Окно настройки свойств доверительных отношений позволяет выбрать домены, которые входят в доверительные отношения между лесами, и указать направление устанавливаемого доверительного отношения.
Эта возможность позволяет “направлять” доверительные отношения в пределах федерации. Например, можно настроить доверительные отношения между лесами, при которых пользователи домена PacRim. Subsidiary. com смогут получать доступ к ресурсам домена US. Company. com, но не к ресурсам домена Canada . Company. com.
Для создания доверительных отношений между лесами с участием другого домена пользователь должен входить в группу Incoming Forest Trust Builders. Эта новая встроенная группа позволяет главному администратору домена предоставлять право создания доверительных отношений администратору другого домена, не наделяя другого администратора полными привилегиями по управлению доменом.
Перемещение объектов между доменами и лесами
После создания доверительных отношений между родительским и дочерним доменами и между деревом и корневым доменом их невозможно разорвать или создать дополнительные отношения такого типа, поэтому единственным способом изменения структуры леса является перемещение объектов между доменами. Компания Microsoft предоставляет утилиту для перемещения объектов, которая называется Active Directory Migration Tool, или ADMT.
Перемещение пользователей, компьютеров и учетных записей групп между доменами связано с проблемами безопасности и поддержки доступа. И классическая операционная сис-
тема Windows NT, и серверы под управлением современных операционных систем Windows для идентификации пользователей используют идентификаторы безопасности. Идентификаторы безопасности указываются в списках контроля доступа (Access Control List — ACL) и служат для ограничения доступа к ресурсам. Утилита ADMT выполняет сложный набор функций, которые проектировались для сохранения оригинальных идентификаторов безопасности, что позволяет сохранить права доступа пользователей к ресурсам. Новая версия операционной системы Windows Server 2003 также сохраняет пароли и оригинальные профили пользователей. Существует множество утилит сторонних производителей, которые облегчают перемещение объектов между доменами и лесами. Дополнительную информацию по этому вопросу можно получить в главе 9, “Развертывание доменов Windows Server 2003”.
Sysvol
На контроллер домена возлагаются дополнительные задачи, помимо хранения копии базы данных Active Directory. Кроме этого, контроллер домена отвечает за рассылку файлов, связанных с групповыми политиками. Групповые политики используются для централизованного управления серверами, входящими в домен, настольными компьютерами и пользователями. Дополнительную информацию о групповых политиках можно получить в главе 12, “Управление групповыми политиками".
Также контроллерами домена Active Directory должны поддерживаться клиенты более ранних версий благодаря предоставлению места для хранения классических сценариев и системных политик, которые находятся в файлах config.pol или Ntconfig.pol. В домене WindowsNT эти файлы хранятся на общем ресурсе Net logon, физически расположенном в каталоге С:\Windows\System32\Repl\lmport\Scripts.
Файлы каталога Sysvol
Для выполнения двойной задачи по поддержке современных групповых политик и классических системных политик и сценариев на контроллерах домена Active Directory хранится специальный каталог Sysvol. Расположение каталога определяется во время использования утилиты dcpromo. Каталог Sysvol должен храниться на томе NTFS, поскольку его подкаталоги используют точки функционального монтирования, которые поддерживаются только в файловой системе NTFS.
В каталоге Sysvol содержится каталог Domain, в подкаталоге Policies которого хранятся файлы групповых политик, а в подкаталоге Scripts — классические сценарии. Каталог Scripts предоставляется клиентам более ранних версий в виде общего ресурса Netlogon. Современные сценарии, которые предоставляются в составе групповых политик, хранятся вместе с конкретной групповой политикой в каталоге Policies.
Для получения доступа к Sysvol клиенты используют отказоустойчивый обилий ресурс (fault tolerant share), адрес которого в формате UNC выглядит как \\химя^омена>\Sysvol. Например, доступ к ресурсу Wcompany. com\Sysvol предоставляется всем клиентам домена Company. com. Для доступа к отказоустойчивым общим ресурсам на клиенте должна быть запущена служба Df sclient.
Репликация файлов и каталог Sysvol
Содержимое каталога Sysvol реплицируется на каждый контроллер в пределах домена. Очень важно, чтобы содержимое всех копий этого каталога оставалось одинаковым. В противном случае пользователи будут получать различные групповые политики, системные политики и классические сценарии при регистрации на различных контроллерах домена.
За синхронизацию содержимого каталога Sysvol на различных контроллерах домена отвечает служба репликации файлов (File Replication Service — FRS). Фактически служба назы-
вается Ntfrs; это имя встречается в журнале событий. При внесении изменений в файл служба репликации файлов копирует файл целиком. Во избежание ситуации “гонки на выживание” при доступе к заблокированному файлу сначала файл копируется в каталог Staging, после чего реплицируется на другие контроллеры доменов.
Поиск служб Active Directory
Для обнаружения контроллеров домена клиенты Active Directory используют службу DNS. Для этого клиенты запрашивают информацию записей SRV, которые доступны через порты LDAP и Kerberos, а также через порт глобального каталога. Дополнительная информация доступна в документе RFC 2052, “A DNS RR for Specifying the Location of Services” (RR — Resource Record, т.е. записи ресурсов).
Записи srv для Active Directory
На рис. 6.15 показана зона DNS для домена company. com. В таблице зоны содержатся записи SRV, зарегистрированные первым контроллером домена Windows Server 2003.
- dnsmgml [[)^S SLRVFR I Forward Lookup Tories .company.com\_msd< *> Ф- dnsmgml [[)^S SLRVFR I Forward Lookup Tories .company.com\_msd< *> Фj’4, Ha Action I»* window f*'• * ■*":©J® >^^'"б)“'Э 3^j’4, Ha Action I»* window f*'• * ■*":©J® >^^'"б)“'Э 3^■ •-JOLti■ •-JOLtiЛ g SERVERIК -LU Forward Lookup Zones@ ^ branch.company.comЙ-^ company.comВ LJ _msdcsЛ g SERVERIК -LU Forward Lookup Zones@ ^ branch.company.comЙ-^ company.comВ LJ _msdcs) J*' Emmrdto) J*' Emmrdto№ „kerberosSZkiap№ „kerberosSZkiapService Location (SRV) Service Location (SRV)Service Location (SRV) Service Location (SRV)10*a[01100188] server 1. company -com.[011001389] serveri .corrpany.com.10*a[01100188] server 1. company -com.[011001389] serveri .corrpany.com.
- dnsmgml [[)^S SLRVFR I Forward Lookup Tories .company.com\_msd< *> Ф
- dnsmgml [[)^S SLRVFR I Forward Lookup Tories .company.com\_msd< *> Ф
j’4, Ha Action I»* window f*
'• * ■*":©J® >^^'"б)“'Э 3^
j’4, Ha Action I»* window f*
'• * ■*":©J® >^^'"б)“'Э 3^
■ •-JOLti
■ •-JOLti
Л g SERVERI
К -LU Forward Lookup Zones
@ ^ branch.company.com
Й-^ company.comВ LJ _msdcs
Л g SERVERI
К -LU Forward Lookup Zones
@ ^ branch.company.com
Й-^ company.comВ LJ _msdcs
) J*' Emmrdto
) J*' Emmrdto
№ „kerberos
SZkiap
№ „kerberos
SZkiap
Service Location (SRV) Service Location (SRV)
Service Location (SRV) Service Location (SRV)
10*a
[01100188] server 1. company -com.
[011001389] serveri .corrpany.com.
10*a
[01100188] server 1. company -com.
[011001389] serveri .corrpany.com.
8 uJ .sites
. В £j Defadt-Hrst-Ste-Name
s £3 _tcp ® Cj domains В Cj gc В £j pdc BQ .sites SI CJ _tcp s Cj _udp
- (S Й branch
: ® Ш DomainDnsZones ■ В -u3 ForestDnsZones ®-^ subsidary.com
Puc. 6.15. Консоль DNS с записями SRVдля домена Company. com
Ниже приведены записи SRV в стандартном формате таблицы зоны.
„kerberos._tcp.phoenix.„sites.de._msdcs
600
SRV
0 100 88
'b dc-01.company.com._
„kerberos._tcp.phoenix.„sites
600
SRV
0 100 88
dc-01. company. com.
„kerberos._tcp.dc.„msdes
600
SRV
0 100 88
dc-01. company. com. „kerberos.„tcp
600
SRV
0 100 88
dc-01. company. com. „kerberos._udp
600
SRV
0 100 88
dc-01. company. com. _kpasswd.„tcp
600
SRV
0 100 464
^ dc-01.company.com.
_kpasswd._udp
600
SRV
0 100 464
'Ъ dc-01.company.com.
_ldap._tcp.phoenix.„sites.gc.
,„msdes600
SRV
0 100 3268
^ dc-01.company.com.
_gc._tcp.phoenix.„sites
600
SRV
0 100 3268
'b dc-01. company . com. _ldap._tcp.gc.„msdes
600
SRV
0 100 3268
'b dc-01.company.com. _gc.„tcp
600
SRV
0 100 3268
dc-01.company.com.
„1dap._tcp.phoenix.„sites.de.
.„msdes600
SRV
0 100 389
'b dc-01.company.com.
_ldap._tcp.phoenix.„sites
600
SRV
0 100 389
'b dc-01.company.com._ ldap._tcp.dc.„msdes
600
SRV
. 0 100 389
'b dc-01. company. com.
Idap._tcp.{guid of domain}.domains.„msdes 600
SRV
0 100 389
'b dc-01.company.com. _ldap._tcp
600
SRV
0 100 389
dc-01. company. com.
„1dap. _t cp.pdc._msdes
600
SRV
0 100 389
dc-01.company.com. dc-01
1200
A
10.1.1.1
gc.„msdes
600
A
10.1.1.1
(QUID of DC invocation}.„msdes600
dc-01.company.com.
CNAME
Формат записей srv
Указанные первыми символы подчеркивания в записях SRV созданы для упрощения идентификации этих записей среди других записей с таким же именем. Формат именования описан в документе RFC 2052, "SRV Record Format and Use".
Служба Windows DNS выводит записи SRV в обратном порядке в виде иерархии папок. Рассмотрим функции записей SRV в зависимости от расположения на консоли DNS.
„MSDCS. Под этим заголовком показаны записи SRV, соответствующие контроллерам домена, ссылкам на домены, серверам глобального каталога и основным контроллерам доменов. Контроллеры домена и серверы глобального каталога разделяются по сайтам. Это позволяет клиентам Active Directory быстро находить локальные серверы. Ссылки на домены поддерживают репликацию. Каждый контроллер домена получает глобально уникальный идентификатор, который используется при вызове репликации. Раздел основного контроллера домена содержит запись- SRV для контроллера домена, назначенного на роль PDC Emulator (этот контроллер домена выступает в роли основного контроллера домена для вторичных контроллеров домена под управлением операционной системы WindowsNT 4.0).
_SITES. Сайт является областью, в которой компьютеры связаны высокоскоростными соединениями по сети, и соответствует одной или нескольким подсетям IP. Индексируя контроллеры домена по сайтам, клиенты могут обращаться в раздел „SITES для обращения к локальным службам вместо отправки запросов LDAP по внешним каналам. Стандартные запросы LDAP отправляются на порт 389. Запросы к глобальному каталогу отправляются на порт 3268.
„ТСР. В этом разделе перечислены все контроллеры домена для этой зоны DNS. Группа „ТСР выступает в роли справочника для всех клиентов, которые не могут найти свой сайт или нуждаются в услугах любого контроллера домена в сети, когда не работает ни один из локальных контроллеров домена.
_UDP. Протокол Kerberos v5 позволяет клиентам получать билеты и менять пароли без установки соединения. Для этого используются UDP-порты, номера которых соответствуют TCP-портам для данной службы. Для выдачи билетов используется UDP-порт 88, а для смены пароля используется UDP-порт 464.
Описание запросов на получение записей srv
Как только пользователь запускает процесс, требующий поиска в базе данных Active Directory, клиентский процесс Active Directory отправляет запрос службе DNS на получение записи SRV для сервера, который предоставляет порты LDAP. Первый запрос отправляется на поиск записей SRV в пределах локального сайта клиента. Это позволяет предотвратить отправку запросов LDAP на любой из контроллеров домена, находящихся в глобальной сети. Если в пределах сайта клиента отсутствует контроллер домена, отправляется запрос на получение записи SRV на любом контроллере домена.
Совет по использованию системного реестра: кэш преобразования имен сайта
Клиенты кэшируют информацию о сайте в следующих разделах системного реестра:
Раздел: HKLM\System\CurrentControlSet\Services\Netlogon\Parameters
Запись: Dynamic Si teName
Данные: "плоское" имя последнего контроллера домена, который аутентифицировал клиента, например de-01
Служба DNS предоставляет все записи SRV, которые соответствуют критериям запроса. Если в пределах сайта существует пять контроллеров домена, служба DNS возвращает пять записей SRV вместе с записью Host, в которой перечислены IP-адреса каждого сервера, указанного в записях SRV. Это отличается от стандартных правил работы службы DNS, когда поочередно возвращается только одна запись из множества записей, соответствующих критерию запроса.
После получения записей SRV клиент выполняет быстрый опрос LDAP, отправляя каждому контроллеру домена запрос на подключение к UDP-порту 389. Первый ответивший контроллер домена выбирается в качестве основного сервера LDAP. Рассмотрим эту транзакцию подробно.
После загрузки операционной системы работающий в сети клиент находит контроллер домена, обращаясь к службе DNS за записями SRV. Клиент отправляет запрос на получение записи _kerberos._tcp.Phoenix._sites.dc._msdcs.Company.com. Обратите внимание, что область видимости этого запроса ограничена контроллерами домена в пределах локального сайта и домена. Клиент хранит имя сайта в системном реестре в разделе HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\Dynamic Sit eName.
После получения запроса сервер DNS возвращает все записи SRV, которые соответствуют критерию запроса. Записи сортируются по приоритету и весу.
После получения записей SRV клиент отправляет тестовый запрос LDAP (единственный UDP-пакет) на порт 389 каждого контроллера домена, указанного в записях SRV. Пакеты отправляются последовательно по десять пакетов за секунду.
Как только контроллер домена получает запрос LDAP, он возвращает ответ LDAP. Первый ответивший контроллер домена выбирается клиентом как регистрационный сервер. После этого клиент пытается провести регистрацию по протоколу Kerberos.
С этого момента клиент ведет себя, как одинокий ребенок, который нашел друга. Клиент заваливает контроллер домена последующими запросами LDAP, запросами на аутентификацию Kerberos и запросами на загрузку групповых политик.
Для идентификации контроллера домена, который аутентифицировал член домена Windows Server 2003, можно воспользоваться утилитой systeminfo. Вот фрагмент отчета с информацией о сервере регистрации:
1,733 MB1,344 MB3 89 MBC:\pagefile.sys company.com\\DC01.company.com0 Hotfix(s) Installed1,733 MB1,344 MB3 89 MBC:\pagefile.sys company.com\\DC01.company.com0 Hotfix(s) InstalledVirtual Memory: Max Size:
1,733 MB
1,344 MB
3 89 MB
C:\pagefile.sys company.com
\\DC01.company.com
0 Hotfix(s) Installed
1,733 MB
1,344 MB
3 89 MB
C:\pagefile.sys company.com
\\DC01.company.com
0 Hotfix(s) Installed
Virtual Memory: Available: Virtual Memory: In Use: Page File Location(s): Domain:
Logon Server:
Hotfix(s):
Если клиент находится в пределах леса, контроллеры домена генерируют ссылки на другие домены. Клиенты используют записи SRV для этих доменов для обнаружения контроллеров, на которых хранятся копии интересующего контекста именования Domain.
Охват сайта
Не существует способа настройки предпочтительного контроллера домена, к которому будет подключаться клиент. Если в большой локальной сети необходимо разделить клиентов в соответствии с различными сегментами локальной или городской сети, топологию репликации придется строить на основе нескольких сайтов. Эта рекомендация остается справедливой, даже если внешние соединения предоставляют достаточную пропускную способность, которая обычно доступна внутри сайтов.
Контроллеры домена автоматически регистрируют записи SRV, используя имя сайта. Кроме этого, клиентам предоставляются ссылки на локальный контроллер домена, чтобы обеспечить обработку запросов LDAP и регистрацию в пределах сайта. Такая возможность “локализации” обеспечивается благодаря соответствию сайта одной или нескольким IP-сетям, соединенным с помощью связей межу сайтами. По IP-адресу клиента контроллер домена может определить сайт клиента. На основе этой информации сервер DNS выдает записи SRV, обеспечивающие локализацию обработки клиентских запросов.
Вот как это работает. Предположим, что в качестве клиента выступает портативный компьютер. Пользователь отключает компьютер, перемещается в Хьюстон и опять подключается к сети.
Клиент получает локальный адрес от сервера DHCP. Клиент помнит, что находится в пределах сайта Phoenix, и отправляет DNS-запрос для получения адресов контроллеров домена в пределах этого сайта.
Сервер DNS возвращает запрошенные записи SRV и клиент отправляет тестовый запрос LDAP на контроллер домена, находящийся в пределах сайта Phoenix.
Контроллер домена в пределах сайта Phoenix проверяет IP-адрес клиента и обнаруживает, что клиент находится в пределах сайта Houston. Для этого контроллер домена сравнивает IP-адрес клиента с объектами IР Subnet в базе данных Active Directory.
Контроллер домена отправляет клиенту ссылку с предложением найти сайт Houston.
Клиент повторно отправляет запрос DNS-серверу на получение записей SRV, но в этот раз клиента интересует контроллер домена в пределах сайта Houston. Таким образом, клиент автоматически реализует "перемещение между сайтами.
Клиенты кэшируют информацию о сайте в следующей записи системного реестра.
Раздел: HKLM\System\CurrentControlSet\Services\Netlogon\Parameters
Запись: DynamicSiteName
Значение: "плоское" имя контроллера домена, который аутентифицировал клиента, например del
Благодаря возможности локализовать сайт клиенты могут быть переданы локальным контроллерам домена, которые выполняют аутентификацию и обработку запросов LDAP. Если в удаленном офисе отсутствует контроллер домена, все равно желательно создать сайт, в пределах которого будет находиться этот офис. В таком случае служба DNS будет выдавать записи SRV из ближайшего сайта, позволяя клиентам работать с ближайшим контроллером домена.
Параметры совместимости
Для сохранения обратной совместимости при наличии контроллеров домена под управлением операционной системы Windows более ранних версий некоторые возможности Active Directory отключаются.
Для доменов Windows Server 2003 возникают две проблемы в области совместимости (если речь идет о совместимости с другими версиями операционной системы Windows).
Взаимодействие с контроллерами домена под управлением Windows NT
Взаимодействие с контроллерами домена под управлением Windows 2000
Каждая из проблем требует своих параметров совместимости.
Взаимодействие с контроллерами домена под управлением операционной системы Windows NT
Контроллеры домена Active Directory могут сосуществовать с контроллерами домена под управлением Windows NT 4.0. Такой режим работы домена называется Windoms 2000 Mixed. В режиме Mixed контроллеры домена под управлением операционной системы Windows Server 2003, назначенные на роль PDC Emulator (эмулятор первичного контроллера домена), для доставки информации на вторичные контроллеры домена под управлением WindowsNT используют классический механизм LMRepl (LanMan Replication).
В режиме Mixed некоторые возможности Active Directory отключены, поскольку они не поддерживаются в операционной системе Windows NT 4.0. Ниже приведен список отключенных возможностей.
Универсальные группы. В группах этого типа могут содержаться члены любого домена в пределах леса. Универсальные группы могут использоваться в списках контроля доступа в любой точке леса.
Вложенность глобальных групп. В режиме Native глобальные группы из различных доменов поддерживают вложенность и могут входить в универсальные группы.
Локальный доступ к локальным для домена группам. В режиме Native локальные для домена группы из Active Directory могут указываться в списках управления доступом на серверах и настольных компьютерах.
Возможность использования транзитивной аутентификации клиентами под управлением более ранних версий операционной системы Windows. После перевода домена в режим Native контроллеры домена могут передавать запросы на аутентификацию по протоколу NTLM, предоставляя клиентам доступ к доменам, доступ к которым невозможен в стандартной структуре главных доменов/доменов ресурсов, принятой в операционной системе Windows NT.
После модернизации или отключения всех вторичных контроллеров домена под управлением операционной системы Windows NT 4.0 домен можно переключить в режим Windows 2000 Native и получить все отключенные возможности. После этого репликация с PDC Emulator на оставшиеся вторичные контроллеры домена под управлением Windows NT 4.0 прекратится. После переключения домена в режим Windows 2000 Native обратное переключение в режим Windows 2000 Mixed будет невозможным.
Функциональные уровни
Несколько возможностей операционной системы Windows Server 2003 несовместимы с операционной системой Windows 2000. Ниже приведен список таких несовместимых функций.
Упростилась методика расчета топологии репликации между сайтами. Это позволяет решить проблему, при которой большая организация с сотнями сайтов сталкивается с неудачной репликацией, когда расчет топологии не может завершиться в течение времени, выделенного на решение этой задачи.
Члены группы теперь реплицируются в виде отдельных элементов, а не в виде целого списка членов группы. Это позволяет решить проблему, при которой изменения членства в группе, внесенные на двух разных контроллерах домена в течение одного цикла репликации, перезаписывали друг друга.
Добавлен новый тип доверительных отношений, который упрощает создание транзитивных доверительных отношений между доменами из разных лесов.
Добавлена поддержка класса объектов inetOrgPerson, который используется в других коммерческих службах каталогов LDAP для описания пользователей. Для объектов inetOrgPerson может быть установлен идентификатор безопасности, и они могут использоваться в качестве участников системы безопасности для регистрации и добавления в списки управления доступом.
В домене Windows Server 2003 поддерживается переименование контроллеров домена. Сами домены можно переименовывать в лесу Windows Server 2003. Это позволяет менять структуру леса, меняя отношения между родительскими и дочерними доменами.
Объекты Schema могут быть объявлены неработающими, чтобы параметры могли использоваться в других объектах Schema. Объект Schema не может быть удален, как не может измениться доменное имя.
Внесение изменений в глобальный каталог, например добавление или удаление атрибута, не требует полной перестройки и репликации глобального каталога.
Пока контроллеры домена под управлением Windows Server 2003 работают вместе с контроллерами домена под управлением Windows 2000, все эти возможности отключены. Как только все контроллеры домена под управлением Windows 2000 модернизированы до Windows Server 2003 или понижены до обычных серверов, домены и лес могут быть переключены на использование полного набора функциональных возможностей операционной системы Windows Server 2003. Это одноразовая необратимая операция. Дополнительную информацию о требованиях и процедуре переключения функциональных уровней можно получить в главе 9, “Развертывание доменов Windows Server 2003".
Совместимость с клиентами
Домены Active Directory на основе операционной системы Windows Server 2003 совместимы с любыми клиентами под управлением операционной системы Windows, а также с клиентами под управлением Microsoft DOS и с большинством современных версий Samba.
Справедливо и обратное утверждение. Операционные системы Windows Server 2003 и Windows ХР могут работать в любой среде доменов Windows: в классических рабочих группах, классических доменах WindowsNT, доменах Active Directory под управлением Windows 2000 и, конечно, в доменах Active Directory под управлением Windows Server 2003 (единственным исключением является операционная система Windows ХР Home Edition, которая не поддерживает работу ни в одном из типов доменов).
Одна из скрытых проблем операционной системы Windows 2000 была исправлена с выходом операционных систем Windows Server 2003 и Windows 2000 Service Pack 2. Клиенты под
управлением Windows, способные использовать аутентификацию на основе протокола Kerberos, при работе в доменах более ранних версий используют аутентификацию NTLM по типу “запрос—ответ”. Это значит, что такие клиенты могут подключаться к вторичным контроллерам домена и принимать участие в сквозной аутентификации.
Скачок нагрузки
При модернизации домена до Active Directory клиенты, способные использовать протокол Kerberos, меняют флаг в базе данных безопасности и отключают механизм аутентификации NTLM “запрос—ответ”, переходя на использование исключительно протокола Kerberos. Это значит, что при развертывании нескольких тысяч рабочих станций под управлением операционных систем Windows 2000 и Windows ХР в домене WindowsNT и при последующей модернизации одного основного контроллера домена все рабочие станции попытаются получить аутентификацию на этом контроллере. Компания Microsoft признает, что такой механизм приводит к резкому скачку нагрузки на контроллер домена.
Кроме этого, после аутентификации на контроллере домена Active Directory этот клиент больше никогда не будет использовать механизм аутентификации NTLM и всегда будет выполнять аутентификацию на контроллере домена Active Directory. Если в сети остались доступными только вторичные контроллеры домена, рабочая станция будет выполнять аутентификацию пользователей с помощью кэшированных данных, но не обратится к доступному вторичному контроллеру домена. Это может привести к проблемам во время модернизации основного контроллера домена, когда в сети уже развернуто много рабочих станций и серверов под управлением операционных систем Windows 2000, Windows ХР и Windows Server 2003. Если клиенты находятся в Хабаровске, а основной контроллер домена — в Ростове, утренняя регистрация клиентов из Хабаровска будет выполняться исключительно медленно.
Чтобы избежать этой проблемы, в операционную систему Windows Server 2003 включена возможность, которая позволяет контроллеру домена Active Directory “представляться” клиентам как контроллер домена более ранней версии. После того как будет установлено достаточно контроллеров домена под управлением Windows Server 2003, чтобы обработать все запросы на регистрацию, можно отказаться от этой маскировки и разрешить клиентам использовать протокол Kerberos.
Эта возможность обеспечивается благодаря записи в системном реестре, которая заставляет контроллеры домена под управлением Windows Server 2003 выдавать себя за контроллеры домена под управлением Windows NT 4.0. Эта запись хранится в следующем разделе:
I
Раздел:HKLM\System\currentcontrolSet\Services\Netlogon\Parameters
Запись: NT4Emulator
Значение: 1 (reg_dword)
Важно указать эту запись на каждом контроллере домена под управлением операционной системы Windows NT 4.0 до модернизации. Контроллер домена все равно будет регистрировать записи SRV, но при поступлении запроса на аутентификацию от современного клиента Windows контроллер домена будет отвечать с использованием протокола аутентификации NTLM.
Особые соображения по поводу эмуляции Windows NT 4.0
Во время использования записи NT4Emulator рабочие станции под управлением операционных систем Windows ХР и Windows 2000 будут продолжать использование протокола аутентификации NTLMv2 и не станут переходить на использование протокола Kerberos. Это налагает следующие ограничения.
Клиенты не могут загружать или применять групповые политики.
На клиенте нельзя использовать утилиты управления Active Directory, например, Active Directory — Users and Computers (Active Directory — пользователи и компьютеры) и Active
Directory — Sites and Services (Active Directory — сайты и службы), так как клиент не прошел аутентификации по протоколу Kerberos и не может получать доступ к базе данных Active Directory по протоколу LDAP.
Невозможно повысить сервер до контроллера домена, поскольку нельзя использовать протокол LDAP для обращения к существующим контроллерам домена.
Если запись NT4Emulator установлена на контроллерах корневого домена леса, создание новых доменов в пределах леса оказывается невозможным, так как новый контроллер домена не сможет использовать протокол LDAP для взаимодействия с существующими контроллерами корневого домена.
Эти ограничения можно обойти, если разрешить некоторым клиентам эмуляцию NT4Emulator контроллером домена и все равно выполнять аутентификацию с использованием протокола Kerberos. Для этого в системный реестр клиента необходимо добавить следующую запись:
Раздел: HKLM\System\CurrentContгolSet\Services\Netlogon\Parameters
Запись: NeutralizeNT4Emulator
Значение: 1 (reg_dword)
После добавления этой записи в системный реестр завершите сеанс и повторно зарегистрируйтесь в домене. Рабочая станция найдет контроллер домена под управлением операционной системы Windows Server 2003 и запросит аутентификацию по протоколу Kerberos. Для проверки правильности работы клиента можно воспользоваться утилитой kerbtray, которая входит в состав Resource Kit.
После добавления достаточного количества контроллеров домена под управлением операционной системы Windows Server 2003, которые смогут обработать планируемое количество запросов на аутентификацию по протоколу Kerberos и планируемое количество запросов на загрузку групповых политик, установите параметр NT4Emulator равным нулю в системном реестре каждого контроллера домена. После изменения значения записи перезагрузите контроллер домена. Это позволит контроллеру домена обрабатывать запросы на аутентификацию как по протоколу NTLMv2, так и по протоколу Kerberos. Во избежание путаницы проверьте значение записи NT4Emulator на каждом контроллере домена.
Основные особенности пространств имен Active Directory
Еще раз перечислим наиболее важные элементы структуры пространства имен Active Directory, которые стоит запомнить. Эта информация позволяет принимать критически важные решения при проектировании и развертывании Active Directory в организации.
База данных Active Directory разделена на несколько элементов репликации, которые называются контекстами именования. Существует четыре контекста именования: Domain, Configuration, Schema и Application.
Домены Active Directory формируют отдельные единицы управления и безопасности, а также отдельные контексты именования.
Каждый контроллер домена в пределах леса содержит копию контекста именования Configuration и контекста именования Schema. Это позволяет обеспечить одинаковое представление о топологии, операциях и управлении базой данных Active Directory на каждом контроллере домена.
Отдельные дрмены Active Directory могут быть связаны в общую структуру безопасности. Если домены используют общее пространство имен DNS, они формируют дерево. Если домены не используют общее пространство имен DNS, они формируют лес.
В Active Directory доверительные отношения между доменами используются для создания деревьев, лесов и безопасных соединений с внешними доменами, лесами и сферами MIT Kerberos. Также доверительные отношения могут использоваться для создания урезанного доверительного отношения между доменами одного леса.
Между доменами Windows, использующими протокол Kerberos для аутентификации, можно создавать транзитивные и двусторонние доверительные отношения. С доменами на основе более старых версий Windows можно создавать только односторонние и нетранзитивные доверительные отношения.
Active Directory позволяет увеличить скорость поиска по нескольким доменам LDAP благодаря добавлению частичных копий всех контекстов именования Domain в глобальный каталог. Все контроллеры домена могут хранить копию глобального каталога.
Для поиска служб Active Directory на контроллерах домена клиенты Active Directory используют записи SRV, предоставляемые службой DNS. Клиенты предпочитают использовать локальные контроллеры домена, стараясь повысить производительность и сократить объем данных, передаваемых по внешним каналам.
Операционная система Windows Server 2003 обеспечивает обратную совместимость с доменами на основе Windows NT 4.0 и Windows 2000.
Для поддержки полного набора функциональных возможностей Active Directory все домены в пределах леса и сам лес должны быть переведены на функциональный уровень Windows Server 2003.
Схема Active Directory
При рассмотрении структуры и операций службы каталогов до этого момента использовались универсальные термины, относящиеся практически ко всем реализациям LDAP. Пришло время обратить внимание на особенности Active Directory. Приведенная здесь информация может показаться лишней с точки зрения ежедневного обслуживания домена на основе Windows Server 2003, но знание деталей функционирования службы каталогов позволяет создавать надежные проекты доменов и быстро диагностировать возникающие неисправности.
Если коротко, то объектно-ориентированная база данных LDAP, которая лежит в основе Active Directory, построена на основе набора классов объектов и соответствующих атрибутов. Отдельные объекты являются экземплярами классов объектов. Схема определяет доступные классы объектов, их атрибуты, типы данных, допустимые диапазоны значений атрибутов и правила размещения объектов в базе данных Active Directory и управления ими.
Функции схемы
Чтобы понять принципы работы схемы, представьте простой бумажный каталог. Каждый месяц я получаю каталог от продавца одежды Land’s End. Каталог в определенном смысле является базой данных, похожей на службу каталогов, но пользователю предоставляются данные об одежде, а не о элементах сети. Рассмотрим пример.'
Схема каталога определяет набор классов объектов в области видимости “Предметы одежды, продаваемые Land’s End”. Эти классы описывают объекты, интересующие покупателя одежды, например “Свитера”, “Костюмы”, “Пиджаки”, “Аксессуары” и т.д.
Кроме этого, схема определяет доступные атрибуты, которые могут присутствовать в классе объекта, например “Размер”, “Цвет”, “Длина шва” и “Цена", а также более специализированные атрибуты, характерные для каталога, например “Изображение предмета одежды”.
В схеме определяются правила для содержимого (content rules), в которых устанавливается, какие атрибуты могут быть связаны с определенным классом. Некоторые атрибуты, например “Размер” и “Цвет”, могут быть связаны практически с каждым классом. Атрибут “Длина шва” может быть связан только с классами “Брюки” и “Джинсы”, но не с классами “Спортивная куртка” и “Туфли".
Некоторые классы одежды имеют практически одинаковые атрибуты. Например, атрибуты класса “Рубашка с коротким рукавом” совсем незначительно отличаются от атрибутов класса “Спортивная рубашка". Класс “Рубашка с коротким рукавом” является потомком класса “Спортивная рубашка” и наследует атрибуты своего родителя. Новые атрибуты просто добавляются в порожденном классе.
Наследование классов требует использования структурных правил (structure rules), которые поддерживают связь каталога с реальным миром. Например, структурное правило предотвращает размещение объекта класса “Банный халат” в контейнере класса “Туфли”.
Конкретные предметы одежды являются экземплярами (instance) класса одежды. Например, экземпляром класса “Пиджак” является настоящий красный пиджак с зелеными полосами, который я подарил брату на последнее Рождество.
Схема Land’s End содержит синтаксические правила (syntax rules), определяющие значения, которые могут быть связаны с атрибутами. Например, атрибут “Размер” должен быть целым числом, а аргумент “Размер обуви" может иметь дробное значение.
Поскольку классы' одежды и их атрибуты меняются, каталог Land's End поддерживает функцию расширения (extensible). Например, в класс “Пиджак” может быть добавлен новый атрибут, который называется “Количество пуговиц".
Для увеличения гибкости определенные специальные классы объектов могут назначаться : динамически (dynamically assigned) определенному объекту. Это позволяет создавать спе- j циальные наборы атрибутов для определенных объектов, например “Красные футболки", 1 не меняя остальные экземпляры класса, например “Футболки”.j
Это был длинный пример, поэтому повторим ключевые термины и концепции.1
Классы объектов. Определяют объекты, которые могут храниться в Active Directory, и 1 атрибуты этих объектов.|
Наследование классов. Определяет метод создания нового класса объектов на основе су- | ществующего класса объектов.1
Атрибуты объектов. Определяет доступные атрибуты, в том числе расширенные атрибу- 1 ты, которые управляют операциями с классами объектов.1
Структурные правила. Определяют возможные конфигурации дерева.I
Синтаксические правила. Определяют типы значений атрибутов.1
Правила для содержимого. Определяют атрибуты, которые могут быть связаны с опреде- 1 ленным классом.1
Расширяемая схема. Есть возможность добавлять классы объектов и атрибуты.л
Динамическое назначение классов. Некоторые классы могут быть автоматически назна- а чены конкретному объекту, не меняя весь класс объектов.■
Классы объектов и наследование классов
Класс объектов представляет собой именованный набор атрибутов. Например, класс User имеет атрибуты, которые отличают его от классов Organizational-Unit и Server. В обновленной версии стандарта Х.500/9594, которая описана в документе RFC 2256, “A Summary of the Х.500/(96) User Schema for use with LDAPv3”, определяются 21 класс и 55 атрибутов стандартной схемы каталога LDAP.
Схема Active Directory значительно расширяет этот список, определяя 200 классов и около 1700 атрибутов. Полный перечень доступных классов и атрибутов доступен в Windows Server 2003 Platform SDK или на сайте MSDN по адресу msdn.microsoft. com.
Стандартные классы и атрибуты LDAP в службе каталогов Active Directory
Схема Active Directory содержит все классы, перечисленные в документе RFC 2256, кроме классов Alias и Strong-Authentication-User, а также все атрибуты, кроме Aliased- Object-Name. Класс Alias был исключен намеренно. Псевдонимы являются одной из основных причин снижения производительности и проблем целостности служб каталогов. Кроме этого, большинство классов объектов, которым присваиваются псевдонимы, в Active Directory должны иметь уникальные имена. Среди таких классов можно назвать User, Computer и Group.
В составе Windows Server 2003 предоставляется класс inetOrgPerson, определенный в документе RFC 2798, “Definition of the inetOrgPerson Object Class”. Это делает службу каталогов Active Directory более совместимой со службами каталогов Netscape Directory Services и Novell Directory Services, которые наследуют класс User из класса inetOrgPerson.
Правила схемы
Недостаточно определить компоненты схемы с точки зрения объектов, операций и отношений. Правила и обычаи необходимы во избежание анархии. Для этого используются правила схемы (schema rules). Разработчики службы каталогов встраивают в схему правила, которые определяют использование классов и атрибутов, допустимые значения атрибутов и правила взаимодействия между классами. Существует три категории правил.
Структурные правила
Правила для содержимого
Синтаксические правила
Структурные правила
Фрэнк Ллойд Райт (Frank Lloyd Wright) определил парадигму проектирования для архитектуры XX столетия, заявив, что форма всегда должна следовать за функцией. Конечно, он был архитектором зданий, а не архитектором служб каталогов, но Active Directory слишком монументальна, чтобы служить беседкой. Эта монументальность определяется структурными правилами.
На самом деле в Active Directory существует только одно структурное правило: над каждым классом объектов могут находиться только определенные классы, которые называются допустимые суперклассы (Possible Superiors). Это очень важное структурное правило, поскольку классы наследуют атрибуты от родительских классов. Структурные правила предотвращают размещение объекта класса User в совершенно произвольном классе контейнера, например, IPSEC-Base или NTDS Settings.
Правила для содержимого
Каждый класс объектов имеет определенные атрибуты, которые обязательно должны получить значения при создании экземпляра класса. Это так называемые обязательные атрибуты (must-contain attributes). Например, для каждого экземпляра класса User должно быть установлено значение атрибута Common-Name. Другие атрибуты являются необязательными атрибутами (may-contain attributes).
Важным принципом проектирования Active Directory является хранение в базе данных только тех атрибутов, для которых установлены значения. Это позволяет значительно упростить базу данных и сократить ее размер. Поскольку атрибуты могут добавляться и после создания объекта с последующим удалением с помощью установки атрибута равным нулю, механизм управления базой данных должен постоянно “пересматривать” данные. Эта функция реализуется службой сборки “мусора”, которая запускается каждые 12 часов.
Синтаксические правила
Атрибуты хранят данные. Данные должны иметь тип, который определяет требования к подсистеме хранения. Действительные числа хранятся в форме, отличной от формы хранения целых чисел или длинных целых чисел, которые отличаются от строк символов.
Атрибут может иметь только один тип данных. Атрибут не может хранить строку в одном объекте и целое число — в другом. Синтаксические правила в схеме определяют допустимые типы значений и диапазоны атрибутов.
Объекты описания схемы
Отдельные объекты всегда являются экземплярами класса объектов. Этот принцип проектирования подразумевает использование шаблона, который определяет атрибуты, правила схемы и иерархию классов объектов внутри класса объектов. Это касается и атрибутов, которые нуждаются в шаблоне для описания синтаксических правил. Такой набор шаблонов составляет определение схемы для информационного хранилища службы каталогов.
Некоторые службы каталогов хранят определение схемы в отдельном файле, который считывается в процессе загрузки или при каждом изменении схемы. В службе каталогов Active Directory схема является самоопределяемой. Это значит, что все определения классов, определения атрибутов и правила схемы являются частью самой схемы. Подходящим названием для руководства по принципам работы схемы Active Directory было бы “Все, что мне нужно, я узнал от самого себя”.
Схема Active Directory содержит два класса объектов схемы, ClassSchema и Attribute Schema. Объекты, созданные на основе этих классов, выступают в роли шаблонов для создания других объектов. Объекты схемы хранятся в каталоге в контейнере cn=Schema, cn=Configuration,de=<имя_домена>,5с=<корень_домена>.
Кроме классов ClassSchema и Attributeschema, контейнер Schema содержит класс SubSchema, в котором содержится всего один экземпляр Aggregate. Составное имя этого объекта выглядит как cn=aggregate,cn=schema, cn=configuration,dc=company,dc=com. Объект Aggregate выступает в роли единого источника информации о схеме Active Directory для клиентов LDAP. Без этого объекта клиентам пришлось бы выполнять сканирование всего контейнера Schema.
Идентификация объектов
Выше были полностью рассмотрены структура, функции и правила схемы. Прежде чем двигаться дальше, рассмотрим методы уникальной идентификации объектов в Active Directory. Эта информация исключительно важна для работы с более сложными инструментами Active
Directory. Вот краткий список атрибутов для объекта User, созданного с помощью утилиты Idifde. Полужирным шрифтом выделены уникальные идентификаторы.
C:\>ldifde -d cn=administrator,cn=users,dc=testdomain -f con Connecting to "DC01.Company.com" Logging in as current user using SSPI Exporting directory to file con Searching for entries...
Writing out entries.dn: CN=bgates,CN=Users,DC=dotnet,DC=com changetype: add objectclass: top'
objectclass: person objectclass: organizationalPerson objectclass: user ccn: bgates distinguishedName: CN=bgates,CN=Users,DC=dotnet,DC=com instanceType: 4 whenCreated: 20020812134034. OZ whenChanged: 20020812134034 . OZ uSNCreated: 13772 uSNChanged: 13774 name: bgates-
objectGUID:: 7swJ8PXwqkWu8N2Qv+jQ+Q== userAccountControl: 512 badPwdCount: 0 codePage: 0 countryCode: 0 badPasswordTime: 0 lastLogoff: 0 lastLogon: 0 pwdLastSet: 126736332347481024 primaryGroupID: 513 objectSid:: AQUAAAAAAAUVAAAAdbllVBUlr0cWwOoyVQQAAA== accountExpires: 0 logonCount: 0 sAMAccountName: bgates userPrincipalName: bgates@dotnet.com sAMAccountType: 805306368 objectcategory: CN=Person,CN=Schema,CN=Configuration,DC=dotnet,DC=com
Характерное имя
Поскольку LDAP использует объектно-ориентированную базу данных, очень важно, чтобы каждый объект имел уникальное имя в пространстве имен, как каждый файл имеет уникальное имя в файловой системе.
Атрибут “характерное имя” (Distinguished Name — DN) определяет путь LDAP к объекту от корня пространства имен; таким образом, характерное имя объекта должно быть уникальным. Если переместить объект в другой контейнер Active Directory, на самом деле изменится только характерное имя этого объекта.
Глобально уникальный идентификатор
В классическом продукте Exchange компания Microsoft использовала характерное имя в качестве уникального идентификатора строки базы данных для объектов в хранилище службы каталогов. Это неудачное решение создало проблемы при настройке Exchange. При перемещении объекта меняется его характерное имя, но уникальный идентификатор строки не меняется никогда. Именно по этой причине в Exchange версии 5.5 и более ранних версий по-
лучатели почты не могли быть перемещены, а должны были создаваться заново и связываться с учетной записью User в базе данных SAM.
Чтобы избежать этой проблемы в Active Directory, компания Microsoft решила использовать другой уникальный идентификатор строки, который называется глобально уникальный идентификатор, или GUID (Globally Unique Identifier). Алгоритм создания глобально уникального идентификатора практически гарантирует уникальность идентификатора в пределах системы.
Используя глобально уникальный идентификатор, можно произвольно перемещать объекты из одного контейнера в другой, не меняя уникальный номер строки объекта, а значит, поддерживая внутреннюю целостность ссылок в базе данных. Запомните эту особенность, поскольку она будет иметь большое значение при изучении контроллера Infrastructure Master (Хозяин инфраструктуры), при отслеживании им информации о членстве в группах для пользователей из других доменов.
Другие способы применения GUID
Компания Microsoft использует алгоритм генерации идентификатора GUID в различных ситуациях. Идентификаторы GUID используются в дескрипторах объектов СОМ и операциях регистрации объектов OLE. Групповые политики используют идентификаторы GUID для создания уникального имени папки каждой политики. Во время инвентаризации устройств Plug and Play операционная система использует идентификаторы GUID для идентификации аппаратных компонентов. Идентификаторы GUID иногда называют универсально уникальными идентификаторами UUID (Universally Unique Identifier) и идентификаторами классов CLSID (Class ID).
Идентификатор безопасности
В списки управления доступом для защиты объектов безопасности могут добавляться три класса объектов Active Directory. Это классы User, Computer и Group. Все вместе они называются участниками системы безопасности (security principal).
Участнику системы безопасности присваивается уникальный номер, который называется идентификатором безопасности SID (Security Identifier). Это тот же идентификатор безопасности, который используется в Windows NT для идентификации пользователей, групп и компьютеров. Идентификатор SID участника системы безопасности состоит из идентификатора безопасности домена и уникального суффикса, который называется относительным идентификатором RID (Relative ID). Относительные идентификаторы для создаваемых администратором участников системы безопасности начинаются с числа 1000. Например, первая учетная запись User, созданная после домена, получит относительный идентификатор 1000. Следующий объект, например группа, получает относительный идентификатор 1001 и т.д.
Комбинация идентификатора безопасности SID и относительного идентификатора RID составляет номер, уникальный в пределах домена и в пределах леса. Пул идентификаторов RID поддерживается и обслуживается специально выделенным контроллером домена Windows Server 2003, который называется RID Master (Хозяин относительных идентификаторов).
Имя учетной записи SAM
В домене Windows NT каждый объект в базе данных SAM должен иметь уникальное имя. Это справедливо для компьютеров, пользователей и групп. Уникальное имя гарантирует, что объект будет уникально определяться в сети NetBIOS и позволит создавать однозначное соответствие между регистрационным именем (в данном случае — именами компьютеров или пользователей) и идентификатором безопасности SID, который используется для управления доступом к ресурсам.
Такое же ограничение налагается в операционных системах Windows 2000 и Windows Server 2003. Каждый пользователь, компьютер и группа должны иметь уникальное имя в пре-
делах домена. Этот атрибут называется SAMAccountName, хотя иногда встречаются названия регистрационное имя (logon name) и “плоское” имя (flat name). При создании нового участника системы безопасности регистрационное имя объекта должно быть уникальным в пределах домена вне зависимости от контейнера, в котором будет храниться объект.
Основное имя пользователя и основное имя службы
Так же, как уникальные регистрационные имена идентифицируют участников системы безопасности в NetBIOS, полное доменное имя пользователя UPN (User Principal Name) служит для идентификации участников системы безопасности в пределах иерархического пространства имен LDAP базы данных Active Directory. Формат полного доменного имени пользователя выглядит как UserSCompany . com.
Уникальность полного доменного имени пользователя обеспечивает возможность регистрации пользователя с помощью этого имени и позволяет отказаться от классической конструкции домен\имя пользователя. Для анализа составляющих в имени UPN используется глобальный каталог.
Чтобы обеспечить уникальность при создании участника системы безопасности, система отправляет запрос в глобальный каталог для проверки существования данного полного доменного имени пользователя. Если сервер глобального каталога недоступен, система выдает сообщение об ошибке, в котором администратору предлагается подождать доступности глобального каталога для проверки уникальности имени.
При использовании доверительных отношений по типу “родитель—потомок” суффикс полного доменного имени пользователя корневого домена назначается каждому участнику системы безопасности. При использовании доверительных отношений между деревом и корневым доменом необходимо вручную указывать общий суффикс полного доменного имени пользователя. Это можно сделать в окне свойств дерева доменов на консоли Active Directory — Domains and Trusts (Домены и отношения доверия Active Directory).
Идентификатор объекта
Кроме атрибутов, которые обеспечивают уникальность определенного объекта, база данных Active Directory должна гарантировать, что объекты одного класса генерируются на основе одинаковых объектов Schema. Для этого каждому объекту в контексте именования Schema назначается идентификатор объекта OID (Object Identifier). Структура и распределение идентификаторов объекта описаны в стандарте ISO/IEC 8824:1990, “Information Technology — Open Systems Interconnection — Specification of Abstract Syntax Notation One (ASN.l)”.
Стандарт ASN.l определил для организаций по стандартизации из разных стран стандартные элементы данных, что позволяет избегать взаимных конфликтов. Стандарт ASN.l предназначен не только для классов и атрибутов служб каталогов. Например, идентификаторы объектов широко применяются в SNMP для создания иерархий чисел Management Information Base (Ml6). Кроме этого, идентификаторы объектов присваиваются многим компонентам, связанным с Интернет. Список организаций, назначающих идентификаторы объектов, и их иерархия доступны по адресу ftp. isi . edu/in-notes/iana/assignments/ enterprise-numbers.
Если необходимо создать новый атрибут или класс объектов для Active Directory, придется получить уникальный идентификатор объекта. Для этого существует несколько способов. Первый способ подразумевает запрос у института стандартизации (ANSI) собственной последовательности номеров. Это будет стоить несколько тысяч долларов и займет некоторое время. Еще один способ подразумевает использование утилиты oidgen из состава Resource Kit. Эта утилита сгенерирует идентификаторы объектов для класса и атрибута. Идентификаторы будут находиться в пределах пространства идентификаторов, выделенных компании Microsoft. Недостатком использования утилиты oidgdn является очень и очень большая
длина номера, как показано в следующем примере (числа были перенесены на следующую строку из-за ограниченных размеров страницы).
с:\>oidgen
Attribute Base OID:
1.2.840.113556.1.4.7000.233.180672.443844.62.26102.2020485.
'Ъ 1873967.207938
Class Base OID:
1.2.840.113556.1.5.7000.111.180672.443844.62.199519.642990.
4> 1996505.1182366
Поиск информации об иерархии идентификаторов объектов
Множество благодарностей отправляется Гаральду Альвестранду (Harald Alvestrand), который за долгую зиму в Тронхейме, Норвегия, создал дерево гиперссылок, в котором содержится информация об известных регистрациях идентификаторов объектов. Эта информация немного устарела, но структура все еще действительна и очень полезна. Дополнительная информация доступна на сайте по адресу www.alvestrand.no/objectid.
Расширение схемы для поддержки возможностей Windows Server 2003 R2
При создании операционной системы Windows Server 2003 R2 ставилась задача сохранения максимальной совместимости с предыдущими версиями. Это касается и схемы Active Directory. Если вы не планируете использовать новые возможности Windows Server 2003 R2 на контроллере домена, то нет необходимости внесения изменений в текущую схему Active Directory. В противном случае или при необходимости использования сервера под управлением Windows Server 2003 R2 в качестве контроллера домена, придется подготовить Active Directory, расширив схему, чтобы она удовлетворяла новым требованиям. Ниже перечислены возможности, для которых необходимо расширение схемы.
Служба репликации Distributed File System (DFS). Требуется добавление новых классов объектов в контекст именования домена и в группы репликации. Кроме того требуется добавление новых классов объектов в класс объектов Computer в контексте именования домена с целью поддержки специальных параметров, необходимых для выполнения репликации DFS.
Консоль Print Management (Управление печатью). Требует добавления нового класса объектов для добавления информации о развертываемых принтерах.
Identity Management for UNIX (Управление идентификацией для UNIX). Требует добавления новых классов объектов для отображения элементов на карте NIS (Network Information Service).
Для внесения изменений в схему следует обладать привилегиями группы Schema Admins (Администраторы схемы).
Новые классы объектов определены в файле Sch31.1df, который находится на втором инсталляционном компакт-диске Windows Server 2003 R2.
При расширении схемы нет необходимости повышать контроллеры домена до Windows Server 2003 R2; они по-прежнему могут работать под управлением Windows Server 2000 или Windows Server 2003. Однако Identity Management for UNIX устанавливается только на контроллере домена Windows Server 2003 R2.
Расширение схемы необходимо при повышении контроллера домена до Windows Server 2003 R2 или при установке Active Directory на сервер под управлением Windows Server 2003 R2, чтобы превратить этот сервер в контроллер домена.
Файлы поддержки Active Directory
Механизм ESE, который используется в Active Directory, основан на технологии баз данных Microsoft Jet. Jet использует файловую структуру в виде b-дерева с журналом транзакций, который обеспечивает восстановление в случае отказа системы или диска.
После повышения сервера до контроллера домена необходимо указать место хранения файлов Active Directory. По умолчанию файлы хранятся в загрузочном разделе в каталоге \windows\NTOS. Обычно для повышения производительности эти файлы следует размещать на отдельном диске.
В следующем списке перечислены файлы поддержки Active Directory и описаны их функции.
■ Файл ntds.dit. Это основная база данных Active Directory. NTDS расшифровывается как NT Directory Services. DIT расшифровывается как Directory Information Tree (информационное дерево каталога). В файле ntds.dit на конкретном контроллере домена содержатся все контексты именования, которые хранятся на этом контроллере домена, включая контексты именования Configuration и Schema. Глобальный каталог содержит частичные копии контекстов именования в файле ntds. dit рядом с полной копией контекста именования Domain для этого домена.
■ Файл edb. log. Это журнал транзакций. Любые изменения объектов Active Directory сначала сохраняются в журнале транзакций. Во время снижения нагрузки на центральный процессор база данных применяет транзакции к основному файлу ntds. dit. Это обеспечивает возможность восстановления базы данных в случае сбоя системы. Записи, которые не были внесены в файлы ntds.dit, хранятся в памяти для повышения производительности. Размер используемых механизмом ESE файлов транзакций никогда не превышает 10 Мбайт.
Файлы edbxxxxx. log. Это вспомогательные журналы транзакций, которые используются для хранения изменений, если файл edb.log будет переполнен до внесения изменений в файл ntds.dit. Вместо ххххх используется последовательный шестнадцатеричный номер. После заполнения файла edb. log открывается файл edbtemp. log. Оригинальный файл edb.log переименовывается в edb00001.log, а файл edbtemp.log переименовывается в edb.log. Утилита esent использует циклический журнал транзакций. Лишние файлы журнала удаляются после внесения изменений в базу данных. Если на контроллере домена в очереди стоит много операций по обновлению базы данных, то одновременно может существовать несколько файлов edbxxxxx. l og.
Файл edb. chk. Это файл контрольной точки (checkpoint file). Файл используется системой протоколирования транзакций для отметки времени внесения обновлений из файлов журналов в базу данных ntds. dit. После внесения транзакций в базу данных контрольная точка смещается в файле edb. chk вперед. Если произойдет аварийное завершение работы системы, контрольная точка покажет, на каком этапе закончилось внесение транзакций.
Файлы reel. log и res2. log. Это резервные файлы журнала. Если дисковое пространство закачивается при попытке создания файла edbxxxxx. log, то используется дисковое пространство, выделенное ранее для хранения файлов res. При этом на экран выдается предупреждение о необходимости освободить дисковое пространство до повреждения базы данных Active Directory. Никогда нельзя допускать переполнения тома с базой данных Active Directory. Фрагментация файлов значительно снижает производительность. При сокращении дискового пространства резко увеличивается доля фрагментированных файлов. Кроме этого, при отсутствии свободного дискового пространства могут возникнуть проблемы в процессе дефрагментации (сжатия) базы данных. Невозможность обновления индексов может привести к неработоспособности Active Directory.
Файл temp.edb. Это временный файл, в котором хранится информация о текущих транзакциях, а также страницы, извлеченные из базы данных ntds. dit во время сжатия.
Файл schema. ini. Этот файл используется для инициализации файла ntds. di t во время повышения сервера до контроллера домена. После повышения этот файл не используется.
Утилиты Active Directory
Выше были рассмотрены все компоненты Active Directory. В следующих нескольких главах будет показано, как их использовать для создания надежной и полезной структуры. Но сначала рассмотрим инструменты, которые предоставляются в составе Active Directory. Доступ к некоторым утилитам появляется при повышении сервера до контроллера домена Windows Server 2003. Некоторые утилиты доступны на установочном компакт-диске операционной системы Windows Server 2003, а часть утилит предоставляется в составе Resource Kit, который необходимо приобретать отдельно. В тексте будет указано место хранения каждой утилиты.
Стандартные консоли управления Active Directory
В составе операционной системы Windows Server 2003 предоставляются три консоли ММС, которые предназначены для просмотра объектов Active Directory и управления ими. Файлы консоли ММС имеют расширение .msс. Консоли управления различаются по контексту именования, которым можно управлять с помощью консоли.
Active Directory — Users and Computers (Active Directory — пользователи и компьютеры). Эта консоль используется для управления содержимым контекста именования Domain. Консоль хранится в файле Dsa.msc.
Active Directory — Sites and Services (Active Directory — сайты и службы). Эта консоль используется для управления контейнерами Sites и Services, которые расположены в контексте именования Configuration. Консоль хранится в файле Dssi te. msc.
Active Directory — Domains and Trusts (Домены и отношения доверия Active Directory).
Эта консоль используется для управления содержимым контейнера Partitions, который находится в контексте именования Configuration. Для идентификации доменов леса в составе иерархии используются объекты CrossRef, расположенные в контейнере Partitions. Консоль хранится в файле Domain .msc.
В операционной системе Windows Server 2003 эти консоли можно запустить из меню Start (Пуск), выбрав Startc>Programsc>Administrative Тоо\8^<имя_консоли> (Пуск^Программы^ АдминистрированиесХДия консоли>). Кроме этого, консоль можно запустить, введя имя файла консоли, например dssite.msc, в диалоговом окне Run (Выполнить) или в приглашении командной строки. Более подробные инструкции по использованию этих консолей управления приводятся в оставшихся главах, посвященных Active Directory. Знакомясь с консолями управления, важнее всего обратить внимание, что практически все функциональные возможности доступны после щелчка правой кнопкой мыши. Всего несколько операций требуют использования меню.
Представления виртуального списка
Администраторы операционных систем Windows 2000 могут обратить внимание на другой способ вывода списков, полученных в результате запроса LDAP.
В операционной системе Windows 2000 результат поиска предоставлялся клиенту в виде 1500 записей, выданных в порядке обнаружения соответствующих записей в базе данных. Это усложняло управление списками выбора, поскольку записи были не отсортированы.
В операционной системе Windows Server 2003 результат поиска полностью загружается на сервер, сортируется и только после этого выдается клиенту. Это значит, что списки выбора оказываются автоматически отсортированными в алфавитном порядке, что значительно упрощает выбор конкретного элемента.
Консоль Schema
Компания Microsoft значительно затруднила доступ к контексту именования Schema. Не существует стандартной консоли, предназначенной для управления схемой. Для этой цели придется создавать собственную консоль, которая содержит оснастку Schema. Оснастка представляет собой библиотеку DLL, которая загружается выполняемым файлом консоли ММС. После добавления необходимых оснасток консоль можно сохранить в виде файла с расширением .msc.
Перед созданием собственной консоли ММС для управления схемой необходимо получить доступ к оснастке Schema. Эта оснастка входит в состав административных инструментов, но по умолчанию она не зарегистрирована. Это позволяет предотвратить неосторожное изменение схемы. Для регистрации оснастки Schema откройте окно командного интерпретатора, перейдите в каталог с: \Windows\System32 и запустите команду regsvr32 schmgmt.dll.
После регистрации оснастки Schema создайте собственную консоль ММС, как описано в процедуре 6.1.
Процедура 6.1. Создание собственной консоли управления Schema
В окне Run (Выполнить) введите команду пипс и щелкните на кнопке ОК. Откроется пустая консоль ММС.
В меню File (Файл) выберите команду Add/Remove Snap-in (Добавить/Удалить оснастку).
В открывшемся окне Add/Remove Snap-in (Добавить/Удалить оснастку) щелкните на кнопке Add (Добавить). Откроется окно Add Standalone Snap-in (Добавить изолированную оснастку).
Дважды щелкните на пункте Active Directory Schema (Схема Active Directory) и щелкните на кнопке Close (Закрыть).
Щелкните на кнопке ОК, чтобы сохранить изменения и вернуться на консоль М МС. В папке Console Root появится дерево оснастки Active Directory Schema.
Сохраните файл под подходящим именем, например Schema.msc. Система сохранит файл в персональном профиле пользователя. Если консоль должна быть доступна и другим администраторам, сохраните ее в каталоге \Windows\System32.
Раскрыв дерево Active Directory Schema, вы получаете доступ к объектам, которые составляют классы и атрибуты схемы. Для просмотра свойств объекта следует дважды щелкнуть на нем кнопкой мыши. На рис. 6.16 показан пример окна свойств атрибута SamAccountName, который используется для хранения регистрационного имени пользователя.
Существует список флагов, которые оказывают влияние на использование атрибута в Active Directory.
Allow this attribute to be shown in advanced view (Показывать атрибут при расширенном просмотре). На каждой консоли Active Directory содержится кнопка Advanced View (Дополнительные функции). Это позволяет не отображать на интерфейсе редко используемые элементы управления. Иногда такой метод запутывает администраторов, которые хотят выполнить операцию и не знают, что команда скрыта в нормальном режиме работы консоли. Это называется возможность (feature).
Attribute is active (Атрибут активен). Некоторые атрибуты не являются обязательными для работы системы и могут быть отключены, чтобы предотвратить присвоение им значений.
JUJSJUJSмоеюмоеюрАм^одйЛнм». р1вёмзяёлл5ГрАм^одйЛнм». р1вёмзяёлл5Грл- rlрл- rl
JUJS
JUJS
моею
моею
рАм^одйЛнм». р1вёмзяёлл5Г
рАм^одйЛнм». р1вёмзяёлл5Г
рл- rl
рл- rl
*<*
Рис. 6.16. Окно свойств объекта attribute Schema, которое используется для создания атрибута SamAccountName
11ЯЯIndex this attribute hi Active Directory (Индексировать этот атрибут в Active Directory). В любой базе данных производительность повышается при поиске по индексированному атрибуту. Но индексирование требует пространства на диске и временных затрат. Кроме этого, атрибут должен иметь уникальное значение, чтобы индекс имел какой-то смысл. • Индексация включается только для самых часто используемых атрибутов.
1
1
Я
Я
Ambiguous Name Resolution (ANR) (Допускать применение неоднозначных имен ANR). ] При использовании неоднозначных имен допускается поиск по частичному совпадению. | То есть при поиске по аргументу SamAccountName с критерием “gh” будут предоставле- | ны результаты “ghawn”, “ghaskell”, "ghowell” и т.д. Поиск с возможностью указания 1 неоднозначных имен приводит к повышенной нагрузке на механизм управления базой | данных, поэтому по умолчанию только девять атрибутов поддерживают такой поиск. Если 1 создано приложение с атрибутом, при наличии которого будет эффективным поиск с при- ] менением неоднозначных имен, этот флажок можно установить для добавления атрибута 1 в список атрибутов, поддерживающих использование неоднозначных имен.I
Replicate this attribute to the Global Catalog (Реплицировать этот атрибут в глобальный | каталог). Этот параметр позволяет добавлять атрибут в глобальный каталог. Добавление 1 в глобальный каталог обоснованно только для тех атрибутов, которые часто фигурируют в 1 поисковых запросах. Это позволяет минимизировать размер глобального каталога и со- 1 кратить нагрузку в процессе репликации. В операционной системе Windows 2000 добав- 1 ление атрибута в глобальный каталог или его удаление требовало полной перестройки и ] репликации глобального каталога. Потенциально это могло привести к увеличению объе- Я ма передаваемых по сети данных. Операционная система Windows Server 2003 допускает I изменение содержимого глобального каталога без полной перестройки.я
Attribute is copied when duplicating a user (Копировать атрибут при дублировании учет- Я ной записи). После установки этого флажка значение атрибута будет переноситься в но- Я вый объект User с помощью функции Сору. Значение атрибута SamAccountName долж- Я
но быть уникальным в пределах домена, поэтому для этого атрибута данный параметр недоступен.
■ Index this attribute for containerized searches in the Active Directory (Индексировать атрибут для поиска в контейнерах Active Directory). Процедуры поиска, предоставленные в составе API протокола LDAP и в составе интерфейса служб Active Directory, позволяют выполнять поиск в контейнере вместо поиска по всему каталогу. Можно установить этот флажок для ускорения поиска внутри контейнеров.
Схема может модифицироваться только на одном контроллере домена, который выбран на роль Schema Operations Master (Хозяин схемы). Это позволяет обеспечить целостность схемы, предотвращая внесение конфликтующих изменений на двух контроллерах домена в течение одного интервала репликации.
Чтобы назначить роль Schema Operations Master необходимо щелкнуть правой кнопкой мыши на пункте Active Directory Schema и выбрать из контекстного меню пункт Operations Master (Хозяин операций).
Для просмотра и модификации схемы не обязательно находиться за консолью контроллера Schema Operations Master (Хозяин схемы). К Operations Master можно подключиться из консоли Active Directory Schema, щелкнув правой кнопкой мыши на Active Directory Schema и выбрав пункт Change Domain Controller (Изменить контроллер домена).
Флаги поиска
Несколько параметров свойств атрибутов, указанных в окне диспетчера схемы, управляют записью SearchFlags. Эта запись управляет следующими действиями (значения могут объединяться друг с другом).
— индексировать этот атрибут
— индексировать этот атрибут и его контейнер
— добавить в перечень ANR (должен поддерживать индексацию)
— сохранить атрибут при удалении объекта и создании отметки на удаление
— скопировать значение атрибута при создании новой копии объекта
Из этих значений только параметр “8” не контролируется из оснастки Active Directory Schema. Для изменения этого значения можно воспользоваться консолью ADSI Edit (рассматривается в следующем разделе).
Требования к системному реестру для модификации схемы
В операционной системе Windows 2000 существовал механизм безопасности, который требовал установки параметра Schema updated Allowed в системном реестре компьютера, на котором запускалась консоль Active Directory Schema. В операционной системе Windows Server 2003 этот механизм отключен.
Для внесения изменений в любую часть схемы пользователь должен входить в группу Schema Admins. Учетная запись Administrator по умолчанию входит в эту группу. Группе Schema Admins предоставлен набор специальных разрешений на доступ к контейнеру Schema.
Смена контроллера Schema Master
Управление топологией репликации
Реплицирование изменений в каталоге
Синхронизация репликации
Обновление кэша схемы
Не стоит вносить изменения в схему, если нет полной уверенности в понимании ее структуры и желаемой цели. Новые объекты схемы невозможно удалить. Изменения существующих объектов могут привести к проблемам, требующим переустановки Active Directory или восстановления из резервной копии.
Утилиты Active Directory общего назначения
Стандартные консоли управления Active Directory предоставляют богатый интерфейс для модификации объектов и атрибутов Active Directory и доступа к ним. Кроме этого, консоли управления скрывают множество механизмов, которые обеспечивают работу Active Directory.
Теперь перейдем к рассмотрению утилит, которые позволяют заглянуть за красивый фасад консолей управления Active Directory. Добро пожаловать в реальный мир Active Directory! Но сначала ответим на один вопрос:
“Какую таблетку вы выбираете — красную или синюю?”
ADSI Edit
Первый набор утилит общего назначения предоставляется в составе Support Tools на установочном компакт-диске Windows Server 2003. Установите утилиты поддержки, дважды щелкнув на пиктограмме \Support\Tools\2000RKST.MSI и ответив на все вопросы мастера установки. ■
После установки утилит откройте окно Run (Выполнить) и введите команду adsiedit. msc. Это имя файла, в котором содержится консоль ADSI Edit. После открытия консоли ADSI Edit становятся доступными три пиктограммы, которые соответствуют трем стандартным контекстам именования на контроллере домена: Domain, Configuration и Schema (контекст именования приложений не отображается). Пример консоли показан на рис. 6.17.
4* Mint Wew W«*» H*Ф> •» E)i®'X tFQig.iS.4* Mint Wew W«*» H*Ф> •» E)i®'X tFQig.iS.В ^ Domain [serverLcompany.com] : В О DC-company,DC-com& Q CN-Buitin■@ О CN-Computers® О OU—Domain ControlersE О CN-ForeignSecurityPrincipeis% CJ CN-LostAndFoundE О CN-System■ST Ц Configuration [serverl.cornpany.com]В CJ CN-Configuration, DC -company, DC -com E Q CN-DisplaySpedfiers ® CJ CN-Extended-Rights; r*l D CN-ForestUpdates ffl О CN—LostAndFoundConfig $ LJ CN-Partittons•® О CN-Physical Locations1% D CN-Services№ Q CN-Sites.£ О CN-WeKnown Security Principalsa Schema[serverl.cornpany.com]i~J CN-Schema,CN—Configuration,DC-companyВ ^ Domain [serverLcompany.com] : В О DC-company,DC-com& Q CN-Buitin■@ О CN-Computers® О OU—Domain ControlersE О CN-ForeignSecurityPrincipeis% CJ CN-LostAndFoundE О CN-System■ST Ц Configuration [serverl.cornpany.com]В CJ CN-Configuration, DC -company, DC -com E Q CN-DisplaySpedfiers ® CJ CN-Extended-Rights; r*l D CN-ForestUpdates ffl О CN—LostAndFoundConfig $ LJ CN-Partittons•® О CN-Physical Locations1% D CN-Services№ Q CN-Sites.£ О CN-WeKnown Security Principalsa Schema[serverl.cornpany.com]i~J CN-Schema,CN—Configuration,DC-company—r :■■-I•—ICN-Admnstrator £1CN-8RANCH$ CiCN-Cert Publshers D CN-DHCP Administrators L3 CN-DHCP Users G.J C№"DnsAdmin$ Q) CN-DnsUpdateProxyCN-Domain Admins f23CN-Domain Computers Cj CN-Domain Controlers LJ CNH)omain Guests <2J CN-Domah Users c-J CN—Enterprise Admins U CN-Group Poky Creator Own.., uJcN-Guest LJ CN-HeipAssi$tant_Of579e 2J CN—HetpServicesGroup LjCN-krbtgt lJcn-RAS and IAS Servers Lj CN-Schema Admins S3 CN—SUBSIDIARY^ S3CN-5UPPORT_388945aO □cN-#lta Users—r :■■-I•—ICN-Admnstrator £1CN-8RANCH$ CiCN-Cert Publshers D CN-DHCP Administrators L3 CN-DHCP Users G.J C№"DnsAdmin$ Q) CN-DnsUpdateProxyCN-Domain Admins f23CN-Domain Computers Cj CN-Domain Controlers LJ CNH)omain Guests <2J CN-Domah Users c-J CN—Enterprise Admins U CN-Group Poky Creator Own.., uJcN-Guest LJ CN-HeipAssi$tant_Of579e 2J CN—HetpServicesGroup LjCN-krbtgt lJcn-RAS and IAS Servers Lj CN-Schema Admins S3 CN—SUBSIDIARY^ S3CN-5UPPORT_388945aO □cN-#lta UsersJsmlZgroup group groupgroup •group group group group group■ groupgroupgroup groupJsmlZgroup group groupgroup •group group group group group■ groupgroupgroup groupCN-Administrator,CN—Users.DC-compan CN-BRANCH$, CN-Users, DC-company, О OMCert Publshers,ChMJ$ers,DC-compa CN-DHCP Administrators,ChMJsers,DC-c CN-DHCP Users,CN-Users,DC-company, CN—DnsAdmins,CN-Users,DC-company,[ CN-DnsUpdateProxy,CN-Users,DC-come CN-Domain Admins,CN-Users,DC-compa CN-Domain Computers.CN—Users,DC-cot CN-Domain Controlers,CN-Users,DC-c» CN-Domain Guests, CN-Users,DC-compa CNH)omain Users, CN-Users, DC-compan ■ CN-Enterprise Admins, CN-Users, DC-con CN-Group Poky Creator Owners, CN-Use CN-Guest,CN-Users,DC-cornpany,DC-c . CN-HeipAs$l$tant_0f579e,CN-Users,DC" CN-HelpServicesGroup, CN-Users, DC-cot CN-tatigt,CN-Users,DC-company,DC-c . CN—RAS and IAS Servers,CN-Users,DC-» ' CN-Schema Admins, CN-Users, DC -compt CN-SLBSIDIARY$,CN-Users,DC-compare CN-5UPPORT_388945aO,CN-Users,DC-сВч CN-WINSUsers. CN-Users.DC-сотоапу-ЗCN-Administrator,CN—Users.DC-compan CN-BRANCH$, CN-Users, DC-company, О OMCert Publshers,ChMJ$ers,DC-compa CN-DHCP Administrators,ChMJsers,DC-c CN-DHCP Users,CN-Users,DC-company, CN—DnsAdmins,CN-Users,DC-company,[ CN-DnsUpdateProxy,CN-Users,DC-come CN-Domain Admins,CN-Users,DC-compa CN-Domain Computers.CN—Users,DC-cot CN-Domain Controlers,CN-Users,DC-c» CN-Domain Guests, CN-Users,DC-compa CNH)omain Users, CN-Users, DC-compan ■ CN-Enterprise Admins, CN-Users, DC-con CN-Group Poky Creator Owners, CN-Use CN-Guest,CN-Users,DC-cornpany,DC-c . CN-HeipAs$l$tant_0f579e,CN-Users,DC" CN-HelpServicesGroup, CN-Users, DC-cot CN-tatigt,CN-Users,DC-company,DC-c . CN—RAS and IAS Servers,CN-Users,DC-» ' CN-Schema Admins, CN-Users, DC -compt CN-SLBSIDIARY$,CN-Users,DC-compare CN-5UPPORT_388945aO,CN-Users,DC-сВч CN-WINSUsers. CN-Users.DC-сотоапу-З
4* Mint Wew W«*» H*Ф> •» E)i®'X tFQig.iS.
4* Mint Wew W«*» H*Ф> •» E)i®'X tFQig.iS.
В ^ Domain [serverLcompany.com] : В О DC-company,DC-com
& Q CN-Buitin■
@ О CN-Computers
® О OU—Domain Controlers
E О CN-ForeignSecurityPrincipeis
% CJ CN-LostAndFound
E О CN-System■
ST Ц Configuration [serverl.cornpany.com]
В CJ CN-Configuration, DC -company, DC -com E Q CN-DisplaySpedfiers ® CJ CN-Extended-Rights
; r*l D CN-ForestUpdates ffl О CN—LostAndFoundConfig $ LJ CN-Partittons
•® О CN-Physical Locations
1% D CN-Services
№ Q CN-Sites.
£ О CN-WeKnown Security Principalsa Schema[serverl.cornpany.com]i
~J CN-Schema,CN—Configuration,DC-company
В ^ Domain [serverLcompany.com] : В О DC-company,DC-com
& Q CN-Buitin■
@ О CN-Computers
® О OU—Domain Controlers
E О CN-ForeignSecurityPrincipeis
% CJ CN-LostAndFound
E О CN-System■
ST Ц Configuration [serverl.cornpany.com]
В CJ CN-Configuration, DC -company, DC -com E Q CN-DisplaySpedfiers ® CJ CN-Extended-Rights
; r*l D CN-ForestUpdates ffl О CN—LostAndFoundConfig $ LJ CN-Partittons
•® О CN-Physical Locations
1% D CN-Services
№ Q CN-Sites.
£ О CN-WeKnown Security Principalsa Schema[serverl.cornpany.com]i
~J CN-Schema,CN—Configuration,DC-company
—r :■■-I
•—ICN-Admnstrator £1CN-8RANCH$ CiCN-Cert Publshers D CN-DHCP Administrators L3 CN-DHCP Users G.J C№"DnsAdmin$ Q) CN-DnsUpdateProxy
CN-Domain Admins f23CN-Domain Computers Cj CN-Domain Controlers LJ CNH)omain Guests <2J CN-Domah Users c-J CN—Enterprise Admins U CN-Group Poky Creator Own.., uJcN-Guest LJ CN-HeipAssi$tant_Of579e 2J CN—HetpServicesGroup LjCN-krbtgt lJcn-RAS and IAS Servers Lj CN-Schema Admins S3 CN—SUBSIDIARY^ S3CN-5UPPORT_388945aO □cN-#lta Users
—r :■■-I
•—ICN-Admnstrator £1CN-8RANCH$ CiCN-Cert Publshers D CN-DHCP Administrators L3 CN-DHCP Users G.J C№"DnsAdmin$ Q) CN-DnsUpdateProxy
CN-Domain Admins f23CN-Domain Computers Cj CN-Domain Controlers LJ CNH)omain Guests <2J CN-Domah Users c-J CN—Enterprise Admins U CN-Group Poky Creator Own.., uJcN-Guest LJ CN-HeipAssi$tant_Of579e 2J CN—HetpServicesGroup LjCN-krbtgt lJcn-RAS and IAS Servers Lj CN-Schema Admins S3 CN—SUBSIDIARY^ S3CN-5UPPORT_388945aO □cN-#lta Users
JsmlZ
group group group
group •group group group group group
■ group
group
group group
JsmlZ
group group group
group •group group group group group
■ group
group
group group
CN-Administrator,CN—Users.DC-compan CN-BRANCH$, CN-Users, DC-company, О OMCert Publshers,ChMJ$ers,DC-compa CN-DHCP Administrators,ChMJsers,DC-c CN-DHCP Users,CN-Users,DC-company, CN—DnsAdmins,CN-Users,DC-company,[ CN-DnsUpdateProxy,CN-Users,DC-come CN-Domain Admins,CN-Users,DC-compa CN-Domain Computers.CN—Users,DC-cot CN-Domain Controlers,CN-Users,DC-c» CN-Domain Guests, CN-Users,DC-compa CNH)omain Users, CN-Users, DC-compan ■ CN-Enterprise Admins, CN-Users, DC-con CN-Group Poky Creator Owners, CN-Use CN-Guest,CN-Users,DC-cornpany,DC-c . CN-HeipAs$l$tant_0f579e,CN-Users,DC" CN-HelpServicesGroup, CN-Users, DC-cot CN-tatigt,CN-Users,DC-company,DC-c . CN—RAS and IAS Servers,CN-Users,DC-» ' CN-Schema Admins, CN-Users, DC -compt CN-SLBSIDIARY$,CN-Users,DC-compare CN-5UPPORT_388945aO,CN-Users,DC-сВч CN-WINSUsers. CN-Users.DC-сотоапу-З
CN-Administrator,CN—Users.DC-compan CN-BRANCH$, CN-Users, DC-company, О OMCert Publshers,ChMJ$ers,DC-compa CN-DHCP Administrators,ChMJsers,DC-c CN-DHCP Users,CN-Users,DC-company, CN—DnsAdmins,CN-Users,DC-company,[ CN-DnsUpdateProxy,CN-Users,DC-come CN-Domain Admins,CN-Users,DC-compa CN-Domain Computers.CN—Users,DC-cot CN-Domain Controlers,CN-Users,DC-c» CN-Domain Guests, CN-Users,DC-compa CNH)omain Users, CN-Users, DC-compan ■ CN-Enterprise Admins, CN-Users, DC-con CN-Group Poky Creator Owners, CN-Use CN-Guest,CN-Users,DC-cornpany,DC-c . CN-HeipAs$l$tant_0f579e,CN-Users,DC" CN-HelpServicesGroup, CN-Users, DC-cot CN-tatigt,CN-Users,DC-company,DC-c . CN—RAS and IAS Servers,CN-Users,DC-» ' CN-Schema Admins, CN-Users, DC -compt CN-SLBSIDIARY$,CN-Users,DC-compare CN-5UPPORT_388945aO,CN-Users,DC-сВч CN-WINSUsers. CN-Users.DC-сотоапу-З
I tf '-7
Puc. 6.17. На консоли ADSI Edit отображаются три стандартных контекста именования на контроллере домена
Выбор альтернативного контроллера домена для ADSI Edit
Если после запуска консоли ADSI Edit нет доступа к контекстам именования или необходимо просмотреть контексты именования на другом контроллере домена, выполните следующие действия.
Щелкните правой кнопкой мыши на пиктограмме ADSI Edit и выберите из контекстного меню команду Connect То (Подключиться к). Откроется окно Connection (Подключение).
В группе Computer (Компьютер) выберите переключатель Select or Type a Domain or Server (Выберите или введите имя домена или сервера).
Введите полностью определенное DNS-имя контроллера домена в комбинированном поле. После ввода имени автоматически изменится значение поля Path (Путь).
Щелкните на кнопке Advanced (Дополнительно). Откроется окно Advanced (Дополнительно), которое показано на рис. 6.18.
В этом окне доступны следующее параметры.
Credentials (Аутентификационные данные). Если необходимо подключиться к базе данных Active Directory в другом домене или пользователь вошел в систему без прав системного адмиинистратора, здесь можно указать аутентификационные данные учетной записи администратора.
Port Number (Номер порта). Если это поле оставить пустым, то ADSI Edit для отправки запросов LDAP будет использовать ТСР-порт 389. Если необходимо установить связь с нестандартной реализацией системы, в этом поле можно указать другой порт. Также это поле можно использовать для просмотра глобального каталога через ТСР-порт 3268, но удобнее использовать для этого параметр Protocol (Протокол).
Protocol (Протокол). Выберите, что вы хотите просматривать: Active Directory (порт 389) или Global Catalog (порт 3268).
Щелкните на кнопке ОК, чтобы сохранить внесенные изменения и вернуться в окно Connections (Подключения).
Чтобы сохранить внесенные изменения и вернуться на консоль ADSI Edit, еще раз щелкните на кнопке ОК. Содержимое консоли обновится, и будут показаны новые значения.
Рис. 6.18. Окно консоли ADSI Edit Advanced (Дополнительно), в котором можно указать альтернативные аутентификационные данные, номер порта и используемый протокол
Л1Л1Л1Л1AtrtwteEcfaf |sec«^|■17 fShowsHndatc® afcfcui*| P ShowsptiondaertxXm Г Shewa* aH*Uw№efchwex*Bt AttfateeAtrtwteEcfaf |sec«^|■17 fShowsHndatc® afcfcui*| P ShowsptiondaertxXm Г Shewa* aH*Uw№efchwex*Bt AttfateeAbb*Abb*accountExpies accountNameHistOfy eCSPofcyName adminCount a*ninD escription a*nirOispiqyName afowedAttributes alowedAttributesEffe... aiowedChildClasses alowedCMdClassesE . akSecuritjrfdentUes assistant atinbuteCertificateAttri..accountExpies accountNameHistOfy eCSPofcyName adminCount a*ninD escription a*nirOispiqyName afowedAttributes alowedAttributesEffe... aiowedChildClasses alowedCMdClassesE . akSecuritjrfdentUes assistant atinbuteCertificateAttri..I St**Lege Integer/...Unicode String Unicode StringUnicode String Unicode String Object Identifier Object Identifier Object Identifier . Object IdentifierUnicode StringDistinguished... . Octet StrinaI St**Lege Integer/...Unicode String Unicode StringUnicode String Unicode String Object Identifier Object Identifier Object Identifier . Object IdentifierUnicode StringDistinguished... . Octet Strinajv*ue "9223372036054775807<NotSet><NotSebjv*ue "9223372036054775807<NotSet><NotSeb<Not Seb ■<Not SeblabetedU RI ;$ubSchemaSt msDS-Cached-M embersh nJ FR S S ubscriptions;cl8$: nT FR S S ib$crptions;clas:<Not Seb <Not Seb <Not Seb<Not Seb ■<Not SeblabetedU RI ;$ubSchemaSt msDS-Cached-M embersh nJ FR S S ubscriptions;cl8$: nT FR S S ib$crptions;clas:<Not Seb <Not Seb <Not Seb
Л1Л1
Л1Л1
AtrtwteEcfaf |sec«^|■
17 fShowsHndatc® afcfcui*| P ShowsptiondaertxXm Г Shewa* aH*Uw№efchwex*Bt Attfatee
AtrtwteEcfaf |sec«^|■
17 fShowsHndatc® afcfcui*| P ShowsptiondaertxXm Г Shewa* aH*Uw№efchwex*Bt Attfatee
Abb*
Abb*
accountExpies accountNameHistOfy eCSPofcyName adminCount a*ninD escription a*nirOispiqyName afowedAttributes alowedAttributesEffe... aiowedChildClasses alowedCMdClassesE . akSecuritjrfdentUes assistant atinbuteCertificateAttri..
accountExpies accountNameHistOfy eCSPofcyName adminCount a*ninD escription a*nirOispiqyName afowedAttributes alowedAttributesEffe... aiowedChildClasses alowedCMdClassesE . akSecuritjrfdentUes assistant atinbuteCertificateAttri..
I St**
Lege Integer/...
Unicode String Unicode String
Unicode String Unicode String Object Identifier Object Identifier Object Identifier . Object Identifier
Unicode String
Distinguished... . Octet Strina
I St**
Lege Integer/...
Unicode String Unicode String
Unicode String Unicode String Object Identifier Object Identifier Object Identifier . Object Identifier
Unicode String
Distinguished... . Octet Strina
jv*ue "
9223372036054775807
<NotSet>
<NotSeb
jv*ue "
9223372036054775807
<NotSet>
<NotSeb
<Not Seb ■
<Not Seb
labetedU RI ;$ubSchemaSt msDS-Cached-M embersh nJ FR S S ubscriptions;cl8$: nT FR S S ib$crptions;clas:
<Not Seb <Not Seb <Not Seb
<Not Seb ■
<Not Seb
labetedU RI ;$ubSchemaSt msDS-Cached-M embersh nJ FR S S ubscriptions;cl8$: nT FR S S ib$crptions;clas:
<Not Seb <Not Seb <Not Seb
Использование ADSI Edit для просмотра и модификации объектов Active Directory
Просмотр и изменение объектов Active Directory рассматриваются в процедуре 6.2.
Процедура 6.2. Использование ADSI Editor для просмотра и модификации объектов Active Directory
Раскройте дерево, чтобы открылась вершина контекста именования, который необходимо просмотреть. Одновременно можно открыть несколько контекстов именования Domain для разных контроллеров домена. Эта возможность делает ADSI Editor удобным инструментом для просмотра объектов на большом предприятии.
Существует возможность просмотра атрибутов любого объекта в любом контексте именования. Например, раскройте дерево Domain, в котором будет показан список объектов в контейнере cn=Users. Щелкните правой кнопкой мыши на cn=Administrator и выберите пункт Properties (Свойства) из контекстного меню. Откроется окно Properties ( Свойства), показанное на рис. 6.19.
I L'N ‘-Administrator Properties
Puc. 6.19. Свойства объекта с характерным именем cn=Administrator,cn=Users, dc= Company,dc=com '
По умолчанию установлены флажки Show Mandatory Attributes (Показывать обязательные атрибуты) и Show Optional Attributes (Показывать необязательные атрибуты). Для сокращения объема предоставляемой в данном окне информации установите флажок Show Only Attributes That Have Values (Показывать только атрибуты с установленным значением).
Перейдите по списку вниз, чтобы просмотреть различные атрибуты и их значения.
Для изменения значения атрибута дважды щелкните на атрибуте. Будет запущен подходящий редактор для изменения значения атрибута.
ADSI Edit можно рассматривать как расширенную версию редактора Regedit для базы данных Active Directory. Все ограничения редактора системного реестра справедливы и для
редактора базы данных Active Directory. Несколько щелчков мышью могут превратить отлично настроенный домен в развалину. В то же время небольшие изменения способны решить проблемы, которые казались неустранимыми.
Браузер LDAP
Оснастка ADSI Edit предназначена исключительно для управления контекстами именования Active Directory. В набор Support Tools включена утилита, позволяющая работать с любой службой каталогов, соответствующей документам RFC, которые описывают протокол LDAP. Эта утилита является выполняемым файлом, а не оснасткой ММС. Утилита называется LDAP Browser или Idp. exe.
LDP немного сложнее в использовании, чем ADSI Edit, и требует более глубоких знаний архитектуры LDAP. Но изучение этой технологии обычно оправдывает себя, a LDP предоставляет намного больше информации, чем ADSI Edit, при меньших затратах времени. Кроме этого, некоторые операции LDAP скрыты от ADSI Edit, но доступны с помощью LDP.
Установка LDP
Перед использованием LDP придется выполнить несколько операций по привязке (аутентификации) и настройке просмотра дерева каталога. Необходимая последовательность действий приводится в процедуре 6.3.
Процедура 6.3. Установление привязки с помощью LDP
На клиентском компьютере в пределах домена откройте окно Run (Выполнить) и введите LDP.
В открывшемся окне выберите Connection^Bind (Подключение^Привязка). Откроется окно Bind (Привязка).
Введите аутентификационные данные учетной записи администратора для домена или леса.
Щелкните на кнопке ОК. В правой панели будут открыты атрибуты объекта RootDSE. Эти атрибуты описывают структуру и содержимое каталога, расположенного на сервере. LDP осуществит привязку к текущему регистрационному серверу. Для выбора другого сервера можно воспользоваться командой Connect (Подключение).
В меню View (Вид) выберите команду Tree (Дерево). Откроется окно Tree View (Представление дерева).
В поле BaseDN введите характерное имя контейнера, который необходимо просмотреть. Например, можно ввести dc=Company,dc=com и начать просмотр с самого верха контекста именования Domain домена Company. Также можно указать контейнер на нижних уровнях дерева Active Directory. Например, можно выбрать контейнер Users, указав характерное имя cn=Users,dc=Company,dc=com. Интерфейс утилиты не чувствителен к регистру вводимых символов.
Щелкните на кнопке ОК. В левой панели окна будет показан корень контейнера, характерное имя которого было введено в предыдущем шаге. Щелкните на символе “плюс" (+) или дважды щелкните на имени контейнера, чтобы раскрыть дерево. Это приведет к генерации запроса LDAP, предназначенного для выполнения инвентаризации дочерних объектов контейнера. Объекты будут перечислены в дереве на левой панели. Кроме этого, генерируется запрос на получение атрибутов объекта домена. Эти атрибуты отображаются на правой панели (рис. 6.20).
Рис. 6.20. В окне LDP отображается дерево домена Company. сот
Поиск конкретного атрибута
LDP является удобным средством для поиска конкретных экземпляров атрибута в каталоге (процедура 6.4).
Процедура 6.4. Поиск средствами утилиты LDP
Выберите команду В rowset Search (Просмотри Поиск) из основного меню. Откроется окно поиска.
В поле Base DN введите характерное имя контейнера, в котором необходимо выполнить поиск. Если нужно выполнить поиск по всему дереву, можно ввести характерное имя корневого домена. На большом предприятии с несколькими дочерними доменами поиск требует значительного времени.
Введите критерий поиска в поле Filter (Фильтр). В данном случае используется достаточно сложный синтаксис команды. Протокол LDAP предполагает использование бинарных операторов & (И) и I (ИЛИ) в префиксной форме (перед строкой поиска). Например, для поиска всех пользователей (Users), которые входят в отделение Finance, необходимо использовать критерий поиска (&(objectclass=user) (department=finance) ). Регистр символов не учитывается.
Если необходимо найти только объекты с введенным характерным именем, выберите Base (Базовая). Если необходимо найти базовые объекты и все объекты непосредственно под ними, выберите One Level (Один уровень). Если необходимо выполнить поиск во всех контейнерах, расположенных в базовом контейнере, выберите Subtree (Поддерево). LDP не поддерживает поиск в пределах всего леса. Для этого придется отправить несколько запросов на поиск, каждый раз вводя характерное имя интересующего дерева.
Универсальные символы в запросах LDP
LDP разрешает использовать универсальные символы только внутри и в конце запроса на поиск. Можно выполнить поиск по критерию department=fin* или department=fin*ce, но не по критерию department=*ance.
LDP позволяет выполнить множество операций. С помощью этой утилиты можно быстро увидеть дескриптор безопасности объекта. Можно просмотреть метаданные репликации, связанные со всеми свойствами объекта (эта тема будет рассматриваться более подробно в главе?, “Управление репликацией Active Directory”). Желательно научиться использовать все возможности утилиты LDP. Одновременно вы ознакомитесь со многими особенностями протокола LDAP и службы каталогов Active Directory. Вы не пожалеете, что выбрали красную таблетку.
Утилита dcdiag
Эта утилита входит состав Resource Kit. Утилита dcdiag незаменима при контроле и диагностике различных операций Active Directory. Результат тестирования предоставляет достаточный объем информации о текущем состоянии доменов, доверительных отношений и репликаций Active Directory. Введите команду dcdiag /? для получения перечня доступных тестов. Тестируется каждый компонент Active Directory. Лучше Научиться использовать эту утилиту.
Утилиты ds
В операционной системе Windows Server 2003 предрставляются дополнительные утилиты, запускаемые из командной строки, предназначенные для администрирования Active Directory. Эти утилиты имеют общее название ds. Вот список доступных утилит.
dsadd. Создает объект указанного класса. Одновременно позволяет присваивать значения большому количеству атрибутов. Например, ниже перечислены доступные атрибуты для команды dsadd user.
dsadd user <ijserDN> [-samid <SAMName>] [-upn <UPN>] [-fn <FirstName>]
, [-mi <Initial>] [-In <LastName>] [-display <DisplayName>]
' [-empid <EmployeeID>] [-pwd (<Password> I *}] [-desc <Description>]
’ [-memberof <Group ...>] [-office <Office>] [-tel <Phone#>]
[-email <Email>] [-hometel <HomePhone#>] [-pager <Pager#>] [-mobile <CellPhone#>] [-fax <Fax#>] [-iptel <IPPhone#>] [-webpg <WebPage>] [-title <Title>] [-dept <Department>] [-company <Company>] [-mgr <Manager>] [-hmdir <HomeDir>] [-hmdrv <DriveLtr:>] [-profile <ProfilePath>] [-loser <ScriptPath>] [-mustchpwd [yes I no}] [-canchpwd [yes I no}]
[-reversiblepwd [yes I no}] [-pwdneverexpires [yes I no}] [-acctexpires <NumDays>] [-disabled [yes I no}] [{-s <Server> I -d <Domain>}] [-u <UserName>]
[-p (<Password> I *}] [-q] [{-uc I -uco I -uci}]
dsznod. Позволяет изменить указанные атрибуты существующего объекта.
dsrm. Предназначена для удаления объекта или контейнера. Осторожно пользуйтесь этой утилитой. С ее помощью можно случайно удалить целую ветвь дерева, которую придется восстанавливать из резервной копии.
dsmove. Перемещает объект в новый контейнер. Контейнер должен входить в тот же контекст именования.
dsquery. Находит объекты, удовлетворяющие определенному критерию поиска.
dsget. Показывает значения свойств указанного объекта.
Импорт и экспорт больших объемов данных
Иногда возникает необходимость экспорта информации из базы данных Active Directory в текстовый файл, в котором можно выполнять поиск. Иногда приходится создавать большое количество объектов, при этом для упрощения задачи информацию удобнее импортировать из текстового файла. Стандартный контроллер домена под управлением Windows предоставляет администратору несколько утилит, которые предназначены для массовой обработки объектов. Сначала рассмотрим формат обмена информацией LDAP.
LDAP Data Interchange Format (LDIF)
В документе RFC 2849, “The LDAP Data Interchange Format (LDIF) — Technical Specification”, определена стандартная структура для обмена информацией LDAP. В следующем примере показан формат LDIF для атрибутов учетной записи Administrator в домене Company. com.
dn: CN=Administrator,CN=Users,DC=company,DC=com
memberOf: CN=Group Policy Admins,CN=Users,DC=company,DC=com memberOf: CN=Enterprise Admins,CN=Users,DC=company,DC=com memberOf: CN=Schema Admins,CN=Users,DC=company,DC=com memberOf: CN=Administrators,CN=Builtin,DC=company,DC=com memberOf: CN=Domain Admins,CN=Users,DC=company,DC=com accountExpires: 9223372036854775807 adminCount: 1 badPasswordTime: 125693193676075896 badPwdCount: 0 codePage: 0 cn: Administrator countrycode: 0
description: Built-in account for administering the computer/domain isCriticalSystemObject: TRUE lastLogoff: 0
lastLogon: 125693891796993128
logonCount: 109
distinguishedName: CN=Administrator,CN=Users,DC=company,DC=com
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=company,DC=com objectclass: user
objectGUID:: gLgtb/juOhGcKADATlNqTQ==
objectSid:: AQUAAAAAAAUVAAAAoF4uDLI/DAf7Cwgn9AEAAA== primaryGroupID: 513
pwdLastSet: 125681556744344992 name: Administrator
sAMAccountName: Administrator
sAMAccountType: 805306368
userAccountControl: 66048
uSNChanged: 1532
uSNCreated: 1410
whenChanged: 19990410040835.0Z
whenCreated: 19990410034956.0Z
В данном случае стоит обратить внимание на несколько моментов.
В файлах LDIF используются символы из таблицы ASCII. Если некоторые атрибуты имеют значение в кодировке Unicode, то при преобразовании значения могут не сохраниться.
Длинные целые числа, которые используются для записи времени и даты, будут представлены в десятичном формате и также не сохранятся при преобразовании. Эти атрибуты удаляются и создаются заново при импорте данных и создании новых объектов.
Строки октетов преобразовываются в формат Base64. На это указывает двойное двоеточие после названия атрибута. Примером такого атрибута является ObjectGUlD. Подобные значения сохраняются при преобразовании. Но в большинстве случаев такой синтаксис используется для уникальных значений, поэтому после импорта значение будет проигнорировано.
Атрибуты соответствуют схеме Active Directory того леса, из которого были экспортированы объекты. Попытка импортировать объекты в другую службу каталогов приведет к проблемам совместимости. Как минимум придется менять характерные имена, поскольку вероятность использования такого же пространства имен в другой службе каталогов достаточно мала.
В стандарте LDIF определено несколько команд, которые используются для выполнения операций с конкретной записью. Команды позволяют добавлять, модифицировать, заменять или удалять целые объекты или отдельные атрибуты объектов. К тому же эти команды позволяют изменять схему службы каталогов. Active Directory поддерживает добавление и модификацию классов объектов и атрибутов средствами LDIF, но удаление классов и атрибутов не поддерживается. После добавления в схему службы каталогов класс или атрибут остается в схеме навсегда.
LDIF и изменение схемы Active Directory
Если вы считаете, что LDIF — это одна из тех программистских игрушек, которых разумный системный администратор должен всячески избегать, подумайте вот о чем: при модернизации первого контроллера домена Windows 2000 до Windows Server 2003 с целью поддержки изменений в новой операционной системе добавляются новые и модифицируются существующие объекты. Кроме этого, схема Active Directory должна быть модифицирована для поддержки новых возможностей операционной системы Windows Server 2003. Как Microsoft осуществляет все эти преобразования схемы? С помощью LDIF, вот как.
Перейдите в каталог \I386 на установочном компакт-диске операционной системы Windows Server 2003. Обратите внимание на файлы с расширением . Idf. В этих файлах содержатся записи LDIF, которые используются для модификации схемы и содержимого Active Directory. На компакт-диске находится несжатый выполняемый файл schupgr. ехе. Этот файл загружает изменения из файлов LDF непосредственно в базу данных Active Directory.
Стоит обратить внимание на еще одну возможность такого метода модернизации. Последней инструкцией в файле LDF является модификация атрибута Objectversion контейнера Schema. Именно так операционная система Windows отслеживает файлы LDF, которые устанавливаются при обновлении. Установка операционной системы Windows Server 2003 модернизирует схему до версии 30. Установка Exchange также приводит к модификации схемы, но при этом номер версии не меняется.
Утилита Idifde
На контроллере домена Windows автоматически устанавливается утилита для импорта и экспорта файлов LDIF. Утилита называется Idifde. Для получения списка доступных параметров запустите утилиту Idifde без параметров.
Утилита Idifde упрощает импорт и экспорт большого количества записей из базы данных Active Directory. Кроме этого, утилита оказывается полезной для просмотра записей службы каталогов без запуска оснастки ММС. Для перенаправления вывода на консоль воспользуйтесь параметром -f.
Чтобы добавить в состав группы определенного пользователя, воспользуйтесь командой
Idifde -d сп=имя_пользовател.я,cn=Users,dc=company,dc=com -f con.
Для проверки записей в доверенном домене воспользуйтесь командой Idifde -s alb- dc-01.office.company.com -d dc=Office,dc=company,dc=com -f con.
Чтобы найти все принтеры в подразделении, воспользуйтесь командой Idifde -d ou=Phoenix,dc=Company,dc=com -r "(objectclass=printers)" -f con.
Утилиту Idifde можно использовать для сохранения в файле информации о пользователе, модификации параметров и имени пользователя и импорта этого файла, в качестве источника данных для нового пользователя. Для этого воспользуйтесь параметром -т, чтобы удалить из дампа информацию, специфическую для базы данных SAM.
Кроме этого, утилиту Idifde можно использовать для изменения атрибутов существующих объектов, но для этого нужно знать одну особенность. После создания файла LDIF, в котором содержатся изменяемые записи, необходимо добавить дефис в первой пустой строке после всех записей и добавить пустую строку после дефиса. Рассмотрим пример модификации атрибута Description для пользователя Avguser.
dn: CN=avguser,OU=Phoenix,DC=Company,DC=com changetype: modify replace: Description Description: Wazula
Без завершающего символа дефиса будет выдано сообщение об ошибке, показанное ниже:
Failed on line 4. The last token starts with 'W. The change-modify entry is missing the terminator '-'.
Утилита csvde
Работа с форматом LDIF может стать немного утомительной, поскольку атрибуты сортируются по вертикали, а не по горизонтали. Если более предпочтительным является формат электронной таблицы, воспользуйтесь утилитой cvsde. Для утилиты cvsde доступны те же параметры, что и для 1 di f de.
Рассмотрим пример использования утилиты cvsde. Предположим, администратор школы должен добавить данные о 5000 учащихся в базу данных Active Directory. Список учащихся может храниться на мейнфрейме, в приложении AS400, в приложении UNIX той или иной формы или в базе данных SQL. Можно написать сценарий JCL (Job Control Language) или воспользоваться запросом SQL, который выдаст список в файл с разделением значений. После этого файл можно импортировать в электронную таблицу и изменить формат на пригодный для импорта в базу данных Active Directory (для просмотра названий заголовков и типов данных можно воспользоваться командой csvde -f output.Idf). После этого воспользуйтесь командой csvde - i для импорта содержимого электронной таблицы в базу данных Active Directory.
Повторный импорт дампов LDIF
Если выполняется экспорт с помощью утилиты Idifde или csvde, то многие атрибуты объектов пользователей и групп принадлежат системе и не могут быть импортированы обратно. Есть небольшой фокус для обхода этого ограничения. Выполняйте экспорт с использованием параметра -ш. Это включает SAM Logic и является одним из способов отключить экспорт атрибутов, которые принадлежат системе. При этом создается шаблон, который можно использовать для создания импортируемых файлов или электронных таблиц.
Другие утилиты для работы с LDAP
Поскольку служба Active Directory является соответствующей RFC реализацией службы каталогов LDAP, для просмотра объектов и сбора информации можно использовать практически все утилиты, предназначенные для работы с протоколом LDAP. Вот несколько ссылок на источники информации и утилит, связанных с протоколом LDAP.
OpenLDAP (www.openldap.org). Поклонники открытого исходного кода приложений могут обратить внимание на последние программы от этого сообщества. Это программы не для слабохарактерных. Здесь не предоставляются готовые скомпилированные приложения. Но если возникла необходимость заменить оснастки ММС собственными инструментами администрирования, обратите внимание на эти программы.
Novell (www.novell.com/products/nds/ldap.html). В операционной системе NetWare 5 используется протокол IP, как и служба каталогов NDS. Также обратите внимание на сайт developer.novell. com, где предоставляются утилиты для LDAP и Х.500, полезные в гетерогенных сетях.
ADAM (Active Directory Application Mode)
Реализованная в Windows Server 2003 R2 своеобразная технология работы с Active Directory под названием ADAM (Active Directory Application Mode — режим приложений Active Directory) предназначена для приложений, которые “знают" о существовании Active Directory (AD), данные в AD не хранят, но рассчитаны на использование преимуществ, предлагаемых AD в области безопасности и аутентификации.
Например, приложению требуется сохранить огромный объем информации, который не нужен остальным приложениям или который не следует реплицировать на каждый контроллер домена. ADAM использует отдельную базу данных, которая поддерживает многое из того, что есть в AD (схема, репликации, управление), но при этом полностью отделена от AD (т.е. не требует внесения изменений в схему). Такая независимость базы данных означает, что у вас может быть отдельная схема для каждой копии ADAM. Как и AD, ADAM использует интерфейс LDAP (Lightweight Directory Access Protocol), что позволяет LDAP- и AD- приложениям без ограничений использовать и ADAM.
ADAM является обычной прикладной программой, для развертывания которой не требуются ни домен, ни контроллер домена, ни даже сервер. Благодаря этому ADAM совершенно легко инсталлируется и деинсталлируется, запускается и останавливается на любом сервере под управлением Windows Server 2003 и Windows ХР. Кроме того, на одном и том же компьютере может одновременно выполняться сразу несколько экземпляров ADAM (при этом каждый из них должен быть настроен на использование уникального TCP-порта для доступа к нему). Администрирование ADAM также практически ничем не отличается от обслуживания обычной службы Active Directory, для чего применяется один и тот же набор утилит.
Теперь разработчики могут непосредственно на своих машинах поддерживать несколько каталогов с различными схемами, работающими к тому же совершенно изолированно друг от друга. Соответственно, и для развертывания готового приложения у заказчика не потребуется вмешательства в существующую информационную среду или задействования дорогостоящих серверов.
Безусловным плюсом технологии ADAM является простота программного доступа к каталогу, который обеспечивается тем же API, что используется при работе с глобальной службой Active Directory.
Более подробную информацию об использовании ADAM можно найти по адресу http://www.microsoft.com/windowsserver2003/adam/default.mspx. Там же находятся и все необходимые для загрузки и установки файлы.
ADFS
ADFS (Active Directory Federation Services — службы объединения Active Directory) — это новая технология Microsoft, использующая Web-сервисы, которые позволяют компаниям безопасно совершать транзакции с бизнес-партнерами, основываясь на Web. То есть возможности и ресурсы локальных Web-приложений можно предоставлять удаленным пользователям. Для этой цели, например, партнеры вашей организации могут использовать однократную регистрацию (Single Sign-On — SSO), которая используется в домене организации. В настоящее время ADFS работает только для Web-приложений. .
Чтобы разрешить клиентам доступ к ресурсам в вашем домене, необходимо обеспечить безопасность, и эта технология называется WS-Federation.
Для ADFS требуется, чтобы учетные записи пользователей хранились в Active Directory. Объединенные службы используют эти учетные записи для аутентификации. ADFS аутентифицирует пользователей с помощью Active Directory, и использует безопасность, которую создает Active Directory. ADFS также использует аутентификацию Windows. Установка ADFS позволяет безопасно расширить Active Directory для использования в Интернет.
При установке ADFS необходимо установить объединенный сервер, который будет контролировать доступ к вашей системе, основываясь на идентификации, аутентификации и авторизации с помощью доверительного отношения между лесами (федерация лесов). Доверительное отношение между доменом с ресурсами и доменом, на котором хранятся учетные записи пользователей, позволяет совершать безопасные Интернет-транзакции между компанией А и компанией В, соединенных с помощью доверительного отношения. При установке ADFS необходимо установить новые связующие серверы на каждой из сторон, между которыми вы хотите установить доверительные отношения. Связующие серверы маршрутизируют все запросы на аутентификацию, посланные пользователями из партнерской организации через Интернет. Связующие серверы в домене с ресурсами проверяют безопасность, основываясь на данных связующих серверов в домене с учетными записями.
Более подробное объяснение технологии работы ADFS можно найти на вкладке “ADFS Architecture”, доступной на сайте http: //www.windowsitpro.com, InstantDoc ID 48252.
В следующей главе
В этой главе рассматривались структура и принципы работы Active Directory. В следующих пяти главах рассматриваются проектирование и развертывание доменов на основе Active Directory, а также управление ими, управление репликацией между контроллерами доменов, исправление и восстановление базы данных Active Directory в случае возникновения неисправностей.
7
Управление репликацией Active Directory
ftp -
Н
а всех контроллерах домена хранится копия базы данных Active Directory с правами чтения и записи. Это простое утверждение открывает двери в целый сложный мир. Безопасное хранение десятков и сотен актуальных копий базы данных Active Directory в нестабильных условиях сети требует значительных умственных усилий от разработчиков и профессионализма при проектировании от системного администратора.
Для проектирования эффективной архитектуры Active Directory необходимо хорошо понимать принципы репликации. Без репликации можно получить множество несинхронизи- рованных контроллеров домена, клиентов, которые регистрируются по всей сети, низкую производительность поиска LDAP, проблемы при регистрации и даже искажение информации базы данных.
Новые возможности операционной системы Windows Server 2003
Вот возможности операционной системы Windows Server 2003, которые оказали самое заметное влияние на механизм репликации.
Масштабируемая архитектура сайтов. Был упрощен алгоритм, который использовался средством проверки согласованности знаний (Knowledge Consistency Checker — КСС). Это позволило решить проблему операционной системы Windows 2000, при которой крупные организации с большим количеством сайтов были вынуждены вручную настраивать соединения между сайтами, поскольку программа проверки согласованности знаний не успевала закончить расчеты в течение выделенного промежутка времени.
Репликация членства в группах. Связанные значения, например члены группы, теперь реплицируются как отдельные элементы, а не в виде одного значения атрибута. Это позволяет решить проблему операционной системы Windows 2000, при которой обновления членства в группе, внесенные в течение одного интервала репликации, перезаписывали друг друга.
Контексты именования приложений. Был добавлен новый контекст именования, который называется Application. В этом контексте именования хранятся объекты, относящиеся к приложениям. Операционная система Windows Server 2003 использует этот контекст именования для хранения объектов зоны DNS.
Минимизация перестройки глобального каталога. Добавление атрибута в глобальный каталог или его удаление теперь не требует полного цикла синхронизации. Это позволяет уменьшить объем данных, передаваемых по сети, при добавлении атрибута в глобальный каталог.
Расширения схемы. Была добавлена возможность связывать вспомогательные классы схемы с отдельными объектами, а не с целым классом объектов. Такая связь может быть динамической и позволять временно добавлять новые атрибуты определенному объекту или нескольким объектам.
Обзор репликации
Для управления репликацией Active Directory желательно иметь схему подключения контроллеров домена и описание информации, которой обмениваются контроллеры домена. В этом разделе рассматриваются компоненты Active Directory, которые реплицируются между контроллерами, направления передачи данных при репликации, управление передачей данных, а также механизмы разрешения конфликтов при обновлениях.
Репликация и контексты именования
Контроллеры домена, как тяжело работающие родители, дают только то, что у них есть. Каждый контроллер домена хранит копии как минимум трех контекстов именования.
Configuration. На каждом контроллере домена в пределах леса хранится копия этого контекста именования, доступная для чтения и записи.
Schema. На каждом контроллере домена в пределах леса хранится копия этого контекста именования, доступная только для чтения.
Domain. На каждом контроллере домена в пределах домена хранится копия этого контекста именования, доступная для чтения и записи.
Кроме этого, на серверах глобального каталога хранится частичная копия контекстов именования других доменов. Для хранения объектов зон DNS можно создать контекст именования Application. Он будет храниться на тех контроллерах домена, которые поддерживают работу службы DNS. На рис. 7.1 показан лес из трех доменов, а также контексты именования, которые хранятся на сервере глобального каталога в одном из доменов.
Мысленно создавая схему репликации, не забывайте, что каждый контекст именования представляет собой самостоятельную единицу репликации. Контроллеры домена должны распространять изменения, внесенные в их копии контекста именования, предоставляя информацию об изменениях другим контроллерам домена, на которых хранятся копии этого контекста именования.
Соединения
Контроллеры домена выполняют репликацию с определенными партнерами. Партнеры определяются с помощью объектов Connection, хранящихся в базе данных Active Directory. Карта контроллеров домена и соответствующих соединений называется топологией (topology).
Лес из трех доменов
Company.com
Сервер глобального каталога
Домен Company. com
dc=Company,dc=com
cn=Configuration, dc=Company,dc=com
cn=Schema,cn=Configuration, dc=Company,dc=com
cn=DomainDNSZones, dc=Company,dc=com
cn*ForestDNSZones, dc*Company,dc=com
Puc. 7.1. Схема леса аз трех доменов и контексты именования, которые хранятся в глобальном каталоге в пределах корневого домена.
За репликацию между двумя контроллерами домена отвечает служба агент репликации каталога DRA (Directory Replication Agent). Агент репликации каталога зависит от объектов Connection в карте топологии, определяя партнеров для репликации изменений в контекстах именования.
Объекты Connection определяют входящие маршруты репликации. Контроллеры домена запрашивают (pull) изменения у своих партнеров. Если контроллер домена нуждается в обновлении собственной копии контекста именования, агент репликации каталога отправляет партнерам запрос на репликацию. Агент репликации каталога на партнерах по репликации отвечает на запрос, формируя пакет с изменениями в контексте именования и отправляя этот пакет запросившему контроллеру домена.
Размер пакета обновлений зависит от объема оперативной памяти на контроллере домена. Размер пакета составляет 1/100 от объема оперативной памяти. Поэтому желательно устанавливать большой объем оперативной памяти на контроллеры домена. Также на испытывающий большую нагрузку контроллер домена желательно установить второй процессор.
Наблюдать за контроллерами домена, выбирающими партнеров по репликации, — все равно что наблюдать за подростками, выбирающими места в кафетерии во время обеда. Агент репликации каталога предпочитает использовать единственный объект Connection для определения конечных точек репликации всех контекстов именования, хранящихся на контроллере домена. Именно по этой причине для контроллеров домена предпочтительнее репликация с контроллерами того же домена. При необходимости контроллер домена сможет реплицировать контексты именования Configuration и Schema с одним партнером, а контекст именования Domain — с другим, но такая схема репликации используется только в самом крайнем случае.
Серверы глобального каталога используют особую логику при выборе партнера по репликации. Сервер глобального каталога должен получить частичную копию всех контекстов именования Domain. Эта копия доступна на других серверах глобального каталога или непосредственно с контроллеров интересующего домена. Помните об этом, создавая архитектуру репликации. Обеспечьте для сервера глобального каталога возможность связи с другими серверами глобального каталога. В противном случае сервер будет устанавливать соединения с контроллерами всех остальных доменов.
Репликация свойств
Репликация целых контекстов именования при каждом обращении к партнерам по репликации потребовала бы передачи большого объема данных по сети. Намного эффективнее реплицировать только те данные, в которые были внесены изменения.
Служба каталогов Exchange, на основе которой построена Active Directory, реплицирует целый объект при изменении любого свойства данного объекта. Это простой механизм репликации, при котором агент репликации каталога просто копирует всю строку базы данных, содержащую изменившийся объект. Но репликация целого объекта загружает сеть ненужными данными и усложняет механизмы обработки конфликтов, возникающих, когда несколько изменений осуществляется в течение одного интервала репликации.
Механизм Active Directory реплицирует отдельные свойства, а не целые объекты. Это позволяет экономить пропускную способность сети за счет небольшого увеличения сложности. В такой ситуации, когда по сети передаются отдельные свойства, оказывается сложнее поддерживать целостность базы данных.
Для управления репликацией свойств каждое свойство содержит массив информации, описывающий время модификации свойства, источник модификации и количество Модификаций свойства. Этот массив информации называется метаданными свойства (property metadata). Метаданные хранятся вместе с основным значением свойства. Дополнительную информацию по этой теме можно получить в разделе “Метаданные свойства” далее в этой главе.
Сайты
Надежность репликации во многом зависит от инфраструктуры на более низких уровнях. Если используется медленное или ненадежное сетевое соединение, репликация с использованием этого соединения может завершиться неудачно.
Компания Microsoft определяет сайт (site) как область быстрой и надежной связи по сети. Репликация в пределах сайта называется внутрисайтовой (intra-site). Репликация между сайтами называется межсайтовой (inter-site).
Принятие решения о создании сайтов и определение связей между сайтами является одной из важных задач развертывания архитектуры Active Directory.
Измерение пропускной способности
В отличие от классической операционной системы Windows NT, операционная система Windows Server 2003 динамически измеряет производительность соединения. Механизм измерений выглядит следующим образом.
Отправляется пустой тестовый эхо-пакет и замеряется время до получения ответа. Если ответ возвращается менее чем за 10 мс, соединение считается высокоскоростным.
Отправляется тестовый эхо-пакет на тот же сервер, но в этот раз с полезной нагрузкой размером 4 Кбайт, и замеряется время до получения ответа.
Вычисляется разность между скоростью ответа с полезной нагрузкой размером 4 Кбайт и скоростью ответа без нагрузки. Разность указывает на период времени, необходимый для копирования 4 Кбайт данных.
Эти действия повторяются трижды, что позволяет получить среднее время копирования 4 Кбайт данных.
Значение скорости переводится в килобиты в секунду и сравнивается с эталонной скоростью. По умолчанию эталонной является скорость 500 Кбит/с.
Обычно в качестве сайта рассматривается локальная или городская сеть. Также это может быть сеть университетского городка, если между зданиями проложены высокоскоростные линии связи. Для поддержки полноскоростной репликации в пределах сайта необходима пропускная способность 500 Кбит/с. Дополнительная информация об измерении скорости приводится во врезке “Измерение пропускной способности". Даже если соединение поддерживает достаточную скорость передачи данных, регулярные “заторы” и периоды больших задержек при передаче данных могут привести к проблемам при репликации, если не создать два различных сайта.
Кроме этого, сайты используются для ограничения объема передаваемых по сети данных при поиске LDAP и аутентификации Kerberos.
Частота репликации
База данных Active Directory использует слабо связанный механизм репликации (loosely coupled replication mechanism). Это значит, что существует задержка между внесением изменения в одной копии и появлением этого изменения в других копиях. В течение этого интервала запрос LDAP на различных контроллерах доменов может дать различные результаты. Помните об этом при диагностике проблем.
Время, которое требуется для репликации измененного свойства на все контроллеры домена, называется временем сходимости (convergence time). В идеальном случае изменения должны передаваться мгновенно, чтобы время сходимости стремилось к нулю. Время сходимости всегда является компромиссом между уменьшением объема данных, передаваемых по сети, и скоростью распространения обновлений. Active Directory использует два метода для управления временем сходимости: уведомление и опросы.
Уведомление
Как только контроллер домена изменяет свойство в одном из контекстов именования, он уведомляет об этом изменении партнеров по репликации в пределах сайта. После этого партнеры по репликации запрашивают копию изменившегося свойства и вносят изменение в собственные копии контекстов именования. Эти контроллеры домена, в свою очередь, уведомляют собственных партнеров по репликации, и изменение распространяется по сайту.
Срочная репликация
Несколько компонентов реплицируются немедленно, вне зависимости от длительности интервала репликации.
Сведения о блокировке учетных записей
Изменения в LSA Secrets
Изменения в настройках RID Manager (Диспетчер относительных идентификаторов)
Срочные изменения быстро реплицируются только в пределах сайта. Поскольку партнеры по межсайтовой репликации не используют механизм уведомлений, они не могут распространять пакеты срочной репликации. Это может оказать влияние на блокирование учетных записей, так как пользователь, который несколько раз неправильно ввел пароль, может находиться не на том сайте, на котором находится администратор, имеющий возможность отменить блокировку.
Можно подумать, что изменения паролей также реплицируются срочно, но такие изменения обрабатываются с помощью отдельного механизма. Изменения паролей отправляются непосредственно на PDC Emulator по защищенному каналу, а не по стандартному маршруту репликации. PDC Emulator выступает в роли второго барьера для всех неправильных паролей.
Небольшие интервалы уведомления позволяют быстрее распространять изменения, но при этом для передачи того же объема информации по сети передается больший объем данных (используются меньшие по размеру пакеты репликации). По умолчанию интервал уведомления составляет 15 секунд.
Уведомления используются только между контроллерами домена в пределах одного сайта. Репликация между пограничными серверами на разных сайтах выполняется только на основе опроса без использования уведомления. Это позволяет накапливать достаточный объем изменений (более 50 Кбайт) для получения эффекта от сжатия.
Опрос
Контроллеры домена периодически опрашивают партнеров по репликации о наличии изменений. Уменьшение интервала опроса сокращает время сходимости.
Интервал опроса между контроллерами домена в пределах одного сайта устанавливается равным одному часу. Внутрисайтовый опрос не предназначен для распространения изменений. Внутри сайта этот механизм используется только в качестве проверки работоспособности партнеров по репликации, если в течение часа не вносились изменения в базу данных Active Directory.
По умолчанию интервал опроса между контроллерами домена из различных сайтов устанавливается равным 180 минутам или трем часам. Это достаточно долго для распространения изменений. Можно указать меньший интервал опроса.
Запомните длительности интервалов опроса. При настройке сайтов и параметров репликации эти численные значения будут использоваться не один раз. Кроме того, эти значения оказывают влияние на ежедневную работу. Например, инженер службы поддержки, который отвечает за изменение состава членов в группах, должен помнить, что перемещение пользователя в другую группу будет реплицироваться на сайт пользователя в течение трех часов (или дольше).
Компоненты срочной репликации распространяются между сайтами с обычной частотой опроса. Можно включить уведомления между сайтами, но это не рекомендуется. Дополнительную информацию можно получить в разделе “Управление параметрами репликации”.
Методы репликации
Для большинства соединений между элементами сети используется протокол уровня приложений. Например, при копировании файла с клиента Windows на сервер Windows используется протокол Server Message Block (SMB). Если клиент электронной почты пытается отправить сообщение на почтовый сервер, используется протокол Simple Mail Transport Protocol (SMTP. Для репликации Active Directory используется один из двух протоколов высокого уровня.
Удаленные вызовы процедур
В основном, для репликации Active Directory используется протокол RPC (Remove Procedure Call — протокол удаленного вызова процедур). Транзакции RPC просты в использовании и предоставляют достаточный набор инструментов для создания соединений и управления ими. Протокол RPC особенно привлекателен для операций по репликации Active Directory, поскольку использует простую методологию шифрования. Шифрование является важным компонентом репликации. Нельзя допустить, чтобы в промежуточных сетях перехватывались пакеты с незашифрованной ценной информацией из службы каталогов.
В транзакции RPC клиент вызывает функцию на сервере RPC, не обращая внимания на состояние сети. Это значительно упрощает программирование приложений. С другой стороны,
приложение может отказаться от вызова, если результата приходится ждать слишком долго. Если клиент откажется от дальнейшего ожидания, соединение будет разорвано.
Итак, удаленные вызовы процедур являются отличным инструментом передачи данных, но такой метод недостаточно надежно работает в глобальных сетях. Именно по этой причине в Active Directory используются два метода удаленных вызовов процедур: быстрый метод (в локальной сети) и медленный метод (в глобальных сетях). При применении медленного метода возникают длительные задержки и предпринимается по нескольку попыток установить соединение до окончательного отказа.
SMTP
Для передачи пакетов репликации служба Active Directory может использовать протокол) SMTP. Этот протокол хорошо подходит для использования поверх ненадежных сетевых соединений. Кроме этого, протокол SMTP поддерживает асинхронные соединения, позволяя передавать несколько пакетов репликации одновременно.
К сожалению, протокол SMTP обладает парой серьезных недостатков с точки зрения репликации Active Directory. Первый недостаток — архитектурного характера. Протокол SMTP передает сообщения открытым текстом, поэтому система автоматически шифрует сообщения SMTP с помощью закрытой формы шифрования. Такое шифрование основано на сертификатах, поэтому необходим центр сертификации. Шифрование приводит к значительной нагрузке на сервер, поэтому пограничные серверы должны быть оборудованы несколькими процессорами для обеспечения необходимой производительности.
Вторым недостатком использования SMTP является ограничение службы репликации файлов (File Replication Service — FRS). Служба репликации файлов используется для синхронизации содержимого папки Sys vol между контроллерами домена. Для передачи данных при репликации служба репликации файлов может использовать только протокол RPC. Кроме этого, служба репликации файлов использует ту же топологию репликации (включая параметры соединений), что и база данных Active Directory, поэтому невозможно указать один транспортный протокол для репликации Active Directory и другой транспортный протокол для службы репликации файлов.
Из-за этого протокол SMTP не может использоваться для репликации содержимого контекста именования Domain, поскольку невозможно реализовать синхронизацию папки Sys- vol. Протокол SMTP может использоваться для репликации остальных контекстов именования, включая Configuration, Schema и Application, а также частичные копии контекстов именования, которые хранятся в глобальном каталоге.
Если существует удаленный офис с медленным и ненадежным подключением к сети, для которого необходимо использовать механизмы запроса по протоколу SMTP, для этого офиса придется создать отдельный домен.
Топология репликации
Контроллеры домена обладают информацией о расположении друг друга и о соединениях между ними. В LDAP для этой информации используется термин знание (knowledge). Создание топологии репликации возлагается на средство проверки согласованности знаний (Knowledge Consistency Checker — КСС).
Средство проверки согласованности знаний рассматривает топологию контроллеров домена как игру типа K*Nex. Каждые 15 минут служба просматривает контроллеры домена и принимает решение о размещении объекта Connection, чтобы каждый контроллер домена принял участие в процессе репликации за разумный период времени. Средство проверки согласованности знаний на пограничном сервере включает в расчеты пограничные серверы других сайтов.
Средство проверки согласованности знаний принимает решение на основе алгоритма растущего дерева. Одним из улучшений в операционной системе Windows Server 2003 является упрощение алгоритма, что позволяет средству проверки согласованности знаний обрабатывать большее количество сайтов и крупные сети. В операционной системе Windows 2000 существовал предел в 100 сайтов и контроллеров домена, по достижении которого администратору приходилось вмешиваться и создавать соединения вручную. В операционной системе Windows Server 2003 поддерживается значительно большее количество сайтов и контроллеров домена. Компания Microsoft не называет их предельного количества.
Внутрисайтовая топология
Администраторы Exchange обрадуются изменениям в средстве проверки согласованности знаний, которые были внесены с выходом операционной системы Windows Server 2003.
При выборе партнеров по репликации служба каталогов Exchange ведет себя, как моряк в суточном отпуске. Служба каталогов создает соединения для репликации между всеми контроллерами домена в пределах сайта. Средство проверки согласованности знаний в Active Directory ведет себя намного избирательнее. Выбирается ограниченное количество партнеров для структурирования четко контролируемой топологии. Для внутрисайтовой репликации средство проверки согласованности знаний создает кольцо репликации (рис. 7.2).
При создании кольца репликации средство проверки согласованности знаний следует правилу трех переходов: ни один контроллер домена не должен находиться на расстоянии более трех переходов от других контроллеров домена. Вспомните, что контроллер домена может ожидать до 15 секунд перед уведомлением партнеров по репликации об изменении одного из контекстов именования. Ограничивая количество переходов, средство проверки согласованности знаний обеспечивает быструю сходимость изменений.
DC-02
DC-01
DC-03
Рис. 7.2. Простое кольцо репликации
Варианты кольца репликации
При повышении нового контроллера домена средство проверки согласованности знаний на этом контроллере домена получает копию Active Directory. В процессе повышения до контроллера домена с помощью мастера устанавливается соединение с существующим контроллером домена, и используется это подключение для копирования полной копии базы данных Active Directory. При следующем запуске средства проверки согласованности знаний на существующем контроллере домена (в течение ближайших 15 минут) средство обнаруживает новое соединение и создает дополнительное соединение с новым контроллером домена. Теперь оба контроллера домена являются полноценными партнерами по репликации.
Средство проверки согласованности знаний на другом контроллере домена обращает внимание на эти изменения и создает собственные соединения для добавления нового контроллера домена в кольцо репликации. Это происходит без вмешательства администратора.
Если в кольце находится больше шести контроллеров домена (рис. 7.3), средство проверки согласованности знаний на каждом контроллере домена обнаруживает, что в кольце существуют связи длиной более трех переходов. В таком случае служба создает оптимизирующие соединения (optimizing connections) между контроллерами домена, чтобы снизить максимальное количество переходов. Контроллеры домена совместно используют информацию о соединениях, поэтому со временем формируется взаимовыгодная топология.
Рис. 73. Кольцо репликации с оптимизирующими соединениями
Восстановление кольца репликации
Если контроллер домена не отвечает на запрос репликации, агент DRA активизирует средство проверки согласованности знаний (КСС). Средство проверки согласованности знаний берет управление на себя и создает новые соединения в обход отказавшего контроллера домена.
Агент DRA продолжает попытки установить соединение с отказавшим контроллером домена. Как только контроллер оказывается в работоспособном состоянии, средство проверки согласованности знаний повторно устанавливает соединение, возвращая контроллер домена в кольцо репликации.
В нормальных условиях восстановление кольца репликации выполняется автоматически. Единственным случаем, когда требуется вмешательство администратора, является невозможность поиска подходящего партнера по репликации средствами средства проверки согласованности знаний из-за отказа службы DNS. Обычно это случается, когда отказавший контроллер домена одновременно является DNS-сервером для сайта. Если в параметрах протокола TCP/IP всегда указывать несколько DNS-серверов, то такая проблема не возникнет.
Межсайтовая топология
Картина репликации значительно меняется, если контроллеры домена находятся на различных сайтах. Рассмотрим ситуацию, когда контроллеры домена находятся в двух разных сайтах (рис. 7.4).
При такой конфигурации агенты репликации каталога, запущенные на контроллерах домена, не могут знать, что промежуточные сетевые соединения не поддерживают быструю передачу данных и могут отказать в любой момент. Поэтому агенты репликации каталога будут выполнять репликацию с такой же скоростью и частотой, как и при использовании высокоскоростных сетевых соединений.
С этого момента начинаются проблемы. Скоростные соединения RPC отказывают при повышенной загруженности внешних каналов. Проблемы в работе RPC проявляются в виде постоянных различий в копиях базы данных Active Directory, ошибок служб DRA и КСС в журнале событий. В итоге возникают критические ошибки RPC после нескольких следующих подряд отказов в установке соединения.
Для предотвращения таких ситуаций службой Active Directory для межсайтовой репликации используются специальные “медленные” соединения RPC. По этой причине для межсайтовой репликации используется совершенно другая топология (рис. 7.5).
Рис. 7.4. Кольцо репликации без специальной настройки межсайто- вой репликации
DC-02DC-02Связующий сервер (Bridehead)Связующий сервер (Bridehead)PhoenixPhoenixHoustonHoustonDC-05DC-05Генератормежсайтовойтопологии(ISTG)Генератормежсайтовойтопологии(ISTG)
DC-02
DC-02
Связующий сервер (Bridehead)
Связующий сервер (Bridehead)
Phoenix
Phoenix
Houston
Houston
DC-05
DC-05
Генератормежсайтовойтопологии(ISTG)
Генератормежсайтовойтопологии(ISTG)
Рис. 7.5. Топология межсайтовой репликации
Сравнение межсайтовой и внутрисайтовой репликации
Существует несколько отличий межсайтовой репликации от внутрисайтовой репликации.
Межсайтовая репликация выполняется только между двумя контроллерами домена, которые называются связующими серверами (bridgehead).
Между связующими серверами уведомления не передаются. Репликация реализуется исключительно с помощью опроса. По умолчанию для межсайтовой репликации используется интервал опроса продолжительностью 180 минут (3 часа).
Выполняется сжатие пакетов межсайтовой репликации, что позволяет сэкономить пропускную способность сети. Сжатие требует ресурсов центрального процессора на контроллере домена, поэтому связующий сервер должен обладать достаточной производительностью для выполнения всех возложенных на него задач.
Выбор связующего сервера
Средство проверки согласованности знаний выбирает сервер, который будет выступать в роли связующего сервера для сайта. Это решение принимается на основе следующих критериев.
Просматривается список указанных администратором связующих серверов. Если заданы предпочтительные серверы, связующий сервер выбирается среди них.
Если не заданы предпочтительные серверы, то рассматриваются все контроллеры домена в пределах сайта.
Средство проверки согласованности знаний сортирует контроллеры домена в порядке возрастания значения глобально уникального идентификатора (GUID). Выбирается контроллер домена с наибольшим идентификатором GUID.,
Генератор межсайтовой топологии
Выбор связующего сервера остается загадкой для контроллеров домена из другого сайта, пока им об этом не будет сообщено. Это похоже на выборы Папы Римского Советом кардиналов.
Вместо дыма из дымохода Сикстинской капеллы сайты ждут появления объекта Connection в собственном контексте именования Configuration. Этот объект создается контроллером домена, который назначается генератором межсайтовой топологии (Inter-Site Topology Generator — ISTG).
В пределах сайта существует только один генератор межсайтовой топологии. Он выбирается на основе того же критерия, что и связующий сервер — выбирается контроллер домена с наибольшим глобально уникальным идентификатором. Именно по этой причине часто генератор межсетевой топологии одновременно является связующим сервером, но это не всегда так. Например, генератор межсайтовой топологии может не входить в список предпочтительных связующих серверов.
Идентификация связующего сервера и генератора межсайтовой топологии
Для определения сервера, который выбран в качестве связующего, можно воспользоваться утилитой repadmin:
С: \>repadmin /bridgeheads /verbose
Gathering topology from site Phoenix (sl.company.com):;
Bridgeheads for site Phoenix (sl.company.com):
Source Site Local Bridge Trns Fail. Time # Status
HoustonSIRPC(never) 0 Operation
completed successfully.
Naming Context Attempt TimeSuccess Time#FailLast R esult
subsidiary 2002-02-0708:53:012002-02-0708:53:010Operation
completed successfully.
Configuration 2002-02-0709:04:422002-02-0709:04:420Operation
completed successfully.
Schema2002-02-0708:49:192002-02-0708:49:190Operation
completed successfully.
Генератор межсайтовой топологии указывается на консоли Active Directory— Sites and Services (Active Directory—сайты и службы) в окне свойств объекта NTDS Site Settings.
Генератор межсайтовой топологии работает независимо от средства проверки согласованности знаний, поскольку при наличии нескольких доменов сайт может иметь более одного связующего сервера. На каждом из связующих серверов хранятся копии контекстов именования Schema и Configuration и могут храниться копии глобального каталога с частичными копиями других контекстов именования. Межсайтовая репликация будет полностью разрушена, если каждый связующий сервер будет самостоятельно принимать решение о создании объекта Connection.
Особенности межсайтовой репликации
Если возникают проблемы при попытке создания мысленной картины межсайтовой репликации, обратите внимание на рис. 7.5.
В пределах одного сайта существует только один генератор межсайтовой топологии. Он создает объекты Connection, которые определяют маршруты репликации между связующими серверами различных сайтов.
На каждом сайте для каждого контекста именования Domain существует один связующий сервер. Один связующий сервер для контекста именования Domain назначается связующим сервером и для контекстов именования Schema и Configuration. Если связующий сервер для контекстов именования Schema и Configuration не является DNS- сервером, то отдельный связующий сервер будет отвечать за контексты именования Do-
.mainDNSZones иForestDNSZones.
Средство проверки согласованности знаний выбирает связующий сервер из списка кон- троллеров домена. Выбирается контроллер с наибольшим идентификатором GUID. Если администратор указал предпочтительные связующие серверы, выбор делается только из списка предпочтительных контроллеров домена.
При создании контекста именования Application и назначении контроллеров домена из различных сайтов для хранения копии этого контекста именования на каждом сайте будет связующий сервер для этого контекста именования. Это может быть (но не обязательно) связующий сервер, который используется для репликации другого контекста именования.
Выход из строя связующего сервера или генератора межсайтовой топологии
При выходе из строя связующего сервера его партнеры по репликации с других сайтов не смогут завершить транзакции по репликации. Агенты репликации каталога на локальных партнерах связующего сервера по репликации “заметят” отсутствие ответов от связующего сервера. Эта информация будет передана средству проверки согласованности знаний, которое начнет выбор другого связующего сервера. Средство проверки согласованности знаний выдерживает паузу (по умолчанию — два часа) до передачи обязанностей по репликации на новый связующий сервер.
Если администратор указал список предпочтительных связующих серверов и ни один из этих серверов не доступен, средство проверки согласованности знаний не сможет выбрать новый связующий сервер и межсайтовая репликация завершится неудачно. Именно по этой причине важно указывать несколько предпочтительных связующих серверов для каждого контекста именования Domain.
Если отказавший связующий сервер восстановит работоспособность, его прежние обязанности не восстановятся автоматически. Сервер устанавливается в очередь потенциальных связующих серверов на случай отказа нового связующего сервера.
Обнаружение отказа генератора межсайтовой топологии выполняется немного сложнее. Генератор межсайтовой топологии выступает в роли заслуженного профессора; он появляется только на церемониях и похоронах. Для того чтобы все знали, что он еще жив, генератор межсайтовой топологии периодически обновляет атрибут TnterSiteTopologyGenerator объекта NTDS Settings. По умолчанию атрибут обновляется каждые 30 минут. Обновление реплицируется на остальные контроллеры домена, предоставляя информацию о работоспособности генератора межсайтовой топологии. Если атрибут не обновлялся в течение часа, средство проверки согласованности знаний на другом контроллере домена указывает новый генератор межсайтовой топологии, выбирая контроллер домена с наибольшим идентификатором GUID.
Объекты сайта в базе данных Active Directory
Объекты, управляющие репликацией, хранятся в базе данных Active Directory в контейнере Sites контекста именования Configuration. Поскольку на каждом контроллере домена хранится копия контекста именования Configuration, все контроллеры домена владеют одинаковой информацией об именах сайтов, расположении и соединениях. Именно так средство проверки согласованности знаний на различных контроллерах домена приходит к одному решению о топологии репликации. Все контроллеры домена используют одинаковые исходные данные.
На рис. 7.6 показано, как с помощью объектов Active Directory реализуется представление различных компонентов топологии репликации. Ниже приведены перечень этих объектов и выполняемые ими функции.
ВходящееВходящеесоединениясоединенияЛогическиеЛогическиесоединениясоединенияСайтPhoenixСайтPhoenixСоединение Т1 между сайтами Phoenix И Houston Репликация: 180 минутСоединение Т1 между сайтами Phoenix И Houston Репликация: 180 минут
Входящее
Входящее
соединения
соединения
Логические
Логические
соединения
соединения
Сайт
Phoenix
Сайт
Phoenix
Соединение Т1 между сайтами Phoenix И Houston Репликация: 180 минут
Соединение Т1 между сайтами Phoenix И Houston Репликация: 180 минут
Рис. 7.6. Объекты Active Directory, с помощью которых реализуется топология репликации
Site. Этот объект выступает в роли контейнера для других объектов.
<название_сайта>. Этот объект представляет конкретный сайт. Объект имеет атрибут Site-Object-BL, который указывает на объект Subnet, например 10.3.20.0/24. Каждый сайт должен быть связан как минимум с одним объектом Subnet.
Subnet. Этот объект содержит атрибут Site-Object, который указывает на связанный объект Site. Сайт может быть связан более чем с одной подсетью, но подсеть может быть связана только с одним сайтом.
<имя_сервера>. Этот объект представляет определенный сервер. Объект содержит атрибуты, которые определяют DNS-имя сервера и его глобально уникальный идентификатор. Эта информация содержится в каждом свойстве, которое меняется на данном сервере, и выступает в роли маркера при репликации свойств на другие серверы.
NTDS Settings. В этом объекте,перечисляются контексты именования, которые хранятся на связайном контроллере домена. Например, сервер глобального каталога в домене DomA, который входит в двухдоменный лес, содержащий домен DomB, будет хранить сле-
\ дующие записи:
hasMasterNCs: CN=Schema,CN=Configuration,DC=DomA,DC=com hasMasterNCs: CN=Configuration,DC=DomA,DC=com hasMasterNCs: CN=DomB,CN=com hasPartialReplicaNCs: DC=DomB, DC=com
NTDS Site Settings. Этот объект содержит атрибут Schedule, который определяет принятое по умолчанию расписание репликации для объекта Connection в пределах сайта. Кроме этого, объект содержит атрибут Inter-site-Topology-Generator, который идентифицирует генератор межсайтовой топологии для сайта.
Site Link. Этот объект содержит атрибут Site-Link, который описывает сайты, выступающие конечными точками связи сайтов. Система определяет принятый по умолчанию объект связи сайтов, который называется Default-lP-Site-Link.
Connection. Этот объект определяет параметры входящей репликации для контроллера домена и содержит атрибут From-Server, который указывает партнера по репликации. Атрибут Transport-Туре указывает на вариант транспортного механизма, который используется для этого соединения. Атрибут Schedule определяет частоту опроса изменений. По умолчанию объект Connection использует расписание, определенное родительским объектом NTDS Site Settings.
В разделе “Настройка межсайтовой репликации”, приведенном далее в этой главе, рассматривается использование этих объектов при настройке сайтов и межсайтовой репликации.
Резюме топологии репликации
Вот основные моменты, которые необходимо учитывать при проектировании архитектуры сайтов Active Directory.
Active Directory делится на различные контексты именования. Каждый контекст именования формирует отдельную единицу репликации.
Реплицируются изменившиеся свойства, а не целые объекты. В метаданных свойств содержится специальная информация, которая используется при проверке целостности базы данных и управлении передачей данных при репликации.
Сайты определяют области надежной и быстрой передачи данных по сети. Пропускная способность высокоскоростного сетевого подключения начинается с 500 Кбит/с.
Контроллеры домена осуществляют репликацию только с определенными партнерами. Партнеры по репликации определяются объектами Connection в базе данных Active Directory. Для репликации используются только входящие соединения.
Средство проверки согласованности знаний отвечает за создание топологии репликации, создавая объекты Connection между контроллерами домена в пределах одного сайта. Генератор межсайтовой топологии создает объекты Connection между связующими серверами из различных сайтов.
Внутрисайтовая топология использует кольцо с таким количеством связей, чтобы переходов было не больше трех. При межсайтовой репликации используются связующие серверы.
В пределах сайта контроллеры домена уведомляют партнеров о наличии изменений. По умолчанию используется интервал продолжительностью 15 секунд. Между сайтами связующие серверы ожидают запроса от партнера по репликации из другого сайта. По умолчанию используется интервал опроса, равный трем часам.
Существует три варианта транспортировки для передачи данных при репликации: быстрый протокол RPC, который используется внутри сайта, медленный протокол RPC для использования между сайтами и протокол SMTP, который может использоваться между доменами. Протокол SMTP требует наличия протокола IPSec и центра сертификации.
Подробное описание транзакций репликации
Теперь, когда общая картина репликации ясна, подробно рассмотрим механизм транзакций репликации. Эта информация позволяет диагностировать проблемы при репликации и принимать критически важные решения при проектировании службы каталогов, например решения о размещении определенных контроллеров домена и выборе подходящей частоты опроса.
Репликация, при которой контроллеры домена выполняют роли различных хозяев, приводит к появлению нескольких новых проблем.
Целостность данных. Важно, чтобы все копии контекста именования на различных контроллерах домена совпадали после всех обновлений.
Избыточные обновления. Контроллеры домена не должны тратить время на репликацию обновлений, которые уже были получены от данного партнера по репликации.
Циркулирующие обновления. Контроллеры домена не должны тратить пропускную способность сети на репликацию обновлений от одного партнера по репликации, полученных от другого партнера.
Коллизии при обновлении. Существует вероятность внесения нескольких изменений в один и тот же объект или свойство на разных контроллерах домена за один и тот же интервал репликации. Такие потенциально конфликтующие изменения со временем приведут к конфликту при распространении по системе. Контроллеры домена должны правильно обрабатывать такие коллизии, чтобы избежать повреждения информации базы данных.
Метаданные свойства
Active Directory решает проблему репликации с несколькими хозяевами, добавляя информацию для управления репликацией в каждое свойство. Такая информация называется метаданными свойства (property metadata). Информация метаданных сохраняется вместе с основным значением свойства при каждой модификации свойства. Это так называемая атомарная транзакция (atomic transaction), при которой записываются или оба значения, или ни одно из значений.
Существует несколько возможностей просмотра метаданных свойств объекта. Самым простым способом является использование утилиты repadmin. Эта утилита доступна на всех контроллерах домена. Необходимо знать характерное имя интересующего объекта. Например, объект Sites в домене Company. com имеет характерное имя cn=Sites, cn=Conf iguration, dc=Company, dc=com. Рассмотрим пример использования команды repadmin. После создания объекта было модифицировано свойство, выделенное полужирным шрифтом (некоторые строки были перенесены из-за ограниченных размеров страницы).
repadmin /showmeta cn=sites,cn=configuration,dc=company,dc=com 10 entries.
Loc.USN
Org.DSAOrg.USN
Org.Time/Date
Ver
Attribute
1165
Phoenix\DC-01
1165
2002-02-23
17:48.40
1
objectClass
1165
Phoenix\DC-01
1165
2002-02-23
17:48.40
1
cn
2765
Phoenix\DC-02
2843
2002-02-24
18:14.10
3
description
1165
Phoenix\DC-01
1165
2002-02-23
17:48.40
1
instanc eType
1165
Phoenix\DC-01
1165
2002-02-23
17:48.40
1
whenCreated
1165
Phoenix\DC-01
1165
2002-02-23
17:48.40
1
^ showInAdvancedViewOnly
1165
Phoenix\DC-01
1165
2002-02-23
17:48.40
1
4> nTSecurityDescriptor
1165
Phoenix\DC-01
1165
2002-02-23
17:48.40
1
name
1165
Phoenix\DC-01
1165
2002-02-23
17:48.40
1
systemFlags
1165
Phoenix\DC-01
1165
2002-02-23
17:48.40
1
'b objectcategory
Заголовки столбцов в листинге являются аббревиатурами полей метаданных свойств. Вот описание этих полей.
Loc.USN (Update Sequence Number — локальный порядковый номер обновления). Это порядковый номер, который назначается свойству при создании или модификации. Каждый контроллер домена поддерживает счетчик порядковых номеров обновления. При каждом изменении любого свойства любого объекта следующий номер обновления сохраняется в метаданных свойства. Порядковый номер обновления является 64-разрядным числом, т.е. диапазона значений хватит контроллеру домена на предоставление примерно 10 000 номеров USN каждую секунду в течение примерно 66 миллионов лет.
Org. DSA (Originating DSA — исходный агент служб каталога). Агент служб каталога DSA (Domain Services Agent) по терминологии LDAP является сервером, на котором хранится копия базы данных каталога. Контроллер домена Active Directory также является агентом служб каталога LDAP. В отчете утилиты repadmin исходный агент DSA можно идентифицировать по имени сайта и имени компьютера, но в действительности используется значение идентификатора GUID. Если сервер, на котором запускается утилита repadmin, не в состоянии преобразовать имя сервера и сайта, будет показан только идентификатор GUID.
Org. USN (Originating USN — исходный последовательный номер обновления). Этот номер назначается свойству в копии, которая хранится на исходном агенте служб каталога. Обратите внимание, что в этом примере (за единственным исключением) локальный и исходный последовательные номера обновления совпадают. Это значит, что объект был создан на контроллере домена DC-01. Свойство Description было модифицировано на контроллере домена DC-02. Обратите внимание, что контроллер домена обновляет значение локального последовательного номера обновления при любой модификации свойства: непосредственной или в результате репликации.
Org. Time/Date (Исходное время/дата). Это метка времени, которая указывает время модификации свойства на исходном агенте служб каталога. Эта информация используется в качестве критерия при решении конфликта, когда свойство изменяется на двух контроллерах домена в течение одного интервала репликации.
Ver (Property Version Number — номер версии свойства). PVN является порядковым номером, по которому можно определить количество модификаций данного свойства.
Номер версии свойства является ключевым значением для определения идентичности двух копий. Вся система репликации направлена на обеспечение того, чтобы свойства с одинаковым номером версии имели одинаковые значения. Именно так в Active Directory решается проблема целостности данных. В следующих нескольких разделах подробно рассматривается использование метаданных для управления избыточными запросами на репликацию, предотвращения циклических обновлений и управления столкновениями.
Пример транзакции репликации
В следующих трех примерах используется кольцо репликации, состоящее из трех узлов в пределах одного домена и в пределах одного сайта (рис. 7.7). Состояние глобального каталога не имеет значения, так как используется только один домен.
Рис. 7.7. Кольцо репликации из трех узлов, в котором все контроллеры домена находятся в пределах одного сайта и одного домена
В этом примере отслеживается изменение свойства объекта пользователя с доменным именем cn=Al Bondigas. Рассмотрим несколько значений метаданных свойств объекта cn=Al_Bondigas. Листинг был получен с помощью утилиты repadmin на контроллере домена DC-01. Значения порядкового номера обновления и номера версии свойства для свойства Title, показанные полужирным шрифтом, различаются, поскольку они были модифицированы после создания объекта пользователя А1.
Log.USN
Originating DC
Org.USN Org.Time/Date Ver
Attribute
1416
Athlanta\DC-01
1416
2002-02-01
01:20:50
1
objectclass
1416
Athlanta\DC-01
1416
2002-02-01
01:20:50
1
cn
1416
Athlanta\DC-01
1416
2002-02-01
01:20:50
1
description
14D3
Athlanta\DC-01
14D3
2002-02-02
12:14:31
2
title
1416
Athlanta\DC-01
1416
2002-02-01
01:20:50
1
department
Использование порядкового номера обновления
Значение локального порядкового номера обновления предотвращает появление лишних запросов на обновление. Система использует локальный порядковый номер обновления в качестве метки для фильтрации всех обновлений, кроме самых последних. Использование локального порядкового номера обновления рассматривается в процедуре 7.1.
Процедура 7.1. Трассировка репликации, демонстрирующая использование порядкового номера обновления
В приведенных ниже листингах показаны отчеты об изменении свойства Description объекта cn=Al Bondigas.
Ниже показаны метаданные свойства на контроллере домена DC-01:
Loc.USN Org. DSA Org.USNOrg.Time/DatePVNAttribute
1416 Athlanta\DC-01 14162002-02-01 01:20.501description
Ниже показаны метаданные свойства на контроллере домена DC-02:
Loc.USN Org. DSA Org.USNOrg.Time/DatePVNAttribute
2F5 Athlanta\DC-01 14162002-02-01 01:20.501 description
Обратите внимание на различающееся значение локального порядкового номера обновления. Как только контроллер домена вносит изменение в значение свойства, в метаданные вносится значение порядкового номера обновления, полученное от собственного счетчика порядковых номеров обновления.
Изменим значение атрибута Description объекта А1 на контроллере домена DC-01. Ниже показаны метаданные измененного атрибута:
Loc.USN Org. DSA Org.USNOrg.Time/DatePVN Attribute
15B1 Athlanta\DC-01 15B12002-02-21 02:35.33 2description
Обратите внимание, что значение номера версии свойства увеличилось на единицу.
Контроллер домена DC-01 уведомляет DC-02 о внесении изменений, и контроллер DC-02 загружает пакет репликации. Вот метаданные свойства после загрузки изменений на контроллер домена DC-02:
Loc.USN Org. DSA Org.USN Org.Time/DatePVN Attribute
3AC Athlanta\DC-01 15B12002-02-21 02:35.332 description
Значение локального последовательного номера обновления отражает состояние счетчика последовательных номеров обновления на контроллере DC-02 в момент прибытия обновления.
После загрузки обновления с контроллера домена DC-01 на контроллер домена DC-02 принявший обновление контроллер домена заносит значение порядкового номера обновления, полученное от DC-01, в таблицу порядковых номеров обновления. Записи этой таблицы используются для запроса у партнеров по репликации только новых обновлений. Рассмотрим использование этой таблицы на другом примере репликации. В этот раз изменение вносится в свойство Department.
Ниже показаны метаданные свойства на контроллере домена DC-01 до внесения изменений:
Loc.USN Org. DSA Org.USNOrg.Time/DatePVN Attribute
1416 Athlanta\DC-01 14162002-02-01 01:20.50 2department
Обратите внимание, что значение номера версии свойства равно 1, а значение локального последовательного номера обновления совпадает со значением исходного последовательного номера обновления. Это указывает на то, что объект создавался на контроллере домена DC-01.
Изменим атрибут Department на контроллере домена DC-01. Новые метаданные будут выглядеть следующим образом:
Loc.USN Org. DSA Org.USNOrg.Time/DatePVN Attribute
15B2 Athlanta\DC-01 15B22002-02-21 02:37.15 2department
Обратите внимание, что теперь значение номера версии свойства равно 2.
Контроллер домена DC-01 уведомляет DC-02, который, в свою очередь, загружает пакет репликации, но при этом выдвигает условие. Контроллер домена сверяется с таблицей порядковых номеров обновления и указывает последнее значение порядкового номера обновления (15В1), которое было получено от DC-01. Другими словами, он запрашивает только те изменения, которые не были получены ранее.
Контроллер домена DC-01 получает запрос, содержащий максимальное значение порядкового номера обновления. На основании этого значения все находящиеся в очереди обновления фильтруются и остаются только те обновления, которые имеют большее или равной значение порядкового номера обновления. Из всех обновлений остается только обновление свойства Department, которое имеет порядковый номер обновления, равный 15В2. Контроллер домена DC-01 упаковывает обновление и отправляет пакет контроллеру DC-02.
Контроллер DC-02 вносит изменения в базу данных. Метаданные после обновления базы данных выглядят следующим образом:
Loc.USN Org. DSA Org.USN Org.Time/DatePVN Attribute
3AD Athlanta\DC-01 15B22002-02-21 02:37.152 department
Если у вас не хватило терпения разобраться во всем процессе, то нет ничего удивительного. Повторим основные моменты, которые необходимо запомнить.
i При модификации свойства значение номера версии свойства увеличивается на единицу и контроллер домена сохраняет следующий доступный порядковый номер обновления.
При получении обновления контроллер домена сохраняет полученной порядковый номер обновления в таблице порядковых номеров обновления.
При запросе обновлений контроллер домена предоставляет партнеру по репликации последний порядковый номер обновления, который был получен от этого партнера. Это позволяет избежать отправки избыточных обновлений.
Использование вектора обновления
Циклический характер репликации каталога допускает возможность распространения обновлений на контроллеры домена, которые уже получили это обновление. Если не проверять существование таких циклов, обновления будут циркулировать в кольце репликации бесконечно. Пакеты репликации будут расти, пока вся сеть не окажется загруженной из-за операций избыточной репликации.'
В такой ситуации требуется какой-то амортизатор. В этом случае в качестве амортизатора используется вектор обновления (Up-To-Dateness Vector — UTD Vector). Вот как он работает.
Метаданные свойства содержат идентификатор исходного сервера. При получении пакета репликации контроллер домена просматривает идентификатор исходного сервера и последовательный номер обновления, назначенный исходным сервером. Эта информация сохраняется в таблице векторов обновления. Таблица содержит идентификаторы GUID и наибольшие значения порядковых номеров обновления для каждого контроллера домена, который когда- либо отправлял обновления.
Контроллер домена распространяет свою копию вектора обновления вместе с наиболь- , шим порядковым номером обновления при каждом запросе на репликацию. Другими слова- i ми, запрашивается самое актуальное обновление, кроме тех обновлений, которые были полу- 1 чены из других источников. Пример этого процесса рассматривается в процедуре 7.2.]
Процедура 7.2. Трассировка репликации с использованием вектора обновления
В предыдущем примере атрибут Description, который был модифицирован на сервере
DC-01, выглядел следующим образом:
Loc.USN Org. DSA Org.USNOrg.Time/DatePVNAttribute
15B1 Athlanta\DC-01 15B12002-02-21 02:35.332description
Метаданные этого свойства на сервере DC-02 выглядели следующим образом:
Loc.USN Org. DSA Org.USNOrg.Time/DatePVNAttribute
ЗАО Athlanta\DC-01 15B1 2002-02-21 02:35.33 2 description
После сохранения обновления на сервере DC-02 контроллер домена сохранял вектор обновления для контроллера домена DC-01, соответствующий порядковому номеру обновления 15В1.
Рассмотрим, что происходит, когда контроллер домена DC-02 реплицирует обновленное свойство Description на контроллер домена DC-ОЗ. Ниже приведены метаданные этого свойства на контроллере домена DC-ОЗ до и после обновления:
До:
Loc.USN Org. DSA Org.USNOrg.Time/DatePVN Attribute
101 Athlanta\DC-01 14162002-02-01 01:20.501 description-
После:
Loc.USN Org. DSA Org.USNOrg.Time/DatePVN Attribute
1B9 Athlanta\DC-01 15B12002-02-21 02:35.332 description
После того как контроллер домена DC-ОЗ вносит изменения в базу данных, он сохраняет вектор обновления для контроллера домена DC-01, в котором отражается значение порядкового номера обновления 15В1.
В течение пяти минут после внесения обновления в базу данных контроллер DC-ОЗ уведомляет контроллер DC-01 о наличии обновлений. Контроллер DC-01 запрашивает пакет репликации.
Теперь, как говорят фокусники, следите за картами, а не за руками. В обычной ситуации контроллер DC-ОЗ добавил бы в пакет репликации обновление свойства Description. Но контроллер DC-01 предоставил копию вектора обновления, в которой для контроллера DC-01 указано значение порядкового номера обновления 15В2. Это значение было присвоено обновлению в собственной копии базы данных (обновление свойства Department, которое рассматривалось в предыдущем разделе).
Контроллер DC-ОЗ просматривает ожидающие обновления и замечает, что DC-01 является источником обновления свойства Description с порядковым номером обновления 15В1. Этот номер ниже, чем значение 15В2 из вектора обновления, поэтому контроллер DC-ОЗ удаляет это обновление из пакета репликации. Цикл обновления разорван.
Вектор обновления является критическим компонентом механизма для предотвращения “наводнений" в виде пакетов репликации. Вот основные моменты использования вектора об
новления.
Вектор обновления является комбинацией глобально уникального идентификатора (GUID) исходного сервера и порядкового номера обновления, назначенного исходным сервером.
Контроллер домена отправляет копию вектора обновления с каждым запросом на репликацию.
После получения запроса на репликацию контроллер домена отфильтровывает все обновления, порядковые номера обновлений которых меньше или равны записям в векторе обновления, предоставленном партнером по репликации.
Обработка коллизий при репликации
До этого момента рассматривалось, как метаданные свойств обеспечивают целостность данных и избавляют от ненужной репликации. Осталось рассмотреть последнюю проблему, которая возникает при репликации с несколькими хозяевами: что делать с конфликтующими изменениями, внесенными на различных контроллерах домена. Такая ситуация называется конфликтом (collision). К конфликту может привести несколько разных событий.
Одновременная модификация. Одно и то же свойство одновременно изменяется на различных контроллерах домена.
Одинаковые характерные имена. Объекты с одинаковым характерным именем создаются в одном и том же контейнере на различных контроллерах домена.
Перемещение объекта. На одном контроллере домена изменяется свойство объекта, а на другом контроллере домена объект переносится в другой контейнер.
Удаление объекта. На одном контроллере домена изменяется свойство объекта, а на другом контроллере домена объект удаляется.
Удаление контейнера. На одном контроллере домена изменяется свойство объекта, а на другом контроллере домена удаляется контейнер, содержащий этот объект.
Далее будет подробно рассмотрено решение каждой ситуации средствами Active Directory. Но сначала рассмотрим, что происходит с удаленными объектами.
Обработка удаленных объектов
Объекты, удаленные из Active Directory, не удаляются из базы данных немедленно. Это связано с тем, что изменения распространяются с помощью репликации, а репликация отсутствия объекта связана с определенными трудностями.
Вместо этого к удаленному объекту относятся, как к запятнавшему честь мундира офицеру. Его лишают всех атрибутов и переносят в скрытый контейнер, который называется Deleted Ob j ects. Объект невозможно восстановить после удаления.
После удаления объекта контроллер домена уведомляет об этом событии партнеров по репликации. Партнеры загружают пакет репликации с обновлением, в котором меняется характерное имя объекта, перемещающее объект в контейнер Deleted Objects. Партнеры по репликации выполняют перемещение объекта и лишают объект атрибутов.
Контейнер Deleted Objects недоступен на консолях управления Active Directory и в утилите ADSI Edit. Просмотр удаленных объектов из определенного контекста именования описывается во врезке “Просмотр удаленных объектов”.
Просмотр удаленных объектов
Компания Microsoft намеренно скрыла контейнер Deleted objects, поскольку нет задач, которые требовали бы просмотра его содержимого. Во время анализа инцидентов может потребоваться узнать, действительно ли был удален объект и когда произошло удаление. Для просмотра содержимого контейнера Deleted Objects можно воспользоваться утилитой LDAP Browser, Idp. ехе, которая доступна в составе Support Tools.
Подключитесь к домену.
В меню выберите Browse^Search (Просмотр^Поиск). Откроется окно Search (Поиск).
В поле Base DN (Базовое характерное имя) введите следующую информацию (подставьте имя собственного домена; угловые скобки важны).
<WKGUID=18E2EA80684FllD2B9AA00C04F79F805,DC=domain,DC=root>
Щелкните на Options (Параметры). После этого щелкните на Controls (Элементы управления). Откроется окно Controls (Элементы управления).
В поле Object Identifier (Идентификатор объекта) введите значение 1.2.840.113556. 1.4.417.
Сбросьте флажок Value (Значение).
Выберите для Control Туре (Тип управления) значение Server (Сервер).
Сбросьте флажок Critical (Критический).
Выберите переключатель Check In » (Включить в »).
Щелкните на кнопке ОК для сохранения изменений и закрытия окна.
В группе Search Call Туре (Тип поиска вызова) выберите Extended (Расширенный).
Сбросьте флажок Attributes Only (Только атрибуты).
Сбросьте флажок Chase Referrals (Отслеживать ссылки).
Выберите переключатель Display Results (Показывать результаты).
Щелкните на кнопке ОК, чтобы сохранить изменения и закрыть окно.
В группе Scope (Область видимости) выберите переключатель Subtree (Поддерево).
Щелкните на кнопке Run (Выполнить). Результаты поиска будут отображены в правой панели. Это объекты, которые находятся в контейнере Deleted Objects.
Сборка мусора
Объекты в контейнере Deleted Objects называются отметкой на удаление (tombstone). Отметка на удаление сохраняется в контейнере Deleted Objects в течение 60 дней. Это так называемый срок действия отметки на удаление (tombstone interval).
Как только для определенного объекта истекает термин действия отметки на удаление, объект может быть полностью удален из базы данных. Удаление выполняется в процессе сборки мусора (garbage collection). Сборка мусора выполняется каждые 12 часов. Сборщик мусора удаляет все отметки на удаление с истекшим термином действия, а затем архивирует базу данных и выполняет переиндексацию. Без периодической сборки мусора производительность работы с базой данных снижается.
При сборке мусора база данных сжимается, но физический размер файла ntds . dit остается тем же. Единственным способом освобождения дискового пространства является выполнение неинтерактивной дефрагментации.
Интервал, равный 60 дням, может показаться слишком долгим, но для этого есть определенные причины. Наличие удаленных объектов позволяет избежать повреждения базы данных в случае восстановления с ленты.
Рассмотрим использование термина действия, равного одному дню вместо 60 дней.
Предположим, отказал контроллер домена и существуют только резервные копии трехдневной давности (вполне реальная ситуация). Принимается решение о восстановлении данных из резервной копии, поскольку все изменения за три дня контроллер получит от других контроллеров домена Active Directory в процессе репликации.
К сожалению, актуальность ленты меньше, чем интервал в один день, поэтому удаленные с момента записи ленты объекты уже были удалены на других контроллерах домена. При восстановлении из резервной копии объекты окажутся в исходных контейнерах, а на других контроллерах домена будет отсутствовать информация, противоречащая существованию этих
объектов. База данных каталога окажется поврежденной, так как копии на различных контроллерах будут отличаться.
Интервала продолжительностью 60 дней достаточно для восстановления с ленты, но никогда нельзя забывать, что резервная копия базы данных Active Directory становится бесполезной через 61 день после создания.
Обладая этой информацией о процедуре обработки удаленных объектов, можно переходить к механизму разрешения конфликтов средствами Active Directory.
Одновременное изменение
Рассмотрим такую ситуацию. Генеральный директор желает, чтобы название его должности выдавалось в результатах поиска “в этой штуке, как ее, Active Directory, ну, которую вы поставили".
■ Генеральный директор звонит в службу поддержки, и принявший звонок техник с радостью меняет значение атрибута Title объекта СЕО на “СЕО”.
■ Ассистент генерального директора звонит системному администратору и просит его изменить название должности начальника. Администратор соглашается и меняет значение атрибута Title объектаСЕО на “Chief Executive".
Техник службы поддержки и системный администратор зарегистрированы на различных контроллерах домена. Изменение вносится в течение одного интервала репликации. Это значит, что измененные атрибуты имеют одинаковые значения номера версии свойства, но хранят различную информацию.
Неинтерактивная дефрагментация
Неинтерактивная дефрагментация полезна только для уменьшения объема файла ntds.dit. Возможности подсистемы хранения должны соответствовать наибольшему возможному размеру ntds.dit, поэтому нет совершенно никакого смысла запускать неинтерактивную дефрагментацию.
В течение 15 секунд изменения начинают распространяться на другие контроллеры домена. Поскольку обновления имеют одинаковые номера версии свойства, другие контроллеры домена должны принять решение о сохранении одного из изменений.
В качестве критерия можно использовать метку времени, которая установлена исходным контроллером домена. Будет сохранено то изменение, которое вносилось последним.
Если изменения были внесены одновременно, контроллер домена использует самый главный критерий: сравнение глобально уникальных идентификаторов исходного контроллера домена.
Побеждает контроллер с наибольшим глобально уникальным идентификатором. Конечно, это произвольное сравнение, но оно позволяет сделать однозначный выбор.
Одинаковое характерные имена
Рассмотрим еще одну ситуацию. Новый пользователь поступает на работу в компанию. Внутренний распорядок требует, чтобы представитель отдела кадров со специальными привилегиями на доступ к каталогу создавал объект пользователя в Active Directory и устанавливал все необходимые параметры. Но это очень важный пользователь, поэтому кто-то решил нарушить процедуру и вызвать непосредственно администратора операций.
Представитель отдела кадров и администратор операций одновременно создают объекты пользователя с одинаковыми именами в одном контейнере в течение одного интервала репликации. В Active Directory объекты не могут иметь одинаковые характерные имена. При репликации нового объекта по сети другие контроллеры домена сталкиваются с проблемой выбора. Какой объект необходимо сохранить в базе данных?
Существует вероятность, что при простой перезаписи объекта другим объектом будет потеряна информация о пользователе, поэтому необходимо сохранить оба объекта. Один объект переименовывается с использованием отличающегося характерного имени. Каждый контроллер также должен переименовать объект, чтобы сохранить идентичность копий.
И в этом случае в качестве критерия используется сначала метка времени, после которой выполняется сравнение глобально уникальных идентификаторов GUID. Если объекты создаются в разное время, контроллер домена сохраняет имя объекта, созданного последним. Объект, созданный первым, переименовывается. Если метки времени совпадают, сохраняется имя объекта, созданного на сервере с наибольшим глобально уникальным идентификатором.
Для создания нового имени используется следующая процедура.
Оригинальное имя используется в качестве префикса.
К оригинальному имени добавляется зарезервированный символ звездочки ( * ).
К полученному имени добавляется глобально уникальный идентификатор исходного сервера.
В результате имя будет выглядеть следующим образом:
cn=Jane Jones*2FAC1234-31F8-llB4-A222-08002B34C003
При этом единственным предупреждением будет служить запись в журнале событий. После обнаружения проблемы администратор должен просмотреть оба объекта и решить, какой объект необходимо сохранить, а какой удалить.
Уведомление о результатах конфликта
При появлении ошибок Active Directory, например конфликта при репликации, система заносит в журнал событий предупреждение и продолжает работу. Администратор может установить утилиту, которая отправляет сообщение по электронной почте или выдает его на экран при появлении критических ошибок или предупреждений.
В качестве примера такой утилиты можно указать программу LogCaster от компании Rip- pleTech, Inc. (www.rippletech.com). Эта программа может быть настроена на обнаружение конкретных событий и отправку SNMP-уведомлений, сообщений на пейджер, сообщений на мобильные телефоны или сообщений электронной почты.
Такой же продукт, который называется Event Log Monitor, предоставляется для ознакомительного использования и покупки компанией Sunbelt Software (www. sunbelt software. com).
Перемещенные объекты
Вот еще одна ситуация, которая может привести к коллизии. Один администратор вносит изменения в значение свойства объекта, а в это же время второй администратор на другом контроллере домена переносит этот объект в другой контейнер. Когда обновление свойства дойдет до контроллера домена, на котором был перемещен объект, перед службой каталогов встанет проблема. Характерное имя объекта изменилось, а характерное имя, связанное со свойством объекта, нет.
Active Directory легко решает эту проблему, поскольку глобально уникальный идентификатор объекта не меняется при изменении характерного имени. Служба каталога просто находит объект с соответствующим глобально уникальным идентификатором, определяет новое характерное имя и обновляет свойство у правильного объекта.
Удаленные объекты
Следующий тип конфликтов происходит в следующих ситуациях. Один сотрудник некоего отдела меняет значение атрибута Telephone в объекте другого сотрудника. В это же время менеджер увольняет сотрудника и требует от администратора удалить учетную запись поль-
зователя. (В реальной ситуации учетная запись пользователя деактивизируется на некоторое время, но не удаляется. Не стоит уничтожать идентификатор безопасности пользователя, пока не будет полной уверенности, что пользователь не вернется.)
Когда объект удаляется, он перемещается в контейнер Deleted Objects. Кроме этого, объект лишается практически всех атрибутов. Если обновление одного из атрибутов приходит после удаления объекта, система игнорирует обновление атрибута.
Удаленные контейнеры
В этом случае конфликт вызывается удалением целого контейнера на одном из контроллеров домена. В это время на другом контроллере домена в этот контейнер перемещается объект.
Например, предположим, что звонит знакомый и сообщает, что его повысили до менеджера в филиале компании. Кроме этого, он просит выполнить все необходимые операции, чтобы обеспечить ему доступ к компьютерам в офисе. Для этого объект пользователя придется переместить в соответствующую организационную единицу (OU), чтобы пользователь мог получить доступ к настройкам рабочих станций и групповым политикам, которые применяются в этом офисе.
В это же время генеральный директор обращается к администратору, сообщает, что филиал закрывается, и просит администратора удалить всю организационную единицу из базы данных.
При перемещении меняется несколько свойств объекта, включая характерное имя объекта. Если данные об обновлении объекта пользователя прибывают на контроллер домена после удаления организационной единицы, база данных Active Directory сталкивается с проблемой. Обычно объект помещается в контейнер организационной единицы, но в этом случае целевым контейнером становится Deleted Obj ects и система не знает, действительно ли нужно удалять объект. Вместо этого объект помещается в скрытый контейнер Lost and Found.
В отличие от контейнера Deleted Objects, контейнер Lost and Found можно просмотреть с помощью консоли Active Directory — Users and Computers (Active Directory — пользователи и компьютеры). Для этого необходимо включить Advanced View (Дополнительные функции). Объект пользователя остается действительным, и пользователь по- прежнему может регистрироваться в системе. О возникшей проблеме можно не догадываться, пока пользователь не пожалуется, что не получает ожидаемого результата от использования групповых политик.
Объект из контейнера Lost and Found можно переместить в другой контейнер или удалить.
Служба Windows Time
Синхронизация времени критически важна для железных дорог, аэропортов, свиданий с незнакомками и доменов Active Directory. Правильное управление конфликтами требует согласующихся меток времени, поэтому часы на контроллерах домена должны работать синхронно. Кроме этого, метки времени используются системой аутентификации Kerberos для предотвращения хищения аутентификационных билетов с последующим их использованием.
За синхронизацию отвечает служба Windows Time или WTS. Фактически служба называется Win32Time и входит в пакет Service. ехе.
Служба WTS использует стандартную реализацию протокола SNTP, описанного в документе RFC 2030, “Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI”. Каждый контроллер домена под управлением операционных систем Windows 2000 и Windows Server 2003 является сервером SNTP.
Для синхронизации времени протокол SNTP использует иерархический принцип. Контроллер домена, выполняющий роль PDC Emulator, выступает в роли эталона времени для домена. (Дополнительная информация приводится в главе 8, “Проектирований доменов Windows Server 2003”). В лесу каждый PDC Emulator синхронизирует время с PDC Emulator из корневого домена. При создании леса корневой домен создается первым.
Совет по использованию системного реестра: служба Windows Time
Параметры службы Windows Time Service хранятся в системном реестре следующим образом: Раздел:HLKM\System\CurrentControlSet\Services\W32TIME\Parameters Запись/Значение: LocalNTP / О
Запись/Значение: Period / Specialskew
Запись/Значение: туре / ntds
Для службы времени можно включить протоколирование, которое помогает при диагностике проблем синхронизации времени:
Раздел:HLKM\System\CurrentContго1Set\Services\W32TIME\Config
Запись: FileLogName
Значение: <полное_имя_файла_журнала>
Запись: FileLogEntries
Значение: 0-109 (введите, как показано здесь)
Остановите и перезапустите службу для инициализации файла и запуска журнала. Удалите записи для отключения журнала.
Net Time и WIN32TM
Операционная система Windows Server 2003 предоставляет две утилиты с интерфейсом командной строки, которые предназначены для управления службой WTS: net t ime и win3 2tm. Утилита win32tm предоставляет больше возможностей по просмотру и установке параметров работы протокола SNTP.
Например, если необходимо узнать источник точного времени для определенного клиента, введите следующую команду: w32tm -source -v
В отчете утилиты будет представлен подробный список обнаруженных источников точного времени. По умолчанию современные операционные системы Windows для получения точного времени обращаются к контроллеру домена.
Кроме этого, можно воспользоваться командой net time /querysntp, которая выводит имя источника точного времени для клиента, но в результате будет показан сервер t ime. windows.net. Это сервер точного времени, который поддерживается компанией Microsoft. Компьютеры, входящие в домен, будут игнорировать этот источник и за точным временем будут обращаться к регистрационному серверу. Контроллеры домена обращаются за точным временем к PDC Emulator в пределах своего домена. PDC Emulator каждого домена обращается к PDC Emulator корневого домена.
Если необходимо синхронизировать время на PDC Emulator корневого домена, воспользуйтесь следующей командой:
net time /setsntp:<эталон_времени>
Чаще всего в пределах США используется сервер точного времени, поддерживаемый National Institute of Standards and Technology (NIST). Список серверов точного времени и их IP-адресов доступен по адресу www.boulder.nist.gov/timefreq/service/time- servers. html. Для использования SNTP на компьютере, защищенном брандмауэром, необходимо открыть UDP-порт 123.
Если синхронизацию времени необходимо выполнить на изолированном сервере или на рабочей станции, можно воспользоваться той же процедурой. Для синхронизации клиента введите следующую команду:
w32tm -once
В этом случае выполняется однократная синхронизация с сервером NTP. Кроме этого, можно ввести такую команду:
net time /domain:<имя_домена> /set
Для обоих вариантов требуется разрешение на замену локального времени на клиентском компьютере. Для проверки наличия этого права доступа можно воспользоваться утилитой who ami, входящей в состав Resource Kit. Введите команду whoami /all. В отчете будут показаны все разрешения и группы, в которые входит пользователь. Отобразятся имена групп и их идентификаторы безопасности. Обычные пользователи не имеют разрешений на изменение локального времени системы.
Пользователи портативных компьютеров, которые сталкиваются с проблемами при син- хронизации времени, поскольку долго находятся вне сети, могут получить право менять локальное время с помощью групповой политики. Групповая политика хранится в разделе Computer ConfigurationWVindows Settings\Local Policies\User Rights Assignment\Change The System Time (Конфигурация компьютерам Настройки Windows1^ Локальные политики безопасности1^ Назначение прав пользователей М Изменение системного времени). Создайте группу безопасности для пользователей портативных компьютеров и добавьте ее в групповую политику.
Не стоит вручную устанавливать время на контроллере домена. Если это сделать, в обновления свойств Active Directory будут включены неправильные метки времени, пока контроллер домена в очередной раз не выполнит синхронизацию с PDC Emulator. Это может привести к проблемам целостности при репликации объектов. Всегда выполняйте изменение времени с помощью синхронизации контроллера домена с сервером точного времени. Самым простым способом является использование команды net t ime, например:
net time \\имя_локального_компьютера /set
Команда net time не может использоваться для подключения к серверам точного времени, которые работают не под управлением операционной системы Windows, поскольку для обработки транзакции используется протокол SMB. Если сервер необходимо настроить на использование внешнего источника точного времени, воспользуйтесь следующей командой (в данном случае указывается стандартный сервер точного времени, который поддерживается National Institute of Standards and Technology): net time /setsntp:nistl.datum.com
Команда net time /setsntp вносит в системный реестр имя или IP-адрес сервера точного времени. Указанный сервер проверяется при каждой загрузке компьютера. Если воспользоваться командой net time или net time /set, параметр /setsntp перестанет иметь какое-либо значение.
Проектирование архитектуры сайтов
В любом процессе проектирования приходится реализовывать необходимые возможности и адекватные средства компенсации отказов. Проектируя архитектуру сайтов для организации, не забывайте о следующих ключевых моментах.
Минимизируйте время сходимости, не подвергая внешние каналы повышенной нагрузке.
Локализуйте доступ клиентов к контроллерам домена для аутентификации и доступа к службам Active Directory. Это касается и запросов к глобальному каталогу.
Подготовьтесь к возможному отказу связующих серверов.
Подготовьтесь к возможному отказу внешнего канала.
Обеспечьте маршрут репликации каждого контекста именования через каждый сайт.
Планирование сайтов зависит от сетевой инфраструктуры. Начинайте с оценки существующей инфраструктуры. На рис. 7.8 показана типичная структура внешних каналов организации среднего размера. Компания имеет четыре региональных офиса. Офисы могут быть как в пределах одного города, так и на различных континентах. Основную проблему составляет не расстояние, а скорость передачи данных и надежность внешних каналов.
Отделение компании в Альбукерке
Отделение компании а Солт-Лейк-Сити
Рис. 7.8. Схема внешних соединений для офисов в четырех городах
Ниже перечислены ключевые аспекты сетевой инфраструктуры, которые оказывают влияние на архитектуру сайтов.
Для связи между офисами используются соединения с различной пропускной способностью. Некоторые соединения, например ISDN, оказываются слишком дорогими для непрерывного использования. В такой ситуации приходится подсчитывать цену соединения между сайтами, чтобы обеспечить репликацию самым выгодным маршрутом.
По сетевым соединениям, кроме ISDN, можно передавать достаточно большой объем данных. Это позволяет использовать короткие временные интервалы опроса между сайтами.
Лес состоит из двух доменов. Необходимо обеспечить передачу обновлений контроллерам домена от партнеров из того же домена. Кроме этого, необходимо обеспечить обмен обновлениями между серверами глобального каталога.
Все офисы связаны высокоскоростными соединениями, поэтому нет смысла использовать протокол SMTP или создавать специальное расписание репликации.
На рис. 7.9 показан план сайтов для инфраструктуры, показанной на рис. 7.8.
В этом примере для каждого офиса создается отдельный сайт. Может возникнуть соблазн разместить соединенные быстрыми каналами офисы на одном сайте, что позволит миними-
зировать время сходимости, но это противоречит еще одной цели — локализации пользовательского доступа. Использование отдельных сайтов позволяет клиентам в каждом офисе выполнять аутентификацию на локальном контроллере домена. Даже если отделения соединены каналами DS-3 или SONET, желательно создавать отдельные сайты, чтобы минимизировать ущерб в случае отказа соединения.
Альбукерке
Hou-Alb-512
Солт-Лейк-Сити
Рис. 7.9. План репликации сайтов, сиответствуюгций схеме внешних каналов, показанных на рис. 7.8
Объекты IP Subnet используют IP-адреса, назначенные каждому офису инфраструктурой маршрутизации. Это позволяет контроллерам домена направлять клиента на соответствующий сайт на основе IP-адреса клиентского компьютера.
Объекты Site Link соответствуют сетевой инфраструктуре в пределах, необходимых для определения межсайтовой топологии. Нет необходимости создавать объект Site Link для каждого маршрута. Связи сайтов не используются для маршрутизации отдельных пакетов репликации Active Directory. Связи сайтов просто используются для определения линий соединения. В основном, они предназначены для предоставления информации о допустимых маршрутах генератору межсайтовой топологии (ISTG). Это позволяет генератору межсайтовой топологии создавать объекты Connect ion на соответствующих связующих серверах.
Имена объектов Site Link состоят из имен конечных точек связи, чтобы администратор с первого взгляда мог определить назначение связи. Используется тот же принцип, что и на сельских шоссе на Среднем Западе США. Например, в штате Цинциннати шоссе Кармел- Табаско связывает города Кармел и Табаско.
Кроме этого, в имя связи сайтов можно включить тип соединения, чтобы обозначить различные связи между одними и теми же сайтами. Например, основное соединение между офисом в Хьюстоне и офисом в Альбукерке представляет собой frame relay PVC (Permanent Virtual Circuit — постоянный виртуальный канал) co скоростью передачи информации 512 Кбит/с, поэтому связь сайтов будет называться Хыо_Альб_512.
Стоимость связи отражает скорость физического соединения. Связующие серверы выбирают направление отправки уведомлений согласно стоимости соединения. В этом примере связующий сервер в Альбукерке будет получать пакеты репликации от связующего сервера в Финиксе через связующий сервер в Хьюстоне. Используется именно этот маршрут вместо
непосредственной загрузки с сайта в Финиксе по линии ISDN, поскольку стоимость связи сайта до Хьюстона ниже, чем стоимость до Финикса. В этом примере связи назначаются следующим образом.
Самому быстрому соединению назначается стоимость 5. Это обеспечивает пространство для маневра в случае появления более быстрого подключения.
Оставшиеся связи получают стоимости, кратные стоимости самой быстрой связи. Например, связь со скоростью передачи данных 512 Кбит/с работает в три раза медленнее линии Т1, поэтому такая связь стоит 3x5, или 15. Стоимость подключения ISDN составляет 60 (в 12 раз медленнее Т1, или 12x5).
Частота опроса для высокоскоростных связей устанавливается равной 15 минутам. Это минимальный интервал репликации, который позволяет обеспечить самую быструю сходимость изменений. Частота опроса для подключения ISDN устанавливается равной 30 минутам, что позволяет сократить нагрузку на более медленную линию.
В плане сайтов указываются предпочтительные связующие серверы, хотя делать это и не обязательно. Средство проверки согласованности (КСС) знаний выбирает связующие серверы автоматически. Создание списка предпочтительных связующих серверов позволяет выбрать на эту роль самый производительный компьютер. Важно ясно обозначить предпочтительные связующие серверы, чтобы обслуживающий персонал случайно не откЛючил эти контроллеры домена, прекратив тем самым репликацию сайта.
Мост связей сайтов
Средство проверки согласованности знаний (КСС) в пределах каждого сайта предполагает, что контекст именования можно получить с удаленного сайта через промежуточный сайт. Такой механизм транзитной репликации называется мостом (bridging). Для объекта ip Transport доступно свойство Bridge All Site Link (Создать мосты для всех связей сайтов), установка которого приводит к объединению всех связей сайтов в один большой мост. Это позволяет связующему серверу получать пакеты репликации по самому дешевому соединению независимо от стоимости внешнего соединения.
Если используется большая сеть с большим количеством маршрутизаторов и несколькими доменами, некоторые комбинации маршрутов могут оказаться более предпочтительными. В таком случае можно сбросить флажок Bridge All Site Link (Создать мосты для всех связей сайтов) и определить соответствующий Site Link Bridge (Мост связей сайтов). Это требуется только в случаях, когда возникают значительные задержки при репликации из-за выбора неправильного маршрута связующими серверами.
В плане сайтов необходимо также указать расположение контроллеров домена и серверов глобального каталога. Ниже приведено несколько советов по размещению серверов.
В небольших офисах с несколькими пользователями можно не устанавливать локального контроллера домена. При этом офис все равно определяется как сайт, чтобы пользователи могли проходить аутентификацию на контроллере домена в ближайшем офисе.
На сайтах большего размера должен быть локальный контроллер домена, который не настроен в качестве сервера глобального каталога. Контроллер домена должен быть настроен на кэширование информации из глобального каталога, чтобы отказ внешнего соединения не приводил к невозможности аутентификации.
На крупных сайтах должны быть установлены локальные контроллеры домена и сервер глобального каталога. Это позволяет преодолеть пиковые нагрузки при массовой аутентификации клиентов. Также это позволяет поддерживать непрерывность ссылок между сайтами; которые содержат различные домены. На практике, если серверы обладают достаточной производительностью, каждый контроллер домена можно сделать сервером глобального каталога.
Сайты Active Directory необходимо настроить до развертывания контроллеров домена в различных сайтах. Таким образом, система сможет разместить контроллеры домена на правильных сайтах в процессе повышения. В противном случае сервер придется перемещать на правильный сайт вручную.
Настройка межсайтовой репликации
После создания плана сайтов, в котором определены сайты, подсети IP, связи сайтов, стоимости связей и связующие серверы, можно переходить к созданию объектов в Active Directory. Ниже представлена примерная последовательность действий.
Переименуйте объект Default-First-Site-Name
Создайте новые объекты Site
Создайте объекты Subnet
Создайте объекты Site Link
Назначьте связующие серверы
После этого средство проверки согласованности знаний будет обрабатывать все изменения в распределении контроллеров домена и серверов глобального каталога без вмешательства администратора.
Переименование объекта
Default-First-Site-Name
В большинстве случаев имя первого сайта оказывается немного длинным и неудобным. Последовательность действий по переименованию сайта приводится в процедуре 7.3.
Процедура 7.3. Переименование объекта Default-First-Site-Name
Откройте консоль Active Directory — Sites and Services (Active Directory — сайты и службы).
Щелкните правой кнопкой мыши на объекте Default-First-Site-Name и выберите Rename (Переименовать) из контекстного меню. Название объекта будет заключено в рамку с синим фоном.
Замените имя объекта именем сайта, указанным в плане сайтов, и нажмите клавишу <Enter>. В этом примере в качестве имени сайта используется Phoenix.
Не закрывайте консоль. Она потребуется для выполнения последующих операций.
Изменение имени автоматически регистрируется в службе DNS. Воспользуйтесь консолью DNS и проверьте изменение имени. Это позволяет обеспечить правильность ссылок на сайты, используемых клиентами Active Directory. Если в момент изменения имени сайта недоступен DNS-сервер или во время репликации изменения обрывается сетевое соединение, новое имя сайта будет зарегистрировано после подключения к сети DNS-сервера. Иногда приходится удалять прежнее имя сайта из таблицы зоны вручную.
Создание нового сайта
После переименования первого сайта создайте объекты оставшихся сайтов, описанных в плане. Для этого необходимо воспользоваться консолью Active Directory — Sites and Services (Active Directory — сайты и службы), как описано в процедуре 7.4.
Процедура 7.4. Создание нового объекта сайта
Щелкните правой кнопкой мыши на объекте Sites (Сайты) и выберите из контекстного меню команду New Site (Создать сайт). Появится окно New Object — Site (Новый объект — Сайт), показанное на рис. 7.10.
В поле Name (Имя) введите название сайта. В данном примере используется имя Houston.
В списке Link Name (Название связи) выберите DefaultIPSiteLink. Это единственный шаблон. Собственные связи будут создаваться немного позже.
Щелкните на кнопке ОК для создания объекта Site.
Рис. 7.10. Окно New Object — Site
При создании объекта Site система автоматически создает контейнер Server и два объекта Settings: Licensing Site Settings иNTDS Site Settings. Кроме этого, система добавляет в зону DNS несколько записей SRV, которые указывают на новый контроллер домена. Эти записи сгруппированы в разделах_msdcs и _sites.
\
Создание подсетей IP
Active Directory использует подсети для идентификации сайтов. Создайте объект Subnet для каждой подсети, как рассказано в процедуре 7.5.
Процедура 7.5. Создание объекта Subnet
Щелкните правой кнопкой мыши на объекте Subnets и выберите команду New^Subnet (Создать1^ Подсеть) из контекстного меню. Откроется окно New Object — Subnet (Новый объект — Подсеть), показанное на рис. 7.11.
В поле Name (Имя) введите адрес подсети и количество разрядов маски подсети. В этом примере используется подсеть 10.1.1.0с 24-битной маской подсети (255.255.255.0).
Выберите объект Site, который будет связан с объектом Subnet. В этом примере исполь* зуется сайт Phoenix. Если в пределах сайта находится более одной подсети, можно создать несколько объектов Subnet и связать каждый из них с одним и тем же сайтом.
Щелкните на кнопке ОК, чтобы создать объект подсети и вернуться в основное окно консоли.
Воспользуйтесь этой процедурой для создания объектов Subnet для каждой подсети.
^ewObpul Subnet
щ Atlanta
§ Phoenix
Рис. 7.11. Окно New Object— Subnet, в котором показана подсеть для сайта Phoenix
LajtijSSiSfiitiM.LiaaitibiriMMi^^
Создание связей сайтов
Теперь можно создавать и настраивать необходимые объекты Site Link, которые описывают сетевую инфраструктуру. Последовательность необходимых действий рассматривается в процедуре 7.6.
Процедура 7.6. Создание и настройка объектов site Link
1.
2.
5.
8.
Разверните дерево и в разделе Sites1* Inter-Site Transports (Сайты1* Межсайтовые транс- i порты) найдите объект IP. | Щелкните правой кнопкой мыши на объекте IP и выберите из контекстного меню команду 1 New1*Site Link (Создать^Связь сайтов). Откроется окно New Object — Site Link (Новый I объект — Связь сайтов), показанное на рис. 7.12. | В поле Name (Имя) введите имя объекта Site Link. j Выберите два сайта и щелкните на кнопке Add (Добавить) для добавления сайтов в спи- 1 сок Sites In This Link (Сайты для этой связи). Связь сайтов должна быть установлена как | минимум с двумя сайтами. 1 Щелкните на кнопке ОК для создания нового объекта. 4
Откройте окно Properties (Свойства) для нового объекта Site Link (рис. 7.13). 1 Введите описание связи в поле Description (Описание). Желательно указать тип соедине- 1 ния, пропускную способность и другую полезную информацию, которая поможет при 4 устранении проблем в работе связи. ■ Назначьте стоимость связи. В примере сети это самое быстрое подключение. Для связи на Я основе соединения с пропускной способностью 512 Кбит/с назначьте стоимость 20. Для я резервной линии ISDN назначьте стоимость 100. Установите минимальное количество я параметров. Средство проверки согласованности знаний (КСС) будет использовать эти ■ параметры для создания карты дерева распространения. Если указать слишком много зНа-Я чений, это может ввести в заблуждение механизм. Я
Рис. 7.12. Окно New Object— Site Link
Рис. 7.13. Свойства связи сайтов Phoenix — Houston
Уменьшите стандартный интервал репликации (кроме случаев использования действительно низкоскоростного или загруженного соединения). Система допускает самый короткий интервал репликации, равный 15 минутам. Если ввести более короткий интервал, изменение будет принято, но все равно будет использоваться 15-минутный интервал.
Щелкните на кнопке Change Schedule (Изменить расписание). Откроется окно Schedule (Расписание) с расписанием работы связи (рис. 7.14).
Рис. 7.14. Окно Schedule (Расписание) для связи сайтов Phoenix -Houston. С помощью этого соединения репликация может выполняться круглые сутки семь дней в неделюРис. 7.14. Окно Schedule (Расписание) для связи сайтов Phoenix -Houston. С помощью этого соединения репликация может выполняться круглые сутки семь дней в неделю
Рис. 7.14. Окно Schedule (Расписание) для связи сайтов Phoenix -Houston. С помощью этого соединения репликация может выполняться круглые сутки семь дней в неделю
Рис. 7.14. Окно Schedule (Расписание) для связи сайтов Phoenix -Houston. С помощью этого соединения репликация может выполняться круглые сутки семь дней в неделю
Если соединение доступно только в определенное время, очистите синие интервалы, в течение которых подключение недоступно. Воспользуйтесь этим окном, чтобы настроить расписание для низкоскоростных соединений, на которые в определенное время выпадает пиковая нагрузка, и поэтому нежелательно, чтобы репликация повышала эту нагрузку.
Настраивая интервалы репликации, не забывайте, что эти интервалы напрямую влияют на величину задержек при распространении изменений.
Щелкните на кнопке OK, чтобы сохранить установленные параметры и вернуться в окно Properties (Свойства).
Чтобы вернуться на консоль, щелкните на кнопке ОК.
Закройте консоль.
Теперь создайте объекты Site Link для всех остальных соединений между сайтами.
Выбор связующих серверов
При автоматической настройке средство проверки согласованности знаний (КСС) может выбрать в качестве связующих серверы, которые не являются самыми производительными контроллерами домена в пределах сайта. Кроме этого, может быть выбран связующий сервер, который не является сервером глобального каталога. В таком случае придется создавать дополнительные соединения для обеспечения репликации глобального каталога между сайтами.
Создав список предпочтительных связующих серверов, можно уменьшить сложность репликации между сайтами и увеличить производительность. Важно назначить несколько предпочтительных связующих серверов, чтобы отказ одного сервера не привел к нарушению репликации между сайтами. В процедуре 7.7 рассматривается выбор связующих серверов.
Процедура 7.7. Выбор связующих серверов
1.
2.
3.
Откройте консоль Active Directory — Sites and Sevices (Active Directory — сайты и службы). Раскройте дерево, чтобы получить доступ к объекту Server для контроллера домена, который будет назначен в качестве связующего сервера.
Щелкните правой кнопкой мыши на объекте Server и выберите пункт Properties (Свойства) из контекстного меню. Откроется окно Properties (Свойства), которое показано на рис. 7.15.
tMwUon I ЕмпНаде t
ржвюЗобГ Sww8l*nK.
IjDrsebto recursion
■vjBlND secondaries
□Fai on load if bad zone data
У|ЕпаЫе round robin
Enable netmask ordering ^Secure cache agarrat polution
(млЕлщтрвГ
UMWMdataonaMw:{FromActive Directory and registry
P1 €mifc«iiei6*iceiwflfcigefii*ie6e*
и
ReeetioDdeA |
Cared I Ap*
Рис. 7.15. Окно свойств сервера, в котором показан транспортный механизм для данного предпочтительного связующего сервера
В качестве транспортного механизма выберите IP и щелкните на кнопке Add (Добавить) для его перемещения на панель окна связующего сервера.
Щелкните на кнопке ОК для сохранения изменений.
В поле Computer будет показан объект Computer, связанный с объектом Server, который используется для управления репликацией. Эти имена всегда должны совпадать.
Связующие серверы и брандмауэры
Еще одной причиной создания списка предпочтительных связующих серверов является настройка репликации через брандмауэр. Назначая сервер для выполнения репликации между сайтами, можно настроить брандмауэр на передачу данных только от этого сервера.
Существует возможность указать порт, который используется связующим сервером. Это необходимо для настройки репликации через брандмауэр. Для указания этого порта используется следующая запись в системном реестре:
Раздел:HKLM\System\CurrentControlSet\Services\NTDS\Parameters
Запись: TCP/IP Port
Значение: <номер_порта>,
Создание мостов связей сайтов
После создания связей сайтов и использования системы в реальных условиях может оказаться, что связующие серверы требуют дополнительной информации о сети для эффективного планирования репликации. Для этого придется создать специальные объекты Site Link Bridge, которые описывают предпочтительные маршруты. В процедуре 7.8 рассматривается отключение глобальных мостов связей сайтов и создание объектов Site Link Bridge.
Процедура 7.8. Создание объектов Site Link Bridge
Откройте консоль Active Directory — Sites and Services (Active Directory — сайты и службы).
Щелкните правой кнопкой на объекте IP и выберите из контекстного меню команду Properties (Свойства). Откроется окно IP Properties, показанное на рис. 7.16.
Сбросьте флажок Bridge All Site Links (Создать мосты для всех связей сайтов). Это приведет к отключению глобальных мостов связей сайтов.
Щелкните правой кнопкой мыши на объекте IP и из контекстного меню выберите команду New Site Link Bridge (Создать мост связей сайтов). Откроется окно New Object — Site Link Bridge (Новый объект — Мост связей сайтов), показанное на рис. 7.17.
Выберите связи, которые составляют предпочтительный маршрут, и щелкните на кнопке Add (Добавить), чтобы добавить связи в список.
Щелкните на кнопке ОК, чтобы сохранить изменения и вернуться на консоль. Объект Site Link Bridge будет добавлен в список связей IP.
Обратите внимание на журнал событий и состояние объектов Connection. Следите за ними в течение следующих нескольких часов, что позволит определить, как средство проверки согласованности знаний отреагировало на изменение.
Необходимо убедиться, что контроллеры домена эффективно рассылают обновления с помощью репликации. Этим должны заниматься связующие серверы.
9 Domain[serverl.company.com]9 Ш DC-company,DC-com9 LJ CN-Buitin:*! -J CN-Computers®LJ OU-Domain Controlers® СЗ CN—ForeignSecurityPrindpals$ 2J CN-LostAndFound$• 2] CN-System* -J ■■В ^ Configuration[serverl.company.com]3 О CN-Configwation, DC-company, DC-com @23 CN-DisplaySpedflers3 23 CN-Extended-Rights3 '2] CN-ForestUpdates@ 23 CN-LostAndFoundConfigSJ 21 CN-Parttions3 ^ CN-Phy$teal Locations3 Cl CN-ServicesS 23 CN-Sites$ 23 CN-WeKnown Security Principals9 ^ Schema [serveri .company.com]•2J CN-SchemajCN-Configur^aon.DC-company9 Domain[serverl.company.com]9 Ш DC-company,DC-com9 LJ CN-Buitin:*! -J CN-Computers®LJ OU-Domain Controlers® СЗ CN—ForeignSecurityPrindpals$ 2J CN-LostAndFound$• 2] CN-System* -J ■■В ^ Configuration[serverl.company.com]3 О CN-Configwation, DC-company, DC-com @23 CN-DisplaySpedflers3 23 CN-Extended-Rights3 '2] CN-ForestUpdates@ 23 CN-LostAndFoundConfigSJ 21 CN-Parttions3 ^ CN-Phy$teal Locations3 Cl CN-ServicesS 23 CN-Sites$ 23 CN-WeKnown Security Principals9 ^ Schema [serveri .company.com]•2J CN-SchemajCN-Configur^aon.DC-company»a2j CN-Administrator CJcn-branch# O CN-Cert Pubishers U CN-DHCP Administrators CJ CN-DHCP Users м3 CN-DnsAdmins CJ CN-DnsUpdateProxy ^CN-Domaln Admins LJ CN-Domain Computers 23 CN-Domain controlers 23 CN-Domain Guests LJ CN-Domain Users 21 CN-Enterprise Admins»a2j CN-Administrator CJcn-branch# O CN-Cert Pubishers U CN-DHCP Administrators CJ CN-DHCP Users м3 CN-DnsAdmins CJ CN-DnsUpdateProxy ^CN-Domaln Admins LJ CN-Domain Computers 23 CN-Domain controlers 23 CN-Domain Guests LJ CN-Domain Users 21 CN-Enterprise Adminsgroup group groupgroup group group group group group groupgroup group groupgroup group group group group group groupG3CN-<koupPo*cy Creator Own.,. groupG3CN-<koupPo*cy Creator Own.,. groupillillGJCN—Guest21 CN-HdpA$sistant_0f579e C2 CN-HelpServkesGroup GJCN-krbtgt■□ CN—RAS and IAS Servers 23CN-Schema Admins 23CN-SU85IDIARY$23 CN-SUPPORT_388945aO £jCN-WIN5 UsersGJCN—Guest21 CN-HdpA$sistant_0f579e C2 CN-HelpServkesGroup GJCN-krbtgt■□ CN—RAS and IAS Servers 23CN-Schema Admins 23CN-SU85IDIARY$23 CN-SUPPORT_388945aO £jCN-WIN5 UsersgroupgroupgroupgroupgroupgroupCN-Administrator, CN-Users, DC-comparr CN-BRANCH$,CN-Users,DC-company,Di . CN-Cert Publishers,CN-Users,DC-compa ? CN-DHCP Administrators,CN-Users,DC-c ' CN-DHCP Users,CN-Users,DC-company CN-DnsAdmins,CN—Users,DC-company,r CN-DnsUpdateProxy, CN-Users, DC-comf... CN=Domain Admins,CN-Users,DC-compa CN-Domain Corrvuters,CN-Users,DC-coi . CN-Domain Controllers,CN-Users,DC-cot CN-Domain Guests,CN-Users,DC-compa ' CN-Domain Users,CN-Users,DC-compan , CN-Enterprlse Admins,CN-Users,DC-corr CN-Group Policy Creator Owners, CN-Use CN=Guest,CN-Users,DC=company,DC=c ; CN-He^A$sistant_Of579e,CN-Users,DC- " CN—HelpServicesGroup,CN—Users,DC=coi CN=krbtgt,CN-Users,DC=company,DC=c CN—RAS and IAS Servers,CN-Users,DC=i CN=5chema Admins,CN-Users,DC-comp4 CN-5LB5IDIARY$,CN-Users,DC-compand CN-5UPPORT_388945aO,CN-Users,DC-c. COWINS Users,CN=Users,DC=comDanv^|CN-Administrator, CN-Users, DC-comparr CN-BRANCH$,CN-Users,DC-company,Di . CN-Cert Publishers,CN-Users,DC-compa ? CN-DHCP Administrators,CN-Users,DC-c ' CN-DHCP Users,CN-Users,DC-company CN-DnsAdmins,CN—Users,DC-company,r CN-DnsUpdateProxy, CN-Users, DC-comf... CN=Domain Admins,CN-Users,DC-compa CN-Domain Corrvuters,CN-Users,DC-coi . CN-Domain Controllers,CN-Users,DC-cot CN-Domain Guests,CN-Users,DC-compa ' CN-Domain Users,CN-Users,DC-compan , CN-Enterprlse Admins,CN-Users,DC-corr CN-Group Policy Creator Owners, CN-Use CN=Guest,CN-Users,DC=company,DC=c ; CN-He^A$sistant_Of579e,CN-Users,DC- " CN—HelpServicesGroup,CN—Users,DC=coi CN=krbtgt,CN-Users,DC=company,DC=c CN—RAS and IAS Servers,CN-Users,DC=i CN=5chema Admins,CN-Users,DC-comp4 CN-5LB5IDIARY$,CN-Users,DC-compand CN-5UPPORT_388945aO,CN-Users,DC-c. COWINS Users,CN=Users,DC=comDanv^|
9 Domain[serverl.company.com]
9 Ш DC-company,DC-com
9 LJ CN-Buitin
:*! -J CN-Computers
®LJ OU-Domain Controlers
® СЗ CN—ForeignSecurityPrindpals
$ 2J CN-LostAndFound
$• 2] CN-System
* -J ■■
В ^ Configuration[serverl.company.com]
3 О CN-Configwation, DC-company, DC-com @23 CN-DisplaySpedflers
3 23 CN-Extended-Rights
3 '2] CN-ForestUpdates
@ 23 CN-LostAndFoundConfig
SJ 21 CN-Parttions
3 ^ CN-Phy$teal Locations
3 Cl CN-Services
S 23 CN-Sites
$ 23 CN-WeKnown Security Principals
9 ^ Schema [serveri .company.com]
•2J CN-SchemajCN-Configur^aon.DC-company
9 Domain[serverl.company.com]
9 Ш DC-company,DC-com
9 LJ CN-Buitin
:*! -J CN-Computers
®LJ OU-Domain Controlers
® СЗ CN—ForeignSecurityPrindpals
$ 2J CN-LostAndFound
$• 2] CN-System
* -J ■■
В ^ Configuration[serverl.company.com]
3 О CN-Configwation, DC-company, DC-com @23 CN-DisplaySpedflers
3 23 CN-Extended-Rights
3 '2] CN-ForestUpdates
@ 23 CN-LostAndFoundConfig
SJ 21 CN-Parttions
3 ^ CN-Phy$teal Locations
3 Cl CN-Services
S 23 CN-Sites
$ 23 CN-WeKnown Security Principals
9 ^ Schema [serveri .company.com]
•2J CN-SchemajCN-Configur^aon.DC-company
»a
2j CN-Administrator CJcn-branch# O CN-Cert Pubishers U CN-DHCP Administrators CJ CN-DHCP Users м3 CN-DnsAdmins CJ CN-DnsUpdateProxy ^CN-Domaln Admins LJ CN-Domain Computers 23 CN-Domain controlers 23 CN-Domain Guests LJ CN-Domain Users 21 CN-Enterprise Admins
»a
2j CN-Administrator CJcn-branch# O CN-Cert Pubishers U CN-DHCP Administrators CJ CN-DHCP Users м3 CN-DnsAdmins CJ CN-DnsUpdateProxy ^CN-Domaln Admins LJ CN-Domain Computers 23 CN-Domain controlers 23 CN-Domain Guests LJ CN-Domain Users 21 CN-Enterprise Admins
group group group
group group group group group group group
group group group
group group group group group group group
G3CN-<koupPo*cy Creator Own.,. group
G3CN-<koupPo*cy Creator Own.,. group
ill
ill
GJCN—Guest
21 CN-HdpA$sistant_0f579e C2 CN-HelpServkesGroup GJCN-krbtgt
■□ CN—RAS and IAS Servers 23CN-Schema Admins 23CN-SU85IDIARY$
23 CN-SUPPORT_388945aO £jCN-WIN5 Users
GJCN—Guest
21 CN-HdpA$sistant_0f579e C2 CN-HelpServkesGroup GJCN-krbtgt
■□ CN—RAS and IAS Servers 23CN-Schema Admins 23CN-SU85IDIARY$
23 CN-SUPPORT_388945aO £jCN-WIN5 Users
group
groupgroup
group
groupgroup
CN-Administrator, CN-Users, DC-comparr CN-BRANCH$,CN-Users,DC-company,Di . CN-Cert Publishers,CN-Users,DC-compa ? CN-DHCP Administrators,CN-Users,DC-c ' CN-DHCP Users,CN-Users,DC-company CN-DnsAdmins,CN—Users,DC-company,r CN-DnsUpdateProxy, CN-Users, DC-comf... CN=Domain Admins,CN-Users,DC-compa CN-Domain Corrvuters,CN-Users,DC-coi . CN-Domain Controllers,CN-Users,DC-cot CN-Domain Guests,CN-Users,DC-compa ' CN-Domain Users,CN-Users,DC-compan , CN-Enterprlse Admins,CN-Users,DC-corr CN-Group Policy Creator Owners, CN-Use CN=Guest,CN-Users,DC=company,DC=c ; CN-He^A$sistant_Of579e,CN-Users,DC- " CN—HelpServicesGroup,CN—Users,DC=coi CN=krbtgt,CN-Users,DC=company,DC=c CN—RAS and IAS Servers,CN-Users,DC=i CN=5chema Admins,CN-Users,DC-comp4 CN-5LB5IDIARY$,CN-Users,DC-compand CN-5UPPORT_388945aO,CN-Users,DC-c. COWINS Users,CN=Users,DC=comDanv^|
CN-Administrator, CN-Users, DC-comparr CN-BRANCH$,CN-Users,DC-company,Di . CN-Cert Publishers,CN-Users,DC-compa ? CN-DHCP Administrators,CN-Users,DC-c ' CN-DHCP Users,CN-Users,DC-company CN-DnsAdmins,CN—Users,DC-company,r CN-DnsUpdateProxy, CN-Users, DC-comf... CN=Domain Admins,CN-Users,DC-compa CN-Domain Corrvuters,CN-Users,DC-coi . CN-Domain Controllers,CN-Users,DC-cot CN-Domain Guests,CN-Users,DC-compa ' CN-Domain Users,CN-Users,DC-compan , CN-Enterprlse Admins,CN-Users,DC-corr CN-Group Policy Creator Owners, CN-Use CN=Guest,CN-Users,DC=company,DC=c ; CN-He^A$sistant_Of579e,CN-Users,DC- " CN—HelpServicesGroup,CN—Users,DC=coi CN=krbtgt,CN-Users,DC=company,DC=c CN—RAS and IAS Servers,CN-Users,DC=i CN=5chema Admins,CN-Users,DC-comp4 CN-5LB5IDIARY$,CN-Users,DC-compand CN-5UPPORT_388945aO,CN-Users,DC-c. COWINS Users,CN=Users,DC=comDanv^|
Рис. 7.16. Окно IP Properties, в котором можно включить глобальное создание мостов связей сайтов
^7" ^
Puc. 7.17. Окно New Object — Site Link Bridge
Управление параметрами репликации
Принятые по умолчанию интервалы репликации, установленные объектом NTDS Site Settings, достаточны для выполнения большинства операций. В этом разделе рассматривается изменение стандартного интервала репликации для более точной настройки системы. Кроме этого, здесь показано, как" принудительно запустить репликацию для ускорения отправки изменений.
Настройка интервалов репликации
При обновлении копии контекста именования контроллер домена уведомляет партнеров по репликации, чтобы они могли загрузить обновленную копию. По умолчанию используется интервал уведомления, равный пяти минутам. Контроллер домена отправляет уведомление одному из партнеров по репликации и ожидает ответа в течение 30 секунд перед тем, как отправить уведомление следующему партнеру по репликации.
Интервалы уведомлений определяются двумя записями в разделе системного реестра HKLM\System\CurrentControlSet\NTDS\Parameters:
Replicator notify pause after modify (secs) — ЗООсекунд;
Replicator notify pause between DSAs (secs) —30секунд.
Если необходимо использовать более короткий интервал уведомления, можно уменьшить значение записи Replicator notify pause after modifу, но при этом нужно следить за нагрузкой на контроллеры домена.
Кроме уведомлений об обновлениях, контроллеры домена выполняют репликацию через фиксированные интервалы времени. Фиксированные интервалы используются для проверки работоспособности соединений. Значение фиксированного интервала уведомления устанавливается в свойствах объекта Connection.
Изменение расписания и частоты опроса при межсайтовой репликации
По умолчанию при межсайтовой репликации для опроса выделяется 15-минутное окно каждые три часа. Интервал определяется значением атрибута объекта Site Link. Интервал можно изменить с помощью консоли Active Directory — Sites and Services (Active Directory — сайты и службы), как, например, показано на рис. 7.18. Минимальный интервал составляет 15 минут.
Рис. 7.18. В свойствах объекта Site Link отображается заданный интервал репликации
Принятое по умолчанию расписание репликации подразумевает репликацию в любой момент времени. Расписание можно изменить и разрешить репликацию только в определенные периоды времени. Например, можно отложить репликацию до окончания рабочего дня.
Интервал устанавливается с помощью другого атрибута объекта Site Link. Если щелкнуть на кнопке Change Schedule (Изменить расписание), откроется окно Schedule (Расписание) с расписанием репликации. Можно создать такое расписание, при котором определенный сайт окажется “забытым” при репликации. Такая ситуация возникает в случае, если расписания репликации различных связей не пересекаются. Если возникла связанная с расписанием проблема, то все расписания можно отключить, установив флажок Ignore Schedules (Игнорировать расписание) в окне свойств объекта для транспортного протокола IP или SMTP.
Принудительная репликация
Если определенное обновление необходимо реплицировать раньше, чем закончится интервал репликации, можно провести принудительную репликацию. Один из способов заключается в использовании консоли Active Directory — Sites and Services (Active Directory — сайты и службы), как показано в процедуре 7.9.
Процедура 7.9. Запуск принудительной репликации с помощью консоли Active Directory — Sites and Services (Active Directory — сайты и службы)
Рас крюйте дерево для доступа к серверу, на который нужно реплицировать обновление. 1 Помните, что соединения отображают входящие потоки данных.1
Найдите объект NTDS Settings и связанные с ним объекты Connection в разделе I нужного сервера.|
11Щелкните правой кнопкой мыши на соединении с партнером по репликации и выберите 1 из контекстного меню команду Replicate Now (Реплицировать сейчас). Будет выдано со- | общение о начале репликации. Если соединение неработоспособно, будет выдано сообще- 1 ние о недоступности соединения RPC. Если соединение является межсайтовым, запрос на | репликацию будет поставлен в очередь.1
1
1
Завершение репликации можно проверить с помощью журнала событий. Кроме этого, 1 можно проверить свойства интересующего объекта и убедиться, что они изменились. Реп- I ликация не выполняется мгновенно, поэтому перед проверкой придется подождать не- 4 сколько минут.1
Если предпочтение отдается утилитам с интерфейсом командной строки, принудитель- I ную репликацию можно запустить с помощью утилиты repadmin, воспользовавшись еле- 1 дующей командой:1
repadmin /syncall <агент DSA> <контекст именования>■
Вместо < агент DSA> необходимо указать полностью определенное доменное имя того сер- ■ вера, на который должны реплицироваться изменения. Вместо <контекст именование Я необходимо указать характерное имя контекста именования, который необходимо реплици- Я ровать, например:Я
repadmin /syncall dc-01.company.com dc=company,dc=comЯ
Диагностика проблем соединений RPC
Внутрисайтовая репликация выполняется по безопасным соединениям RPC. Отказ соединения RPC может привести к появлению в журнале событий сообщений об ошибке, например There are no more endpoints available from the RPC Endpoint Mapper .
Обычно такая проблема вызвана отказом сетевых аппаратных средств, например отказом коммутатора, повреждением таблицы маршрутизации или отказом сетевого адаптера. Кроме этого, проблема может быть вызвана другим приложением RPC, которое решило вмешаться в работу службы RPC Endpoint Mapper и воспользоваться выделенными для нее ТСР-портами. Служба Microsoft RPC Runtime случайным образом выбирает TCP-порты с номерами выше 1024. Если другой процесс попытается воспользоваться этим портом, при попытке репликации возникнет ошибка.
Еще одной причиной проблемы отказа RPC является ошибка в работе службы RPC Locator. Эта служба использует ТСР-порт 135 для доступа к серверу RPC. Иногда другое приложение пытается использовать ТСР-порт 135 и вмешивается в работу службы RPC Locator. Но чаще всего недоступность этого порта связана с действиями администратора брандмауэра.
Если предполагается, что проблема связана с работой службы RPC Locator, попытайтесь воспользоваться утилитами Rpcping, которые предоставляются в составе Resource Kit. Изначально эти утилиты предназначены для использования вместе с Exchange, но они оказались полезными и для Active Directory.
Существует два компонента утилит Rpcping, предназначенных для отслеживания RPC-соеди- нений. На сервере с помощью команды Rpings32 необходимо запустить RPC Listener. На клиенте необходимо сгенерировать запросы RPC, воспользовавшись командой Rpings и указав полностью определенное доменное имя сервера. Если будет получен ответ на запрос, значит, служба RPC Locator на клиентском компьютере работает, а на сервере правильно настроена служба RPC Runtime.
Если на запрос rpings ответа не последует, проверьте сетевые соединения и их настройки. Попытайтесь перезагрузить сервер. Возможно, проблема связана с драйвером сетевого адаптера, поэтому всегда используйте самый актуальный драйвер.
Специальные операции при репликации
После настройки сайтов и развертывания контроллеров домена дополнительных операций больше не требуется. Но может возникнуть несколько вопросов, которые требуют вмешательства администратора.
Создание соединений вручную
Если времени достаточно, средство проверки согласованности знаний (КСС) создает топологию внутрисайтовой репликации, которая обеспечивает максимальную скорость сходимости изменений. Генератор межсайтовой топологии (ISTG) выполняет ту же функцию для межсайтовой репликации.
Если отказывает контроллер домена, средству проверки согласованности знаний может потребоваться некоторое время для обнаружения проблемы и начала работы по исправлению кольца репликации. Если средство проверки согласованности знаний или генератор межсайтовой топологии не может вовремя отреагировать на отказ контроллера домена, приходится вмешиваться администратору и создавать соединение вручную.
При создании соединения вручную администратор вмешивается в автоматическую работу средства проверки согласованности знаний. Это не всегда плохо. Если администратор совершит ошибку, сеть не пострадает. Но в результате действий администратора контроллер домена может столкнуться с неожиданными проблемами при репликации. Внимательно планируйте каждое свое вмешательство.
Перемещение объектов между сайтами
Иногда персонал центрального отдела информационных технологий создает сервер для удаленного офиса и передает сервер в управление локальному техническому персоналу. В процессе повышения контроллера домена локальный IP-адрес сервера определяет принадлежность к сайту. Иногда в результате контроллер домена должен находиться на другом сайте.
Если на контроллере домена изменить параметры сети IP или создать новый сайт, который соответствует назначенной подсети IP контроллера домена, объект Server, а также соответствующие объекты Connection и NTDS Settings необходимо перенести в контейнер нового сайта. Для этого можно воспользоваться консолью Active Directory — Sites and Services (Active Directory — сайты и службы). Перетащите объект сервера в контейнер Server на новом сайте.
После перемещения объекта предоставьте средству проверки согласованности знаний достаточно времени для создания новой топологии репликации и измените транспортный механизм с высокоскоростного протокола RPC на низкоскоростной протокол RPC. Если по- рытаться принудительно запустить репликацию до завершения работы средства проверки согласованности знаний, будет выдано сообщение об ошибке. Подождите как минимум полчаса (два интервала средства проверки согласованности знаний) и повторите попытку репликации. Если и это не даст положительного результата, проверьте содержимое журнала событий. В журнале может присутствовать сообщение об ошибке, показанное на рис. 7.19.
Event PropertiesEvent PropertiesЙ1Г ЛИГ
Event Properties
Event Properties
Event |
Dueaet/ахв Sone NTD6 КС
Tree11:Ю21АМСаЬдо КжЫйСтЫап»
ТдеесW*np Event И): 1325
UterNTMfTHORnYVWDNWDUSLDQON
ComputerSERVER!
Deeaiptiore .2
The attempt to «rtriifah амйм^^У*
Pwttton: ОСчоатрау^Ома Wrtabte. TRUE SotfceDSAON: C№*T06 5e6ingiX>^ERVER1CUX-'6wvmJ>H)tf^ NwtejBMIwirNeCwifauHienXtotowiipw^^
оомрмуюдп Intoi* Transport @we*XI
SllSBliiliBisliiilil^I
и
I.. I c—< i ■■ - ii
Puc. 7.19. Запись в журнале событий о невозможности создать соединение с помощью средства проверки согласованности знаний
Если выдается ошибка соединения, удостоверьтесь, что сайт случайно не связан с другой подсетью IP. Проверьте службу DNS и убедитесь, что записи SRV находятся в соответствующих зонах и сервер настроен на использование работоспособной службы DNS. Кроме этого, если это единственный контроллер домена в пределах нового сайта, он становится одновременно и связующим сервером, и генератором межсайтовой топологии. Автоматическая настройка этой функциональной возможности также занимает некоторое время.
Управление топологией репликации вручную
При создании соединений с помощью средства проверки согласованности знаний (КСС)' в качестве конечных точек выбираются два контроллера домена и объект Connection помещается в контейнер NTDS Settings, соответствующий этим серверам. Объекты Connection всегда представляют входящие потоки данных. Источник входящих данных для объекта Connection изменить нельзя, но можно изменить партнера по репликации.
При создании соединений вручную убедитесь, что контроллер домена не создает цикл репликации и конечная точка подключения не является контроллером домена, который не имеет непосредственной связи с другими контроллерами доменов, хранящими копию того же контекста именования.
Кроме этого, средство проверки согласованности знаний не будет удалять созданные вручную соединения при добавлении новых контроллеров домена в кольцо репликации или при отключении существующих контроллеров домена. Администратору придется самостоятельно менять топологию.
При управлении топологией репликации вручную у администратора есть два варианта действий: выбрать нового партнера по репликации для соответствующего соединения или создать новый объект Connection.
Выбор нового партнера по репликации
Выбор нового партнера по репликации рассматривается в процедуре 7.10.
Процедура 7.10. Выбор нового партнера по репликации
Откройте консоль Active Directory — Sites and Services (Active Directory — сайты и службы).
Раскройте дерево для доступа к интересующему серверу и выделите пункт NTDS Settings.
Дважды щелкните на объекте Connection, соответствующем контроллеру домена, параметры которого необходимо изменить. При этом откроется окно со свойствами соединения (рис. 7.20).
Рис. 7.20. Окно свойств для автоматически созданного соединения, в котором указан партнер по репликации
В разделе Replicate From (Реплицировать с) указаны имя партнера по репликации, название сайта партнера и домены, репликация которых выполняется с этого партнера. В этом примере интересующий сервер находится в домене Subsidiary. com и не является сервером глобального каталога, поэтому другие контексты именования не реплицируются.
Щелкните на кнопке Изменить (Change) в разделе Replicate From (Реплицировать с). Откроется окно Find Domain Controllers (Найти контроллеры домена). Если лес имеет достаточно сложную структуру, открывшийся список может оказаться весьма большим.
Выполните двойной щелчок на записи для контроллера домена, который станет новым партнером по репликации. После этого окно закроется и управление вернется в окно свойств. Новый партнер по репликации будет указан в поле Server.
Щелкните на кнопке ОК для сохранения изменений и закрытия окна. Агент репликации каталога обнаружит изменения и начнет репликацию с новым партнером. Если это межсайтовое соединение, то до начала репликации может пройти некоторое время.
Создание нового соединения
При создании нового соединения между контроллерами домена выполните последовательность действий, описанную в процедуре 7.11.
Процедура 7.11. Создание нового объекта Connection
Откройте консоль Active Directory — Sites and Services (Active Directory — сайты и службы).
Раскройте дерево и откройте контейнер NTDS Settings, соответствующий серверу, для которого необходимо создать подключение. В этом контейнере должен быть как минимум объект Connection, называющийся outomatically generated>. Этот объект создан средством проверки согласованности знаний.
Щелкните правой кнопкой мыши на объекте NTDS Settings и из контекстного меню выберите пункт New NT DS Connection. Откроется окно Find Domain Controllers (Найти контроллеры домена).
Выберите контроллер домена, с которым необходимо создать подключение. Помните, что объект Connection всегда представляет входящий поток данных.
Щелкните на кнопке ОК. Откроется окно New Object— (Connection) (Новый объект — Соединение). Имя выбранного контроллера домена указывается в поле Name (Имя).
Щелкните на кнопке ОК, чтобы сохранить внесенные изменения и вернуться на консоль. Новый объект Connection появится в списке. Обратите внимание на содержимое журнала событий. Агент репликации каталога должен “увидеть” новое соединение и начать репликацию с его помощью. Для просмотра этих событий может потребоваться включение диагностики Active Directory. Дополнительная информация по этому вопросу приводится в следующем разделе.
Диагностика проблем в процессе репликации
Репликация службы Active Directory состоит из последовательности сложных транзакций. Если одна из транзакций завершится неудачно, возникнут, мягко говоря, сложные проблемы. В общем, проблемы при репликации обычно вызываются нестабильными аппаратными средствами сервера, ненадежными сетевыми соединениями и ошибками в работе службы DNS.
Обычно при нарушении репликации в журнал событий добавляются соответствующие сообщения. В сообщениях описывается причина отказа, но не всегда причина отказа является причиной проблемы. Существует несколько инструментов, которые позволяют получить дополнительную информацию. К таким инструментам можно отнести следующие.
Специальные диагностические утилиты, которые заносят сведения в журнал событий
Утилита управления репликацией из командной строки, repadmin
Утилита Graphical Replication Monitor, replmon
Кроме этого, обратите внимание на проблемы в работе других служб, которые зависят от Active Directory. Это касается служб, учетные записи которых должны проходить аутентификацию в домене.
Записи реестра для диагностики работы службы каталогов
Один из инструментов диагностики проблем при репликации находится в системном реестре. Несколько записей в разделе HKLM\System\CurrentControlSet\Services\NTDS\ Diagnostics позволяют включить сохранение информации в журнале событий. Существует три возможных значения каждой записи (кроме значения 0, которое отключает диагностический инструмент).
1 — отчет минимального размера
3 — отчет среднего размера
5 — полный отчет
В полном отчете предоставляется максимальный объем информации, но на активно работающем сервере такой отчет быстро заполняет журнал службы каталогов. В этом нет ничего плохого, но при таком объеме информации можно пропустить важный фрагмент данных.
Содержимое журнала событий может быть экспортировано в форматы CSV и ТХТ с последующим импортом в базу данных или электронную таблицу. В меню Eveng Log (Журнал) выберите команду File^Save As (Файл ^Сохранить как), после чего выберите тип файла и каталог, в котором необходимо сохранить экспортируемый журнал.
Кроме этого, существует пункт меню Export (Экспорт), но он предоставляет те же возможности, что и пункт Save As (Сохранить как). Можно воспользоваться и программой из состава Resource Kit, которая называется Dumpel. Эта программа работает с тремя стандартными журналами: журналом приложений, журналом безопасности и системным журналом. На момент написания книги программа Dumpel не работала с журналом службы каталогов или журналом репликации файлов.
Использование утилиты repadmin
Компания Microsoft предоставляет в составе Resource Kit утилиту Replication Administrator, repadmin, которая предназначена для управления внутренними механизмами репликации. Графическая утилита Replmon предоставляет практически ту же информацию. Дополнительная информация об использовании утилиты с графическим интерфейсом приводится в разделе “Использование Replmon” далее в этой главе.
Справочное руководство, доступное с помощью команды repadmin /?, содержит информацию о доступных параметрах этой утилиты. Рассмотрим краткий список терминов и правил, которыми оперирует утилита.
DSA в терминологии Х.500 расшифровывается как Directory Services Agent (агент служб каталога). Контроллер домена Active Directory является агентом служб каталога.
■ Указывайте полностью определенное доменное имя агента служб каталога, напрИмер dc-01.branch.company.com.
■ GUID — это глобально уникальный идентификатор. Идентификатор представляет собой строку октетов, которая назначается контроллеру домена. Контроллер домена обычно имеет два глобально уникальных идентификатора: глобально уникальный идентификатор объекта и глобально уникальный идентификатор вызова (invocation). Глобально уникальный идентификатор объекта соответствует самому агенту служб каталога. Глобально уникальный идентификатор вызова соответствует копии базы данных Active Directory, которая хранится на агенте служб каталога.
■ Контекст именования описывает один из разделов каталога, который хранится на агенте служб каталога. Только серверы глобального каталога хранят копии контекстов именования всех доменов (копии предназначены только для чтения).
Object DN соответствует характерному имени выбранного объекта LDAP.
В некоторых отношениях функции утилиты Replication Administrator дублируют функции консоли Active Directory — Sites and Services (Active Directory — сайты и службы). Например, чтобы определить, настроен ли контроллер домена в качестве сервера глобального каталога, можно открыть консоль, перейти к объекту NTDS Settings соответствующего сервера и проверить свойства объекта. С другой стороны, можно открыть приглашение командной строки и ввести repadmin /options.
Стандартные функции утилиты repadmin
Консоль Active Directory — Sites and Services (Active Directory — сайты и службы) не предоставляет значительного объема информации, который предоставляет утилита repadmin. Ниже приводится список вопросов, на которые способна предоставить ответ утилита repadmin.
В каком состоянии находится согласованность знаний для кольца репликации?
repadmin /ксс
Consistency check on local host successful.
Какие результаты были получены от каждого партнера по репликации на последнее событие репликации (в листинге показаны результаты для контекста именования Schema на агенте служб каталога DC - 01)?'
repadmin /showreps
Phoenix\DC-01
DSA Options : IS_GC
objectGuid : 61d9fcd2-1172-lld3-b902-00c04f536a4d invocationlD: 61d9fcd2-1172-lld3-b902-00c04f536a4d
===== INBOUND neighbors ====================================== CN=Schema,CN=Configuration,DC=company,DC=com
Phoenix\DC-02
DEL:604ba650-124d-lld3-b903-00c04f536a4d via RPC
objectGuid: 85e37932-124d-lld3-b903-00c04f536a4d
Last attempt @ 2002-02-26 19:53.35 failed, result 1722: The RPC server is unavailable.
Last success @ 2002-02-25 17:45.37.
27 consecutive failure(s).
Phoenix\DC-03 via RPC
objectGuid: ce87aefl-1232-lld3-b903-00c04f536a4d
Last attempt @ 2002-02-26 19:53.35 was successful.
Atlanta\DC-04 via IP
objectQuid: fba7a044-1176-lld3-b903-00c04f536a4d
Last attempt @ 2002-02-26 19:53.35 was successful.
= === OUTBOUND NEIGHBORS FOR CHANGE NOTIFICATIONS ============
CN=Schema,CN=Configuration,DC=company,DC=com
Phoenix\DC-05 via RPC
objectGuid: fba7a044-1176-lld3-b903-00c04f536a4d
Без соединения система может сообщать только идентификатор GUID отказавшего партнера по репликации, но не его имя. Можно получить список идентификаторов GUID контроллеров домена и выяснить, какой из контроллеров отказал. Можно заглянуть в журнал событий, так как в сообщениях указывается идентификатор GUID для сервера, который привел к возникновению ошибки. Результат использования параметра showreps в пределах сайта с большим количеством контроллеров домена может оказаться слишком сложным для интерпретации. Для просмотра только тех контроллеров домена, которые не приняли участие в репликации, воспользуйтесь параметром /unreplicated.
Расширенные функции утилиты repadmin
Операционная система Windows Server 2003 предоставляет множество дополнительных функций, которые доступны с помощью утилиты repadmin. Справочная информация по этим функциям доступна после ввода команды repadmin /experthelp. Ниже приведен пример такого листинга.
Expert Help)
/add <Naming Context> <Dest DC> <Source DC> [/asyncrep] [/syncdisable]
[/dsadn:<Source DC DN>] [/transportdn:<Transport DN>] [/mail]
[/async] [/readonly]
/mod <Naming Context> <Dest DC> <Source GUID>
[/readonly] [/srcdsaaddr:<dns address>]
[/transportdn:<Transport DN>]
[+nbrflagoption] [-nbrflagoption]
/delete <Naming Context> <Dest DC> [<Source DC Address>] [/localonly] [/nosource] [/async]
/removelingeringobjects <Dest_DC> <Source DC GUID> <NC> [/ADVISORY_MODE]
/addrepsto <NamingContext><DC><Reps-ToDC><Reps-ToDCGUID>
/updrepsto <NamingContext><DC><Reps-ToDC><Reps-ToDCGUID>.
/delrepsto <NamingContext><DC><Reps-ToDC><Reps-ToDCGUID>
/options [DC] [{+|-}IS_GC] [{+I-}DISABLE_INBOUND_REPL]
[ {+I -}DISABLE_OUTBOUND_REPL] [{+I -}DISABLE_NTDSCONN_XLATE]
/siteoptions [DC] [/site:<Site>] [{ + I -}IS_AUTO_TOPOLOGY_DISABLED]
[{+I -}IS_TOPL_CLEANUP_DISABLED] [{+I -}IS_TOPL_MIN_HOPS_DISABLED] [{+[-}IS_TOPL_DETECT_STALE_DISABLED]
[{+I -}IS_INTER_SITE_AUTO_TOPOLOGY_DISABLED]’
[{+I-}IS_GROUP_CACHING_ENABLED] [{+I -}FORCE_KCC_WHISTLER_BEHAVIOR]
/testhook [DC] [{+I-}lockqueue] [{+I-}link_cleaner]
[{+rpctime:<call_name>,<ip or hostname>,<seconds_to_run>|-rpctime)]
[{+rpcsync:<call_name>,<ip or hostname>I-rpcsync}]'
nbrflagoptions:
SYNC_ON_STARTUP DO_SCHEDULED_SYNCS TWO_WAY_SYNC
NEVER_SYNCED IGNORE_CHANGE_NOTIFICATIONS DISABLE_SCHEDULED_SYNC
COMPRESS_CHANGES NO_CHANGE_NOTIFICATIONS
Существуют две важные расширенные возможности утилиты repadmin. Первая позволяет удалять так называемые устаревшие объекты (lingering objects) из копии базы данных Active Directory. Устаревший объект может возникать в результате восстановления базы данных Active Directory, особенно если резервная копия старше, чем интервал сборки мусора, составляющий 60 дней.
Вторая возможность позволяет отключить сжатие при межсайтовой репликации. Для этого используется параметр -compress changes. Если для связующего сервера назначено несколько партнеров по репликации, например при топологии “звезда”, процессор связующего сервера может оказаться перегруженным запросами на сжатие пакетов репликации. Если внешнее соединение обладает достаточной пропускной способностью, то, отключив сжатие, можно значительно снизить нагрузку на центральный процессор связующего сервера.
Использование Replmon
Кроме утилиты с интерфейсом командной строки, repadmin, в составе Support Tools предоставляется утилита управления репликацией с графическим интерфейсом. Эта утилита называется Replication Monitor или Replmon.]
Утилита Replmon выводит на экран большой объем информации в очень удобном виде. Запуск j утилиты Rep Imon и выбор интересующего контроллера домена рассматриваются в процедуре 7.12. ]
Процедура 7.12. Настройка утилиты ReplmonI
Запустите утилиту Replication Monitor из меню Support Tools. Хотя утилита и не является | консолью ММС, она предоставляет такой же графический интерфейс и правила работы. 1
После открытия основного окна щелкните правой кнопкой мыши на пункте Monitored Servers 1 (Контролируемые серверы) и выберите команду Add Monitored Servers (Добавить сервер) из I контекстного меню. Запустится мастер Add Monitored Server Wizard (Добавление сервера). J
Выберите Search The Directory For The Server to Add (Искать сервер в каталоге). После | небольшой паузы, в течение которой сервер выполняет поиск в каталоге, в поле раскры- I вающегося списка вставляется имя домена, в котором находится сервер.1
Щелкните на кнопке Next (Далее). Откроется окно Add Server То Monitor (Добавить сер- I вер). В верхней панели показан список доступных сайтов в пределах леса. Раскройте дерево 1 и выберите сервер, дважды щелкнув на пиктограмме сервера. Кроме этого, можно щелкнуть 1 на кнопке Enter The Name Of The Server (Ввести имя сервера) в нижней части окна и ввести 1 имя интересующего сервера. В этом случае можно вводить “плоское” имя сервера.1
Если планируется контролировать сервер из другого домена и пользователь не зарегист- 1 рирован с правами администратора в соответствующем домене, выберите переключатель ■ Use Alternate Credentials (Использовать альтернативные аутентификационные данные), 1 щелкните на кнопке Change (Изменить) и введите подходящие аутентификационные дан- ■ ные для интересующего домена.I
Щелкните на кнопке Finish (Готово). Сервер будет добавлен в основное окно Replication Я monitor (Монитор репликации). Раскройте дерево, чтобы просмотреть контексты имено- ■ вания (рис. 7.21). Выделите один из серверов в пределах дерева, чтобы просмотреть жур- ■ нал репликации для этого соединения.■
Ниже приводится краткое описание информации, которая доступна в основном окне ути- ■ литы Replication Monitor (см. рис. 7.21).■
Контексты именования. Показан каждый контекст именования, который хранится на вы- ■ бранном сервере. Если сервер является сервером глобального каталога, в списке указыва- ■ ется каждый домен, входящий в лес. Если сервер является стандартным контроллером до- Я мена, в списке указываются контексты именования Domain, а также контексты именова- Я ния S с hema и С on f i gura t i on, полученные от корневого домена.Я
Active DireActive Dire;/ Ai Uve Direttory Replication Monitor
Active Dire
Active Dire
Mb e* *8* Ш h*
' jnerVofed Serov*.
E- fl Phoenix
E ^ DC01
® ф DC-companyDC=com
83 • CN^onfigusbonI)C-co(TipanyI)C=com
® ф CN-Schema^-Configuistion,DC-eompany.DC-ccfn
а ф DC*OomainDnsZonesJ)C-co(TipanyDC-com
® ф DC=ForestDnsZonesJ)C-co(npanyDC-com
Й-Ф DC-subsriiaryDC-com
Г»! ф DC=bfanchDC-companyJ)C*ccm
"Г Wife®"" FSKHl“
Рис. 721. Основное окно Replication Monitor, в котором показаны контексты именования на сервере DC-01
Партнеры по репликации. Дерево под каждым контекстом именования содержит входящие соединения от партнеров по репликации данного контекста именования. Имена рассортированы по сайтам и по “плоскому” имени сервера. В этом примере сервер DC - 01 имеет четырех партнеров по репликации контекстов именования Schema и Configuration.
Пиктограммы серверов. Пиктограмма в виде соединенной пары серверов соответствует партнеру по внутрисайтовой репликации. Пиктограмма сервера с изображением телефона соответствует партнеру по межсайтовой репликации. Пиктограмма с изображением небольшого персонального компьютера соответствует локальному серверу.
Записи журнала. В правой панели показана история событий при репликации с использованием выбранного соединения. Новые записи добавляются в конец журнала.
Совет по использованию системного реестра: параметры утилиты Replication Monitor
Параметры утилиты Replication Monitor (Монитор репликации) хранятся в следующем разделе системного реестра:
Раздел: HKCU\Sof twareWB and VBA Program Settings\Active Directory Replication Monitor\Settings
Запись: View Menu Options
Варианты просмотра отчетов с помощью Replmon
После настройки утилиты Replmon на мониторинг контроллера домена следует задать параметры просмотра. Для этого в меню View (Вид) выберите команду Options (Параметры). Откроется окно Active Directory Replicaton Monitor Options (Параметры монитора репликации Active Directory) на вкладке General (Общие), как показано на рис. 7.22.
Большинство параметров в этом окне не требуют дополнительных пояснений. В числе непонятных параметров можно назвать следующие.
Show Retired Replication Partners (Показать удаленных партнеров по репликации).
Этот параметр управляет отображением серверов, для которых уже установлена отметка на удаление, но которые еще не были удалены из базы данных. Такие объекты удаляются с течением времени. Утилита ntdsutil предоставляет возможность удалить метаданные и эти устаревшие записи из базы данных.
Show Transitive Replication Partners and Extended Data (Показывать транзитивных партнеров по репликации и расширенные данные). Этот параметр указывает утилите
Repl mon показывать порядковые номера обновлений и информацию метаданных для серверов, которые находятся за пределами локального сайта и мультиплексируются с помощью той же связи сайта.
Рис. 7.22. Окно Active Directory Replicaton Monitor Options (Параметры монитора репликации Active Directory)
Notify When Replication Fails After This Number Of Attempts (Уведомлять после ука- занного количества неудачных попыток репликации). Этот параметр вместе со значениями в группе Notification Options (Параметры уведомления) может использоваться для отправки сообщения по электронной почте в случае неудачной репликации с помощью выбранного подключения. Количество попыток должно быть в пределах от 3 до 5, что соответствует количеству отказов во время нормального режима работы.
Log Files (Файлы журналов). Этот параметр позволяет изменить место хранения файлов журнала, принятое по умолчанию. По умолчанию журнал расположен в каталоге Resource Kit.
Enable Debug Logging (Включить журнал отладки). Этот параметр предназначен для отладки утилиты Replmon, а не для отладки репликации. После включения отладочных событий большая часть информации о работе утилиты заносится в журнал приложений. При этом журнал событий заполняется достаточно быстро, поэтому данный параметр стоит использовать только для диагностики.
Свойства соединения
Открыв окно свойств соединения, можно получить доступ к дополнительной информации, которая касается данного соединения (рис. 7.23). На вкладке General (Общие) показаны тип соединения и информация о самом соединении. Важная статистическая информация ; приводится в последних трех строках. Здесь показано, удачно ли завершились попытки реп-’ ликации, и в противном случае отображается соответствующее сообщение об ошибке. '
На вкладке Update Sequence Numbers (Порядковый номер обновления) показан теку- j щий номер обновления, полученный от каждого партнера по репликации. Эта возможность 1
требует установки флажка Show Transitive Replication Partners and Extended Data (Показывать транзитивных партнеров по репликации и расширенные данные) в меню View (Вид).
На вкладке Flags (Флаги) отображаются конфигурационные параметры соединения. В этом примере показаны флаги, соответствующие стандартному межсайтовому соединению.
Рис. 7.23. Вкладка General (Общие) окна Properties (Свойства) для соединения
Параметры синхронизации копий
Щелкните правой кнопкой мыши на пиктограмме контекста именования и выберите из контекстного меню пункт Synchronize This Directory Partition With All Servers (Синхронизировать этот раздел каталога со всеми серверами). Откроется окно (рис. 7.24). Параметры, устанавливаемые в этом окне, позволяют изменить принятые по умолчанию правила работы при репликации.
Рис. 7.24. Окно Synchronizing Naming Context (Синхронизировать контекст именования со всеми серверами)
Disable Transitive Replication (Отключить транзитивную репликацию). По умолчанию < вся межсайтовая репликация выполняется с помощью принятой по умолчанию связи сай- j тов, а средство проверки согласованности знаний может создавать соединения между контроллерами домена, не обращая внимания на их принадлежность сайтам. При диагностике ; проблем, связанных с циклической репликацией или невозможностью репликации на on- j ределенный сервер, транзитивную репликацию можно отключить.j
Push Mode (Режим принудительной репликации). По умолчанию агент репликации каталога (DRA) запрашивает обновления у партнера по репликации. Этот параметр позво- ] ляет включить принудительную репликацию для следующей транзакции.I
Cross Site Boundaries (Пересекать границы сайта). Этот параметр позволяет непосред- 1 ственно запустить межсайтовую репликацию, но это эффективно только для RPC- I соединений. По умолчанию для межсайтовой репликации используется транспортный I протокол IP. В окне свойств соединения можно изменить транспортный механизм на RPC з и установить флажок Cross Site Boundaries. Если изменить транспортный механизм со- I единения, соединение становится статическим и требует управления вручную.1
Skip Initial Topology Check (Пропустить начальную проверку топологии). Этот пара- | метр позволяет ускорить репликацию по низкоскоростным сетям с большим количеством 1 контроллеров домена. Предполагается, что сервер (или соединение) находится в работо- 1 способном состоянии.j
Generate Fatal Error On Unreachable Server (Генерировать критическую ошибку при 1 недоступности сервера). Параметр недоступен. '|
Disable All Synchronization (Отключить синхронизацию). Параметр недоступен.|
Return Server DN (Возвращать характерное имя сервера). Параметр недоступен. 1
Пункты меню свойств сервераi
После щелчка правой кнопкой мыши на пиктограмме сервера появляется раскрывающее- j ся меню. Несколько пунктов этого меню позволяют получить дополнительную информацию i о репликации и состоянии контроллера домена.1
Generate Status Report (Генерировать отчет о состоянии). Выберите этот пункт для получе- I
ния подробного отчета о конфигурации контроллера домена по отношению к Active Directory. 1 Список характеристик, которые отображаются в отчете, выбирается в окне Report Options I (Параметры отчета). Это окно открывается перед созданием отчета (рис. 7.25).1
Show Group Policy Status (Показать состояние групповых политик). Отображается спи- | сок объектов Group Policy, доступных в пределах домена, а также предоставляется ин- 1 формация о синхронизации этих объектов. Эта информация необходима при диагностике 1 проблем, когда пользователи одного контроллера домена получают групповые политики, а | пользователи другого контроллера домена — не получают.]
Show Trust Relationships (Показать отношения доверия). Этот пункт позволяет про- 1 смотреть информацию, которая доступна в окне Active Directory — Domains and Trusts 1 (Active Directory — домены и доверия), но в данном случае информация предоставляется Я в более удобной форме.I
Display Metadata Properties (Показать метаданные свойств). При выборе этого пункта ] выдается запрос на ввод альтернативных аутентификационных данных (если это необхо- 1 димо) и ввод характерного имени объекта, для которого необходимо просмотреть данные 1 о репликации. Эта возможность эквивалентна команде repadmin/showmeta. Информа- j ция о метаданных оказывается незаменимой при попытке определить причину поврежде- 1 ния данных свойства или пользовательского объекта. Сравнивая метаданные различных копий, можно обнаружить ошибку и оценить масштаб ее распространения.1
J
^ Report Options
For ar* the «ejected server • Mo* dtiawi be output automatic*-these era optional ’ p Conoection».genwat6dbytheKCCI .
p C»<«itFSMO(Rm*teSm^ Master Op«ab^
Addtional Information that gvi be recorded flease «elect horn the folowRng apbonol coffponMr
p Server/DC Configvation Data
1 P Extended Sie Configuration{
. p Computer Account Data.' 1
P StebnkandStsUr*BridgeConfigixabon•
P Inter-Sue Transport Coihguabon P Signets P Active Drectory Repficahon Parameters {genaaD
Puc. 7.25. Окно Report Options (Параметры отчета) для настройки отчета о состоянии сервераPuc. 7.25. Окно Report Options (Параметры отчета) для настройки отчета о состоянии сервера1Г"»-1СотЫ j
Puc. 7.25. Окно Report Options (Параметры отчета) для настройки отчета о состоянии сервера
Puc. 7.25. Окно Report Options (Параметры отчета) для настройки отчета о состоянии сервера
Свойства сервера
Щелкните правой кнопкой мыши на пиктограмме сервера. Откроется окно Properties (Свойства). На вкладках в этом окне будет показано состояние репликации.
Server Flags (Флаги сервера). На этой вкладке показана специальная информация о контроллере домена, включая состояние глобального каталога, состояние KDC и состояние службы W32Time.
Рис. 7.26. Вкладка FSMO Roles (Мастеры операций) окна Server Properties (Свойства)
FSMO Roles (Мастеры операций). На этой вкладке перечислены имена и сайты мастеров операций — серверов, ответственных за выполнение критически важных операций. Для проверки соединения с сервером следует щелкнуть на Query (Запрос) справа от названия его роли (рис. 7.26).
Inbound Replication Connections (Входящие подключения репликации). На этой вкладке предоставляется информация о входящих соединениях репликации (рис. 7.27).
G*wl[ SwFhgil FSMO Rd# | CwMdl |
t»eiow is « w or me гоошо connection очесы емктпео nr tuts ooew conroeer
Correction NewГ Sever Ne*I MevGwedKt? i
jj44M37c9d4b6-4 Phoe™\SERVER4AUTO jU756O8c77-c1a2-4. . Phoenix\SERVER2AUTO
$9d2e45bO-d432-4... Houslon\SEHVER3AUTO
B*w е w «dvencei deicripbon of wfy the ntxxnd comoclion rrfeiad» *•* аЫ№Л»А
Connection Name: 44Ы 37c9-d4b6-45b2-8915-dda6e80cd721
Replication Partner: PhoenoASERVER4
Administrator Generated?: AUTO
Reasons for this connection.'
Directory Partition lDC-ForestOnsZonesDC=companyJDC=com) Replicated because the replication partner is a ring neighbor.
Puc. 7.27. Вкладка Inbound Replication Connections (Входя-щие соединения репликащш) окна Server Properties (Свойства)
В следующей главе
На этот момент читатели получили достаточный объем информации о работе Active Directory и репликации, чтобы приступить к проектированию собственной системы. В следующей главе рассматривается создание службы каталогов, которая максимально использует возможности Active Directory.
В
предыдущих главах рассматривались критически важные компоненты службы DNS и службы каталогов Active Directory. Теперь, когда стали понятны преимущества службы каталогов по сравнению с классической архитектурой Windows NT, пришло время достать чистый лист бумаги и начать составление архитектурного плана системы.
Служба Active Directory имеет весьма сложную структуру, в которой задействованы многочисленные механизмы. Многие решения, которые придется принимать при проектирова- нии каталога, связаны со сложностями различного характера. Обычно проектирование должно начинаться с оценки технических достоинств каждой возможности с точки зрения улучшения текущей ситуации. Если подготовиться достаточно тщательно и учесть все возможные переменные, в итоге можно получить технически корректный проект. Но не всегда хорошие проекты реализуются без изменений, поскольку часть проблем связана с восьмым уровнем сетевой модели OSI —уровнем политики.
В этой главе рассматриваются технические проблемы и вопросы политики, связанные с проектированием службы каталогов Active Directory. Здесь будут показаны компромиссы, на которые приходится идти многим администраторам при проектировании Active Directory, а также различные методы устранения проблем, которые возникают в результате подобных компромиссов. Кроме этого, будут описаны лучшие методы и решения, которые были разработаны в течение последних нескольких лет одновременно с развитием Active Directory.
Существует три основных вопроса, на которые приходится отвечать при проектировании общей структуры Active Directory.
Количество и имена доменов
Структура организационных единиц высокого уровня
■ Локальная структура организационных единиц
В результате начальной оценки будет получен набросок, который определяет общий вид домена или доменов, зон DNS, которые будут поддерживать доменное пространство имен, а также уровень организационных единиц.
После этого можно определить расположение DNS-серверов, контроллеров домена, серверов глобального каталога и серверов, выступающих в роли Master Operations (Хозяин операций), которые рассматриваются далее в этой главе.
Новые возможности операционном системы Windows Server 2003
Лишь некоторые из новых возможностей операционной системы Windows Server 2003 оказывают непосредственное влияние на архитектуру Active Directory. Но они предоставля ют большую гибкость при проектировании, чем гибкость, которая была доступна при исполь зовании операционной системы Windows 2000. Рассмотрим эти возможности.
■ Возможность переименования. Поддерживается переименование доменов и изменение отношений между родительским и дочерним доменами. Это позволяет менять структуру леса в соответствии с реорганизацией компании. При этом динамическое выделение до менов в отдельный лес не поддерживается, как не поддерживается перенос доменов из одного леса в другой. Также поддерживается переименование контроллеров домена.
■ Федерации. Новый тип доверительных отношений, который называется доверие между лесами (Forest Trust), позволяет создавать транзитивные доверительные отношения между доменами, входящими в различные леса. Возможность формирования федера ции значительно упрощает использование Active Directory в таких организациях, как университет и промышленный конгломерат, в которых подразделения постоянно добав ляются и удаляются.
■ Усовершенствованные функции безопасности. Добавлена поддержка аутентификации на основе дайджеста, описанная в документе RFC 2829, “Authentication Methods for LDAP” Это упрощает интеграцию Active Directory с другими операционными системами.
■ Гибкость схемы. Появилась возможность объявлять компоненты схемы “неработающи ми”. Эта возможность допускает удаление классов объектов и атрибутов, которые были добавлены приложением, но теперь не используются.
Взаимодействие. Добавлена поддержка класса InetOrgPerson, который определен в до кументе RFC 2798, “Definition of the inetOrgPerson LDAP Object Class". Это позволяет добиться более полного взаимодействия со службами каталогов Netscape и NetWare, котб рые используют класс inetOrgPerson для создания пользовательских объектов.
Масштабируемость. Максимальное количество объектов, которые можно хранить в базе данных Active Directory, было увеличено до миллиарда.
Цели проектирования
Я так же люблю аппаратные и программные новинки, как и любой администратор. Я обожаю инновационные технологии, основанные на передовых идеях. Но сети существуют не только для администраторов. Администраторы просто их обслуживают, а результатами работы сети пользуются другие. Нравится это или нет, но сети существуют для пользователей.
Каждый администратор может поделиться историями о нетерпеливых пользователях, которые жалуются и кричат при необходимости выполнить даже самую простую сетевую операцию. Подключить сетевой диск? Забудьте. Подключить принтер? Даже не обсуждается. Пользователи требуют простого, надежного и производительного доступа к сетевым ресурсам. Если для использования ресурса приходится выполнить больше двух щелчков мышью или научиться чему-то, что отдаленно напоминает специализированное техническое решение, ресурс с тем же успехом мог бы находиться в галактике Малого Магелланового Облака. Если в результате проектирования службы каталогов Active Directory пользовательская среда не упрощается и не становится надежнее, проект провалится.
Значит, правильный проект домена должен сделать доступ к ресурсам максимально простым и интуитивно понятным. Хорошо. Но, кроме простоты, существуют и другие критерии правильного проекта. С точки зрения системного администратора, проект домена должен соответствовать ряду критериев. Ниже перечислены некоторые основные критерии.
Безопасность. Методы и протоколы управления доступом к ресурсам должны быть достаточно надежными для защиты миллионов и миллиардов долларов, вложенных в данные и аппаратные средства. В результате проектирования неавторизованный доступ должен быть максимально усложнен, а авторизованный доступ, наоборот, — максимально упрощен. Необходима поддержка аудита, чтобы нарушения в работе обнаруживались как можно раньше, еще до нанесения значительных повреждений. Кроме этого, проверки системы безопасности должны выполняться как можно быстрее и “беспрепятственнее”.
Стабильность. Ни одной сетевой операционной системе не позволено предоставлять сетевые ресурсы непредсказуемым образом или демонстрировать неожиданное поведение при выполнении функций. Сетевые ресурсы должны работать одинаково в любой момент времени.
Надежность. В хорошем проекте отсутствуют критические точки отказа, от работоспособности которых зависит вся система. Поскольку достичь полной избыточности слишком сложно, в проекте должны присутствовать простые планы восстановления после отказов с высокой вероятностью их успешной реализации.
Управляемость. Ни одному из администраторов не удавалось избегать использования в сетевой инфраструктуре различных аппаратных средств и операционных систем. В хорошем проекте должны быть минимизированы сложности при передаче информации из одной системы в другую.
Поддержка восстановления. Active Directory является базой данных. Ни одна база данных не защищена от повреждения, ошибок и несчастных случаев. В хорошем проекте должны быть учтены проблемы в работе службы каталогов. Должны существовать возможность быстрого обнаружения проблем и средства для восстановления системы после устранения проблем с минимально возможным простоем.
Эффективность. Операции со службой каталогов оказывают нагрузку на такие элементы инфраструктуры, как сетевые соединения и аппаратные средства серверов. В проекте службы Active Directory должны быть минимизированы стоимость инфраструктуры и обоснованы все неизбежные финансовые затраты, чтобы никто из управляющего персонала не смог вычеркнуть эти расходы из бюджета.
Кроме этого, существуют менее формализованные, но такие же важные факторы, которые можно объединить в понятие политика. Если не соблюдать осторожность, эти факторы могут полностью нарушить структуру действительно красивого проекта. Одним из первых источников компромиссов при проектировании структуры Active Directory является доменное имя. Рассмотрим этот вопрос в первую очередь.
Служба DNS и пространства
имен Active Directory
Как было сказано в главе 6, “Службы Active Directory”, домен Active Directory должен соответствовать имени домена DNS. На рис. 8.1 показано пространство имен домена и соответствующее дерево Active Directory.
Нет никаких сомнений в том, что операционная система Windows Server 2003 значительно упрощает развертывание службы Active Directory и управление ею. Но если уже используется платформа DNS от стороннего производителя, то вероятность полного перехода на Windows
Server 2003 крайне невысока. Иногда такой переход даже нежелателен. Поскольку служба DNS является критически важным компонентом Active Directory, необходимо принять решение об интеграции Windows Server 2003 в существующую инфраструктуру DNS. Ниже приведены три самые популярные конфигурации.
Пространство имен DNSПространство имен DNSПространство имен доменаПространство имен доменаdc-Phoenix,dc=Company,dc=comdc-Phoenix,dc=Company,dc=comРис. 8.1. Пространство имен DNS и дерево Active DirectoryРис. 8.1. Пространство имен DNS и дерево Active Directory
Пространство имен DNS
Пространство имен DNS
Пространство имен домена
Пространство имен домена
dc-Phoenix,dc=Company,dc=com
dc-Phoenix,dc=Company,dc=com
Рис. 8.1. Пространство имен DNS и дерево Active Directory
Рис. 8.1. Пространство имен DNS и дерево Active Directory
Полностью отказаться от использования службы DNS под управлением операционной системы Windows и использовать серверы имен от сторонних производителей для хранения доменов Active Directory.
Создать отдельные домены DNS для Active Directory; хранить зону на сервере под управлением Windows Server 2003 и перенаправлять запросы о записях из других зон на DNS- серверы сторонних производителей.
Использовать текущий открытый домен DNS в качестве корневого домена Active Directory, создать отдельные частную и общедоступные зоны DNS и хранить частную зону на сервере под управлением операционной системы Windows Server 2003.
В следующих разделах подробно рассматриваются эти варианты.
Active Directory и серверы имен от сторонних производителей
В операционной системе Windows Server 2003 не обязательно запускать службу DNS для поддержки Active Directory, но версия используемых DNS-серверов должна поддерживать обработку записей Service Locator (SRV), которые определены в документе RFC 2782, “A DNS RR for Specifying the Location of Services (DNS SRV)” (“Записи DNS для определения местоположения служб").
Контроллеры домена Active Directory используют записи SRV для предоставления сведений о поддерживаемых ими службах LDAP и Kerberos. Формат этих записей описывается в документе RFC 2052, “SRV Records Format and Use” (“Формат и использование записей SRV”). Серверы имен BIND 8.1.2 и более поздние версии поддерживают записи SRV. Это касается и последних версий DNS-серверов Lucent QIP и NetWare 5.x.
Поскольку записи SRV имеют достаточно сложный формат, а в Active Directory такие записи используются весьма часто, желательно использовать платформу DNS, которая поддерживает динамическую регистрацию записей, описанную в документе RFC 2136, “Dynamic Updates in the Domain Name System (DNS UPDATE)”.
Если для конкретной службы DNS используются только статические зоны или динамические обновления нежелательно включать по другим причинам, то администратору придется вручную ввести необходимые записи SRV. Мастер установки Active Directory создает файл, который называется netlogon.dns и хранится в каталоге C:\windows\System32\Config. Этот файл содержит записи SRV, которые служба Netlogon пыталась зарегистрировать в службе DNS. Этот файл можно импортировать на сервер имен стороннего производителя, но на этом работа администратора не заканчивается. Необходимо вручную обновлять зоны при всех последующих изменениях, например при повышении или понижении контроллеров домена, создании новых объектов сайтов или перемещении контроллеров домена с одного сайта на другой.
Использование отдельных зон
Иногда существующее имя DNS не подходит для использования вместе с Active Directory или управляющий персонал не удается убедить в необходимости хранения записей ресурсов Active Directory на существующем сервере имен. В этом случае можно создать отдельный домен DNS и использовать его для хранения пространства имен Active Directory. Новую зону можно хранить на сервере под управлением операционной системы Windows, а запросы к другим зонам можно перенаправлять на существующие DNS-серверы. Такая конфигурация показана на рис. 8.2.
Рис. 8.2. Служба DNS под управлением операционной системы Windows Server2003, исполъ- зуюгцая перенаправление запросов к DNS-серверу от третьего производителяРис. 8.2. Служба DNS под управлением операционной системы Windows Server2003, исполъ- зуюгцая перенаправление запросов к DNS-серверу от третьего производителяDNS-сервер верхнего уровняDNS-сервер верхнего уровня
Рис. 8.2. Служба DNS под управлением операционной системы Windows Server2003, исполъ- зуюгцая перенаправление запросов к DNS-серверу от третьего производителя
Рис. 8.2. Служба DNS под управлением операционной системы Windows Server2003, исполъ- зуюгцая перенаправление запросов к DNS-серверу от третьего производителя
DNS-сервер верхнего уровня
DNS-сервер верхнего уровня
В этом случае клиенты под управлением операционной системы Windows обращаются к серверам имен под управлением Windows. Если клиент запрашивает запись из внешней зоны, сервер под управлением Windows перенаправляет запрос на оригинальный сервер. Если клиент запрашивает записи из сети Интернет, то сервер под управлением Windows может обращаться непосредственно к серверам верхнего уровня, которые поддерживаются компанией Verisign.
Общедоступный домен с разделением на общедоступную и частную зоны
Этот вариант часто используется организациями, которые пытаются сохранить зарегистрированные ранее доменные имена и использовать их в качестве доменных имен Active Directory. Например, компания International Widget Company может предпочесть использование имени Widget.com вместо Widget.net или Widget. local, или другого частного пространства имен. На рис. 8.3 показан пример подобной конфигурации.
Сервер преобразования имен под управлением операционной системы Windows Server 2003Сервер преобразования имен под управлением операционной системы Windows Server 2003Основной серверAD.Company.comОсновной серверAD.Company.comСервер имен BINDСервер имен BINDОсновной сервер Company.comОсновной сервер Company.comЗона-заглушкаAD.Company.comЗона-заглушкаAD.Company.comОсновнаяграницабрандмауэраОсновнаяграницабрандмауэраDNS-сервер верхнего уровняDNS-сервер верхнего уровняххОсновной сервер Company.comОсновной сервер Company.comDNS-серверпровайдерауслуг ИнтернетDNS-серверпровайдерауслуг Интернет
Сервер преобразования имен под управлением операционной системы Windows Server 2003
Сервер преобразования имен под управлением операционной системы Windows Server 2003
Основной сервер
AD.Company.com
Основной сервер
AD.Company.com
Сервер имен BIND
Сервер имен BIND
Основной сервер Company.com
Основной сервер Company.com
Зона-заглушка
AD.Company.com
Зона-заглушка
AD.Company.com
Основнаяграницабрандмауэра
Основнаяграницабрандмауэра
DNS-сервер верхнего уровня
DNS-сервер верхнего уровня
х
х
Основной сервер Company.com
Основной сервер Company.com
DNS-серверпровайдерауслуг Интернет
DNS-серверпровайдерауслуг Интернет
Рис. 83. Общедоступный домен DNS с разделением на общедоступную и частную зоны
При такой конфигурации используются отдельные зоны для общедоступного и частного пространств имен. Частная зона хранится на сервере имен внутри сети, защищенной бранд- мауэром. Общедоступная зона хранится на сервере имен в демилитаризованной зоне или на DNS-сервере провайдера. В любом случае клиенты используют сервер внутри защищенной сети. Этот сервер будет использовать внешний сервер для перенаправления запросов или корневые серверы для преобразования адресов за пределами защищенной сети. Наибольшая гибкость при использовании Active Directory достигается при хранении частной зоны на сервере имен под управлением операционной системы Windows.
Если используется конфигурация с разделением, не забывайте, что клиенты за пределами защищенной сети не смогут получать доступ к серверу имен, которые находятся внутри защищенной сети. Клиенты смогут пройти аутентификацию только при подключении через брандмауэр с помощью коммутируемого доступа, подключения VPN или другой формы защищенного соединения. Клиенты могут использовать флажок Logon Using Dial-Up Connection (С использованием удаленного доступа) в окне для ввода аутентификационных Данных. При установке этого флажка клиенты под управлением операционных систем Windows 2000 и Windows ХР используют регистрацию на основе протокола Kerberos, что значительно ускоряет последующий доступ к ресурсам серверов.
Имя корневого домена
“Что в имени тебе моем?” — спрашивала Джульетта, мечтая о Ромео. Имена оказываются критически важными в любви и при использовании компьютеров. Не платите цену, которую заплатили Ромео и Джульетта, проигнорировав имена при проектировании доменов.
Клиенты под управлением операционной системы Windows живут в двух мирах: иерархическом мире, где имеет значение только полностью определенное доменное имя DNS, и “плоском” мире, где основное значение имеют имена NetBIOS. При проектировании необходимо поддерживать обе системы именования.
При повышении первого контроллера домена Active Directory мастер установки Active Directory (Dcpromo) создает “плоское” имя NetBIOS на основе крайней слева части полностью определенного имени DNS. Например, при наличии доменного имени DNS company. com будет создано “плоское" имя COMPANY. При повышении контроллера домена теоретически возможно назначить “плоское" имя, которое не будет основано на крайнем слева элементе имени DNS. Однако это может привести к замешательству среди пользователей, которым придется догадываться, какое имя использовать в каждой конкретной ситуации.
Чтобы сохранить текущее имя домена Windows NT и использовать его в качестве имени домена Active Directory, необходимо выбрать доменное имя DNS, которое использует имя домена Windows NT как элемент самого нижнего уровня. Например, если имя домена Windows NT выглядело, как COMPANY, доменное имя DNS будет выглядеть, как Company.com, Company .net, Company. local или Company. Enterprise. ParentDomain. com.
Ограничения на доменные имена, связанные с "плоскими" именами
Для сохранения текущего имени домена Windows NT в качестве “плоского" имени домена Active Directory необходимо модернизировать существующий основной контроллер домена. Параллельный домен Active Directory с таким же “плоским” именем создать не удастся, так как это приведет к конфликту имен NetBIOS.
Например, предположим, что существующий домен Windows NT называется COMPANY. При попытке создания нового контроллера домена под управлением Windows Server 2003, и когда в качестве корневого домена Active Directory использовался домен DNS Company. com, мастер установки Active Directory попытается зарегистрировать “плоское” имя COMPANY, полученное на основе имени Company. com. При попытке регистрации от основного контроллера домена COMPANY (или от службы WINS) будет получено уведомление о том, что имя COMPANY уже существует. Мастер повышения предложит использовать имя COMPANY0. Администратору не следует принимать это или любое другое имя, которое не соответствует части доменного имени DNS самого низкого уровня.
Если существующее имя домена Windows NT не нравится и планируется создать домен Active Directory с другим “плоским” именем, необходимо создать новый домен Active Direc- tory и перенести в него объекты из старого домена. В следующей главе процедура переноса объектов рассматривается более подробно.
Советы по решению проблем при конфликте имен
Создание “союза" между Active Directory и DNS во многих организациях превращается в еще одну историю Ромео и Джульетты. В крупных организациях обычно существует несколько конкурирующих групп информационных технологий, которые разбили пространство имен DNS на несколько зон и используют перенаправление и делегирование с помощью таких схем, которые вызвали бы головную боль даже у чемпиона мира по шахматам.
Например, пространство имен DNS университета может использовать отдельные домены для академии, административных служб, школы при университете, биологического факуль-
тета, химического факультета, физического факультета, факультета изобразительного искусства, отделения физкультуры, лабораторного корпуса, механико-математического факультета, гуманитарного отделения, библиотеки, профсоюза студентов и книгохранилища, а также по нескольку поддоменов в каждом домене, не считая доменов для внешних отделений, университетских городков, подготовительных курсов и так далее и так далее.
У администратора офиса или отделения, которое существует в поддомене DNS, может возникнуть проблема при проектировании домена Active Directory в таких условиях. Может возникнуть соблазн разместить лес Active Directory в составе текущего поддомена DNS, чтобы обойти неизбежный бюрократический процесс принятия решения. Именно такое решение является ошибочным.
Предположим, что поддомен DNS называется Humanities. EastCampus. Big University.edu. Текущий домен WindowsNT называется PLATO. При переходе на Active Directory может возникнуть желание изменить “плоское” имя домена, поскольку Plato (Платон) был разоблачен как интеллектуальный деспот, который веками нарушал спокойствие западной мысли. Администратор может принять решение о создании домена Windows Server 2003, находящегося в поддомене DNS и использующего имя HUMANITIES. В таком случае возникают два неприятных последствия.
“Плоское” имя домена должно быть уникальным в пределах леса для сохранения обратной совместимости. Существуют и другие гуманитарные отделения в других университетских городках, которые не согласятся с единоличным использованием этого имени.
Разместив домен Active Directory в поддомене DNS Humanities. EastCampus. BigUniversity. edu, администратор создает новый лес. Как только весь остальной университет примет решение о переходе на Active Directory, администратору придется переносить объекты из собственного леса в лес университета или формировать доверительные отношения между лесами. Второй вариант ограничивает возможность совместного ис
' пользования ресурсов и значительно усложняет управление доменом.
Лучше всего в этом случае — встретиться с персоналом отделов информационных технологий из различных университетских городков и обсудить возможные решения по совместному использованию пространства имен DNS для унифицированного проектирования и развертывания доменов Active Directory. Если бюрократия полностью “задавила" процесс принятия согласованного решения, можете приступать к созданию собственного леса, но в будущем придется приложить значительные усилия для исправления ситуации.
Стратегия проектирования доменов
В Active Directory, как и в классических доменах Windows NT, домен (domain) определяет отдельную единицу администрирования и безопасности. Кроме этого, домен определяет границы репликации, поскольку каждый домен формирует отдельный контекст именования в пределах базы данных Active Directory./
Проектируя структуру доменов, постарайтесь найти способ использования единственного домена Active Directory. Придерживайтесь этой рекомендации, даже если по правилам политики необходимо создать несколько доменов. Использование единственного домена имеет свои преимущества.
Упрощенная навигация. Пользователи рассматривают сетевые структуры с теми же страхом и подозрительностью, с которыми средневековые крестьяне рассматривали комету. Чем проще процедура поиска ресурсов, тем выше вероятность успешной реализации проекта.
Более простая конфигурация DNS. Если между несколькими доменами устанавливаются сложные отношения типа “родитель—потомок”, это усложняет настройку результирующих ссылок в зонах DNS. Служба DNS является основной причиной большинства
проблем в работе Active Directory, поэтому старайтесь избегать лишней сложности всегда, когда это возможно.
Более простая топология репликации. Управлять репликацией в пределах одного домена значительно проще, так как в топологии репликации не нужно учитывать несколько контекстов именования доменов и серверы глобального каталога
Длина имен
Для доменов старайтесь создавать короткие и простые имена. Используйте аббревиатуры всегда, когда это возможно. Пользователи будут очень раздражены, если основное имя пользователя будет выглядеть как user@Albuquerque .NewMexico .UnitedSCates .North America.Company.com.
Старайтесь использовать короткие имена и для организационных единиц. Характерное имя не может быть длиннее 255 символов, включая указатели типов dc=, CN= и ои=.
Возможность отказа от использования отдельных серверов глобального каталога. При использовании одного домена можно не зависеть от единственного сервера глобального каталога и включить функцию глобального каталога на каждом контроллере домена.
Более простая реализация системы безопасности. Это правда, что транзитивные доверительные отношения по протоколу Kerberos действительно позволяют прозрачным образом получать доступ к ресурсам других доменов. Однако прозрачность возможности не означает простоту ее администрирования. Самый страшный кошмар администратора — устранение проблемы при доступе к файлам и каталогам путем просмотра списков членов сотен групп в отдельных доменах.
Причины использования нескольких доменов
Против использования единственного домена может выступать еще один администратор, который желает иметь автономный домен любой ценой. Все эти возражения можно отнести к ограничениям политики. Это совсем не означает, что такие ограничения менее важны, чем технические. Стабильность и производительность информационной системы намного больше зависит от людей, чем от технологий. Просто ограничения политики могут значительно меняться в процессе утверждения проекта, поэтому при проектировании они учитываются менее тщательно, чем технические ограничения.
Существует лишь несколько технических ограничений Active Directory, которые могут требовать использования нескольких доменов. В их числе можно назвать размер базы данных, производительность, необходимость использования разных политик паролей и существование сайтов, требующих репликации с использованием протокола SMTP.
Ограничения, связанные с размером базы данных
Чем больше объектов существует в пределах домена, тем больше становится база данных Active Directory, которая хранится в файле Ntds . dit. При этом увеличивается количество изменений, которые необходимо реплицировать между контроллерами домена. Active Directory поддерживает до миллиарда объектов, поэтому существующего запаса достаточно для дальнейшего расширения, но для особо больших баз данных требуются высокопроизводительные серверы для обработки аутентификации и запросов LDAP. В данном случае можно обратиться к примеру Римской империи, размер которой отрицательно повлиял на долговечность.
База данных Active Directory для ста тысяч пользователей, их Компьютеров, и групп, необходимых для управления таким количеством клиентов, будет иметь размер около 1,5 Гбайт. Если учесть дополнительные накладные расходы службы каталога Exchange 2000, размер ба-
зы данных может составить 2 Гбайт. Экстраполируя результат на организацию с полумиллионом пользователей, можно получить файл Ntds.dit размером 10 Гбайт, что не превышает возможностей обычного зеркалированного массива или массива RAID 5.
По современным меркам это не слишком большие базы данных, поэтому решение об использовании нескольких доменов не будет зависеть от количества пользователей, компьютеров и групп. В данном случае администратора должны больше интересовать объем данных, передаваемых при репликации, и производительность во время процедуры аутентификации.
В большинстве доменов Windows работает менее 10 тыс. пользователей, что намного меньше, чем максимальные возможности Active Directory. Самой сложной задачей администратора при проектировании такой системы является необходимость убедить управляющий персонал не размещать дополнительные службы, например службы сообщений или СУБД, на контроллерах домена. Обычно контроллеры домена хорошо справляются с поддержкой служб DNS, DHCP и WINS, но установка дополнительных служб может привести к излишней нагрузке на сервер. Очень нежелательно перезагружать или перестраивать контроллер домена из-за отказа приложения.
Только действительно огромные организации с сотнями тысяч пользователей и компьютеров нуждаются в делении на несколько доменов. Компания Microsoft не опубликовала четкие правила о максимальном практическом размере базы данных, поэтому представители огромных организаций при проектировании доменной структуры должны тесно сотрудничать с консультационной службой компании Microsoft.
Ограничения, связанные с производительностью
Большинство компаний, использующих Active Directory, пытаются создавать отдельные домены для ограничения объема данных, передаваемых при репликации между отделениями по дорогостоящим каналам WAN. Обычно это означает создание доменов под названием, например, Europe, Pacific Rim, South America, Asia для Китая и Индии, а также Africa.
Для получения допустимой производительности при аутентификации придется выбирать контроллер домена, соответствующий количеству пользователей в пределах определенного сайта. Если в пределах сайта существует несколько сотен пользователей, которые проходят аутентификацию практически одновременно каждое утро, то для создания контроллера домена хватит стоечного сервера 1U с одним процессором Xeon, оперативной памятью 256 Мбайт, сетевым адаптером со скоростью передачи данных 100 Мбит/с и зеркалированным массивом дисков для хранения файлов Active Directory. Такой сервер обойдется до 4000 долларов при покупке у большинства производителей верхнего уровня.
Если утром одновременно проходят аутентификацию несколько тысяч пользователей, нагрузку можно распределить на несколько контроллеров домена меньшего размера или увеличить производительность контроллера домена, установив два центральных процессора, несколько сетевых адаптеров и отдельные зеркалированные массивы для файлов Active Directory и Sysvol.
Ограничения, связанные с политиками паролей
Три набора политик оказывают влияние на атрибуты объекта Domain и не могут быть переопределены групповыми политиками в подчиненных контейнерах, например в организационных единицах. Вот эти наборы.
Политики паролей. Эти политики определяют минимальный и максимальный сроки действия пароля, минимальную длину пароля, историю паролей, требования к сложности пароля и параметры обратимого хранения паролей.
Политики блокирования учетных записей. В этих политиках определяется количество неудачных попыток регистрации, которые приводят к блокированию, длительность блокирования и интервал сброса.
Политики Kerberos. Эти политики описывают длительность существования пользовательских билетов и билетов служб, интервал возобновления билетов и допустимое отклонение во времени.
Если эти политики должны иметь различные значения в пределах одной организации, придется создавать отдельные домены. Иногда это происходит при работе по контракту и клиент желает использовать разные ограничения в системе безопасности.
Ограничения, связанные с репликацией по SMTP
Сайты могут существовать в удаленных, всеми забытых уголках мира, например в Тьерра Дель Фуэго или Хоббс в Нью-Мексико. Сетевые соединения с этими районами не всегда обеспечивают надежную передачу данных. При попытке создания стандартного межсайтового соединения с использованием низкоскоростной версии RPC обрыв соединения может случаться достаточно часто, чтобы связующие серверы выдали сообщение о невозможности репликации.
В таком случае в качестве транспортного протокола для репликации с удаленным сайтом можно использовать протокол Simple Mail Transport Protocol (SMTP).
Протокол SMTP хорошо подходит для передачи пакетов репликации по ненадежным соединениям, но обладает рядом связанных с безопасностью недостатков. Протокол RPC, который применяется при внутрисайтовой и межсайтовой репликации, шифрует передаваемые данные, а протокол SMTP передает данные открытым текстом. Для защиты информации Active Directory сообщения шифруются специальными средствами шифрования сообщений. Это требует наличия сертификата контроллера домена на связующих серверах на каждой стороне соединения. Для получения такого сертификата необходимо установить Microsoft Certification Authority.
Еще один недостаток протокола SMTP связан со службой репликации файлов (File Replication Service — FRS). Эта служба реплицирует содержимое каталога Sysvol, в котором хранятся файлы шаблонов групповых политик, а также файлы, которые используются классическими системными политиками и сценариями. Служба репликации файлов не поддерживает протокол SMTP в качестве транспортного механизма. Это значит, что контейнерные объекты групповых политик в базе данных Active Directory не будут синхронизированы с файлами групповых политик из каталога Sysvol. Именно по этой причине протокол SMTP не может использоваться для соединения связующих серверов в пределах одного домена.
Ограничения, связанные с правилами политики
Единственный домен можно использовать во всех организациях, кроме самых крупных, в которых офисы находятся на большом расстоянии друг от друга. При более подробном рассмотрении аутентификации, делегирования прав, управления группами и групповых политик, будет ясно, что можно создать единственный домен, в котором административные границы и границы управления определяются с помощью организационных единиц.
Но не забывайте, что в процессе утверждения даже хороший проект единственного домена может быть разделен на несколько частей. Обычно это случается из-за применения правил политики, а не ограничений технического характера. Системные администраторы и управляющий персонал могут с подозрением относиться к объединению доменов. Иногда при недостаточной силе воли проектировщика или недостаточной поддержке со стороны управляющего персонала в результате может получиться больше доменов, чем нужно на самом деле.
Не позволяйте локальным администраторам добиваться независимости в ущерб надежности и производительности. Большое количество доменов, особенно формирующих отдельное дерево в пределах леса, значительно усложняет репликацию и размещение контроллеров домена.
Локальным администраторам, которым представители центрального отдела информационных технологий предложили объединить домены, рекомендуем отказаться от подозрений. В пределах организационной единицы администратор по-прежнему владеет широкими пол-
номочиями, при этом получая возможность пользоваться всеми преимуществами единой структуры Active Directory.
На рис. 8.4 показан пример леса, в котором глобальные регионы выделены в отдельные домены. Крупные офисы также выделены как домены, а не как организационные единицы. Кроме того, в компании есть филиалы, которые также настаивают на предоставлении отдельного домена.
С точки зрения администрирования эта структура крайне нежелательна, так как требует управления несколькими контекстами именования доменов с различными вариантами организационных единиц и групповых политик. Если в компании нет центрального отдела информационных технологий, такая структура может оказаться работоспособной. В противном случае следует избегать использования отдельных доменов для структур в пределах одного материка.
Рис. 8.4. Контейнеры верхнего уровня с использованием нескольких доменов
Группы и использование нескольких доменов
Если принято решение об использований нескольких доменов, влияние групп безопасности придется рассмотреть в самом начале процесса проектирования. В главе 12, “Управление групповыми политиками”, подробно рассматриваются правила безопасности групп, а здесь приводится краткое описание тех возможностей, которые необходимо знать при проектировании домена. Ниже перечислены важные элементы, на которые стоит обратить внимание.
В Active Directory существуют группы трех основных типов с различными областями применения и членства. Максимальная гибкость предоставляется в режиме Native.
Подсистема безопасности использует группы для авторизации доступа. При неправильном планировании пользователи не смогут получить доступ к некоторым ресурсам или, наоборот, администратор не сможет ограничить доступ.
Списки членов групп различных типов в глобальном каталоге хранятся по-разному. Это делает доступ к глобальному каталогу очень важным элементом проектирования Active Directory.
Классификация групп
Active Directory поддерживает три класса групп безопасности: локальные для домена, глобальные и универсальные. Четвертый тип, локальные для компьютера, существует только в локальной базе данных SAM.
Группы различаются по области членства и области действия.
Локальные для домена. В группы этого типа могут входить члены любого домена в пределах леса. Группы этого типа можно включать в списки контроля доступа только в пределах домена.
Глобальные. В группы этого типа могут входить только члены конкретного домена. Группы этого типа можно включать в списки контроля доступа в любом домене в пределах леса.
Универсальные. В группы этого типа могут входить члены любого домена в пределах леса. Группы этого типа можно включать в списки контроля доступа в любом домене в пределах леса.
Вложенность групп
Одни группы могут быть вложены в другие группы, т.е. одна группа может являться членом другой группы. Правила вложенности ограничивают множество типов групп, которые могут являться членами групп других типов. Правила вложенности зависят от режима работы домена (Mixed или Native). Вот эти правила.
В режиме Mixed локальные для домена группы не могут входить в другие группы. В режиме Native локальные для домена группы могут входить в другие локальные для домена группы в пределах того же домена, но не могут входить в группы других типов. Кроме этого, локальные для домена группы не могут быть членами групп в других доменах.
В режимах Mixed и Native глобальные группы могут входить в группы, локальные для домена. В режиме Native глобальные группы могут входить в другие глобальные группы и универсальные группы.
Универсальные группы могут создаваться и использоваться в режиме Native. Универсальные группы могут входить в локальные для домена, глобальные и другие универсальные группы. Если в универсальную группу входят пользователи из нескольких доменов, универсальную группу можно включать в глобальную группу, если обе группы находятся в пределах одного домена.
Членство пользователя в группах позволяет определить ресурсы, к которым пользователю разрешен доступ. Правила вложенности групп определяют объем работы регистрационного сервера пользователя для определения членства пользователя в группах.
Группы и авторизация
При регистрации пользователя служба Local Security Authority Subsystem (LSASS) на регистрационном сервере создает для пользователя сертификат привилегий доступа (Privilege Access Certificate — РАС). Сертификат привилегий доступа содержит идентификатор безопасности пользователя, набор политик безопасности (длина пароля, история паролей, ограничения на время регистрации и т.д.), идентификатор безопасности каждой группы, в которую входит пользователь, и идентификатор безопасности каждой группы, в которую входят эти группы.
Последняя часть предложения выделена специально, так как вложенность групп определяет проектирование домена и создание структур безопасности. Рассмотрим пример.
Предположим, что дескриптор безопасности для определенного каталога содержит список управления доступом, в котором указаны записи для двух групп. Для группы А предоставлены разрешения Deny АП (Нет доступа). Это значит, что всем членам группы А доступ запрещен. Для группы В указаны права доступа Full Control (Полный доступ). Это значит, что любому члену группы В разрешено создавать, читать, записывать и изменять файлы, а также менять дескриптор безопасности для этого каталога.
Если группу В вложить в группу А, членам группы В неожиданно будет отказано в доступе. Наибольший приоритет имеет самое жесткое ограничение.
Для того чтобы вложенность групп работала, служба LSASS должна просмотреть все дерево групп, чтобы сертификат привилегий доступа пользователя содержал все относящиеся к пользователю идентификаторы безопасности. Теперь можно рассмотреть основное отличие между группами безопасности.
Объект Group имеет атрибут, который называется Member. Этот атрибут содержит характерное имя каждого члена группы. При добавлении пользователя или другой группы в список членов группы характерное имя пользователя или группы добавляется в атрибут Member. Способ хранения атрибута Member в базе данных Active Directory отличается в зависимости от типа группы.
Стандартный контроллер домена хранит атрибут Member для всех объектов Group в пределах домена: локальный для домена, глобальный и универсальный.
Глобальный каталог хранит атрибут Member для универсальных групп из всех доменов в пределах леса.
Глобальный каталог не хранит атрибут Member для локальных и глобальных групп.
Компания Microsoft приняла решение исключить информацию о членстве в локальных для домена и в глобальных группах из глобального каталога, чтобы сократить объем данных, передаваемых при репликации. Ниже представлены причины этого решения.
Универсальные группы могут быть вложены в другие группы в пределах домена. Они могут указываться в списках контроля доступа в пределах любого домена. Именно по этой причине для универсальных групп служба LSASS должна просмотреть дерево членства в группах. Чтобы не просматривать все дерево при каждом поиске, атрибут Member для универсальных групп хранится в глобальном каталоге.
Локальные для домена группы не могут быть вложены в группы из других доменов. При создании сертификата привилегий доступа служба LSASS не просматривает дерево членства в группах из других доменов, поскольку такая вложенность невозможна. Вся необходимая информация может быть получена из локального контекста именования Domain. Таким образом, хранить в глобальном каталоге информацию о членстве в группах, локальных для домена, нет смысла.
Глобальные группы могут входить в локальные для домена и в универсальные группы из других доменов. Локальные для домена группы не могут использоваться в списках контроля доступа за пределами собственного домена, поэтому также нет смысла просматривать дерево групп.
Сведения о членстве в универсальных группах уже хранятся в глобальном каталоге. Поэтому для глобальных групп службе LSASS достаточно обратиться к локальному контексту именования Domain. Хранить в глобальном каталоге информацию о членстве в глобальных группах не нужно.
Резюме по группам и проектированию Active Directory
Несложно заметить, что взаимодействие групп в пределах леса из нескольких доменов может стать достаточно сложным. Сложность возрастает, если принять решение об использовании Exchange 2000 в качестве платформы для обмена сообщениями, поскольку группы безопасности управляют доступом к общим папкам. Кроме этого, Exchange использует еще один тип групп, которые называются группами распространения (distribution group). Группы распространения используются для создания списков рассылки сообщений электронной почты без регистрационных данных.
При проектировании Active Directory стоит обратить внимание на следующие основные моменты, связанные с функционирование^ групп.
Изменение членства в универсальной группе приводит к событию репликации для каждого сервера глобального каталога в пределах леса. Если определить различные домены для разных географических областей, например North America, Europe, Pac-Rim и т.д., частое изменение членства в универсальных группах приведет к передаче по сети дополнительного объема данных. Именно по этой причине компания Microsoft рекомендует размещать пользователей в глобальных группах и включать глобальные группы в состав универсальных групп.
Универсальные группы и расширенные правила вложенности для глобальных групп доступны только в режиме Native, поэтому желательно как можно быстрее отказываться от использования классических операционных систем Windows NT.
Регистрационный сервер пользователя должен иметь возможность определить членство пользователя в универсальных группах. Это необходимо для правильного создания сертификата привилегий доступа. Для подготовки к потенциальному отказу сервера глобального каталога в пределах сайта желательно настроить несколько серверов глобального каталога или настроить стандартный контроллер домена на кэширование содержимого глобального каталога.
Если используется несколько доменов, важно разработать набор стандартов для административного персонала, в которых будут описываться типы групп, создаваемых в различных ситуациях. В противном случае в результате может получиться несовпадение типов групп, которое значительно усложняет определение прав доступа к ресурсам.
Проектирование доверительных отношений
в лесу из нескольких доменов
Если приходится использовать более одного домена, необходимо принять решение о структурировании доверительных отношений между доменами. В данном случае возможно несколько вариантов, в зависимости от прогнозируемой структуры компании в течение ближайших нескольких лет.
Дерево. Создание непрерывного пространства имен для доменов позволяет добиться самой простой структуры в виде дерева. Отдельные домены в пределах дерева доверяют друг другу с помощью доверительных отношений между родительским и дочерним доменом. Это упрощает поиск LDAP и создание сценариев. Кроме этого, упрощается управление пользователями, поскольку отдельные объекты могут быть" быстро и просто перемещены между различными организационными единицами.
Лес. Если пространство имен DNS не может обеспечить единственного и непрерывного дерева, следующим по эффективности решением является создание леса деревьев. Промышленные конгломераты и университеты часто останавливаются на этой структуре, поскольку пользуются услугами разрозненных и децентрализованных отделов информационных технологий. Каждая компания или институт получает собственный домен верхнего уровня с собственным корневым доменом DNS. Корневые домены доверяют друг другу с использованием доверительного отношения между деревом и корневым доменом. Дочерние домены устанавливают доверительные отношения с помощью транзитивной и двусторонней аутентификации Kerberos.
Федерация. Если не удалось убедить коллег в необходимости слияния отдельных доменов в один лес, подобие единственного элемента безопасности можно создать с помощью доверительного отношения между лесами, которое устанавливается между корневыми
доменами каждого леса. С точки зрения аутентификации Kerberos такое доверительное отношение является транзитивным и двусторонним, что упрощает пользователям доступ к ресурсам. Доверительное отношение между лесами не заменяет истинного доверительного отношения между деревом и корневым доменом. Два леса представляют собой совершенно различные административные элементы. Не существует простого способа перемещения объектов между лесами. Кроме этого, нельзя создавать простые сценарии для управления двумя лесами. Доверительное отношение между лесами является наиболее предпочтительным в ситуации, когда необходимо быстро создать структуру безопасности и подождать до объединения объектов в пределах одного леса.
Смешанные домены. Если используются домены под управлением Windows NT, Samba или сферы MIT Kerberos v5, которые необходимо интегрировать в архитектуру Active Directory, можно создать внешние доверительные отношения или доверительные отношения между сферами Kerberos. Кроме этого, внешние доверительные отношения можно создавать с другими лесами Active Directory, с которыми невозможно создать доверительные отношения между лесами. Доверительные отношения между сферами могут быть двусторонними и транзитивными. Внешние доверительные отношения всегда односторонние и нетранзитивные.
Настройка регистрации для нескольких доменов
Если используется единственный глобальный домен, пользователи могут переехать из Финикса в Сеул, сесть за рабочую станцию, нажать комбинацию клавиш <Ctrl+Alt+Del> и зарегистрироваться с помощью стандартных регистрационных данных. Локальный контроллер домена в Сеуле содержит копию того же контекста именования Domain, который хранится на контроллере домена в Финиксе.
Однако, если используется несколько доменов, придется учить мобильных пользователей одному из двух методов.
Выбирать домашний домен из списка доменов, доступных для регистрации. При этом от пользователя требуется запомнить свой домашний домен, что может казаться подвигом для пользователя, который не может запомнить собственный пароль. Кроме этого, по умолчанию окно регистрации не содержит списка доменов. Для этого придется щелкнуть на кнопке Options (Параметры).
Регистрироваться с использованием основного имени пользователя (User Principal Name — UPN), например t jones@company. com. Если в имени пользователя появляется символ @, список выбора домена становится неактивным.
Система ведет себя одинаково как при использовании основного имени пользователя, так и при регистрации с помощью "плоского" имени и выборе домена. Пользователь проходит аутентификацию по протоколу Kerberos в домене Active Directory и по протоколу NTLM Challenge-Response в домене Windows NT. Использование основного имени пользователя не заставляет клиента “искать” контроллер домена Active Directory в домене, работающем в смешанном режиме. Единственное различие заключается в необходимости поиска в глобальном каталоге для разделения строки на компоненты имени и домена. При создании доверительного отношения между родительским и дочерним доменами в непрерывном пространстве имен DNS дочерний домен автоматически настраивается на использование основного имени пользователя, основанного на имени корневого домена в дереве. Это не относится к лесам, в которых домены или деревья доменов не используют непрерывное пространство имен.
При использовании “раздельного" леса регистрация по основному имени пользователя позволяет назначить всем пользователям суффикс основного имени, что дает пользователям возможность не запоминать домашний домен. Если выбрать “плоское” имя, которое соответ-
ствует названию учетной записи электронной почты, имя пользователя и учетная запись электронной почты будут совпадать. Такой метод нельзя назвать решением с одним набором аутентификационных данных для регйстрации, но он позволяет значительно упростить работу пользователей с двумя системами, требующими аутентификации.
Назначая суффикс основного имени пользователя, можно получить универсальную структуру регистрации, упрощающую обучение. Но в таком случае “плоские” имена должны быть уникальны в пределах всех доменов. При попытке назначения “плоского” имени, которое уже существует в другом домене, контроллер домена обратится к глобальному каталогу для проверки уникальности имени. Если глобальный каталог окажется недоступным, в создании потенциально повторяющегося имени будет отказано. Для назначения суффикса основного имени пользователя можно воспользоваться консолью Active Directory — Domains and Trusts (Active Directory — домены и доверия), как показано в процедуре 8.1.
Сброс основного имени пользователя с помощью сценария
Просматривая вкладку Account (Учетная запись) в свойствах пользователя, можно заметить поле User Logon Name (Регистрационное имя пользователя), в котором указана комбинация "плоского" имени пользователя и суффикса основного имени пользователя. Для любого нового пользователя из списка в окне New User (Новый пользователь) можно выбрать новый суффикс основного имени пользователя.
Но для существующих пользователей для использования нового суффикса придется менять основное имя пользователя. Для быстрого выполнения этой операции можно воспользоваться интерфейсом служб Active Directory (Active Directory Services Interface) посредством сценария. Ниже приведен пример, сценария, который устанавливает в качестве суффикса основного имени пользователя строку @BigCompany.com для пользователей в организационной единице Phoenix домена company. В реальном сценарии будут содержаться процедура проверки ошибок и код проверки на тот случай, если заданное имя уже соответствует требованиям преобразования, что позволит избежать ненужных обновлений.
set OU=GetObject("LDAP://ou=Phoenix,dc=Company,dc=com") OU.filter = Array("User")
NewUPNSuffix = "@BigCompany.com"
For Each User in OU
Wscript.echo "Текущее имя UPN: " & User.UserPrincipalName
Wscript.echo "Текущее регистрационное имя: " & User.SamAccountName User.UserPrincipalName = user.SamAccountName & NewUPNSuffix User.Setinfo
Wscript.echo "Новое имя UPN: " & User.UserPrincipalName Next
Процедура 8.1. Назначение суффикса основного имени пользователя
Щелкните правой кнопкой мыши на пиктограмме Active Directory — domains and trusts (Active Directory — домены и доверия) и выберите из контекстного меню команду Properties (Свойства). Окно Properties (Свойства) показано на рис. 8.5.
В окне Properties (Свойства) присутствует только одна вкладка — UPN Suffixes (Суффиксы UPN). Введите суффикс в поле Alternative UPN Suffixes (Дополнительные UPN- суффиксы) и щелкните на кнопке Add (Добавить).
Чтобы сохранить изменения и закрыть окно, щелкните на кнопке ОК.
Ai I >Vf I •» t i rot у Domains and Trust s rtupetUr*
tixltixlUPN&dSm)
tixl
tixl
-iTopdomanconi-iTopdomanconiThe nanaa ol <■ ctMrt dOMin and Vh tact flimn ан №■ <Ma* uw eexil>dnan»flH6a«*HeM*»*«*lw*aie»> name» Head* addbgnal bgot (MuRr and аацмм ии Iwn ham
-iTopdomanconi
-iTopdomanconi
**♦
Puc. 8.5. В окне Properties (Свойства) открыта вкладка UPN Suffixes (Суффиксы UPN)
Стратегии проектирования организационных единиц
На рис. 8.6 показана принятая по умолчанию структура контекста именования Domain. Преимуществом стандартных контейнеров является простота. Однако, кроме этого, никаких преимуществ стандартные контейнеры не предоставляют. Их можно использовать в небольшой организации, но возможностей стандартных контейнеров недостаточно, если необходимо разграничить сферы управления или области применения групповых политик. Как только администраторы начинают показывать друг на друга пальцами при “загадочных” изменениях объектов или прав в службе каталогов или пользователи из одного отдела требуют настроек настольного компьютера, отличающихся от настроек в другом отделе, значит, пришло время отказаться от использования стандартных контейнеров и начинать проектировать собственную архитектуру.
Обе проблемы (невозможность управления на отдельных уровнях и отсутствие специализированных групповых политик) могут быть решены с помощью размещения объектов Active Directory в отдельных контейнерах и назначения контейнерам различных прав и политик. В Active Directory предоставляется единственный контейнер общего назначения: организационная единица (Organizational Unit — OU). Более обобщенный класс Container доступен только системе. Классы Country, Organization и Locality, определенные в протоколе LDAP, присутствуют в схеме Active Directory, но не предоставляются с помощью стандартных инструментов.
При размещении организационных единиц необходимо рассмотреть несколько факторов.
Организационная единица представляет собой отдельный элемент управления, поскольку поддерживается делегирование прав доступа для организационной единицы и ее дочерних объектов.
Рис. 8.6. Стандартные контейнеры для контекста именования Domain в операционной системе Windoms Server2003
Организационная единица представляет собой отдельный элемент при настройке возможностей пользователя, поскольку для организационных единиц могут быть назначены групповые политики.
Организационная единица выступает в роли инструмента сортировки при создании запросов LDAP. По существу организационные единицы предназначены для структурирования и сохранения порядка в каталоге, что является весьма непростой задачей, если приходится управлять тысячами и тысячами объектов.
Размещение организационных единиц
Контейнер организационной единицы предназначен для разделения управления по функциональным границам внутри организации. Но перед запросом в отдел кадров на получение самой актуальной организационной диаграммы подумайте, кто использует каталог. Пользователи никогда не взаимодействуют с Active Directory напрямую, если администратор не показал, как выполнять поиск. Даже в этом случае большинство операций поиска будут выполняться в пределах всего леса, а не в пределах отдельного домена или организационной единицы. Единственным человеком, кого интересует структура Active Directory, является администратор. Поэтому при составлении организационных единиц желательно ориентироваться на структуру отдела информационных технологий, а не на структуру пользовательских отделов.
Рис. 8.7. Пример организации отдела информационных технологий (ИТ) для компании среднего размера
Подразделения управления
На рис. 8.7 показана структура управления информационными технологиями в организации, состоящей из двух компаний. Основная компания использует главное имя — Company, Inc. Вторая компания полностью принадлежит первой и называется Subsidiary Corp. Обе компании используют общие офисы в нескольких городах. Кроме того что работники завтракают в одном и том же кафе и пользуются услугами одного и того же банка, это совершенно различные элементы управления.
Такое разделение относится и к отделу информационных технологий. Отделы информационных технологий в компаниях Company и Subsidiary не только имеют собственный штат и бюджет, но и обслуживают свои компьютеры в сотню раз лучше, чем те дуралеи, офисы которых расположены в другом крыле подвала. Кроме этого, компания поддерживает небольшую корпоративную группу информационных технологий, но от них требуется составление пятилетних прогнозов по инвестициям и распространение отчетов с помощью Lotus Notes вместо централизованного управления развертыванием технологий.
Административные функции
Если попытаться спроектировать структуру организационной единицы только на основе схемы отдела информационных технологий, можно обречь себя на долгие собрания, в течение которых придется идти от одного призрачного компромисса к другому. И все эти компромиссы растают, как туман утром, когда планы дойдут до верхнего управляющего звена компании.
На организационных диаграммах не отражаются функциональные иерархии, региональные иерархии и отраслевые иерархии, которые действительно влияют на работу отдела информационных технологий. Даже современные прогрессивные компании, нацеленные на обогащение, формируют определенные иерархические структуры между группами, как минимум для того, чтобы определить очередность парковки.
Поэтому не занимайтесь проектированием в закрытом кабинете. Задайте необходимые вопросы другим сотрудникам, даже если вы знакомы с ними несколько лет. Определите, как отдел информационных технологий распределяет обязанности. Это может быть вертикальное распределение по отделам или горизонтальное распределение по регионам. После этого найдите всех администраторов и их начальство и выясните, как они взаимодействуют в процессе работы.
Занимаясь изучением ситуации, не пытайтесь общаться только с теми людьми, название должности которых начинается со слова “Управляющий” или “Администратор”. Ищите скрытые линии ответственности. За пределами структуры отдела информационных технологий можно обнаружить опытных пользователей и специалистов различного калибра, на которых в той или иной степени возложена административная ответственность. Иногда сотрудники корпоративного отдела информационных технологий получают административные привилегии в локальных организациях. Кроме этого, необходимо обнаружить несколько консультантов, на которых возложены административные или управленческие обязанности, но официально эти обязанности начальством не рассматриваются. Другими словами, найдите всех, кому нужны административные привилегии в пределах проектируемого домена или доменов.
После определения истинной административной иерархии инфраструктуры информационных технологий выясните методы взаимодействия различных сотрудников. Определите их административные привилегии и разделите сотрудников на группы с учетом полученных привилегий и областей ответственности.
Организационные единицы более высокого уровня
Получив всю необходимую информацию о структуре информационных технологий, набросайте схему организационных единиц в виде двух уровней.
Верхний уровень определяет административные границы персонала отдела информационных технологий. Например, в нефтяной компании Conoco можно определить две организационные единицы верхнего уровня, Upstream и Downstream, чтобы разделить экономические подразделения с независимым персоналом отделов информационных технологий.
Второй уровень определяет объекты, которые должны иметь одинаковые групповые политики или требуют специальных подходов к управлению. Например, можно возложить задачу обслуживания рабочих станций на стороннюю компанию, поэтому можно создать организационную единицу, в которой будут храниться объекты, права доступа к которым предоставлены сторонней организации.
Верхний уровень организационных единиц используется для делегирования административных привилегий. Например, локальным администраторам можно предоставить полный доступ (Full Control) ко всем объектам в пределах их организационной единицы, не предоставляя никаких прав доступа к объектами в других организационных единицах. Это позволяет разделить административные привилегии.
Нижний уровень (или уровни) организационных единиц используется для назначения групповых политик (немного ниже эта тема будет рассматриваться более подробно) отделам, которые требуют отдельных административных прав для управления собственным оборудованием, группами или пользователями. Часто менеджеры готовы доверять центральному отделу информационных технологий управление оборудованием, но требуют разделения административных полномочий для управления пользователями и группами.
Не нужно быть магистром, чтобы понять, что ответственность за управление должна быть смещена на самые нижние уровни организации. В результате проектирования необходимо достичь централизованного управления структурой каталога и локализованного управления объектами каталога. Если сказать в двух словах, то несколько администраторов верхнего уровня могут создавать и модифицировать организационные единицы в пределах домена, а локальные администраторы будут создавать, модифицировать, удалять и менять разрешения для объектов в пределах своих организационных единиц.
Децентрализованная работа
На рис. 8.8 показана структура организационных единиц верхнего уровня для домена, который включает в себя большую часть США, Мексики и часть Центральной Америки. Компания состоит из двух организаций. Дочерняя организация совместно использует оборудование в двух офисах компании и собственное оборудование в двух удаленных офисах.
Компания имеет несколько департаментов с как будто независимым персоналом информационных отделов. Например, отдел кадров настаивает, что конфиденциальный характер данных на их серверах и жестких дисках (они до сих пор не доверяют сети) требует, чтобы только представители их собственного административного персонала управляли ресурсами отдела.
Структура контейнеров верхнего уровня делит домен по географическому признаку, поскольку в каждом офисе есть собственный персонал для обеспечения работы компьютеров. Департаменты с собственными отделами информационных технологий получают отдельные контейнеры, соответствующие их офису. Это позволяет локальному персоналу управлять подчиненными контейнерами вместо того, чтобы пользоваться услугами централизованного отдела информационных технологий. Организационная единица Солт_Лейк_Сити является противоположным примером. Локальные администраторы не против вхождения в организа-
ционную единицу Финикс, но персонал организационной единицы Финикс не желает, предоставлять им привилегий администраторов.
При проектировании практически все организационные единицы находятся близко к вершине каталога. Горизонтально ориентированная структура каталога не несет с собой снижения производительности. На самом деле справедливо обратное утверждение. Желательно избегать слишком глубоких вложенных структур на основе организационных единиц. Возможности индексирования и кэширования в механизме управления базой данных Active Directory легко поддерживают до 10 уровней вложенности. Увеличение глубины вложенности возможно, но не рекомендуется. Если поддерживать неглубокую структуру контейнеров становится сложнее, обратитесь за поддержкой к инженеру компании Microsoft и совместно выработайте приемлемое решение для конкретной ситуации.
Централизованное управление
Структура организационных единиц из предыдущего примера значительно изменится, если в компании существует централизованный отдел информационных технологий с широкими полномочиями, а системные администраторы в офисах часто подвергаются аудиту и оценкам производительности. В таком случае можно избавиться от верхнего уровня каталога, как показано на рис. 8.9.
Структура контейнеров для централизованного отдела информационных технологий используется для разделения полномочий между автономными группами отдела. В такие контейнеры включаются пользователи, группы, компьютеры, принтеры и общие каталоги, которые управляются соответствующей автономной группой без учета географического положения управляемых объектов. Каталог реплицируется на все контроллеры домена, поэтому контейнер Служба поддержки пользователей может содержать объекты пользователей из Финикса, Хьюстона и Мехико. Обратите внимание, что администраторы в дочерней компании не доверяют централизованному отделу информационных технологий и настаивают на использовании собственного пространства имен, связанного с лесом с помощью доверительного отношения, которое устанавливается между деревом и корневым доменом.
Параметры отображения и локализация
Специальные объекты схемы Active Directory, которые называются параметрами отображения (Display Specifies), обеспечивают перевод содержимого объектов. Параметры отображения определяют выбранную при установке рабочей станции или сервера группу языков и соответствующим образом фильтруют содержимое объекта. Использование параметров отображения позволяет выводить названия полей и параметров объектов каталога на испанском языке, если они просматриваются административным персоналом в Мехико.
Subsidiary.comSubsidiary.comCompany.comCompany.comWebWebФиникс Хьюстон Денвер АльбукеркеФиникс Хьюстон Денвер Альбукеркекомпьютеров пользователей инфраструктурыкомпьютеров пользователей инфраструктурыСлужба поддержкиСлужба поддержкиСлужба поддержкиСлужба поддержкиТранзитивные доверительные отношения между деревом и корневым доменомТранзитивные доверительные отношения между деревом и корневым доменомСлужба аудитаСлужба аудитаСлужбаРазработкаподдержки ПОСлужбаРазработкаподдержки ПОРис. 8.9. Структура контейнеров верхнего уровня для централизованного отдела информационных технологий с дочерней организацией, выделенной в отдельный домен лесаРис. 8.9. Структура контейнеров верхнего уровня для централизованного отдела информационных технологий с дочерней организацией, выделенной в отдельный домен леса
Subsidiary.com
Subsidiary.com
Company.com
Company.com
Web
Web
Финикс Хьюстон Денвер Альбукерке
Финикс Хьюстон Денвер Альбукерке
компьютеров пользователей инфраструктуры
компьютеров пользователей инфраструктуры
Служба поддержки
Служба поддержки
Служба поддержки
Служба поддержки
Транзитивные доверительные отношения между деревом и корневым доменом
Транзитивные доверительные отношения между деревом и корневым доменом
Служба аудита
Служба аудита
СлужбаРазработка
поддержки ПО
СлужбаРазработка
поддержки ПО
Рис. 8.9. Структура контейнеров верхнего уровня для централизованного отдела информационных технологий с дочерней организацией, выделенной в отдельный домен леса
Рис. 8.9. Структура контейнеров верхнего уровня для централизованного отдела информационных технологий с дочерней организацией, выделенной в отдельный домен леса
Организационные единицы нижнего уровня
В правилах создания организационных единиц нижнего уровня принято больше ориентироваться на управление компьютерами и пользователями, чем на делегирование административных привилегий. Такое управление тем или иным образом подразумевает управление возможностями пользователей. Наиболее подходящим для этих целей инструментом являются групповые политики (group policies).
В главе 12, “Управление групповыми политиками”, групповые политики рассматриваются более подробно. Здесь рассматриваются особенности групповых политик, которые необходимы для принятия решений при проектировании организационных единиц. Групповые политики являются набором инструкций, которые загружаются с аутентификационного сервера современными клиентами Windows (Windows 2000 и Windows ХР) и вносятся в локальный
системный реестр и базы данных безопасности. В операционной системе Windows Server 2003 существует 13 типов политик. Этими политиками поддерживаются следующие операции.
Обновление системного реестра (так называемые Administrative Templates — Административные шаблоны)
Обновления системы безопасности
Регистрационные сценарии
Распространение программного обеспечения
Перенаправление каталогов
Управление дисковыми квотами
Управление беспроводными сетями
Ограничение доступного программного обеспечения
Распространение открытых ключей
Управление политиками IPSec
Управление Internet Explorer
Управления службами удаленной установки
Управление качеством обслуживания
Связи групповых политик
Групповые политики связаны с контейнерами Active Directory. Именно так клиенты определяют, какие к ним применяются политики. Групповые политики могут быть связаны со следующими контейнерами, перечисленными в порядке возрастания приоритета.
Сайты
Домены
Организационные единицы
Политики устанавливаются в дереве Active Directory по принципу “сверху вниз”. Другими словами, сначала пользователи и компьютеры наследуют политики, назначенные родительской организационной единице и организационным единицам верхних уровней, затем наследуются политики домена, а затем — политики локального сайта.
Список политик, применяющихся к конкретному пользователю или компьютеру, называется резулътируюгцим набором политик (Resultant Set of Policies — RSoP). В состав операционной системы Windows Server 2003 входит новая утилита, которая предоставляет сведения о результирующем наборе политик для пользователя или компьютера. На рис. 8.10 показан пример наследования политик в дереве и то, что означает информация о результирующем наборе политик.
Вот главное правило: чем ближе объект групповой политики расположен к пользователю или компьютеру в дереве Active Directory, тем выше приоритет политик в объекте групповой политики. Например, политика «Скрывать пиктограмму “Мой компьютер”», связанная с непосредственной организационной единицей для пользовательского объекта, переопределит политику «Не скрывать пиктограмму “Мой компьютер”», связанную с организационной единицей, находящейся выше по дереву.
Как будет показано в главе 12, “Управление групповыми политиками”, в отдельной организационной единице можно заблокировать наследование групповых политик, чтобы объекты ниже по дереву не наследовали никаких групповых политик, связанных с сайтами, доменами и другими организационными единицами, находящимися выше по дереву. Кроме этого, можно переопределить блокировку наследования политик, чтобы администраторы подчиненных организационных единиц не могли запретить своим пользователям применять политики, определенные центральным административным персоналом.
Company.com
Рис. 8.10. Структура доменов и организационных единиц, в которой показаны унаследованные групповые политики и результирующее множество политик
Компоненты групповой политики
Групповые политики имеют два различных компонента, которые обеспечивают доставку политик клиенту для последующей обработки.
Контейнер групповой политики (Group Policy Container — GPC). Контейнер групповой политики представляет собой объект Active Directory, который определяет имя политики, расширение на стороне клиента для обработки политики, расположение инструкций для политики и описывает контейнер, с которым связана групповая политика. Контейнер групповой политики расположен в контейнере cn=Policies,cn=System,dc=<HMH_/roMeHa>,clc=<KopeHb> в контексте именования Domain. Для просмотра этого контейнера можно воспользоваться консолью Active Directory — Users and Computers (Active Directory — пользователи и компьютеры) в режиме расширенных функциональных возможностей. На рис. 8.11 показан пример политики, в которой описывается политика распространения программного обеспечения. В этом случае в Active Directory вносится дополнительная информация.
-bWJ-bWJ№ РЭ DomaHJodates® "^3 ^^® Replication Serviceйг Qj FileUnks£ uJ IP SecuritySi- Pj Meetings® О McrosoftDNS8 Pl Policies\ В u]{31B2F340-016D-HD2-94^-00C04FB9 О Machine№ РЭ DomaHJodates® "^3 ^^® Replication Serviceйг Qj FileUnks£ uJ IP SecuritySi- Pj Meetings® О McrosoftDNS8 Pl Policies\ В u]{31B2F340-016D-HD2-94^-00C04FB9 О Machine33^ с7Гес061-9сЬ4-1вв4-в0ее-2с09вав1Н5в9^ с7Гес061-9сЬ4-1вв4-в0ее-2с09вав1Н5в9шваккет |^ Fit .Action Wow Window Help > -* i®;®! X *!:X Iff
-bWJ
-bWJ
№ РЭ DomaHJodates
® "^3 ^^® Replication Service
йг Qj FileUnks
£ uJ IP Security
Si- Pj Meetings
® О McrosoftDNS
8 Pl Policies
\ В u]{31B2F340-016D-HD2-94^-00C04FB9 О Machine
№ РЭ DomaHJodates
® "^3 ^^® Replication Service
йг Qj FileUnks
£ uJ IP Security
Si- Pj Meetings
® О McrosoftDNS
8 Pl Policies
\ В u]{31B2F340-016D-HD2-94^-00C04FB9 О Machine
3
3
^ с7Гес061-9сЬ4-1вв4-в0ее-2с09вав1Н5в9
^ с7Гес061-9сЬ4-1вв4-в0ее-2с09вав1Н5в9
U] {6AC1786C-016F-11 D2-945F-00C04fB9
Si Pj Machine
Si LJ RAS and IAS Servers Access Check it! ^ RpcServices
® ~ I WinsockServices
1
Рис.8.11. Контейнер Policies на консоли Active Directory — Users and Computers
■ Шаблон групповой политики (Group Policy Template — GPT). Шаблон групповой политики представляет собой набор инструкций, связанных с определенной групповой политикой. Например, в политике аутентификации шаблон будет содержать сценарий. В политике Administrative Template (Реестр) будет присутствовать шаблон групповой политики, включающий в себя запись в файл Registry.pol. Клиенты загружают файлы шаблонов групповых политик и выполняют локальную обработку. Файлы конкретного шаблона групповой политики расположены в каталоге \Windows\Sysvol\Sysvol\ <имя_домена>\<название_политики>. Содержимое каталога Sys vol реплицируется на все контроллеры домена средствами службы репликации файлов (FRS).
Набор двух компонентов групповой политики называется объектом групповой политики (Group Policy Object — GPO). Компания Microsoft некстати решила использовать термин “объект групповой политики”, так как обычно в качестве объекта воспринимается запись в базе данных Active Directory, а объект групповой политики определяет одновременно и объект в базе данных, и набор файлов шаблонов.
При создании новой групповой политики для нее устанавливается связь с организационной единицей, доменом или сайтом. При следующей загрузке компьютеров из этого контейнера или регистрации пользователей из этого контейнера будет загружена соответствующая политика. Политики Administrative Template применяются в оперативной памяти, чтобы не засорять системный реестр, как это было в случае системных политик Windows NT.
Инструменты для работы с групповыми политиками
Групповые политики создаются и настраиваются с использованием редактора групповых политик (Group Policy Editor — GPE). Для запуска редактора групповых политик необходимо открыть окно Properties (Свойства) для контейнера, с которым должен быть связан объект групповой политики, и активизировать вкладку Group Policy (Групповая политика). На рис. 8.12 показаны принятые по умолчанию групповые политики, связанные с контейнером домена.
При добавлении или изменении групповых политик в редакторе система немедленно создает или обновляет соответствующий контейнер групповой политики и файлы шаблонов групповой политики. Предупреждений наподобие “Вы уверены, что хотите это сделать?” не выдается.
»Й1Х|»Й1Х|Gyrate Root^H ^ Defaufc Domain Poky [server! .company?Й Д Computer Cortflgu-ation$ CS Software Settingsit! ^3 Windows Settings® О Administrative TemplatesS jjP User Configuration ® -23 Software Settings ®- £3 Windows Settings Й ^ Administrative Templatesffl- О Windows ComponentsGyrate Root^H ^ Defaufc Domain Poky [server! .company?Й Д Computer Cortflgu-ation$ CS Software Settingsit! ^3 Windows Settings® О Administrative TemplatesS jjP User Configuration ® -23 Software Settings ®- £3 Windows Settings Й ^ Administrative Templatesffl- О Windows ComponentsRemove Documents menu from Start MenuRemove Documents menu from Start MenuDisplay PropertiesDisplay PropertiesRequirements:At least Microsoft Windows 2000Requirements:At least Microsoft Windows 2000Description:Removes the Documents menu from the Start menu.Description:Removes the Documents menu from the Start menu.BIBIГ1 Desktop Г‘1 Control Panel П} Shared Folders lJ Network ■r-1 SystemГ1 Desktop Г‘1 Control Panel П} Shared Folders lJ Network ■r-1 SystemThe Documents menu contains inks to the nonprogram files that users have most recently opened. It appears so that users can easiy reopen their documents.The Documents menu contains inks to the nonprogram files that users have most recently opened. It appears so that users can easiy reopen their documents.UL—UL—^ Remove user's feeders from the Start Menu W Remove inks and access to Windows Update ^T Remove common program groups from Start Menu^ Remove user's feeders from the Start Menu W Remove inks and access to Windows Update ^T Remove common program groups from Start MenuIf you enable this setthg, the system saves document shortcuts but does not dteplay them in the Documents menu. If you Iker disable it or set itIf you enable this setthg, the system saves document shortcuts but does not dteplay them in the Documents menu. If you Iker disable it or set itу ^ Remove Network Connections from Start Menu< ^| Remove Favorites menu from Start Menu< ^1 Remove Search menu from Start Menu^| Remove Help menu from Start Menu^1 Remove Run menu from Start Menuл^ Remove My Pictures icon from Start Menu^Remove My Musk icon from Start MenuIff Remove My Network Places icon from Start Menu ^( Add Logoff to the Start Menuу ^ Remove Network Connections from Start Menu< ^| Remove Favorites menu from Start Menu< ^1 Remove Search menu from Start Menu^| Remove Help menu from Start Menu^1 Remove Run menu from Start Menuл^ Remove My Pictures icon from Start Menu^Remove My Musk icon from Start MenuIff Remove My Network Places icon from Start Menu ^( Add Logoff to the Start Menu
»Й1Х|
»Й1Х|
Gyrate Root^
H ^ Defaufc Domain Poky [server! .company?
Й Д Computer Cortflgu-ation
$ CS Software Settings
it! ^3 Windows Settings
® О Administrative Templates
S jjP User Configuration ® -23 Software Settings ®- £3 Windows Settings Й ^ Administrative Templates
ffl- О Windows Components
Gyrate Root^
H ^ Defaufc Domain Poky [server! .company?
Й Д Computer Cortflgu-ation
$ CS Software Settings
it! ^3 Windows Settings
® О Administrative Templates
S jjP User Configuration ® -23 Software Settings ®- £3 Windows Settings Й ^ Administrative Templates
ffl- О Windows Components
Remove Documents menu from Start Menu
Remove Documents menu from Start Menu
Display Properties
Display Properties
Requirements:
At least Microsoft Windows 2000
Requirements:
At least Microsoft Windows 2000
Description:
Removes the Documents menu from the Start menu.
Description:
Removes the Documents menu from the Start menu.
BI
BI
Г1 Desktop Г‘1 Control Panel П} Shared Folders lJ Network ■r-1 System
Г1 Desktop Г‘1 Control Panel П} Shared Folders lJ Network ■r-1 System
The Documents menu contains inks to the nonprogram files that users have most recently opened. It appears so that users can easiy reopen their documents.
The Documents menu contains inks to the nonprogram files that users have most recently opened. It appears so that users can easiy reopen their documents.
UL
—
UL
—
^ Remove user's feeders from the Start Menu W Remove inks and access to Windows Update ^T Remove common program groups from Start Menu
^ Remove user's feeders from the Start Menu W Remove inks and access to Windows Update ^T Remove common program groups from Start Menu
If you enable this setthg, the system saves document shortcuts but does not dteplay them in the Documents menu. If you Iker disable it or set it
If you enable this setthg, the system saves document shortcuts but does not dteplay them in the Documents menu. If you Iker disable it or set it
у ^ Remove Network Connections from Start Menu
< ^| Remove Favorites menu from Start Menu
< ^1 Remove Search menu from Start Menu
^| Remove Help menu from Start Menu
^1 Remove Run menu from Start Menu
л^ Remove My Pictures icon from Start Menu
^Remove My Musk icon from Start Menu
Iff Remove My Network Places icon from Start Menu ^( Add Logoff to the Start Menu
у ^ Remove Network Connections from Start Menu
< ^| Remove Favorites menu from Start Menu
< ^1 Remove Search menu from Start Menu
^| Remove Help menu from Start Menu
^1 Remove Run menu from Start Menu
л^ Remove My Pictures icon from Start Menu
^Remove My Musk icon from Start Menu
Iff Remove My Network Places icon from Start Menu ^( Add Logoff to the Start Menu
7m dompol [Console Root Default Domain Policy [setverl.company.com] Policy tb*t i .1и1«цшаГнм«
Puc. 8.12. Окно редактора групповых политик, в котором показаны принятые по умолчанию политики домена
Групповые политики и проектирование
организационных единиц
Групповые политики широко используются для управления пользователями и компьютерами в домене Active Directory, поэтому их важно учитывать при проектировании организационных единиц низкого уровня. Например, менеджер отдела продаж может потребовать жестких настроек для рабочих станций персонала отдела, чтобы сотрудники отдела занимались своей основной работой, а не настраивали компьютер. С другой стороны, руководитель сборочного цеха может заявить, что даже минимальные ограничения параметров рабочих станций могут оказаться слишком жесткими.
На рис. 8.13 показан пример проекта организационной единицы, в котором учитываются созданные групповые политики. Каждый проект отличается от остальных, но существуют базовые компоненты, которые показаны на этом примере.
■ Users. В этом контейнере содержатся учетные записи всех пользователей из офиса в Финиксе, кроме отдела кадров и сборочного цеха, который подключается к локальной сети офиса в Финиксе по внешнему каналу. Размещение всех пользователей в единственном контейнере позволяет делегировать административный контроль над контейнером и определять групповые политики. Подчиненный контейнер для отдела продаж обеспечивает использование других групповых политик в соответствии с руководством отдела. Теоретически для каждого департамента можно создать собственную организационную единицу с соответствующим набором групповых политик.
■ Groups. Групповые политики нельзя назначать группам (можно только пользователям и компьютерам). Но этот контейнер обеспечивает определенный порядок структуры. Автор этой книги предпочитает хранить объекты групп в отдельном контейнере, что значительно облегчает поиск интересующей группы. Размещение группы и ее членов в разных контейнерах не приводит к снижению производительности.
■ Field. Этот контейнер предоставляет возможность отдельного хранения объектов для удаленных точек: рабочих мест и временных офисов. Отдельный контейнер служит для
двух целей. Во-первых, групповые политики выездного персонала оказываются менее ограничивающими по сравнению с групповыми политиками для стационарного персонала. Во-вторых, выездные операции обычно сопровождаются техническим персоналом, который не обладает полными административными привилегиями. Отдельный контейнер позволяет назначать техническому персоналу ограниченные административные права по отношению к соответствующим пользователям и компьютерам.
Company.comCompany.com6 1 111 МГ ЙП ПА16 1 111 МГ ЙП ПА1SubsidiarySubsidiaryPHX.Company.eom HOU.Company.comPHX.Company.eom HOU.Company.comВСВСDALDALSaft_LakeSaft_LakeICICPanamaPanamanilPhoenix Houston Denver AlbuquerquenilPhoenix Houston Denver AlbuquerqueHardwareHardwareUsersUsersGroups FieldGroups FieldISISHRHRPrintersPrintersWorkstationsWorkstationsServersServersSalesSales
Company.com
Company.com
6 1 111
МГ ЙП ПА1
6 1 111
МГ ЙП ПА1
Subsidiary
Subsidiary
PHX.Company.eom HOU.Company.com
PHX.Company.eom HOU.Company.com
ВС
ВС
DAL
DAL
Saft_Lake
Saft_Lake
IC
IC
Panama
Panama
nil
Phoenix Houston Denver Albuquerque
nil
Phoenix Houston Denver Albuquerque
Hardware
Hardware
Users
Users
Groups Field
Groups Field
IS
IS
HR
HR
Printers
Printers
Workstations
Workstations
Servers
Servers
Sales
Sales
QA-QC
PUc. 8.13. Структура контейнеров нижнего уровня для одного домена в многодоменном каталоге
IS и HR. Эти контейнеры представляют отдельные единицы управления, которые обеспечивают автономию определенной группе персонала. Конечно, существует опасность, что администратор контейнера HR может каким-либо образом нарушить свою часть каталога так, что даже представитель центрального отдела информационных технологий не сможет исправить ситуацию.
Printers и Shared_Folders. В этих контейнерах близко к вершине каталога содержатся элементы, которые часто ищут пользователи. Чем меньше контейнеров приходится открывать пользователю при поиске интересующего элемента, тем выше вероятность, что пользователи будут применять каталог. Если доступ к каталогу не сделать элементарно простым, то пользователи всегда начнут просматривать все каталоги подряд, включая лишние и ненужные им каталоги.
Hardware. В этом контейнере содержится два отдельных контейнера для хранения объектов Computer: один — для рабочих станций, а второй — для серверов. Таким образом, компьютерами разного класса можно управлять по отдельности. Администраторам рабочих
станций или сотрудникам службы технической поддержки могут быть предоставлены административные права по отношению к контейнеру с рабочими станциями (workstations). Доступ к контейнеру с серверами (Servers) будет предоставлен исключительно сетевым администраторам. Размещение компьютеров и пользователей в одном контейнере не дает никаких преимуществ. Намного проще искать интересующий объект в контейнере, который не засорен объектами различных классов.
После создания проекта организационных единиц нижнего уровня начинайте сбор информации от других администраторов по проектированию их областей ответственности и управления. Рассчитывайте, что этот этап займет некоторое время даже в небольшой организации. Может потребоваться оборудование небольшой лаборатории, в которой будут проверены типичные операции.
Упрощенная структура подразделений
При работе в небольшой организации или консультировании небольших и средних компаний можно обнаружить, что показанный на рис. 8.13 проект слишком сложный. На рис. 8.14 показана структура каталога для небольшой организации.
При ограниченном количестве административного персонала административные задачи возлагаются на опытных пользователей, работающих в соответствующих отделах. Именно по этой причине в проекте на рис. 8.14 контейнеры нижнего уровня разделены по функциональному предназначению. В каждой организационной единице административные привилегии могут быть предоставлены определенной группе, а главный администратор может вносить изменения в список членов группы в зависимости от запросов менеджера отдела.
Рис. 8.14. Проект каталога для небольшой компанииРис. 8.14. Проект каталога для небольшой компании
Рис. 8.14. Проект каталога для небольшой компании
Рис. 8.14. Проект каталога для небольшой компании
В любом случае оставляйте пространство для маневра и не бойтесь перестраивать структуру проекта в результате изменений рабочего процесса отдела информационных технологий. Пока в результате проектирования не приходится создавать отдельный домен и при использовании групповых политик не применяется излишняя изобретательность, все изменения можно вносить незаметно для пользователей.
Теперь, когда рассмотрены необходимые проектные решения при подготовке к развертыванию каталога, пора обратить внимание на несколько вспомогательных операций, которые подразумевают размещение серверов специального назначения.
Хозяева операций
В среде репликации с несколькими контроллерами домена, выполняющими роли хозяев, любой контроллер домена теоретически может менять любой объект в базе данных Active Directory. Как было показано в предыдущей главе, в Active Directory предоставляются специальные возможности для обработки конфликтующих обновлений, внесенных в течение одного интервала репликации.
Определенные функции Active Directory просто не могут использоваться одновременно на нескольких компьютерах, не приводя к потенциальному нарушению целостности данных. Такие специальные функции называются Flexible Single Master Operations (FSMO). Контроллер домена, выделенный для выполнения определенной функции FSMO, называется хозяином операции (role master). Существует пять таких операций. Ниже приводится список функций FSMO и названий консолей, которые могут использоваться для просмотра и назначения хозяев операций.
Роль PDC Emulator — консоль Active Directory — Users and Computers (Active Directory — пользователи и компьютеры)
Роль RID Master — консоль Active Directory— Users and Computers (Хозяин относительных идентификаторов — Active Directory — пользователи и компьютеры)
Роль Infrastructure Master — Active Directory — консоль Users and Computers (Хозяин инфраструктуры — Active Directory — пользователи и компьютеры)
Роль Domain Naming Master — Active Directory — Domains and Trusts (Хозяин именования доменов — Active Directory — домены и доверия)
Роль Schema Master (Хозяин схемы) — специальная консоль, которая содержит оснастку Active Directory Schema (Схема Active Directory)
Идентификация хозяина операций
Щелкнув правой кнопкой на пиктограмме соответствующей консоли ММС и выбрав Operations Master (Хозяин операций), можно определить хозяина операции. Откроется окно Operations Master, в котором будут присутствовать вкладки для всех операций, которые управляются данной консолью ММС.
Хозяева операций обозначаются в базе данных Active Directory с помощью специального атрибута, который называется FSMORoleOwner. Этот атрибут назначается объекту, который управляет функцией с единственным хозяином. Атрибут FSMORoleOwner связывается со следующими объектами.
PDC Emulator — контейнер Domain
Хозяин относительных идентификаторов (RID Master) — объект rid Manager?, который хранится в контейнере cn=System, dc=< домен>, ал-<корень>
Хозяин инфраструктуры (Infrastructure Master) — контейнер infrastructure в контейнере &с=<домен>,&с=<корень>.
Хозяин схемы (Schema Master) — контейнер Schema
Хозяин именования доменов (Domain Naming Master)— контейнер Partitions в контейнере cn=Configuration,dc=<домен>, <1с=<корень>
Для просмотра хозяев операций можно воспользоваться файлом пакетной обработки Dumpfsmos.cmd, который входит в состав Resource Kit. Для отображения перечня хозяев операций файл использует утилиту ntosutil. Синтаксис команды выглядит следующим образом:
dumpfsmos <имя_контроллера_домена>
PDC Emulator
Active Directory поддерживает использование резервных контроллеров домена под управлением операционной системы WindowsNT. Для этого Active Directory на контроллере домена под управлением операционной системы Windows Server 2003 “представляется” для резервных контроллеров как основной контроллер домена Windows NT. Это необходимо, поскольку резервные контроллеры домена поддерживают репликацию только с основного контроллера домена (PDC). Один из контроллеров домена назначается хозяином роли PDC Emulator.
PDC Emulator упаковывает обновления Active Directory, относящиеся к объектам из классической базы данных SAM, и реплицирует эти обновления на резервные контроллеры домена (BDC) с помощью механизма LanMan Replication. При работе домена в режиме Mixed объекты участников системы безопасности (пользователи, компьютеры и группы) могут создаваться только на контроллере домена, который выступает в роли PDC Emulator.
После отключения всех контроллеров домена под управлением более ранних версий Windows домен можно переключить в режим Native. Затем останавливают службу LanMan Replication и резервные контроллеры домена прекращают получать обновления. Однако на самом деле резервные контроллеры домена продолжают работать, все больше и больше теряя актуальность, как рок-группы в 60-х годов прошлого века.
После начала перехода на Active Directory повышение резервного контроллера домена до основного контроллера данных невозможно. Но роль PDC Emulator можно передать другому контроллеру домена под управлением Windows Server 2003 (или под управлением Windows 2000, если домен все еще работает на функциональном уровне 0). С точки зрения резервных контроллеров домена это выглядит как повышение. Резервные контроллеры домена переключаются на новый PDC Emulator и начинают получать обновления у него.
Клиенты под управлением операционных систем Windows Эх и Windows NT, которые являются членами домена, “знают”, что основной контроллер домена является единственным сервером, которому разрешена запись в базу данных SAM. Таким образом, если клиенту необходимо изменить пароль, клиент связывается непосредственно с основным контроллером домена. В современных операционных системах Windows любой контроллер домена может вносить изменения в пароли пользователей, но клиенты более старых версий об этом не знают. PDC Emulator является тем местом, куда клиенты устаревших версий обращаются для изменения паролей или внесения других изменений в классическую базу данных SAM.
Обновление процесса регистрации для клиентов устаревших версий
Заплата dsclient на установочном компакт-диске операционной системы Windows Server 2003 изменяет поведение клиентов под управлением операционной системы Windows Эх, позволяя менять пароль на любом контроллере домена, а не только на PDC Emulator. Обновление для Windows NT 4.0, доступное на сайте компании Microsoft, обеспечивает такое же изменение функциональных возможностей для клиентов Active Directory под управлением операционной системы Windows NT 4.0.
Также эта заплата меняет механизм аутентификации для клиентов под управлением операционных систем Windows 9х/МЕ. После исправления используется механизм NTLM Challenge- Response version 2, а не LanMan Challenge-Response. Классические клиенты под управлением операционной системы Windows NT Service Pack 3 и более поздних версий уже используют механизм NTLMv2. Исправление Active Directory для клиентов устаревших версий не обеспечивает использование протокола Kerberos.
Кроме обслуживания резервных контроллеров домена, компания Microsoft возложила на PDC Emulator дополнительные операции. Например, как было показано в главе 7, “Управление репликацией Active Directory”, PDC Emulator является основным источником точного времени для контроллеров домена. Существует еще три задачи, которые выполняются на ; PDC Emulator.
Окончательная проверка изменений паролей
При изменении пароля пользователя или при сбросе пользовательского пароля администратором обновление реплицируется на PDC Emulator по принципу “наибольшего приоритета”. Это значит, что игнорируются расписания промежуточных межсайтовых связей.
Контроллеры домена используют PDC Emulator в качестве “последней инстанции” при проверке правильности пароля. Если пользователь вводит неправильный пароль, локальный контроллер домена обращается к PDC Emulator, чтобы проверить ситуацию, когда пользователь ввел правильный пароль, но изменение еще не достигло контроллера домена. В таком случае пользователю предоставляется доступ. Эта возможность предотвращает звонки пользователей в службу поддержки сразу после изменения пароля.
Предпочтительное расположение групповых политик
Групповые политики состоят из двух компонентов: контейнера групповой политики (Group Policy Container — GPC), хранящегося в базе данных Active Directory, и шаблона групповой политики (Group Policy Template — GPT), который хранится в каталоге \Windows\ Sysvol\Sysvol\<HMH_доменах Если синхронизация компонентов окажется нарушенной, пользователь может попытаться получить политику, шаблон которой еще отсутствует в папке Sysvol, или не сможет получить политику, так как соответствующий контейнер еще не был реплицирован на регистрационный сервер.
Чтобы избежать возникновения таких проблем и других нарушений целостности, которые могут возникать при репликации с использованием нескольких хозяев, при запуске редактора групповых политик основным указывается PDC Emulator. При таком механизме все администраторы смогут вносить модификации в групповые политики на единственном компьютере, снижая вероятность проблем синхронизации.
Отключение проверки при вводе неправильного пароля
Проверка при вводе неправильного пароля приводит к повышению нагрузки на PDC Emulator и на внешний канал, который используется для доступа к PDC Emulator. Если PDC Emulator и локальный контроллер домена находятся на различных сайтах, проверку при вводе неправильного пароля можно отключить. Для этого необходимо внести изменения в системный реестр локального контроллера домена:
Раздел: HKLM\CurrentControlSet\Services\Netlogon\Parameters
Запись: AvoidPDCConWAN
Значение: 1
Если PDC Emulator недоступен (из-за отказа сервера или нарушения в работе внешнего канала), будет предложено выбрать другой контроллер домена или подождать, пока не станет доступен PDC Emulator. Если есть уверенность, что изменения не будут конфликтовать с изменениями, внесенными другим администратором, можно выбрать другой контроллер домена.
Помните об этом, обновляя групповые политики. Если PDC Emulator подключен через несколько низкоскоростных каналов, до обновления экрана может пройти некоторое время.
Основной обозреватель домена (Master Browser)
В некоторых отношениях операционную систему Windows можно сравнить с волком. Сколько волка не корми, а он все равно в лес смотрит.
Примером такого поведения является просмотр (browsing). Автор этой книги не знает ни одной функции Windows, которая не приводила бы к возникновению такого количества проблем при администрировании.
Современные операционные системы Windows не требуют возможности просмотра. Принтеры можно “объявить" в Active Directory. Распределенную файловую систему (Distributed File System — DFS) можно использовать в качестве уровня абстракции над общими каталогами независимо от серверов хранения информации. Но по какой-то причине пользователи предпочитают открыть окно Му Network Places (Мое сетевое окружение) и перебирать контейнеры в поисках необходимых ресурсов. Операционная система Windows Server 2003 обеспечивает обратную совместимость с процессом просмотра. Рабочие станции под управлением операционных систем Windows Server 2003 и Windows ХР принимают участие в “выборах" обозревателя на равных с рабочими станциями и серверами под управлением операционной системы Windows NT 4.0. В случае победы на выборах компьютер становится Subnet Master Browser — главным обозревателем сети.
На предприятии, использующем маршрутизацию, просмотр зависит от единственного сервера, Domain Master Browser (Основной обозреватель домена), который объединяет базы данных обозревателей подсетей и распространяет полный список серверов. В классическом домене WindowsNT в роли Master Browser использовался основной контроллер домена — РОС. В домене Active Directory эта задача возлагается на PDC Emulator.
Служба WINS играет важную роль в процессе просмотра благодаря предоставлению этой службой IP-адресов Domain Master Browser и Subnet Master Browser. Важно, чтобы PDC Emulator являлся клиентом WINS и регистрировал соответствующие записи для обозревателей.
Хозяин относительных идентификаторов —
RID Master
Для всех объектов системы безопасности создается идентификатор безопасности. Идентификатор безопасности представляет собой комбинацию идентификатора безопасности домена и порядкового номера, который называется относительным идентификатором (Relative ID — RID). В классическом домене Windows NT участники системы безопасности, добавленные после установки операционной системы, получали относительные идентификаторы начиная с номера 1000. Ниже представлен пример нескольких идентификаторов безопасности в пределах домена:
PhxUserl: S-1-5-21-515967899-764733703-1708537768-1000
XP-WKS-01$: S-l-5-21-515967899-764733703-1708537768-1001 PhxAdmins: S-l-5-21-515967899-'7647337 03-17 08537768-1002 PhxUser2: S-l-5-21-515967899-764733703-1708537768-1003
Обратите внимание, что последние четыре цифры, которые обозначают идентификатор RID для идентификатора безопасности SID, увеличиваются по порядку. В режиме Native, в котором участников системы безопасности может создавать любой контроллер домена, относительные идентификаторы RID могут назначаться без учета последнего предоставленного порядкового номера, но они должны быть уникальны. По этой причине только один контроллер домена может распоряжаться пулом относительных идентификаторов. Этот контроллер домена называют хозяином относительных идентификаторов, или RID Master. Доступные относительные идентификаторы хранятся в атрибуте, который называется RiDAllocationPool.
В режиме Mixed контроллеры домена, на которые возложены роли RID Master и PDC Emulator, постоянно сохраняют контакт, поскольку только PDC Emulator может создавать участников системы безопасности. В режиме Native контроллер домена, выполняющий роль RID Master, выдает запрашивающим контроллерам домена фрагмент списка относительных идентификаторов RID.
В пределах каждого домена существует один RID Master. По умолчанию роли RID Master и PDC Emulator назначаются одному и тому же контроллеру домена. Роль RID Master можно передать другому контроллеру домена, но связь между этими серверами не должна нарушать-
ся, если домен работает в режиме Mixed. Постоянная связь не является критичной при работе в режиме Native, поскольку каждый контроллер домена содержит большое количество относительных идентификаторов для использования при создании объектов. Несмотря на это, без RID Master невозможно повысить новый контроллер домена.
Хозяин инфраструктуры — Infrastructure Master
При добавлении пользователя к группе характерное имя пользователя добавляется в атрибут Member объекта группы. Объект User имеет соответствующий атрибут MemberOf, который содержит характерные имена групп, в которые входит пользователь.
Эта пара атрибутов, Member и MemberOf, является примером связанных атрибутов (linked attributes). В паре связанных атрибутов основной атрибут называется прямой ссылкой (forward link), а вторичный атрибут называется обратной ссылкой (back-link). В этом примере атрибут Member является прямой ссылкой, а атрибут MemberOf является обратной ссылкой. Непосредственное изменение разрешается только для прямых ссылок. Обратные ссылки рассчитываются автоматически.
В Active Directory существует много примеров связанных атрибутов. Еще одним примером является атрибут Manager, являющийся прямой ссылкой, указывающей на менеджера соответствующего пользователя, и атрибут Reports, который является обратной ссылкой и указывает на пользователей, которые управляются конкретным менеджером.
При изменении прямой ссылки, например при добавлении нового пользователя в группу, характерное имя пользователя реплицируется на все контроллеры домена, которые хранят копию соответствующего контекста именования. При записи обновления контроллер домена пересчитывает атрибут обратной ссылки для соответствующего объекта пользователя.
Если вам кажется, что этот процесс потенциально может стать слишком сложным и приводить к различным ошибкам, то вы правы. Поддержка целостности ссылок между связанными атрибутами является одним из более сложных процессов, возложенных на службу каталогов.
Связанные атрибуты Member и MemberOf играют важную роль в системе безопасности Active Directory, поскольку группы в качестве участников системы безопасности используются для защиты объектов. Пользователи, входящие в группу, получают соответствующие разрешения на доступ. При регистрации пользователя система выполняет поиск всех групп, в атрибуте Member которых указано характерное имя пользователя. Имена групп преобразовываются в идентификаторы безопасности и добавляются в сертификат привилегий доступа данного пользователя. Подсистема безопасности на сервере использует сертификат привилегий доступа для создания билета локального доступа для зарегистрированного пользователя.
При изменении характерного имени пользователя система должна обновить все объекты групп, в которые входит пользователь. Эта операция должна быть выполнена как можно быстрее, чтобы пользователь не мог “пролететь под радарами” и получить недопустимые права доступа.
Обновления атрибута Member объектов групп в том же домене, в который входит пользователь, происходит немедленно, поскольку на контроллере домена хранятся и объект группы, и объект пользователя. Но если пользователь входит в группу из другого домена, обновление может занять некоторое время. Контроллер удаленного домена должен быть проинформирован об изменении имени, чтобы получить возможность изменить атрибут Member для соответствующих групп в домене. ,
Задача быстрого распространения изменений имен возлагается на Infrastructure Master — хозяина инфраструктуры.
Хозяин именования доменов —
Domain Naming Master
При создании нового домена в существующем лесу другие контроллеры домена должны узнать о существовании нового домена, так как каждый домен представляет отдельный контекст именования. Агенты служб каталога (DSA) предоставляют друг другу в совместное пользование сведения о контекстах именования в других агентах, что является одной из основ LDAP.
Служба Active Directory хранит указатели на другие домены в специальном объекте CrossRef, который хранится в контейнере Partitions в контексте именования Configuration. Этот объект имеет атрибуты, которые описывают характерное имя, имя DNS, “плоское” имя и имя контекста именования Domain, а также типы доверительных отношений, которые связывают домен с лесом.
Если два администратора создают новые домены с идентичными именами в течение одного интервала репликации, стандартные алгоритмы управления конфликтами не срабатывают и не позволяют предотвратить создание набора неправильных ссылок, связей и соединений репликации. Именно по этой причине только один компьютер в пределах леса может вносить изменения в контейнер Partitions. Этот компьютер называется хозяином именования доменов (Domain Naming Master). '
По умолчанию хозяином именования доменов становится первый контроллер домена, повышенный в составе леса. Эту роль можно перенести на любой контроллер любого домена, но лучше всего разместить такой контроллер в пределах корневого домена, чтобы не возникали вопросы о предоставлении прав доступа к серверу той или иной группе администраторов.
Хозяин схемы — Schema Master
Объекты в контексте именования Schema определяют структуру Active Directory в пределах леса. Добавление, изменение и удаление объектов схемы разрешены только в строго определенных условиях. Только один контроллер домена может изменять схему. Этот контроллер домена называется хозяином схемы (Schema Master).
В главе 6, “Службы Active Directory”, рассматриваются требования при изменении схемы вручную. Это позволяет добавлять атрибуты и классы объектов для поддержки собственных приложений, используемых в различных отделах. Приложения типа клиент/сервер, например Exchange 2000, также вносят изменения в схему. Новые приложения управления сетью могут использовать возможности Active Directory и также вносят изменения в схему.
Для установки приложения, вносящего изменения в схему Active Directory, не обязательно присутствовать за консолью компьютера, который выполняет роль Schema Master, но перед обновлением схемы Schema Master должен быть включен и доступен по сети. Кроме этого, устанавливающий такое приложение пользователь должен входить в группу Schema Admins.
Роль хозяина операции может передаваться другому контроллеру домена или приниматься другим контроллером домена, если текущий хозяин операции отказал и не может быть восстановлен. Процедура передачи роли рассматривается в главе 10, “Обслуживание Active Directory”.
Распределение ролей
Если не выполнять назначение ролей хозяев операций вручную, первый контроллер домена получит все роли хозяев операций, что приведет к значительному риску и созданию единственной точка отказа. Ниже представлен перечень рекомендаций по распределению ролей хозяев операций.
PDC Emulator и RID Master. Эти роли должны быть назначены одному контроллеру домена. Этот компьютер должен обладать достаточной производительностью и иметь высокоскоростное внешнее соединение. Помните, что все контроллеры домена при вводе неправильного пароля обращаются к PDC Emulator для окончательной проверки.
Infrastructure Master. Передайте эту роль контроллеру домена, который не является сервером глобального каталога. Удостоверьтесь, что сервер имеет надежное соединение, так как он отвечает за уведомление других контроллеров домена об изменениях взаимосвязанных имен.
Domain Naming Master. Передайте эту роль контроллеру домена, который является сервером глобального каталога. Этот сервер не обязательно должен иметь высокую производительность, но он должен быть доступен при создании новых доменов.
Schema Master. Компания Microsoft рекомендует назначать эту роль тому же контроллеру домена, которому назначена роль Domain Naming Master, но это не обязательно. Обновление схемы требуется очень редко, но необходимо обеспечить полную безопасность Schema Master. Копия схемы хранится на всех серверах, поэтому Schema Master может не быть сервером глобального каталога.
Размещение контроллеров домена
Следует избегать превращения каждого сервера под управлением Windows Server 2003 в контроллер домена. Это снижает производительность, отнимая процессорное время на репликацию и управление каталогом. Кроме этого, усложняется топология репликации.
Начальное количество контроллеров домена зависит от требований к обеспечению устойчивости к отказам. Стоит Всегда иметь как минимум два контроллера домена, чтобы обеспечить постоянное наличие копии базы данных Active Directory, если один сервер откажет. Рекомендуем использовать три контроллера домена, чтобы один из серверов мог быть отключен для ремонта, в то время как остальные два остаются доступными для клиентов.
Надежность и производительность становятся основными критериями для выбора контроллеров домена. Планируйте развертывание как минимум двух контроллеров домена в больших офисах (более 1000 пользователей), чтобы обеспечить приемлемую производительность при утренней регистрации и для обеспечения отказоустойчивости.
Как минимум один контроллер домена должен находиться в каждом офисе, для которого нежелательна аутентификация пользователей через внешнее соединение. Если используется надежная и быстрая сетевая инфраструктура, допустима аутентификация 50 пользователей с использованием внешнего соединения. Если инфраструктура не обеспечивает достаточной производительности или надежности, контроллер домена следует устанавливать для десяти пользователей и больше.
Если в офисе отсутствует контроллер домена, но есть обычные серверы, нарушение работы внешнего соединения в конечном итоге закроет доступ и к локальным серверам. Это связано с устареванием билетов Kerberos (по умолчанию время жизни билета составляет 10 часов). В связи с этим в таких ситуациях желательно установить локальный контроллер домена.
Серверы глобального каталога
Серверы глобального каталога являются ключевыми компонентами архитектуры Active Directory. Система аутентификации Windows использует глобальный каталог для получения информации о членстве в универсальных группах. Такие клиент/серверные приложения, как Exchange 2000, используют глобальный каталог для получения информации. Многие запросы
LDAP требуют гораздо большего времени, если клиенту приходится проходить по дереву, а не получать информацию из глобального каталога.
Если в пределах сайта отсутствует сервер глобального каталога, пользователям будет разрешено регистрироваться в домене только в том случае, если локальный контроллер домена настроен на кэширование информации из глобального каталога. В противном случае будет выдано сообщение об ошибке подключения к серверу глобального каталога и невозможности регистрации. Это ограничение не относится к администраторам.
Назначение сервера на роль сервера глобального каталога может значительно увеличить нагрузку на этот сервер в большой сети. Если в пределах леса существует 200 тыс. пользователей, но в пределах домена находятся только 20 тыс. пользователей, то серверам глобального каталога в каждом домене придется обрабатывать достаточно большой файл Ntds . dit. Аппаратные средства сервера необходимо выбирать в соответствии с предполагаемой нагрузкой.
Разместите как минимум один сервер глобального каталога в каждом большом офисе. В офисах меньшего размера можно использовать сервер глобального каталога или стандартный контроллер домена, настроенный на кэширование информации из глобального каталога.
Если используется только один домен, глобальный каталог можно включить на каждом сервере. Это обеспечивает каждому клиенту возможность отправить запрос на порт 3268 каждого сервера и получить от сервера ответ. Такая конфигурация не приводит к увеличению непроизводительных расходов или снижению производительности.
Вторичные серверы DNS
Стабильность и надежность домена Windows Server 2003 полностью зависят от стабильности и надежности динамической системы DNS, которая предоставляет службы преобразования имен. Размещение дополнительного контроллера домена в удаленном офисе без размещения вторичного сервера DNS в этом же офисе не позволит добиться истинной отказоустойчивости.
Самым простым способом распределения служб DNS средствами Active Directory является использование интегрированных зон (дополнительную информацию по этой теме можно получить в главе 5, “Управление службой DNS”). Это позволяет хранить записи DNS непосредственно в базе данных Active Directory, чтобы каждый контроллер домена мог получать к ним доступ. Все, что необходимо сделать, — это установить службу DNS на контроллере домена. Доступ к интегрированным зонам будет предоставлен автоматически. Поскольку в Active Directory используется репликация с несколькими хозяевами, каждый контроллер домена с установленной службой DNS может вносить изменения в содержимое зоны.
Существует несколько “подводных камней”, связанных с использованием интегрированных зон. Служба DNS обязательно должна быть запущена на контроллере домена. При желании можно создать стандартный вторичный сервер DNS, который получает зону (по своему запросу) от основного сервера. При этом DNS-зона основного сервера интегрирована в Active Directory. Как и в случае стандартной службы DNS, копия на вторичном сервере будет предназначена только для чтения. Всегда необходимо создавать как минимум один стандартный вторичный сервер DNS, чтобы иметь возможность быстрого восстановления зоны в случае проблем в репликации Active Directory. Использовать такой вторичный сервер для обслуживания клиентов не обязательно. Он служит только резервной копией данных зоны.
Если контроллер домена под держивает работу службы DNS, в свойствах протокола TCP/IP всегда нужно указывать другой DNS-сервер, который будет использоваться для преобразования имен. Если заставить контроллер домена использовать собственную службу DNS для преобразования имен, можно получить “проблему-22”, при которой контроллер не сможет начать репликацию из-за невозможности преобразовать имя партнера в IP-адрес и не сможет обновить данные зоны из-за отказа репликации. Кроме этого, проблемы могут возникнуть в процессе загрузки сервера, так как службы Active Directory запускаются до службы DNS.
В следующей главе
На этом этапе проект должен пройти рецензирование и получить подтверждение всех ответственных лиц компании. При планировании встреч по поводу рецензирования проекта воспользуйтесь советом Арло Гатри из кинофильма “Ресторан Элис”. Подготовьте много картинок, на которых изображены круги и стрелки, а на обратной стороне листа опишите значение этих кругов и стрелок. Автору этой книги также помогала подготовка большого количества пончиков и кофе. Кофеин, сахар и насыщенные жиры всегда ускоряют процесс утверждения.
Пришло время переходить к развертыванию доменов Windows Server 2003. В следующей главе приводится подробная информация по модернизации существующих доменов Windows NT и Windows 2000, а также рассматривается повышение новых доменов Windows Server 2003. Кроме этого, рассматриваются переключение из режима Mixed, Functional Level 0 в режим Native, Functional Level 1 и миграция пользователей, компьютеров и групп между доменами.
П
ришло время заканчивать разговоры. Все альтернативы были рассмотрены, отчеты написаны, диаграммы нарисованы, встречи проведены, весь кофе выпит, планы учтены, споры закончены, а соглашения достигнуты. Теперь осталось сделать дело и развернуть домен Active Directory. В этой главе рассматриваются следующие сценарии развертывания домена.
Модернизация классического домена Windows NT 4.0 до домена Windows Server 2003
Модернизация домена Windows 2000 до домена Windows Server 2003
Миграция из домена Windows NT 4.0 или Windows 2000 в домен Windows Server 2003
Обычно организации принимают решение о миграции, предпочитая ее модернизации, если во время миграции планируется изменение структуры доменов. Самыми главными обстоятельствами являются следующие.
Изменения имен доменов. При непосредственной модернизации приходится сохранять оригинальное “плоское” имя NetBIOS в качестве крайнего слева компонента нового имени DNS. Например, имя BRANCH превращается в Branch. company. com. В противном случае придется создавать новый домен Windows Server 2003 с новым "плоским” именем и переносить пользователей, группы и компьютеры в новый домен.
Уменьшение количества доменов учетных записей. Если в организации уже используется конфигурация из нескольких доменов и в результате планируется получить единственный домен Active Directory, лучшим вариантом является миграция содержимого различных доменов Windows NT в новый домен Windows Server 2003.
Уменьшение количества доменов ресурсов. Обычно в доменах ресурсов хранятся только учетные записи компьютеров, а не пользователей и групп. Перенос учетных записей компьютеров из домена ресурсов WindowsNT в новый домен Windows Server2003 требует только изменения принадлежности домену. Необходимо обеспечить сохранение прав доступа к ресурсам с сохранением пользовательских профилей и других критически важных структур.
Реструктуризация доменов Windows 2000. Новый тип доверительных отношений между лесами в операционной системе Windows Server 2003 предоставляет дополнительную
гибкость при совместном использовании ресурсов в различных лесах. Это позволяет организации переопределить план доменов для создания отдельных лесов вместо отдельных доменов в пределах одного леса. Такой вариант может пригодиться, если в ближайшем будущем планируется разделение компании.
Из всех этих причин самой весомой для пересмотра стратегии, с точки зрения администратора, является необходимость переименования доменов. Многие организации используют инфраструктуру DNS с соглашениями по именованию, которые не соответствуют существующим именам доменов Windows NT.
Например, администраторы в университете могут решить использовать существующее корневое имя DNS, University. edu, в качестве имени корневого домена Active Directory, а в качестве имен дочерних доменов использовать имена Undergrad.University.edu, Grad.University.edu, Law.University.edu и т.д. Если получившиеся в результате “плоские” имена UNDERGRAD, GRAD и LAW не соответствуют существующим именам доменов Windows NT, администраторам придется создавать новые домены Windows Server 2003 и переносить пользователей из существующих доменов Windows NT.
В этой главе рассматриваются некоторые варианты модернизации и миграции, предназначенные для удовлетворения следующих критериев.
Сохранение пользовательских учетных записей
Сохранение разрешений на доступ к сетевым ресурсам'
Минимизация простоев в работе пользователей
Построение устойчивой иерархии управления для объектов и процессов домена и леса
Новые возможности операционной системы Windows Server 2003
Операционная система Windows Server 2003 предоставляет несколько новых возможностей и инструментов, которые предназначены для развертывания доменов и улучшения взаимодействия. Рассмотрим перечень усовершенствований.
Улучшения в работе утилиты Active Directory Migration Tool (ADMT). Новая версия утилиты ADMT поддерживает перенос паролей, сохранение доступа к пользовательским учетным записям, а также значительно упрощает повторное назначение прав доступа серверам и рабочим станциям.
Функциональные уровни. До тех пор, пока продолжают свою работу контроллеры домена под управлением операционных систем Windows NT и Windows 2000, многие новые возможности операционной системы Windows Server 2003 придется отключить. Включение новых возможностей определяется набором функциональных уровней (Junctional levels). Два функциональных уровня предназначены для режимов Mixed и Native операционной системы Windows 2000. Оставшиеся два функциональных уровня позволяют разрешить использование новых возможностей операционной системы Windows Server 2003 сначала в пределах домена, а потом в пределах леса.
Контексты именования приложений. Эта возможность рассматривалась в главе 5, “Управление службой DNS”, но здесь она будет рассмотрена еще раз. Контроллер домена под управлением операционной системы Windows Server 2003 способен хранить зону DNS в базе данных Active Directory в отдельном контексте именования Application. Это предоставляет значительную гибкость при проектировании службы DNS под управлением операционной системы Windows на крупных предприятиях.
■ Предотвращение повышенной нагрузки на контроллер домена. Рабочие станции под управлением операционных систем Windows 2000 и Windows ХР обычно регистрируются на контроллерах домена Active Directory. Это может стать причиной проблем при развертывании, когда количество новых контроллеров домена непропорционально количеству рабочих станций. Специальная запись в системном реестре контроллера домена Windows Server 2003 позволяет имитировать классический резервный контроллер домена (ВВС), пока в сети не будет установлено достаточное количество новых контроллеров домена.
■ Повышение контроллеров домена с использованием резервных копий. Если размер базы данных Active Directory слишком велик, повышение контроллера домена, подключенного через внешнее соединение, может занять достаточно длительное время. Новая возможность позволяет использовать резервную копию базы данных Active Directory для первоначального развертывания базы.
■ Новая схема. В операционной системе Windows Server 2003 в схему внесено около 400 изменений по сравнению с операционной системой Windows 2000. Эти изменения должны быть внесены в схему до модернизации контроллера домена под управлением Windows 2000 до Windows Server 2003. Новая утилита, adprep, позволяет модернизировать схему и устанавливает новые атрибуты и контейнеры в контексте именования Domain. Эти атрибуты и контейнеры используются для модернизации.
■ Новые операции с доменами. Лес Windows Server 2003 может быть реструктуризирован с помощью переименования доменов и изменения отношений между родительским и дочерним доменами. Кроме этого, поддерживается переименование контроллеров домена, хотя перемещение контроллера между доменами без промежуточного понижения не поддерживается.
Подготовка к модернизации домена Windows NT
На рис. 9.1 показана простая конфигурация домена WindowsNT. В данном случае используются единственный домен учетных записей и основной контроллер домена в главном офисе, а также контроллеры BDC в удаленных офисах, предназначенные для обеспечения локальной аутентификации. Обычные серверы в домене проверяют регистрационные данные пользователей с помощью сквозной аутентификации на соответствующих контроллерах BDC.
В такой конфигурации модернизация начинается с небольшого “диалога” с основным контроллером домена, который можно перефразировать следующим образом (диалог напоминает эпизод мультипликационного сериала о Симпсонах).
Администратор садится перед сервером и говорит: “Основной контроллер домена, ты пообещал, но нарушил обещание. Сначала ты начал работать медленнее, потом перестал отвечать на запросы контроллеров BDC, а теперь оказывается, что ты предоставляешь информацию взломщикам паролей”.
“Я старался избежать неприятностей. Я действительно старался”, — отвечает основной контроллер домена, виновато моргая индикаторами на передней панели.
“Слишком поздно, — говорит администратор. — Пришло время перемен", — администратор распахивает пиджак и достает из внутреннего кармана установочный компакт-диск операционной системы Windows Server 2003.
“Хорошо, — отвечает основной контроллер домена, — но только... только... не на консоль, хорошо? Оставь мне мои глаза”.
Домен учетных записейДомен учетных записейОсновной контроллер домена под управлением Windows NTОсновной контроллер домена под управлением Windows NTРезервный контроллер домена под управлением Windows NTРезервный контроллер домена под управлением Windows NTРепликация нарезервныйконтроллердоменаРепликация нарезервныйконтроллердоменаРабочие станции ипользователи■ проходятаутентификацию нарезервномконтроллере доменаРабочие станции ипользователи■ проходятаутентификацию нарезервномконтроллере доменаРядовые серверы проходят аутентификацию на резервных контроллерах домена и используют резервные контроллеры домена для сквозной аутентификацииРядовые серверы проходят аутентификацию на резервных контроллерах домена и используют резервные контроллеры домена для сквозной аутентификацииПользователь обращается к общему ресурсу на файловом сервере или сервере печати и аутентифицируется с помощью классического механизма сквозной аутентификацииПользователь обращается к общему ресурсу на файловом сервере или сервере печати и аутентифицируется с помощью классического механизма сквозной аутентификации
Домен учетных записей
Домен учетных записей
Основной контроллер домена под управлением Windows NT
Основной контроллер домена под управлением Windows NT
Резервный контроллер домена под управлением Windows NT
Резервный контроллер домена под управлением Windows NT
Репликация нарезервныйконтроллердомена
Репликация нарезервныйконтроллердомена
Рабочие станции ипользователи■ проходятаутентификацию нарезервномконтроллере домена
Рабочие станции ипользователи■ проходятаутентификацию нарезервномконтроллере домена
Рядовые серверы проходят аутентификацию на резервных контроллерах домена и используют резервные контроллеры домена для сквозной аутентификации
Рядовые серверы проходят аутентификацию на резервных контроллерах домена и используют резервные контроллеры домена для сквозной аутентификации
Пользователь обращается к общему ресурсу на файловом сервере или сервере печати и аутентифицируется с помощью классического механизма сквозной аутентификации
Пользователь обращается к общему ресурсу на файловом сервере или сервере печати и аутентифицируется с помощью классического механизма сквозной аутентификации
Репликация нарезервныйконтроллердомена
Резервный контроллердомена под управлениемWindowsNT
Рис. 9.1. Единственный домен с несколькими резервными контроллерами для обработки регистрационных запросов в удаленных офисах
Администратор открывает привод компакт-дисков, вставляет установочный компактдиск, и появившееся окно предлагает модернизацию операционной системы. Администратор делает легкое движение бровью и щелкает на кнопке Yes (Да). Примерно через час все закончится. Можно поставить свечку за старый основной контроллер домена и начинать настройку Active Directory.
Для того чтобы добраться до этого этапа, необходимо полностью спланировать последовательность действий. Вернемся немного назад и начнем со списка требований к процедуре модернизации. После этого рассмотрим проблемы, которые могут возникнуть в процессе модернизации основного контроллера домена, и последовательность действий по модернизации остальных контроллеров домена со сменой функцйональных уровней домена и леса с целью использования возможностей операционной системы Windows Server 2003.
DNS
Перед модернизацией администратор должен развернуть инфраструктуру DNS, которая поддерживает записи SRV и динамическую регистрацию. Поддержка динамической регистрации не является обязательной, но это экономит время, избавляя администратора от импорта вручную большого списка записей SRV. Как было показано в главе 5, “Управление службой DNS", для поддержки Active Directory не требуется служба DNS, работающая под управлением операционной системы Windows Server 2003 или Windows 2000. Подойдет любая версия сервера BIND начиная с версии 8.1.3. Это справедливо и для последних версий сервера Lucent QIP.
Если на данный момент используется служба DNS под управлением операционной системы Windows 2000 и DNS-серверы не являются контроллерами домена, их можно модернизировать до Windows Server 2003, сохранив службу DNS. В таком случае можно будет получить возможности перенаправления по условию и создания зон-заглушек.
Если служба DNS для поддержки домена Active Directory еще не выбрана, пришло время собрать всех за одним столом и прийти к определенному соглашению. В отличие от операционной системы Windows 2000, операционная система Windows Server 2003 позволяет изменить имя домена после развертывания, но процедуру изменения имени нельзя назвать простой, поэтому не стоит делать лишнюю работу.
Помните, что при модернизации существующего домена Windows NT крайний слева элемент полностью определенного имени DNS должен совпадать с текущим именем NetBIOS. Кроме этого, при установке отдельного домена Windows Server 2003 крайний слева элемент имени домена не должен совпадать с существующим “плоским” именем любого домена, сервера или пользователя. Это приведет к появлению ошибки дублирования имен при попытке повышения первого контроллера домена в новом домене.
Настройте свойства протокола TCP/IP контроллера домена Windows NT таким образом, чтобы до модернизации была запущена служба DNS с динамической регистрацией. Это позволяет серверам регистрировать собственные записи SRV во время повышения контроллеров домена после модернизации. Кроме этого, клиенты должны использовать те же самые DNS- серверы, что обеспечит предоставление записей SRV и использование этих записей для обнаружения получивших повышение контроллеров доменов.
Требования к контроллерам доменов
Основной контроллер домена Windows NT может существовать с темных времен середины 90-х годов прошлого века, когда серверы на основе процессора Pentium 90 считались вершиной научной мысли и для использования зеркалированных жестких дисков SCSI объемом 2 Гбайт для хранения операционной системы требовалось одобрение на высшем уровне.
В главе 1, “Установка и настройка Windows Server 2003", перечислены минимальные рекомендуемые аппаратные средства для операционной системы Windows Server 2003, включая центральный процессор, объем оперативной памяти, объем кэш-памяти, производительность подсистемы ввода-вывода, объем дисковой подсистемы и тип сетевых соединений. Контроллер домена должен быть больше ориентирован на производительность ввода-вывода и надежность, а не на производительность центрального процессора. Если в сети присутствует меньше десяти тысяч пользователей и одновременно в сети регистрируется не больше нескольких сотен пользователей, контроллер домена может быть основан на единственном центральном процессоре, работающем на частоте 600 МГц или выше, и обеспечен 256 Мбайт оперативной памяти. Кроме этого, на контроллере домена должны быть установлены два жестких диска, формирующих зеркальный массив для хранения файлов операционной системы, и еще два жестких диска, формирующих зеркальный массив для хранения файлов базы данных Active Directory. Такие серверы доступны в виде стойки 1U от большинства производителей и стоят в пределах 3000 долларов.
Если в домене работают десятки тысяч пользователей и несколько тысяч пользователей регистрируются одновременно в каждом офисе, и пользователям предоставляется большое количество групповых политик, потребуется более одного контроллера домена, и на каждый из них следует установить по нескольку процессоров и большой объем оперативной памяти.
Для модернизации Windows NT до Windows Server 2003 необходимо использовать Service Pack 6а (этот пакет обновлений должен быть установлен на всех серверах, включая контроллеры домена).
Удаление файлов Lmhosts и Hosts
Перед модернизацией контроллера домена Windows NT проверьте содержимое файлов Hosts и Lmhosts. Записи в этих файлах могут привести к проблемам преобразования имен после модернизации сервера до Windows Server 2003. Он них легко забыть.
I
Эти файлы находятся в каталоге \wiNNT\System32\Drivers\Etc. Каталог для хранения этих файлов определяется в системном реестре в записи HKLM\System\CurrentControlSet\ Services\TCPIP\Parameters\DataBasePath.
На контроллере домена должен присутствовать как минимум один раздел NTFS, в котором будет храниться каталог Sysvol. Если модернизируемый контроллер домена WindowsNT 4.0 использует только разделы FAT, лучше выполнить преобразование разделов еще до модернизации. Таким образом, при возникновении проблем не придется диагностировать две проблемы одновременно: модернизацию и преобразование файловой системы.
Всегда храните файлы базы данных Active Directory на отдельном зеркалированном массиве дисков. Большинство операций ввода-вывода, связанных с Active Directory, ориентированы на чтение, а не на запись, поэтому зеркалирование позволяет увеличить производительность. Если на контроллере домена одновременно регистрируется несколько сотен пользователей, получая групповые политики из каталога Sysvol на этом же контроллере домена, то каталог Sysvol стоит также разместить на отдельном зеркалированном массиве дисков.
Вопросы совместимости приложений
Даже если существующие аппаратные средства сервера в состоянии поддерживать полноценную работу контроллера домена Windows Server 2003, все равно непосредственная модернизация может оказаться нежелательной из-за программного обеспечения, которое работает на сервере, из-за содержимого системного реестра, которое начало напоминать доску для объявлений с десятками слоев бумаги, или из-за большого количества управляющих утилит и аналитического программного обеспечения, с которыми администратор экспериментировал на протяжении нескольких лет.
Контроллер домена может выступать в роли файлового сервера и сервера печати и даже может поддерживать работу небольших приложений, например служб TCP/IP, но для поддержки требовательных к ресурсам клиент/серверных приложений контроллер домена использовать не стоит. Это не связано с ограничениями в работе операционной системы; скорее это является архитектурным решением. Если пришлось остановить работу почтового сервера для обслуживания, нежелательно во время этого простоя на обслуживание нарушать работу служб аутентификации, которые предоставляет контроллер домена.
Поэтапная модернизация
Если возникло желание выполнить непосредственную модернизацию домена, простое подключение сервера Windows Server 2003 к сети и его повышение до контроллера домена невозможно. Первым делом всегда необходимо выполнить модернизацию существующего основного контроллера домена. После этого в сеть можно добавлять любое количество контроллеров домена под управлением Windows Server 2003. Если основной контроллер домена не в состоянии поддерживать работу новой операционной системы, можно выполнить поэтапную модернизацию (рис. 9.2).
Сначала подберите аппаратные средства, достаточные для обеспечения работоспособности контроллера домена. Выполните тестовую установку операционной системы Windows Server 2003 для того, чтобы убедиться в отсутствии проблем с совместимостью. Проверьте все диски и соединения SCSI, которые будут использоваться для хранения файлов Active Directory.
После этого удалите операционную систему с нового сервера и установите операционную систему Windows NT 4.0, настроенную на работу в качестве резервного контроллера в пределах существующего домена Windows NT. Убедитесь в надежной репликации между новым резервным контроллером домена (BDC) и основным контроллером домена (PDC). Оставьте новый сервер подключенным к сети на день или два, чтобы убедиться в отсутствии дополнительных проблем до модернизации.
Исходный основной контроллер доменаИсходный основной контроллер доменаНовый основной контроллер доменаНовый основной контроллер доменаПроцессор Pentium 90.ОЗУ 32 Мбайт, зеркалированные SCSI- диски емкостью 2 Гбайт для хранения ОСПроцессор Pentium 90.ОЗУ 32 Мбайт, зеркалированные SCSI- диски емкостью 2 Гбайт для хранения ОСПроцессор Pentium 4,933 МГц, ОЗУ 256 Мбайт, зеркалированные SCSI- диски емкостью 9 Гбайт для хранения ОС и зеркалированные SCSI-диски емкостью2 Гбайт для хранения Active DirectoryПроцессор Pentium 4,933 МГц, ОЗУ 256 Мбайт, зеркалированные SCSI- диски емкостью 9 Гбайт для хранения ОС и зеркалированные SCSI-диски емкостью2 Гбайт для хранения Active DirectoryРезервный контроллер домена под управлением Windows NT 4.0Резервный контроллер домена под управлением Windows NT 4.0Рядовой сервер под управлениемWindows Server 2003Рядовой сервер под управлениемWindows Server 2003Исходный резервный контроллер доменаИсходный резервный контроллер доменаНовый сервер под управлением Windows Server 2003Новый сервер под управлением Windows Server 2003Процессор Pentium 90,ОЗУ 32 Мбайт,зеркалированные SCSI-диски емкостью 2 Гбайтдля хранения ОСПроцессор Pentium 90,ОЗУ 32 Мбайт,зеркалированные SCSI-диски емкостью 2 Гбайтдля хранения ОСЧлен домена Windows NT
Исходный основной контроллер домена
Исходный основной контроллер домена
Новый основной контроллер домена
Новый основной контроллер домена
Процессор Pentium 90.
ОЗУ 32 Мбайт, зеркалированные SCSI- диски емкостью 2 Гбайт для хранения ОС
Процессор Pentium 90.
ОЗУ 32 Мбайт, зеркалированные SCSI- диски емкостью 2 Гбайт для хранения ОС
Процессор Pentium 4,933 МГц, ОЗУ 256 Мбайт, зеркалированные SCSI- диски емкостью 9 Гбайт для хранения ОС и зеркалированные SCSI-диски емкостью
2 Гбайт для хранения Active Directory
Процессор Pentium 4,933 МГц, ОЗУ 256 Мбайт, зеркалированные SCSI- диски емкостью 9 Гбайт для хранения ОС и зеркалированные SCSI-диски емкостью
2 Гбайт для хранения Active Directory
Резервный контроллер домена под управлением Windows NT 4.0
Резервный контроллер домена под управлением Windows NT 4.0
Рядовой сервер под управлением
Windows Server 2003
Рядовой сервер под управлением
Windows Server 2003
Исходный резервный контроллер домена
Исходный резервный контроллер домена
Новый сервер под управлением Windows Server 2003
Новый сервер под управлением Windows Server 2003
Процессор Pentium 90,ОЗУ 32 Мбайт,зеркалированные SCSI-диски емкостью 2 Гбайтдля хранения ОС
Процессор Pentium 90,ОЗУ 32 Мбайт,зеркалированные SCSI-диски емкостью 2 Гбайтдля хранения ОС
Настроен так же, какновый основнойконтроллер домена
Заменит исходныйBDC
Рис. 9.2. Поэтапная модернизация основного контроллера домена для введения нового сервера
С помощью службы User Manager (Диспетчер пользователей) повысьте новый сервер до основного контроллера домена. Существующий основной контроллер домена автоматически будет понижен до резервного контроллера домена. После этого позвольте системе проработать несколько дней, чтобы убедиться в ее нормальной работе.
Подготовившись к модернизации домена, начинайте с модернизации нового PDC до Windows Server 2003. Поскольку мы уже проверили работу аппаратных средств под управлением Windows Server 2003, модернизация пройдет нормально, если до модернизации не была повреждена база данных SAM или в процессе модернизации не возникало проблем с питанием.
После модернизации основного контроллера домена можно модернизировать или заменить существующие резервные контроллеры домена. На схеме показано, что рядовой сервер под управлением Windows Server 2003 ждет момента, чтобы принять на себя обязанности исходного ВВС.
Утилита upromote и контроллеры домена Windows NT
Если на контроллере домена WindowsNT запущено несколько приложений, часто непрактично модернизировать сервер до контроллера домена Windows Server 2003. После мо-
дернизации сервер можно оставить рядовым сервером вместо того, чтобы воспользоваться утилитой Domain Controller Promotion Wizard (Dcpromo) для модернизации сервера до контроллера домена Windows Server 2003.
При необходимости резервный контроллер домена под управлением WindowsNT можно понизить до стандартного сервера еще до модернизации. Для этого можно воспользоваться утилитой Upromote от компании Algin Technologies. Утилита Upromote позволяет понизить ВВС под управлением Windows NT до обычного сервера или повысить рядовой сервер до ВВС. Благодаря этой утилите администратор получает больше свободы при планировании.
Если в списки контроля доступа для файлов и разделов системного реестра были добавлены локальные для домена группы, то меняйте статус контроллера домена с осторожностью. Стандартные рядовые серверы не распознают локальные для домена группы, поэтому пользователи могут утратить доступ к файлам.
Защита базы данных SAM
По ряду причин модернизация может завершиться неудачно. Перечислим наиболее часто встречающиеся причины неудачной модернизации.
Несовместимость аппаратных средств с операционной системой Windows Server 2003
Отказ аппаратных средств во время модернизации или во время повышения контроллера домена
Повреждение базы данных SAM или LSA может помешать переносу учетных записей и политик в базу данных Active Birectory
Неправильная подготовка служб BNS и WINS
Среди всех потенциальных сценариев неудачной модернизации основное внимание стоит обратить на защиту базы данных с учетными записями. Только на РВС хранится предназначенная для чтения и записи копия базы данных SAM и раздел системного реестра Security. Именно в этой базе данных хранятся учетные записи, политики учетных записей, а также информация об установленных доверительных отношениях. Если модернизация завершится неудачей и восстановить РВС будет невозможно, пользователи все равно смогут регистрироваться с помощью ВВС, но изменение паролей, членства в группах и привилегий пользователей окажутся невозможными.
Восстановление можно ускорить. Для этого перед модернизацией нужно создать образ раздела операционной системы, например с помощью программы Ghost от компании Symantec или программы Brivelmage от компании PowerQuest. Также можно создать стандартную резервную копию с помощью утилиты Ntbackup или, еще лучше, утилиты с возможностью экстренного восстановления.
Еще одним потенциальным источником проблем является повреждение разделов реестра SAM и Security, которое остается незаметным до повышения контроллера домена. Если поврежденные записи реплицируются на резервные контроллеры домена (ВВС), пользователи могут потерять доступ к домену. В качестве защиты от такого варианта отказа многие организации используют отключенные от сети контроллеры ВВС, как страховой полис. Рассмотрим, как работает это решение.
Установите сервер Windows NT в качестве ВВС на резервном компьютере. Поддержка серверных задач от него не требуется. Все, что требуется от этого компьютера, — хранение полной копии разделов системного реестра SAM и Security. После проверки правильности работы этого ВВС отключите его от сети. Если разделы SAM и Security будут повреждены в процессе модернизации или сразу после модернизации, выполните следующие действия для восстановления.
Отключите от сети контроллер домена под управлением Windows Server 2003 и резервные контроллеры домена Windows NT 4.0.
Включите в сеть запасной ВВС.
Повысьте ВВС до РВС с помощью службы Server Manager.
Проверьте базу данных WINS и убедитесь, что сервер зарегистрирован в качестве РВС. При необходимости удалите записи остальных контроллеров домена.
По одному подключайте ВВС под управлением Windows NT 4.0 и запускайте принудительную репликацию. Проверьте содержимое журнала событий и убедитесь, что резервные контроллеры нашли основной контроллер домена и завершили репликацию.
Восстановите оригинальный РВС с ленты или из образа.
После подключения оригинального РВС к сети он обнаружит присутствие другого основного контроллера и не запустит службу Netlogon.
Понизьте оригинальный РВС до ^ВС и после репликации повысьте его обратно до основного контроллера.
После полного восстановления работы в сети можно оценить возможные причины отказа и начать модернизацию заново. Придется удалить и переустановить все контроллеры домена под управлением Windows Server 2003, которые были установлены в процессе модернизации.
Отключенный от сети ВВС является хорошей страховкой только в течение нескольких дней. Со временем пароли и списки членов групп устаревают. Одной из первых операций, которую необходимо выполнить после полной модернизации основного и резервных контроллеров домена, является создание резервной копии, которая обеспечит работу домена под управлением Windows Server 2003 и позволит не откатываться обратно на Windows NT 4.0 в случае серьезного отказа.
Функциональные уровни
При повышении главного контроллера домена под управлением Windows NT до Windows Server 2003 функциональный уровень домена устанавливается в Windows 2000 Mixed. Это позволяет сохранить совместимость с контроллерами домена Windows NT. Ниже перечислены возможности, которые доступны на функциональном уровне Windows 2000 Mixed.
Отдельные контексты именования приложений в базе данных Active Directory для хранения интегрированных зон DNS
Возможность сохранять запросы на консоли Active Directory — Users and Computers (Active Directory — пользователи и компьютеры)
Новая служба Trust Wizard (Мастер доверия); которая упрощает создание доверительных отношений
При переключении в режим Windows 2000 Native отключается репликация на резервные контроллеры домена Windows NT 4.0 и добавляются следующие возможности.
Универсальные группы
Вложенность глобальных групп
Разрешения на удаленный доступ, основанные на политиках
Отдельная адресация и маршрутизация удаленного доступа для каждого пользователя
Кэширование членства в универсальных группах
Транзитивный междоменный доступ к ресурсам для клиентов более старых версий и обычных серверов
Сохранение истории идентификаторов безопасности для перемещенных участников системы безопасности
Переключение домена на функциональный уровень Windows 2000 Native не мешает работе клиентов более старых версий. Рабочие станции под управлением операционных систем Windows 9х/Ме и WindowsNT4.0 могут проходить аутентификацию в домене и получать доступ так же, как и при использовании домена Windows NT. Удостоверьтесь, что на рабочие станции установлены последние пакеты обновлений, что позволяет избежать проблем, связанных с устаревшим механизмом аутентификации NTLMvl. Кроме этого, стоит серьезно задуматься о модернизации серверов и рабочих станций под управлением WindowsNT 3.51, чтобы обеспечить возможность использования протокола аутентификации NTLMv2.
После модернизации или отключения всех контроллеров домена под управлением операционной системы Windows 2000 домен можно переключить на функциональный уровень Windows Server 2003. Это приводит к появлению следующих возможностей.
Переименование контроллеров домена
Обновление меток времени регистрации
Полноценное использование объектов inetOrgPerson в качестве участников системы безопасности
Номера версий ключей центра распространения ключей Kerberos
После переключения всех доменов на функциональный уровень Windows Server 2003 на этот же уровень можно переключить лес. Это предоставляет следующие возможности.
Изменение структуры леса с помощью переименования доменов для изменения иерархии родительских и дочерних доменов
Создание транзитивных доверительных отношений между лесами
Специальные операции схемы, включая отключение объектов схемы, создание динамических вспомогательных классовй модификация характеристик класса inetOrgPerson
Репликация отдельных членов группы как отдельный независимый фрагмент в механизме репликации
Репликация модифицированного глобального каталога
Улучшенное управление топологией репликации
Динамические вспомогательные классы
Если в домене работают только контроллеры домена Windows Server 2003 и WindowsNT, можно установить функциональный уровень Interim. Это позволяет добиться раздельной репликации членства в группах.
Переключение домена на функциональный уровень Windows Server 2003 выполняется на консоли Active Directory — Users and Computers (Active Directory — пользователи и компьютеры). Щелкните правой кнопкой мыши на вершине дерева и выберите из контекстного меню команду Raise Domain Functional Level (Повысить функциональный уровень домена). Откроется окно Raise Domain Functional Level (Повышение функционального уровня домена), показанное на рис. 9.3.
Переключение леса на функциональный уровень Windows Server 2003 выполняется средствами консоли Active Directory— Domains and Trusts (Active Directory — домены и доверия). Щелкните правой кнопкой мыши на вершине дерева и выберите из контекстного меню команду Raise Forest Functional Level (Повысить функциональный уровень леса). На рис. 9.4 показано окно Raise Forest Functional Level (Повышение функционального уровня леса).
Ш$В Domain НякИооЫ t eve!
y«ynp^.axrira^
WhtfowsZOtomtwd
.Sefc^^aweitiitedctii^j^^
Mу: у Aft«y^«^M<Mii^For more Hormatiori
у v.iaiydM^
Рис. 9.3. Окно Raise Domain Functional Level (Повышение функционального уровня домена), в котором показаны текущий функциональный уровень и следующий доступный функциональный уровень
IRdtse Forest Functional Level
Forerinama
ЯВВВЯВК
Ожег* fared functional tevet
Vr>dbws200Q
s^i^S^SJI^?^^
p/indom Server 2003Ж
Д WteryoufaKetiwtaestfarxaiQnalfevelicanrtolbeieveKedFwnwe.in^^ foraA functional level tick Help.
| Ba» ] Cancel | H* j
Puc. 9.4. Окно Raise Forest Functional Level (Повышение функционального уровня леса), в котором показаны текущий функциональный уровень и следующий доступный функциональный уровень
Новые контроллеры BDC в режиме Mixed
При работе на функциональном уровне Windows 2000 Mixed в домен можно добавлять новые BDC под управлением Windows NT. Но сначала необходимо создать учетную запись компьютера с помощью консоли Active Directory— Users and Computers (Active Directory— пользователи и компьютеры). При создании нового объекта установите флажок Allow Pre-Windows 2000 Backup Domain Controllers To Use This Account (Разрешить использование этой учетной записи резервным контроллерам домена до Windows 2000). Пример показан на рис. 9.5.
Смешанные домены и групповые политики
При попытке доступа к контроллерам домена для аутентификации и получения групповых политик рабочие станции под управлением операционных систем Windows 2000 и Windows ХР могут работать в одном из следующих окружений.
Рис. 9.5. Объект компьютера, созданный для классического резервного контроллера домена в базе данных Active Directory
Домен на основе Windows NT 4.0
Домен в режиме Windows 2000 Mixed под управлением контроллеров домена Windows NT 4.0 и Windows 2000
Домен в режиме Windows 2000 Mixed под управлением контроллеров домена Windows NT 4.0 и Windows Server 2003
Домен в режиме Windows 2000 Mixed под управлением контроллеров домена Windows NT 4.0, Windows 2000 и Windows Server 2003
Домен в режиме Windows 2000 Native под управлением только контроллеров домена Windows 2000 или под управлением контроллеров домена Windows 2000 и Windows Server 2003
Домен в режиме Windows Server 2003 под управлением только контроллеров домена Windows Server 2003
В домене, в котором все контроллеры домена работают под управлением WindowsNT, групповые политики доменом не предоставляются, поэтому рабочие станции под управлением операционных систем Windows 2000 и Windows ХР используют локальные политики, сохраненные в файлах шаблонов на локальном жестком диске, и системные политики, которые загружаются с регистрационного сервера в виде файлов Nt conf ig. pol. В доменах Active Directory современные клиенты Windows не загружают и не обрабатывают классические (Windows NT) системные политики.
Ситуация значительно усложняется, когда одновременно используются групповые политики от Windows 2000, Windows ХР и Windows Server 2003. Желательно потратить немного времени и понять, как создаются и модифицируются политики, что позволит избежать ситуации, когда объекты групповых политик содержат файлы политик без критически важных параметров.
Предпочтительная аутентификация
Компания Microsoft настроила клиенты Windows ХР и Windows 2000 на “предпочтительный поиск" контроллеров домена Active Directory вместо поиска классических контроллеров BDC под управлением Windows NT. Каждый раз при загрузке современного компьютера под управлением Windows клиент запрашивает службу DNS, не произошла ли в зоне DNS реги-
страция первой записи SRV для контроллера домена Active Directory. Если служба DNS отвечает отрицательно, клиент “грустно вздыхает” и возвращается к использованию классического протокола аутентификации NT LanMan (NTLM), регистрируясь на резервном контроллере домена.
Если служба DNS возвращает запись SRV, указывающую на контроллер домена Active Directory, клиент под управлением Windows 2000 или Windows ХР переходит к использованию нового контроллер домена для аутентификации. Это позволяет современным клиентам получать групповые политики при аутентификации.
После того как современный клиент один раз “попробовал вкус” аутентификации Active Directory, он больше не возвращается к использованию классических ВВС. Если контроллеры домена Active Directory недоступны, клиенты используют кэшированные регистрационные данные (и кэшированные групповые политики), но не обращаются к резервному контроллеру домена.
Наводнение
Остановитесь на секунду и посчитайте количество рабочих станций под управлением современной версии Windows, работающих в домене Windows NT 4.0. Превышает ли их количество 20% от общего количества рабочих станций? Может, 40%? Все? Где они расположены? Все ли офисы находятся на одном континенте? Часть офисов находится на других континентах? На нефтяной платформе в Персидском заливе? На военной базе Диего Гарсиа? Подключены ли удаленные офисы кабельными линиями или для связи используются спутники? Может, для связи используется виртуальная частная сеть (VPN) поверх широкополосного соединения?
Представьте, что сегодня вечером завершена модернизация основного контроллера домена. Процедура модернизации начинается после 18:00, когда все пользователи покинули рабочие места, и завершается через несколько часов. В такой ситуации администратор уходит домой, довольный собой. Вот что происходит на следующее утро. Все рабочие станции под управлением современной версии операционной системы Windows, подключенные к сети во всем мире, просыпаются и обнаруживают запись SRV в базе данных DNS. Они хлопают в ладоши, как маленькие дети, обнаружившие подарки под новогодней елкой; после этого все эти рабочие станции обращаются к единственному контроллеру домена под управлением Windows Server 2003 с запросами на регистрацию.
NT4Emulator
Этого кошмара можно избежать, если на некоторое время отложить поддержку аутентификации Kerberos и развертывание групповых политик, пока в сети не окажется достаточное количество контроллеров домена под управлением Windows Server 2003. Для этого необходимо внести запись в системный реестр, которая заставляет контроллер домена Windows Server 2003 выдавать себя за классический контроллер домена под управлением Windows NT 4.0. Эта запись выглядит следующим образом.
Раздел:HKLM\System\CurrentControlSet\Services\Netlogon\Parameters
Запись: NT4Emulator
Значение: 1 (reg_dword)
Очень важно создать эту запись на всех контроллерах домена Windows NT до модернизации. Контроллер домена все еще будет регистрировать записи SRV, но при попытке аутентификации современного клиента Windows контроллер домена будет отвечать только на запросы по протоколу NTLM. Если создать запись после модернизации, когда клиенты уже зарегистрировались с помощью протокола Kerberos и сбросили конфигурацию LSA, будет уже слишком поздно. Ящик Пандоры уже открыт, и обратно закрыть в нем несчастья уже не получится.
NeutralizeNT4Emulator
При использовании записи NT4Emulator клиенты Windows 2000 и Windows ХР продолжат использование протокола аутентификации NTLMv2 и не будут переходить на протокол Kerberos. Это означает невозможность использования утилит управления Active Directory на основе консолей ММС, так как для этого требуется поддержка Kerberos для привязки LDAP. Кроме этого, невозможно повышение контроллеров домена или добавление домена в лес, поскольку серверы не могут осуществить привязку LDAP к существующему контроллеру домена.
Конкретному серверу или рабочей станции можно разрешить игнорировать маскировку контроллера домена, созданную с помощью параметра NT4Emulator. Следующая запись системного реестра позволяет рабочей станции использовать регистрацию Kerberos.
I
Раздел:HKLM\SystenACurгentContгоISet\Services\Netlogon\Parameters
Запись: NeutralizeNT4Emulator
Значение: 1 (reg_dword)
После добавления этой записи завершите сеанс работы и повторно пройдите аутентификацию. Рабочая станция найдет контроллер домена Windows Server 2003 и воспользуется протоколом Kerberos для аутентификации. После этого начнут работать консоли ММС. Если рабочую станцию больше не нужно использовать для управления, запись NeutralizeNT4Emulator можно отключить.
После развертывания в сети количества контроллеров домена Windows Server 2003, достаточного для предполагаемого количества регистраций Kerberos и доставок групповых политик, установите запись NT4Emulator равной значению 0 на каждом контроллере домена. После установки записи перезагрузите контроллеры домена.
Размещение политик Windows ХР
Для того чтобы понять, как рабочие станции под управлением Windows ХР получают специфические для Windows ХР групповые политики в смешанном окружении из контроллеров домена Windows 2000 и Windows Server 2003, рассмотрим методы построения групповых политик.
При создании нового объекта групповой политики редактор групповой политики создает два набора элементов безопасности.
Объект контейнера групповой политики (GPC — Group Policy Container) в базе данных Active Directory
Один или несколько файлов шаблона групповой политики (GPT — Group Policy Teraplate) в каталоге Sys vol
Оба эти набора создаются на эмуляторе PDC независимо от того, где запускается редактор групповых политик (GPE). Это позволяет избежать одновременного редактирования групповой политики двумя администраторами.
Затем при первом запуске редактора групповых политик этой программе необходимо узнать, какие параметры политики из системного реестра показывать в разделе Administrative Templates (Административные шаблоны). Список параметров политик извлекается из файлов ADM, которые хранятся в каталоге \WZNNT\lnf на компьютерах под управлением операционной системы Windows 2000 и в каталоге \Windows\lnf на компьютерах под управленцем операционной системы Windows Server 2003 или Windows ХР.
С этого момента начинается самое интересное. Обратите внимание на рис. 9.6, на котором изображена схема домена, работающего на функциональном уровне Windows 2000 Native и содержащего контроллеры домена под управлением Windows 2000 и Windows Server 2003. Предположим, что пользователь Боб, работая на рабочей станции под управлением Window, 2000, создает объект групповой политики с помощью консоли Active Directory — Users and Computers (Active Directory — пользователи и компьютеры), которая входит в состав на- бораинструментов Windows 2000 Adminpak. msi.
PDC Emulator
Рабочая станция под управлением Windows ХР
Рис. 9.6. Развертывание политик Windows ХР в смешанном домене на основе Windows 2000 и Windows Sewer 2003
Параметры Administrative Templates (Административные шаблоны) в объекте групповой политики создаются на основе файлов ADM, которые хранятся на компьютере Боба под управлением Windows 2000. Таким образом, объект групповой политики не содержит параметров, предназначенных для операционной системы Windows ХР.
Если Алиса модифицирует объект групповой политики на рабочей станции под управлением Windows ХР, файлы ADM с ее рабочей станции перепишут файлы ADM в папке политики из каталога ADM, поскольку они имеют более позднюю отметку времени создания. Если Боб установит пакет обновлений на рабочую станцию под управлением Windows 2000 и модифицирует объект групповой политики, метка времени файлов ADM может оказаться более поздней, чем у файлов ADM с рабочей станции Алисы, поэтому специфичные для Windows ХР параметры могут исчезнуть.
Если кто-нибудь еще модифицирует объект групповой политики на сервере под управлением Windows Server 2003, метка времени файлов ADM может оказаться более поздней, чем у файлов из пакета обновлений Windows 2000, а значит, параметры политики изменятся еще раз. Чтобы предотвратить постоянные изменения параметров групповой политики, следует реализовать следующие правила работы.
Новые групповые политики должны создаваться только на клиентах, на которых установлена новейшая версия файлов ADM.
Всегда устанавливайте последние версии пакетов обновлений на те компьютеры, на которых происходит обновление групповых политик.
Не меняйте содержимое существующих файлов ADM, поскольку это приведет к обновлению метки времени и возникновению потенциальной возможности перезаписи существующих файлов ADM. Вместо этого создавайте собственные копии файлов ADM.
Некоторые администраторы могут никогда не столкнуться с этой проблемой, но если это произошло, подумайте, что будет после выхода следующей версии операционной системы Windows, Longhorn.
Поддержка классических служб удаленного доступа Windows NT 4.0
Как будет показано в главе 20, “Управление удаленным доступом и маршрутизацией”, при подключении пользователя к серверу удаленного доступа Windows сервер выполняет аутентификацию пользователя согласно одному из методов. По умолчанию для клиентов Windows используется закрытый протокол Challenge Handshake Authentication Protocol version 2, или MS-CHAPv2. Этот протокол использовался в классической службе удаленного доступа Windows NT и в службе маршрутизации и удаленного доступа в операционной системе Windows 2000.
Согласно правилам протокола аутентификации MS-CHAPv2, сервер удаленного доступа должен создать защищенное соединение с контроллером домена. По этому соединению сервер получает хешированный пароль пользователя Windows NT. Служба маршрутизации и удаленного доступа (RRAS) в Windows Server 2003 и Windows 2000 может устанавливать такое соединение с помощью регистрационных данных Kerberos учетной записи компьютера. Для классических серверов удаленного доступа под управлением Windows NT 4.0 эта возможность не поддерживается. Операционная система Windows NT 4.0 ничего не знает о протоколе Kerberos.
В операционной системе Windows NT сервер удаленного доступа (RAS-сервер) создает защищенное соединение с контроллером домена Windows NT 4.0 с помощью так называемого- нулевого сеанса (null session). Нулевой сеанс представляет собой специальный тип соединения, при котором запрашивающий соединение объект не предоставляет аутентификационных данных. Контроллер домена Windows NT 4.0 настроен на создание локального потока для нулевого сеанса. Потоку назначаются привилегии доступа на основе маркера доступа группы Everyone и группы Network. Группе Everyone в операционной системе WindowsNT предоставлено право вызывать определенные функции, предназначенные для создания защищенного соединения.
В операционных системах Windows Server 2003 и Windows 2000 подключение к Active Directory с помощью нулевого сеанса запрещено. Таким образом, в нормальных условиях классический сервер удаленного доступа Windows NT 4.0, входящий в домен Active Directory, не сможет выполнить аутентификацию пользователей по коммутируемому соединению.
Если модернизация сервера удаленного доступа под управлением Windows NT 4.0 до Windows Server 2003 или Windows 2000 по какой-либо причине невозможна, можно остановиться на классической аутентификации удаленного доступа, выбрав переключатель Retain Pre-Windows 2000 Compatible Access (Сохранить возможность доступа для версий до Windows 2000) в процессе повышения контроллера домена. В операционной системе Windows Server 2003 этот флажок означает добавление групп Everyone и Anonymous Logon в группу PW2CA (Pre-Windows 2000 Compatible Access). Группа PW2CA обладает достаточными правами доступа к Active Directory, чтобы получить аутентификационные данные пользователя и проверить возможность регистрации пользователя по коммутируемому соединению.
Операционная система Windows 2000 добавляет в группу PW2CA только группу Everyone, но для Windows Server 2003 этого недостаточно, поскольку группе Everyone не предоставлено прав на установку нулевых сеансов. Дополнительную информацию о конкретных правах доступа, предоставленных группе PW2CA, можно найти в главе 20, “Управление удаленным доступом и маршрутизацией”.
После модернизации сервера удаленного доступа под управлением Windows NT 4.0 систему безопасности можно переключить в обычный режим, удалив группу Everyone и группу Anonymous Logon из группы PW2CA. Перед вступлением изменений в силу необходимо пере- ; загрузить все контроллеры домена.
Поддержка классических сценариев и политик
Классические сценарии регистрации Windows NT идентифицируются по записям в каждой пользовательской учетной записи в базе данных SAM. Например, если пользователь Rdanger field должен запускать регистрационный сценарий logon. cmd при каждой аутентификации в домене, необходимо ввести имя logon. cmd в поле Scripts (Сценарии) пользовательского профиля.
После 'определения регистрационного сценария в учетной записи пользователя Windows сетевой клиент Windows пытается найти сценарий в совместно используемом каталоге Net logon, хранящемся на контроллере домена, который выполняет аутентификацию пользователя. Если в этом каталоге сценария не оказалось, сетевой клиент продолжает регистрацию без запуска сценария.
Классические системные политики также хранятся в совместно используемом каталоге Netlogon. Файлы политик, Config.pol для Windows 9х/Ме и Ntconfig.pol для клиентов Windows NT, загружаются клиентами Windows при каждой аутентификации в домене.
В операционной системе Windows Server2003 общий каталог Netlogon соответствует каталогу \Windows\Sysvol\domain\Scripts. Поскольку содержимое каталога Sysvol синхронизируется на все контроллеры домена средствами службы репликации файлов, клиенты могут регистрироваться на любом контроллере домена Windows Server 2003 и в любом случае будут предоставлены одни и те же регистрационные сценарии и системные политики.
Это не относится к клиентам, которые регистрируются на контроллерах ВВС домена, работающего в режиме Mixed. Операционная система Windows Server 2003 не предоставляет службы для репликации содержимого Netlogon на контроллеры ВВС. В классической операционной системе WindowsNT такая служба существовала и называлась Lmrepl, но в операционных системах Windows Server 2003 и Windows 2000 она не поддерживается.
Если в сети присутствуют устаревшие ВВС и используются регистрационные сценарии и системные политики, необходимо создать “мост” между контроллером домена Windows Server 2003 и устаревшими контроллерами ВВС. Для этого один из контроллеров ВВС необходимо настроить в качестве сервера службы Lmrepl. Настройте остальные резервные контроллеры домена на запрос обновлений из общего ресурса $Repl на этом сервере. Совместно используемый ресурс $Repl указывает на каталог \WINNT\System32\Repl\Export.
После этого настройте утилиту автоматического копирования, например Robocopy из состава Resource Kit, для синхронизации содержимого ресурса $Repl с содержимым ресурса Netlogon на контроллере домена под управлением Windows Server 2003. Такое решение позволяет продолжать использовать классические системные политики и регистрационные сценарии на клиентах устаревших версий.
Размещение серверов, выполняющих роли FSMO
Основному контроллеру домена учетных записей при модернизации будут назначены все пять ролей хозяев операций. Напомним эти роли.
РВС Emulator
Хозяин относительных идентификаторов RIB Master
Хозяин инфраструктуры — Infrastructure Master
Хозяин схемы — Schema Master
Хозяин именования доменов — Bomain Naming Master,
При развертывании новых контроллеров домена Windows Server 2003 важно обеспечить назначение ролей хозяев операций подходящим серверам.
На функциональном уровне Windows 2000 Mixed роли PDC Emulator и RID Master должны быть назначены одному контроллеру домена, поскольку PDC Emulator является единственным контроллером, который может модифицировать объекты пользователей, групп и компьютеров. После переключения функционального уровня на Windows 2000 Native роли можно назначить разным контроллерам домена, но делать это не рекомендуется.
Еще одной важной задачей PDC Emulator является роль “третейского судьи” при проверке правильности паролей. Если администратор сбрасывает пароль пользователя, изменение немедленно передается на PDC Emulator, где записывается в копию базы данных Active Directory. Если пользователь вводит неправильный пароль при регистрации на любом контроллере домена, контроллер обращается к PDC Emulator до того, как запрещать пользователю доступ. Именно по этой причине PDC Emulator должен иметь надежное внешнее соединение.
Если в пределах леса существует несколько доменов, важно назначить роль Infrastructure Master в пределах каждого домена тем контроллерам домена, которые не являются серверами глобального каталога. Infrastructure Master отвечает за проверку совпадения имен в записях, представляющих участников системы безопасности из других доменов, и имен в глобальном каталоге. Контроллеры домена, являющиеся серверами глобального каталога, не содержат таких записей, поэтому им нельзя назначать роли Infrastructure Master.
Существуют только один контоллер домена, выполняющий роль Schema Master, и один Domain Naming Master в пределах всего леса. Компания Microsoft рекомендует назначать обе роли одному контроллеру домена, что позволяет упростить задачу управления. Роль Domain Naming Master домена должна быть назначена серверу глобального каталога, что позволит хозяину именования доменов получать доступ ко всем контекстам именования Domain.
Неподдерживаемые операции доменов
Следующие операции не поддерживаются операционными системами Windows Server 2003 и Windows 2000.
Разбиение доверительных отношений. Не поддерживается разбиение доверительных отношений между доменами или доверительных отношений между деревом и корневым доменом для формирования независимого леса. Чтобы домены выделить в отдельный лес, необходимо создать новый лес и перенести в него участников системы безопасности.
Перемещение контроллера домена из одного домена в другой. Не существует инструмента для перемещения контроллера домена из одного домена в другой. Контроллер необходимо понизить до стандартного сервера, добавить в новый домен и повысить до контроллера домена в новом домене.
Дополнительные проблемы при развертывании
Ниже приведено несколько дополнительных вопросов, на которые стоит обратить внимание при модернизации основного контроллера домена.
Базы данных SAM и LSA. Все учетные записи пользователей групп и компьютеров копируются из базы данных SAM в базу данных Active Directory. Ключи LSA для доверитель- ; ных отношений, пароли учетных записей компьютеров и другие элементы также копиру- ; ются в базу данных Active Directory. Информация о безопасности из базы данных LSA, ; например, User Rights и Policy Rights копируются в базу данных Security Editor, где они ‘ реализовываются в виде групповых политик доменов и контроллеров доменов.;
Классические доверительные отношения. Любое классическое доверительное отношение I Windows NT между модернизируемым доменом и другими доменами превращается во внешнее j
доверительное отношение, включая односторонние доверительные отношения от домена ресурсов и двусторонние доверительные отношения между доменами учетных записей.
Права доступа. Идентификаторы безопасности пользователей и групп не меняются, поэтому права доступа сохраняются. Пользователи и группы из других доменов Windows NT могут получать доступ с использованием внешних доверительных отношений.
Выделение времени на модернизацию. Служба Netlogon на основном контроллере домена отключается с момента начала модернизации операционной системы и не включается, пока не будет выполнено повышение контроллера домена с последующей перезагрузкой. Все это время сервер не способен выполнять аутентификацию пользователей или вносить изменения в элементы баз данных SAM и LSA. Кроме этого, не поддерживается репликация на резервные контроллеры домена.
Необходимые права доступа для выполнения модернизации. Для запуска модернизации необходимы полные привилегии учетной записи Administrator (Администратор) в пределах домена Windows NT. Удостоверьтесь, что точно знаете пароль учетной записи Administrator на случай неполадок и блокирования всех остальных учетных записей.
Подготовка подсистемы хранения. Для модернизации сервера Windows NT до Windows Server 2003 в разделе, где установлена операционная система, должно быть как минимум 1 Гбайт свободного дискового пространства. Еще один раздел, желательно на другом жестком диске, необходим для хранения базы данных Active Directory. Требования к объему этого раздела зависят от предполагаемого объема файла Ntds.dit, в котором хранится база данных Active Directory. Зеркалированного массива дисков размером 9 Гбайт вполне достаточно для хранения базы данных, содержащей информацию о 250 тысячах пользователей. Все разделы должны использовать файловую систему NTFS и быть полностью дефрагментированы.
Обзор. Классический основной контроллер домена Windows NT одновременно выполняет роль Domain Master Browser (главный обозреватель домена). За время длительной процедуры модернизации могут быть проведены выборы обозревателя, в которых управление базой данных обозревателя может быть передано одному из резервных контроллеров домена (BDC). Но в базе данных WINS в качестве главного обозревателя домена все еще будет зарегистрирован основной контроллер домена. По окончании последней перезагрузки сервера, когда он будет работать уже в качестве полноценного контроллера домена, этот сервер организует новые выборы (election), возвратит себе управление базой данных и опять станет главным обозревателем домена.
Непосредственная модернизация домена Windows NT 4.0
На этом этапе план развертывания должен быть полностью подготовлен. Должен быть указан список контроллеров домена Windows NT, которые будут модернизированы, а также указан порядок модернизации контроллеров домена. Должны быть удовлетворены все требования к модернизации и заварена большая чашка кофе.
На рис. 9.7 изображена схема классического домена Windows NT, в котором работают несколько серверов, выступающих в роли хозяев, и создан единственный домен ресурсов. В сети масштаба предприятия существовало бы несколько доменов ресурсов с перекрестными доверительными отношениями между несколькими доменами учетных записей. На схеме показан пользователь из второго домена учетных записей, получающий доступ к совместно используемому ресурсу на сервере домена ресурсов.
ГлавныйГлавныйРепликация наBDC с помощьюслужбы LMRepIРепликация наBDC с помощьюслужбы LMRepIдомендоменГлавныйГлавныйдомендоменPDC под у. управлением ' Windows NT 4.0PDC под у. управлением ' Windows NT 4.0Классическое одностороннее доверительное отношение Windows NT (нетранзитивное)Классическое одностороннее доверительное отношение Windows NT (нетранзитивное)BDC под управлением Windows NTBDC под управлением Windows NTДоменресурсовPDC подуправлениемWindows NT 4.(ДоменресурсовPDC подуправлениемWindows NT 4.(Репликация наBDC с помощьюслужбы LMRepIРепликация наBDC с помощьюслужбы LMRepIДва классическиходностороннихдоверительныхотношения WindowsNT (нетранзитивные)Два классическиходностороннихдоверительныхотношения WindowsNT (нетранзитивные)PDC под С^'^иип управлениемWindows NT 4.0■BDC под управлениемWindows NTPDC под С^'^иип управлениемWindows NT 4.0■BDC под управлениемWindows NTРабочая станцияпроходитаутентификациюв собственномдоменеРабочая станцияпроходитаутентификациюв собственномдоменеФайловый серверФайловый серверСервер проходит аутентификацию в домене ресурсовСервер проходит аутентификацию в домене ресурсови сервер печатии сервер печатиПользовательпроходитаутентификациюв домене АПользовательпроходитаутентификациюв домене А6*Рабочая6*РабочаяРабочаяРабочаястанция клиентастанция клиента
Главный
Главный
Репликация наBDC с помощьюслужбы LMRepI
Репликация наBDC с помощьюслужбы LMRepI
домен
домен
Главный
Главный
домен
домен
PDC под у. управлением ' Windows NT 4.0
PDC под у. управлением ' Windows NT 4.0
Классическое одностороннее доверительное отношение Windows NT (нетранзитивное)
Классическое одностороннее доверительное отношение Windows NT (нетранзитивное)
BDC под управлением Windows NT
BDC под управлением Windows NT
Доменресурсов
PDC подуправлениемWindows NT 4.(
Доменресурсов
PDC подуправлениемWindows NT 4.(
Репликация наBDC с помощьюслужбы LMRepI
Репликация наBDC с помощьюслужбы LMRepI
Два классическиходностороннихдоверительныхотношения WindowsNT (нетранзитивные)
Два классическиходностороннихдоверительныхотношения WindowsNT (нетранзитивные)
PDC под С^'^иип управлением
Windows NT 4.0
■
BDC под управлениемWindows NT
PDC под С^'^иип управлением
Windows NT 4.0
■
BDC под управлениемWindows NT
Рабочая станцияпроходитаутентификациюв собственномдомене
Рабочая станцияпроходитаутентификациюв собственномдомене
Файловый сервер
Файловый сервер
Сервер проходит аутентификацию в домене ресурсов
Сервер проходит аутентификацию в домене ресурсов
и сервер печати
и сервер печати
Пользовательпроходитаутентификациюв домене А
Пользовательпроходитаутентификациюв домене А
6*
Рабочая
6*
Рабочая
Рабочая
Рабочая
станция клиента
станция клиента
Рис. 9.7. Классический домен Windows NT, в котором работают несколько хозяев
Сервер не в состоянии самостоятельно выполнить аутентификацию пользователя, поскольку не установлены доверительные отношения между доменом ресурсов и доменом, в котором зарегистрирована учетная запись пользователя. В WindowsNT не поддерживаются транзитивные доверительные отношения. Пользователь должен зарегистрироваться с помощью аутентификационных данных из первого домена учетных записей или предоставить другой набор аутентификационных данных при монтировании ресурса.
В следующих примерах описана модернизация домена Windows NT, в котором несколько серверов выступают в роли хозяев, до единого леса Windows Server 2003. Администраторы в этом примере решили сохранить структуру доменов при переходе на Active Directory. В разделе “Миграция доменов Windows NT и Windows 2000 в домены Windows Server 2003” рассматривается преобразование нескольких классических доменов в единый домен нового поколения.
Рассмотрим последовательность действий.
Установите домен, который будет служить корневым доменом леса.
Модернизируйте основной контроллер (PDC) первого домена учетных записей.
Модернизируйте резервные контроллеры (BDC) первого домена учетных записей.
Переключите функциональный уровень первого домена учетных записей на Windows Server 2003.
Модернизируйте основной и резервные контроллеры домена ресурсов в первом домене учетных записей или переместите всех пользователей и все компьютеры в новый домен Windows Server 2003.
Переключите функциональный уровень всех модернизированных доменов ресурсов на Windows Server 2003.
Модернизируйте основной и резервные контроллеры второго и последующих доменов учетных записей и переключите их функциональный уровень на Windows Server 2003.
Переключите функциональный уровень леса на Windows Server 2003.
Установка домена-контейнера
Если существует несколько доменов учетных записей под управлением Windows NT, которые необходимо сохранить при модернизации до Windows Server 2003 и переходе на Active Directory, стоит рассмотреть возможность создания домена-контейнера, который будет выступать в роли корневого домена леса. Иногда такое решение называется пустым корнем (empty root), так как в этом корневом домене отсутствуют действующие учетные записи пользователей. Пример такого решения показан на рис. 9.8.
Пустой корневой домен
Функциональный уровень Windows Server 2003
Главный домен АГлавный домен АГлавный домен БГлавный домен Би сервер печатии сервер печатиРис. 9.8. Модернизация домена Windows NT, которая начинается с создания нового домена Windows Server 2003, выступающего в роли контейнера для существующих доменов учетных записейРис. 9.8. Модернизация домена Windows NT, которая начинается с создания нового домена Windows Server 2003, выступающего в роли контейнера для существующих доменов учетных записей
Главный домен А
Главный домен А
Главный домен Б
Главный домен Б
и сервер печати
и сервер печати
Рис. 9.8. Модернизация домена Windows NT, которая начинается с создания нового домена Windows Server 2003, выступающего в роли контейнера для существующих доменов учетных записей
Рис. 9.8. Модернизация домена Windows NT, которая начинается с создания нового домена Windows Server 2003, выступающего в роли контейнера для существующих доменов учетных записей
Пустой корень явно определяет, кто управляет создаваемым лесом. Оба контекста именования, Configuration и Schema, рассматриваются как часть корневого домена, хотя копия этих контекстов именования хранится в каждом домене.
Повышение контроллера домена и локальная база данных SAM
При повышении сервера Windows Server 2003 до контроллера домена раздел системного реестра зам удаляется и заменяется стандартным разделом, который содержит учетную запись Administrator, отключенную учетную запись Guest и стандартные встроенные группы для сервера, кроме группы Server Operators, вместо которой присутствует группа Power Users.
Если сервер используется для поддержки файловых служб и служб печати или на сервере присутствуют локальные группы или учетные записи пользователей, не забудьте заменить записи для этих учетных записей в списках контроля доступа к файлам и принтерам до повышения сервера.
Администраторы пустого корневого домена имеют право управлять контекстами именования, общими для всего леса, а администраторы дочерних доменов могут управлять собственными контекстами именования, но не обладают правами управления в пределах всего леса. Без корневого домена, который выступает в роли контейнера, первый модернизированный домен учетных записей стал бы корневым доменом нового леса и администраторы этого домена получили бы слишком широкие полномочия.
Домен-контейнер установить очень просто, так как не приходится модернизировать контроллеры домена под управлением операционных систем Windows NT 4.0 или Windows 2000. Выберите как минимум два сервера, которые соответствуют требованиям к контроллерам домена, и установите на них операционную систему Windows Server 2003. Эти серверы могут поддерживать работу службы DNS для предоставления клиентам зон, интегрированных в Active Directory, и хранения контекста именования DNS Application. Позднее контексты именования DNS можно разместить на выбранных контроллерах других доменов или создать отдельную топологию репликации DNS.
Кроме этого, использование домена-контейнера упрощает начальную установку. Создание первого контроллера домена в домене-контейнере и в пределах всего леса требует только запуска утилиты Dcpromo на сервере Windows Server 2003. Функциональный уровень домена может быть переключен на Windows Server 2003 сразу же после установки первого контроллера домена.
Повышение сервера Windows Server 2003 до контроллера домена рассматривается в процедуре 9.1. Кроме этого, в процедуре рассматривается инициализация первого домена в пределах леса. Удостоверьтесь, что сервер настроен на использование DNS-сервера, который будет хранить зону Active Directory.
Процедура 9.1. Повышение первого сервера Windows Server 2003 до контроллера домена
Запустите утилиту Dcpromo из окна Run (Выполнить). Запустится мастер установки Active Directory.
Щелкните на кнопке Next (Далее). В открывшемся окне Domain Controller Туре (Тип кон- троллера домена) выберите Domain Controller For A New Domain (Контроллер домена в новом домене). Помните, что при этом будут удалены существующие разделы системных реестров SAM и Securi ty (рис. 9.9).
Щелкните на кнопке Next (Далее). Откроется окно Create New Domain (Создать новый домен). Выберите Domain In A New Forest (Новый домен в новом лесу). Это приведет к назначению нового домена-контейнера в качестве корневого домена леса.
Щелкните на кнопке Next (Далее). Откроется окно New Domain Name (Новое имя домена). Введите полностью определенное имя DNS для домена-контейнера (рис. 9.10).
Рис. 9.9. Окно Domain Controller Туре утилиты DcpromoРис. 9.9. Окно Domain Controller Туре утилиты Dcpromo
Рис. 9.9. Окно Domain Controller Туре утилиты Dcpromo
Рис. 9.9. Окно Domain Controller Туре утилиты Dcpromo
Active Directory Installation Wizard
New D owain Name
Specify a name for the new domain.
Tee the MONS name far tvnewdwMn wwmh headquetewwearoptei «creed
Ful DNS name tar new domm |companycom-nni.1»^
«Back || C*ca ]
Puc. 9.10. Окно New Domain Name утилиты Dcpromo
Щелкните на кнопке Next (Далее). Мастер отправит запрос службе WINS и широковещательные запросы, чтобы убедиться, что ни один домен или элемент безопасности NetBIOS не зарегистрировал “плоское" имя, соответствующее введенному имени DNS. Если коллизия имен не возникла, откроется окно NetBIOS Domain Name (Имя домена NetBIOS), в котором будет отображаться “плоское” имя нового домена.
Щелкните на кнопке Next (Далее). В открывшемся окне Database and Log Folders (Папки базы данных и журналов) введите путь к тому, в котором будут храниться файлы Active Directory (рис. 9.11).
Щелкните на кнопке Next (Далее). В открывшемся окне Shared System Volume (Общий системный том) введите путь к тому, в котором будет храниться каталог Sysvol. Это может быть тот же том, в котором хранятся файлы Active Directory.
Щелкните на кнопке Next (Далее). Откроется окно DNS Registration Diagnostics (Диагностика регистрации DNS), как показано на рис. 9.12. Утилита анализа DNS сообщит о результатах диагностической проверки. Если DNS-сервер доступен, а зона существует и готова для динамиче-
ских обновлений, утилита анализа сообщит об успешности проверки. В противном случае будет выдано сообщение об ошибке и предложены действия по исправлению ситуации.
Рис. 9.11. Окно Database and Log Folders утилиты DcpromoРис. 9.11. Окно Database and Log Folders утилиты Dcpromo
Рис. 9.11. Окно Database and Log Folders утилиты Dcpromo
Рис. 9.11. Окно Database and Log Folders утилиты Dcpromo
DNS RagirbaKon Diagnostic»
Vertly DNS support, « ntial DNS on Iha computet.
Dia»wHicRe»*'*
ThotaoMraioti dagnoilic hat been art 1 6na
Tbewed*eeu<eiedwanix*H»ieingtod*i™wllheONSwv*wei «Meh We tan aee*r «<1 legatar wggart» ejewic red»»
f« moa «itamafen, мЫИв atepe l« сама Hr fwblan. ма tub.
■ThemiaavOHS«*v*lerWlwaK»inS2.iaOLl)jrj
G lhevec«iaot»d*»prabiB* EadermlheDNS <t»gno«bcl«t agarx
Г keHwd«rfawlheON8«ewenWiMei|ii*r.«id«ellhfo<»ii>uUrlau«e Ie DNS mw etetehndDNS aew.
Г 1 wigaeact the protiemlat* by oonlgtrting DNS manual iMveiced)
< flack | H«d> | Cancel |
Puc. 9.12. Окно DNS Registration Diagnostics
Щелкните на кнопке Next (Далее). Откроется окно Permissions (Разрешения), показанное на рис. 9.13. Если в сети отсутствуют серверы удаленного доступа под управлением WindowsNT 4.0, выберите переключатель Permissions Compatible Only With Windows 2000 or Windows Server 2003 Operating System (Права доступа, совместимые только с Windows 2000 или Windows Server 2003).
Щелкните на кнопке Next (Далее). В открывшемся окне Directory Services Restore Mode Administrator Password (Пароль администратора для режима восстановления) введите пароль, который будет назначен учетной записи Administrator в новой базе данных SAM, устанавливаемой на сервер. Эта учетная запись предоставляет доступ при недоступности Active Directory.
Щелкните на кнопке Next (Далее). Откроется окно с выбранными параметрами.
Рис. 9.13. Окно Permissions утилиты De promo
Щелкните на кнопке Next (Далее). Мастер начнет установку службы каталогов. Это может занять от трех до пяти минут в зависимости от производительности сервера. При установке нового контроллера домена в существующем домене дополнительное время потребуется для репликации базы данных Active Directory на новый контроллер домена.
После окончания повышения происходит перезагрузка компьютера. Для аутентификации после перезагрузки воспользуйтесь учетной записью Administrator (Администратор), которая была задана в процессе повышения.
Перед тем как продолжать настройку, убедитесь в правильной регистрации записей SRV на сервере DNS. Регистрация выполняется средствами службы Netlogon и требует около пяти минут. Через пять минут после регистрации на консоли контроллера домена проверьте содержимое зоны DNS. Если записи SRV отсутствуют, нужно устранить эту проблему немедленно. Если причиной проблемы является неправильная настройка DNS на контроллере домена, то аутентификацию можно запустить вручную, остановив и перезапустив службу Netlogon.
Устранение неисправностей при повышении сервера
Самой распространенной причиной проблем в процессе повышения является неправильная настройка службы DNS. Если в процессе повышения возникает необъяснимая ошибка, внимательно проверьте параметры службы DhJS. Существует множество малоизвестных параметров DNS, установка которых может привести к срыву всего процесса повышения сервера. Среди самых распространенных причин неудачного повышения можно назвать следующие.
Поврежденные данные в разделах реестра SAM или Security
Повреждение системного реестра или неправильные параметры критически важных служб в системном реестре
Недостаточный объем оперативной памяти или дискового пространства во время повышения (это может быть связано с массовой фрагментацией, а не с реальным недостатком дискового пространства)
Проблема в работе сетевого соединения
Повреждение файлов драйверов
В процессе работы утилиты Dcpromo окном Configuring Active Directory (Настройка Active Directory) предоставляется информация об операциях, которые выполняются мастером повышения. Мастер создает полный отчет в файле Dcpromoui. log, который хранится в каталоге \Windows\Debug. Еще в одном файле журнала, Dcpromo.log, сохраняются подробности каждого вызова API и отчеты об ошибках.
В табл. 9.1 показана стандартная последовательность событий во время повышения контроллера домена. Последовательность событий записывается в файл Dcpromo. log мастером установки Active Directory. В этой таблице показан пример удачного процесса повышения.
Таблица 9.1. Записи в файле Dcpromo.log при успешном повышении контроллера домена
Действие
Описание
Проверка пути
Проверяются и при необходимости создаются пути к базе данных Active Directory, журналам и каталогу Sysvol
Создание домена
Начало повышения
Проверяется уникальность "плоского" имени домена
Останавливается служба Netlogon и создаются каталоги для копирования. Настраивается репликация каталога Sysvol
Установка Active Directory
Проверяются права доступа, необходимые для создания домена от имени указанной учетной записи. Создаются файлы Active Directory. Создается и заполняется контекст именования Schema. Создается и заполняется контекст именования configuring. Создается и заполняется контекст именования Domain
Создание учетных записей
Учетные записи пользователей, компьютеров и групп копируются из базы данных SAM в базу данных Active Directory. Домену назначается оригинальный идентификатор безопасности домена
Установка параметров безопасности
Политики LSA копируются и подготавливаются. Инициализируется служба Windows Time Service. Настраивается служба Netlogon. Инициализируются политики LSA
Установка параметров безопасности системного реестра Установка параметров безопасности файлов
Очистка
Для системного реестра применяется шаблон безопасности "Повышение контроллера домена"
Шаблон безопасности "Повышение контроллера домена" применяется к системным файлам и каталогам
Удаляются временные файлы и устаревшая информация для служ-
Успешное завершение
бы Netlogon
Мастер сообщает об успешном завершении повышения
Добавление контроллеров домена
Не стоит хранить файлы Active Directory на единственном контроллере домена. Повысьте второй контроллер домена, как только первый контроллер начнет нормально выполнять свои функции.
Единственной разницей между повышением первого контроллера домена и повышением второго контроллера домена является выбор типа контроллера в начале работы программы Dcpromo. Переключатель Additional Domain Controller For An Existing Domain (Дополнительный контроллер домена в существующем домене) указывает мастеру на необходимость реплицировать содержимое базы данных Active Directory с существующего контроллера домена.
Если необходимо избежать длительной процедуры репликации крупной базы данных Active Directory по низкоскоростному внешнему соединению, можно заполнить базу данных, воспользовавшись резервной копией базы данных с другого контроллера домена.
Для использования этой возможности сначала запустите резервное копирование состояния системы на первом контроллере домена. После этого восстановите резервную копию во временный каталог на сервере, который будет повышен до контроллера домена. Удостоверьтесь, что временный каталог находится в дисковом разделе с большим объемом свободного дискового пространства. Необходимо как минимум 300 Мбайт, не считая размера файла Ntds. dit, так как утилита Nt backup позволяет восстанавливать полное состояние системы, а не только файлы Active Directory.
Чтобы получить возможность использования локальной копии файлов Active Directory, запустите утилиту Dcpromo с параметром /adv: dcpromo /adv. В расширенном режиме при выборе дополнительного контроллера домена в существующем домене мастер откроет окно Copying Domain Information (Копирование информации домена), в котором можно указать расположение файла с резервной копией (рис. 9.14). Укажите временный каталог, в который были восстановлены файлы состояния систёмы.
Рис. 9.14. Мастер установки Active Directory. Дополнительные параметры. В окне Copying Domain Information предоставляется возможность использования файла резервной копии для заполнения базы данных Active Directory
Если файлы Active Directory были скопированы с сервера глобального каталога, утилита Dcpromo запросит необходимость включения глобального каталога на новом контроллере домена. Можно отказаться, и мастер импортирует контекст именования исходного домена, а также контексты именования Configuration и Schema.
По завершении повышения убедитесь, что средство проверки согласованности знаний (КСС) создало соединения с другими контроллерами домена в пределах сайта. Воспользуйтесь консолью Active Directory — Sites and Services (Active Directory — сайты и службы) для просмотра объектов Connection и проверки правильности репликации. Дополнительную информацию по этой теме можно получить в главе 7, “Управление репликацией Active Directory”.
При необходимости можно создать внешнее доверительное отношение к одному или ко всем доменам учетных записей WindowsNT. Это не обязательно для развертывания леса, но позволит гарантировать возможность просмотра ресурсов корневого домена для администраторов доменов учетных записей. Любое внешнее доверительное отношение между корневым доменом и доменами WindowsNT будет преобразовано в доверительное отношение между доменами при модернизации доменов учетных записей.
Определение ролей контроллеров домена
Первый контроллер домена по умолчанию является сервером глобального каталога. При настройке пустого корневого домена включите функцию глобального каталога и на вторюм сервере. Это позволяет обеспечить устойчивость к сбоям. Если оставить один сервер стандартным контроллером домена, очень важно передать этому серверу роль хозяина инфраструктуры (Infrastructure Master).
Для настройки контроллера домена в качестве сервера глобального каталога воспользуйтесь консолью Active Directory — Sites and Services (Active Directory — сайты и службы). Откройте окно Properties (Свойства) объекта NTDS Settings в поддереве сервера и установите флажок Global Catalog (Глобальный каталог), как показано на рис. 9.15.
Рис. 9.15. В свойствах объекта NTDS Settings для повышенного контроллера домена установлен флажок Global Catalog
Предоставьте серверу некоторое время для репликации содержимого глобального каталога с другого сервера глобального каталога или для сбора частичных копий контекстов именования с контроллеров доменов в различных доменах леса. Результаты этой репликации отображаются в журнале событий.
Для просмотра списка серверов глобального каталога можно воспользоваться утилитой Replmon. Щелкните правой кнопкой мыши на сервере и выберите пункт Show Global Catalog Servers In Enterprise (Показывать серверы глобального каталога на предприятии) из контекстного меню. Кроме этого, можно применить утилиту ADSI Edit (Adsiedit .msc) из пакета Support Tools для опроса порта 3268. Это стандартный порт, на который отправляются LDAP-запросы для глобального каталога. Если компьютер отвечает на запросы, отправленные на этот порт, он является сервером глобального каталога.
Оставшиеся роли хозяев операций можно возложить на первый контроллер домена, если для передачи ролей нет других причин. Например, второй сервер может иметь более высокую производительность или на нем может быть установлено два центральных процессора, что делает его более подходящим кандидатом на выполнение роли PDC Emulator. При передаче роли PDC Emulator стоит передать и роль хозяина относительных идентификаторов (RID
Master). Это необязательно, особенно при работе на функциональном уровне Windows Server 2003. Если роли PDC Emulator и RID Master не распределены между двумя контроллерами домена, восстановление после отказа выполняется немного проще.
Если это первый сервер в пределах сайта, он станет генератором межсайтовой топологии (ISTG) и связующим сервером. Воспользуйтесь консолью Active Directory — Sites and Services (Active Directory — сайты и службы) для проверки установленных соединений с другими связующими серверами и проверки репликации в соответствии с расписанием, установленным для связей сайтов (site links).
Смена функционального уровня корневого домена на уровень Windows Server 2003
По умолчанию новый домен Windows Server 2003 работает на функциональном уровне Windows 2000 Mixed. Нет необходимости эксплуатировать домен-контейнер на более низком функциональном уровне, поэтому перед модернизацией доменов Windows NT следует сменить функциональный уровень корневого домена на уровень Windows Server 2003.
Для изменения функционального уровня домена воспользуйтесь консолью Active Directory — Users and Computers (Active Directory — пользователи и компьютеры). Щелкните правой кнопкой мыши на вершине дерева и выберите Raise Domain Functional Level (Повысить функциональный уровень домена) из контекстного меню. Откроется окно, в котором можно будет выбрать функциональные уровни Windows 2000 Native и Windows Server 2003 (рис. 9.16).
Рис. 9.16. Переходим на функциональный уровень Windows Sewer в окне Raise Domain Functional Level
После переключения функционального уровня домена на Windows Server 2003 для предоставления новых возможностей операционной системы Windows Server 2003 необходимо перезагрузить контроллер домена.
DNS-зоны, интегрированные в Active Directory
Теперь можно переходить к модернизации доменов учетных записей, но стоит остановиться и потратить некоторое время на перенастройку инфраструктуры DNS. При повышении контроллеров корневого домена на существующем сервере были зарегистрированы записи SRV. Если желательно использование DNS-зон, интегрированных в Active Directory, то
можно установить службу DNS на один из новых контроллеров домена и настроить его в качестве основного DNS-сервера для зоны Active Directory.
Обратите внимание, что в параметрах стека протоколов TCP/IP на контроллере домена необходимо указать другой контроллер домена в качестве предпочтительного DNS-сервера. Это позволит избежать проблем, когда ошибка репликации приводит к блокированию обновлений записей DNS, что затем еще больше усугубляет проблему репликации. Дополнительная информация об установке службы DNS и настройке параметров зоны приводится в главе 5, “Управление службой DNS”.
На функциональных уровнях Windows 2000 Mixed и Windows 2000 Native записи ресурсов для интегрированных зон DNS хранятся в контексте именования Domain. Этого достаточно, если в пределах леса существует единственный домен, но если используется несколько доменов с географически удаленными контроллерами, могут возникнуть проблемы. Клиенты нуждаются в записях SRV, которые предоставляют информацию о серверах в пределах всего леса.
В операционной системе Windows 2000 для предоставления локального доступа к записям SRV, описывающим серверы в пределах леса, нужно было создавать основную зону для записей SRV в иерархии _msdcs и размещать вторичные копии этой зоны на DNS-серверах различных доменов.
-Ш|х1-Ш|х1Status as of:'Status as of:'В операционной системе Windows Server 2003 эта проблема решается более элегантно. При переходе на функциональный уровень Windows Server 2003 записи ресурсов DNS можно разместить в собственном контексте именования, а не в контексте именования Domain. Операционная система Windows Server 2003 для этих целей создает два контекста именования: один — для записей SRV в пределах домена, а второй — для записей SRV в пределах леса. Новые контексты именования можно просмотреть с помощью утилиты Replication Monitor, которая входит в пакет Support Tools. На рис. 9.17 показан пример использования этой утилиты. Содержимое контекстов именования можно просматривать с помощью утилиты LDAP Browser, Idp, которая также входит в состав Support Tools.
-Ш|х1
-Ш|х1
Status as of:'
Status as of:'
. • Active Directory Replication Monitor
, ^Monftxed Servers ' '
- S- j| Default-First-Site-Name
а M
®l 1 DC-cornpanyDC-com
6 0 OI-ConfiguraboriJ)C-cofTipanyJ)C-com
I I DC*DomainDn^one$.DCecompary,DC"Com
I k OC-ForestDnsZonesDC-company.DC-com
21
ГГГОгмййГ
Г
Г
Puc. 9.17. Использование утилиты Replication Monitor для просмотра контекстов именования DNS, созданных при переходе на функциональный уровень Windows Server2003
Обновление основных контроллеров первого домена учетных записей
После создания домена-контейнера можно переходить к модернизации первого домена учетных записей. На рис. 9.18 показаны результаты этого этапа модернизации. Сначала модернизируется операционная система, после чего автоматически запускается утилита Dcpromo
с целью создания домена Active Directory. В процессе повышения домен будет включен в состав леса, сформированного с помощью домена-контейнера.
Пустой корневой доменПустой корневой доменФункциональный уровень Windows Server 2003Функциональный уровень Windows Server 2003Контроллер домена под управлением Windows Server 2003Контроллер домена под управлением Windows Server 2003Двустороннее транзитивное доверительное отношение между родительским и дочерним доменамиДвустороннее транзитивное доверительное отношение между родительским и дочерним доменамиГлавный домен БГлавный домен БВнешнее доверительное отношение, двустороннее, нетразитивноеВнешнее доверительное отношение, двустороннее, нетразитивноеДомен АФункциональный уровень Windows Server 2003Домен АФункциональный уровень Windows Server 2003Домен ресурсовДомен ресурсовОсновной контроллер домена под управлением Windows NT 4.0Основной контроллер домена под управлением Windows NT 4.0файловый сервер и сервер печатифайловый сервер и сервер печатиОсновной контроллер домена под управлением Windows NT 4.0Основной контроллер домена под управлением Windows NT 4.0Рабочая станция клиентаРабочая станция клиентаКонтроллер домена .NETКонтроллер домена .NETРис. 9.18. Домен Windows NT после модернизации контроллера PDC первого домена учетных записейРис. 9.18. Домен Windows NT после модернизации контроллера PDC первого домена учетных записейРезервный контроллердомена под управлениемWindows NT 4.0
Пустой корневой домен
Пустой корневой домен
Функциональный уровень Windows Server 2003
Функциональный уровень Windows Server 2003
Контроллер домена под управлением Windows Server 2003
Контроллер домена под управлением Windows Server 2003
Двустороннее транзитивное доверительное отношение между родительским и дочерним доменами
Двустороннее транзитивное доверительное отношение между родительским и дочерним доменами
Главный домен Б
Главный домен Б
Внешнее доверительное отношение, двустороннее, нетразитивное
Внешнее доверительное отношение, двустороннее, нетразитивное
Домен А
Функциональный уровень Windows Server 2003
Домен А
Функциональный уровень Windows Server 2003
Домен ресурсов
Домен ресурсов
Основной контроллер домена под управлением Windows NT 4.0
Основной контроллер домена под управлением Windows NT 4.0
файловый сервер и сервер печати
файловый сервер и сервер печати
Основной контроллер домена под управлением Windows NT 4.0
Основной контроллер домена под управлением Windows NT 4.0
Рабочая станция клиента
Рабочая станция клиента
Контроллер домена .NET
Контроллер домена .NET
Рис. 9.18. Домен Windows NT после модернизации контроллера PDC первого домена учетных записей
Рис. 9.18. Домен Windows NT после модернизации контроллера PDC первого домена учетных записей
Если операционная система Windows Server 2003 не приобреталась на правах официального лицензирования (master licence или volume licence), то после установки сервер необходимо активировать. На активацию отводится тридцать дней, но система будет регулярно напоминать о необходимости активации, поэтому желательно выполнить эту процедуру сразу после модернизации.
После удовлетворения всех предварительных требований и операций по восстановлению после сбоев выполните последовательность действий, описанную в процедуре 9.2.
Процедура 9.2. Модернизация основного контроллера домена учетных записей
Вставьте в привод установочный компакт-диск операционной системы Windows Server 2003 или запустите утилиту Winnt3 2 с сетевого диска. Это приведет к запуску мастера модернизации.1
В открывшемся окне примите условия лицензионного соглашения и введите ключ продукта, состоящий из 25 символов. Оставшаяся часть процедуры модернизации выполняется без вмешательства администратора.
По окончании последней перезагрузки компьютера автоматически запускается мастер установки Active Directory, утилита Dcpromo. На этом этапе классические разделы системного реестра SAM и Security еще существуют и сервер отвечает на регистрационные запросы. Пользователи все еще могут выполнять аутентификацию в домене с помощью резервных контроллеров домена (ВВС).
Перед использованием мастера Dcpromo запустите интерпретатор командной строки и с помощью утилиты Nslookup убедитесь, что сервер обнаружил DNS-сервер и на этом сервере хранится зона, которая станет основой для домена Active Directory.
В мастере установки Active Directory щелкните на кнопке Next (Далее). Откроется окно Create New Domain (Создать новый домен). Выберите Child Domain In En Existing Tree (Новый дочерний домен в существующем дереве). Это подготовит домен к включению в лес с использованием домена-контейнера в качестве корневого.
Щелкните на кнопке Next (Далее). Откроется окно Network Credentials (Сетевые аутентификационные данные). Введите имя и пароль учетной записи с привилегиями администратор» в корневом домене, а также полностью определенное имя DNS корневого домена.
Щелкните на кнопке Next (Далее). Откроется диалоговое окно Child Domain Installation (Установка дочернего домена). В поле Parent Domain (Родительский домен) введите полностью определенное имя родительского домена. В нашем примере родительским является корневой домен леса. В поле Child Domain (Дочерний домен) введите “плоское” имя модернизируемого домена Windows NT.
Щелкните на кнопке Next (Далее). Откроется окно Database and Log Folders (Папки базы данных и журналов). Введите путь к файлам Active Directory и файлам журналов. Эти каталоги не следует хранить на том же жестком диске, на котором хранятся файлы операционной системы.
Щелкните на кнопке Next (Далее). Откроется окно Shared System Volume (Общий системный том). Введите путь к каталогу Sysvol. Если не планируется значительная нагрузка на сервер при массовой утренней регистрации пользователей, этот каталог может храниться на том же жестком диске, что и файлы Active Directory. Для тома следует использовать файловую систему NTFS.
Щелкните на кнопке Next (Далее). Откроется окно DNS Registration Diagnostics (Диагностика DNS-регистрации), в котором отображается отчет о соединениях с DNS-сервером. Если обнаруживается служба DNS, которая содержит указанную зону, и зона поддерживает динамические обновления, то мастер сообщает об успешном завершении проверки. В противном случае мастер выдает сведения о предполагаемой причине проблемы и предоставляет возможность исправить проблему перед продолжением работы.
Щелкните на кнопке Next (Далее). Откроется окно Permissions (Разрешения). Если не используются серверы удаленного доступа под управлением операционной системы Windows NT 4.0, выберите переключатель Permissions Compatible Only With Windows 2000 or Windows Server 2003 Operating Systems (Разрешения, совместимые только c Windows 2000 или Windows Server 2003).
Щелкните на кнопке Next (Далее). Откроется окно Directory Services Restore Mode Administrator Password (Пароль администратора для режима восстановления). Введите пароль, который будет использоваться для доступа к серверу при недоступности Active Directory. Этот пароль назначается учетной записи Administrator, которая хранится в новой базе данных SAM, устанавливаемой в конце процедуры повышения.
Щелкните на кнопке Next (Далее). Откроется окно с итоговой информацией.
Щелкните на кнопке Finish (Готово). Мастер начнет процедуру повышения.
После повышения сервер выполнит перезагрузку для последнего изменения параметров. В следующем разделе рассматривается набор проверок, которые позволяют убедиться в правильности модернизации.
Проверки после модернизации
После модернизации и повышения основного контроллера домена выполните ряд проверок, которые позволяют убедиться в работоспособности ключевых служб. Рассмотрим набор основных проверок.
Репликация учетных записей на резервные контроллеры домена. Удостоверьтесь, что модернизированный основной контроллер домена, который теперь работает под управлением операционной системы Windows Server 2003 и которому предоставлена роль PDC Emulator, поддерживает репликацию на резервные контроллеры домена. Непосредственная проверка правильности репликации с помощью запуска User Manager (Диспетчер пользователей) на вторичном контроллере домена невозможна, так как User Manager (Диспетчер пользователей) всегда обращается к основному контроллеру домена. Для проверки правильности репликации запустите Server Manager (Диспетчер серверов) на резервном контроллере домена, выберите имя вторичного контроллера домена из списка и воспользуйтесь командой Computer^Synchronize with primary domain controller (Компьютера Синхронизировать с основным контроллером домена). Это приведет к запуску процедуры репликации. Результаты репликации можно просмотреть в журнале событий.
Проверка записей DNS. Обязательно проверьте регистрацию записей SRV для нового домена в зоне DNS. Регистрация выполняется средствами службы Netlogon. На регистрацию требуется несколько минут, поэтому через пять минут после регистрации на консоли сервера проверьте содержимое зоны на сервере DNS. Если записи SRV не появились, исправьте проблему немедленно. Можно остановить и перезапустить службу Netlogon для повторной регистрации записей SRV. По умолчанию сервер выполняет регистрацию раз в час.
Аутентификация пользователей. Зарегистрируйтесь с нескольких рабочих станций, чтобы проверить правильность аутентификации пользователей. Некоторые формы повреждения базы данных SAM могут привести к ситуации, когда пользователи операционной системы Windows 98 могут зарегистрироваться, а пользователи операционной системы Windows NT — не могут. Это связано с ошибкой при импорте хешированного пароля Windows NT во время процедуры повышения контроллера домена Active Directory.
Групповые политики. Зарегистрируйтесь с рабочей станции под управлением операционной системы Windows ХР или Windows 2000, чтобы убедиться в использовании аутентификации Kerberos и предоставлении групповых политик с модернизированного основного контроллера домена (PDC). Для этого можно воспользоваться утилитой Kerbtray, которая предоставляется в составе Resource Kit.
Параметры профилей. Убедитесь, что пользователи получают перемещаемые профили и домашние каталоги, которые указаны в параметрах учетной записи.
Проверка коммутируемого доступа. Как минимум для одного пользователя проверьте возможность коммутируемого подключения и способность сервера удаленного доступа проверять аутентификационные данные пользователя.
Аутентификация компьютеров. Перезагрузите как минимум по одному клиентскому компьютеру каждого типа под управлением Windows NT, чтобы убедиться в правильности копирования учетных записей компьютеров в базу данных Active Directory. Если в сети присутствуют тысячи компьютеров, можно сравнить общее количество компьютеров до и после модернизации (значения должны совпадать).
Аутентификация с использованием доверительных отношений. Зарегистрируйтесь на рабочей станции, входящей в домен ресурсов, воспользовавшись аутентификационными данными из модернизированного домена, что позволит убедиться в работоспособности доверительного отношения. Если между доменами учетных записей установлено двустороннее доверительное отношение, выполните тестовую регистрацию для учетных записей в обоих доменах. Кроме этого, воспользуйтесь консолью Active Directory — Domains and Trusts (Active Directory — домены и доверия) для проверки присутствия каждого доверия.
Регистрационные сценарии и проверка системных политик. Убедитесь, что существующие регистрационные сценарии и системные политики были перенесены в каталог \WlNNT\Sysvol\Domain\Scripts (системный каталог не переименовывается в процессе модернизации). Установите альтернативную копию регистрационных сценариев для обновления каталога Net logon на резервных контроллерах домена. После этого зарегистрируйтесь на различных рабочих станциях и убедитесь, что все рабочие станции получают регистрационные сценарии.
Проверка доступности совместно используемых ресурсов. Убедитесь, что доступны все существовавшие ранее совместно используемые ресурсы. Это касается и административных (начинающихся с символа $) ресурсов. Самым простым способом является использование команды net share.
Проверка приложений. Если до модернизации сервер обеспечивал работу определенного приложения, проверьте работоспособность приложения после модернизации. Это касается и таких приложений, как агенты резервного копирования (или само приложение резервного копирования), антивирусные агенты, Web-сайты и агенты Simple Network Management Protocol (SNMP).
Модернизация резервных контроллеров домена учетных записей
Некоторое время домен может проработать в режиме Windows 2000 Mixed, но для использования всех возможностей Active Directory, которые предоставляются в операционной системе Windows Server 2003, необходимо переключить функциональный уровень домена на Windows Server 2003. Это означает отключение классических резервных контроллеров домена. Их можно модернизировать или удалить. На рис. 9.19 показана конфигурация домена после этого этапа модернизации.
Если серверы, выступающие в роли резервных контроллеров домена, в состоянии под- ■ держивать работу операционной системы Windows Server 2003 и не обеспечивают работоспособности устаревших приложений, их можно модернизировать до контроллеров домена Windows Server 2003, как был модернизирован основной контроллер домена. Единственным отличием является источник получения файлов для создания локальной копии базы данных Active Directory. Резервный контроллер домена не преобразовывает локальные разделы системного реестра SAM и Security, а копирует содержимое базы данных с другого контроллера домена Active Directory.
Пустой корневой доменПустой корневой доменWindows Server 2003Windows Server 2003Домен АДомен АДомен Windows NTДомен Windows NTОсновной контроллер домена под управлением Windows NT 4.0Основной контроллер домена под управлением Windows NT 4.0файловый сервер и сервер печатифайловый сервер и сервер печатиКонтроллер домена под управлением Windows Server 2003Контроллер домена под управлением Windows Server 2003Домвн ресурсовДомвн ресурсовФункциональный уровень Windows Server 2003Функциональный уровень Windows Server 2003Рис. 9.19. Смешанные домены под управлением WindowsNT и Windows Server2003 после модернизации оставшихся резервных контроллеров первого домена учетных записейРис. 9.19. Смешанные домены под управлением WindowsNT и Windows Server2003 после модернизации оставшихся резервных контроллеров первого домена учетных записейОсновнойконтроллерJ домена подуправлениемWindows NT 4.0ОсновнойконтроллерJ домена подуправлениемWindows NT 4.0Рабочая станция клиентаРабочая станция клиента
Пустой корневой домен
Пустой корневой домен
Windows Server 2003
Windows Server 2003
Домен А
Домен А
Домен Windows NT
Домен Windows NT
Основной контроллер домена под управлением Windows NT 4.0
Основной контроллер домена под управлением Windows NT 4.0
файловый сервер и сервер печати
файловый сервер и сервер печати
Контроллер домена под управлением Windows Server 2003
Контроллер домена под управлением Windows Server 2003
Домвн ресурсов
Домвн ресурсов
Функциональный уровень Windows Server 2003
Функциональный уровень Windows Server 2003
Рис. 9.19. Смешанные домены под управлением WindowsNT и Windows Server2003 после модернизации оставшихся резервных контроллеров первого домена учетных записей
Рис. 9.19. Смешанные домены под управлением WindowsNT и Windows Server2003 после модернизации оставшихся резервных контроллеров первого домена учетных записей
ОсновнойконтроллерJ домена подуправлениемWindows NT 4.0
ОсновнойконтроллерJ домена подуправлениемWindows NT 4.0
Рабочая станция клиента
Рабочая станция клиента
Контроллер доменапод управлениемWindows Server 2003
Внешнее двустороннеенетранзитивноедоверительноеотношение
Вторичный контроллер домена Windows NT 4.0
Если резервный контроллер домена находится рядом с основным контроллером домена, модернизация и повышение не должны занять много времени. На этом этапе база данных Active Directory еще не велика и не имеет сложной структуры, так как сохраняется обратная совместимость с существующими резервными контроллерами домена. Если в сети присутствует несколько тысяч пользователей, можно воспользоваться файлами резервных копий, как описано в разделе о модернизации домена-контейнера.
Новые контроллеры домена под управлением операционной системы Windows Server 2003 можно создавать в пределах того же сайта, что и модернизированный основной контроллер домена. После этого новые контроллеры домена можно устанавливать в удаленных сайтах. На удаленном сайте локальный администратор должен подключить сервер к сети и настроить параметры протокола TCP/IP. На этом этапе переместите сервер в нужный сайт, указав соответствующую новую подсеть.
После модернизации резервного контроллера домена убедитесь, что созданный контроллер домена Windows Server 2003 поддерживает правильную репликацию с другими контрол-
лерами домена. Если это первый контроллер в пределах сайта, проверьте его работу в качестве связующего сервера и рассмотрите возможность включения функции глобального каталога. Кроме этого, проверьте соединения со связующими серверами на других сайтах, определенные объектами связей сайтов.
Модернизация доменов ресурсов
Теперь, когда первая стадия модернизации завершена, необходимо принять решение о будущем доменов ресурсов, показанных на рис. 9.20. Их можно модернизировать, тогда ими будут управлять администраторы домена, как и при использовании Windows NT, или учетные записи компьютеров можно перенести в новый домен Windows Server 2003 и полностью отказаться от использования доменов ресурсов.
Контроллер домена под управлением Windows Server 2003Контроллер домена под управлением Windows Server 2003Основной контроллер домена под управлением Windows NT 4.0Основной контроллер домена под управлением Windows NT 4.0Внешнее доверительное отношение, двустороннее, нетранзитивноеВнешнее доверительное отношение, двустороннее, нетранзитивноеДомен А функциональный уровень Windows Server 2003Домен А функциональный уровень Windows Server 2003Контроллер домена под управлением Windows Server 2003 Домен Windows NTКонтроллер домена под управлением Windows Server 2003 Домен Windows NTКонтроллер домена.NETКонтроллер домена.NETТранзитивное двустороннее доверительное отношение между доменамиТранзитивное двустороннее доверительное отношение между доменамиДочерний домен, работающий на функциональном уровне Windows Server 2003Дочерний домен, работающий на функциональном уровне Windows Server 2003Контроллер домена под управлением Windows Server 2003Контроллер домена под управлением Windows Server 2003Резервный контроллер домена под управлением Windows NT 4.0Резервный контроллер домена под управлением Windows NT 4.0Файловый сервер и сервер печатиФайловый сервер и сервер печатиРабочая станция клиентаРабочая станция клиента
Контроллер домена под управлением Windows Server 2003
Контроллер домена под управлением Windows Server 2003
Основной контроллер домена под управлением Windows NT 4.0
Основной контроллер домена под управлением Windows NT 4.0
Внешнее доверительное отношение, двустороннее, нетранзитивное
Внешнее доверительное отношение, двустороннее, нетранзитивное
Домен А функциональный уровень Windows Server 2003
Домен А функциональный уровень Windows Server 2003
Контроллер домена под управлением Windows Server 2003 Домен Windows NT
Контроллер домена под управлением Windows Server 2003 Домен Windows NT
Контроллер домена.NET
Контроллер домена.NET
Транзитивное двустороннее доверительное отношение между доменами
Транзитивное двустороннее доверительное отношение между доменами
Дочерний домен, работающий на функциональном уровне Windows Server 2003
Дочерний домен, работающий на функциональном уровне Windows Server 2003
Контроллер домена под управлением Windows Server 2003
Контроллер домена под управлением Windows Server 2003
Резервный контроллер домена под управлением Windows NT 4.0
Резервный контроллер домена под управлением Windows NT 4.0
Файловый сервер и сервер печати
Файловый сервер и сервер печати
Рабочая станция клиента
Рабочая станция клиента
Рис. 9.20. Смешанные домены Windows NT и Windows Server2003 после модернизации контроллеров домена в домене ресурсов
Если принято решение о сохранении раздельных доменов, как можно раньше переключите функциональный уровень на Windows 2000 Native. Это позволит клиентам из других доменов получать доступ к ресурсам с использованием транзитивных доверительных отноше-' ний по протоколу Kerberos. .
Модернизация оставшихся главных доменов учетных записей
На этом этапе миграция классического домена Windows NT, включая домены учетных записей и домены ресурсов, завершена. Теперь необходимо модернизировать оставшиеся домены учетных записей и включить их в лес Windows Server 2003.
Модернизация оставшихся доменов учетных записей выполняется так же, как и модернизация первого домена. DNS-имя домена должно входить в пространство имен корневого домена. Проверьте доступность ресурсов для пользователей и репликацию между контроллерами домена, особенно если контроллеры находятся в различных сайтах. Не ошибитесь, предположив, что межсайтовая репликация будет работать сама по себе. Конечно, часто именно так и происходит, но без проверки нельзя быть в этом уверенным.
Кроме этого, необходимо внимательно проверить транзитивные доверительные отношения, которые создаются между доменами (процедура 9.3). Для этого можно воспользоваться Trust Wizard (Мастер доверия), доступным на консоли Active Directory— Domains and Trusts (Active Directory — домены и доверия).
Процедура 9.3. Проверка транзитивного доверительного отношения
На одном из контроллеров домена откройте консоль Active Directory — Domains and Trusts (Active Directory — домены и доверия)
Откройте окно свойств одного из доменов, а затем вкладку Тrusts (Доверительные отношения), которая показана на рис. 9.21.
Рис. 921. Окно свойств, в котором отображается запись доверительного отношения между деревом и корневым доменом
Выделите доверительное отношение и щелкните на кнопке Properties (Свойства).
В окне Properties (Свойства) щелкните на кнопке Validate (Проверить). Будет выдан запрос на ввод аутентификационных данных для удаленного домена.
Если проверка завершится успешно, значит, общая для двух доменов секретная учетная запись доступна и оба домена знают пароль. Если проверка завершается неудачно, может потребоваться удаление доверительного отношения. Если в результате проверок оказывается, что в домене ресурсов доступны все функциональные возможности, повысьте оставшиеся контроллеры домена.
Смена функционального уровня леса на уровень Windows Server 2003
После отказа от контроллеров домена устаревших версий можно переходить на функциональный уровень Windows Server 2003. Это предоставляет множество дополнительных возможностей. В основном, это возможность раздельной репликации членов групп вместо репликации списка как одного целого. Кроме этого, генератор межсайтовой топологии (ISTG) и средство проверки согласованности знаний (КСС) используют более простой и быстрый алгоритм расчета, что значительно увеличивает масштабируемость леса.
Смените функциональный уровень леса с помощью консоли Active Directory — Domains and Trusts (Active Directory — домены и доверия). Щелкните правой кнопкой мыши на вершине дерева и выберите из контекстного меню команду Raise Forest Functional Level (Повысить функциональный уровень леса). Откроется окно Raise Forest Functional Level (Повышение функционального уровня леса), показанное на рис. 9.22.
•\ Afcwjwww8wl6toel1Unc*»Mlie¥*fceweiberwMreri.F«mwf*xm*№ fawtlmcMmdlBwLcickH*
I в*» I c*Mi | a* I
Рис.9.22. Выберите функциональный уровень Win-dows Server2003в окне Raise Forest Functional Level
Щелкните на кнопке Raise (Повысить) для завершения перехода на новый функциональный уровень. Однако дополнительные возможности не будут доступны, пока в пределах леса существуют домены с функциональным уровнем ниже Windows Server 2003. Для полного перехода необходимо перезагрузить все контроллеры всех доменов в пределах леса.
После переключения функционального уровня леса на Windows Server 2003 развертывание можно официально считать ЗАВЕРШЕННЫМ! Теперь администратор может выбирать, куда поехать в отпуск!
Модернизация леса Windows 2000
Если развертывание операционной системы Windows 2000 уже завершено, модернизация до Windows Server 2003 не должна потребовать значительных усилий. Серверы, которые в состоянии работать в качестве контроллеров домена Windows 2000, вполне подходят для работы
под управлением Windows Server 2003. Но если аппаратные средства удовлетворяют только минимальным требованиям для новой операционной системы, то стоит рассмотреть вариант модернизации аппаратных средств. Компания Microsoft рекомендует использовать центральный процессор с частотой 533 МГц, объемом оперативной памяти 256 Мбайт и 4 Гбайт дискового пространства для хранения файлов операционной системы Windows Server 2003. Кроме этого, на жестких дисках для хранения данных должно быть достаточно места для хранения файлов базы данных Active Directory.
База данных Active Directory в операционной системе Windows Server 2003 немного больше по размеру аналогичной базы данных в Windows 2000, но не настолько, чтобы повлиять на расчеты свободного дискового пространства. Если на работающей системе осталось около 20 % свободного дискового пространства для хранения файлов Active Directory, стоит рассмотреть возможность установки жестких дисков большего объема, даже если модернизация не планируется.
Если в пределах сайта установлено несколько контроллеров домена и на контроллерах домена не выполняются важные приложения, модернизацию можно провести в рабочее время. В рабочее время не стоит отключать связующий сервер узла, единственный сервер глобального каталога и любой из контроллеров домена, которому назначена роль хозяина операций.
Возможно, самой интересной возможностью Active Directory в операционной системе Windows Server 2003 является возможность создавать транзитивные доверительные отношения на основе протокола Kerberos между двумя лесами. Для иллюстрации этой возможности в примерах этого раздела будет показана модернизация двух лесов Windows 2000, в которых домены совместно используют внешние доверительные отношения (рис. 9.23).
Лес БДомены в режиме Windows 2000 NativeЛес БДомены в режиме Windows 2000 NativeКонтроллер домена под управлением Windows 2000Контроллер домена под управлением Windows 2000Двустороннее транзитивное доверительное отношение между доменамиДвустороннее транзитивное доверительное отношение между доменамиКонтроллер ^ домена под '•управлением Windows 2000Контроллер ^ домена под '•управлением Windows 2000Лес А Домены в режиме Windows 2000 NativeЛес А Домены в режиме Windows 2000 NativeДвустороннеенетранзитивноевнешнееотношениедоверияДвустороннеенетранзитивноевнешнееотношениедоверияКонтроллер домена под управлением Windows 2000Контроллер домена под управлением Windows 2000Двустороннеетранзитивноедоверительноеотношение междудоменамиДвустороннеетранзитивноедоверительноеотношение междудоменамиКонтроллер домена под управлением Windows 2000Контроллер домена под управлением Windows 2000Файловый сервер и сервер печатиФайловый сервер и сервер печатиРабочая станцияРабочая станцияПользователь получает доступ по протоколу NTLM к файловому серверу и серверу печати с помощью внешнего доверительного отношенияПользователь получает доступ по протоколу NTLM к файловому серверу и серверу печати с помощью внешнего доверительного отношенияПользователь проходит аутентификацию с помощью локальных для домена регистрационных данныхПользователь проходит аутентификацию с помощью локальных для домена регистрационных данных
Лес БДомены в режиме Windows 2000 Native
Лес БДомены в режиме Windows 2000 Native
Контроллер домена под управлением Windows 2000
Контроллер домена под управлением Windows 2000
Двустороннее транзитивное доверительное отношение между доменами
Двустороннее транзитивное доверительное отношение между доменами
Контроллер ^ домена под '•
управлением Windows 2000
Контроллер ^ домена под '•
управлением Windows 2000
Лес А Домены в режиме Windows 2000 Native
Лес А Домены в режиме Windows 2000 Native
Двустороннеенетранзитивноевнешнееотношениедоверия
Двустороннеенетранзитивноевнешнееотношениедоверия
Контроллер домена под управлением Windows 2000
Контроллер домена под управлением Windows 2000
Двустороннеетранзитивноедоверительноеотношение междудоменами
Двустороннеетранзитивноедоверительноеотношение междудоменами
Контроллер домена под управлением Windows 2000
Контроллер домена под управлением Windows 2000
Файловый сервер и сервер печати
Файловый сервер и сервер печати
Рабочая станция
Рабочая станция
Пользователь получает доступ по протоколу NTLM к файловому серверу и серверу печати с помощью внешнего доверительного отношения
Пользователь получает доступ по протоколу NTLM к файловому серверу и серверу печати с помощью внешнего доверительного отношения
Пользователь проходит аутентификацию с помощью локальных для домена регистрационных данных
Пользователь проходит аутентификацию с помощью локальных для домена регистрационных данных
Рис. 9.23. Леса Windows 2000 с доменами, связанными внешними доверительными отношениями
На этой схеме пользователи двух доменов совместно используют ресурсы соответствующих доменов. Типичным примером такой структуры является внешнее соединение между производителем и торговой точкой. Еще одним примером является больница на территории университета, доктора которой являются сотрудниками обеих организаций и нуждаются в доступе к ресурсам основного домена университета.
Между доменом, на котором хранятся учетные записи пользователей, и доменом, на котором хранятся учетные записи серверов, установлено двустороннее внешнее доверительное отношение. Это позволяет имитировать классические доверительные отношения Windows NT, которые на самом деле являются двумя односторонними доверительными отношениями с аутентификацией по протоколу NTLM, а не по протоколу Kerberos (т.е. транзитивность не поддерживается). Именно поэтому домены доверяют непосредственно друг другу и не используют доверительные отношения между корневыми доменами.
При такой конфигурации модернизация доменов и лесов до Windows Server 2003 включает в себя следующие основные этапы.
Модернизация схемы и подготовка доменов к модернизации.
Модернизация контроллеров домена в корневых доменах и переход на функциональный уровень доменов Windows Server 2003.
Модернизация контроллеров домена в дочерних доменах и переход на функциональный уровень Windows Server 2003.
Переход на функциональный уровень лесов Windows Server 2003.
Замена внешнего доверительного отношения между дочерними доменами доверительным отношением к лесу между корневыми доменами.
Модернизация схемы
Перед модернизацией контроллеров домена Windows 2000 до Windows Server 2003 или перед добавлением контроллера домена под управлением Windows Server 2003 в домен Windows 2000 необходимо модернизировать схему Windows 2000. Операционная система Windows Server 2003 вносит около 400 изменений в схему, включая добавление новых классов и атрибутов, изменение индексирования и изменения атрибутов, публикуемых в глобальном каталоге. Последнее требует перестройки глобального каталога, который затем реплицируется на все серверы глобального каталога в пределах леса.
Кроме значительных изменений схемы, операционная система Windows Server 2003 требует нескольких изменений в доменах. Эти изменения обеспечивают соединения между лесами и позволяют отслеживать обновления доменов.
Утилита для выполнения обновлений схемы и доменов называется adprep. Утилита в сжатом виде хранится в каталоге \ 13 8 6 на установочном компакт-диске операционной системы Windows Server 2003.
Проще всего для установки утилиты adprep запустить команду winnt32 / checkupgradeonly с установочного компакт-диска Windows Server 2003. При этом утилита adprep будет распакована в каталог \WINNT\System3 2. Вместе с утилитой будут скопированы И файлов LDIF, от Schl4. Idf до Sch24 . Idf, в которых хранятся новые записи в схеме.
Номер в имени файла соответствует версии схемы. Операционная система Windows 2000 использует схему версии 13, поэтому имена файлов начинаются с Schl4. Idf. Приложение Exchange 2000 также вносит изменения в схему, но использует отдельный набор файлов LDIF (LDAP Data Interchange Format), который не меняет номера версии схемы.
Утилита adprep предоставляет два параметра, каждый из которых должен быть использован перед модернизацией контроллера домена Windows 2000 до Windows Server 2003 или до установки нового контроллера домена под управлением Windows Server 2003 в существующем домене Windows 2000.
adprep /forestprep. Этот параметр запускает модернизацию схемы. В этом случае вызывается другая утилита, schupgr, которой последовательно предоставляются файлы Sch##. Idf. Кроме этого, параметр / forestprep обновляет права доступа Active Directory и вносит изменения в параметры отображения для поддержки новых классов.
adprep /domainprep. Этот параметр добавляет в объект Domain новые атрибуты, которые используются для поддержки квот доверия. Кроме этого, в контейнер System добавляется новый контейнер для отслеживания обновлений домена.
Для обновления схемы на всех контроллерах домена должна быть установлена операционная система Windows 2000 SP2. Необходимы права администратора в корневом домене леса, а также членство в группе Schema Admins.
Команду adprep /forestprep запускайте на контроллере домена, которому назначена роль хозяина схемы (Schema Master). Этот сервер можно обнаружить с помощью командного сценария dumpfsmos, входящего в набор средств Resource Kit. Для этого введите команду dumpfsmos <имя_контроллера_домена>.
Команду adprep /domainprep следует запустить на хозяине инфраструктуры (Infrustruc- ture Master) в каждом домене. Для этого необходимы права администратора в пределах домена. В схему изменения не вносятся. Параметр /domainprep просто добавляет поддержку квот для доверительных отношений между лесами и добавляет новый контейнер в контейнер System для отслеживания обновлений.
Модернизация корневых доменов
Windows 2000
После распространения внесенных утилитой adprep изменений на все контроллеры домена в пределах леса можно начинать модернизацию контроллеров домена в корневых доменах. На рис. 9.24 показан результат модернизации. В отличие от модернизации контроллеров доменов Windows NT до Windows Server 2003, при модернизации систем Windows 2000 операционная система и служба каталогов модернизируются одновременно. Процедура модернизации может занять некоторое время, иногда до часа, в зависимости от производительности центрального процессора и необходимых преобразований системного реестра.
Можно просто повысить сервер под управлением Windows Server 2003 до контроллера домена, а не модернизировать существующие контроллеры домена. Если принято решение о таком методе модернизации, перед отключением контроллеров домена Windows 2000 необходимо передать все пять ролей хозяев операций новому контроллеру домена.
Сценарий dumpfsmos
Сценарий dumpfsmos передает утилите Ntdsutil следующий набор команд:
ntdsutil roles Connections "Connect to server %1" Quit
^ "Select Operation Target" "List roles for connected server"
^ Quit Quit Quit
На самом деле утилите Ntdsutil требуется только часть каждого слова для создания уникальной записи, поэтому сценарий можно сократить так:
Ntdsutil г с "со t s %1" q "sei о t" "lrfcs"qqq
Если принято решение о модернизации, желательно начинать с сервера, выполняющего роль PDC Emulator. Это необязательно, но PDC Emulator является принятым по умолчанию сервером для редактирования групповых политик, а также источником точного времени и главным обозревателем домена, поэтому с ним стоит разобраться в первую очередь.
Как только будет завершена модернизация всех контроллеров домена в корневом домене, смените функциональный уровень домена на уровень Windows Server 2003. Убедитесь в целостности установленных доверительных отношений с дочерними доменами. Проверьте возможность регистрации администраторов в корневом домене и сохранение привилегий администратора в дочерних доменах.
Лес Афункциональный уровень Windows 2000Лес Афункциональный уровень Windows 2000Лес БФункциональный уровень Windows 2000Лес БФункциональный уровень Windows 2000
Лес Афункциональный уровень Windows 2000
Лес Афункциональный уровень Windows 2000
Лес Б
Функциональный уровень Windows 2000
Лес Б
Функциональный уровень Windows 2000
Контроллер домена .NETКонтроллер домена .NETДомен в режиме Windows 2000 NativeДомен в режиме Windows 2000 NativeФункциональный уровень Windows Server 2003Функциональный уровень Windows Server 2003Контроллер домена под управлением Windows 2000Контроллер домена под управлением Windows 2000Двустороннее транзитивное доверительное отношение между доменамиДвустороннее транзитивное доверительное отношение между доменамиКонтроллер домена .NETКонтроллер домена .NETКонтроллер домена под управлением WindowsКонтроллер домена под управлением WindowsДомен в режиме Windows 2000 NativeДомен в режиме Windows 2000 NativeФункциональный уровень Windows Server 2003Функциональный уровень Windows Server 2003Двустороннее транзитивное доверительное отношение между доменамиДвустороннее транзитивное доверительное отношение между доменамиФайловый сервер и сервер печатиФайловый сервер и сервер печатиДвустороннеенетранзитивное внешнеедоверительное отношениеДвустороннеенетранзитивное внешнеедоверительное отношение44Рабочая станция пользователяРабочая станция пользователя
Контроллер домена .NET
Контроллер домена .NET
Домен в режиме Windows 2000 Native
Домен в режиме Windows 2000 Native
Функциональный уровень Windows Server 2003
Функциональный уровень Windows Server 2003
Контроллер домена под управлением Windows 2000
Контроллер домена под управлением Windows 2000
Двустороннее транзитивное доверительное отношение между доменами
Двустороннее транзитивное доверительное отношение между доменами
Контроллер домена .NET
Контроллер домена .NET
Контроллер домена под управлением Windows
Контроллер домена под управлением Windows
Домен в режиме Windows 2000 Native
Домен в режиме Windows 2000 Native
Функциональный уровень Windows Server 2003
Функциональный уровень Windows Server 2003
Двустороннее транзитивное доверительное отношение между доменами
Двустороннее транзитивное доверительное отношение между доменами
Файловый сервер и сервер печати
Файловый сервер и сервер печати
Двустороннеенетранзитивное внешнеедоверительное отношение
Двустороннеенетранзитивное внешнеедоверительное отношение
4
4
Рабочая станция пользователя
Рабочая станция пользователя
Рис. 9.24. Леса Windows 2000 после модернизации корневых доменов до Windows Server2003
Модернизация дочерних доменов
Теперь, когда завершена модернизация корневых доменов, можно начинать модернизацию дочерних доменов. Помните, что домен необходимо подготовить к модернизации с помощью команды adprep /domainprep до модернизации первого контроллера домена. На рис. 9.25 изображена окончательная конфигурация, когда функциональный уровень леса переведен на Windows Server 2003.
Как и в случае с корневым доменом, стоит начинать модернизацию с контроллера домена, выполняющего роль PDC Emulator. После завершения модернизации всех контроллеров домена Windows 2000 следует сменить функциональный уровень домена на уровень Windows Server 2003. После этого переключите функциональный уровень леса на Windows Server 2003.
На этом этапе можно создавать доверительные отношения между двумя лесами. После создания этого доверительного отношения можно удалить внешнее доверительное отношение между дочерними доменами. Убедитесь, что посредством доверительного отношения между лесами пользователи могут получать доступ к ресурсам во всех доменах.
Лес A функциональный уровень Windows Server 2003Лес A функциональный уровень Windows Server 2003Лес Б функциональный уровень Windows Server 2003Лес Б функциональный уровень Windows Server 2003функциональный уровень Windows Server 2003функциональный уровень Windows Server 2003Функциональный уровень Windows Server 2003Функциональный уровень Windows Server 200388Функциональный уровень Windows Server 2003Функциональный уровень Windows Server 2003Функциональный уровень Windows Server 2003Функциональный уровень Windows Server 2003Рабочая станция пользователяРабочая станция пользователяДвустороннее транзитивное доверительное отношение между доменамиДвустороннее транзитивное доверительное отношение между доменамиРис. 9.25. Последняя стадия модернизации Windows 2000, когда все контроллеры домена модернизированы до уровня Windows Server 2003Рис. 9.25. Последняя стадия модернизации Windows 2000, когда все контроллеры домена модернизированы до уровня Windows Server 2003Двустороннеетранзитивноедоверительноеотношение междулесамиДвустороннеетранзитивноедоверительноеотношение междулесамиДвустороннеетранзитивноедоверительноеотношение междудоменамиДвустороннеетранзитивноедоверительноеотношение междудоменамиФайловый сервер ^ и сервер печатиФайловый сервер ^ и сервер печати
Лес A функциональный уровень Windows Server 2003
Лес A функциональный уровень Windows Server 2003
Лес Б функциональный уровень Windows Server 2003
Лес Б функциональный уровень Windows Server 2003
функциональный уровень Windows Server 2003
функциональный уровень Windows Server 2003
Функциональный уровень Windows Server 2003
Функциональный уровень Windows Server 2003
8
8
Функциональный уровень Windows Server 2003
Функциональный уровень Windows Server 2003
Функциональный уровень Windows Server 2003
Функциональный уровень Windows Server 2003
Рабочая станция пользователя
Рабочая станция пользователя
Двустороннее транзитивное доверительное отношение между доменами
Двустороннее транзитивное доверительное отношение между доменами
Рис. 9.25. Последняя стадия модернизации Windows 2000, когда все контроллеры домена модернизированы до уровня Windows Server 2003
Рис. 9.25. Последняя стадия модернизации Windows 2000, когда все контроллеры домена модернизированы до уровня Windows Server 2003
Двустороннеетранзитивноедоверительноеотношение междулесами
Двустороннеетранзитивноедоверительноеотношение междулесами
Двустороннеетранзитивноедоверительноеотношение междудоменами
Двустороннеетранзитивноедоверительноеотношение междудоменами
Файловый сервер ^ и сервер печати
Файловый сервер ^ и сервер печати
Миграция доменов Windows NT и Windows 2000 в домены Windows Server 2003
Если непосредственная модернизация доменов Windows NT или Windows 2000 невозможна, можно создать новый домен Windows Server 2003 и переместить (мигрировать) в него пользователей, компьютеры и группы из существующих доменов. Компания Microsoft предоставляет несколько утилит для миграции в составе операционной системы. Самыми простыми инструментами являются сценарии для копирования участников системы безопасности между доменами. Перечислим эти сценарии.
Clonepr. Копирует учетные записи пользователей в указанный домен.
Clonegg. Копирует глобальные группы в указанный домен.
Clonelg. Копирует локальные группы в указанный домен.
Cloneggu. Копирует глобальные группы и пользователей в указанный домен.
Sidhist. Извлекает идентификатор безопасности пользователя или группы из одного домена и назначает его пользователю или группе в другом домене. В следующих разделах будет предоставлена дополнительная информация о службе истории идентификаторов безопасности (SID History).
При крупномасштабной миграции эти сценарии могут оказаться немного неудобными для использования. Сценарии предоставляют минимальные сведения о возникающих ошибках и
не предоставляют возможности тестирования. Для более сложных операций при миграции компания Microsoft предоставляет набор мастеров, который называется Active Directory Migration Tool (Набор средств для миграции в Active Directory), или ADMT.
Технология ADMT изначально была лицензирована у компании NetIQ. В составе операционной системы Windows 2000 предоставлялась версия, которая могла использоваться для миграции небольшого масштаба. Вторая версия ADMT, которая предоставляется в составе операционной системы Windows Server 2003, была усовершенствована и модифицирована для обеспечения миграции паролей, сохранения пользовательских профилей и упрощения повторного назначения прав доступа к файловым серверам и серверам печати, а также к рабочим станциям. Кроме этого, значительно улучшена и расширена документация.
Крупномасштабную миграцию можно реализовать исключительно средствами ADMTv2, но, кроме этого, можно обратить внимание на продукты от сторонних производителей, которые создают программы для миграции и объединения систем. Может оказаться, что небольшие затраты на приобретение подходящего программного средства с лихвой окупаются благодаря экономии сотен часов и усилий во время миграции. Перечислим наиболее известные программные продукты для решения этих задач.
Controlled Migration Suite от Aelita Software, www .aelita.com
FastLane Migrator от Quest Software (ранее — FastLane Technologies), www. quest. com
Domain Migration Administrator от NetIQ, www .netiq.com
bv-Admin for Windows 2000 Migration от Bindview, www. bindview. com
Все эти программы одинаково хорошо справляются с тонкостями процесса миграции. Основные отличия программ заключаются в методах создания отчетов, простоте использования и возможностях настройки. Кроме этого, производители предлагают дополнительные инструменты, которые упрощают управление доменами после завершения миграции, поэтому стоит рассмотреть возможность приобретения целого пакета инструментов, если предложение выглядит достаточно привлекательно.
Библиотека функций SID History
На рис.9.26 изображена схема классического домена под управлением WindowsNT. Пользователь является членом домена учетных записей. Пользователь подключается к системе со своей рабочей станции, которая является членом домена ресурсов. Пользователь получает доступ к серверу, являющемуся членом того же домена ресурсов, в который входит его рабочая станция.
Совместно используемые ресурсы на сервере защищены с помощью списка контроля доступа, в котором записан идентификатор безопасности группы, локальной для компьютера. Администратор домена ресурсов включает глобальную группу для домена учетных записей в локальную для компьютера группу на сервере. Пользователь является членом глобальной группы.
Вот что происходит при подключении пользователя к совместно используемому ресурсу. Сервер проверяет действительность аутентификационных данных пользователя с помощью классической сквозной аутентификации NTLM, после чего создает локальный поток обработки для пользователя и присоединяет маркер доступа. Маркер доступа состоит из идентификатора безопасности (SID) пользователя, идентификатора безопасности глобальной группы для домена учетных записей и идентификатора безопасности группы, локальной для компьютера. Согласно этому составному идентификатору безопасности в маркере доступа пользователю предоставляется доступ к совместно используемому ресурсу.
При создании новой учетной записи пользователя в домене Windows Server 2003 пользователю предоставляется возможность входа в систему, но при этом пользователь получает
полностью новый идентификатор безопасности с полностью новым набором членства в группах. Без дополнительных операций по поддержке миграции пользователь потеряет доступ ко всем ресурсам в оригинальном домене. Конечно, можно заново переопределить права доступа во всех каталогах оригинального домена для пользователей и групп нового домена, но на это потребуется слишком много времени и усилий. '
Глобальная группа SIDS-1-5-21-888-1055Глобальная группа SIDS-1-5-21-888-1055Главный домен Windows NT SIDS-1-5-21-888Главный домен Windows NT SIDS-1-5-21-888NT4^ PDCNT4^ PDCЛокальная группа на компьютере SID S-t-5-21-111-1003Локальная группа на компьютере SID S-t-5-21-111-1003Резервный контроллер домена под управлением Windows NT 4.0Резервный контроллер домена под управлением Windows NT 4.0Основной контроллердомена под управлениемWindows МТ 4.0Основной контроллердомена под управлениемWindows МТ 4.0Домен ресурсов SID S-1-5-21-444Домен ресурсов SID S-1-5-21-444SIDS-1-5-21-444-1009Член домена ресурсовSIDS-1-5-21-444-1009Член домена ресурсовSIDS-1-5-21-888-1027Член глобальной группыSIDS-1-5-21-888-1027Член глобальной группыФайловый сервер и сервер печатиЛокальный идентификатор безопасности S-1 -5-21 -111 -1001Идентификатор безопасности домена S-1 -21 -444-1292Файловый сервер и сервер печатиЛокальный идентификатор безопасности S-1 -5-21 -111 -1001Идентификатор безопасности домена S-1 -21 -444-1292
Глобальная группа SIDS-1-5-21-888-1055
Глобальная группа SIDS-1-5-21-888-1055
Главный домен Windows NT SIDS-1-5-21-888
Главный домен Windows NT SIDS-1-5-21-888
NT4
^ PDC
NT4
^ PDC
Локальная группа на компьютере SID S-t-5-21-111-1003
Локальная группа на компьютере SID S-t-5-21-111-1003
Резервный контроллер домена под управлением Windows NT 4.0
Резервный контроллер домена под управлением Windows NT 4.0
Основной контроллердомена под управлениемWindows МТ 4.0
Основной контроллердомена под управлениемWindows МТ 4.0
Домен ресурсов SID S-1-5-21-444
Домен ресурсов SID S-1-5-21-444
SIDS-1-5-21-444-1009
Член домена ресурсов
SIDS-1-5-21-444-1009
Член домена ресурсов
SIDS-1-5-21-888-1027
Член глобальной группы
SIDS-1-5-21-888-1027
Член глобальной группы
Файловый сервер и сервер печати
Локальный идентификатор безопасности S-1 -5-21 -111 -1001Идентификатор безопасности домена S-1 -21 -444-1292
Файловый сервер и сервер печати
Локальный идентификатор безопасности S-1 -5-21 -111 -1001Идентификатор безопасности домена S-1 -21 -444-1292
Рис. 9.26. Главный домен и домен ресурсов Windows NT, в которых показаны идентификаторы безопасности различных участников системы безопасности
Компания Microsoft предоставляет технологию, которая позволяет решить эту проблему. Эта технология лежит в основе всех утилит для облегчения миграции как от компании Microsoft, так и от других производителей. Это библиотека функций, которая называется SID History (что можно перевести как “история идентификаторов безопасности”). Иногда для обозначения этой библиотеки используется название SID History API.
Библиотека функций SID History позволяет создавать учетные записи для участников системы безопасности (пользователей, групп или компьютеров) в создаваемом домене Windows Server 2003 или Windows 2000. После этого в новые учетные записи можно добавить дополнительный атрибут, который называется SIDHistory и содержит идентификатор безопасности оригинального участника системы безопасности.
На рис. 9.27 показано, что происходит, когда от имени учетной записи пользователя, недавно созданной с помощью SID History API домена Windows Server 2003, предпринимается попытка получить доступ к ресурсам в оригинальном домене.
Дополнительное одностороннее нетранзитивное доверительное отношениеДополнительное одностороннее нетранзитивное доверительное отношениеРезервный контроллер домена под управлением Windows NT 4.0Резервный контроллер домена под управлением Windows NT 4.0Главный домен Windows NT SIDS-1-5-21-888Главный домен Windows NT SIDS-1-5-21-888Домен ресурсов NT4SIDS-1-5-21-444 PDCДомен ресурсов NT4SIDS-1-5-21-444 PDCОсновной контроллер домена под управлением Windows NT 4.0 Контроллер Глобальная группа / домена SlDSJ-5-21-888-105^ \Основной контроллер домена под управлением Windows NT 4.0 Контроллер Глобальная группа / домена SlDSJ-5-21-888-105^ \Контроллер доменаКонтроллер доменаДомен Windows Server 2003 SID S-1-5-21-3333Домен Windows Server 2003 SID S-1-5-21-3333Глобальная группа Локальный идентификатор безопасности S-1-5-21-3333-t030 SlDHistory: S-t-5-21-888-1055Глобальная группа Локальный идентификатор безопасности S-1-5-21-3333-t030 SlDHistory: S-t-5-21-888-1055\\//локальная группа компьютера SIDS-1-5-21-111-1OO3локальная группа компьютера SIDS-1-5-21-111-1OO3Локальный идентификатор безопасности S-1-5-21-3333-1035 SlDHistory: S-1-5-21-888-1O27Локальный идентификатор безопасности S-1-5-21-3333-1035 SlDHistory: S-1-5-21-888-1O27Локальный идентификатор безопасностиS-1-5-21-3333-1034SlDHistory: S-1-5-21 -444-1009Локальный идентификатор безопасностиS-1-5-21-3333-1034SlDHistory: S-1-5-21 -444-1009
Дополнительное одностороннее нетранзитивное доверительное отношение
Дополнительное одностороннее нетранзитивное доверительное отношение
Резервный контроллер домена под управлением Windows NT 4.0
Резервный контроллер домена под управлением Windows NT 4.0
Главный домен Windows NT SIDS-1-5-21-888
Главный домен Windows NT SIDS-1-5-21-888
Домен ресурсов NT4
SIDS-1-5-21-444 PDC
Домен ресурсов NT4
SIDS-1-5-21-444 PDC
Основной контроллер домена под управлением Windows NT 4.0 Контроллер Глобальная группа / домена SlDSJ-5-21-888-105^ \
Основной контроллер домена под управлением Windows NT 4.0 Контроллер Глобальная группа / домена SlDSJ-5-21-888-105^ \
Контроллер домена
Контроллер домена
Домен Windows Server 2003 SID S-1-5-21-3333
Домен Windows Server 2003 SID S-1-5-21-3333
Глобальная группа Локальный идентификатор безопасности S-1-5-21-3333-t030 SlDHistory: S-t-5-21-888-1055
Глобальная группа Локальный идентификатор безопасности S-1-5-21-3333-t030 SlDHistory: S-t-5-21-888-1055
\
\
/
/
локальная группа компьютера SIDS-1-5-21-111-1OO3
локальная группа компьютера SIDS-1-5-21-111-1OO3
Локальный идентификатор безопасности S-1-5-21-3333-1035 SlDHistory: S-1-5-21-888-1O27
Локальный идентификатор безопасности S-1-5-21-3333-1035 SlDHistory: S-1-5-21-888-1O27
Локальный идентификатор безопасности
S-1-5-21-3333-1034
SlDHistory: S-1-5-21 -444-1009
Локальный идентификатор безопасности
S-1-5-21-3333-1034
SlDHistory: S-1-5-21 -444-1009
Файловый сервер и сервер печатиФайловый сервер и сервер печати
Файловый сервер и сервер печати
Файловый сервер и сервер печати
Локальный идентификатор безопасности 8-1-5-21-111-1001 Идентификатор безопасности домена 8-1-21-444-1292
Puc. 9.27. Участники системы безопасности после миграции операционной системы Windows NT в Windows Server2003
Пользователь регистрируется в домене Windows Server 2003 с помощью новой учетной записи, которая была скопирована в базу данных Active Directory из оригинального домена. Пользователь пытается получить доступ к ресурсу на сервере оригинального домена. Сервер выполняет аутентификацию пользователя с помощью стандартного протокола сквозной аутентификации NTLM. Контроллер домена Windows Server 2003 предоставляет серверу набор идентификаторов безопасности. В набор входят следующие идентификаторы.
Идентификатор безопасности пользователя из домена Windows Server 2003
Идентификатор безопасности пользователя из оригинального домена, полученный из атрибута SlDHistory, который хранится в объекте учетной записи пользователя в базе данных-Active Directory
Идентификатор безопасности глобальной группы домена Windows Server 2003, в которую входит пользователь
Оригинальный идентификатор безопасности глобальной группы, полученный из атрибут та SlDHistory объекта глобальной группы в Active Directory
Созданный в результате этой транзакции маркер локального доступа содержит все эти идентификаторы безопасности, а также идентификатор безопасности локальной для компьютера группы, в которую входила глобальная группа в оригинальном домене. Маркер локального доступа предоставляет пользователю право получать доступ к ресурсам даже при регистрации в другом домене.
Миграция учетных записей компьютеров
Учетные записи компьютеров и серверов в домене ресурсов (см. рис. 9.27) приводят к дополнительным трудностям в процессе миграции. Рабочая станция входит в домен ресурсов, а пользователь входит в доверенный домен учетных записей. Для миграции домен ресурсов должен доверять домену Windows Server 2003, иначе пользователь не сможет пройти аутентификацию в удаленном домене с локальной рабочей станции. Классические доверительные отношения в системе Windows NT нетранзитивны.
Надежным решением является перемещение рабочей станции в новый домен. Рабочую станцию можно вручную вывести из оригинального домена и присоединить к новому домену, но ADMT и инструменты миграции от сторонних производителей предоставляют способы автоматизации процесса миграции. В этом процессе локальные профили пользователей и разрешения на доступ к локальным файлам NTFS передаются учетной записи пользователя в удаленном домене.
ADMT предоставляет возможность копирования установленных элементов системы безопасности, что упрощает повторное назначение прав доступа рабочей станции или серверу. Это достигается с помощью замены устаревших идентификаторов безопасности новыми или с помощью SID History для обеих учетных записей (сервера и рабочей станции). Вызов возможности копирования установленных элементов системы безопасности является частью процесса миграции компьютеров. Доступ к оригинальному профилю пользователя поддерживается на протяжении всего процесса (рис. 9.28).
Рис. 9.28. Окно Translate Objects мастера миграции компьютеров
Кроме этого, мастер миграции компьютеров предоставляет возможность переименования компьютеров в процессе миграции, особенно удобную, когда возникает необходимость добавить префикс, указывающий на то, что компьютер является членом нового домена.
Мастер миграции компьютеров вносит изменения в настройки локальных рабочих станций и серверов, после чего перезагружает компьютер. Для этого учетная запись домена Windows Server 2003, от имени которой запущена утилита ADMT, должна обладать привилегиями администратора на рабочих станциях. Нельзя просто внести эту учетную запись в группу Domain Admins в домене WindowsNT или Windows 2000, поскольку в глобальные группы не могут входить члены других доменов. Самым простым решением является использование
учетной записи из исходного домена, которой были предоставлены достаточные права для запуска ADMT в домене Windows Server 2003.
Кроме этого, можно запустить копирование установленных элементов системы безопасности в качестве отдельного процесса после миграции, что позволит упорядочить список прав доступа на рабочих станциях и серверах, а также отказаться от использования устаревших учетных записей. Это необходимо сделать до отключения домена Windows NT, чтобы в списках контроля доступа не появились пустые идентификаторы безопасности.
ADMT можно использовать для миграции рабочих станций и серверов на платформе IA64, но перезагрузка компьютера на платформе IA64 по команде с компьютера на платформе IA32 невозможна. Необходимо вручную перезагрузить компьютеры на платформе IA64.
Миграция учетных записей групп
Миграция учетных записей пользователей в домен Windows Server 2003 является только половиной дела для сохранения возможности доступа пользователей к ресурсам оригинального домена. Другой неотъемлемой составляющей являются локальные и глобальные группы, в которые входит пользователь.
На этапе планирования миграции пользователей начните с поиска закрытых объединений пользователей и групп. Например, может потребоваться миграция пользователя Amcbeal, который входит в группу Legal. Но пользователь Jcage также входит в эту группу, поэтому, возможно, придется выполнить миграцию и этого пользователя. Но пользователь Jcage входит в группу General-Partners, поэтому придется выполнить миграцию и этой группы, но в нее входит пользователь R f i sh.
Определение взаимосвязанных пользователей и групп в домене может оказаться достаточно сложным, но, к счастью, ADMT предоставляет возможность добавлять перенесенных пользователей в группы, если миграция этих групп была проведена ранее.
Подготовка к миграции учетных записей
Несложно догадаться, что возможность копирования идентификатора безопасности пользователя из одного домена и помещение этого идентификатора в учетную запись в другом домене требует значительных привилегий. Библиотека SID History API предоставляет длинный список предварительных требований. Если принимается решение о миграции паролей одновременно с учетными записями пользователей, потребуется еще больше операций по настройке, чем при простой миграции учетных записей пользователей. Рассмотрим требования для миграции учетных записей между лесами (в следующем разделе рассматривается последовательность действий по миграции, включая миграцию паролей).
Функциональный уровень выбранного для миграции домена. Домен, в который осуществляется миграция, должен работать на функциональном уровне Windows 2000 Native или Windows Server 2003. Это необходимо, поскольку SID History не может храниться в базе данных SAM, поэтому все резервные контроллеры домена должны быть отключены от сети.
Расположение исходных доменов. Если выполняется миграция из домена Windows 2000, исходный домен не может находиться в пределах того же леса, что и выбранный для миграции домен.
Пакеты обновлений. На контроллере исходного домена Windows NT 4.0 должна быть установлена служба SPGA. На контроллере исходного домена Windows 2000 может быть установлена любая версия пакета обновлений (Service Pack).
Доверительные отношения. Исходный домен должен доверять домену, в который осуществляется миграция. Это позволяет обеспечить подходящий контекст безопасности для агента ADMT.
Привилегии администратора. Учетная запись, от имени которой выполняется миграция, должна обладать неограниченными привилегиями администратора в исходном и конечном доменах. Разместите учетную запись домена Windows Server 2003 в группе Administrators (Администраторы) исходного домена.
Доверительные отношения с доменами ресурсов. При миграции учетных записей компьютеров и серверов из домена ресурсов для этого домена ресурсов должны быть установлены доверительные отношения с доменом Windows Server 2003.
Группа отслеживания миграции. Исходный домен должен содержать локальную группу, которая называется Domain$$$, где Domain является именем NetBIOS данного домена, например NT-DOM$$$. В этой группе не может быть членов. Группа используется для проверки имени исходного домена. ADMT автоматически создает такую группу, если она не существует. Если группа создается администратором, стоит обратить внимание, что это должна быть локальная для домена группа (Domain Local), а не глобальная группа.
Анонимный доступ. Добавьте группы Everyone и Anonymous Users в группу Pre Windows 2000 Compatible Access.
Соединения по сети. Отключите все связи между исходным и конечным контроллерами доменов; это касается смонтированных дисков и принтеров. Агент ADMT должен иметь эксклюзивный контроль над соединением между компьютерами.
Доступ к базе данных SAM по протоколу TCP/IP. Обычно к базе данных SAM можно получить доступ только с помощью протокола RPC. Для выполнения миграции агент ADMT требует доступа по протоколу TCP/IP. Для этого придется внести изменения в системный реестр в исходном домене. ADMT автоматически внесет необходимые изменения, но есть запись в реестре, которую следует изменить вручную:
Раздел: HKLM\System\CurrentControlSet\Control\Lsa
Запись: TcpipClientSupport
Значение: 1 (REG_DWORD)
Аудит. Аудит управления учетными записями должен быть включен в обоих доменах. Это позволяет обеспечить ведение протокола доступа к SID History API. Дополнительную информацию можно прочесть во врезке “Аудит управления учетных записей”.
Административные общие ресурсы. Совместно используемые ресурсы, название которых заканчивается символом $, должны быть доступны и на исходном, и на конечном контроллерах доменов. Для проверки доступности общих ресурсов можно воспользоваться командой net share.
Отсутствие пустых паролей. Для учетной записи администратора в исходном домене не может использоваться пустой пароль.
Миграция паролей
ADMT может сохранять пароли, установив агент миграции паролей на исходном контроллере домена. Этот агент обрабатывает запросы сохранения паролей, поступающие от конечного контроллера домена. С целью обеспечения безопасности исходный контроллер домена должен аутентифицировать целевой контроллер домена в обход стандартного механизма аутентификации NTLM. Для этого используется ключ миграции паролей.
Ключ миграции паролей создается на конечном контроллере домена с помощью версии утилиты ADMT с интерфейсом командной строки. После этого с помощью гибкого диска
ключ переносится на исходный контроллер домена, на котором запускается мастер миграции паролей с установочного компакт-диска Windows Server 2003. Мастер проверяет наличие ключа миграции паролей до установки и инициализации агента миграции на исходном контроллере домена.
Аудит управления учетных записей
Перед использованием SID History API необходимо включить аудит в обоих доменах.
В операционных системах Windows Server 2003 и Windows 2000 аудит учетных записей управляется групповой политикой Audit Account Management в политике Default Domain Controllers. Эта политика хранится в разделе Computer ConfigurationMwindows SettingsMSecurity SettingsMLocal Policies'?’Audit Policy. He забывайте включать политику регистрации успешных и неудачных попыток доступа.
В операционной системе Windows NT аудит учетных записей управляется службой User Manager (Диспетчер пользователей) для домена. Выберите из меню Policies (Политики) команду Audit (Аудит). Включите аудит успешных и неудачных попыток для событий User and Group Management (Управление пользователями и группами).
Агент миграции паролей на исходном контроллере домена требует доступа к учетным записям пользователей в базе данных Active Directory на контроллере домена, в который осуществляется миграция." Это требует поддержки доступа к Active Directory с помощью нулевого сеанса, поскольку исходный контроллер домена работает под управлением Windows NT и не в состоянии проходить аутентификацию по протоколу Kerberos. В процессе подготовки миграции необходимо настроить политики контроллера домена на предоставление доступа с помощью нулевого сеанса.
Выполните процедуру 9.4 до запуска ADMT, если необходимо при миграции учетных записей пользователей одновременно перенести существующие пароли.
Процедура 9.4. Настройка агента миграции паролей
6. Мастер миграции паролей найдет файл пароля на гибком диске и запросит пароль для открытия файла. После этого мастер завершит установку утилиты миграции на контроллере исходного домена.
На этом этапе агент миграции паролей установлен на контроллере исходного домена, но он не будет отвечать на запросы по предоставлению паролей до тех пор, пока не будет активизирована запись системного реестра, которая создается мастером установки:
Раздел:HKLM\System\CurrentControlSet\Control\Lsa
Запись: AllowPasswordExport
Значение: о (reg_dword)
Установите для записи AllowPasswordExport значение 1. После этого можно приступать к миграции паролей.
Миграция учетных записей пользователей и групп
После установки и правильной настройки агента миграции паролей на исходном контроллере домена и удовлетворения требований к миграции учетных записей можно запускать тестовую миграцию с помощью агента ADMT, что позволит убедиться в правильности работы перенесенных учетных записей.
В описанном в процедуре 9.5 примере для миграции групп и пользователей из домена Windows NT в домен Windows Server 2003 используется мастер миграции учетных записей групп утилиты ADMT. Для миграции проще выбрать одну группу, чем выбирать отдельных пользователей из длинного списка. Другие администраторы могут иметь другую точку зрения. Но конечный результат выглядит одинаково.
Процедура 9.5. Миграция пользователей и групп с помощью ADMT
Запустите утилиту ADMT из меню Administrative Tools (Администрирование).
Щелкните правой кнопкой мыши на вершине дерева и выберите из контекстного меню команду Group Account Migration (Миграция учетных записей групп). Запустится мастер миграции учетных записей групп (Group Account Migration Wizard).
Щелкните на кнопке Next (Далее). Откроется окно Test or Make Changes (Проверка или внесение изменений). На этом этапе"необходимо только протестировать миграцию.
Щелкните на кнопке Next (Далее). В открывшемся окне Domain Select (Выбор домена) выберите из списка исходный и конечный домены. Если в списке отсутствуют нужные домены, проблема заключается в работе служб DNS и WINS.
Щелкните на кнопке Next (Далее). В открывшемся окне Group Selection (Выбор группы) щелкните на кнопке Add (Добавить), чтобы открыть стандартное окно выбора объектов. Выберите группы, миграция которых будет осуществлена из исходного домена. Миграция стандартных встроенных групп невозможна.
Щелкните на кнопке Next (Далее). Откроется окно Organizational Unit selection (Выбор организационной единицы). Воспользуйтесь браузером Target OU (Конечная организационная единица) для выбора организационной единицы, в которую будет осуществлена миграция групп.
Щелкните на кнопке Next (Далее). Откроется окно Group Options (Параметры групп), которое показано на рис. 9.29. Установите все флажки в этом окне, кроме Update Previously Migrated Objects (Обновлять перемещенные ранее объекты).
Щелкните на кнопке Next (Далее). Мастер сообщит, что в исходном домене отсутствует локальная группа TARGET$ $ $, и предложит ее создать.
Щелкните на кнопке Yes (Да). Мастер сообщит об отсутствии записи поддержки TCP/IP в системном реестре исходного домена и предложит создать необходимую запись.
Щелкните на кнопке Yes (Да). Мастер выдаст сообщение о необходимости перезагрузки исходного контроллера домена для вступлений в силу внесенных изменений. Это необходимо для обновления системного реестра.
Рмс. 929. Окно Group Options (Параметры групп) мастера миграции групп
Щелкните на кнопке Yes (Да). Пока исходный контроллер домена выполняет перезагруз1 ку, мастер продолжает работу. Откроется окно User Accounts (Учетные записи пользователей). Введите регистрационные данные учетной записи администратора в исходном домене. Подождите, пока перезагрузится исходный контроллер домена.*
Щелкните на кнопке Next (Далее). Откроется окно Naming Conflicts (Конфликты имен), показанное на рис. 9.30. Выберите вариант решения конфликтной ситуации, возникающей, когда в конечном домене уже существует аналогичное имя пользователя или группы. Самым безопасным вариантом является Ignore Conflicting Accounts And Don't Migrate (Игнорировать конфликтующие учетные записи и не выполнять миграцию).
Щелкните на кнопке Next (Далее). Откроется окно Group Member Password Options (Параметры паролей членов групп). Для пользователей можно создать новые пароли, а можно перенести существующие пароли. Выберите переключатель Migrate Passwords (Мигрировать пароли) и укажите исходный контроллер домена. Если на исходном контроллере домена не был установлен агент миграции паролей, будет выдано несколько сообщений об ошибке.
Щелкните на кнопке Next (Далее). Откроется окно Group Member Transition Options (Параметры перемещения членов групп). Можно выбрать отключение исходных учетных записей и включение мигрированных учетных записей, но безопаснее оставить оба набора учетных записей на случай, если что-то произойдет с контроллером домена Windows Server 2003. Можно указать интервал, после которого исходные учетные записи будут отключены автоматически.
Щелкните на кнопке Next (Далее). Откроется окно со списком выбранных параметров.
Щелкните на кнопке Finish (Готово). Мастер миграции групп выполнит тестовую миграцию и выдаст результат каждой операции. Эта информация сохраняется в локальной базе данных Jet для последующего просмотра.
Рис. 930. Окно Naming Conflict (Конфликты имен) мастера миграции групп
Если ADMT сталкивается с ошибками при тестовой миграции, ошибки-выдаются в окне текущего состояния вместе с фрагментами журнала миграции. Если ошибки отсутствуют, можно начинать полноценную процедуру миграции, воспользовавшись той же последовательностью действий.
После завершения действительной миграции проверьте следующие параметры системы.
Учетные записи пользователей и групп должны находиться в выбранной организационной единице.
■ Списки членов групп соответствуют реальным пользователям.
Пользователи могут регистрироваться в домене Windows Server 2003, используя свои - оригинальные пароли.
Пользователи могут регистрироваться в домене Windows Server 2003 и получать доступ к ' совместно используемым каталогам и принтерам на серверах Windows NT и Windows 2000 в пределах исходного домена.
Пользователи получили оригинальные профили с доступом ко всем совместно используемым ресурсам.
На полную миграцию пользователей, групп и компьютеров может потребоваться длительное время. После того как процедур» будет полностью проведена и исходный домен уже будет не нужен, выделите половину рабочего дня для запуска мастера трансляции безопасности и удаления старых учетных записей с рабочих станций и серверов. Это позволит избежать существования набора идентификаторов безопасности, которые невозможно преобразовать в дружественные имена после отключения контроллеров исходного домена.
Кроме этого, необходимо очистить атрибуты SIDHistory из учетных записей участников системы безопасности в базе данных Active Directory. Это позволяет увеличить производительность и снизить сложность назначения прав доступа.
Дополнительные операции в домене
В этом разделе рассматривается несколько дополнительных операций с контроллерами домена.
Понижение контроллера домена, включая понижение последнего контроллера домена
Переименование контроллера домена
Переименование домена
Понижение контроллера домена
В отличие от основных и резервных контроллеров домена Windows NT, контроллеры доменов Windows Server 2003 и Windows 2000 могут быть понижены до обычного сервера. При понижении удаляются службы, связанные с аутентификацией пользователей и передачей групповых политик, но способность поддерживать работу приложений и имя сервера сохраняются.
Контроллер домена должен иметь возможность связи с партнерами по репликации. В противном случае контроллер домена откажется выполнять понижение. Если отключить сервер от сети и после этого попытаться понизить контроллер домена, он также откажется выполнять понижение. В такой ситуации приходится полностью переустанавливать операционную систему Windows Server 2003. Кроме этого, если остается доступен домен, с помощью утилиты Ntdsutil необходимо выполнить очистку метаданных. Это необходимо для удаления имени сервера из базы данных Active Directory. В главе 10, “Обслуживание Active Directory", приводится дополнительная информация по очистке базы данных.
Рассмотрим список связанных с доменом служб, которые могут работать на контроллере домена.
Связующий сервер репликации (Replication bridgehead). Перед понижением связующего сервера необходимо убедиться в наличии другого сервера, который будет обеспечивать межсайтовую репликацию. Генератор межсайтовой топологии (ISTG) отвечает за определение связующего сервера. Если отключить генератор межсайтовой топологии, остальные серверы определят его отсутствие примерно через час, после чего начнутся выборы нового генератора межсайтовой топологии. Дополнительная информация о процедуре выборов генератора межсайтовой топологии приводится в главе 7, “Управление репликацией Active Directory”. Для определения ролей серверов можно воспользоваться утилитой Replication Monitor, Replmon.
Роли хозяев операций (FSMO). Перед понижением контроллера домена, который является хозяином операции, необходимо передать роль другому серверу. Для определения роли сервера можно воспользоваться утилитой Replmon.
Глобальный каталог. Перед понижением сервера глобального каталога убедитесь, что в пределах сайта существует еще один сервер глобального каталога. Если сайт останется без сервера глобального каталога, клиентам придется использовать внешнее соединение, что отрицательно скажется на производительности. Для обнаружения серверов глобального каталога в пределах леса можно воспользоваться утилитой Replmon.
Контексты именования приложений. Если удалить последний контроллер домена, придется решать, что делать с контекстами именования Application, в которых хранятся записи DNS. Если интегрированные в Active Directory зоны DNS больше не нужны, можно удалить контекст именования вместе с доменом. Если необходимо сохранить содержимое зон DNS, придется создать новый сервер DNS и сделать его основным сервером для хранения зон.
DHCP. Входящие в домен DHCP-серверы под управлением операционных систем Windows 2000 и Windows Server 2003 для определения своего статуса авторизации использу-
ют Active Directory. При понижении всех контроллеров домена сервер все еще будет показывать статус Authorized и раздавать адреса клиентам. Если сервер должен прекратить работу, придется вручную отменить авторизацию или полностью остановить службу.
Для понижения контроллера домена воспользуйтесь утилитой Dcpromo. Утилита обнаружит присутствие Active Directory и предложит понизить контроллер домена до сервера. Если это последний сервер в домене, установите соответствующий флажок. В таком случае мастер выполнит дополнительные действия по очистке последних записей домена из системного реестра и сделает сервер членом рабочей группы.
Переименование доменов
В операционной системе Windows Server 2003 поддерживается реструктуризация леса с помощью переименования и изменения иерархии доменов. Для этого необходимо работать на функциональном уровне Windows Server 2003. Чтобы переименовать домен, необходимо воспользоваться утилитой rendom. По умолчанию эта утилита не устанавливается. Утилиту можно найти на установочном компакт-диске Windows Server 2003 в каталоге \Valueadd\ Msft\Mgmt\Rendom.
Утилиту rendom нельзя использовать для выделения домена в отдельный лес. Также не поддерживается слияние домена с существующим лесом, поэтому нельзя считать, что компания Microsoft выполнила все обещания, данные перед выпуском этой версии операционной системы. Но и этого достаточно, чтобы заметить движение в сторону упрощения внутренней реструктуризаци и.
Переименование контроллеров домена
Если функциональный уровень домена установлен в Windows Server 2003, контроллер домена можно переименовать с помощью нового параметра команды netdom, которая предоставляется в составе пакета Support Tools. Существует два варианта переименования.
Переименование с использованием нового имени
Для этого необходимо воспользоваться командой netdom computername. Команда позволяет добавить новое имя, сделать это имя основным и удалить оригинальное имя. Последовательность действий рассматривается в процедуре 9.6.
Процедура 9.6. Переименование контроллера домена
с помощью команды netdom computername
Введите следующую команду в приглашении командной строки на консоли контроллера домена, который необходимо переименовать (введите полностью определенное имя DNS, а не просто “плоское” имя): netdom computername <старое_имя> /add:<новое_имя>'
Убедитесь, что в службе DNS зарегистрировано новое имя.
Введите следующую команду для назначения нового имени основным именем сервера: netdom computername <старое_имя> /makeprimary:<новое_имя>
Перезагрузите сервер для вступления в силу внесенных изменений.
После перезагрузки вернитесь в режим командной строки и введите следующую команду для удаления старого имени:
netdom computername <новое_имя> /remove:<старое_имя>
Убедитесь, что сервер имеет только одно имя. Для этого воспользуйтесь следующей командой:
netdom computername <новое_имя> /enumerate
На этом этапе в службе DNS и в окне свойств сервера будет указано только новое имя.
Переименование с замещением основного имени
В этом случае для замены основного имени контроллера домена используется единственная команда netdom renamecomputer. Кроме этого, с ее помощью можно перезагрузить контроллер домена после задержки, заданной в командной строке. После перезагрузки будет использоваться новое имя. Команда выглядит следующим образом: netdom renamecomputer <старое_имя> /newname:<новое_имя> /reb: 1
После перезагрузки сервер зарегистрирует новое имя в службе DNS. Это имя будет использоваться в качестве основного в Active Directory.
В следующей главе
На этом развертывание Active Directory в пределах предприятия можно считать завершенным. В следующей главе будут рассмотрены проблемы, которые возникают в процессе использования Active Directory. После этого мы на некоторое время оставим тему Active Directory и рассмотрим развертывание файловых серверов и серверов печати, обратив особое внимание на обеспечение безопасности и надежности.
то
Обслуживание Active Directory
Д
ля обеспечения нормальной работы Active Directory использует различные службы и функции операционной системы. Если одна из этих служб поддержки откажет, можно ожидать необычного или ошибочного поведения Active Directory. В этой главе рассматриваются следующие сценарии отказа (и предлагаются приемлемые варианты решения).
Выход из строя сервера службы DNS и влияние этого события на клиентов и контроллеры домена.
Выход из строя контроллера домена, включая выход из строя сервера глобального каталога и серверов, выполняющих роли хозяев операций (FSMO).
Выход из строя ключевых компонентов репликации, включая связующие серверы, генераторы межсайтовой топологии (ISTG) и внешние соединения.
Выход из строя или повреждение базы данных Active Directory, включая методы резервного копирования и восстановления содержимого базы данных.
Обслуживание Active Directory, включая перемещение файлов с расширениями . ese на другой носитель, дефрагментацию базы данных Active Directory и настройку параметров конфигурации Active Directory.
К концу этой главы мы расскажем об основах предпочтительных методов, которые следует использовать как при планировании восстановления Active Directory, так и при ежедневном обслуживании.
Новые возможности операционной системы Windows Server 2003
Единственной новой возможностью операционной системы Windows Server, оказывающей влияние на отказы и восстановление Active Directory, является способность контроллеров домена, не являющихся серверами глобального каталога, кэшировать списки членов универсальных групп. В глобальном каталоге содержатся списки членов универсальных групп, и без этой информации контроллер домена не позволяет пользователям проходить аутентифи-
кацию в домене. Обычно нарушение связи с серверами глобального каталога, например, при обрыве линии Т1, делает невозможной регистрацию пользователей в домене. Кэширование списка членов универсальных групп на стандартных контроллерах домена позволяет сохранить доступ к домену даже при отказе серверов глобального каталога.
Выход из строя DNS-сервера
Отказ DNS-сервера оказывает влияние на несколько аспектов работы Active Directory. Важнее всего то, что контроллер домена должен иметь возможность преобразования имен узлов и записей ресурсов SRV для связи и репликации с другими контроллерами доменов. Если используемый DNS-сервер выйдет из строя, контроллер домена не сможет длительное время предоставлять полный набор своих функциональных возможностей.
Проектировать инфраструктуру DNS следует таким образом, чтобы отказ единственного DNS-сервера не приводил к перерывам в обслуживании. Всегда стоит создавать как минимум два авторитетных для зоны DNS-сервера. Клиенты должны использовать оба сервера, один в качестве первичного, а второй — в качестве вторичного. Клиенты Windows обращаются к вто-. ричному DNS-серверу при отсутствии ответа от первичного сервера.
Эффект острова
Если заставить контроллер домена, поддерживающий работу службы DNS для предоставления интегрированной зоны, использовать собственную службу DNS для преобразования имен, система может пасть жертвой ошибки 22, которая в компании Microsoft называется эффектом острова (island effect).
При использовании зоны DNS, интегрированной в Active Directory, контроллер домена обновляет записи DNS с использованием механизма репликации. Контроллер домена обнаруживает партнеров по репликации с помощью преобразования имен DNS. Если IP-адрес изменился, контроллер домена не может найти партнера по репликации и обновить зону DNS, поскольку не может найти партнера по репликации.
Во избежание подобных ситуаций необходимо настроить свойства протокола TCP/IP для контроллера домена таким образом, чтобы основным DNS-сервером являлся другой контроллер домена. В качестве вторичного сервера DNS контроллеру домена можно указать самого себя. Предполагается, что вторичный DNS-сервер будет использоваться только в короткие периоды перебоев в связи.
Влияние отказа сервера DNS на клиентов под управлением операционной системы Windows
Без службы DNS клиенты Active Directory не в состоянии находить записи SRV, необходимые для обнаружения контроллеров домена. Без этих записей клиенты не могут проходить аутентификацию и отправлять запросы LDAP.
Сразу после потери доступа к серверу DNS клиент продолжит работать, используя кэшированные записи DNS. Запись SOA (Start of Authority) для домена DNS определяет принятое по умолчанию время жизни записей DNS, выданных сервером преобразования имен, хранящим зону. По умолчанию в DNS-серверах под управлением операционной системы Windows используется время жизни записей, равное 1 часу (3600 секунд).
По окончании термина жизни записей SRV и при отсутствии доступа к DNS-серверу клиенты перестанут находить контроллеры домена. Это приведет к невозможности обновить
билеты сеансов для доступа по протоколу Kerberos, поэтому соединение с обычными серверами также окажется невозможным.
При планировании инфраструктуры DNS стоит всегда создавать резервный DNS-сервер в каждом офисе. Это может быть стандартный вторичный DNS-сервер или контроллер домена, на котором будет храниться зона, интегрированная в Active Directory.
Выход из строя контроллера домена
При отказе контроллера домена служба Kerberos, работающая на клиенте, обнаружит отказ по истечении времени жизни билета безопасности Kerberos, когда окажется, что этот билет невозможно обновить. Как только клиент обнаруживает, что регистрационный сервер не отвечает, он запрашивает у DNS-сервера альтернативный контроллер домена. Альтернативный контроллер домена используется для повторной аутентификации.
Если отказавший контроллер домена является единственным контроллером домена в пределах сайта, клиенты попытаются аутентифицироваться повторно через внешнее соединение. Это замедляет процедуру аутентификации в зависимости от пропускной способности внешнего соединения. В то время, пока локальный контроллер домена остается недоступным, ответы на запросы LDAP, например, для поиска принтера или использования Outlook в среде Exchange 2000 потребуют большего времени ожидания из-за задержек при передаче через внешнее соединение.
Если нет других контроллеров домена для обеспечения повторной аутентификации, билеты Kerberos, выданные клиенту, окончательно устареют и клиент потеряет доступ к обычным серверам. Если клиент завершит сеанс работы, повторная регистрация будет выполнена с использованием кэшированных регистрационных данных, но этого недостаточно для возобновления доступа к серверам.
Важно помнить, что при отсутствии локальных контроллеров домена отказ внешнего соединения может привести к невозможности доступа к локальным серверам. Как вариант решения можно предложить создание резервного внешнего соединения, например линии ISDN, которое включается только при отказе основного соединения. Или можно установить локальный контроллер домена. Как будет сказано в следующем разделе, контроллер домена должен поддерживать работу сервера глобального каталога или должен быть настроен на кэширование записей глобального каталога.
Регистрация без доступа к глобальному каталогу
В обычных условиях при невозможности доступа к серверу глобального каталога пользователи не могут выполнять вход в домен. Это связано с тем, что в глобальном каталоге хранятся списки членов универсальных групп.
Кроме этого, при аутентификации пользователей с помощью основного имени пользователя (user@company. com) глобальный каталог используется для “анализа” составляющих основного имени пользователя. Операционная система Windows ХР кэширует составляющие имени после первой регистрации, но операционная система Windows 2000 нуждается в доступе к глобальному каталогу при каждой регистрации с помощью основного имени пользователя.
В операционной системе Windows Server 2003 существует новая возможность, которая позволяет стандартным контроллерам домена кэшировать информацию о членстве в универсальных группах. Это позволяет контроллерам доменов выполнять аутентификацию пользователей даже при отсутствии связи с глобальным каталогом. Однако кэш с записями о членстве в универсальных группах не превращает контроллер домена в сервер глобального ката-
лога. Кэширующий контроллер домена не принимает запросы LDAP на порт 3268 и не хранит объекты из других доменов, кроме членства в универсальных группах.
Кэширование членства в универсальных группах не требует дополнительного времени центрального процессора или объема оперативной памяти от контроллеров домена в пределах сайта. После включения кэш универсальных групп обновляется каждые восемь часов. Если пользователь добавляется в универсальную группу после последнего обновления, права доступа для этой группы (и других групп, в которые входит эта группа) не будут включены в сертификат привилегий доступа и не попадут в маркеры локального доступа, созданные для пользователя на обычном сервере. Кэш членства в универсальных группах может хранить информацию о пользователях около 500 групп.
Кэширование членства в универсальных группах необходимо включить на всех сайтах, на которых отсутствует локальный сервер глобального каталога. В процедуре 10.1 описывается настройка сайта для регистрации пользователей без использования глобального каталога.
Процедура 10.1. Кэширование сведений о членах универсальных групп
Откройте консоль Active Directory — Sites and Services (Active Directory — сайты и службы).
Выделите узел, который необходимо настроить.
В правой панели откройте окно Properties (Свойства) для объекта NTDS Site Settings.
Пример окна показан на рис. 10.1.
Рис. 10.1. В окне NTDS Settings Properties отображаются параметры регистрации без глобального каталога
Установите флажок Enable Universal Group Membership Caching (Разрешить кэширование членства в универсальных группах). Оставьте окно для раскрывающегося списка Refresh Cache From (Обновлять кэш из) пустым. Средство проверки согласованности знаний автоматически определит ближайший узел с помощью сервера глобального каталога.
Щелкните на кнопке ОК, чтобы сохранить изменения и закрыть окно.
Удаление метаданных на отказавшем контроллере домена
Если восстановить отказавший контроллер домена не удалось, необходимо удалить ссылки на этот контроллер домена из базы данных Active Directory. Так называемые метаданные должны быть удалены до повышения другого сервера с тем же именем. Если потерян весь домен, метаданные этого домена также необходимо удалить до создания нового домена с аналогичным именем.
Для удаления метаданных предоставляется утилита с интерфейсом командной строки, которая называется Ntdsutil. Удаление метаданных выполняется при работающей службе Active Directory. Выполните последовательность действий, описанную в процедуре 10.2.
Процедура 10.2. Удаление метаданных
Запустите утилиту Ntdsutil.
В приглашении на ввод команды ntdsutil: введите metadata cleanup. Появится при глашениеmetadata cleanup.
Введите вопросительный знак для получения списка доступных команд: metadata cleanup: ?
ConnectionsHelpQuitRemove selected domainRemove selected Naming Context -Remove selected server.Select operation target4>ConnectionsHelpQuitRemove selected domainRemove selected Naming Context -Remove selected server.Select operation target4>Вывод этой справочной информации Подключение к конкретному контроллеру доменаВывод этой справочной информацииВозврат к предыдущему менюУдаление объектов DS для выбранного доменаУдаление объектов DS для выбранного контекста именованияУдаление объектов DS для выбранного сервера Выбор узлов, серверов, доменов, ролей, контекстов именованияВывод этой справочной информации Подключение к конкретному контроллеру доменаВывод этой справочной информацииВозврат к предыдущему менюУдаление объектов DS для выбранного доменаУдаление объектов DS для выбранного контекста именованияУдаление объектов DS для выбранного сервера Выбор узлов, серверов, доменов, ролей, контекстов именования
Connections
Help
Quit
Remove selected domain
Remove selected Naming Context -
Remove selected server.
Select operation target
4>
Connections
Help
Quit
Remove selected domain
Remove selected Naming Context -
Remove selected server.
Select operation target
4>
Вывод этой справочной информации Подключение к конкретному контроллеру домена
Вывод этой справочной информации
Возврат к предыдущему меню
Удаление объектов DS для выбранного домена
Удаление объектов DS для выбранного контекста именования
Удаление объектов DS для выбранного сервера Выбор узлов, серверов, доменов, ролей, контекстов именования
Вывод этой справочной информации Подключение к конкретному контроллеру домена
Вывод этой справочной информации
Возврат к предыдущему меню
Удаление объектов DS для выбранного домена
Удаление объектов DS для выбранного контекста именования
Удаление объектов DS для выбранного сервера Выбор узлов, серверов, доменов, ролей, контекстов именования
Clear credsConnect to domain %sConnect to server %sHelpInfoQuitSet creds %s %s %sClear credsConnect to domain %sConnect to server %sHelpInfoQuitSet creds %s %s %s
Clear creds
Connect to domain %s
Connect to server %s
Help
Info
Quit
Set creds %s %s %s
Clear creds
Connect to domain %s
Connect to server %s
Help
Info
Quit
Set creds %s %s %s
Введите параметр connections и ? для вывода списка дополнительных параметров:
Удаление учетных данных предыдущего соединения
Подключение к DNS-имени домена
Подключение к серверу по DNS-имени или IP-адресу
Вывод этой справочной информации
Отображение информации о соединении
Возврат к предыдущему меню
Установка учетных данных - домен, пользователь, пароль
Используйте "NULL” для установки пустого пароля
Если операция выполняется с обычного сервер» и без привилегий администратора, то воспользуйтесь командой set creds для ввода аутентификационных данных административной учетной записи.
Введите connect to server <dsa> для привязки к определенному серверу, где вместо <dsa> необходимо ввести полностью определенное имя DNS контроллера домена, на ко-
тором необходимо обновить базу данных Active Directory. Подойдет любой функционирующий контроллер домена. Результат транзакции будет выглядеть следующим образом: server connections: set creds company.com administrator pw server connections: connect to server dc-01.company.com
Binding to de-11.company.com as user(administrator) in domain(company.com ...
Connected to dc-11.company.com as user(administrator) in domain(company.com)
7. Введите select operation target. Появится приглашение select operation target. Введите ? для получения списка доступных команд:
Connections
- Подключение к конкретному
контроллеру домена
Help
- Вывод этой информации
List current selections узел/домен/сервер
- Показать текущий
List domains
- Показать список всех доменов, для
ч>
которых есть перекрестные ссылки
List domains in site
- Показать все домены в пределах
выбранного узла
List roles for connected
server
- Показать роли, о которых знает
ч>
выбранный сервер
List servers for domain
in site
- Показать серверы в пределах
выбранного домена и узла
List servers in site
- Показать серверы в пределах
ч>
выбранного узла
List sites
- показать узлы в пределах
предприятия
Quit
- Вернуться в предыдущее меню
Select domain %d
- Выбрать домен %d
Select server %d
- Выбрать сервер %d
Select site %d
- Выбрать узел %d
Введите list sites. Пример результата выполнения этой команды показан ниже: select operation target: list sites Found 4 site(s)
0 - CN=Phoenix,CN=Sites,CN=Configuration,DC=Company,DC=com
- CN=Houston,CN=Sites,CN=Configuration,DC=Company,DC=com
- CN=Albuquerque,CN=Sites,CN=Configuration,DC=Company,DC=com 3 - CN=Salt_Lake,CN=Sites,CN=Configuration,DC=Company,DC=com
Введите select site <#>, где вместо символа < #> необходимо ввести номер узла, в котором установлен удаляемый сервер: select operation target: select site 1 Site - CN=Salt_Lake,CN=Sites,CN=Configuration,DC=Company,DC=com No current domain No current server
Введите list domains in site. Пример результата выполнения этой команды показан ниже: select operation target: list domains in site
Found 1 domain(s)
0 - DC=subsidiary,DC=com
1 - DC=company,DC=com
Введите select domain <#>, где вместо <#> необходимо ввести номер домена, в который входит удаляемый сервер:
select operation target: select domain 1
Site - CN=S.alt_Lake,CN=Sites,CN=Configuration,DC=Company,DC=com Domain - DC=company,DC=com No current server
Введите строку list servers for domain in site. Пример выполнения этой команды показан ниже:
select operation target: list servers for domain in site
Found 1 server(s)
0 - CN=DC-11,CN=Servers,CN=Salt_Lake,CN=Sites,CN=Configuration,
^ DC=Company,DC=com
Введите select server <#>, где вместо < #> необходимо ввести номер удаляемого сервера. Пример выполнения команды показан ниже:
select operation target: select server 0
Site - CN=Salt_Lake,CN=Sites,CN=Configuration,DC=Company,DC=com
Domain - DC=company,DC=com
Server - CN=DC-11,CN=Servers,CN=Salt_Lake,CN=Sites,CN=Configuration, ^DC=Company,DC=com
DSA object - CN=NTDS Settings,CN=DC-01,CN=Servers,CN=Salt_Lake,
^CN=Sites,CN=Configuration,DC=Company,DC=com
DNS host name - DC-11.company.com
Computer object - CN=DC-11,OU=Domain Controllers,DC=company,DC=com
На этом этапе мы указали интересующий объект сервера, который мы хотим удалить. Теперь можно ввести команду q и вернуться к приглашению metadata cleanup.
Введите команду remote selected server. Откроется окно сообщения с предложением проверить запрос.
Щелкните на кнопке Yes (Да), и процедура удаления начнется. Пример отчета показан ниже:
Metadata cleanup: remove selected server
"CN=DC-11,CN=Servers,CN=Salt_Lake,CN=Sites,CN=Configuration, ^DC=Company,DC=com" removed from server "dc-01.company.com"
Завершите работу утилиты Ntdsut il и подождите, пока изменение будет реплицировано.
Этим же методом можно воспользоваться для удаления домена, который не был полностью удален при отключении последнего контроллера домена. Не стоит напоминать, что следует соблюдать максимальную осторожность при удалении любого работающего домена.
Выход из строя серверов, играющих роли хозяев операций
Некоторые задачи не предназначены для выполнения на нескольких серверах одновременно, поэтому для их выполнения выбирается отдельный сервер. Эти задачи называются Flexible Single Master Operations (FSMO). Сервер, выбранный для выполнения подобной задачи, называется хозяином операции. В главе 8, “Проектирование доменов Windows Server 2003”, рассматривались задачи, которые возлагаются на хозяев операций. Вкратце напомним названия серверов, выполняющих роли FSMO.
Хозяин именования домена (Domain Naming Master). Сервер, выполняющий эту роль, отвечает за обеспечение уникальности доменных имен в пределах леса. В пределах леса существует единственный хозяин именования доменов.
Хозяин схемы (Schema Master). На сервере, выполняющем эту роль, хранится единственная предназначенная для чтения и записи копия схемы. В пределах леса существует только один хозяин схемы.
PDC Emulator. Выполняющий эту роль сервер реплицирует обновления на классические резервные контроллеры домена Windows NT (ВВС) при работе в режиме Windows 2000 Mixed. Кроме этого, PDC Emulator выступает в роли последней инстанции при обновлении паролей и является источником точного времени для других контроллеров домена. В каждом домене существует один PDC Emulator.
Хозяин относительных идентификаторов (RID Master). На сервере, выполняющем эту роль, хранится главная копия списка относительных идентификаторов. В режиме Windows 2000 Mixed относительные идентификаторы выдаются в арифметическом порядке. В режиме Windows 2000 Native каждый контроллер домена получает набор относительных идентификаторов от хозяина относительных идентификаторов. В каждом домене существует свой RID Master.
Хозяин инфраструктуры (Infrastructure Master). Сервер, выполняющий эту роль, отвечает за быстрое распространение изменений имен, которые оказывают влияние на членство в группах в пределах всего леса. В каждом домене существует собственный хозяин инфраструктуры.
Кратковременный выход из строя сервера, выполняющего роль хозяина операции, не требует специальных мероприятий по восстановлению, но, если планируется длительное отключение такого сервера, его роль или роли необходимо передать другому контроллеру домена. Это особенно справедливо, если восстановление сервера вообще не планируется.
Если сервер, выполняющий роль хозяина операции, аварийно завершил работу и не может быть восстановлен, его роль или роли могут быть переданы другому контроллеру домена. При обычной передаче роли предыдущий хозяин операции должен быть подключен к сети для удовлетворения запроса на передачу роли. При принудительной передаче роли, когда новый контроллер домена вступает в права хозяина переданной ему роли, исходный хозяин операции отключается от сети, и роль передается без запроса.
После принудительной передачи роли другому контроллеру домена не подключайте потерявшего роль хозяина операции к сети. Рассматривайте такой сервер, как костер на лагерной стоянке: залейте водой, закопайте и еще раз залейте водой. Это позволит предотвратить предоставление устаревшей информации предыдущим хозяином операции и не даст создать обходной путь обновления контролируемых структур, например контейнеров Schema и Partition.
Назначение хозяев операций
Для идентификации роли хозяина операции используется атрибут объекта Active Directory, который управляет определенной ролью. Например, объект Domain управляет ролью PDC Emulator. Атрибут FSMO этого объекта содержит характерное имя сервера, который был назначен хозяином операции для роли PDC Emulator. При нормальной или принудительной передаче роли меняется характерное имя, хранящееся в этом атрибуте.
Восстановление сервера, выполняющего роль PDC Emulator'
Единственным исключением из правила "не подключайте потерявшего роль хозяина операций в сеть" является сервер, выполняющий роль PDC Emulator. Если сервер, выполняющий роль PDC Emulator, подключается обратно в сеть, он в процессе репликации получает имя нового сервера, теперь выполняющего роль PDC Emulator, и вежливо прекращает все собственные действия по выполнению роли PDC Emulator.
На практике часто роль RID Master назначается тому же серверу, который выполняет роль PDC Emulator, поэтому данный сервер нельзя подключать обратна в сеть. Восстановление прежнего сервера, который до выхода из строя выполнял роль RID Master, может привести к созданию двух объектов с одинаковыми относительными идентификаторами. Это приведет к проблемам в работе службы безопасности и к нарушению целостности базы данных. Если роли RID Master и PDC Emulator назначены одному серверу и другому серверу пришлось принудительно передать эти роли, удалите содержимое жесткого диска на отказавшем компьютере и повторно установите операционную систему Windows Server 2003.
Передача роли хозяина операций
Для передачи роли новому хозяину операций администратор может воспользоваться консолью ММС или утилитой с интерфейсом командной строки. Выбор конкретной консоли ММС зависит от передаваемой роли. В табл. 10.1 перечислены роли и соответствующие консоли ММС, а также критерии выбора хозяина операций.
Таблица 10.1. Передача роли хозяев операций
Роль хозяина операций
Консоль
Критерии выбора хозяина операций
PDC Emulator
Active Directory — Users and Computers (Active Directory — пользователи и компьютеры)
Сервер, выполняющий роль PDC Emulator, должен поддерживать связь со всеми контроллерами BDC Windows NT. Кроме этого, для обеспечения проверки действительности паролей PDC Emulator должен иметь надежное внешнее соединение
RID Master
Active Directory — Users and Computers (Active Directory — пользователи и компьютеры)
Эта роль должна быть назначена тому же серверу, что и роль PDC Emulator. Если Существуют веские причины для предоставления этой роли другому серверу, обеспечьте надежную связь между серверами, выполняющими роли RID Master и PDC Emulator. В режиме Windows 2000 Mixed сервер, выполняющий роль RID Master, должен быть доступен для создания учетных записей пользователей, компьютеров и групп
Infrastructure Master
Active Directory — Users and Computers (Active Directory — пользователи и компьютеры)
Эту роль можно назначить любому контроллеру домена, который не является сервером глобального каталога. Дополнительная информация приводится во врезке "Выполнение сервером роли Infrastructure Master"
Domain Naming Master
Active Directory — Domains and Trusts (Active Directory — домены и доверия)
Эту роль и роль Schema Master следует назначить одному контроллеру домена. Обе роли уникальны в пределах леса, поэтому хозяин операции должен иметь надежное внешнее соединение
Schema Master
Schema Management
См. описание для Domain Naming Master
Выполнение сервером роли Infrastructure Master
При внесении участника системы безопасности (пользователя, группы или компьютера) в группу характерное имя участника системы безопасности добавляется в атрибут Members объекта группы в базе данных Active Directory. База данных Active Directory поддерживает внутреннюю целостность, создавая обратные ссылки на объект, который представляет участ-
ника системы безопасности. Таким образом, при изменении имени объекта обновляется атрибут Members объекта группы.
Если администратор домена в пределах леса добавляет участника системы безопасности из другого домена в группу локального домена, то служба Active Directory сталкивается с дилеммой. Создание обратной ссылки на объект из другого контекста именования Domain невозможно. Проблема решается с помощью создания фантомного объекта (phantom object), который фактически является списком в своем контексте именования Domain и содержит характерные имена объектов, глобально уникальные идентификаторы и идентификаторы безопасности объектов.
Сервер, выполняющий роль Infrastructure Master в домене обнаруживает изменения имен для участников системы безопасности, реализованные с помощью фантомных объектов в собственном домене. Без этой службы имена, показанные в списке членов групп, не соответствовали бы новым именам в исходном домене. Это не оказывает влияния на доступ к ресурсам, так как идентификатор безопасности не изменился, но администратора это может ввести в заблуждение.
Сервер Infrastructure Master выполняет свою задачу, периодически просматривая список фантомных объектов и сравнивая имена в списке с именами в глобальном каталоге. Если возникнет несовпадение, служба обновит фантомный объект для соответствия реальному имени. Это изменение реплицируется на другие контроллеры домена, которые хранят фантомные объекты.
Серверы глобального каталога уже содержат копии объектов из других доменов, поэтому им не нужны фантомные объекты. Именно по этой причине важно, чтобы сервер Infrastructure Master не являлся сервером глобального каталога.
Передача роли хозяина операций с помощью консоли ММС
Обратитесь к табл. 10.1 для выбора соответствующей консоли и выполните передачу роли, как описано в процедуре 10.3.
Процедура 10.3. Передача роли хозяина операций с помощью консоли ММС
Откройте соответствующую консоль ММС для передачи роли хозяина операций.
Если консоль запущена не на том контроллере домена, который должен получить роль хозяина операций, щелкните правой кнопкой мыши на верхней пиктограмме и выберите из контекстного меню команду Connect То Domain Controller (Подключение к контроллеру домена).
Выберите имя контроллера домена, который станет новым хозяином операций. Это удовлетворяет требование LDAP по привязке к серверу для аутентификации.
Щелкните на кнопке ОК, чтобы подключиться к контроллеру домена.
Еще раз щелкните правой кнопкой мыши на верхней пиктограмме. В этот раз выберите из раскрывающегося меню значение Operations Master (Хозяин операций). Откроется окно Operations (Операции).
Перейдите на вкладку, связанную с передаваемой ролью.
Убедитесь в том, что контроллер домена, указанный в поле Current Focus (Текущий фокус), является сервером, которому будет передана роль хозяина операции.
Щелкните на кнопке Change (Изменить). Откроется окно с требованием подтверждения.
Щелкните на кнопке ОК. Через некоторое время будет выдано сообщение об успешной передаче роли хозяина операций. Теперь на вкладке Operations (Операции) в разделе Current Operations Master (Текущий хозяин операций) отображается новое имя сервера
Щелкните на кнопке ОК, чтобы закрыть окно.
Connections-Help-Quit-Seize domain namingmaster-Seize infrastructuremaster-Seize PDC-Seize RID master-Seize schema master-Select operationtarget-Transfer domain namingmaster -Transfer infrastructure masterTransfer PDCTransfer RID master-Transfer schema master-Connections-Help-Quit-Seize domain namingmaster-Seize infrastructuremaster-Seize PDC-Seize RID master-Seize schema master-Select operationtarget-Transfer domain namingmaster -Transfer infrastructure masterTransfer PDCTransfer RID master-Transfer schema master-
Connections-
Help-
Quit-
Seize domain namingmaster-
Seize infrastructuremaster-
Seize PDC-
Seize RID master-
Seize schema master-
Select operationtarget-
Transfer domain namingmaster -
Transfer infrastructure master
Transfer PDC
Transfer RID master-
Transfer schema master-
Connections-
Help-
Quit-
Seize domain namingmaster-
Seize infrastructuremaster-
Seize PDC-
Seize RID master-
Seize schema master-
Select operationtarget-
Transfer domain namingmaster -
Transfer infrastructure master
Transfer PDC
Transfer RID master-
Transfer schema master-
На этом этапе стоит подождать полной сходимости репликации, чтобы все контроллеры домена знали о новом хозяине операции. Для запуска принудительной репликации можно воспользоваться консолью Active Directory — Sites and Services (Active Directory - сайты и службы) или утилитой Replication Monitor (Replmon) из состава Support Tools.
Передача роли хозяина операций с помощью утилиты Ntdsutil
Если системный администратор предпочитает использовать утилиты с интерфейсом командной строки (или возникла необходимость управления серверами с помощью Telnet или SSH), то для передачи роли хозяина операций другому контроллеру домена можно воспользоваться утилитой Ntdsutil. Как исходный хозяин операции, так и контроллер домена, которому передается роль, должны быть доступны в сети. Последовательность действий по передаче роли описывается в процедуре 10.4.
Процедура 10.4. Передача роли хозяина операции с помощью утилиты Ntdsutil
Зарегистрируйтесь в домене от имени учетной записи с правами администратора. Если планируется передача ролей Schema Master и Domain Naming Master, то привилегии администратора должны распространяться на контекст именования Configuration.
Откройте интерпретатор команд и запустите утилиту ntdsut i 1.
В приглашении ntdsutil введите команду roles. Появится приглашение FSMO maintenance:.
Введите ? для получения списка доступных команд, как показано ниже.
fsmo maintenance: ?
Вывести справочную информацию ' Подключиться к конкретному контроллеру домена
Вывести справочную информацию Вернуться в предыдущее меню Перезаписать Domain Naming Master в домене на подключенном сервере
Перезаписать роль Infrastructure Master на подключенном сервере Перезаписать роль PDC Master на подключенном сервере Перезаписать роль RID Master на подключенном сервере
Перезаписать роль Schema Master на подключенном сервере
Выбор узлов, серверов, доменов, ролей, контекстов именования
Сделать подключенный сервер Domain Naming Master
- Сделать подключенный сервер Infrastructure Master
- Сделать подключенный сервер PDC Master
Сделать подключенный сервер RID Master
Сделать подключенный сервер Schema Master
Введите команду connections. Появится приглашение server connections.
Введите символ ? для получения списка доступных команд:
server connections: ?
Clear credsS>Connect to domain %sConnect td server %sHelpInfoQuitSet creds %s %s %sClear credsS>Connect to domain %sConnect td server %sHelpInfoQuitSet creds %s %s %sВывести справочную информацию
Clear creds
S>
Connect to domain %s
Connect td server %s
Help
Info
Quit
Set creds %s %s %s
Clear creds
S>
Connect to domain %s
Connect td server %s
Help
Info
Quit
Set creds %s %s %s
Очистить аутентификационные данные предыдущего соединения
Подключение К домену по DNS-имени
Подключение к серверу по имени DNS или IP-адресу
Вывести справочную информацию
Вывести сведения о соединении
Вернуться в предыдущее меню
Установка учетных данных - домен, пользователь, пароль
Используйте “NULL" для установки пустого пароля,
* - для ввода пароля с консоли
Введите команду connect to server %s, где %s — это полностью определенное имя DNS контроллера домена, которому необходимо передать роль хозяина операций. Например, введите connect to server company.com. При успешном выполнении команды будет выдано следующее сообщение: server connections: connect to server dc-02.company.com Binding to WDC-02.company.com ...
Connected to WDC-02.company.com с помощью учетных данных
'Ъ= локального пользователя.
Если необходимо воспользоваться другой учетной записью, сделайте это с помощью команды set creds перед использованием команды connect to server.
Введите q для выхода из модуля и возврата к приглашению на ввод команды FSMO maintenance.
Выберите передаваемую роль и введите соответствующую команду. Например, для передачи роли PDC Emulator введите команду transfer PDC.
В открывшемся окне с запросом на подтверждение операции щелкните на кнопке ОК, чтобы начать процесс передачи роли.
Если операция передачи завершается неудачей, выдается сообщение об ошибке и роль останется назначенной оригинальному серверу. Например, если сервер, которому передается роль, уже является хозяином операции, выдается соответствующее уведомление. Если операция по передаче завершается успешно, утилита Ntdsutil выдает список текущих хозяев операций, подтверждая успешное завершение, как показано в следующем отчете:
fsmo maintenance: transfer pdc
Server "dc-01.subsidiary.com" knowsabout 5 roles
Schema - CN=NTDS Settings,CN=DC-01,CN=Servers,CN=Phoenix,CN=Sites,
S>CN=Configuration,DC=company,DC=com
Domain - CN=NTDS Settings,CN=DC-01,CN=Servers,CN=Phoenix,CN=Sites, ^CN=Conf i gura t i on,DC=company,DC=c om
PDC- CN=NTDS Settings,CN=DC-02,CN=Servers,CN=Phoenix,CN=Sites,
^CN=Configuration,DC=company,DC=com
RID- CN=NTDS Settings,CN=DC-01,CN=Servers,CN=Phoenix,CN=Sites,
'bCN=Conf iguration,DC=company,DC=com
Infrastructure - CN=NTDS Settings,CN=DC-01,CN=Servers,CN=Phoenix, 'bCN=Sites,CN=Configuration,DC=company,DC=com
Сокращенный ввод команд при работе с Ntdsutil
В утилите Ntdsutil для запуска команды достаточно ввести ту часть команды, которая делает ее однозначной. Например, вместо connect to server можно ввести con t s.
Принудительное назначение роли хозяина операции
Если контроллер домена, который является хозяином операции, аварийно завершает работу или становится недоступен без возможности восстановления, использовать консоли управления для передачи роли нельзя. Роль необходимо назначить с помощью утилиты Ntdsut il.
Еще раз напоминаем: после назначения роли хозяина операций новому серверу нельзя подключать к сети контроллер домена, который ранее выполнял эту роль хозяина операции. Лучше всего просто переформатировать жесткий диск отказавшего сервера.
Убедитесь, что новый сервер, которому назначается роль хозяина операции, подключен к сети, и выполните последовательность действий, описанную в процедуре 10.5.
Процедура 10.5. Назначение роли хозяина операции
Зарегистрируйтесь в домене с помощью учетной записи администратора. Если необходимо провести назначение роли Schema Master или Domain Naming Master, то потребуются' привилегии администратора в контексте именования Configuration.
Вызовите интерпретатор команд и запустите утилиту Ntdsut i 1.
В приглашении на ввод команды введите roles. Появится приглашение FSMO maintenance.
Введите connections. Появится приглашение server connections.
Введите команду connect to server %s, где вместо %s введите полностью определенное DNS-имя того контроллера домена, которому передается роль хозяина операции, например connect to server company. com. При успешной передаче роли будет выдан следующий отчет: server connections: connect to server dc-03.company.com Bindindg to WDC-03.company.com ...
Connected/to WDC-03.company.com с помощью учетных данных
*Ълокального пользователя.
Введите q, чтобы вернуться к приглашению на ввод команды FSMO maintenance.
Выберите роль, которую следует передать серверу. Например, чтобы передать серверу роль RID Master, необходимо ввести команду seize RID master. Откроется окно с запросом на под-
тверждение операции. Щелкните на кнопке ОК (если текущий хозяин операции доступен в сети, утилита Ntdsut il попытается выполнить стандартную процедуру передачи роли). Если передача роли завершается неудачей, будет выдано сообщение об ошибке и роль останется назначенной текущему хозяину операции. Если же передача роли будет успешно осуществлена, то утилита Ntdsutil отобразит перечень текущих серверов, выполняющих роли хозяев операций.
Выход из строя ключевого компонента репликации
При отказе контроллера домена его партнеры по репликации обнаруживают отсутствие ответов на запросы обновлений. Партнеры уведомляют средство проверки согласованности знаний, которое начинает работу по созданию объектов соединений для обхода отказавшего контроллера домена, как работники дорожной службы направляют движение автомобилей вокруг места аварии.
Как только отказавший контроллер домена восстанавливает работоспособность, его партнеры по репликации обнаруживают его присутствие и сообщают средству проверки согласованности знаний. Средство проверки согласованности знаний (КСС) повторно создает объекты соединений и удаляет обходной маршрут.
Это может занять некоторое время, поэтому наберитесь терпения. В итоге в журнале событий появится сообщение о создании объектов соединения с помощью средства проверки согласованности знаний, а также сообщение об успешной синхронизации контекстов именования агентом репликации каталога.
Все немного усложняется, если на отказавший контроллер домена возложены задачи, связанные с межсайтовой репликацией. Это касается связующих серверов (bridgehead server) и генераторов межсайтовой топологии (Inter-Site Topology Generator server).
Выбор нового предпочтительного связующего сервера
Репликация между сайтами выполняется с помощью избранных контроллеров домена, которые называются связующими серверами. В обычных условиях средство проверки согласованности знаний устраняет проблемы при выходе связующего сервера без вмешательства администратора. Для этого выполняется сортировка доступных контроллеров домена по глобально уникальному идентификатору и выбирается сервер с наибольшим глобально уникальным идентификатором.
Средство проверки согласованности знаний можно заставить выбирать связующий сервер из определенной группы серверов. Например, желательно, чтобы в качестве связующего сервера выступал сервер глобального каталога, чтобы при репликации частичных контекстов именования требовался только один переход. Список кандидатов можно ограничить списком серверов глобального каталога.
Для назначения предпочтительного связующего сервера можно воспользоваться консолью Active Directory — Sites and Services (Active Directory — сайты и службы). Необходимые параметры настраиваются в окне свойств сервера. В главе 7, “Управление репликацией Active Directory”, подробно описана последовательность действий для выполнения этой операции. На рис. 10.2 показано окно выбора связующего сервера, доступное из консоли Active Directory — Sites and Services (Active Directory — сайты и службы).
General | Qbiaet | Security |General | Qbiaet | Security |Л1Л1Л1Л1
General | Qbiaet | Security |
General | Qbiaet | Security |
Л1Л1
Л1Л1
Djycfpli(Xt |Brkjgehead Servet forPhoentx Site а*»* data bamferbridgehead awver for the
rotwvhgbanstertK
Computer
; Computer. |ST
: Dgnan [corvev.com
OK | Cancel | Йд*
Рис. 102. На консоли Active Directory— Sites and Services в окне свойств сервера можно указать, что этот сервер является предпочтительным связующим сервером
Всегда создавайте как минимум два предпочтительных связующих сервера. Если выбрать только один сервер и он откажет, репликация остановится до назначения нового связующего сервера. Если последний из доступных связующих серверов выйдет из строя, необходимо быстро назначить новый предпочтительный связующий сервер, чтобы восстановить возможность репликации.
Выбор нового генератора межсайтовой топологии
Выход из строя генератора межсайтовой топологии (ISTG) не приводит к немедленному возникновению проблем. Единственной задачей генератора межсайтовой топологии является создание соединения между связующими серверами. Это случается не часто, но такой отказ не стоит оставлять незамеченным.
Генератор межсайтовой топологии информирует партнеров по репликации о своем присутствии, обновляя атрибут собственного объекта каждые 30 минут. Если атрибут не обновляется в течение часа, средство проверки согласованности знаний на других контроллерах домена в пределах сайта определяет отсутствие генератора межсайтовой топологии и начинает выборы другого генератора межсайтовой топологии.
Генератор межсайтовой топологии можно определить в окне свойств объекта NTDS Site Settings на консоли Active Directory— Sites and Services (Active Directory — сайты и службы). Пример такого окна показан на рис. 10.3.
Для выбора генератора межсайтовой топологии средство проверки согласованности знаний использует те же принципы, что и для выбора нового связующего сервера. Выбирается контроллер домена с наибольшим глобально уникальным идентификатором в пределах сайта. Но в случае генератора межсайтовой топологии невозможно указать “предпочтительные” контроллеры домена.
|n CDS Site Settings Properties|n CDS Site Settings Properties33jjxjjjxj
|n CDS Site Settings Properties
|n CDS Site Settings Properties
3
3
jjxj
jjxj
S<eS<№g> |ot*ct| Seortyj
NTDS Site SellingsNTDS Site Sellings
NTDS Site Sellings
NTDS Site Sellings
description:P
Change Schetfcfa.. |
, Inter-Sie TopotosyGenefator
i Server |S1
Яе
f< Default)f< Default)fiefmh cache hornfiefmh cache horn/UrivefMl Group MeroberthpC^^' Г EnAle Universal Group Membership Caching/UrivefMl Group MeroberthpC^^' Г EnAle Universal Group Membership Caching
f< Default)
f< Default)
fiefmh cache horn
fiefmh cache horn
/UrivefMl Group MeroberthpC^^
' Г EnAle Universal Group Membership Caching
/UrivefMl Group MeroberthpC^^
' Г EnAle Universal Group Membership Caching
Puc. 10.3. Свойства объекта NTDS Site Settings, в которых показан генератор межсайтовой топологии для указанного сайта
Проверка копий с помощью утилиты dsastat
После запуска репликации желательно проверить совпадение копий, хранящихся на разных контроллерах домена. Проще всего воспользоваться утилитой dsastat, которая предоставляется в составе Support Tools. Откройте интерпретатор команд и введите команду dsastat - loglevekinfo. В зависимости от скорости соединений между партнерами по репликации утилита может потребовать от 5 до 15 минут на выполнение проверки. В итоге будет выдан список объектов, хранящихся в копиях, а также размер каждого объекта.
Выход из строя внешнего соединения
Если происходит обрыв связи по внешнему соединению, связующие серверы на обоих концах соединения обнаружат, что не удается получить обновления от партнера по репликации. Если существует альтернативное (но более дорогое) соединение с другим сайтом, агент репликации каталога на связующих серверах воспользуется им автоматически. Кроме этого, агент репликации каталога уведомит генератор межсайтовой топологии, который попытается создать новые соединения с другими связующими серверами.
Не стоит вмешиваться в {заботу агента репликации каталога и в работу генератора межсайтовой топологии. Если они не в состоянии создать подходящий маршрут репликации в результате особенностей настройки и подключения сайтов, придется отказаться от репликации, пока не будет восстановлено отказавшее соединение.
Резервное копирование каталога
Во времена операционной системы Windows NT разделы системного реестра можно было скопировать на единственный гибкий диск аварийного восстановления, если домен не слишком большой, или на жесткий диск с помощью команды rdisk -s, если база данных Security Account Manager (SAM) слишком велика для копирования на жесткий диск. Эти дни давно прошли. Даже утилиты rdisk давно не существует.
При операциях Active Directory активно используются системный реестр и множество двоичных файлов, поэтому для сохранения целостности системы придется копировать целые системные каталоги. Компания Microsoft называет эти файлы System State (состояние системы). На рис. 10.4 показан перечень файлов состояния системы в окне утилиты NTBackup. В этот перечень входят следующие файлы.
Все файлы, защищенные системой защиты файлов Windows (практически все файлы в каталоге С: \Windows)
Системные файлы ntdetect. com, Ntldr и bootsect .dat
База данных Active Directory, ntds . dit и связанные с ней файлы журналов и контрольных точек
Некоторые файлы обозревателя Internet Explorer и другие совместно используемые файлы в каталоге Program Files
Все разделы системного реестра из каталога \Windows\System32\Conf ig (обновленные копии размещаются в каталоге \Windows\Repair)
База данных регистрации классов СОМ+
Содержимое каталога Sy svo 1
Файлы службы сертификатов (если служба установлена)
Файлы службы кластеров (если служба установлена)
Backup UI ihtу | llnhl led]Backup UI ihtу | llnhl led]й^'й. »Ш1Л1й^'й. »Ш1Л1
Backup UI ihtу | llnhl led]
Backup UI ihtу | llnhl led]
й^'й. »Ш1Л1
й^'й. »Ш1Л1
Wan BakmlflMhMMlMaMaBMatfal SataMtMal-
IBw DwMop8^3 My Computer»] Qm* 3K Floppy (A.) ;Щ Q^ LocalDisk(C) 83 D^* DMa(D:J ® D^ CD Drive |X:) ®-me tods on *ргоГ (U:■ ’9^intiak on ‘pro11 ^;. BOSERc1-e$onPro1M: : $ □» captures on *pro1;83 D5E rclon-proVg:)■ ивиненIS 0^3 My Documents @ Q*3 My Network PlacesIBw DwMop8^3 My Computer»] Qm* 3K Floppy (A.) ;Щ Q^ LocalDisk(C) 83 D^* DMa(D:J ® D^ CD Drive |X:) ®-me tods on *ргоГ (U:■ ’9^intiak on ‘pro11 ^;. BOSERc1-e$onPro1M: : $ □» captures on *pro1;83 D5E rclon-proVg:)■ ивиненIS 0^3 My Documents @ Q*3 My Network PlacesГсяимиГсяимиU ^BootFiesU#C0M+ Class Regis...Q ^Registry□ ®SYSVOLU ^BootFiesU#C0M+ Class Regis...Q ^Registry□ ®SYSVOLВмкмрцН» * Яв пек |A\Badaip.bWВмкмрцН» * Яв пек |A\Badaip.bW
IBw DwMop8^3 My Computer
»] Qm* 3K Floppy (A.) ;
Щ Q^ LocalDisk(C) 83 D^* DMa(D:J ® D^ CD Drive |X:) ®-me tods on *ргоГ (U:
■ ’9^intiak on ‘pro11 ^;
. BOSERc1-e$onPro1M: : $ □» captures on *pro1;
83 D5E rclon-proVg:)
■ ивинен
IS 0^3 My Documents @ Q*3 My Network Places
IBw DwMop8^3 My Computer
»] Qm* 3K Floppy (A.) ;
Щ Q^ LocalDisk(C) 83 D^* DMa(D:J ® D^ CD Drive |X:) ®-me tods on *ргоГ (U:
■ ’9^intiak on ‘pro11 ^;
. BOSERc1-e$onPro1M: : $ □» captures on *pro1;
83 D5E rclon-proVg:)
■ ивинен
IS 0^3 My Documents @ Q*3 My Network Places
Гсяими
Гсяими
U ^BootFies
U#C0M+ Class Regis...
Q ^Registry
□ ®SYSVOL
U ^BootFies
U#C0M+ Class Regis...
Q ^Registry
□ ®SYSVOL
ВмкмрцН» * Яв пек |A\Badaip.bW
ВмкмрцН» * Яв пек |A\Badaip.bW
Puc. 10.4. Окно утилиты NTBackup, в котором отображается список файлов состояния системы
Необходимость одновременного резервного копирования этих файлов позволяет сохранить согласованность между различными хранилищами данных, но это значит, что небольшая ошибка в системном реестре во временном промежутке по окончании последней удачной конфигурации (Last Known Good Configuration) может привести к необходимости восстановления всех файлов состояния системы, включая базу данных Active Directory.
В этом разделе рассматриваются резервное копирование и восстановление файлов состояния системы с помощью утилиты Ntbackup. Это урезанная версия программы Veritas Backup Exec. Существуют аналогичные по возможностям программы резервного копирования от сторонних производителей. Это касается полной версии Backup Exec, Computer Associates AcrServe, Legato Networker, Tivoli Storage Manager, BEI Corporation UltraBac, CommVault Galaxy и других программ. Убедитесь в том, что вы используете последнюю версию программы, поскольку даже версия для Windows 2000 может быть неполностью совместима с операционной системой Windows Server 2003.
Почему необходимо создавать резервные копии Active Directory
Может возникнуть вопрос, зачем вообще нужно создавать резервные копии базы данных Active Directory. В конце концов, при правильном проектировании системы в домене всегда будет присутствовать как минимум три контроллера домена. Каждый из контроллеров домена хранит полную версию базы данных Active Directory. При отказе любого из серверов и даже при отказе двух серверов в качестве резервного остается третий контроллер домена. Кроме этого, до контроллера домена можно быстро повысить другой сервер Windows, что позволит добиться отказоустойчивости.
Самым очевидным ответом на вопрос “Зачем создавать резервные копии контроллера домена?” является закон Мэрфи, согласно которому при отсутствии резервных копий обязательно одновременно откажут все три контроллера домена. Кроме этого, в комнате с сервера-
ми может начаться пожар, и резервную копию Active Directory придется восстанавливать на удаленном сайте. Всегда необходимо иметь полную резервную копию на случай неудачного расположения звезд.
Но более вероятной причиной является ошибка со стороны администратора. Автор сам с этим сталкивался. И вы столкнетесь. Усталость и раздражение могут привести к удалению или изменению не того объекта. Результат может оказаться весьма прискорбным. Если случайно была удалена целая организационная единица с тысячами объектов пользователей, компьютеров и групп, ошибка администратора быстро реплицируется на другие контроллеры домена. Единственным решением является восстановление информации из резервной копии.
Необязательно создавать резервные копии на всех контроллерах домена. Выберите два или три контроллера и создайте резервную копию состояния системы на этих компьютерах. Не запускайте на контроллерах доменов приложения, которые потребуют резервного копирования локальным администратором.
Резервное копирование состояния системы
Резервная копия состояния системы всегда выполняется, когда система подключена к сети и работает в нормальном режиме. Служба Plug and Play Manager (Диспетчер Plug and Play) должна обнаружить устройство резервного копирования, например привод магнитной ленты, и установить необходимые драйверы. Может потребоваться Removable Storage Manager (Диспетчер сменных носителей) для переключения носителей. Дополнительная информация приводится в главе 21, “Восстановление после отказов системы".
Чтобы выполнить резервное копирование состояния системы с помощью утилиты Ntbackup, следуйте указаниям, приведенным в процедуре 10.6.
Процедура 10.6. Резервное копирование состояния системы
Установите в привод чистую магнитную ленту.
Запустите службу Windows 2000 Backup, выбрав Start* Programs1* Accessories*System Tools* Backup (Пуск*Программы*Стандартные*Служебные* Архивация данных). Откроется окно Backup (Резервное копирование).
Щелкните на кнопке Advanced (Дополнительно), чтобы отказаться от использования мастера.
Откройте вкладку Backup (Резервное копирование).
Раскройте дерево, чтобы получить доступ к пункту System State (Состояние системы), который указан под перечнем букв дисков.
Установите флажок напротив пункта System State (Состояние системы).
В поле Backup Destination (Путь к резервной копии) выберите устройство записи на магнитную ленту, на которое записывается резервная копия.
Если резервная копия записывается в файл, выберите File (Файл) и введите путь и имя файла в поле Backup Media or File Name (Устройство резервного копирования или имя файла). Удостоверьтесь, что файлы сохранены на надежном сменном носителе или на сетевом диске, который будет доступен при необходимости восстановления. Не записывайте резервную копию на локальный жесткий диск.
В меню выберите Tools*Options (Сервис1*Параметры). Откроется окно Options (Параметры).
Откройте вкладку Backup Туре (Тип резервной копии).
В разделе Default Backup Туре (Используемый по умолчанию тип резервной копии) выберите переключатель Сору (Копия). Это не позволит системе сбросить архивный флаги
помешать резервному копированию состояния системы в результате ночного резервного копирования.
Откройте вкладку Backup Log (Журнал резервного копирования).
Выберите переключатель Detailed (Подробно). Будет выдан большой объем информации, включая имя каждого файла, сохраненного в резервной копии. Обычно это избыточная информация, но стоит заметить, что как минимум один раз ее следует просмотреть, чтобы оценить набор файлов состояния системы.
Щелкните на кнопке ОК, чтобы сохранить изменения и вернуться в основное окно Backup (Резервное копирование).
Эта задача должна выполняться интерактивно, а не по расписанию, поэтому щелкните на кнопке Start Backup (Начать резервное копирование).
Если магнитная лента используется впервые, может быть выдано сообщение There is no unused media with the selected type, but unrecognized media is available (Нет неиспользованного носителя выбранного типа, но доступен нераспознанный носитель). Если лента опознана, может быть выдан запрос на подтверждение перезаписи существующих данных. Если есть уверенность, что на ленте нет важных данных, щелкните на кнопке ОК. Различные ленточные системы используют различные схемы форматирования и извлечения, поэтому сообщения могут меняться. Конкретные инструкции приводятся в системной документации. Утилита Ntbackup использует формат MTF (Microsoft Таре Format).
Как только система обнаружит ленту или расположение файла на сменном носителей, начнется процедура резервного копирования. Откроется окно Backup Progress (Состояние резервного копирования), в котором будет показано текущее состояние резервного копирования.
После завершения резервного копирования откроется окно со статистикой проведенной операции резервного копирования. Скорее всего, в поле Status (Состояние) будет показано, что были пропущены некоторые файлы. Щелкните на кнопке Report (Отчет) для просмотра журнала резервного копирования. Чаще всего пропускается каталог NO-NOT_ REMOVE_NtFrs_Preinstall_Directory в каталоге Sysvol. В этом каталоге хранятся файлы, которые были скопированы при начальной миграции файлов и папок в базу данных службы репликации файлов. Это нормально, и резервное копирование данного каталога можно не выполнять.
Просмотрите список файлов в журнале, чтобы проверить содержимое резервной копии. Обратите внимание, что файлы Active Directory не указываются отдельно в журнале резервного копирования. О наличии в резервной копии базы данных Active Directory говорит только одна запись в журнале.
Сначала файлы системного реестра из каталога \Windows\System32\Config копируются в специальный каталог, который называется \Registry. Каталог \Registry является временным и используется для создания моментального снимка системного реестра для резервного копирования. Это предотвращает блокирование доступа к файлам системного реестра при резервном копировании.
Восстановление Active Directory
Чаще всего возникают две ситуации, при которых требуется восстановление базы данных Active Directory.
Полный выход из строя контроллера домена, при котором требуется восстановление из резервной копии, включая состояние системы
Ошибка со стороны администратора, которая приводит к уничтожению или повреждению фрагмента Active Directory
Сохраняйте резервные копии состояния системы в отдельных файлах
Хотя совместимая с операционной системой Windows Server 2003 утилита резервного копирования может выполнять вполне приемлемое резервное копирование и восстановление состояния системы, иногда это непрактично для быстрого восстановления. Например, может существовать большая библиотека лент, в которой присутствуют копии десятков или сотен серверов. Полное удаленное восстановление файла Ntds.dit вместе с другими файлами состояния системы может отнять много времени и потребовать выдачи разрешений агенту на контроллере домена, так как Active Directory недоступна для аутентификации службы.
Для ускорения восстановления многие организации планируют пофайловое резервное копирование состояния системы на контроллерах домена до ночного резервного копирования. При этом на удаленный сервер для записи на ленту копируются файлы с расширением . bkf. Восстановление единственного файла с последующим копированием на соответствующий контроллер домена может оказаться проще, чем полное восстановление с ленты.
В первом случае восстановление файлов состояния системы (включая Active Directory) с ленты выполняется вместе с восстановлением операционной системы. При подключении к сети восстановленного контроллера домена его партнеры по репликации предоставляют ему изменения, которые произошли с момента резервного копирования. Именно по этой причине можно восстановить достаточно старую резервную копию (трех-четырехдневной или даже недельной давности), если возникают проблемы в {заботе устройства записи на магнитную ленту, не позволяющие воспользоваться резервной копией суточной давности.
Пароль восстановления службы каталога
При восстановлении Active Directory на контроллере домена необходима возможность регистрации на сервере от имени учетной записи Administrator из локальной базы данных SAM. Иногда пароль этой учетной записи неизвестен.
Для решения этой проблемы компания Microsoft предоставила новую возможность (Reset DSRM Administrator Password) утилиты Ntdsutil, которая позволяет сбросить локальней пароль администратора. При наличии административных привилегий на контроллере домена эту возможность можно использовать для изменения пароля администратора в локальной базе данных SAM.
Обычно без привилегий администратора нельзя локально зарегистрироваться на контроллере домена. Если пользователю без привилегий администратора удастся локально зарегистрироваться на контроллере домена и получить доступ к локальной консоли, то при попытке сбросить пароль восстановления службы каталога будет выдано следующее сообщение:
Reset DSRM Administrator Password: reset pas on ser dotnet-rc-es Please type password for DS restore Mode Administrator Account: Setting password failed:
WIN32 Error Code: 0x6ba
Error Message: The RPC Server is unavailable
Авторитетное восстановление
При стандартном восстановлении состояния системы “восстанавливаются” объекты, удаленные из базы данных Active Directory. Как только восстановленный контроллер домена на- , чинает репликацию, восстановленные объекты опять перемещаются в контейнер Deleted Ob j е с t s и вся процедура восстановления теряет смысл.
Чтобы восстановить фрагмент Active Directory (например, единственный объект или случайно удаленную организационную единицу) или всю базу данных в случае серьезного повреждения, необходимо обеспечить репликацию объектов и их свойств на другие контроллеры домена, а не наоборот. Для этого используется авторитетное восстановление.
Авторитетное восстановление не является восстановлением как таковым. Оно выполняется после восстановления с ленты и подразумевает указание объектов, которые заменят объекты на других контроллерах домена. Для этого к номеру версии каждого свойства авторитетно восстановленного объекта прибавляется 100 000.
В следующем отчете выполнения команды repadmin показан объект до и после авторитетного восстановления. Атрибут Objectclass не затрагивается при авторитетном восстановлении, поскольку это специальный атрибут, используемый ддя индексации.
До:
Loc.USN Originating DSA
Org.USN
Org.Time/Date
Ver
Attribute
2562 Houston\HOU-DC-01
2562
2001-10-23 21:21.29
1
objectclass
3112 Houston\HOU-DC-01
3112
2001-10-24 09:29.12
2
cn
3112 Houston\HOU-DC-01
3112
2001-10-24 09:29.12
2
sn
2562 Houston\HOU-DC-01
2562
2001-10-23 21:21.29
1
description
2562 Houston\HOU-DC-01
2562
2001-10-23 21:21.29
1
givenName
2562 Houston\HOU-DC-01
2562
2001-10-23 21:21.29
1
instanceType
После (для сокращения удалено время создания час:мин:с):
Loc.USN
Originating DSA
Org.USN
Org.Time/Date
! ver
Attribute
2562
Houston\HOU-DC-01
2562
2001-10-23
1
objectclass
28905
Houston\HOU-DC-01
28905
2001-10-29
100002
cn
28905
Houston\HOU-DC-01
28905
2001-10-29
100002
sn
28905
Houston\HOU-DC-01
28905
2001-10-29
100001
description
28905
Houston\HOU-DC-01
28905
2001-10-29
100001
givenName
28905
Houston\HOU-DC-01
28905
2001-10-29
100001
instanceType
Необходимо соблюдать осторожность при авторитетном восстановлении контекста именования Configuration или всей базы данных Active Directory. Убедитесь, что полностью понимаете последствия перезаписи любого параметра конфигурации системы. Это особенно справедливо при использовании Exchange 2000 или других приложений, зависящих от Active Directory. Не обязательно восстанавливать всю базу данных, если необходимо восстановить одну организационную единицу.
Кто может восстанавливать Active Directory
Если организация имеет распределенную структуру и администраторы работают в различных регионах, может возникнуть вопрос, кто имеет право восстанавливать каталог. Необходимо, чтобы только квалифицированный персонал выполнял восстановление контроллера домена с магнитной ленты. Кроме этого, необходимо обеспечить возможность исправления ошибки без привлечения администраторов центрального офиса.
Восстановление состояния системы (в которое входит база данных Active Directory) требует знания пароля учетной записи Administrator из локальной базы данных SAM на контроллере домена. Это пароль восстановления службы каталогов. Знание этого пароля позволяет выполнить авторитетное восстановление фрагмента или всей базы данных Active Directory, независимо от прав доступа к отдельным ветвям дерева Active Directory. Это связано с тем, что служба Active Directory не работает во время авторитетного восстановления, поэтому система не может принять и обработать аутентификационные данные.
Авторитетное восстановление и контекст именования schema
Контекст именования Schema не поддерживает авторитетное восстановление. Если необходимо восстановить предыдущую копию схемы, можно выполнить стандартное восстановление состояния системы на сервере, выполняющем роль Schema Master. При этом утрачиваются все изменения, которые были внесены в схему после создания резервной копии.
Например, предположим, что установлено новое приложение мониторинга сети, которое вносит изменения в схему Active Directory. После установки обнаружена ошибка в программе, не замеченная при лабораторном тестировании, поэтому принимается решение о ее удалении из схемы. Администратор должен отдельно удалить новые классы и атрибуты с помощью консоли Schema Management. Кроме этого, на сервере, выполняющем роль Schema Master, можно восстановить резервную копию состояния системы, которая была создана до изменения схемы. Восстановление состояния системы на контроллере домена, выполняющем роль хозяина схемы, приводит к перезаписи схемы в пределах всего леса.
Помните об этой возможности Schema Master, восстанавливая на нем резервную копию с ленты. Если не нужно восстанавливать схему, лучше восстанавливать состояние системы на другом контроллере домена.
Необходимо хранить локальный пароль администратора контроллера домена в секрете и часто его менять, но следует помнить, что такие утилиты, как ERD Commander, позволяют любому, кто имеет физический доступ к контроллеру домена, устанавливать локальный пароль администратора и получать полный доступ к системе. Для обеспечения безопасности базы данных Active Directory необходимо выполнять следующие условия.
Право резервного копирования или восстановления состояния системы на контроллере домена должно предоставляться только доверенным администраторам.
Выполняйте резервное копирование состояния системы только на выбранных контроллерах домена. Эти операции должны выполнять самые надежные администраторы в организации.
Не допускайте физического доступа к контроллерам домена в удаленных офисах. Это должны быть серверы без локальной консоли и без приводов компакт-дисков и гибких дисков.
Объясните другим администраторам, что контроллеры домена, как и маршрутизаторы, обслуживаются ограниченным количеством администраторов.
Ограничение на срок службы лент для резервного копирования
Такое происходит время от времени в любой организации. При необходимости выполнить восстановление из резервной копии резервная копия, записанная в последнюю ночь, оказывается недоступной или резервное копирование вообще не запускается. После просмотра библиотеки оказывается, что некоторые ленты настолько стары, что сквозь оксидный слой видно, как через окно, а некоторые качественные ленты застряли и на них вообще ничего не записано. В итоге, когда будет найдена нормальная лента, возраст резервной копии может составить неделю или две. В таком случае возникает вопрос, можно ли восстанавливать базу данных Active Directory с такой ленты.
Хорошей новостью является возможность восстановления состояния системы и с более старой резервной копии без отрицательных последствий для целостности Active Directory. Сразу после восстановления состояния системы и перезагрузки контроллера домена восстановленная копия Active Directory получит обновления от партнеров по репликации и ее информация станет актуальной. С другой стороны, если выполняется авторитетное восстановление, будут потеряны такие внесенные за время с момента последнего резервирования изменения, как сброс паролей, изменения членства в группах, создание новых доверительных
отношений и т.д. Будьте крайне внимательны при использовании старой магнитной ленты для авторитетного восстановления.
Время жизни отметок на удаление
Возможность использования старых резервных копий имеет два ограничения. Первым ограничением является время жизни отметок на удаление (tombstone lifetime) для удаленных объектов Active Directory.
При удалении объекта Active Directory механизм ESE выполняет специальную процедуру над объектом. Объект лишается почти всех атрибутов и помещается в контейнер Deleted Objects, где он хранится в течение 60 дней. По прошествии 60 дней (стандартный интервал хранения отметок на удаление) объект полностью удаляется из базы данных в процессе сборки мусора.
Эго значит, что нельзя восстанавливать System State (а значит, и Active Directory) из резервной копии, существующей более 60 дней. Далее мы рассмотрим пример, из которого станет понятен риск, связанный с таким восстановлением.
Предположим, что из базы данных Active Directory удален объект, после чего база данных восстановлена из резервной копии, созданной ночью. Если не выполнять авторитетное восстановление этого объекта, он будет удален, как только контроллер домена получит все обновления в процессе репликации. В обновлениях контроллеру домена сообщается следующее: “У меня этот объект хранится в контейнере Deleted Ob j ect s. Ты тоже должен его переместить в этот контейнер”.
Но если восстановление выполняется из резервной копии, существующей более 60 дней, партнеры по репликации уже удалили некоторые объекты с отметками на удаление из контейнера Deleted Objects. Поэтому они не в состоянии сообщить восстановленному контроллеру домена об удалении объектов. Такие объекты будут удалены на всех контроллерах домена, кроме только что восстановленного. Это приводит к повреждению базы данных Active Directory.
Помните об этом сроке в 60 дней, выполняя восстановление Active Directory из устаревшей копии. Например, не стоит создавать образы контроллеров домена для восстановления после сбоев. Компакт-диск с образом, который является лучшим другом администратора, станет самым страшным кошмаром на 61-й день после записи образа. Если в качестве стратегии восстановления предполагается использование образов, создавайте образ до повышения сервера до контроллера домена. Восстановите образ и после этого повышайте компьютер до контроллера домена. При этом новая копия Active Directory будет получена от другого контроллера домена в процессе репликации.
Если во время катастрофы будут уничтожены все копии Active Directory, единственной альтернативой станет восстановление самой актуальной копии и внесение всех изменений, которые были внесены после создания резервной копии, например изменений паролей и изменения членства в группах.
Интервал отметок на удаление
По умолчанию в параметрах Active Directory заданы 60-дневный интервал существования отметок на удаление и 12-часовой интервал сборки мусора. Для изменения принятых по умолчанию значений можно добавить атрибуты в объект cn=Directory Service,cn=Windows NT, cn=Services , cn=Configuration,de=<имя_домена>,Ьс=<корень>. Вот эти атрибуты.
Tombstone Lifetime. Минимальное значение составляет 2 дня.
Garbage Collection Interval. Минимальное значение составляет 1 час.
Очень осторожно меняйте интервал существования отметок на удаление. Этот интервал должен быть достаточно большим, чтобы можно было использовать старые резервные копии состояния системы. Никогда не восстанавливайте Active Directory из резервной копии, время создания которой превышает интервал существования отметок на удаление.
Восстановление Active Directory и доверительные отношения
Есть еще одно ограничение по времени на восстановление состояния системы из резервной копии. Если используются внешние доверительные отношения к другим лесам или доменам Windows NT, то для таких доверительных отношений назначаются пароли, изменение которых выполняется каждые 7 дней. При выборе нового пароля старый пароль сохраняется. По этой причине при восстановлении из резервной копии, которой больше 14 дней, необходимо проверить внешние доверительные отношения и запустить принудительный выбор нового пароля. В худшем случае придется удалить и создать доверительное отношение заново.
Авторитетное восстановление и каталог Sysvol
Служба репликации файлов копирует содержимое каталога Sysvol на все контроллеры домена. Если выполнить авторитетное восстановление объектов контейнеров групповых политик в Active Directory без восстановления того состояния каталога Sysvol, в котором он находился в момент создания резервной копии состояния системы, есть вероятность несовпадения между контейнерами групповых политик в базе данных Active Directory и файлами шаблонов групповых политик в каталоге Sysvol.
Не существует авторитетного восстановления каталога Sysvol. Вместо этого необходимо восстановить копию файлов состояния системы, включая файлы из каталога Sysvol, в альтернативную папку и скопировать файлы Sysvol на контроллер домена после авторитетного восстановления и перезагрузки. Последовательность действий такого восстановления рассматривается в процедуре 10.7.
Процедура 10.7. Авторитетное восстановление каталога Sysvol
Выполните стандартное восстановление состояния системы в оригинальный каталог. Не перезагружайте компьютер.
Выполните повторное восстановление состояния системы в альтернативный каталог. При этом сохранятся старые файлы Sysvol, которые будут использованы при перезагрузке. .
Выполните авторитетное восстановление интересующих контейнеров или объектов Active Directory. В список интересующих объектов должны входить групповые политики, иначе нет смысла в сложной процедуре восстановления каталога Sysvol.;
Перезагрузите контроллер домена и убедитесь в обновлении каталога Sysvol от партнер- ров по репликации. Это очень важно. Содержимое каталога Sysvol должно полностью совпадать на всех контроллерах домена.
На авторитетно восстановленном контроллере домена скопируйте содержимое каталога Sysvol из альтернативного каталога. При этом существующие файлы будут перезаписаны. Кроме этого, если необходимо удалить файлы шаблонов групповых политик, можно удалить каталоги Policies и Scripts и скопировать их из альтернативного каталога.
Дождитесь сходимости каталога Sysvol на всех контроллерах домена.
Убедитесь, что клиенты получили правильные групповые политики.
Восстановление состояния системы
При восстановлении состояния системы на компьютере перезаписываются существующие файлы. Многие из файлов являются базами данных и поэтому заблокированы во время работы сервера. Это касается базы данных Active Directory, разделов системного реестра, базы данных сертификатов и т.д.
Это значит, что для восстановления состояния системы необходимо загрузиться в таком режиме, в котором базы данных не будут работать. Для этого используется режим восстановления службы каталога (Directory Service Restore Mode) — один из безопасных режимов за-
пуска операционной системы Windows. Для выбора режима загрузки нажмите клавишу <F8> в меню загрузчика. Если меню загрузчика не выводится, нажмите клавишу <F8> сразу после завершения процедуры POST. Нажатие клавиши будет храниться в буфере клавиатуры до запуска загрузчика NTLDR.
Режим восстановления службы каталога поддерживает загрузку сетевых драйверов для восстановления по сети, но служба Active Directory и другие базы данных не запускаются. Также в этом режиме для переменной среды SAFEBOOT_OPTION устанавливается значение dsrepair. Эта переменная должна быть установлена для выполнения авторитетного восстановления с помощью утилиты Ntdsut i 1.
Так как при загрузке в режиме восстановления службы каталога служба Active Directory недоступна, необходимо ввести пароль администратора, который хранится в локальной базе данных SAM. Этот пароль вводится при повышении сервера до контроллера домена.
Изменение пароля режима восстановления
Если пароль режима восстановления (Restore Mode) был утерян или вы получили сервер без информации о пароле, введенном при запуске утилиты dcpromo, этот пароль можно изменить с помощью программы от компании Sysintemals (www. sysinternals. com), которая называется ERD Commander. Существует две версии этой программы. Бесплатная версия не позволяет менять пароль администратора. Платная — позволяет.
У многих возникает вопрос, как запоминать такие пароли. Автор этой книги записывает их на листок бумаги и закрывает в корпусе сервера. Кроме этого, он помещает внутрь корпуса распечатку снимка экрана с запущенной консолью Disk Management (Управление дисками). Это позволит другому администратору узнать оригинальную структуру разделов в случае отказа сервера.
При регистрации на консоли в безопасном режиме выполните восстановление состояния системы, как описано в процедуре 10.8.
Процедура 10.8. Восстановление состояния системы
Загрузите контроллер домена в режиме восстановления службы каталогов.
Вставьте в привод ленту с резервной копией состояния системы.
Откройте окно командного интерпретатора Run (Выполнить) и введите команду Ntbackup.
Откройте вкладку Restore (Восстановление).
Раскройте дерево, чтобы просмотреть содержимое привода и списка назначенных ранее заданий. После щелчка на пункте, соответствующем устройству копирования на магнитную ленту, может возникнуть пауза из-за перемотки ленты. Если на диске хранится каталог, система может сравнить сигнатуру ленты с сигнатурой в каталоге. Если на диске каталог отсутствует, ленту придется добавить в каталог. Щелкните правой кнопкой мыши на пиктограмме носителя и выберите из контекстного меню пункт Catalog (Каталог).
В дереве каталога ленты установите флажок напротив пункта System State (Состояние системы).
Щелкните на кнопке Restore Now (Восстановить). Будет выдано предупреждение о перезаписи существующих файлов при восстановлении состояния системы, если резервная копия не восстанавливается в альтернативный каталог. Автор не рекомендует восстанавливать состояние системы в альтернативный каталог, так как при копировании вручную придется учитывать слишком много файлов и переменных. Задержите дыхание и разрешите перезапись системных файлов.
Щелкните на кнопке Yes (Да) в открывшемся окне и начинайте восстановление. Откроется окно Restore Progress (Состояние восстановления) и начнется использование устройства копирования на магнитную ленту или привода сменных носителей.
После завершения восстановления щелкните на кнопке Report (Отчет) и просмотрите журнал восстановления, чтобы убедиться в том, что восстановление прошло без ошибок.
Закройте редактор Notepad (Блокнот) и вернитесь в окно Restore Progress (Состояние восстановления). Щелкните на кнопке Close (Закрыть) для завершения восстановления. Будет выдан запрос на завершение работы системы. Не перезагружайте компьютер. Вместо этого щелкните на кнопке No (Нет), чтобы отказаться от перезагрузки, и закройте программу резервного копирования.
На этом этапе восстановление состояния системы можно считать завершенным. Если не требуется восстановление отдельных объектов или контейнеров, можете перезагрузить контроллер домена и разрешить репликацию всех изменений, которые были внесены в период после создания резервной копии. Если необходимо восстановить отдельные компоненты базы данных Active Directory, переходите к следующему разделу.
Авторитетное восстановление Active Directory
/
Поскольку авторитетно восстановленные свойства имеют больший номер версии свойства, чем копии на других контроллерах домена, восстановленные свойства реплицируются на другие контроллеры домена и перезаписывают свойства из других копий. Из-за этого авторитетное восстановление может привести к большому объему передаваемых данных в процессе репликации.
Выполняйте авторитетное восстановление по окончании рабочего дня и обратите особое внимание на контроллеры домена, доступные через внешнее соединение. После завершения подготовки к восстановлению выполните последовательность действий, описанную в процедуре 10.9.
Процедура 10.9. Авторитетное восстановление
Запустите интерпретатор команд.
Запустите утилиту Ntdsutil.
В приглашении Ntdsut 11 введите команду authoritative restore. Откроется приглашение на ввод команды authoritative restore:
authoritative restore: ?
HelpQuitRestore databaseRestore database verinc %dRestore object %sRestore object %s verinc %dRestore subtree %sRestore subtree %s verinc %dHelpQuitRestore databaseRestore database verinc %dRestore object %sRestore object %s verinc %dRestore subtree %sRestore subtree %s verinc %dВывести справочную информацию
Help
Quit
Restore database
Restore database verinc %d
Restore object %s
Restore object %s verinc %d
Restore subtree %s
Restore subtree %s verinc %d
Help
Quit
Restore database
Restore database verinc %d
Restore object %s
Restore object %s verinc %d
Restore subtree %s
Restore subtree %s verinc %d
Вывести справочную информацию
Вернуться в предыдущее меню
Принудительно восстановить всю
'Ъ базу данных
... и не увеличивать номер версии
Принудительно восстановить объект
... и не уйеличивать номер версии
Принудительно восстановить поддерево - ... и не увеличивать номер версии
Введите команду, соответствующую восстанавливаемому компоненту. Необходимо знать характерное имя компонента. Например, чтобы восстановить единственный объект, введите команду restore object cn=BigBoss,ou=Executives,dc=Company,dc=com. Откроется окно сообщения с запросом на подтверждение операции.
Щелкните на кнопке Yes (Да) для запуска авторитетного восстановления. Пример отчета показан ниже:
Opening DIT databaseDone
The current time is 2001-10-29 19:59.32
Most recent database update occurred at 2001-10-29 14:27.52 Increasing version numbers by 10000.
Counting records that need updating
Records found: 000001
Done.
Found 000001 records to update.
Updating records...
Successfully updated 000001 records.
Authoritative Restore completed successfully.
Если восстановление завершится неудачей, то, возможно, база данных повреждена. Попытайтесь выполнить мягкое восстановление. Если это не даст результата, переходите к жесткому восстановлению, (как описано далее в этой главе). Затем попытайтесь повторить авторитетное исправление. Если и в этот раз авторитетное восстановление завершится неудачей, повторите попытку восстановления с ленты еще раз. После этого попытайтесь выполнить восстановление на другом контроллере домена. Если ничего не получилось, обратитесь за советом в службу технической поддержки компании Microsoft.
Завершите работу утилиты Ntdsutil и перезагрузите контроллер домена. После завершения загрузки запустите репликацию вручную.
После распространения изменений на все контроллеры домена восстановленные объекты появятся в оригинальных контейнерах.
Обслуживание каталога
Active Directory, как и любая другая база данных, требует внимания администратора. Иногда в базе данных появляются пустые фрагменты, и необходимо выполнить сжатие. Иногда нужна повторная индексация. Иногда записи базы данных повреждаются, и требуется внести исправления. А иногда база данных полностью разрушается и требует восстановления. Большинство этих задач выполняется с помощью утилиты NT Directory Service Utility, Ntdsutil.
Для некоторых операций утилита Ntdsutil вызывает функции утилиты esentutil, “правнучки” утилиты eseutil, которая была создана для Exchange. Утилита esentutil предоставляет ряд параметров для настройки и управления восстановлением и проверками целостности. Утилита Ntdsutil предоставляет все возможности в виде меню. Чаще всего эта утилита используется для выполнения двух следующих задач.
Сжатие и повторная индексация Active Directory
Восстановление базы данных Active Directory
Сжатие базы данных Active Directory
Опытные администраторы Exchange 5.5 знают, насколько хрупкой может быть база данных ESE. Новый и улучшенный механизм управления базой данных Active Directory не требует такого пристального внимания администратора. Каждые 12 часов процесс сборки мусора удаляет объекты, для которых в течение 60 дней существует отметка на удаление. После этого механизм сборки мусора дефрагментирует и сжимает базу данных. Дефрагментация и сжатие базы данных в автономном режиме не требуются.
При выполнении дефрагментации в автономном режиме с помощью утилиты Ntdsutil утилита сжимает базу данных, копируя содержимое в новую копию файла Ntds. dit во вре-
менном каталоге. После этого новый файл можно скопировать поверх старого или сообщить системе, где искать новую копию. Файлы журналов после этого будут недействительны и могут быть проигнорированы.
Единственный случай, когда необходимо выполнять дефрагментацию в автономном режиме, — восстановление свободного дискового пространства, занятого файлом Ntds. dit. При дефрагментации в интерактивном режиме (online) выполняется сжатие базы данных, но дисковое пространство не освобождается. Дефрагментация базы данных в автономном режиме описывается в процедуре 10.10.
Процедура 10.10. Дефрагментация базы данных Active Directory в автономном режиме
Загрузите контроллер домена в режиме восстановления службы каталогов (DS Repair Mode) и запустите утилиту Ntdsutil.
В приглашении Ntdsut i 1 введите files. Откроется приглашение file maintenance.
Введите команду compact to <каталог>, где вместо <каталог> необходимо ввести имя временного каталога, в котором будет храниться сжатая версия файла Ntds. dit. Результат выполнения команды показан в следующем листинге: file maintenance: compact to c:\ntdstemp Opening database [Current] Creating dir: c:\ntdstemp Using Temporary Path: C:\ Executing Command: C\Windows\system32\esentutl.exe /d 'b "e:\Windows\NTDS\ntds.dit" /8 /о /1"e:\Windows\NTDS" /s 'b "e:\Windows\NTDS" /t"c:\temp\ntds.dit" /110240 /p
Initiating DEFRAGMENTATION mode... Database: e:\Windows\NTDS\ntds.dit Log files: e:\Windows\NTDS System files: e:\Windows\NTDS Temp. Database: c:\temp\ntds.dit
Defragmentation status (% complete)
010 20 30 40 50 60 70 80 90 100
I- -I- -I- -I- -I- -I- -I- -I- -I- -I- -I
Note:
It is recommended that you immediately perform a full backup
4> of this database. If you restore a backup made before the defragmentation, the database will be rolled back to the
'b state it was in at the time of that backup.
Operation completed successfully in 22.172 seconds
Spawned Process Exit code 0x0(0)
Скопируйте новый файл Ntds.dit в оригинальный каталог NTDS. При необходимости можно оставить новый файл на месте и перенаправить на него указатели:
Set Path Backup <каталог>
Set Path DB <каталог>
Set Path logs <каталог>
Set Path working dir <каталог>
Если журналы обычно хранятся на другом диске, оставьте соответствующий указатель без изменений.
Восстановление базы данных Active Directory
Если механизм ESE сталкивается с проблемой из-за повреждения страниц в базе данных, повреждения индексного файла или комбинации обоих повреждений, может потребоваться восстановление базы данных. Симптомы таких проблем включают в себя записи журнала событий, ошибки в работе консоли или перезагрузки с сообщениями об ошибках в работе службы LSASS (Local Security Authority Subsystem).
Восстановление базы данных Active Directory выполняется в два этапа.
■ Мягкое восстановление. На этом этапе записи базы данных восстанавливаются с помощью журналов и файлов контрольных точек. После этого перестраиваются индексы.
■ Жесткое восстановление. На этом этапе выполняется такое же восстановление, как и на предыдущем, но, кроме этого, удаляются поврежденные страницы. Это может привести к потере данных, поэтому не выполняйте жесткого восстановления, кроме случаев, когда нет альтернативы. Всегда перед восстановлением базы данных необходимо создать резервную копию.
Оба этапа требуют перезагрузки в режиме восстановления каталога (Directory Services Restore). Для восстановления выполните последовательность действий, описанную в процедуре 10.11.
Процедура 10.11. Мягкое восстановление Active Directory
Откройте окно интерпретатора команд.
Запустите утилиту Ntdsutil.
В приглашении введите команду files. Откроется приглашение file maintenance.
Введите команду recover. Ниже показан пример результата выполнения этой команды:
Executing Command: C\Windows\system32\esentutl.exe /г /8 /о /1
Ч>"e:\Windows\NTDS" /з"е:\Windows\NTDS" /!10240
Initiating RECOVERY mode...
Log files: e:\Windows\NTDS
System files: e:\Windows\NTDS
Performing soft recovery...
Operation completed successfully in 6.985 seconds.
Spawned Process Exit code 0x0(0)
If recovery was successful, it is recommended you to run
'b semantic database analysis to insure semantic database
'b consistency as well.
Как видите, операция выполняется достаточно успешно, если с базой данных все в порядке. Если обнаружена проблема, система попытается ее решить. После этого средствами утилиты Ntdsut il необходимо выполнить процедуру семантического анализа базы данных (Semantic Database Analysis), в результате которой будут проверены и/или исправлены внутренние ссылки базы данных.
Если в результате мягкого восстановления проблему устранить не удалось, может потребоваться жесткое восстановление. Однако предварительно обратитесь в службу технической поддержки компании Microsoft. Специалисты Microsoft могут предложить другие, не такие кардинальные, решения. Если жесткое восстановление все-таки потребовалось, выполните последовательность действий, описанную в процедуре 10.12.
Процедура 10.12. Жесткое восстановление базы данных Active Directory
Запустив утилиту Ntdsutil, в приглашении на ввод команды file maintenance введите команду repair. Пример отчета о выполнении этой команды выглядит следующим образом: Opening database [Current] Executing Command: C\Windows\system32\esentutl.exe /р 'Ъ "e:\Windows\NTDS\ntds.dit" /110240 /8 /v /х /о
Initiating REPAIR mode...
Database: e:\Windows\NTDS\ntds.dit Temp. Database: REPAIR.EDB got 3910 buffers checking database header forcing database to consistent state checking database integrity <<результат выполнения проверки целостности был удален>> integrity check completed Warning:
You MUST delete the logfiles for this database
Note:.
It is recommended that you immediately perform a full 'b backup of this database. If you restore a backup made 'b before the repair, the database will be rolled back to *^ the state it was in at the time of that backup.
Operation completed successfully in 4.336 seconds. Spawned Process Exit code 0x0(0)
Если во время восстановления обнаружена ошибка, сообщение записывается в журнал repair. txt, который расположен в каталоге \Windows\NTDS рядом с файлом Ntds. dit. Кроме этого, необходимо проверить сообщения в журнале событий.
Выполните полное восстановление файлов состояния системы. Процедура восстановления описывалась в разделе “Резервное копирование каталога” этой главы.
Перемещение файлов поддержки Active Directory
При повышении контроллера домена можно указать расположение основного файла Active Directory, Ntds. dit, и расположение файлов журнала. Если для повышения производительности файлы журнала необходимо переместить на другой жесткий диск или переместить их с системного диска, где они хранятся по умолчанию, расположение файлов можно изменить.
Для перемещения файлов необходимо загрузиться в режиме восстановления каталога. Для этого нужно знать пароль локального администратора, который также называется паролем восстановления каталога. Файлы всегда необходимо копировать в файловую систему NTFS, поскольку она предоставляет необходимую безопасность и производительность при произвольном доступе. Последовательность действий по перемещению файлов описывается в процедуре 10.13.
Процедура 10.13. Перемещение файлов Active Directory
Загрузитесь в режиме восстановления Active Directory..
Откройте интерпретатор команд.
Запустите утилиту Ntdsutil.
Введите команду files, чтобы получить доступ к приглашению на ввод команды files maintenance. Введите ?, чтобы отобразить список доступных команд.
file maintenance: ?
- Вывести справочную информацию
Compact to %s
- Сжать базу данных в указанный каталог
Header
- Создать дамп заголовка базы данных Jet
Help
- Вывести справочную информацию
Info
- Показать информацию о файлах службы DS
Integrity
- Проверить целостность Jet
Move DB to %s
- Переместить БД в указанный каталог
Move logs to %s
- Переместить файлы журналов в 'Ъ указанный каталог
Quit
- Вернуться в предыдущее меню
Recover
- Выполнить мягкое восстановление БД
Set path backup %s
- Задает путь к текущему каталогу 'Ъ резервного копирования
Set path DB %s
- Задает путь к файлам БД
Set path logd %s
- Задает путь к каталогу журналов
Set path working dir
%s - Задает путь к рабочему каталогу NTDS
5. Воспользуйтесь командой move db to %s или move logs to %s для перемещения базы данных или журнала. Вместо %s укажите полное имя файла, например D: \Windows\ NTDS.
В следующей главе
На этом заканчивается обзор Active Directory. Мы рассказали, как планировать, реплицировать, развертывать и обслуживать Active Directory, а также управлять ею в различных ситуациях. Теперь можно использовать полученную информацию. В следующих главах рассматриваются зависящие от работы Active Directory распределенная система безопасности, групповые политики и инфраструктура открытых ключей.
11
Безопасность доступа по сети и протокол Kerberos
К
огда-то автор этой книги работал администратором в компании, которая обслуживала центры приема звонков телезрителей, желающих приобрести разрекламированный по телевизору товар. Время от времени на пульт поступали звонки от осторожных покупателей, знающих о правилах обеспечения безопасности по сети. Как это можно было понять? Например, покупатель задавал следующие вопросы: “Откуда мне знать, что вы тот, за кого себя выдаете?”, “Откуда мне знать, что вам разрешено продавать мне это?” и “Могу ли я записать этот звонок?”.
Все эти вопросы указывают на то, что покупатель знает три принципа сетевой безопасности.
Аутентификация
Авторизация
Учет (аудит)
На заметку нашим читателям: агент по продажам обычно реагирует на подобные звонки, просто вешая трубку и переключаясь на менее образованного покупателя. Это доказывает, что подготовка в области информационных технологий имеет свои преимущества в реальном мире.
В этой главе рассматривается реализация трех принципов сетевой безопасности в операционной системе Windows Server 2003. В главе 18, “Управление инфраструктурой открытого ключа”, рассматриваются дополнительные вопросы, связанные с безопасностью на основе инфраструктуры открытого ключа (PKI).
Новые возможности операционной системы Windows Server 2003
Усовершенствования системы безопасности Windows Server 2003 предоставляют расширенные функциональные возможности и позволяют обеспечить защиту традиционно уязвимых мест. Можно выделить следующие усовершенствования.
Новые стандартные учетные записи. Новые учетные записи Local Service и Network Service позволяют удалить некоторые службы из привилегированного контекста безопасности Local System.
Эти учетные записи используются службой IIS^ (Internet Information Services) и предоставляют возможность управления Web-сайтом непривилегированной учетной записи.
Анонимный вход в систему. Новые правила обработки попыток анонимного входа в систему повышают безопасность операционной системы Windows Server 2003 по отношению к программам сканирования запущенных на компьютере служб NetBIOS. Права доступа для группы Everyone больше не предоставляются в виде маркера доступа при анонимном входе в систему.
Кэширование аутентификационных данных. Теперь существует возможность сохранения альтернативных имен и паролей, которые могут использоваться при отсутствии доступа к серверу аутентификации. Это упрощает управление серверами в демилитаризованной зоне, а также другими отдельно работающими серверами.
Уменьшение объема передаваемых данных от сервера, выполняющего роль PDC Emulator. Если контроллер домена не является хозяином роли PDC Emulator и получает неправильные аутентификационные данные от пользователя, он локально кэширует результаты для сокращения объема данных, передаваемых PDC Emulator. По умолчанию пользователь имеет до 10 попыток ввода аутентификационных данных. После этого пользователю отказывается в доступе с помощью кэшированных данных в течение 10 минут.
Обработка сброса пароля. В операционной системе Windows 2000 неавторизованный сброс пароля приводил к получению доступа к криптографическим элементам системы, компрометации зашифрованных файлов и безопасной электронной почты. Операционная система Windows Server 2003 защищает криптографические структуры от неавторизованного изменения паролей.
Восстановление потерянных паролей. Новая возможность Password Reset Disk позволяет получить доступ к изолированному серверу даже в случае утери локального пароля.
Упрощенные доверительные отношения между сферами Kerberos. Операционная система Windows Server 2003 предоставляет новые методы для создания транзитивных доверительных отношений между сферами MITv5 Kerberos, что значительно упрощает интеграцию сфер с открытым исходным кодом и доменов Windows.
Идентификация личности. Операционная система Windows Server 2003 требует подписи всех пакетов LDAP и SMB, которые отправляются контроллерам домена и обычным серверам. Эта возможность требует использования клиентов более новых версий.
Блокировка Internet Explorer. Операционная система Windows Server 2003 предоставляет новую возможность, которая называется Internet Explorer Enhanced Security Configuration. Эта служба требует явно указывать доверенные сайты. Кроме этого,- все параметры безопасности Internet Explorer установлены равными High. Для узлов в пределах сети необходимо вручную установить менее жесткие требования безопасности.
Синхронизация паролей в разнородных сетях. В операционной системе Windows Services 2003 R2 с целью упрощения взаимодействия с системами под управлением UNIX создан новый компонент — Password Synchronization. Этот компонент позволяет выполнять синхронизацию паролей между отдельными учетными записями на компьютерах под управлением Windows или синхронизацию паролей целого домена Active Directory для хоста под управлением UNIX или для всех компьютеров в домене NIS. При такой синхронизации один набор учетных записей может использоваться на различных платформах. Для активизации Password Synchronization службы синхронизации паролей должны быть установлены на всех контроллерах домена.
Архитектура безопасности операционной системы Windows Server 2003
Желательно составить полное представление о том, как работают вместе различные элементы системы безопасности Windows Server 2003. Это помогает проектировать безопасные системы и диагностировать проблемы по мере их появления. На рис. 11.1 показаны основные компоненты системы безопасности, которая называется Local Security Authority, или LS А.
Рис. 11.1. Схема взаимодействия компонентов службы Local Security Authority
Рассмотрим несколько самых важных элементов схемы.
Аутентификация выполняется с помощью использующих пароли транзакций по протоколу Kerberos или по классическому протоколу NT LanMan (NTLM) по схеме “запрос - ответ”. Система безопасности также поддерживает механизмы обеспечения безопасности от сторонних производителей, которые не зависят от паролей, например смарт-карты, и позволяет устанавливать дополнительные модули, например системы аутентификации по биометрическим показателям.
Для обеспечения авторизации ресурсы защищаются специальными структурами данных, которые называются дескрипторами безопасности (security descriptors). По дескрипторам безопасности определяются пользователи, которым разрешен доступ к ресурсу, а также возможные операции с ресурсом. Все процессы идентифицируются маркерами доступа (access tokens), которые определяют контекст безопасности пользователя.
В системе безопасности аудит обеспечивается благодаря специальным функциям, позволяющим протоколировать доступ к объектам системы безопасности.
Служба LSA состоит из привилегированных служб режима ядра, которые выполняются в контексте Windows Executive, и служб непривилегированного (пользовательского) режима, которые управляют клиент/серверными процессами, например интерактивной аутентификацией и предоставлением разрешений на доступ по сети. Службы безопасности непривилегированного режима в составе LSA содержатся в двух выполняемых файлах: Local Security Authority Subsystem (LSASS) и Winlogon. LSASS включает в себя следующие компоненты.
Центр распространения ключей Kerberos. Эта служба обеспечивает аутентификацию по протоколу Kerberos и предоставляет билеты. База данных Active Directory используется для хранения регистрационных данных.
Провайдер поддержки безопасности NTLM. Эта служба предоставляет классическую аутентификацию по протоколу WindowsNT и управление системой безопасности. Поддерживает все клиенты более ранних версий, а также клиенты Windows, которые не являются членами домена.
Диспетчер учетных записей безопасности (SAM). Эта служба отвечает за получение регистрационных данных пользователей из базы данных Security Account Manager (SAM) в ответ на запрос устаревшего провайдера NTLM.
Netlogon. Эта служба поддерживает классическую аутентификацию по протоколу Windows NT, реализуя сквозную аутентификацию от клиентов более ранних версий. Служба Netlogon не используется для поддержки транзакций Kerberos. В контроллерах домена Active Directory служба Netlogon отвечает за регистрацию записей DNS.
IPSec. Эта служба управляет политиками установки соединений IP Security (IPSec) и IPSec Internet Key Exchange (IKE).
Protected Storage (Защищенное хранилище). Эта служба отвечает за шифрование и безопасное хранение сертификатов, связанных с подсистемой PKI.
Компоненты LSA
Процесс покупки стереосистемы в сети магазинов Best Buy или Circuit City можно представить в виде последовательности транзакций между покупателем и продавцом. Продавец принимает кредитную карту, пропускает ее через компьютер, который сверяет ее данные с данными в базе данных на другом конце света, вы расписываетесь в документе о продаже, и продавец упаковывает покупку для транспортировки.
Если создать формальную блок-схему процедуры покупки, можно будет выявить стандартные элементы безопасности: аутентификацию, авторизацию и аудит. Любой из элементов может реализовываться отдельно, не оказывая влияния на другие элементы. Например, если попытаться расплатиться не кредитной карточкой, а чеком, то на этапе “аутентификации” у покупателя придется потребовать документ, удостоверяющий личность.
При доступе к защищенным ресурсам на сервере пользователь сталкивается с такими же транзакциями безопасности. Управление этими транзакциями реализовывается с помощью пакетов (packages). Существует два типа пакетов: пакеты аутентификации (authentication packages) и пакеты системы безопасности (security packages).
Пакеты аутентификации
Как несложно догадаться, пакет аутентификации подтверждает личность пользователя. Компания Microsoft предоставляет два типа пакетов аутентификации.
Kerberos-пакеты. Трехсторонний механизм аутентификации, в котором сервер использует секретный ключ, предоставленный доверенным источником для идентификации личности клиента.
Пакеты MSV1_O. Устаревшие пакеты аутентификации для систем WindowsNT. Часто этот механизм называют “запрос-ответ" (challenge-response), поскольку он предполагает отправку зашифрованного случайного числа, которое называется запросом (challenge). Операционная система Windows Server 2003 поддерживает механизм LanMan (LM) Challenge- Response для клиентов под управлением операционных систем Windows 3.11, Windows Эх и Windows Me и механизм NT LanMan (NTLM) Challenge-Response для клиентов Windows NT и современных клиентов под управлением Windows, которые не являются членами домена.
Классические базы данных системы безопасности
Механизм аутентификации NTLM исйользует информацию из системного реестра, которая хранится в трех базах данных.
Builtin. Эта база данных содержит две принятые по умолчанию учетные записи, Administrator и Guest, а также различные принятые по умолчанию группы, например Domain Users для доменов и Power Users для рабочих станций и изолированных серверов. Учетные записи Administrator и Guest не могут быть удалены, но могут быть переименованы. Для встроенных групп предоставляются специальные системные привилегии. Они не могут быть переименованы или удалены. Встроенные учетные записи хранятся в разделе системного реестра SAM.
Security Account Manager (SAM). В этой базе данных хранятся локальные учетные записи пользователей и групп. В классической операционной системе Windows NT в базе данных SAM на основном контроллере домена хранятся элементы системы безопасности для всего домена. База данных SAM хранится в разделе системного реестра SAM.
LSA. В этой базе данных хранятся правила назначения паролей, системные политики и доверенные учетные записи для компьютера. База данных LSA хранится в разделе системного реестра Security. Также в этом разделе хранится копия базы данных SAM.
При модернизации классического основного контроллера домена (PDC) до Windows Server 2003 большая часть содержимого баз данных системного реестра переносится в Active Directory. Системные привилегии и права пользователей, которые определяются в классической базе данных LSA, заменяются набором групповых политик, которые хранятся в базе данных Secedit. sdb в каталоге \Windows\Security\Database.
Пакеты системы безопасности
В пакете системы безопасности содержатся протоколы и возможности, необходимые для управления доступом, защиты данных и обеспечения безопасности потоков между клиентами и серверами.
Пакеты системы безопасности иногда называются провайдерами поддержки безопасности (Security Support Provider — SSP). Приложения, которые используют службы безопасности, могут не знать особенностей этих провайдеров. Чтобы устранить зависимость от функций поставщиков безопасности, используется единый интерфейс Security Support Provider Interface (SSPI). Это напоминает абстрагированный интерфейс доступа к базам данных Open Database Connectivity (ODBC) или абстрагированный доступ к сетевым адаптерам, реализованный с помощью интерфейса Network Device Interface Specification (NDIS).
В составе операционной системы Windows Server 2003 компания Microsoft предоставляет следующие пакеты системы безопасности.
Kerberos. Протокол Kerberos занимает особое место, так как он является одновременно и пакетом аутентификации, и пакетом системы безопасности. В качестве пакета системы безопасности он поддерживает доступ приложений, которые предоставляют билет КегЬе-
ros при попытке доступа к ресурсам. Это так называемые приложения, поддерживающие работу с использованием протокола Kerberos. В качестве примера такого приложения можно назвать службу сетевой файловой системы CIFS/SMB в операционных системах Windows Server 2003 и Windows 2000. (SMB расшифровывается как Server Message Block. Это командный язык, который используется в сетях Windows. CIFS расшифровывается как Common Internet File System. Это еще один синоним SMB.)
NTLM. Этот пакет поддерживает подключение клиентов Windows более старых версий и изолированных компьютеров под управлением Windows Server 2003, Windows 2000 и Windows ХР.
Digest. Это реализация документа RFC 2617, “HTTP Authentication: Basic and Digest Access Authentication”, от компании Microsoft. Пакет Digest также поддерживает аутентификацию Digest в протоколе Simple Authentication and Security Layer (SASL), который определен в документе RFC 2831, “Using Digest Authentication as a SASL Mechanism”. Новая версия пакета Digest в операционной системе Windows Server 2003 поддерживает использование хешированного пароля MD4 для шифрования вызова, что позволяет отказаться от обратимых паролей.
Schannel. Этот пакет содержит протоколы безопасности, необходимые для поддержки частной защищенной связи через Web, а также следующие протоколы безопасности: Transport Layer Security (TLS), Secure Sockets Layer (SSL) и Private Communications Technology (PCT).
Negotiate. Этот псевдопровайдер не содержит протоколов безопасности. Вместо этого пакет позволяет клиентам обнаруживать доступные пакеты безопасности и принимать решение об использовании одного из пакетов. Например, приложение, поддерживающее Kerberos и вызывающее пакет Negotiate, будет перенаправлено на применение пакета Kerberos.
Кроме основных пакетов безопасности, в состав операционной системы Windows включены следующие пакеты (не показаны на рис. 11.1).
Стандартная аутентификация на основе дайджеста
Аутентификация на основе открытого пароля
Распределенная аутентификация на основе пароля (для поддержки MSN)
Аутентификация MSN старого типа
Winlogon
LSA нуждается в механизме получения аутентификационных данных пользователей. За получение таких данных отвечает приложение Winlogon. Доступ к Winlogon предоставляется при нажатии комбинации клавиш <Ctrl+Alt+Del>, которая называется Secure Attention Sequence (SAS).
При этом открывается окно Security (Безопасность), которое также управляется приложением Winlogon. Если аутентификация еще не была проведена, в окне отображаются поля для ввода аутентификационных данных. Если аутентификация уже завершена, в окне Security (Безопасность) предоставляется возможность завершения сеанса, завершения работы компьютера, блокировки компьютера, изменения пароля или запуска Task Manager (Диспетчер задач).
Все окна, отображаемые приложением Winlogon, предоставляются динамической библиотекой Graphical Identification and Authentication (GINA). Независимые производители программного обеспечения могут создавать собственную библиотеку или вносить улучшения в библиотеку GINA для получения возможности ввода собственных регистрационных данных. Например, клиент Novell NetWare устанавливает собственную библиотеку GINA, которая собирает дополнительные аутентификационные данные для службы каталогов Novell.
Монитор ссылок безопасности
Если представить домен или сервер в виде крепости, в которой пакеты аутентификации выступают в роли охранников ворот, то монитор ссылок безопасности можно представить в виде штата телохранителей, которые охраняют посетителей внутри крепости.
Совет по использованию системного реестра: пакеты безопасности
Список провайдеров поддержки безопасности хранится в разделе системного реестра HKLM\System\CurrentControlSet\Control\Securityproviders.
Управляющие параметры LSA и соответствующие провайдеры поддержки безопасности хранятся в разделе системного реестра HKLM\System\CurrentControlSet\Control\LSA.
Операционная система Windows предоставляет раздельные системы защиты для таких объектов, как файлы и папки NTFS, записи системного реестра, объекты Active Directory, принтеры, службы и процессы ядра. Это достигается с помощью установки привязки каждого объекта со специальной структурой, которая называется дескриптором безопасности (security descriptor). Дескриптор безопасности содержит список контроля доступа (Access Control List — ACL). В этом списке указываются пользователи, компьютеры и группы, которым разрешен или запрещен доступ к объекту.
При регистрации пользователя служба LSASS создает маркер доступа (access token), который используется в качестве “пропускной карточки” пользователя для системы безопасности. Этот маркер содержит идентификатор безопасности пользователя, а также идентификаторы безопасности всех групп, в которые входит пользователь, и различные параметры безопасности, например время устаревания аутентификации и требования к сложности пароля.
Как только принадлежащий пользователю процесс пытается обратиться к объекту системы безопасности, монитор ссылок безопасности (SRM — Security Reference Monitor) сравнивает идентификаторы безопасности в дескрипторе безопасности с идентификаторами безопасности в пользовательском маркере доступа. На основании полученной информации вычисляются права доступа пользователя.
Маркеры доступа, как и политики, всегда являются локальными. Они не сопровождают пользователей по сети. При подключении к серверу служба LSASS на сервере должна создать локальный маркер доступа, который соответствует учетной записи пользователя. Устанавливается привязка созданного маркера с процессами, запущенными этим пользователем. Служба LSASS получает необходимую для создания локальных маркеров доступа информацию двумя способами.
Для аутентификации по протоколу Kerberos информация извлекается из поля Authorization Data (Данные авторизации) в предоставленном клиентом билете сеанса доступа Kerberos.
Для аутентификации NTLM информация предоставляется контроллером домена в результате транзакции сквозной аутентификации.
Важно защищать информацию, которая используется для создания маркеров доступа. Если злоумышленник способен похитить маркер доступа или другим способом скомпрометировать механизм создания маркеров доступа, то вся система защиты на основе механизма аутентификации теряет свое значение — злоумышленник все равно получит доступ.
Обзор работы LSA
Рассмотрим подробнее описанные ранее компоненты системы безопасности, а также их взаимодействие для реализации трех принципов безопасности — аутентификации, авторизации и аудита.
Служба Winlogon получает аутентификационные данные пользователя.
Служба LSASS получает аутентификационные данные и использует их для подтверждения личности пользователя с помощью механизмов Kerberos или NTLM (с помощью MSV1_O). Это этап аутентификации.
Служба LSASS создает маркер доступа, который определяет права доступа пользователя и привилегии работы в системе.
Монитор ссылок безопасности сравнивает этот маркер со списком контроля доступа в дескрипторе безопасности объекта. На основе результата сравнения принимается решение о предоставлении доступа. Это этап авторизации.
Наконец, служба LSASS и монитор ссылок безопасности совместно отслеживают доступ к объектам безопасности и создают отчеты, в которых записываются все или некоторые события доступа. Это этап аудита.
Теперь рассмотрим отличительные особенности компонентов безопасности, обратив особое внимание на параметры настройки и потенциально уязвимые места.
Компоненты системы безопасности
Система безопасности операционной системы Windows основана на нескольких фундаментальных элементах. Важно понять, как связаны различные элементы и как они работают вместе. Это даст основу для оценки практических вариантов обеспечения безопасности. В этом разделе рассматриваются следующие элементы.
Маркеры доступа
Идентификаторы безопасности
Дескрипторы безопасности
Списки контроля доступа
Пароли
Маркеры доступа
Информация в маркере доступа определяет права доступа и привилегии.
Разрешения. Маркер доступа содержит всю необходимую информацию, на основе которой система оценивает список ресурсов, к которым пользователь может получить доступ, и список действий, которые разрешены пользователю для этих ресурсов.
Привилегии. Маркеры доступа содержат список прав, определяющий системные вызовы, которые может вызывать пользователь. Например, пользователь, обладающий привилегией SeBackupPrivilege, способен запускать процессы, которые используют системные функции резервного копирования.
Просмотр содержимого маркеров доступа
Чтобы получить дополнительную информацию о маркерах доступа, рекомендую обратить внимание на книгу Джеффри Рихтера (Jeffrey Richter) и Джейсона Кларка (Jason D. Clark) Programming Server-Side Applications for Windows 2000 (Программирование серверных приложений для Windows 2000). Не дайте названию обмануть вас. Книга окажется полезной даже тем, кто не написал ни одной строки кода. Книга продается вместе с компакт-диском, на котором присутствует несколько полезных утилит. Одна из утилит, Tokenmaster, позволяет предоставить содержимое маркера доступа для любого запущенного на сервере процесса.
В табл. 11.1 рассматривается содержимое маркера доступа. По этой информации можно составить представление о том, какими сведениями руководствуется система для принятия решений при обеспечении безопасности.
Таблица 11.1. Элементы маркера доступа и их назначение
Элемент
Назначение
Идентификатор безопасности пользователя (SID)
Система безопасности выполняет идентификацию пользователя по номеру, а не по имени, как это делает служба социального страхования. Идентификатор безопасности является комбинацией относительного идентификатора, пользователя (RID) и идентификатора безопасности (SID) домена или (в случае локальной регистрации) идентификатора безопасности компьютера
Идентификаторы безопасности групп
Идентификаторы безопасности (SID) каждой группы, в которую входит пользователь. Это касается как групп в домене, так и групп на локальном компьютере, на котором зарегистрировался пользователь
Регистрационный идентификатор безопасности
Уникальный и временный идентификатор безопасности, который соответствует отдельному сеансу работы в системе. Если пользователь устанавливает несколько соединений с сервером, например, с нескольких компьютеров, то каждому сеансу присваивается отдельный регистрационный идентификатор безопасности
Привилегии пользователя
Существуют системные привилегии, которые предоставляют возможность менять системное время, создавать резервную копию и т.д.
Принятый по умолчанию идентификатор безопасности владельца
Этот идентификатор безопасности используется для указания владельца любого объекта системы безопасности. Кроме членов группы Administrators, для всех пользователей этот идентификатор совпадает с идентификатором безопасности пользователя. Для членов группы Administrators этот идентификатор безопасности совпадает с идентификатором безопасности группы Administrators
Принятый по умолчанию идентификатор безопасности группы
Этот компонент имеет смысл только для подсистем POSIX и Services for Macintosh (SFM). Этот идентификатор безопасности совпадает с идентификатором безопасности основной группы, указанной в атрибутах учетной записи
Принятый по умолчанию список контроля доступа (DACL)
Для каждого объекта в системе создается дескриптор безопасности, который содержит избирательный список контроля доступа. В списке DACL перечислены пользователи, имеющие право доступа к объекту, и способы доступа. Если при создании объекта процесс не указывает содержимое DACL, система использует этот принятый по умолчанию DACL
Исходный процесс
Имя системного процесса, который создал маркер доступа
Тип маркера
При регистрации пользователя на консоли пользователь получает основной маркер доступа. Пользователь, зарегистрировавшийся по сети, получает маркер доступа анонимного режима (impersonation access token)
Уровень заимствования прав
Существует четыре уровня заимствования: Anonymous (Анонимный) — информация о клиенте недоступна; Identification (Идентификационный) — клиент идентифицирован, но не олицетворен; Impersonation (Олицетворенный) — клиент идентифицирован и может запускать локальные процессы, но не может подключаться к другим компьютерам; Delegation (Делегированный) — процессы клиента могут получать доступ к другим компьютерам при аутентификации по протоколу Kerberos
Ограничивающий идентификатор безопасности
Эта возможность, появившаяся в операционной системе Windows 2000, позволяет разработчику блокировать привилегии пользователя без изменения членства пользователя в группах
Разрешения
Как только пользовательский процесс запрашивает доступ к объекту, монитор ссылок безопасности сравнивает идентификаторы безопасности в маркере доступа с идентификаторами безопасности в списке контроля доступа (ACL) этого объекта. Возможны два варианта.
Если совпадение не найдено, пользователь получает отказ в доступе. Это неявный отказ (implicit deny).
Если совпадение найдено, пользователю предоставляется разрешение, связанное с записью в ACL. Это может быть разрешение Allow (Разрешить) или разрешение Deny (Запретить).
Например, разрешение Allow Read (Разрешить чтение), назначенное идентификатору безопасности S-l-1-0 (Everyone), предоставляет любому пользователю возможность чтения содержимого объекта системы безопасности. С другой стороны, разрешение Deny Read (Запретить чтение), назначенное идентификатору безопасности S-l-5-2 (Network Users), запрещает доступ пользователям, которые подключаются к серверу по сети.
Если в этом примере пользователь одновременно является членом групп Everyone и Network Users, ему будет отказано в доступе чтения, поскольку право доступа Deny имеет больший приоритет, чем право доступа Allow, если оба разрешения назначены одному объекту. (Далее будет показано, что унаследованные права доступа обрабатываются немного по-другому.)
Идентификаторы безопасности
Типичный идентификатор безопасности (SID) пользователя выглядит как S-1-5-21- 1683771067-1221355100-624655392-1001. Формат идентификатора безопасности соответствует такому шаблону: S-R-IA-SA-SA-RID. Вот как расшифровывается этот формат.
S — идентификатор SID. Этот идентификатор служит признаком того, что следующее число является идентификатором безопасности, а не простым большим и загадочным числом.
R— номер редакции (revision). Все идентификаторы безопасности, сгенерированные операционной системой Windows, используют номер редакции 1.
ТА — источник выдачи (issuing authority). Практически все идентификаторы безопасности в операционной системе Windows указывают NT Authority номер 5. Исключением являются широкоизвестные группы и учетные записи.
SA — уполномоченный центр (sub-authority). Этот идентификатор определяет специальные группы и функции. Например, число 21 указывает, что идентификатор безопасности был выдан контроллером домена или изолированным компьютером. Большое число, 1683771067-1221355100-624655392, указывает на домен или компьютер, выдавший идентификатор.
RID — относительный идентификатор. Это уникальное порядковое число, присвоенное участнику системы безопасности (например, пользователю, компьютеру или группе) уполномоченным центром (SA).
Функции идентификаторов безопасности
Новичкам в администрировании Windows все эти идентификаторы безопасности и относительные идентификаторы могут показаться игрушками умников, не стоящими внимания. Это ужасное заблуждение. Абсолютно необходимо разбираться в механизме генерации, хранения идентификаторов безопасности и управления ими для грамотного управления системами на основе Windows.
Например, зная, что операционная система использует идентификаторы безопасности для уникальной идентификации пользователя, администратор не удивится возможности менять имя пользователя без влияния на права доступа. Этим можно воспользоваться в ситуации, когда на работу в компанию принимается новый пользователь вместо уволенного сотрудника. Можно просто переименовать старую учетную запись пользователя и сохранить все права доступа и членство в группах.
Знание принципов использования идентификаторов в системе позволяет планировать перемещение учетных записей из одного домена в другой при миграции домена Windows NT или Windows 2000 в домен Windows Server 2003. Например, при копировании пользовательской учетной записи из одного домена в другой с помощью Active Directory Migration Tool (или эквивалентного инструмента от стороннего производителя) пользовательский идентификатор безопасности в домене WindowsNT сохраняется в специальном атрибуте SID History, чтобы пользователь мог получать доступ к ресурсам в старом домене при выполнении аутентификации в новом домене.
Предопределенные идентификаторы безопасности
Не все идентификаторы безопасности используются для учетных записей пользователей, групп или компьютеров. Некоторые идентификаторы безопасности выделены компанией Microsoft для стандартных учетных записей и групп. Это так называемые предопределенные идентификаторы безопасности. Например, при входе в систему с консоли компьютера под управлением операционной системы Windows маркеру доступа присваивается идентификатор безопасности S-1-5-4, который является предопределенным идентификатором безопасности для группы Interactive.
Новые предопределенные идентификаторы безопасности
В классической операционной системе Windows NT и в операционной системе Windows 2000 учетная запись Local System с идентификатором безопасности S-1-5-18 предоставляла возможность использования практически всех служб. Эта учетная запись имеет исключительные привилегии, и ее использование для запуска распространенных служб представляет собой уязвимое место системы безопасности.
В операционной системе Windows Server 2003 предпринята попытка устранить это уязвимое место с помощью двух новых предопределенных идентификаторов безопасности, которые будут предоставлять контекст безопасности для различных служб: Localservice и Networkservice.
Существует два основных преимущества в использовании стандартных учетных записей для запуска служб вместо учетной записи Local System. Первое преимущество заключается в том, что эти учетные записи имеют идентификатор безопасности и, таким образом, могут предоставлять регистрационные данные Kerberos или NTLM при доступе к ресурсам на других серверах. Учетная запись Local System этого делать не может и должна использовать сеанс анонимной регистрации для доступа к сетевым ресурсам.
Второе преимущество связано с инфраструктурой открытого ключа (Public Key Infrastructure — PKI). Новые учетные записи служб могут иметь локальный профиль, а значит, могут получать локальные сертификаты инфраструктуры открытого ключа. Это позволяет идентифицировать службы при использовании в системе цифровых подписей, например при использовании IPSec или безопасной электронной почты.
При сканировании запущенных служб в операционной системе Windows Server 2003 средствами Task Manager (Диспетчер задач) можно обратить внимание на существование двух новых учетных записей для служб, от имени которых запущено несколько фоновых процессов. Несмотря на небольшое количество служб, которые используют новые учетные записи, это только начало. Эти учетные записи особенно полезны для службы IIS, где они используются для управления доступом к рабочим процессам, которым принадлежат Web-сайты.
В табл. 11.2 перечислены предопределенные идентификаторы безопасности и их назначение. Группы и учетные записи, для которых существуют предопределенные идентификаторы безопасности, в пользовательском интерфейсе отображаются специальной пиктограммой с изображением направленной вверх красной стрелки.
Таблица 11.2. Предопределенные идентификаторы безопасности
ИдентификаторНазначение
безопасности
S-1-0-0
Группа, в которой отсутствуют члены. Используется для представления учетной записи с неизвестным идентификатором безопасности. Это так называемый идентификатор безопасности нулевого сеанса. В операционной системе Windows Server 2003 сфера использования идентификатора безопасности нулевого сеанса значительно уменьшилась
s-i-i-o
Идентификатор безопасности для всех пользователей, также известный в операционной системе Windows как группа Everyone. Все пользователи, кроме анонимных, получают его в составе маркера доступа
S-1-2-0
Группа Local. Эта группа определяет пользователей, которые вошли в систему с консоли локального компьютера
S-1-3-0
Группа Creator/Owner (Создатель/Владелец). Используется в качестве знакоместа в ACL. При инвентаризации дескриптора безопасности этот SID заменяется идентификатором безопасности пользователя, создавшего объект
S-1-3-1
Группа Primary. Это значение, заменяющее SID основной группы, к которой принадлежит пользователь, создавший объект. Основные группы пользователя имеют смысл только для подсистем POSIX и Services for Macintosh
S-1-5
NT Authority .
S-1-5-1
Коммутируемый доступ
S-1-5-2
Доступ по сети
S-1-5-3
Пакет
S-1-5-4
Интерактивный доступ
S-1-5-5-#-#
Идентификатор регистрационного сеанса
S-1-5-6
Служба'
S-1-5-7
Анонимная регистрация. Этот SID назначается пользователям, которые не предоставили аутентификационные данные при доступе к системе
S-1-5-8
Proxy (не используется)
S-1-5-9
Контроллеры предприятия. Используется для всех контроллеров домена в пределах леса Active Directory
S-1-5-10
Этот идентификатор безопасности заменяется идентификатором безопасности пользователя, при аутентификации которого был использован особый идентификатор безопасности в маркере' доступа
S-1-5-11
Аутентифицированный пользователь. Добавлен в операционной системе Windows NT 4.0 SP3 для выделения пользователей, которые получили сетевую аутентификацию от группы S-l-1-0 Everyone.
S-1-5-12
Зарезервировано для использования в будущем
S-1-5-13
Пользователи сервера терминалов
S-1-5-14
Удаленная интерактивная регистрация
Идентификатор безопасности
Назначение
S-1-5-15
Идентификатор безопасности для данной организации
S-1-5-18
Группа Local System. Предоставляет контекст безопасности для системных процессов
S-1-5-19
Группа Local Service. Этот SID появился в операционной системе Windows Server 2003. Предоставляет менее привилегированный контекст безопасности для служб, которые управляют локальными процессами
S-1-5-20
Группа Network Service. Этот SID появился в операционной системе Windows Server 2003. Предоставляет менее привилегированный контекст безопасности для служб, которые управляют доступом по сети
S-1-5-21
Неуникальные относительные идентификаторы (RID). Используются в качестве приставки к идентификаторам безопасности домена или рабочей станции
S-1-5-32
Встроенные локальные группы (Bui It in). Этот SID идентифицирует членов базы данных Builtin из базы данных SAM (или контейнера Builtin из базы данных Active Directory). То же самое касается и таких групп, как Administrators и Power Users
S-1-5-1000
Другая организация
S-1-5-64-10
Аутентификация NTLM
S-5-64-14
Аутентификация Schannel
S-5-64-21
Аутентификация Digest
Предопределенные относительные идентификаторы
Относительные идентификаторы назначаются пользователям, компьютерам и группам начиная с числа 1000. Множество относительных идентификаторов между 500 и 999 выделено для представления учетных записей и групп, которые существуют во всех доменах и на всех компьютерах под управлением операционной системы Windows. Это так называемые предопределенные относительные идентификаторы.
Одни предопределенные относительные идентификаторы добавляются к идентификатору безопасности домена для создания уникальных идентификаторов. Другие относительные идентификаторы добавляются к идентификаторам безопасности группы Bui It in, S-l-5-32, что позволяет идентифицировать встроенные учетные записи, которые обладают особыми привилегиями, закодированными в операционной системе или присвоенными в базе данных системы безопасности.
Предопределенные учетные записи и группы можно использовать для управления доступом к ресурсам. Например, прёдположим, что пользователь, использующий компьютер совместно с другими пользователями, желает ограничить доступ к некоторым файлам и каталогам другим пользователям, работающим на этом компьютере. В списке контроля доступа к файлу пользователь может назначить группе Network разрешение Deny Full Control (Запретить полный доступ). Это позволит заблокировать доступ к файлам для всех пользователей, которые подключаются к компьютеру по сети, но сохранит доступ к файлам для локальных пользователей, зарегистрированных на локальной консоли.
В табл. 11.3 перечислены предопределенные относительные идентификаторы и их функции. Доменные идентификаторы безопасности записаны в виде <„.>. Последние несколько записей соответствуют предопределенным относительным идентификаторам безопасности, появившимся в операционной системе Windows Server 2003.
Относительный идентификатор
Назначение
S-l~5-<...>-500
Учетная запись Administrator
S-l-5-<...>-501
Учетная запись Guest.
S-l-5-<...>-502
Учетная запись krbtgt, которая используется для шифрования билетов на получение разрешений Kerberos
S-l-5-<...>-512
Администраторы домена
S-l-5-<...>-513
Пользователи домена
S-l-5-<...>-514
Гости домена
S-l-5-<...>-515
Компьютеры домена*
S-l-5-<...>-516
Контроллеры домена
S-l-5-<...>-517
Издатели сертификатов
S-l-5-<...>-518
Администраторы схемы. Этот идентификатор безопасности указывается в списке контроля доступа для контейнера Schema. Пользователи, которым присвоен этот идентификатор безопасности, имеют право на чтение/запись/ создание объектов в контейнере Schema
S-l-5—<...>-519
Администраторы предприятия. Этот идентификатор указан в списке контроля доступа для'контейнера Configuration и для каждого контейнера Domain в пределах леса. Пользователи, которым присвоен этот идентификатор безопасности, имеют право на полный доступ ко всем объектам в этих контейнерах
S-l-5—<...>-520
Владельцы и создатели групповых политик. Этот идентификатор безопасности указывается в списке контроля доступа для контейнера cn=policies, cn=System в каждом домене. Пользователи, которым присвоен этот идентификатор безопасности, могут создавать новые объекты контейнеров групповых политик
S-l-5-<...>-533
Серверы удаленного доступа и IAS. Этот идентификатор безопасности указывается в контейнере RAS и IAS Servers Access Check. Серверы, которым присвоен этот идентификатор безопасности, могут проверять информацию о пользователях и группах в базе данных Active Directory
S-l-5-32-544
Администраторы
S-l-5-32-545
Пользователи
S-l-5-32-546
Гости
S-l-5-32-547
Опытные пользователи
S-l-5-32-548
Операторы учетных записей
S-l-5-32-549
Операторы сервера
S-l-5-32-550
Операторы печати
S-l-5-32-551
Операторы резервного копирования
S-l-5-32-552
Репликаторы
S-l-5-32-553
Серверы удаленного доступа (RAS-серверы)
S-l-5-32-554
Доступ для компьютеров, работающих под управлением версии Windows до Windows 2000
S-l-5-32-555
Пользователи удаленных рабочих станций (появился в операционной системе Windows Server 2003)
Относительный идентификатор
Назначение
S-1-5-32-556
Операторы настройки сети (появился в операционной системе Windows Server 2003)
S-1-5-32-557
Создатели входящих доверительных отношений между лесами (появился в операционной системе Windows Server 2003)
S-1-5-32-558
Пользователи монитора производительности (появился в операционной системе Windows Server 2003)
S-1-5-32-559
Пользователи журнала производительности (появился в операционной системе Windows Server 2003)
S-1-5-32-560
Windows Authorization Access (появился в операционной системе Windows Server 2003)
S-1-5-32-561
Terminal Server License Servers (появился в операционной системе Windows Server 2003)
Дескрипторы безопасности и списки контроля доступа
Системным администраторам часто приходится принимать решения по предоставлению доступа. Важно понимать, как система реализует такие решения и что дает уверенность в предоставлении пользователям подходящих разрешений.
Все операционные системы Windows, основанные на платформе Windows NT, используют похожий метод контроля доступа для объектов системы безопасности (файлам, каталогам, разделам системного реестра, объектам Active Directory и службам). Для каждого из объектов системы безопасности создана специальная структура, которая называется дескриптором безопасности. На рис. 11.2 показана блок-схема шести компонентов дескриптора безопасности.
Заголовок. В заголовке описывается содержимое дескриптора безопасности. Кроме этого, в заголовке содержится контролирующая структура, которая определяет возможность наследования разрешений от дескриптора безопасности родительского объекта.
Идентификатор безопасности владельца. Кроме администраторов, владельцем объекта является пользователь, который создал объект. Для объектов, созданных любым из членов встроенной группы Administrators, в качестве владельца устанавливается группа Administrators.
Идентификатор безопасности основной группы владельца. Этот идентификатор используется подсистемами POSIX и Macintosh.
Список разграничительного контроля доступа (DACL). В этом списке определены участники системы безопасности, которым разрешен или запрещен доступ к объекту. Изменения в этот список могут вносить владелец и администратор.
Системный список контроля доступа (SACL). Этот список определяет пользователей, которые будут внесены в журнал системой аудита при доступе или при неудачной попытке доступа к объекту. Возможность изменения системного списка контроля доступа должна быть ограничена, чтобы злоумышленник не мог отключить аудит во время несанкционированного доступа.
Рис. 11.2. Блок-схема дескриптора безопасности
Записи контроля доступа
В списке контроля доступа содержится одна или несколько записей контроля доступа (Access Control Entry — АСЕ). Запись контроля доступа состоит из двух компонентов.
Идентификатор безопасности (SID), который представляет участника системы безопасности
Маска доступа (Access Mask), которая определяет разрешения для этого участника безопасности
В табл. 11.4 и 11.5 перечислены разрешения, связанные с каждой записью маски доступа. Эта информация может потребоваться при использовании утилит или сценариев, которые выводят содержимое дескриптора безопасности без его интерпретации.
FILE_READ_DATA
0x1
FILE_WRITE_DATA
0x2
FILЕ_АPPEND-DATA
0x4
FILE_READ_EA
0x8
FILE_WRITE_DATA
0x10
FILE_EXECUTE
0x20
FILE_READ_ATTRIBUTES
0x80
FIL E_WR I TE_ATTR I BUTE S
0x100
READ-CONTROL
0x20000
SYNCHRONIZE
0x100000
Таблица 11.4. Маски доступа и их функции
Универсальные маски доступа
Маска
Назначение
0x10000
Delete (относится ко всему объекту, включая дескриптор безопасности)
0x20000
Read_Control (чтение дескриптора безопасности)
0x40000'
Write_Dac (изменение дескриптора безопасности)
0x80000
Write_Owner (смена владельца)
0x100000
Synchronize (разрешение уровня процесса)
Таблица 11.5. Специализированные маски доступа
Маска
Файл
Папки
Разделы системного реестра
Объекты Active Directory
Объекты служб
0xlRead_
Data
List— '
Directory
Query_
Value
Create—Child
Query_Config
0x2Write_ Data
Add_
File
Set_
Value
Delete_Child
Change_Config
0x4Append_
Data
Add_ Subsidiary
Create_ Subkey
Actrl—DS_List
Query_Status
0x8Read_EA
Read_EA
Enumerate—
Subkey
Self
Enumerate—
Dependencies
0x10
Write_EA
Write_EA
Notify
ReadProperties
Start
0x20
Execute
Traverse
Create_Link
WriteProperties
Stop
0x40
Нет
DeleteChild
Her
Delete_Tree
Pause/Continue
0x80
ReadAttributes
Read
Attributes
Нет
List-Object
Interrogate
0x100
Write_
Attributes
Write
Attributes
Нет
Control
Access
User_Defined_ Control
Маска доступа в записи контроля доступа является суммой всех разрешений, которые предоставлены пользователю, указанному в записи контроля доступа. Рассмотрим пример использования маски доступа. Предположим, что локальной группе Administrators (идентификатор безопасности — S-1-5-32-544) было предоставлено разрешение читать и запускать файл. Маска записи контроля доступа в данном случае будет иметь вид 1021BF. При выводе записи в ACL Editor редактор рассчитывает составляющие разрешения и выводит их в удобном для чтения формате.
Просмотр и изменение записей контроля доступа
На вкладке Security (Безопасность) в окне свойств объекта выводится окно редактора ACL Editor. В этом редакторе доступно несколько различных вариантов отображения дескриптора безопасности. В первом варианте, показанном на рис. 11.3, отображается общий список записей контроля доступа и соответствующих универсальных разрешений на доступ.
Если записи контроля доступа не присвоены универсальные разрешения, список разрешений будет содержать флажки в группе Special Permissions (Специальные разрешения).
Щелкнув на кнопке Advanced (Дополнительно), можно получить более подробную информацию о дескрипторе безопасности, как показано на рис. 11.4.
Ji*lJi*lВ этом окне отображается каждая запись контроля доступа из списка разграничительного управления доступом (DACL) с соответствующими правами доступа. Если выделить запись и щелкнуть на кнопке Edit (Изменить), в ACL Editor будет показан полный набор прав доступа для записи контроля доступа (рис. 11.5). Если для записи контроля доступа было задано несколько отдельных прав доступа, необходимо воспользоваться окном Edit для просмотра конкретного разрешения.
Ji*l
Ji*l
George W. Bush Properties
Emirorwwrt j SetMom] Renetearta] ТатМ$«исмМ1в| COM*Ganta | Adrtwi ] Accou*| Ml» | telephone* | OtganeabonPub6shedCer*catee | Maeta 01 | Di*n | Ohect Sect*
Grouper имг name*:•
fl Authenticated Users
0 Cert Publishers (COMPANYSCert Pubishers) fl CREATOR OWNER.
ml | Remove |
Pemtaomfai Account Operator*Pemtaomfai Account Operator*Ful ControlReadCreate AH Child ObjectsDelete Al Child Objects Change PasswordFul ControlReadCreate AH Child ObjectsDelete Al Child Objects Change PasswordAlowDeny“0□^1в□J0□0□0□0□JAlowDeny“0□^1в□J0□0□0□0□J
Pemtaomfai Account Operator*
Pemtaomfai Account Operator*
Ful Control
Read
Create AH Child Objects
Delete Al Child Objects Change Password
Ful Control
Read
Create AH Child Objects
Delete Al Child Objects Change Password
AlowDeny
“0□^1
в□J
0□
0□
0□
0□J
AlowDeny
“0□^1
в□J
0□
0□
0□
0□J
Advanced |Advanced |11*111*1Тм* I №Тм* I №Alow Allow AllowAllow Alow AlowAlow Allow AllowAllow Alow AlowSYSTEMSYSTEMFulCortrdFulCortrdAccount Operators (COMPAN... Ful ControlAccount Operators (COMPAN... Ful ControlSELF SELF SELF SELF SELF SELFSELF SELF SELF SELF SELF SELFSpecial Change Passw... Send As Receive As Read/Write Per... Read/Write Ph...Special Change Passw... Send As Receive As Read/Write Per... Read/Write Ph...<not inherited» <not inherited» < not inherited» < not inherited» <not inherited» <not inherited» <not inherited»<not inherited» <not inherited» < not inherited» < not inherited» <not inherited» <not inherited» <not inherited»This object or* This object or* This object or* This object «* This object or* This object or* This obiect onk.This object or* This object or* This object or* This object «* This object or* This object or* This obiect onk.
Advanced |
Advanced |
11*1
11*1
Тм* I №
Тм* I №
Alow Allow Allow
Allow Alow Alow
Alow Allow Allow
Allow Alow Alow
SYSTEM
SYSTEM
FulCortrd
FulCortrd
Account Operators (COMPAN... Ful Control
Account Operators (COMPAN... Ful Control
SELF SELF SELF SELF SELF SELF
SELF SELF SELF SELF SELF SELF
Special Change Passw... Send As Receive As Read/Write Per... Read/Write Ph...
Special Change Passw... Send As Receive As Read/Write Per... Read/Write Ph...
<not inherited» <not inherited» < not inherited» < not inherited» <not inherited» <not inherited» <not inherited»
<not inherited» <not inherited» < not inherited» < not inherited» <not inherited» <not inherited» <not inherited»
This object or* This object or* This object or* This object «* This object or* This object or* This obiect onk.
This object or* This object or* This object or* This object «* This object or* This object or* This obiect onk.
Fer apocial регтемт er for e*ancod ta*», cfc* Advanced
Puc. 11.3. Свойства безопасности для объекта пользователя в Active Directory
[Advanced Security Settings for George W. Bush
defined here
Cancel |Cancel |
Cancel |
Cancel |
Puc. 11.4. Расширенное описание дескриптора безопасности объекта пользователя в Active Directory
■Er- .ШЕ1
Nanai |Dtim»inAdmins (COMFAHYWomariAd | Change . ~|
Ap* onto |Fte object only" nn
PeffittoonrAlowDeny
; Read AH Properties0□3
Write AH Properties0□
R ead Account R estrictionsи□
Write Account R estrictionsи□
Read General Informationи□
Write General Information0□
Read Group Membership0П
Write Group Membership0П
Read Logon Informationи□
Write Logon Informationи□
R ead Personal I reformationи□
Wr*e Personal Information0□।
ГOmiAI I
OK I Cencri
Puc. 115. Отображение свойств дескриптора безопасности
Управление владением объектов
При использовании варианта отображения Advanced (Дополнительные параметры) редактора ACL Editor доступна вкладка Owner (Владелец), на которой показано имя пользователя, создавшего объект. Объектам, созданным администратором, в качестве владельца назначается локальная группа Administrators.
Если пользователь обладает привилегией Take Ownership (Изменить владельца), он может заменить текущего владельца объекта собственной учетной записью. Поскольку владелец объекта имеет полный доступ ко всем свойствам объекта, привилегия Take Ownership (Изменить владельца) никогда не должна предоставляться обычным пользователям.
ACL Editor не позволяет передавать права владения другому пользователю. Существует несколько утилит с интерфейсом командной строки, которые это позволяют.
subinacl. Эта утилита предоставляется в составе Resource Kit. Для передачи прав владения необходимо воспользоваться командой следующего формата: subinacl /file <имя_ файла> /зеЬо^ег=<имя_учетной_записи>
chown. В Resource Kit в состав набора утилит POSIX входит утилита chown. Эта утилита требует запуска подсистемы POSIX, которая не предоставляется в составе операционной системы Windows Server 2003. (Пакет совместимости с POSIX, который называется Interix, можно приобрести у компании Microsoft. Некоторые источники не рекомендуют устанавливать подсистему POSIX, поскольку она не входила в состав операционной системы при сертификации.) Для передачи прав владения необходимо воспользоваться командой со следующим синтаксисом: chown <владелец> <файл>. Утилита chown не позволяет передавать права владения группе. Если эта функциональная возможность крайне необходима, попытайтесь воспользоваться утилитой chown, которая предоставляется в составе инструментария Services for UNIX (SFU). Этот пакет стоит около 300 долларов, что делает такой вариант достаточно дорогим1.
'На момент перевода этой книги компания Microsoft предоставляла пакет Services for UNIX бесплатно. — Примеч. ред.
Управление дескрипторами безопасности с помощью утилит с интерфейсом командной строки
ACL Editor является наиболее гибким инструментом для просмотра и модификации содержимого дескрипторов безопасности, но иногда утилита с интерфейсом командной строки оказывается более полезной. Например, может потребоваться изменение разрешений для доступа к объекту с помощью сценария или файла пакетной обработки. Кроме этого, доступ к серверу может предоставляться только по протоколу Telnet или с помощью удаленного интерпретатора команд.
Для просмотра и изменения содержимого дескриптора безопасности существует несколько утилит с интерфейсом командной строки. Список утилит в этой книге классифицирован по классам объектов: службы, объекты Active Directory, файлы и папки NTFS.
Службы
Утилиту subinacl можно использовать для просмотра и изменения дескриптора безопасности для службы. (В документации Resource Kit указана утилита svcacls, предназначенная для установки прав доступа в дескрипторах безопасности служб, но эта утилита была удалена из поставки, так как ее возможности дублировались в утилите subinacl.) Рассмотрим пример использования утилиты subinacl для просмотра параметров доступа к службе LanMan Workstation:
C:\subinacl /service lanmanworkstation
+Service lanmanworkstation
/owner^system
/primary group=system
/audit ace count=1
/aace =everyone SYSTEM_AUDIT_ACE_TYPE-0x2
FAILED_ACCESS_ACE_FLAG-0x80FAILED_ACCESS_ACE_FLAG-0x0x80
SERVICE_ALL_ACCESS
/perm, ace count =4
/pace =authenticated users ACCESS_ALLOWED_ACE_TYPE-OxO
SERVICE_QUERY_CONFIG-0xlSERVICE_QUERY_STATUS-0x4
'b SERVICE_ENUMERATE_DEPEND-0x8
SERVICE_INTERROGATE-0x80READ_CONTROL-0x20000
^ SERVICE_USER_DEFINED_CONTROL-0x0100
/pace =builtin\power users ACCESS_ALLOWED_ACE_TYPE-0x0
SERVICE_QUERY_CONFIG-0xlSERVICE_QUERY_STATUS-0x4
'b SERVICE_ENUMERATE_DEPEND-0x8
SERVICE_START-0x10SERVICE_INTERROGATE-0x80
9> READ_CONTRGL-0x20000SERVICE_USER_DEFINED_CONTRGL-0x0100
pace =builtin\administratprsACCESS_ALLOWED_ACE_TYPE-0x0
SERVICE_ALL_ACCESS
/pace =systemACCESS_ALLOWED_ACE_TYPE-0x0
SERVICE_QUERY_CONFIG-0xlSERVICE_QUERY_STATUS-0x4
4> SERVICE_ENUMERATE_DEPEND-0x8
SERVICE_START-0xl0SERVICE_STOP-0x20
4> SERVICE_PAUSE_CONTINUE-0x40SERVICE_INTERRGGATE-0x80
READ_CONTROL-0x20000SERVICE_USER_DEFINED_CONTROL-0x0100
Объекты Active Directory
Для объектов Active Directory с целью просмотра заданных значений дескрипторов безопасности можно воспользоваться утилитой dsapls, которая предоставляется в составе Resource Kit. Ниже приведен фрагмент отчета утилиты dsacls для объекта домена TestDomain:
C:\>dsacls dc=TestDomain Access list:
Effective Permissions on this object are:
Allow
Everyone
SPECIAL ACCESS READ PROPERTY
Allow
NT AUTHORITYXAuthenticated Users
SPECIAL ACCESS READ PERMISSONS LIST CONTENTS READ PROPERTY LIST OBJECT
Allow
COMPANY\Domain Admins
SPECIAL ACCESS READ PERMISSONS WRITE PERMISSIONS CHANGE OWNERSHIP CREATE CHILD LIST CONTENTS WRITE SELF WRITE PROPERTY READ PROPERTY LIST OBJECT CONTROL ACCESS
Allow
BUILTINXAdministrators
SPECIAL ACCESS DELETE
READ PERMISSONS WRITE PERMISSIONS CHANGE OWNERSHIP CREATE CHILD LIST CONTENTS WRITE SELF WRITE PROPERTY READ PROPERTY LIST OBJECT CONTROL ACCESS
Allow
NT AUTHORITY\SYSTEM
FULL CONTROL
Allow
COMPANYXEnterprise Admins
FULL CONTROL
Файлы и каталоги NTFS
Чтобы просмотреть содержимое дескриптора безопасности для файла или каталога NTFS, можно воспользоваться утилитами cads и xcacls. Утилита xcacls предоставляет больше параметров и входит в состав пакета Support Tools. Кроме этого, можно воспользоваться утилитой subinacl из состава Resource Kit. Из этих трех утилит утилита xcacls оказывается наиболее удобной, но утилита subinacl предоставляет больше возможностей. Если необходимо только просмотреть содержимое дескриптора безопасности, можно воспользоваться утилитой showacls из состава Resource Kit.
Рассмотрим пример отчета утилиты xcacls для файла с тремя записями контроля доступа для групп Authenticated Users, Administrators и широкоизвестного идентификатора безопасности группы Interactive.
С:\test>xcacls text3.txt
C:\test\test.txt NT AUTHORITYXAuthenticated Users:R
BUILTINXAdministrators:(01)(CI)F
NT AUTHORITYXINTERACTIVE:(01)(CI)(special access:)
READ-CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_GENERIC_WRIТЕ FILE_GENERIC_EXECUTE FILE_READ_DATA FILE-WRITE-DATA FILE-APPEND-DATA FILE_READ_EA FILE_WRITE_EA FILE-EXECUTE FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES
Ниже приведен отчет утилиты subinacl для того же файла. Несложно заметить, что предоставляется значительно больший объем информации, возможно, даже больший, чем это необходимо.
С:\test>subinacl /file test3.txt
+ File C:\test\test.txt
/owner=builtin\administrators
/primarygroup=cx612097-b\none
/audit acecount=0
/perm, acecount=3
/pace =builtin\administrators ACCESS—ALLOWED—ACE_TYPE-0x0 CONTAINER.INHERIT.ACE-0x2 OBJECT_INHERIT_ACE-0xl Type of access:
Full Control
Detailed Access Flags:
FILE.READ.DATA-OxlFILE—WRITE.DATA-0x2
4> FILE—APPEND—DATA-0x4 FILE_READ—EA-0x8FILE.WRIТЕ.EA-0x10
4> FILE-EXECUTE-0x20 FILE_DELETE_CHILD-0x40
FILE_READ_ATTRIBUTES-0x80FILE.WRITE.ATTRIBUTES-OxlOO
4> DELETE-OxlOOOO READ_CONTROL-0x20000 WRITE.DAC_0x40000WRITE—OWNER-0x80000
9» SYNCHRONIZE-OxlOOOOO
/pace = authenticated users ACCESS—ALLOWED—ACE.TYPE-0x0
Type of access:
Read
Detailed Access Flags:
FILE_READ_DATA-0x1FILE.READ.EA-0x8
4> FILE—EXECUTE-0x20FILE.READ.ATTRIBUTES-0x80
4> READ-CONTROL-0x20000SYNCHRONIZE-OxlOOOOO
/pace interactiveACCESS—ALLOWED—ACE_TYPE-0x0
CONTAINER.INHERIT.ACE-0x2OBJECT_INHERIT_ACE-0xl
Type of access:
Special access: -Read -Write -Execute
Detailed Access Flags:
FILE_READ_DATA-0x1FILE_WRITE_DATA-0x2
4> FILE-APPEND-DATA-0x4 FILE—READ—EA-0x8FILE_WRITE_EA-0xl0
4> FILE-EXECUTE-0x20' FILE.READ.ATTRIBUTES-0x80
'Ъ FILE—WRITE—ATTRIBUTES-OxlOO RE AD_CONTROL - 0 x2 0 0 0 0 4> SYNCHRONIZE-OxlOOOOO
Сценарии и дескрипторы безопасности
Если принято решение об изменении дескрипторов безопасности с помощью сценария, придется просмотреть большой объем документации и примеров. Обратите внимание на книгу Тома Эка (Tom Eck) ADS! Scripting for NT/Windows 2000 System Administrators. В этой книге приводятся примеры и очень простые объяснения операций с дескрипторами безопасности.
Кроме этого, стоит приобрести COM-объекты сторонних производителей, которые упрощают операции с дескрипторами безопасности. Обратите внимание на библиотеку Ntsec, которая доступна по адресу www.pedestalsoftware. com/ntsec .
В составе операционной системы Windows Server 2003 предоставляются новые стандартные вызовы API, которые упрощают операции с дескрипторами безопасности. Дополнительная информация о новых вызовах функций приводится в Platform SDK, который можно загрузить с сайта по адресу www.microsoft. com или получить в составе библиотеки MSDN.
Оценка прав доступа
Наконец пришло время рассмотреть авторизацию Windows — механизм, который система использует для принятия решения о предоставлении или не предоставлении пользователю доступа к определенному объекту. Когда пользовательский процесс пытается получить доступ к объекту системы безопасности, монитор ссылок безопасности сканирует список контроля доступа DACL дескриптора безопасности объекта и пытается найти идентификатор безопасности, который соответствует идентификатору безопасности из пользовательского маркера доступа.
Как только монитор ссылок безопасности (SRM) обнаруживает совпадение, он сравнивает разрешения в маске записи контроля доступа (АСЕ) с разрешениями, запрошенными процессом, который предоставил маркер доступа. Если одно из разрешений совпадает, вся маска доступа извлекается из АСЕ и добавляется в консолидированную маску доступа пользовательского процесса.
Если запись контроля доступа предоставляет пользователю разрешение, это разрешение затем не пересматривается. Помните об этом, отслеживая транзакции сравнения. Если разрешения явно не предоставлены одной из записей контроля доступа (АСЕ) в списке контроля доступа DACL, пользователю отказывается в доступе. Это неявный отказ (implicit deny).
Кумулятивные разрешения
Разрешения, предоставленные записями контроля доступа Allow (Разрешить), являются кумулятивными, т.е. разрешения, предоставленные одному пользователю различными записями контроля доступа, формируют единый набор разрешений. Рассмотрим пример сравнения записи контроля доступа Allow (Разрешить) для создания кумулятивного набора разрешений.
Рассмотрим процесс, который принадлежит пользователю Jane. Поток этого процесса открывает файл для чтения и записи. В списке DACL этого файла для пользователя Jane существует две записи контроля доступа. В одной указана маска доступа Allow Write (Разрешить запись), а во второй указана маска доступа Allow Read (Разрешить чтение). К потоку присоединен маркер доступа пользователя Jane. При попытке доступа к объекту файла монитор ссылок безопасности сканирует список DACL и находит запись контроля доступа с идентификатором безопасности пользователя Jane.
Назначение разрешений Allow (Разрешить) и Deny (Запретить)
Каждая запись АСЕ в списке DACL классифицируется как Allow (Разрешить) или Deny (Запретить). Это значит, что в одной маске доступа нельзя одновременно указывать разрешения Allow (Разрешить) и Deny (Запретить).
Если воспользоваться программой ACL Editor для установки прав доступа Allow (Разрешить) и Deny (Запретить) для одного участника системы безопасности, редактор создаст две записи контроля доступа: одну — для права доступа Deny (Запретить), а вторую — для права доступа Allow (Разрешить).
Монитор ссылок безопасности SRM сравнивает разрешения, запрошенные потоком (Read и write), с разрешениями в маске доступа записи АСЕ (Read_Data) и находит совпадение для разрешения Read в записи контроля доступа Al low.
Поскольку идентификаторы безопасности и разрешения совпадают, монитор ссылок безопасности добавляет маску доступа из записи контроля доступа в общую (кумулятивную) маску доступа для данного потока. Затем монитор ссылок безопасности продолжает сканирование списка DACL.
После этого монитор ссылок безопасности сталкивается со второй записью контроля доступа, которая содержит идентификатор безопасности пользователя Jane. В процессе сравнения прав доступа SRM определяет, что разрешение Write, запрошенное потоком, совпадает с разрешением Write_Data, указанным в маске доступа записи АСЕ Allow (Разрешить). Монитор ссылок безопасности SRM добавляет маску доступа в общую (кумулятивную) маску доступа потока и продолжает сканирование.
Поскольку пользователю Jane явно не предоставлены разрешения Allow (Разрешить) для других разрешений, окончательное содержимое маски доступа предоставляет потоку возможность чтения и записи файла.
Приоритет разрешения Deny (Запретить)
Разрешения Deny (Запретить) имеют больший приоритет, чем разрешения Allow (Разрешить). Немного изменим пример и рассмотрим, как это происходит. В новом примере в разрешение Write (Запись) была добавлена запись контроля доступа Deny (Запретить).
Как только поток, принадлежащий пользователю Jane, пытается получить доступ к файлу, монитор ссылок безопасности начинает сканирование списка DACL и обнаруживает запись контроля доступа с идентификатором безопасности пользователя Jane. Во время сравнения разрешений монитор ссылок безопасности (SRM) обнаруживает совпадение между запрошенными разрешениями (Read и Write) и разрешением Write_Data, указанным в маске доступа для записи АСЕ Deny (Запретить).
Из-за совпадения идентификаторов безопасности и разрешений монитор ссылок безопасности добавляет маску доступа Deny (Запретить) для разрешения Write_Data в общую (кумулятивную) маску доступа и продолжает сканирование списка разграничительного контроля доступа ( DAC L).
После этого монитор ссылок безопасности обнаруживает вторую запись АСЕ с идентификатором безопасности пользователя Jane. В процессе сравнения разрешений он определяет, что запрошенное разрешение Write (Запись) совпадает с разрешением Read_Data в маске доступа для записи ALE Allow (Разрешить). Монитор ссылок безопасности добавляет маску доступа Read_Data в общую (кумулятивную) маску доступа и продолжает сканирование.
После этого монитор ссылок безопасности SRM обнаруживает третью запись контроля доступа (ALE) с идентификатором безопасности пользователя Jane. В процессе сравнения он определяет, что запрошенное разрешение Write (Запись) уже рассматривалось одновременно с предыдущей записью ALE. Монитор ссылок безопасности не выполняет дополнительных операций по изменению маски доступа и продолжает сканирование. Не забывайте, что после назначения разрешений повторные сравнения не выполняются.
Используя окончательное значение кумулятивной маски доступа, поток, принадлежащий пользователю Jane, получает разрешение на чтение (Read). Потоку было явно запрещен доступ на запись (Write), а все остальные разрешения были запрещены неявно.
Важно обратить внимание, что приоритет разрешения Deny (Запретить) над разрешением Al low (Разрешить) основан на двух ключевых особенностях.
Записи контроля доступа Deny (Запретить) всегда записываются перед записями контроля доступа Allow (Разрешить) в списках контроля доступа. Это так называемая каноническая сортировка (canonical sorting).
После того как монитор ссылок безопасности (SRM) сравнил разрешения, конкретное разрешение не рассматривается повторно.
Операционная система Windows автоматически сортирует записи контроля доступа в каноническом порядке, но в правилах сортировки существуют исключения. Давайте поэкспериментируем. Перейдите в режим отображения Advanced (Дополнительные параметры) в редакторе ACL Editor для объекта файла. В этом режиме отображаются записи контроля доступа в том порядке, в котором выполняет сравнение монитор ссылок безопасности. На рис. 11.6 показан пример пользователя в организационной единице, который находится на три уровня ниже в базе данных Active Directory. Каждой организационной единице назначена административная группа, поэтому объект пользователя наследует разрешения для всех трех групп.
Найдите столбец Inherited From (Унаследовано от) в режиме отображения Advanced (Дополнительные параметры) редактора ACL Editor. Можно обратить внимание, что унаследованные записи контроля доступа записываются ниже непосредственно применяемых записей контроля доступа. Это значит, что непосредственно применяемые записи контроля доступа имеют больший приоритет по сравнению с унаследованными записями управления доступом. Причины и механизмы наследования разрешений рассматриваются в следующем разделе.
Наследование разрешений позволяет быстро и просто изменять разрешения для очень больших структур, не требуя изменения дескрипторов безопасности для каждого элемента большой структуры. Кроме этого, наследование позволяет преодолеть проблему классической операционной системы WindowsNT, которая заключалась в перезаписи списков контроля доступа в дескрипторах безопасности всех низлежащих объектов каталога при изменении списка контроля доступа для каталога, который является вышележащим в структуре.
Рис. 11.6. Режим Advanced (Дополнительные параметры) в редакторе ACL Editor, в котором отображается последовательность записей контроля доступа с учетом наследования прав доступа
Исключения из правил канонической сортировки
Существует возможность программно переопределить каноническую сортировку записей контроля доступа. Это позволяет разработчику воспользоваться особенностями однократного сравнения прав доступа при сканировании записей контроля доступа (АСЕ) средствами монитора ссылок безопасности (SRM).
Например, в Exchange 2000 поддерживается сокрытие членов группы распространения. Для этого группа Everyone должна добавляться в запись контроля доступа Deny Read в списке DACL.
Если бы для списка разграничительного контроля доступа (DACL) использовалась обычная каноническая сортировка, это не позволило бы службе Exchange просматривать содержимое группы. Маркеры доступа для всех учетных записей, кроме Anonymous Logon, автоматически содержат группу Everyone. Служба Exchange обходит эту проблему, переопределяя каноническую сортировку и предоставляя службе Exchange право доступа Full Control (Полный доступ) до рассмотрения записи контроля доступа Deny (Запретить) для группы Everyone.
Поскольку монитор ссылок безопасности SRM только один раз сравнивает разрешения, такая неканоническая сортировка предоставляет полный доступ службе Exchange и запрещает доступ всем остальным. Если открыть редактор ACL Editor, можно получить предупреждение о том, что записи контроля доступа отсортированы нестандартным образом.
Наследование разрешений
При наследовании разрешений используется новый способ управления дескрипторами безопасности, который появился в операционной системе Windows 2000. Точный механизм этого управления рассматривается в разделе "Описание наследования разрешений" далее в этой главе. Вместо размещения дескрипторов безопасности в каждом объекте система поддерживает отдельную базу данных дескрипторов безопасности, на которую ссылаются объекты. (Это не относится к разделам системного реестра. Обновление дискреционного списка контроля доступа (DACL) в разделе системного реестра на более высоком уровне приведет к изменению списка контроля доступа в каждом дочернем разделе системного реестра.)
Служба ACL Editor предоставляет возможность блокирования наследования. Включение этой возможности создает новый дескриптор безопасности в базе данных и меняет указатели в дочернем дескрипторе. Этот механизм позволяет одновременно сохранить скорость и эффективность классического механизма сравнения, доступных в мониторе ссылок безопасности (SRM) WindowsNT, и получить недоступную ранее гибкость процесса динамического наследования.
Оценка записей контроля доступа
с наследованием
Записи контроля доступа, которые непосредственно созданы в списке контроля доступа, имеют больший приоритет, чем записи контроля доступа, унаследованные от родительского объекта. Кроме этого, записи контроля доступа, применяемые на каждом уровне файловой системы или Active Directory, имеют более высокий приоритет, чем записи контроля доступа на вышележащих уровнях. Для этого система сортирует записи контроля доступа на основе их происхождения. Рассмотрим порядок сортировки записей.
Непосредственно созданные записи контроля доступа Deny (Запретить) размещаются на вершине списка контроля доступа.
Непосредственно созданные записи контроля доступа Allow (Разрешить) располагаются после записей Deny.
Унаследованные записи контроля доступа Deny (Запретить).
Унаследованные записи контроля доступа Allow (Разрешить) располагаются последними в списке.
Блокирование наследования разрешений
Если принято решение блокировать наследование разрешений для объекта, система запрашивает, следует ли скопировать или удалить унаследованные записи контроля доступа из списка DACL. Автор этой книги рекомендует копировать записи контроля доступа. После этого можно выбрать, какие записи контроля доступа удалить, а какие оставить. В этом случае можно обезопасить себя от случайного отключения доступа к каталогам или объектам на нижних уровнях дерева, если доступ к этим объектам обеспечивался унаследованными записями контроля доступа, которые были удалены.
Это значит, что непосредственно применяемая запись контроля доступа Allow (Разрешить) имеет более высокий приоритет, чем унаследованная запись контроля доступа Deny (Запретить). Рассмотрим пример, в котором показано использование таких приоритетов.
Пусть существует пользователь, который входит в две группы: А и В. Группа А была непосредственно указана в списке DACL для файла с разрешениями Allow Read/Write/ Access (Разрешить чтение/запись/выполнение). Группа В была унаследована из родительского каталога с разрешениями Deny Read (Запретить чтение) и Deny Access (Запретить запись).
Монитор ссылок безопасности (SRM) будет сравнивать отдельные разрешения только во время сканирования записей контроля доступа. Поскольку первая запись контроля доступа во время сканирования содержит маску доступа для Read_Data, Write_Data и Execute, эти разрешения не сравниваются еще раз, когда будут обнаружены в маске Deny (Запретить) в следующей записи контроля доступа. Общая (кумулятивная) маска доступа для пользовательского процесса в результе получит разрешения Allow Read/Write/Access (Разрешить чтение/запись/выполнение).
Помните об этом при определении разрешений к объектам системы безопасности.
Не предполагайте, что назначение записи контроля доступа Deny (Запретить) каталогу верхнего уровня блокирует доступ ко всему подкаталогу. Другой администратор или владелец подкаталога может блокировать наследование ниже по дереву или непосредственно добавить запись контроля доступа Allow (Разрешить), которая переопределит запись Deny (Запретить). Это предупреждение относится и к объектам Active Directory. Администратор организационной единицы может блокировать наследование разрешений и совершить небольшой виртуальный Государственный переворот.
Не помещайте административную группу в список контроля доступа с записью контроля доступа Access Denied. В этом случае можно случайно заблокировать доступ администраторов к важному каталогу или контейнеру. К счастью, группа Administrators владеет всеми объектами каталоГа, поэтому в случае ошибки список контроля доступа можно исправить.
Не связывайте запись контроля доступа Access Denied с группой Everyone. Если заблокировать группу Everyone, доступ будет заблокирован и для всех администраторов. Это даже может привести к блокированию доступа к локальной системе. То же самое относится к остальным широкоизвестным группам, например Interactive, Network, LocalSeryice и Networkservice. Если доступ к объекту должен быть ограничен, удалите группу Everyone из списка контроля доступа и воспользуйтесь неявным отказом в доступе.
Описание наследования разрешений
Классическая операционная система Windows NT размещает дескриптор безопасности в каждом объекте. Если в список контроля доступа родительского объекта, например каталога для файла, вносится изменение, система открывает дескриптор безопасности каждого дочернего объекта и обновляет список контроля доступа.
Любой администратор файлового сервера и сервера печати под управлением операционной системы Windows NT знает, сколько времени и ресурсов требуется на изменение списков контроля доступа файлов и каталогов при внесении изменений в список управления доступом корневого каталога большого тома NTFS. Файловая система NTFS, которая предоставляется в составе операционной системы Windows 2000, Windows Server 2003 и Windows ХР, обрабатывает разрешения значительно эффективнее. Вместо размещения дескрипторов безопасности в каждом объекте файловая система поддерживает таблицу дескрипторов безопасности в скрытой базе данных в каталоге метаданных $Secure; Каждый файл или каталог содержит ссылку на дескриптор безопасности в этой таблице.
При изменении списка контроля доступа к каталогу все дочерние каталоги, связанные с этим дескриптором безопасности, получают новое значение списка контроля доступа автоматически. При блокировании наследования в каталоге в базе данных будет создан новый дескриптор безопасности. Указатели в подкаталогах будут указывать на созданный дескриптор. Это позволяет значительно снизить требования ко времени и ресурсам, необходимым для изменения разрешений. (Дополнительная информация о безопасности файловой системы NTFS приводится в главе 16, “Управление совместно используемыми ресурсами".)
Назначение параметров наследования
Параметры наследования для каждой конкретной записи контроля доступа в списке контроля доступа указываются отдельно. Параметры наследования можно настроить с помощью режима Advanced (Дополнительные параметры) редактора ACL Editor.
Щелкнув на кнопке Add (Добавить) или Edit (Правка) для редактирования записи контроля доступа в режиме Advanced (Дополнительные параметры), можно открыть окно Permission Entry (Запись разрешения), в поле Apply Onto (Применить) которого перечислены параметры наследования. Ниже перечислены доступные параметры для файловой системы NTFS.
Только для этого каталога
Для этого каталога, его подкаталогов и файлов
Для этого каталога и его подкаталогов
Для этого каталога и его файлов
Только ддя подкаталогов и файлов
Только для подкаталогов
Только для файлов
Ниже перечислены параметры наследования для объектов Active Directory.
Только этот объект
Этот объект и все дочерние объекты
Только дочерние объекты
Объекты Active Directory предоставляют дополнительные параметры наследования для выбора класса объекта, который наследует определенную запись контроля доступа. Мастер делегирования (Delegation Wizard) упрощает процедуру выбора. Дополнительная информация по этому вопросу приведена в главе 13, “Управление безопасностью Active Directory”.
Просмотр результирующих разрешений
Маркер доступа пользбвателя содержит идентификатор безопасности каждой группы, в которую входит этот пользователь. Кроме этого, в маркере доступа указывается идентификатор безопасности каждой группы, в которую входят эти группы, и т.д. Иногда права доступа к определенному объекту для определенного пользователя очень сложно определить.
Результирующий набор разрешений к определенному объекту указанного пользователя или группы можно просмотреть с помощью средств редактора ACL Editor. На рис. 11.7 показан пример учетной записи администратора, который добавлен в группу разрешением Full Control (Полный доступ), предоставленным организационной единице, в которой содержится объект User. Последовательность действий для просмотра разрешений описана в процедуре 11.1.
BFJCoAg* в UtiCor***: В Read AJI Properties В Write АДРгареФм В Delete В Delete Subtiee а Read Рв«т*геоИ8 В Mod& Решайте В MocWy Owner В Al Extended Rtghlt H Create Ai Chid Obfecis В Delete Al Chid Objects
Puc. 11.7. Результирующий набор разрешений отображается в окне редактора ACL Editor
Процедура 11.1. Просмотр результирующего набора разрешений
Откройте окно Properties (Свойства) для интересующего объекта безопасности.
Перейдите на вкладку Security (Безопасность).
Щелкните на кнопке Advanced (Дополнительно).
Откройте вкладку Effective Permissions (Действующие разрешения).
Щелкните на кнопке Select (Выбрать). Откроется окно Select User, Computer or Group (Выберите пользователя, компьютер или группу).
Введите имя пользователя или группы, разрешения которых вас интересуют.
Щелкните на кнопке ОК. В поле Effective Permissions (Действующие разрешения) будет установлен флажок напротив каждого разрешения, предоставленного пользователю.
Системные привилегии
До этого момента рассматривалось, как монитор ссылок безопасности SRM управляет доступом к объектам безопасности на основе маркеров доступа и дескрипторов безопасности. Существует дополнительный набор элементов управления, который определяет, какие пользователи и группы могут получать доступ к базовым системным службам, например возможности резервного копирования/восстановления или изменения системного времени. Это так
называемые системные привилегии (system privileges). Ниже приведен краткий список системных привилегий, которые доступны в операционной системе Windows Server 2003 (привилегии, связанные исключительно с инструментами разработчиков, в списке не указаны).
Add workstations to domain (Добавлять рабочие станции в домен)
Adjust memory quotas for a process (Выделять память для процесса)
Back up files and directories (Резервное сохранение файлов и каталогов)
Change the system time (Изменять системное время)
Create a paging file (Создавать файл подкачки)
Debug programs (Выполнять отладку программ)
Enable accounts to be trusted for delegation (Разрешить делегирование для учетных записей)
Force shutdown from_a remote system (Принудительное выключение с удаленного компьютера)
Impersonate a client after authentication (Принять роль клиента после аутентификации); появилась в операционной системе Windows Server 2003
Increase scheduling priority (Повысить приоритет процесса при составлении расписания)
Load and unload device drivers (Загружать и выгружать драйверы устройств)
Manage auditing and security log (Управлять журналами аудита и безопасности)
Modify firmware environment values (Изменять значения системных переменных среды)
Perform volume maintenance tasks (Выполнять задачи по обслуживанию томов)
Profile single process (Наблюдать за несистемным процессом)
Profile system performance (Получить выборку показателей производительности)
Remove computer from docking station (Отключать переносной компьютер от установочной станции)
Replace a process level token (Изменять маркер доступа для процесса)
Restore files and directories (Восстанавливать файлы и каталоги)
Shut down the system (Выключать систему)
Take ownership of files or other objects (Получение прав владения файлами или иными объектами)
Эти привилегии назначаются с помощью политик, установленных на локальном компьютере или загруженных с контроллера домена в составе объекта групповой политики.
Локальные политики безопасности хранятся в базе данных Secedit. sdb. База данных расположена в каталоге \windows\Security\Database. Локальные политики безопасности настраиваются с помощью редактора групповых политик (файл Gpedit .msc), который можно запустить с помощью команды Starts Programs^ Administrative Tools^Local Security Policy (Пуск^Программы1^ Администрирование^Локальные политики безопасности).
Групповые политики безопасности связаны с определенным сайтом, доменом или организационной единицей в базе данных Active Directory. Например, контроллеры домена загружают собственные групповые политики безопасности из объекта групповой политики Default Domain Controller, который связан с организационной единицей Domain ; Controllers. Групповые политики переопределяют локальные политики, загруженные из базы данных Secedit. sdb. Групповые политики, которые управляют системными при- :
вилегиями, расположены в разделе Computer Configuration^Windows Settings"*Security Settings1* Local Policies1* User Rights Assignment (Конфигурация компьютера*Конфи- гурация Windows1* Параметры безопасности1*Локальные политики1* Назначение прав пользователей).
Политики безопасности могут назначаться непосредственно пользователю или группе, в которую входит пользователь. В любом случае привилегии, назначенные пользователю, становятся частью пользовательского маркера доступа. Привилегии проверяются каждый раз, когда пользователь пытается выполнить привилегированную системную операцию.
Просмотр системных привилегий
Существует несколько утилит с интерфейсом командной строки, которые позволяют просматривать системные привилегии, назначенные пользователю. Эта возможность оказывается полезной при диагностике проблем, когда определенный пользователь не может выполнить определенную задачу.
Утилита whoami
Утилита whoami входит в состав пакета Resource Kit и позволяет просматривать список системных привилегий пользователя и группы, в которые входит пользователь. Рассмотрим пример отчета этой утилиты (команда whoami /all).
C:!>whoami /all
[User] = "COMPANY!Administrator" S-l-5-21-2942328611-
9>473866232-3689853989-500
[Group 1] = "COMPANY!Domain Users" S-l-5-21-2942328611-
4>473866232-3689853989-513
[Group 2] = "Everyone" S-l-1-0
[Group 3] = "BUILTIN!Administrators" S-l-5-32-544
[Group 4] = "BUILTINXUsers"1S-l-5-32-545
[Group 5] = "COMPANY!Schema Admins" S-l-5-21-2942328611-■-
9>' 473866232-3689853989-518
[Group 6] = "COMPANY!Domain Admins" S-l-5-21-2942328611-
9>4738.66232-3689853989-512
[Group 7] = "COMPANY!Group Policy Creator Owners" S-l-5-21-
2942328611-473866232-3689853989-520
[Group 8] = "COMPANY!Enterprise Admins" S-l-5-21-2942328611-
9>473866232-3689853989-519
[Group 9] = "LOCAL" S-l-2-0
[Group 10] = "NT AUTHORITY!REMOTE INTERACTIVE LOGON" S-l-5-14
[Group 11] = "NT AUTHORITY!INTERACTIVE" S-l-5-4
[Group 12] = "NT AUTHORlTY!Authenticated Users" S-l-5-11
(X)
SeChangeNotifyPrivilege
Обход перекрестной проверки
(0)
SeSecurityPrivilege
Управление аудитом и
ч>
журналом безопасности
(0)
SeBackupPrivilege
Резервное копирование файлов
ч>
(0)
SeRestorePrivilege
и каталогов
Восстановление файлов и каталогов
(0)
SeSystemtimePrivilege
Изменение системного времени
(0)
SeShutdownprivilege
Завершение работы системы
(0)
SeRemoteShutdownPrivilege
Принудительное отключение
ч>
(0)
SeTakeOwnershipPrivilege
с удаленного компьютера Получение прав владения
(0)
SeDebugPrivilege
для файла или другого объекта Отладка программ
(0)
SeSystemEnvironmentPrivilege
Изменять значения системных
ч>
(0)
SeSystemProfilePrivilege
переменных среды
Контролировать производительность
(0) SeProfileSingleProcessPrivilege процессом
(0) SelncreaseBasePriorityPrivilege
(X) SeLoadDriverPrivilege
(0) SeCreatePagefilePrivilege
(0) SelncreaseQuotaPrivilege процесса
(0) SeUndockPrivilege
(0) SeManageVolumePrivilege
(0) SeEnableDelegationPrivilege
(0) SeAssignPrimaryTokenPrivilege процесса
(0) SeMachineAccountPrivilege домену
системы
Наблюдать за несистемным
Повысить приоритет процесса при составлении расписания
Загрузка и выгрузка драйверов устройств ■
Создание файла подкачки
Настройка квот памяти для
Извлечение компьютера из стыковочной станции
Выполнение операций по обслуживанию тома
Доверие к учетным записям при делегировании
Изменять маркер доступа для
Добавление рабочих станций к
Обратите внимание, что из отчета утилиты whoami следует, что учетной записи Administrator не предоставлено привилегии SeBackupPrivilege, которая необходима для создания резервных копий. Но известно, что администратор может выполнить эту операцию. Это связано с тем, что утилита whoami сообщает о привилегиях, которые непосредственно присвоены пользователю, и не выводит сведения о привилегиях, которые предоставлены группам, в которые входит пользователь. Более подробный отчет можно получить с помощью утилиты gpresult.
Стандартная утилита gpresult .
Более точный список привилегий пользователя предоставляет утилита gpresult, которая поставляется в составе операционной системы Windows Server 2003 или Windows ХР. В отчете утилиты указаны все политики, а не только системные привилегии. Рассмотрим фрагмент отчета этой утилиты (команда gpresult -v).
GPO: Default Domain Controllers Policy
Policy:CreatePagefilePrivilege
Computer Setting: Administrators.
GPO: Default Domain Controllers Policy
Policy:EnableDelegat ionPrivilege
Computer Setting: Administrators
GPO: Default Domain Controllers Policy
Policy:DebugPrivilege
Computer Setting: Administrators .
GPO: Default Domain Controllers Policy
Policy:SystemTimePrivilege
Computer Setting: Server Operators Administrators
GPO: Default Domain Controllers Policy
Policy:DenyBatchLogonRight
Computer Setting: N/A
GPO: Default Domain Controllers Pplicy
Policy:Backupprivilege
Computer Setting: Server Operators
Backup Operators Administrators
Несложно заметить, что в этом отчете содержится более точная информация, чем в отчете утилиты whoami, поскольку здесь приводятся привилегии, полученные благодаря членству в группах. Но с таким форматом вывода сложнее работать, так как приходится рассматривать каждую привилегию.
Утилита gpresult (из состава Windows 2000 Resource Kit)
Более простой для работы отчет о предоставленных привилегиях можно получить с помощью утилиты gpresult, которая входит в состав Windows 2000 Resource Kit. Рассмотрим пример отчета (команда gpresul t /v):
User Group Policy results for:
CN=Administrator,CN=Users,DC=Company,DC-com
Domain Name:COMPANY
Domain Type:Windows2000
Site Name:Default-First-Site-Name
Roaming profile:(None)
Local profile:C:\Documents and SettingsXAdministrator
The user is a member of the following security groups:
COMPANYXDomain Users
XEveryone
BUILTINXAdministrators
BUILTINXUsers
COMPANYXSchema Admins
COMPANYXDomain Admins
COMPANY\Group Policy Creator Owners
COMPANYXEnterprise Admins XLOCAL
NT AUTHORITY!INTERACTIVE
NT AUTHORITYXAuthenticated Users
The user has the following security privileges:
Bypass traverse checking
Manage auditing and security log
Backup files and directories
Restore files and directories
Change the system time
Shut down the system
Force shutdown from a remote system
Take ownership of files or other objects
Debug programs
Modify firmware environment values
Profile system performance
Profile single process
Increase scheduling priority
Load and unload device drivers
Create a pagefile
Adjust memory quotas for a process
Remove computer from docking station
Perform volume maintenance tasks
Enable computer and user accounts to be trusted for delegation Replace process level token
Add workstations to domain [
Утилита showprivs
Если необходимо получить список пользователей и групп, которым предоставлены определенные привилегии, воспользуйтесь утилитой showprivs из состава Resource Kit. Ниже приведен пример использования этой утилиты (команда showprivs seshutdownpr ivilege):
C:\>showpriv seshutdownprivilege
5 account(s) with the seshutdownprivilege user right: BUILTIN\Backup Operators
BUILTIN\Print Operators new name
BUILTIN\Server Operators
BUILTIN\Account Operators
BUILTIN\Administrators
All accounts enumerated
Политики безопасности
Кроме групповых политик, которые оказывают влияние на фундаментальные системные привилегии, операционная система предоставляет большое количество групповых политик, которые используются для управления безопасностью на более высоком уровне. Политики оказывают влияние на записи системного реестра, а не на записи в базе данных Secedit. sdb. Политики хранятся в разделе Computer ConfigurationoWindows Settings^Security Settings*>Local Policies^Security Options (Конфигурация компьютера^Параметры Windows'* Параметры безопасности1* Локальные политики1* Параметры безопасности).
Ниже приведен перечень часто используемых политик безопасности, соответствующих разделов системного реестра и описание функции каждой политики.
Allow system to be shutdown without having to log on (Разрешить завершение работы сис- темы.без регистрации). Эта политика хранится в разделе HKLM\Software\Microsoft\ Windows NT\CurrentVersion\Winlogon\ShutdownWithoutLogon. При нажатии комбинации клавиш <Ctrl+Alt+Del> для регистрации в регистрационном окне выводится кнопка Shutdown (Завершение работы), которая позволяет выключить компьютер без регистрации в системе. Это допустимо для настольного компьютера под управлением операционной системы Windows ХР, хотя при включении быстрого переключения пользователей это может привести к потере данных. На серверах возможность отключения компьютера без регистрации не следует активизировать, поскольку в момент выключения к серверу могут быть подключены другие пользователи. Именно по этой причине в операционной системе Windows Server 2003 существует локальная политика, которая отключает политику ShutdownWithoutLogon.'
Audit the access of global system objects (Аудит доступа к глобальным системным объектам). Эта политика хранится в разделе HKLM\System\CurrentControlSet\Control\ Lsa\AuditBaseObject). Внутренний мир операционной системы Windows Server 2003 чем-то напоминает Пентагон. Большинство секретных мест достаточно скучны, даже если есть необходимый доступ. Именно по этой причине включение аудита обычно не ограничивает доступ к множеству внутренних объектов. Включение аудита только добавляет внутренние объекты в отчет аудита. В большинстве случаев эта возможность оказывается 1 полезной только разработчикам систем.
Audit the use of all user rights including backup and restore (Аудит использования всех прав доступа, включая архивацию и восстановление). Эта политика хранится в разделе HKLM\System\CurrentControlSet\Control\Lsa\FullPrivilegeAuditing. В обычных условиях включение аудита доступа к привилегированным объектам приводит к переполнению журнала безопасности при первом же резервном копировании. Это связано с тем, что при резервном копировании многократно используется привилегия Backup Operator. Поэтому аудит резервного копирования и восстановления обычно не входит в отчет аудита. Эту политику стоит включать только в том случае, если есть подозрение, что кто-то злоупотребляет своими привилегиями резервного копирования и восстановления. Удостоверьтесь в достаточном размере журнала безопасности и приготовьтесь к очень медленной процедуре резервного копирования.
Rename Administrator account [Guest Account] (Переименовать учетную запись Administrator). Для этой политики запись системного реестра или каталога заблокирована. Учетная запись Administrator напоминает волшебника из произведений Дж. Р. Толкиена. Она обладает инструментами, которые скрыты от обычных пользователей. Это делает учетную запись Administrator наиболее предпочтительной целью атак хакеров. Эта политика позволяет переименовать учетную запись Administrator (и Guest) для их защиты от атак. К сожалению, существуют достаточно простые вызовы API, которые позволяют идентифицировать учетную запись Administrator без использования имени, поэтому такая политика не сможет надолго остановить опытного хакера.
Clear virtual memory page file when system shuts down (Очистить файл подкачки виртуальной памяти при завершении работы системы). Эта политика хранится в разделе HKLM\ System\CurrentControlSet\Control\Session Manager\Memory Management\ ClearPageFileAtShutdown. Очистка файла подкачки при каждом завершении работы является хорошим средством для улучшения безопасности. Эта политика предотвращает хранение важных данных в файле подкачки. Для включения этой политики пользователям потребуется соответствующая системная привилегия.
Shut down system immediately if unable to log security audits (Немедленно завершить работу системы при невозможности аудита событий безопасности). Эта политика хранится в разделе HKLM\System\CurrentControlSet\Control\Lsa\CrashOnAuditFail. Если включен аудит системы, может потребоваться перехват всех событий средствами системы аудита. Если файл журнала оказывается переполнен, некоторые события не будут перехвачены. Таким образом, может потребоваться принудительное отключение системы, как только журнал переполнится. При использовании учетной записке привилегиями администратора можно зарегистрироваться в системе, сохранить и очистить файл журнала безопасности.
Do not allow enumeration of account names and shares by anonymous users (Запретить инвентаризацию учетных записей и ресурсов для анонимных пользователей). Эта политика хранится в разделе HKLM\System\CurrentControlSet\Control\Lsa\ RestrictAnonymous. Она запрещает пользователям без аутентификационных данных получать имена учетных записей и совместно используемых ресурсов на сервере. Дополнительная информация приводится в разделе “Анонимная регистрация”.
Disable Ctrl+Alt+Del requirement for logon (Отключить комбинацию клавиш <Ctrl+Alt+Del> для регистрации). Эта политика хранится в разделе HKLM\Software\Microsoft\ Windows NT\CurrentVersion\Winlogon\DisableCAD. Она позволяет пользователям, не входящим в домен, не регистрироваться и сразу получать доступ к оболочке Explorer. Никогда не включайте эту политику.
Do not display last username in logon screen (He показывать последнее имя пользователя в окне регистрации). Эта политика хранится в разделе HKLM\Software\Microsof t\ Windows NT\CurrentVersion\Winlogon\DontDisplayLastUserName. Иногда удобно автоматически получать введенное имя при регистрации сразу после нажатия комбинации клавиш <Ctrl+Alt+Del>. Но администраторы, уделяющие внимание безопасности, против предоставления злоумышленникам имен пользователей, так как после этого останется только подобрать пароль.
Secure channel: digitally sign secure channel (Защищенный канал: использовать цифровую подпись для защищенного канала). Эта политика хранится в разделе HKLM\System\ CurrentControlSet\Services\Netlogon\Parameters\SealSecureChannel). Эта и следующие две политики предназначены для блокирования конкретного потенциально уязвимого места в системе безопасности операционной системы Windows Server 2003. Рабочие станции и серверы, входящие в домен, связываются с контроллером домена по безопасному каналу RPC. Целостность канала не проверяется, поэтому умный злоумыш-
■3■3
■3
■3
ленник может подставить один компьютер вместо другого и перенаправить передаваемые безопасные данные. Цифровая подпись идентифицирует каждый пакет, который передается по безопасному каналу. При этом происходит небольшое снижение скорости передачи данных (автор не обладает точными цифрами снижения производительности при активизации этой политики.)■
Secure channel: digitally encrypt all secure channel data (Защищенный канал: использовать шифрование для всех данных защищенного канала). Эта политика хранится в разделе HKLMXSystemXCurrentControlSetXServicesXNetlogonXParametersXSignSecur eChannel). Аналогична предыдущей политике, но добавляется шифрование всех передаваемых данных, а не только паролей.
Secure channel: digitally encrypt or sign secure channel (Защищенный канал: использовать шифрование или цифровую подпись для всех данных защищенного канала). Эта политика хранится в разделе HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\ RequreSignOrSeal). Аналогична предыдущей политике, но защищенный канал создается принудительно вместо добровольного автоматического выбора метода защиты. Эту политику необходимо включать только на всех контроллерах домена одновременно.
Encrypt files in the offline folders cache (Шифровать файлы в кэше автономных папок). Эта политика хранится в разделе HKLM\Software\Microsoft\Windows\Current VersionXNetCacheXEncryptEntireCache). Кэширование на стороне клиента позволяет увеличить скорость сетевого доступа. Для этого копии выполняемых файлов и других предназначенных только для чтения файлов хранятся на локальном компьютере. Злоумышленник может скопировать эти файлы и получить ценную информацию. Шифрование файлов снижает производительность, но увеличивает безопасность. Такая зависимость характерна для любых систем безопасности.
Automatically log off users when logon time expires (Автоматически завершать сеанс пользователя по истечении времени регистрации). Эта политика хранится в разделе HKLMX System\CurrentControlSet\Control\Session ManagerXProtectionMode. Можно определить конкретное время суток, после которого пользователю или группе пользователей будет отказано в доступе. Это удобно, когда пользователи должны работать с 8:00 до 17:00, но в остальное время не должны находиться в сети. Эта политика относится к сетевому доступу, а не к возможности локальной регистрации на рабочей станции.:
Message text for users attempting to log on (Текстовое сообщение для регистрирую- . щихся пользователей). Эта политика хранится в разделе HKLMXSof tware\Microsoft\ ’ Windows NTXCurrentVersionXwinlogonXLegalNoticeText). Эта и следующая политики определяют параметры специального окна, которое выводится после нажатия пользователем комбинации клавиш <Ctrl+Alt+Del>, но до появления окна службы Win- 1 logon для ввода регистрационных данных. Чаще всего это окно используется для вывода 1 сообщения отдела кадров вида “Вы используете оборудование компании и должны следо- 1 вать принятым политикам компании”.|
Message title for users attempting to log on (Заголовок сообщения регистрирующим- Л ся пользователям). Эта политика хранится в разделе HKLMXSoftware\Microsoft\ I Windows NT\CurrentVersion\Winlogon\LegalNoticeCaption. Она определяет за- :] головок окна с текстом, заданным с помощью политики LegalNot iceText.|
Number of previous logons to cache (Количество кэшируемых регистраций). Эта полити- | ка хранится в разделе HKLMXSoftwareXMicrosoftXWindows NT\CurrentVersion\ 1 WinlogonXCachedLogonCount. Если рабочая станция не может связаться с контролле- 1 ром домена, пользователь может зарегистрироваться локально с помощью кэшированных | регистрационных данных. По умолчанию для политики задано значение 10. Если сущест- | вует рабочая станция, на которой регистрируется несколько пользователей, некоторые ре- |
гистрации могут быть удалены из кэша. В таком случае для политики можно установить значение 50.
Restrict CD-ROM access to locally logged-on users only (Разрешить доступ к приводу компакт-дисков только локальным пользователям). Эта политика хранится в разделе HKLM\ Software\Microsoft\Windows NT\CurrentVersion\Winlogon\AllocateCDRonis. Требования для уровня безопасности С2 подразумевают отключение сетевого доступа к сменным носителям.
Restrict floppy access to locally logged-on users only (Разрешить доступ к приводу гибких дисков только локальным пользователям). Эта политика хранится в разделе HKLM\Software\ Microsoft\Windows NT\CurrentVersion\Winlogon\AllocateFloppies. (См. описание предыдущей политики).
Send unencrypted password to connect to third-party smb servers (Отправлять незашифрованный пароль при подключении к внешним SMB-серверам). Эта политика хранится в разделе HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel. Если используется устаревшая версия сервера Samba, значит, не поддерживается передача хешированных паролей по протоколу NTLMv2. Установка этой политики позволяет подключаться с использованием хешированных паролей LanMan (LM). Не включайте эту политику. Вместо этого модернизируйте сервер Samba.
Безопасность паролей
Должно быть очевидно, что защищенная паролем компьютерная система не может считаться безопасной, если существует возможность компрометации базы данных с паролями. Операционная система Windows не обладает завидным послужным списком в области безопасности, поэтому важно понимать, как составляются, хранятся и защищаются пароли. Кроме этого, необходимо ознакомиться со всеми доступными утилитами, которые используются злоумышленниками для получения доступа к системным паролям.
В этом разделе также рассматриваются новые возможности операционной системы Windows Server 2003, связанные с использованием паролей.
Кэширование регистрационных данных. Эта возможность позволяет хранить альтернативные регистрационные данные для доступа к изолированным серверам или серверам, которые входят в другой домен.
Диск сброса пароля. Эта возможность позволяет забывшим локальный пароль пользователям изолированного компьютера сбросить пароль во время процедуры регистрации.
Формат паролей и хранилище паролей
Пароль пользователя в операционной системе Windows Server 2003 или любой другой операционной системе на основе Windows NT никогда не хранится в открытой форме. Пароль конвертируется в так называемую одностороннюю функцию (one-way function — OWE), и уже эта функция хранится в базе данных SAM или в базе данных Active Directory. Еще одно название односторонней функции — хеш (hash), поскольку сохраненное в системе значение создается благодаря преобразованию пароля пользователя с помощью криптографического алгоритма, который называется алгоритмом хеширования (hashing algorithm). Система прекращает использование пароля в незашифрованном виде, как только создается хешированная версия пароля. 1
В операционной системе Windows используются два различных метода хеширования пользовательских паролей.
В операционных системах Windows, основанных на DOS (Windows 3.11, Windows 9х и Windows Me), используется алгоритм, основанный на стандарте DES (Data Encryption Standard). Такие хешированные пароли часто называют паролями LanMan (LanMan password), поскольку они используются для аутентификации по протоколу LanMan Challenge- Response.
В операционных системах на основе Windows NT (Windows NT, Windows 2000, Windows Server 2003 и Windows XP) используется алгоритм MD4. MD расшифровывается как message digest (дайджест сообщения). Дополнительная информация по этой теме приводится в главе 18, “Управление инфраструктурой открытого ключа”. Хешированные пароли MD4 часто называют паролями NTLM (NTLM password), поскольку они используются для аутентификации по протоколу NT LanMan Challenge-Response.
На каждой платформе Windows хешированный пароль хранится в специальной базе данных.
В операционных системах Windows на основе DOS хешированный пароль хранится в файле паролей (с расширением . pwl) в каталоге Windows.
В классической операционной системе Windows NT хешированный пароль хранится в базе данных SAM в составе системного реестра. Основной контроллер домена хранит хешированные пароли для всего домена Windows NT и реплицирует содержимое базы данных на вторичные контроллеры домена.'
В современных операционных системах Windows хешированные пароли для локальных учетных записей хранятся в локальной базе данных SAM. Хешированные пароли для учетных записей домена хранятся в базе данных Active Directory.
Взлом паролей
Из двух типов хешированных паролей наиболее уязвимыми являются пароли, хешированные по алгоритму LM (подробный анализ уязвимого места доступен по адресу www .insecure. org/sploits/10phtcrack. lanman. problems . html). Читая этот обзор, обратите особое внимание на возможность злоумышленников восстановить хешированный пароль LM на основе перехваченных фрагментов транзакции LM Challenge-Response. Это позволяет получить пароль без доступа к базе данных SAM или Active Directory. Ниже перечислены основные причины, по которым возможен взлом хешированных паролей LM.
Максимальный размер пароля LM составляет 14 символов.
Пароли хешируются в два компонента по 7 байт, что упрощает раздельный взлом каждого компонента.
Пароль может состоять только из символов ASCII верхнего регистра. Это значительно сокращает множество допустимых символов.
В пароле допускается ограниченное количество специальных символов.
Для создания хешированного пароля LM используется очень простой алгоритм.
Пароли NTLM оказываются более надежными, чем пароли LM. Ниже перечислены причины повышения безопасности. '
В алгоритме хеширования используется 128-разрядный алгоритм MD4, который значительно надежнее алгоритма хеширования DES, используемого при создании паролей LM.
Длина пароля ограничена 128-ю символами, хотя обычные пользователи редко используют пароли длиннее 8 или 10 символов.
Пароли Windows NT содержат символы Unicode, а не ASCII, что теоретически увеличивает безопасность, хотя хакеры обычно предполагают, что пароль содержит только символы
ASCII. Единственный необычный символ в пароле может значительно снизить вероятность его взлома.
Хранение паролей в Active Directory
В базе данных Active Directory пароли хранятся в качестве скрытых атрибутов объектов пользователей и компьютеров.
DbcsPwd. Это пароль LanMan. DBCS расшифровывается как Double-Byte Character Set (двухбайтный набор символов). История паролей LanMan хранится в хешированной форме в атрибуте LmPwdHistory.
UnicodePwd. Это односторонний пароль Windows NT, который используется в операционных системах Windows 2000, Windows Server 2003 и Windows ХР. История паролей хранится в хешированной форме в атрибуте NtPwdHistory.
Начиная с операционной системы Windows NT 4.0 SP4 компания Microsoft предоставила улучшенные обработку транзакций аутентификации и механизм установки сеанса в составе протокола NTLM Challenge-Response. Новая версия протокола, NTLMv2, предоставляется в составе операционных систем Windows 2000, Windows Server 2003 и Windows ХР, а также в составе обновления Dsclient для операционных систем Windows Эх'и Windows Me. По умолчанию операционная система Windows Server 2003 использует устаревший метод аутентификации, если он не заблокирован специальной локальной или групповой политикой.
Взлом хранилища паролей
Программы взлома паролей работают лучше всего, если им на вход предоставить список паролей из базы данных паролей SAM или Active Directory.
Существуют программы, которые копируют хешированные пароли для последующей обработки. Самой популярной является программа pwdump3e. Воспользовавшись ею, хакер с привилегиями администратора может сохранить хешированные пароли в файле, перенести файл на другой компьютер и воспользоваться специальной программой (например, lOphtcrack) для взлома паролей.
Автор этой книги рекомендует всем администраторам обзавестись копиями программ pwdump3e и lOphtcrack для проверки возможности взлома паролей в вашей системе. Скорее всего, скорость взлома большинства паролей вас удивит.
Политики защиты паролей
Установив некоторые групповые политики, можно попытаться усилить безопасность пользовательских паролей. В этом разделе рассматриваются наиболее часто используемые политики защиты паролей.
Откажитесь от использования ненадежных паролей LanMan
Можно установить политику, которая предотвращает хранение паролей LanMan в базе данных Active Directory. Это значительно затрудняет работу таких программ по взлому паролей, как lOphtcrack. Теоретически существует возможность подобрать хешированный пароль NTLM, но этот процесс значительно сложнее, чем при взломе хешированных паролей LM.
Программы взлома паролей
Даже несмотря на то что для хранения паролей LM и NTLM используется необратимый алгоритм хеширования, существует возможность угадать пароль, подобрав слово, хешированный вариант которого совпадет с хешированным паролем.
Алгоритм создания паролей LM и NTLM широко известен. Существует возможность создания списка предварительно хешированных паролей, который позволит ускорить атаку по словарю. Если оригинальный пароль не является распространенным словом, программа взлома паролей попытается создать комбинации символов и чисел, перебирая их, пока не будет найдена подходящая комбинация.
Самой успешной программой взлома паролей является lOphtcrack, хотя существуют и другие программы. Подробная информация о программе lOphtcrack доступна по адресу www.insecure.org/sploits/lOphtcrack.lanman.problems.html. Последняя версия LC3 является платной (версия с ограниченными возможностями доступна для ознакомления) и доступна по адресу www.atstake.com.
Краткий список других приложений для взлома паролей и сканирования систем можно найти по адресу www.insecure.org/tools.html.
Групповая политика, которая управляет этим параметром, называется Network security: Do not store Lan Manager level hash values on next password, change (Сетевая безопасность: не сохранять хеши паролей Lan Manager при следующей смене пароля). Этот параметр устанавливается в политике Default Domain Controllers. Данный параметр расположен в разделе Computer ConfigurationMWindows SettingsMSecurity SettingsM Local Policies1^Security Options (Конфигурация компьютерам Конфигурация WindowsM Параметры безопасности M Локальные политикиМ Параметры безопасности).
Устаревшие пароли не будут удалены из базы данных Active Directory, пока не произойдет смена пароля. При принятом по умолчанию значении политики для смены пароля потребуется 42 дня. Интервал можно уменьшить с помощью политики Maximum Password Age (Максимальный возраст пароля). Этот параметр устанавливается в политике Default Domain. Политика расположена в разделе Computer ConfigurationMWindows SettingsMSecurity SettingsMAccount PoliciesM Password Policy (Конфигурация компьютерам Конфигурация WindowsM Параметры безопасности М Политики аудитам Политики паролей).
Наконец, необходимо отключить все устаревшие механизмы аутентификации, кроме NTLMv2. Это заставит все не связанные с Kerberos транзакции аутентификации использовать наиболее безопасные механизмы обработки паролей. Групповая политика, которая управляет этим параметром, называется Network Settings: Lan Manager Authentication Level (Сетевые параметры: уровень аутентификации Lan Manager) и является частью политики Default Domain Controllers. Эта политика доступна в разделе Computer ConfigurationMWindows SettingsMSecurity SettingsMLocal PoliciesMSecurity Options (Конфигурация компьютерам Конфигурация WindowsM Параметры безопасностиМ Локальные политикиМ Параметры безопасности).
Перед установкой этих политик необходимо переключить клиенты более старых версий на использование аутентификации по протоколу NTLMv2. Для клиентов цод управлением Windows 9х и Windows Me необходимо установить исправление dsclient с установочного компакт-диска Windows Server 2003. Для клиентов под управлением Windows NT 4.0 необходимо установить SP4 или более позднюю версию пакета обновлений.
Кроме этого, необходимо установить запись системного реестра Lmcompatibility на клиентах под управлением Windows 9х и Windows Me. Эта запись системного реестра предотвращает отправку запросов на регистрацию по протоколу LanMan.
Политики блокирования учетных записей
Не стоит предоставлять злоумышленнику возможность ломиться в окно регистрации, пытаясь подобрать пароль. Политика блокирования учетных записей позволяет защититься от такого поведения с помощью блокирования учетной записи после указанного количества неудачных попыток регистрации.
Блокирование учетных записей стоит денег, поскольку результатом блокирования нередко является звонок в службу поддержки. Стоимость блокирования можно минимизировать, установив интервал, после которого блокирование будет снято автоматически. Групповые политики, которые управляют блокированием учетных записей, расположены в разделе Computer Configuration*Windows Settings1*Security Settings*Account Policies*Account Lockout Policy (Конфигурация компьютера1*Конфигурация Windows*Параметры безопасности* Политики учетных записей* Политика блокирования учетных записей). Доступны три параметра управления политикой блокировки.
Счетчик блокировки. Количество разрешенных неудачных попыток регистрации перед блокированием учетной записи.
Изолированные серверы
Все рассмотренные здесь политики могут быть установлены и на изолированных серверах. Об этой возможности стоит помнить, когда сервер находится в демилитаризованной зоне или при других обстоятельствах, когда нет возможности развернуть домен.
Время сброса блокировки. Интервал, после которого счетчик неудачных регистраций устанавливается равным нулю. Например, при времени сброса блокировки, равном 10 минутам, значение счетчика неудачных регистраций будет увеличиваться, если неудачная регистрация выполняется каждые девять минут.
Длительность блокировки. Интервал, по завершении которого блокировка автоматически снимается и пользователю предоставляется возможность повторной регистрации.
Службой Local Security Authority применяется политика блокирования для любой службы, которая предпринимает попытки регистрации по сети. Это касается служб CIFS/SMB, FTP, Telnet и HTTP. Повторные неудачные попытки регистрации с помощью одной из этих служб также приведут к блокированию учетной записи.
Политика блокирования учетных записей имеет очень мало исключений. Учетная запись Administrator не может быть заблокирована, но это исключение не относится к учетным записям с привилегиями администратора. Учетные записи компьютеров не могут быть заблокированы. Точно так не могут быть заблокированы учетные записи доверительных отношений домена.
Обратимые пароли
При аутентификации по протоколу MD5-CHAP и на основе дайджеста необходимо, чтобы сервер знал незашифрованный пароль клиента. Это относится к аутентификации клиентов Macintosh с использованием Random Number Exchange UAM по протоколу AFP (AppleTalk File Protocol) или при удаленном доступе по протоколу ARAP (AppleTalk Remote Access Protocol).
Для этих транзакций невозможно использовать протоколы NTLMv2 или LM, поскольку система хранит односторонние функции, которые не могут быть использованы для восстановления оригинального пароля. Служба Active Directory может использовать механизмы аутентификации на основе пароля, хранящегося в открытой форме. Для этого пароль хранится в зашифрованном виде с возможностью восстановления. Как только клиент MD5-CHAP или Digest попытается получить доступ, система расшифрует пароль и использует результат для проверки личности пользователя.
Групповая политика, которая управляет этими параметрами, называется Store Password Using Reversible Encryption For All Users In The Domain (Хранить пароль с использованием обратимого шифрования для всех пользователей в пределах домена). Политика входит в политику Default Domain и хранится в разделе Computer Configuration*Windows Settings*Security Settings*Account Policies*Password Policy (Конфигурация компьютера* Конфигурация Windows* Параметры безопасности* Политики учетных записей* Политики паролей).
Пароли компьютеров
Рассмотрев некоторые уязвимые места паролей и способы их защиты (или минимизации уязвимостей), перейдем к рассмотрению методов использования паролей в операционной системе Windows.
Клиенты Samba и пароли NTLMv2
Клиенты под управлением более старых версий сервера Samba могут не работать с операционной системой Windows без поддержки обратимых паролей. Новые клиенты Samba используют протокол NTLMv2 и могут выступать в роли контроллеров домена в режиме Windows 2000 Mixed.
Компьютеры, которые входят в домен, имеют пароль, связанный с учетной записью компьютера. Active Directory хранит хеш этого пароля в объекте компьютера, как пользовательские пароли хранятся в объекте пользователя. Кроме аутентификации и авторизации, хешированный пароль компьютера используется для шифрования данных, которые передаются между компьютером и контроллером домена. Это так называемое защищенное соединение RPC. Поток данных в защищенном соединении шифруется с помощью алгоритма RC4 (алгоритм потокового шифрования, лицензированный у компании RSA Security). Хешированный пароль компьютера выступает в роли ключа шифрования.
Диагностика проблем, связанных с паролями компьютеров
Проблемы в работе защищенного канала между компьютером и контроллером домена могут привести к появлению таких ошибок, как Unable to contact domain controller... (Невозможно установить соединение с контроллером домена) при попытке пользователя зарегистрироваться в домене. Если возникает подозрение, что проблема связана с аутентификацией компьютера по сети, проверьте работу защищенного канала с помощью утилиты nltest, как показано ниже (в этом примере используется контроллер домена company. com): nltest /sc_query:company.com
Проблемы в работе службы DNS также могут приводить к ошибкам при аутентификации, поскольку клиент не в состоянии найти контроллер домена, который будет выступать в роли регистрационного сервера. Если при использовании утилиты nltest возникают ошибки, стоит проверить правильность работы сети и правильность преобразования имен.
Пароли компьютеров используются для настройки защищенного соединения и по умолчанию меняются каждые 30 дней. Для этой транзакции к сети должны быть одновременно подключены и компьютер, и регистрационный сервер. Если компьютер, например портативный, отключен от сети, когда наступает момент смены пароля, клиент сменит пароль при следующем подключении к домену.
Смену пароля можно запустить принудительно с помощью утилиты nltest. Для этого можно воспользоваться следующей командой:
nltest /sc_change_pwd:company.com
Если сервер разорвал защищенное соединение и не в состоянии его восстановить, компьютер можно вывести из домена и подключить снова. Самый простой метод для этого заключается в регистрации на сервере и использовании утилиты netdom из состава Resource Kit от имени учетной записи Administrator:'
netdom remove serverl3 /domain:company.com
После этого необходимо воспользоваться следующей командой:
netdom join serverl3 /domain:company.com
Перезагрузите компьютер и подождите установки защищенного соединения с доменом.
Кэш регистрационных данных
В современных операционных системах Windows для доступа к серверам в пределах леса используется единый пароль домена. Это обеспечивается транзитивными доверительными отношениями по протоколу Kerberos. Доступ к серверам за пределами леса, например к серверам в демилитаризованной зоне или в другом домене, требует отдельной транзакции аутентификации с отдельным паролем.
При подключении к серверу за пределами леса выводится запрос на ввод имени и пароля для интересующего компьютера. При междоменной аутентификации может потребоваться ввод доменного имени в следующем формате:
<имя_домена>\<имя_пользователя> пароль
Если это соединение сделано постоянным, при следующей регистрации система восстановит сеанс и выдаст запрос на ввод регистрационных данных.
Компания Microsoft немного упростила управление паролями в операционной системе Windows Server 2003, предоставив новую базу данных для хранения регистрационных данных. Эта база данных доступна через приложение на панели Control Panel (Панель управления), которое называется Stored User Names and Passwords (Сохранение имен пользователей и паролей). Имя и пароль можно хранить в кэше регистрационных данных и воспользоваться ими для автоматической регистрации при подключении к интересующему серверу.
Кэш регистрационных данных хранится в файле, который называется Credentials и находится в профиле пользователя в каталоге Application DataXMicrosoftXCredentialsX <идентификатор_безопасности_пользователя>. Файл зашифрован закрытым ключом пользователя, который, в свою очередь, зашифрован главным ключом шифрования. Дополнительная информация о компонентах инфраструктуры открытого ключа в операционной системе Windows Server 2003 приводится в главе 18, “Управление инфраструктурой открытого ключа".
Имена и пароли в кэше регистрационных данных доступны посредством командной строки и использования команды net use. Например, предположим, что с помощью следующей команды в командной строке подключается сетевой диск: net use * X\serverl3\ shared_folder. Если в кэше регистрационных данных присутствует запись для компьютера Serverl3, то система создаст подключение, не запрашивая у пользователя имя и пароль.
При использовании команды net use для создания подключения можно автоматически сохранить альтернативные регистрационные данные в кэше регистрационных данных. Для этого используется параметр / savecred. Будет выдан запрос на ввод имени и пароля, и в случае упешной регистрации данные будут сохранены в кэше.
Если управление регистрационными данными должно осуществляться из командной строки, воспользуйтесь новой утилитой cmdkey. Эта утилита позволяет создавать, просматривать и удалять регистрационные данные из кэша регистрационных данных. Например, для добавления нового имени пользователя и пароля в кэш можно воспользоваться командой cmdkey /add:<имя_ сервера> /user:<имя_пользователя> /pass: <пароль>. Для просмотра содержимого кэша регистрационных данных воспользуйтесь командой cmdkey /list, например:
C:\>cmdkey /list
Currently stored credentials:
Target: laptop
Type: Domain Password
User: laptopXadministrator
Операционная система Windows Server 2003 позволяет использовать кэш регистрационных данных только для хранения регистрационных данных CIFS/SMB. В следующих версиях будет реализована поддержка хранения регистрационных данных Internet Explorer. Это позволит системе хранить имена и пароли для доступа к Web-сайтам.
Хранение имен и паролей
Последовательность действий для сохранения имени пользователя и пароля описана в процедуре 11.2.
Процедура 11.2. Хранение имен пользователей и паролей
Откройте аплет Stored User Names and Passwords (Сохранение имен пользователей и паролей) в Control Panel (Панель управления).
Щелкните на кнопке Add (Добавить). Откроется окно Logon Information Properties (Свойства регистрационных данных), которое показано на рис. 11.8.
Рис. 11.8. Окно Logon Information Properties из аплета Stored User Names and Passwords (Сохранение имен пользователей и паролей)
Введите полностью определенное доменное имя сервера. “Плоского” имени может быть достаточно, но лучше отвыкнуть от формата имен, который зависит от службы WINS.
Введите имя пользователя в форме <домен>\<имя>. При подключении к изолированному компьютеру введите “плоское” имя компьютера вместо доменного имени, например SERVER1X j jones (это имя не является чувствительным к регистру).
Введите пароль.
Щелкните на кнопке ОК для сохранения изменений. Имя сервера будет отображено в списке.
Кэшированные регистрационные данные
Компания Microsoft неудачно выбрала название Credentials cache (Кэш регистрационных данных) для аплета Stored User Names and Passwords (Сохранение имен пользователей и паролей), поскольку это название уже используется в другом контексте и означает возможность
регистрации в домене при недоступности контроллера домена. В этом контексте кэшированные регистрационные данные хранятся в разделе Secrets узла системного реестра Security (часто этот раздел называется ISA Secrets).
Сброс пароля
Возможность сброса пароля другого пользователя является высокопривилегированной операцией. Изменение пользовательского пароля позволяет зарегистрироваться от имени этого пользователя и получить доступ к его файлам и процессам. Кроме этого, пользовательский пароль защищает открытые ключи пользователя, с помощью которых шифруются файлы, электронная почта и безопасный доступ к Web-сайтам. Пароль также защищает другие открытые ключи, которые используются другими приложениями, основанными на инфраструктуре открытого ключа.
Существуют утилиты, которые позволяют без особых усилий менять пароль пользователя. Например, бесплатная версия ERD Commander 2002 (www.winternals .com) позволяет загрузить компьютер с помощью четырех загрузочных дисков и изменить пароль любого пользователя в локальной базе данных SAM, включая пароль учетной записи Administrator. (Эта утилита не позволяет менять пароли учетных записей в базе данных Active Directory.) При помощи таких утилит, как ERD Commander, можно изменить пароль пользователя и зарегистрироваться в системе от имени этого пользователя для получения доступа к его данным.
Обработка сброса пароля для локальной учетной записи
Операционная система Windows 2000 имеет ряд недостатков, связанных с возможностью сброса пароля. При сбросе пароля локального пользователя в операционной системе Windows 2000 система повторно создает главный ключ шифрования с использованием нового пароля. Это значит, что можно воспользоваться утилитой ERD Commander для изменения пароля локального пользователя, после чего зарегистрироваться от имени этого пользователя и получить доступ ко всем зашифрованным файлам локальной учетной записи пользователя. (Этот недостаток не относится к файлам, которые были зашифрованы, пока пользователь был зарегистрирован в домене.)
В операционных системах Windows Server 2003 и Windows ХР этот недостаток исправлен благодаря сохранению главного ключа шифрования в оригинальном состоянии, кроме случаев изменения пароля с помощью команды Change Password (Смена пароля) в окне Windows Security (Безопасность Windows). Если сбросить локальный пароль пользователя с помощью любого другого механизма, доступ к зашифрованным файлам или любой другой информации, которая защищена с помощью открытого ключа, останется заблокированным. Соответствующее предупреждение будет выдано при попытке сброса пароля средствами аплета Users and Computers (Пользователи и компьютеры) в Control Panel (Панель управления).
Если локальный пароль будет сброшен и пользователь обнаружит, что после сброса невозможно получить доступ к зашифрованным файлам или электронной почте, пользователь может восстановить старый пароль, нажав комбинацию клавиш <Ctrl+Alt+Del> и щелкнув на кнопке Change Password (Смена пароля). Это позволит восстановить доступ к зашифрованным файлам и электронной почте. Чтобы пользователь мог воспользоваться паролем повторно, может потребоваться ослабление требований к истории локальных паролей.
Диск сброса пароля
Одной из самых распространенных причин звонков в службу поддержки является “забытый пароль”. В домене эта проблема может быть быстро решена с помощью сброса пароля пользователя в домене. Если приходится поддерживать изолированные рабочие станции-или серверы, забытый пароль может оказаться серьезной проблемой. Если невозможно получить
физический доступ к компьютеру, пользователю придется позволить зарегистрироваться локально от имени учетной записи Administrator. Это приводит к компрометации пароля (по какой-то причине пользователи, которые не в состоянии помнить свой пароль дольше пяти минут, помнят пароль учетной записи администратора годами).
Эту проблему можно решить с помощью новой возможности операционных систем Windows Server 2003 и Windows ХР. Эта возможность называется Password Reset Disk — PRD (диск сброса пароля). Диск сброса пароля представляет собой созданный пользователем гибкий диск, который содержит специальный ключ, созданный для пользователя операционной системой. Если пользователь забывает свой локальный пароль, он может воспользоваться диском сброса пароля для авторизации сброса локального пароля. Необходимая последовательность действий приводится в процедуре 11.3.
Процедура 11.3. Создание диска сброса пароля
Зарегистрируйтесь с помощью локальной учетной записи. (Диск сброса пароля не относится к доменным учетным записям, так как доменные пароли могут быть сброшены с помощью консоли Active Directory — Users and Computers (Active Directory — пользователи и компьютеры) или с помощью другой утилиты управления доменом.)
Нажмите комбинацию клавиш <Ctrl+Alt+Del> и щелкните на кнопке Change Password (Смена пароля).-
Щелкните на кнопке Backup (Резервная копия). Запустится мастер восстановления пароля Forgotten Password Wizard.
Щелкните на кнопке Next (Далее). Откроется окно Create Password Reset Disk (Создать диск сброса пароля). Вставьте читую отформатированную дискету в привод гибкого диска.
Щелкните на кнопке Next (Далее). Откроется окно Current User Account Password (Текущий пароль учетной записи пользователя). Введите текущий пароль.
Щелкните на кнопке Next (Далее). Мастер запишет аутентификационные данные на гибкий диск.
Щелкните на кнопке Finish (Готово). Мастер завершит работу. После этого гибкий диск будет содержать файл с расширением .pws. В этом файле записан хешированный пароль пользователя.
Если пользователь забудет локальный пароль, выполните последовательность действий, описанную в процедуре 11.4.'
Процедура 11.4. Использование диска сброса пароля для смены локального пароля
Нажмите комбинацию клавиш <Ctrl+Alt+Del> для регистрации.
Введите правильное имя пользователя, но неправильный пароль. Система выдаст сообщение об ошибке и предложит сбросить пароль.
Щелкните на кнопке Reset (Сброс). Запустится Password Reset Wizard (Мастер сброса пароля).
Щелкните на кнопке Next (Далее). Откроется окно Insert Password Reset Disk (Вставьте диск сброса пароля). Вставьте дискету, на которой хранится файл с расширением . pws, в привод гибких дисков.
Щелкните на кнопке Next (Далее). Откроется окно Reset the User Account Password (Сброс пароля учетной записи пользователя). Введите новый пароль и подтверждение нового пароля. Это должен быть новый пароль, а не тот пароль, который находится в базе данных SAM.
Введите подсказку для пароля. Подсказка хранится открытым текстом для каждого пользователя в разделе системного реестра HKLM\Software\Microsoft\Windows\Hints. Подсказка не должна содержать самого пароля. Подсказка “Имя моей жены” не очень подходит, так как эту информацию легко получить. Подсказка “Третий камень от солнца” также нежелательна, кроме случая, если она описывает пароль “johnlithgow”. Подсказка “е в степени пи*1” может быть допустима, но ответ “-1” слишком краток для надежного пароля.
Щелкните на кнопке Next (Далее). Изменение пароля будет сохранено в базе данных.
Щелкните на кнопке Finish (Готово). Мастер сброса пароля завершит работу, и пользователь вернется в окно регистрации. После этого можно ввести новые регистрационные данные и зарегистрироваться в системе.
Содержимое диска сброса пароля
По информации из предыдущего раздела можно догадаться, что если диск сброса пароля попадет в руки злоумышленника, то он получит несанкционированный доступ к системе. Вот краткое описание содержимого файла на диске сброса пароля.
Файл с расширением . pws содержит цифровую подпись, которая идентифицирует пользователя, создавшего файл. Подпись не содержит пароля пользователя и не основана на пароле. Кроме этого, для создания файла не используется информация из инфраструктуры открытого ключа, поэтому цифровая подпись не связана с пользовательским профилем.
Подпись содержит информацию, связанную с конкретным пользователем на конкретном компьютере, поэтому диск сброса пароля нельзя использовать для сброса пользовательского пароля на другом компьютере. Кроме этого, информация в файле с расширением . pws не связана с профилем пользователя. Пользовательский профиль можно удалить, и пользователь все равно сможет использовать диск сброса пароля для регистрации в системе.
Диск сброса пароля нельзя использовать для замены пароля существующим паролем независимо от текущих параметров безопасности истории паролей. Транзакция сброса пароля должна действительно изменить пароль. Новый пароль должен соответствовать всем требованиям к сложности, указанным в локальных параметрах безопасности.
При сбросе пароля с помощью диска сброса пароля не теряется доступ к зашифрованным файлам или другим компонентам, защищенным подсистемой инфраструктуры открытого ключа. Это касается зашифрованной электронной почты и защищенных Web-сайтов.
После регистрации с помощью нового пароля его можно заменить старым паролем (который необходимо вспомнить), нажав комбинацию клавиш <Ctrl+Alt+Del> и щелкнув на кнопке Change Password (Смена пароля).
Если администратор меняет локальный пароль пользователя, пользователь все равно может воспользоваться диском сброса пароля.
При сбросе пароля с помощью диска сброса пароля будут утрачены все записи в кэше регистрационных данных, созданные средствами аплета Stored User Names and Passwords (Сохранение имен пользователей и паролей), доступного в Control Panel (Панель управления).
Если администратор удаляет локальную учетную запись пользователя и создает еще одну учетную запись с тем же именем, диск сброса пароля не будет работать для новой учетной записи.
Пользователь, для которого созданы учетные записи на нескольких компьютерах, не может использовать диск сброса пароля, работая на одном компьютере для сброса пароля на другом компьютере.
Файл с расширением . pws можно скопировать на другой гибкий диск и воспользоваться для сброса пароля копией гибкого диска.
Один и тот же файл с расширением . pws может использоваться любое количество раз в пределах описанных ранее ограничений. Система отслеживает использование диска сброса пароля, внося записи в файл истории (credhist) в пользовательском профиле в каталоге Application DataXMicrosoftXProtect.
Анонимная регистрация
Когда принадлежащий пользователю процесс получает доступ к ресурсу удаленного сервера под управлением Windows, сетевое приложение (например, CIFS/SMB или Winsock) выполняет аутентификацию прозрачно для пользователя.
Если процесс принадлежит учетной записи Local System или другой учетной записи, для которой не задан сетевой контекст безопасности, он не может пройти аутентификацию на удаленном сервере. Вместо этого предпринимается попытка создания нулевого сеанса (null session) с удаленным сервером.
Только несколько серверных процессов в операционной системе Windows создавались с возможностью поддержки нулевых сеансов. Например, когда клиент сканирует список ресур- , сов на сервере в окне Network Neighborhood (Мое сетевое окружение), сетевая файловая система создает нулевой сеанс с сервером для получения списка ресурсов.
Каждый процесс должен иметь маркер доступа, поэтому когда локальный сервер создает маркер доступа для нулевого соединения, он добавляет к маркеру идентификатор безопасности учетной записи Anonymous Logon. По этой причине термины нулевой сеанс (null session) и анонимная регистрация (anonymous logon) можно считать в какой-то степени синонимами в операционной системе Windows.
В классической операционной системе Windows NT и в операционной системе Windows 2000 учетная запись Anonymous Logon входит в группу Everyone. Это позволяет процессу в контексте нулевого сеанса получать доступ к достаточно большому объему информации о сервере. Это привело к появлению множества утилит, предназначенных для сканирования служб NetBIOS и других служб, позволяющих устанавливать соединения на основе нулевых сеансов. В качестве примера можно привести программу сканирования по сети LanGuard, доступную для бесплатной загрузки по адресу www.languard.com/languard/ lanscan. htm. На рис. 11.9 показан пример отчета утилиты LanGuard при сканировании вторичного контроллера домена под управлением операционной системы Windows NT 4.0. Операционная система Windows Server 2003 предоставит намного меньше информации, поскольку на нулевые сеансы наложены дополнительные ограничения.
В операционной системе Windows Server 2003 учетная запись Anonymous Logon не является членом группы Everyone. Это позволяет ограничить объем информации, доступной программе сканирования NetBIOS. При этом значительный объем информации можно по- прежнему получить, используя обычное сканирование портов.
Если программы сканирования, использующие метод нулевого сеанса, представляют угрозу, следует включить групповые политики, которые блокируют анонимную инвентаризацию совместно используемых ресурсов и имен учетных записей. Эти политики расположены в разделе Computer ConfigurationMWindows SettingsM Security SettingsMLocal Policies^ Security Policies (Конфигурация компьютерам Параметры WindowsM Параметры безопасно- стиМ Локальные политикиМ Политики безопасности). Вот названия этих политик.
Network access: Do not allow enumeration of SAM accounts (Enable) (Сетевой доступ: не разрешать инвентаризацию учетных записей SAM) (Включена)
Network access: Do not allow enumeration of SAM accounts and shares (Enable) (Сетевой доступ: не разрешать инвентаризацию учетных записей SAM и совместно используемых ресурсов) (Включена)
CGate rfaMtoCGate rfaMtoNetwork access: Let Everyone permission aplly to anonymous users (Disable) (Сетевой доступ: применять разрешения группы Все к анонимным пользователям) (Отключена)
CGate rfaMto
CGate rfaMto
5 I ASqudi U Network Scanner v(1.25)
i Fb Edt Иан Scan 16* UWgued H*
^ IPadcle*orl»*wetaican.
|l92169010
В m NETBIOS names (9)
33Username: BDC MAC: 00-50-56-4(W5-3E
3
3
2 LAN Manager: NT LAN Manager 4.0
3 Domain: NT-DOM
3 Computer usage: NT/2k PDC (Primary Domain Controler)
Й ^ь Trusted domains (1) □ COMPANY
й ^ Shares (5)
£2 NETLOGON • Logon server share c
•Pl ADMINS - Remote АЛтйп
■^ 'PCS • Remote IPC
•Pl C$ • Default share
ffl ^ Users (27)
В ЦР Network devices (2)
; # \Device\NelBT_AMDPCN1 (00-5O-56-40-O5-3E) Ц? \Device\NetBT_AMDPCN1 |00-50-56^005-3E)
В Remote TOD (time of day)
: 3 Time of d»: 29 Nov 2001,21:49.38: GMT-7
— И UpTime. 1 days, 19hours,36minutes,21 seconds
@ Open Ports (2)
. о 1351 epmap •> DCE endpoint resolution 1 о 139 ['Netbios-ssn ■> NETBIOS Session Service [
Puc. 11.9. Сканирование служб NetBIOS и открытых портов с помощью программы LanGuard
Могут существовать совместно используемые ресурсы, к которым необходимо предоставлять анонимный доступ, например сетевой принтер. В таком случае ресурс можно добавить в групповую политику Network access: Shares that can be accessed anonymously (Сетевой доступ: совместно используемые ресурсы, которые могут использоваться анонимно).
Аутентификация
До этого момента мы рассматривали только элементы поддержки в деле обеспечения безопасности сетевого доступа. Было показано, как один компонент триумвирата безопасности — авторизация, обеспечивает контроль за доступом к ресурсам. Теперь пришло время встретиться с главной звездой шоу — процессом, который управляет аутентификацией. Леди и джентльмены, подготовьтесь к встрече с Kerberos'.
Протокол Kerberos был разработан в MIT в составе проекта Athena. В операционной системе Windows Server 2003 реализован протокол Kerberos версии 5, выпуск 6, который определен в документе RFC 1510, “The Kerberos Network Authentication Service V5”. Все современные платформы Windows (Windows Server 2003, Windows XP и Windows 2000) используют
эту версию протокола Kerberos, что делает их полностью совместимыми друг с другом. В операционной системе Windows Server 2003 поддерживается возможность создания доверительных отношений с системами MITv5 Kerberos. Эта тема более подробно рассматривается далее в этом разделе.
Ограничения классической аутентификации Windows NT
Первый вопрос, который возникает при знакомстве с протоколом Kerberos, — “Зачем менять протокол?”. В конце концов классический протокол NTLM Challenge-Response работал достаточно хорошо. А улучшенная версия протокола, NTLMv2, неплохо справляется с блокированием атак.'
Несмотря на усовершенствования в протоколе NTLMv2, классический механизм аутентификации имеет несколько уязвимых мест и ограничений. Рассмотрим краткий список таких ограничений.
■ Сквозная аутентификация. Как только клиент запрашивает доступ к ресурсу классического сервера, сервер должен создать транзакцию Challenge-Response с контроллером домена от имени клиента для проверки личности клиента. Это замедляет процедуру аутентификации и открывает возможность атаки типа “отказ в обслуживании” или перехвата регистрационных данных клиента.
■ Односторонняя аутентификация. При использовании протокола NTLM контроллер домена или сервер выполняет аутентификацию клиента с использованием сквозной аутентификации, но клиент никогда не проверяет надежность контроллера домена или сервера. Это создает возможность для атак типа “посредник”.
Происхождение названия "Kerberos"
Название "Kerberos" происходит от имени мифологического трехголового пса Цербера, который охранял врата подземного мира. Это связано с тем, что протокол использует три компонента для выполнения транзакции.
Клиент (который называется участником системы безопасности)
Запрашиваемый сервер (который называется проверяющим сервером)
Центральное хранилище регистрационных данных (которое называется центром распространения ключей; Key Distribution Center — KDC)
Если вас интересует информация о происхождении названия "Kerberos" и подробности мифологического происхождения названия, обратите внимание на "Руководство по Kerberos для полных идиотов" ("Moron's Guide to Kerberos"), доступное по адресу www.isi.edu/ -brian/security/kerberos.html.
■ Неограниченное время регистрации. После того как пользователь получил доступ к домену после аутентификации по протоколу NTLM, он может оставаться в домене неограниченное время, если администратор не настроил определенное время завершения сеанса. Это означает, что злоумышленник, которому удалось перехватить набор регистрационных данных, может использовать их неограниченное время.
Отсутствие поддержки транзитивных доверительных отношений. В классическом домене Windows NT, в котором работает несколько серверов, выполняющих роли хозяев, пользователи одного домена могут получать доступ к ресурсам только в тех доменах, с которыми установлены непосредственные доверительные отношения. Если домен А доверяет
домену Б, а домен Б доверяет домену В, пользователи домена В не могут получать доступ к ресурсам домена А.
Отсутствие поддержки делегирования. Если клиент инициирует процесс на удаленном сервере Windows NT, процесс не может получать доступ к ресурсам другого сервера. Это ограничивает возможность WindowsNT поддерживать многоуровневые сетевые приложения. (В качестве примера многоуровневого сетевого приложения можно привести базу данных, в которой на одном сервере работает процесс, реализующий бизнес-логику, а на другом сервере работает база данных.)
Методы аутентификации, поддерживаемые операционной системой Windows Server 2003
Несмотря на ограничения протокола NTLMv2, в операционной системе Windows Server 2003 этот протокол по-прежнему поддерживается для сохранения обратной совместимости. В домене Active Directory по умолчанию используется механизм аутентификации Kerberos. Механизм аутентификации выбирается автоматически и прозрачно для пользователя.
Операционная система Windows Server 2003 использует аутентификацию Kerberos в следующих ситуациях.
Аутентификация современных клиентов Windows (под управлением операционных систем Windows Server 2003, Windows ХР и Windows 2000) при регистрации в домене Active Directory.
Аутентификация современных клиентов Windows при доступе к серверам под управлением современных версий Windows, которые являются членами домена Active Directory.
Аутентификация современных клиентов Windows, которые пытаются получить доступ к ресурсам одного домена из другого домена Active Directory в пределах одного леса, из другого леса Active Directory с помощью доверительных отношений между лесами или из сферы MIT v5 Kerberos Directory с помощью доверительных отношений между сферами.
Операционная система Windows Server 2003 использует протокол аутентификации NTLMv2 в следующих ситуациях.
Аутентификация современных клиентов Windows, регистрирующихся в классическом домене Windows NT.
Аутентификация классических клиентов Windows NT при регистрации в домене Active Directory.
Аутентификация классических и современных клиентов Windows NT при попытке доступа к серверам в домене Active Directory с помощью внешнего доверительного отношения.
Аутентификация пользователей, которые регистрируются на изолированных серверах под управлением современной операционной системы Windows.
Аутентификация клиентов устаревших версий, получающих доступ к ресурсам на сервере под управлением современной операционной системы Windows, когда клиент настроен с использованием надстройки Active Directory.
Операционная система Windows использует протокол аутентификации LM для поддержки клиентов Windows 9х, на которых не было установлено расширение Active Directory, Dsclient.exe.
Чтобы определить использованный метод аутентификации определенного пользователя, необходимо включить аудит регистрации/завершения сеанса.
Обзор транзакций Kerberos
Протокол Kerberos использует три компонента для аутентификации пользователей.
Участник системы безопасности, который пытается получить доступ к сетевым ресурсам. Это может быть пользователь или служба, запущенная на компьютере.
Проверяющий сервер, который получает запрос на подключение участника системы безопасности и должен проверить личность пользователя.
Сервер распространения ключей, который хранит регистрационные данные участника системы безопасности и проверяющего сервера. Сервер распространения ключей выдает специальные сообщения, которые называются билетами (ticket) и используются другими компонентами для идентификации друг друга.
Транзакции Kerberos напоминают фрагмент книги о шпионах Джона Ле Карре. Представьте, что агенту необходимо вступить в контакт со своей шпионской организацией. Агент отправляет заранее оговоренный сигнал, а организация соглашается выслать связного. Агент никогда не видел связного. Связной никогда не видел агента. Как они узнают друг друга при встрече? Просто. У них есть общий знакомый — шеф в штабе организации. В процедуре 11.5 описана последовательность идентификации.
Процедура 11.5. Абстрактный пример использования протокола Kerberos
Связной вызывает шефа и говорит: “Назовите мне пароль, который знаете только вы и агент”.
Всегда думающий о безопасности шеф проверяет личность связного, пытаясь определить, было ли сообщение зашифровано секретным ключом шифрования связного.
После этого шеф просматривает досье на агента и связного. В досье указаны секретные ключи шифрования, которые известны только участникам системы безопасности.
После этого шеф создает сообщение агенту. Сообщение состоит из двух частей.
Первая часть содержит выдуманное шефом случайное число, зашифрованное секретным ключом связного.
Вторая часть содержит случайное число, имя связного и точное время (и дату), когда шеф написал сообщение. Эта часть шифруется секретным ключом агента.
Связной использует собственный секретный ключ для декодирования случайного числа в собственной части сообщения. Если в результате получается бессмысленный набор цифр, связной может предположить, что кто-то выдал себя за шефа и передал ему поддельное сообщение. Если число правильно, часть сообщения для агента остается на хранении у связного.
В этот же день агент и связной встречаются. Они обмениваются именами, и связной передает агенту вторую часть сообщения шефа. Они внимательно следят друг за другом, так как наступил момент Квентина Тарантино. (Если вы не смотрели фильм “Бешенные псы”, прекратите чтение и посмотрите этот фильм.) Вот что происходит в этот момент.
Еслц агент не может декодировать сообщение шефа, он делает вывод, что связной ненастоящий, и стреляет в него.
Если агент декодирует сообщение, но содержимое пакета повреждено, агент знает, что связной пытался изменить сообщение. Агент стреляет в связного.
Если агент декодирует сообщение и имя связного не совпадает с именем в сообщении, агент стреляет в связного.
Если агент уже сталкивался с этим случайным числом, он стреляет в связного.
Если не выполняется ни одно из этих условий, агент передает пакет связному. На пакете указаны имя агента, текущее время и общее количество сообщений в пакете. Пакет зашифрован с помощью полученного от шефа случайного числа, которое используется в качестве ключа шифрования.
Связной использует полученное от шефа случайное число для декодирования пакета связного. Если результат декодирования оказывается бессмысленным, значит, агент подставной, и связной стреляет в агента. Если содержимое дешифруется правильно, но метка времени устарела, агент предоставил старый пакет, и связной стреляет в агента.
Если связной может декодировать пакет агента и содержимое удовлетворяет всем критериям, аутентификация считается завершенной, и они начинают обмениваться информацией.
Объемные метафоры приводят к не совсем корректным примерам, но игра Я знаю секрет, а ты? удачно описывает механизм аутентификации Kerberos. Фактически транзакции оказы- ваются более сложными, но только потому, что участники системы безопасности не могут встретиться лицом к лицу. Они отправляют сообщения по общедоступной сети и обязаны предполагать, что злоумышленник находится в сети между ними и перехватывает все передаваемые пакеты для проникновения в защищенные сети.
Перед подробным рассмотрением транзакций аутентификации важно разобраться, какие термины и выражения используются для описания протокола Kerberos. Терминология Kerberos значительно отличается от терминологии, которая применялась в классическом протоколе NTLM.
Словарь Kerberos
Протокол Kerberos существовал в свободном использовании в течение многих лет. В результате возник собственный язык терминов этого протокола с достаточно разветвленной терминологией. Смесь этой терминологии с терминологией классического механизма аутентификации WindowsNT привела к формированию такого жаргона, который удивляет даже опытных специалистов по стандартам сетевых систем. Далее рассматриваются термины протокола Kerberos, а также приводится их соответствие терминам классического механизма аутентификации Windows NT.
Участник системы безопасности
Механизм аутентификации проверяет подлинность элемента системы безопасности, который желает получить доступ к ресурсам. В протоколе Kerberos такой элемент называется участником системы безопасности (security principal) или просто участником (principal). В операционной системе Windows участникам системы безопасности соответствуют пользователи (user) и компьютеры (computer).
Сфера
Каждая система аутентификации (не исключая Kerberos) нуждается в базе данных, которая будет хранить регистрационные данные. Сфера (realm) Kerberos определяется содержимым этой базы данных. В операционной системе Windows Server 2003 термины домен (domen) и сфера (realm) являются синонимами. Все объекты домена, включая объекты участников системы безопасности, хранятся в единственной базе данных Active Directory.
Билет
Билет (ticket) является фундаментальной единицей обмена в транзакциях Kerberos. Билет содержит зашифрованную информацию, которую могут прочитать только три участника транзакции. Билет обладает специальными свойствами, которые предотвращают его кражу, повторное использование или изменение его содержимого.
Центр распространения ключей
Это центральная служба, которая выполняет аутентификацию участников системы безопасности и распространяет билеты. (В реализации протокола Kerberos от MIT эти функции могут выполняться разными серверами.)
Функция выдачи билета
При каждой попытке обратиться к серверу по сети участник системы безопасности должен предоставить серверу билет Kerberos. Участник системы безопасности получает билет от службы выдачи билетов центра распространения ключей. В операционной системе Windows Server 2003 служба выдачи билетов интегрирована в основной пакет безопасности Kerberos и не представлена отдельным пунктом в списке процессов.
Функции аутентификации
Перед тем как участники системы безопасности получат билет Kerberos, центр распространения ключей должен проверить подлинность этих участников. Служба аутентификации в центре распространения ключей выполняет эту функцию, сверяя аутентификационные данные участников безопасности с содержимым базы данных безопасности.
Как только центр распространения ключей успешно аутентифицирует участника безопасности во время начальной аутентификации, он предоставляет специальный билет, который называется билетом TGT (Ticket-Granting Ticket — билет на получение билетов). Как только участнику системы безопасности требуется доступ к конкретному серверу, он обращается к центру распространения ключей за билетом сеанса доступа (session ticket) для доступа к конкретному серверу. Участник системы безопасности, чтобы ускорить процедуру получения билета сеанса доступа, предоставляет центру распространения ключей билет TGT.
Система билетов TGT и билетов сеансов доступа напоминает сельские ярмарки в США. После оплаты на входе на руку посетителя ставится небольшая печать. Печать не дает права входа на аттракционы. Для этого необходимо приобрести отдельные билеты. При этом персонал аттракциона проверяет наличие печати на руке, которая подтверждает, что посетитель вошел на ярмарку через основные ворота.
Учетная запись krbtgt
Когда центр распространения ключей выдает билет TGT участнику системы безопасности, он нуждается в методе защиты билета TGT от изменения между моментом выдачи и моментом предоставления для получения билета сеанса доступа.
Центр распространения ключей защищает билеты TGT с помощью шифрования секретным ключом, который известен только центру распространения ключей. Этот секретный ключ имеет форму хешированного пароля, который хранится, как атрибут учетной записи krbtgt. Эту учетную запись можно обнаружить в контейнере Users консоли Active Directory — Users and Computers (Active Directory — пользователи и компьютеры).
Учетная запись krbtgt создается автоматически при повышении и модернизации первого контроллера домена. Эта учетная запись не может быть удалена или переименована. Пароль можно изменить, но делать это не рекомендуется. Если пароль krbtgt окажется известным, будет скомпрометирована вся система аутентификации. Для учетной записи krbtgt создается длинный-и сложный пароль. Система регулярно автоматически меняет этот пароль.
Проверяющий сервер
Проверяющий сервер Kerberos (validating server) является эквивалентом рядового сервера под управлением Windows Server 2003. Проверяющий сервер является третьим компонентом транзакции Kerberos. Как только клиент пытается получить доступ к ресурсу на сервере, кли-
ентская система предоставляет билет сеанса доступа Kerberos проверяющему серверу. Проверяющий сервер проверяет билет на наличие информации, выданной центром распространения ключей и зашифрованной секретным ключом проверяющего сервера.
Проверяющий сервер должен принадлежать той же сфере Kerberos, что и центр распространения ключей, который выдал билет сеанса доступа. Об этом важно помнить, если планируется осуществлять аутентификацию через границы сфер.
Структура билета Kerberos
Билет Kerberos является исключительно важным компонентом процесса аутентификации, поэтому желательно подробно рассмотреть его структуру. На рис. 11.10 показана структура билета (или билета TGT) и сообщения, в котором передается билет.
Информация о сеансеклиентаИнформация о сеансеклиентаИнформация проверяющего сервера(зашифрована с помощьюхешированного пароля сервера)Информация проверяющего сервера(зашифрована с помощьюхешированного пароля сервера)Отправленный клиенту ответ (зашифрован спомощью хешированного пароля клиента)
Информация о сеансеклиента
Информация о сеансеклиента
Информация проверяющего сервера(зашифрована с помощьюхешированного пароля сервера)
Информация проверяющего сервера(зашифрована с помощьюхешированного пароля сервера)
КлючсеансаКлючсеансаФлагиФлагиНомерверсиибилета (v5для Windows2000 иWindowsServer 2003)Номерверсиибилета (v5для Windows2000 иWindowsServer 2003)МеткавремениМеткавремениНачальноевремяНачальноевремяСфера(домен, вкоторомбыл выданбилет)Сфера(домен, вкоторомбыл выданбилет)КонечноевремяКонечноевремяОбновить доОбновить доКлюч сеансаКлюч сеансаСфера клиентаСфера клиентаИмя клиентаИмя клиентаПромежуточные сферыПромежуточные сферыМетка времени выпуска билетаМетка времени выпуска билетаНачальное время(момент времени,после которого билет считается действительным)Начальное время(момент времени,после которого билет считается действительным)Конечное время(момент времени, после которого билет считается недействительным)Конечное время(момент времени, после которого билет считается недействительным)Данные авторизации (используются в реализации Microsoft Kerberos для хранения сертификата привилегий доступа)Данные авторизации (используются в реализации Microsoft Kerberos для хранения сертификата привилегий доступа)флаги (Forwardable, Forwarded, Proxiable, Proxy, Renewable, Initial (TGT))флаги (Forwardable, Forwarded, Proxiable, Proxy, Renewable, Initial (TGT))Конкретныйадрес клиента,с которогоможетиспользо-ваться билет(Необязательно)Конкретныйадрес клиента,с которогоможетиспользо-ваться билет(Необязательно)Обновить до(максималь-ный интервал,в течениекоторогоподдержи-ваетсявозобнов-ление билета)Обновить до(максималь-ный интервал,в течениекоторогоподдержи-ваетсявозобнов-ление билета)
Ключсеанса
Ключсеанса
Флаги
Флаги
Номерверсиибилета (v5для Windows2000 иWindowsServer 2003)
Номерверсиибилета (v5для Windows2000 иWindowsServer 2003)
Меткавремени
Меткавремени
Начальноевремя
Начальноевремя
Сфера(домен, вкоторомбыл выданбилет)
Сфера(домен, вкоторомбыл выданбилет)
Конечноевремя
Конечноевремя
Обновить до
Обновить до
Ключ сеанса
Ключ сеанса
Сфера клиента
Сфера клиента
Имя клиента
Имя клиента
Промежуточные сферы
Промежуточные сферы
Метка времени выпуска билета
Метка времени выпуска билета
Начальное время(момент времени,после которого билет считается действительным)
Начальное время(момент времени,после которого билет считается действительным)
Конечное время(момент времени, после которого билет считается недействительным)
Конечное время(момент времени, после которого билет считается недействительным)
Данные авторизации (используются в реализации Microsoft Kerberos для хранения сертификата привилегий доступа)
Данные авторизации (используются в реализации Microsoft Kerberos для хранения сертификата привилегий доступа)
флаги (Forwardable, Forwarded, Proxiable, Proxy, Renewable, Initial (TGT))
флаги (Forwardable, Forwarded, Proxiable, Proxy, Renewable, Initial (TGT))
Конкретныйадрес клиента,с которогоможетиспользо-ваться билет(Необязательно)
Конкретныйадрес клиента,с которогоможетиспользо-ваться билет(Необязательно)
Обновить до(максималь-ный интервал,в течениекоторогоподдержи-ваетсявозобнов-ление билета)
Обновить до(максималь-ный интервал,в течениекоторогоподдержи-ваетсявозобнов-ление билета)
Рис. 11.10. Ответное сообщение по протоколу Kerberos, содержащее билет TGT или билет се анса доступа
Номера портов, которые используются механизмом Kerberos
Администратор брандмауэра должен знать номера портов, которые используются механизмом аутентификации Kerberos. Центр распространения, ключей под управлением операционной системы Windows использует следующие порты:
• TCP- и UDP-порт 88 для аутентификации и выдачи билетов;
1
» TCP- и UDP-порт 464 для классического протокола Kerberos kpasswd (сброс пароля). В операционной системе Windows не используется.
Когда клиент запрашивает билет TGT или билет сеанса доступа, ответ от центра распространения ключей содержит два фрагмента: заголовок, который может быть прочитан клиентом, и сам билет TGT или билет сеанса доступа.
Информация дЛя клиента шифруется с помощью хешированного пароля клиента и не может быть прочитана злоумышленником, который перехватывает пакеты в сети.
Билет TGT зашифрован с помощью хешированного пароля учетной записи krbtgt. Билет TGT может быть прочитан только контроллером домена, поскольку только контроллер домена имеет доступ к хешированному паролю учетной записи krbtgt. Это позволяет проверять аутентичность и источник билета TGT.
Билет сеанса доступа зашифрован с помощью хешированного пароля сервера, который с точки зрения Kerberos является проверяющим сервером. Это позволяет проверить подлинность билета сеанса доступа.
Ниже рассмотрены основные составляющие ответного сообщения.
Ключ сеанса. Это важное поле содержит случайное число, которое уникально идентифицирует билет TGT или билет сеанса доступа. Копия ключа сеанса включается в состав билета TGT или билета сеанса доступа. Ключ сеанса становится общим секретом, который используется проверяющим сервером и участником системы безопасности при проверке подлинности друг друга.
Имя проверяющего сервера. Имя сервера, доступ к которому хочет получить пользователь.
Имя сферы. Это сфера Kerberos (домен Windows) центра распространения ключей, который выдал билет TGT или билет сеанса доступа.
Флаги. Последовательность флагов, установленная центром распространения ключей, определяет допустимое использование билета сеанса доступа или билета TGT. Флаги определяют возможность передачи билета в другую сферу, что позволяет пользователям из одного домена получать доступ к серверам в доверенном домене. Кроме этого, центр распространения ключей может установить флаг, позволяющий серверу использовать билет в качестве “посредника” оригинального клиента для доступа к другому серверу. В операционной системе Windows такая операция называется делегированием доверительных отношений (delegation of trust).
Начальное и конечное время. Эта информация определяет временной интервал, в пределах которого билет является действительным. После истечения срока действия билета участник системы безопасности должен получить новый билет. Это позволяет ограничить время, в течение которого злоумышленник может наносить вред в случае перехвата билета.
Номер версии билета. Операционная система Windows использует протокол Kerberos версии 5.
Зашифрованный билет или билет TGT содержит следующие поля.
Ключ сеанса. Это копия ключа сеанса, предоставленного клиенту.
Имя клиента и сферы. В этом поле проверяющему серверу предоставляется информация i о клиенте и сфере, в которой хранится секретный ключ клиента. Если клиент сообщает о ; себе информацию, не совпадающую с информацией в билете, проверяющий сервер может ■ считать, что кто-то перехватил билет.
Промежуточные сферы. Пользователь из одной сферы может попытаться получить дос- 1 туп к ресурсам проверяющего сервер» из другой сферы. Это возможно, если между сферами существует доверительное отношение. Доверительное отношение принимает роль участника системы безопасности одной сферы, которого можно использовать для проверки
подлинности участника системы безопасности в доверенном домене. При наличии доверительного отношения центр распространения ключей может выдавать межсферные билеты TGT (cross-realm TGT) участникам системы безопасности из других доменов. Если клиент предоставляет межсферный билет TGT, центр распространения ключей просматривает содержимое поля Trasited realms (Промежуточные сферы), чтобы убедиться, что клиент находится в сфере, с которой существуют межсферные доверительные отношения. Это позволяет реализовать транзитивные доверительные отношения, которые операционная система Windows использует для создания деревьев и лесов Active Directory.
Метки времени. Билет TGT или билет сеанса доступа содержит три различные метки времени: время выдачи билета, время, когда билет стал действительным (для билетов с отложенной датой активизации), и время, когда билет перестал быть действительным. Операционная система Windows не использует и не принимает билеты с отложенной датой активизации билета.
Время истечения срока действия определяется значением поля Time-To-Live (TTL — время жизни), которое задается в центре распространения ключей! В операционной системе Windows принятое по умолчанию время жизни билета составляет 10 часов. Для правильной работы меток времени все центры распространения ключей в пределах сферы должны иметь синхронные показания часов. Для синхронизации времени между контроллерами домена операционная система Windows использует службу W32Time. Допустимая разница во времени может достигать пяти минут.
Данные авторизации. Это очень важное поле, на которое обращается особое внимание в реализации протокола Kerberos от компании Microsoft.
Дополнительные элементы Kerberos
Поскольку мир полон злодеев, в протокол Kerberos встроена защита от наиболее вероятных сценариев атаки. Самыми вероятными атаким являются кража билетов, атаки типа “отказ в обслуживании” и атаки типа “посредник”.
Аутентификатор
Если злоумышленник сможет извлечь ключ сеанса из пакета, он сможет действовать от имени клиента и нанести серьезный ущерб. Для предотвращения такой ситуации в запрос на соединение между участником системы безопасности и проверяющим сервером добавляется небольшой фрагмент данных, который называется аутентификатором (authenticator).
Аутентификатор состоит из имени клиента и имени сферы, а также метки времени. Клиент шифрует аутентификатор с помощью ключа сеанса, который представляет собой случайное число, помещенное в билет сеанса доступа центром распространения ключей. Клиент знает значение ключа сеанса, поскольку он получает ключ сеанса в соответствующей половине ответа с билетом сеанса доступа.
Когда проверяющий сервер получает запрос на доступ, он дешифрует билет с помощью собственного хешированного пароля. После этого от проверяющего сервера требуется принятие решения.
Если сервер не может дешифровать билет или данные внутри билета изменились, он сразу отказывает в установке соединения.
Если сервер может дешифровать билет сеанса доступа, он извлекает ключ сеанса из билета и использует полученный ключ для дешифровки аутентификатора. Если сервер не в состоянии дешифровать аутентификатор, он предполагает, что злоумышленник соединил билет и аутентификатор. Сервер должен отказать в соединении.
После этого сервер сравнивает содержимое дешифрованного аутентификатора с информацией в запросе на соединение. Если имена клиента и сферы не совпадают, сервер предполагает, что злоумышленник изменил аутентификатор. Сервер отказывает в соединении.
Если регистрационные данные пользователя совпадают, но метка времени находится за пределами допустимого срока действительности величиной пять минут, сервер предполагает, что злоумышленник похитил аутентификатор для дальнейшего использования. Сервер отказывает в соединении.
Если метка времени точно соответствует метке времени более раннего аутентификатор», сервер предполагает, что злоумышленник пытается повторить более раннее соединение, и отказывает в соединении. Если сервер “запутается” в подключениях клиента, он будет отказывать во всех соединениях в течение пятиминутного интервала.
Если билет сеанса и аутентификатор выдержали тест проверяющего сервера, клиенту предоставляется доступ. Теперь рассмотрим, как протокол Kerberos защищается от атаки типа “посредник”.
Предварительный аутентификатор
Эволюция компьютерных технологий привела к тому, что DOS больше не расшифровывается как Disk Operating System (дисковая операционная система). Теперь эта аббревиатура чаще расшифровывается как Denial of Service (отказ в обслуживании). Одной из наиболее вероятных атак типа “отказ в обслуживании” на протокол Kerberos является бомбардировка центра распространения ключей запросами на аутентификацию. Предполагается, что сервер будет настолько занят, выдавая отказы, что у него не хватит времени выдавать положительные ответы правильным клиентам.
Чтобы защититься от такой атаки, центр распространения ключей принимает билеты TGT только от тех клиентов, которые предоставляют специальную структуру данных. Эта структура данных называется предварительным аутентификатором (preauthenticator) и предоставляется в составе билета TGT. Предварительный аутентификатор представляет собой метку времени, зашифрованную с помощью хешированного пароля клиента.
Когда центр распространения ключей получает билет TGT, он извлекает хешированный пароль из базы данных Active Directory и использует его для дешифровки предварительного аутентификатора.
Если дешифровка предварительного аутентификатора завершается успешно (содержимое успешно проходит проверку CRC), центр распространения ключей (КОС) начинает обработку билета TGT. Если дешифровка завершается неудачей, центр распространения ключей возвращает клиенту сообщение о неправильном имени или пароле.
Кроме этого, центр распространения ключей (КОС) сравнивает метку времени предварительного аутентификатора с системным временем (разница не должна составлять более пяти минут). Это делается на случай, если злоумышленник попытался повторно воспользоваться билетом TGT.
Для обработки предварительного аутентификатора требуется небольшой объем вычислений, поэтому даже центра распространения ключей средней мощности достаточно для противодействия атаке “посредника”.
Взаимная аутентификация
Стандартная транзакция Kerberos является односторонней. Клиент отправляет билет, а сервер его принимает. Но что если злоумышленник подключил к сети подложный сервер? Такой сервер может принимать билет Kerberos, но вместо нормального файла может предоставить файл, содержащий вирусы, программы типа “троянский конь” и другие подобные компоненты.
Предусмотрительный клиент Kerberos всегда пытается удостовериться в том, что принявший билет сервер является настоящим. Эта процедура называется взаимной аутентификацией (mutual authentication). Взаимная аутентификация запрашивается клиентом. Взаимную аутентификацию запрашивают все клиенты под управлением Windows.
Транзакция взаимной аутентификации является зеркальным отображением транзакции предоставления билета сеанса доступа. Проверяющий сервер шифрует метку времени ключом сеанса, полученным из билета, и возвращает результат клиенту в составе ответа. Клиент проверяет аутентификатор и продолжает транзакцию соединения только при успешной проверке аутентификатора.
Кэширование отрицательных ответов Kerberos
Начиная с Windows 2000 Service Pack 2, если контроллер домена, который не выполняет роли РОС Emulator, получает некорректные регистрационные данные пользователя, он кэширует результат локально для сокращения объема данных, передаваемых на РОС Emulator. По умолчанию пользователю предоставляется не больше десяти попыток. После использования всех попыток пользователю отказывается в доступе на основе кэшированной информации в течение 10 минут.
Данные авторизации
Kerberos является протоколом аутентификации, а не протоколом авторизации. Разница может остаться незаметной. Рассмотрим пример.
Во времена военной кампании США в юго-восточной Азии я записался на службу на атомной подводной лодке, подумав (совершенно правильно), что буду в большей безопасности, находясь возле нескольких тонн радиоактивных материалов, чем вояжируя по реке Меконг.
В армии приходится быстро учиться различать аутентификацию и авторизацию. Прежде чем попасть на борт атомной подводной лодки, приходится пройти контроль внешней охраны, которая проверяет удостоверения посетителей. Если лицо посетителя не соответствует фотографии на удостоверении или имя не указано в списке тех, кому разрешен доступ на подводную лодку, охрана стреляет в посетителя. (Ну, возможно, не всегда стреляет, но в доступе на подводную лодку отказывает.) Это начальная проверка личности, которая называется аутентификацией.
Попав на борт подводной лодки, можно посетить камбуз и причал, но без специального разрешения нельзя получить доступ к таким важным помещениям, как торпедный отсек, отсек реактора или винный погреб. Дополнительные разрешения на доступ к важным помещениям можно считать авторизацией.
Как было показано ранее, современные операционные системы Windows используют протокол Kerberos в качестве механизма аутентификации, а комбинацию маркеров доступа и дескрипторов безопасности — для авторизации. Когда инженеры компании Microsoft разработали свою реализацию протокола Kerberos, они решили реализовать часть функций авторизации внутри транзакции Kerberos. Это было сделано за счет поля в билете Kerberos, которое называется данные авторизации (authorization data).
Когда центр распространения ключей готов создать билет TGT, он запрашивает у службы LSASS специальную структуру данных, которая называется сертификат привилегий доступа (Privilege Access Certificate — РАС). Сертификат привилегий доступа содержит информацию о пользователе, необходимую для создания маркеров локального доступа на удаленных серверах. Сертификат РАС одновременно подписывается секретным ключом контроллера домена и секретным ключом, предоставленным службе центра распространения ключей KDC. Это защищает сертификат от подделки клиентом или подложным центром распространения ключей.
Содержимое сертификата привилегий доступа
Краткий обзор содержимого сертификата привилегий доступа позволяет обнаружить достаточно много интересных элементов, которые непосредственно относятся к системному администрированию. Вот список элементов сертификата привилегий доступа.
Время регистрации пользователя и время, до которого сеанс является действительным (если установлен соответствующий параметр). Кроме этого, сертификат привилегий доступа определяет возможность принудительного завершения сеанса в момент истечения срока действительности сеанса.
Момент времени последнего изменения пользователем его пароля и время, когда пользователю можно изменить пароль в следующий раз (если установлена политика минимального срока использования пароля). Кроме этого, указывается дата истечения срока действия пароля.
“Плоское” регистрационное имя пользователя. Это имя хранится в базе данных Active Directory в атрибуте SamAccountName и доступно с помощью консоли Active Directory —■ Users and Computers (Active Directory — пользователи и компьютеры) как Pre-Windows 2000 Logon Name.
Полное имя пользователя, которое хранится в виде параметра Display Name в базе данных Active Directory. Это имя в системе безопасности не используется.
Имя классического регистрационного сценария Windows NT, назначенного учетной записи пользователя. Сценарий должен существовать в совместно используемом ресурсе Ne 11 ogon на сервере аутентификации.
Путь в формате UNC к перемещаемому (роуминг) профилю пользователя, если у пользователя есть такой профиль.
Путь в формате UNC к домашнему каталогу пользователя, если у пользователя есть такой каталог, а также буква диска, которая используется для подключения домашнего каталога
Количество одновременных регистраций пользователя. Это число соответствует подключениям на контроллере домена, который создает сертификат привилегий доступа, а не подключениям в пределах всего домена, поэтому данное число не является точным количеством одновременных регистраций.
Количество неудачных попыток регистрации с момента последней удачной регистрации на контроллере домена, который выдал сертификат привилегий доступа.
Относительный идентификатор (RID) пользователя. Это число создается на основе идентификатора безопасности (SID) домена и уникального идентификатора безопасности (SID) пользователя.
Относительный идентификатор (RID) основной группы пользователя, использующийся в подсистеме POSIX.
Количество групп в домене, в которые входит пользователь, и относительные идентификаторы каждой группы.
Предопределенные идентификаторы безопасности (SID), относящиеся к пользователю, например Authenticated User, Network User и Everyone.
Имя домена пользователя и имя контроллера домена, который аутентифицировал пользо- ; вателя.;
Идентификатор безопасности (SID) домена, который используется вместе с относитель- i ным идентификатором (RID) для создания уникальных идентификаторов безопасности : пользователя и группы.4
■ Идентификатор безопасности домена ресурсов, если пользователь зарегистрировался с компьютера в классическом домене ресурсов Windows NT, и идентификатор безопасности всех групп в домене ресурсов, в которые входит пользователь.
Документация по сертификату привилегий доступа
Документация по 'содержимому и формату сертификата привилегий доступа доступна по адресу www.microsoft.сот/Downloads/Reiease.asp?ReleaseID=20597 .
Кроме этого, существует еще одна структура данных, встроенная в сертификат привилегий доступа. Она называется User Account Control и определяет несколько параметров пользователя, многие из которых соответствуют флажкам на вкладке Account (Учетная запись) окна свойств пользователя на консоли Active Directory — Users and Computers (Active Directory — пользователи и компьютеры). Ниже приведен список параметров, хранящихся в структуре данных User Account Control.
Account Disabled (Учетная запись отключена)
Home Directory Required (Требуется домашний каталог)
Password Not Required (Пароль не требуется)
Temp Duplicate Account (Временный дубликат учетной записи); не используется
Normal Account (Обычная учетная запись)
MNS Logon Account (Регистрационная учетная запись MNS); не документирована и не используется
Interdomain Trust Account (Учетная запись доверительных отношений между доменами)
Workstation Trust Account (Учетная запись доверительного отношения к рабочей станции); для компьютера, входящего в домен
Server Trust Account (Учетная запись доверительного отношения к серверу); для резервного контроллера домена Windows NT
Don’t Expire Password (Срок действия пароля не закачивается)
Account Auto Locked (Учетная запись автоматически заблокирована)
Encrypted Text Password Allowed (Разрешено использовать зашифрованные пароли)
Smart card Required (Необходимо использование смарт-карты)
Trusted For Delegation ( Может быть делегирована)
Not Delegated (Не делегирован)
Use DES Key Only (Использовать только ключ DES); аутентификация выполняется только по протоколу LanMan
Don’t Require Preauthentication (He требовать предварительной аутентификации)
Использование сертификата привилегий доступа
Протокол Kerberos включает сертификат привилегий доступа РАС в поле данных авторизации билета TGT, который выдается клиенту. Клиент Kerberos кэширует билет TGT и отправляет копию каждый раз, когда необходимо получить билет сеанса доступа у центра распространения ключей КОС. При создании билета сеанса доступа КОС извлекает сертификат привилегий доступа РАС из билета TGT и вставляет копию поля данных авторизации в билет сеанса доступа.
После того как сервер проверит билет сеанса доступа, пакет безопасности Kerberos извлекает сертификат РАС и предоставляет его(службе LSASS, которая использует сертификат для создания локального маркера доступа для клиента. Это значит, что при добавлении пользова-
теля в группу или изменении параметров безопасности пользователя от пользователя требуются завершение сеанса и повторная регистрация для получения нового билета TGT с новым сертификатом доступа, который содержит новый идентификатор группы.
Отказавшись от отдельной транзакции для получения пользовательского сертификата РАС, компания Microsoft добилась устранения дополнительных действий в процедуре предоставления доступа. Кроме этого, были исключены потенциально уязвимые места в процессе передачи информации для авторизации на этапе второй, закрытой, транзакции. К сожалению, на момент выхода операционной системы Windows 2000 такой метод передачи информации сертификата привилегий доступа был очень плохо документирован, что разозлило разработчиков, которые планировали портировать приложения для использования протокола Windows Kerberos, но не получили достаточной информации о сертификате привилегий доступа РАС.
Через два года после выхода операционной системы Windows 2000 компания Microsoft предоставила документацию, описывающую сертификат привилегий доступа, но ее все равно недостаточно для поддержки попыток встроить данные авторизации в продукты сторонних производителей. Например, клиенты Samba все еще должны использовать аутентификацию по протоколу NTLM, а не Kerberos, поскольку разработчики Samba все еще нуждаются в дополнительной информации о том, как обрабатывается сертификат привилегий доступа.
На более эзотерическом уровне сертификат привилегий доступа изменил способ, которым компания Microsoft реализовала сообщения Kerberos. Стандартные запросы и ответы Kerberos достаточно невелики, чтобы передаваться в одной дейтаграмме, поэтому чаще всего для их отправки используется протокол UDP. Большой сертификат привилегий доступа с легкостью может превысить размер одной дейтаграммы, что заставит операционную систему использовать протокол TCP для обеспечения гарантированной последовательности доставки всего билета сеанса доступа. Это может привести к проблемам совместимости, если центр распространения ключей Kerberos от стороннего производителя не настроен на ожидание запросов и предоставление ответов через ТСР-порт 88.
Резюме по элементам Kerberos
На рис. 11.11 изображена схема взаимодействия между тремя основными элементами протокола Kerberos. Повторим основные понятия протокола Kerberos, прежде чем перейти к его подробному изучению.
Домен Windows является сферой Kerberos.
Контроллер домена Windows является центром распространения ключей Kerberos.
Центр распространения ключей Windows выполняет обе функции классического центра распространения ключей: аутентификацию и выдачу билетов.
Отдельные домены Windows в пределах одного леса связаны доверительными отношениями между сферами по протоколу Kerberos. Эти доверительные отношения являются двусторонними и транзитивными.
Современный компьютер под управлением Windows, входящий в домен Active Directory, является участником системы безопасности Kerberos. Запущенные на компьютере службы, которым необходим доступ к ресурсам на других компьютерах, получают билеты сеансов доступа у центра распространения ключей.
Сервер под управлением современной операционной системы Windows, который входит в домен, требует билет сеанса доступа от каждого клиента под управлением современной операционной системы Windows при попытке клиента получить доступ к ресурсам. Для аутентификации клиентов более старых версий сервер использует протокол NTLM.
Рис. 11.11. Компоненты и транзакции протокола Kerberos
Пользователь, зарегистрированный на компьютере под управлением современной операционной системы Windows, входящем в домен Active Directory, будет автоматически аутентифицирован на контроллере домена с помощью протокола Kerberos. Это относится даже к доменам, работающим в режиме Windows 2000 Mixed, в котором для аутентификации доступны основные и резервные контроллеры домена Windows NT.
Поле данных авторизации в билете TGT и билете сеанса доступа содержит сертификат привилегий доступа (РАС), в котором хранится информация, необходимая для создания локальных маркеров доступа для пользователей.
Помня об этом, рассмотрим, что происходит при регистрации пользова*еля с помощью протокола Kerberos и попытке пользователя получить доступ к ресурсам.
Анализ транзакций Kerberos
Клиенты под управлением современных операционных систем Windows используют протокол Kerberos для аутентификации в следующих ситуациях.
Начальная загрузка компьютера. Клиентский компьютер использует регистрационные данные из базы данных LSA для аутентификации на контроллере домена Active Directory. После этого компьютер устанавливает безопасное соединение с регистрационным сервером.
Аутентификация Kerberos в доменах в режиме Windows 2000 Mixed
Компьютеры под управлением современных операционных систем Windows, которые входят в домен, работающий в режиме Windows 2000 Mixed, всегда проходят аутентификацию на контроллере домена Active Directory, если такой контроллер домена доступен. Это относится даже к тем компьютерам, которым приходится использовать внешние соединения для доступа к контроллеру домена Active Directory.
Клиенты под управлением современных операционных систем Windows проверяют записи SRV в зоне DNS при каждой загрузке. Пока в зоне отсутствуют упоминания о домене Active Directory, клиенты продолжают использовать протокол NTLM для аутентификации. Но как только в зоне появятся записи SRV, клиенты будут настаивать на использовании протокола Kerberos.
Такое поведение может оказаться неожиданным, если в домене развернуто несколько сотен или тысяч рабочих станций под управлением Windows 2000 или Windows ХР, но контроллеры домена все еще работают под управлением Windows NT 4.0. Как только основной контроллер домена будет модернизирован до контроллера домена Active Directory, каждый клиент под управлением современной версии операционной системы Windows заметит запись srV и запросит аутентификацию непосредственно на контроллере домена Active Directory. Такие запросы на аутентификацию могут приходить от компьютеров по всему миру.
Это правило можно отключить, но для этого в системный реестр придется добавить специальную запись. Дополнительную информацию по этому вопросу можно получить в главе 9, "Развертывание доменов Windows Server 2003".
Аутентификация учетных записей служб. Некоторые службы используют протокол Kerberos для аутентификации при подключении к другим серверам. Эти приложения специально проектировались для использования протокола Kerberos. Они проходят аутентификацию, как отдельные участники системы безопасности в базе данных Active Directory. В качестве примера можно привести подключения к Active Directory по протоколу LDAP, доступ к файлам по протоколу CIFS/SMB и безопасные обновления записей DNS.
Начальная регистрация пользователя. Пользователь, который регистрируется в домене Active Directory с клиента под управлением современной операционной системы Windows, проходит аутентификацию на том же контроллере домена, на котором проходил аутентификацию его компьютер.
Рассмотрим последнюю транзакцию: пользователь регистрируется в домене Active Directory с компьютера под управлением современной операционной системы Windows. Транзакция выполняется одинаково на операционных системах Windows Server 2003, Windows ХР и Windows 2000.
Аутентификация при начальной регистрации пользователя
На рис. 11.12 показана схема регистрации пользователя в домене Active Directory. Ниже приведены ключевые моменты регистрации.
Для получения доступа к компьютеру, который является членом домена, пользователь должен ввести данные аутентификации для домена.
Пароль пользователя никогда не передается по сети ни в зашифрованной форме, ни открытым текстом.
При начальной аутентификации в домене пользователь получает билет TGT.
Идентификация регистрационного сервера >
Для определения регистрационного сервера пользователя необходимо запустить интер- 1 претатор команд и ввести команду set. Ниже приведен фрагмент листинга (переменная | LOGONSERVER выделена полужирным шрифтом): |
ALLUSERSPROFILE=C:\Documents and SettingsXAll Users
APPDATA=C:XDocuments and SettingsXAdministratorXApplication Data CommonProgramFiles=C:XProgram FilesXCommon Files
COMPUTERNAME=SRV1
ComSpec=C:\WINDOWS\system32\cmd.exe
HOMEDRIVE=C:
HOMEPATH=\Documents and Settings\Administrator
LOGONSERVERs\\SERVERI
Файловый сервер и сервер печати под управлением операционной системы Windows Server 2003Файловый сервер и сервер печати под управлением операционной системы Windows Server 2003Сервер отвечает на запрос взаимной аутентификацииСервер отвечает на запрос взаимной аутентификацииКонтроллер домена Active DirectoryКонтроллер домена Active DirectoryКонтроллер домена возвращает билет сеанса доступаКонтроллер домена возвращает билет сеанса доступаПользователь отправляет билет TGT вместе с запреет* на неимение билета сеанса доступаПользователь отправляет билет TGT вместе с запреет* на неимение билета сеанса доступаПользователь отправляет бипет сеанса доступа и аутентификатор вместе с начальным сетевым запросомПользователь отправляет бипет сеанса доступа и аутентификатор вместе с начальным сетевым запросом
Файловый сервер и сервер печати под управлением операционной системы Windows Server 2003
Файловый сервер и сервер печати под управлением операционной системы Windows Server 2003
Сервер отвечает на запрос взаимной аутентификации
Сервер отвечает на запрос взаимной аутентификации
Контроллер домена Active Directory
Контроллер домена Active Directory
Контроллер домена возвращает билет сеанса доступа
Контроллер домена возвращает билет сеанса доступа
Пользователь отправляет билет TGT вместе с запреет* на неимение билета сеанса доступа
Пользователь отправляет билет TGT вместе с запреет* на неимение билета сеанса доступа
Пользователь отправляет бипет сеанса доступа и аутентификатор вместе с начальным сетевым запросом
Пользователь отправляет бипет сеанса доступа и аутентификатор вместе с начальным сетевым запросом
Рис. 11.12. Транзакция регистрации в одном домене Active Directory
В процедуре 11.6 транзакция рассматривается подробно, начиная с начальной регистрации.
Процедура 11.6. Транзакция регистрации по протоколу Kerberos
Пользователь запускает процесс регистрации, нажав комбинацию клавиш <Ctrl+Alt+Del>. Эта комбинация называется Security Attention Sequence. После нажатия комбинации клавиш запускается служба Winlogon и выводится окно для ввода данных аутентификации (параметры окна определяются в библиотеке Gina.dll). Это позволяет предотвратить запуск любых программ, которые пытаются запуститься перед операционной системой и перехватить пароль пользователя.
Пользователь вводит имя учетной записи и пароль и выбирает домен в поле Domain (Домен). С другой стороны, пользователь может ввести основное имя пользователя в формате имя_пользователя©домен, корень. В любом случае система безопасности выполняет одну и ту же последовательность действий.
Различия между использованием основного имени пользователя и вводом имени/выбором домена
В сообществе администраторов операционной системы Windows бытует мнение, что ввод имени пользователя и имени домена в окне Winlogon приводит к использованию протокола NTLM, а ввод основного имени пользователя приводит к использованию протокола Kerberos. В этом нет и доли правды. Если локальный компьютер прошел аутентификацию в домене
Active Directory, пользователь будет аутентифицирован с помощью протокола Kerberos независимо от формата регистрации. Единственной разницей между использованием комбинации "имя_пользователя/домен/пароль" и вводом основного имени пользователя является необходимость опроса сервера глобального каталога для выделения имени пользователя и имени домена из основного имени пользователя. Клиенты под управлением операционных систем Windows Server 2003 и Windows ХР кэшируют результаты таких запросов на случай, если сервер глобального каталога окажется недоступным.
Служба Winlogon принимает регистрационные данные пользователя и передает их службе LSASS, которая хеширует пароль пользователя с помощью алгоритма MD4 И для аутентификации пользователя использует пакет Kerberos.
Пакет Kerberos принимает хешированный пароль пользователя и на его основе создает запрос билета TGT, который содержит предварительный аутентификатор (метка времени, зашифрованная хешированным паролем пользователя). (Эта транзакция не требует наличия службы Netlogon на клиенте или контроллере домена.)
Служба центра распространения ключей (KDC) на контроллере домена получает билет TGT. Если имя пользователя существует, служба извлекает хешированный пароль пользователя из базы данных Active Directory и использует его для дешифрации предварительного аутентификатора.
Если службе центра распространения ключей не удается дешифровать предварительный аутентификатор или метка времени указывает, что предварительный аутентификатор используется повторно или разница во времени выходит за пределы допустимого смещения, аутентификация завершается неудачно. Центр распространения ключей (KDC) отправляет клиенту уведомление о неудачной попытке аутентификации.
Если центр распространения ключей принимает предварительный аутентификатор как истинный, он обращается к службе LSASS для создания сертификата привилегий доступа для пользователя. Центр добавляет сертификат привилегий доступа в поле данных аутентификации билета TGT и возвращает этот билет внутри ответа пользователю. Билет TGT зашифрован хешированным паролем учетной записи krbtgt. Весь ответ зашифрован хешем пароля пользователя.
Клиент Kerberos дешифрует ответ и кэширует билет сеанса доступа и билет TGT в памяти (не на диске). Сертификат привилегий доступа передается службе LSASS.
Служба LSASS использует информацию из сертификата привилегий доступа для создания маркера локального доступа для пользователя. (В маркер добавляются все идентификаторы безопасности локальных групп, в которые входит пользователь, а также всех локальных политик безопасности, которые применяются к пользователю.)
После истечения срока действия билета TGT (по умолчанию его время жизни устанавливается равным 10 часам) клиент получает новый билет TGT у центра распространения ключей (KDC). Это происходит незаметно для пользователя без приостановки обслуживания, если доступен хотя бы один контроллер домена. В противном случае клиент теряет доступ к домену, пока не станет доступен хотя бы один контроллер домена.
На этом этапе регистрацию на консоли можно считать завершенной. Служба Winlogon передает управление службе Userinit, которая загружает и обрабатывает групповые политики из системного реестра и запускает оболочку Explorer в контексте безопасности , пользователя. Любые процессы, запущенные после этого пользователем, получат маркер доступа пользователя.
Аутентификация при подключении к входящим
в домен серверам
После аутентификации в домене пользователь пытается получить доступ к ресурсам на серверах, которые входят в домен. Рассмотрим последовательность операций.
Клиент должен еще раз обратиться к регистрационному серверу для получения билета сеанса доступа для интересующего сервера.
Клиент предоставляет билет сеанса доступа в составе первой транзакции подключения к интересующему серверу. Вместе с билетом сеанса доступа клиент передает аутентификатор и запрос на взаимную аутентификацию.
Сервер дешифрует билет, проверяет действительность аутентификатора и в ответ предоставляет собственный аутентификатор. Кроме этого, для пользователя создается локальный маркер доступа.
Клиент проверяет действительность аутентификатора сервера.
В процедуре 11.7 транзакция рассматривается подробно с момента попытки пользователя получить доступ к сетевому ресурсу.
Процедура 11.7. Транзакция доступа к серверу по протоколу Kerberos
Пользователь открывает окно Му Network Places (Мое сетевое окружение), выделяет пиктограмму сервера и выполняет двойной щелчок на этой пиктограмме.
Сетевой перенаправитель обращается к службе LSASS для получения билета Kerberos, предназначенного для интересующего сервера. Служба LSASS запрашивает помощь у пакета безопасности Kerberos.
Пакет Kerberos получает копию кэшированного билета TGT и на ее основе создает запрос билета сеанса доступа, в котором указано имя запрашиваемого сервера. Запрос шифруется с помощью ключа сеанса, который предоставлен в составе билета TGT.
Центр распространения ключей получает запрос и дешифрует его с помощью собственной копии ключа сеанса. Если дешифровка завершилась неудачно, центр распространения ключей предполагает, что кто-то перехватил запрос. Если содержимое не проходит тест CRC, центр распространения ключей предполагает, что кто-то попытался изменить содержимое запроса.,
После этого центр распространения ключей создает билет для запрошенного сервера. Билет содержит новый ключ сеанса, который предназначен только для этой транзакции. Центр распространения ключей предоставляет билет клиенту в составе ответа на запрос. Сам билет зашифрован хешированным паролем интересующего сервера. Весь ответ зашифрован хешированным паролем пользователя.
Пакет Kerberos дешифрует ответ и кэширует ключ сеанса и билет. Ключ сеанса используется для создания аутентификатора. Аутентификатор и билет добавляются в запрос доступа (access request), который передается сетевому перенаправителю (redirector).
Перенаправитель создает сообщение Server Message Block (SMB), которое запрашивает у сервера создание сеанса и подключение клиента с помощью созданного сеанса. Запрос на доступ Kerberos включается в состав первого запроса SMB.
Запрошенный сервер извлекает запрос доступа из сообщения SMB и передает его службе LSASS, которая обращается к локальному пакету Kerberos для дешифровки билета и проверки действительности аутентификатора.
При проверке действительности клиента пакет Kerberos извлекает копию ключа сеанса из билета и использует ключ для создания собственного аутентификатора, который предоставляется клиенту в составе ответа на запрос.
В то же время сервер извлекает из поля данных авторизации билета сертификат привилегий доступа (РАС) и передает его службе LSASS, которая использует сертификат РАС для создания локального маркера доступа для данного пользователя. (Служба LSASS добавляет идентификаторы безопасности всех локальных групп, в которые входит пользователь, и всех локальных политик безопасности, которые относятся к пользователю.)
Клиент проверяет действительность аутентификатора, выданного сервером, и завершает создание сеанса SMB.
После истечения срока действия билета сеанса доступа (по умолчанию — 10 часов) пакет Kerberos получает еще один билет от центра распространения ключей. Эта операция выполняется незаметно для пользователя, кроме случаев, когда недоступен ни один из контроллеров домена. В таком случае пользователь теряет доступ к серверам, входящим в домен.
Просмотр билетов Kerberos
В составе Resource Kit предоставляются две утилиты, которые помогают диагностировать транзакции Kerberos. Эти утилиты позволяют просматривать билеты TGT и билеты сеансов доступа, полученные клиентом.
Kerbtray. Эта утилита размещает в System Tray пиктограмму, дважды щелкнув на которой, можно просмотреть билеты и дополнительную информацию о содержимом билетов. Пример такого отчета показан на рис. 11.13.
Рис. 11.13. Окно Kerbtray, в котором показан список билетов
klist. Эта утилита, работающая в режиме командной строки, основана на классической одноименной утилите для работы с протоколом MTv5 Kerberos. Ниже приведен пример ее использования:
C:\>klist tickets
Cached Tickets: (2)
Server: krbtgt/COMPANY.COM0COMPANY.COM
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
End Time: 11/25/2001 19:55:37
Renew Time: 12/2/2001 9:55■: 37
Server: SERVERI/COMPANY.COM
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT) End Time: 11/25/2001 19:55:37
Renew Time: 12/2/2001 9:55:37
Междоменная аутентификация
Одной из самых важных возможностей протокола Kerberos является возможность обеспечивать транзитивную межсферную аутентификацию. Это значит, что пользователь из одного домена может получать доступ к объектам системы безопасности (файлам или папкам NTFS, объектам Active Directory, службе или разделу системного реестра) из любого другого домена в пределах леса. Достаточно, чтобы администратор настроил параметры безопасности объекта для авторизации доступа пользователя.
На рис. 11.14 показана схема междоменных транзакций аутентификации. В этом примере пользователь из дочернего домена в одном дереве пытается получить доступ к совместно используемому ресурсу на сервере дочернего домена в другом дереве. Корневые домены обоих деревьев связаны двусторонним доверительным отношением.
Домен ВДомен ВДомен АДомен АДомен СДомен СФайловый сервер и сервер печатиФайловый сервер и сервер печатиКонтроллер домена в нужном домене предоставляет межсферный билет сеанса доступаКонтроллер домена в нужном домене предоставляет межсферный билет сеанса доступаКлиент предоставляет билет сеанса доступа и аутентификатор при первом сетевом подключенииКлиент предоставляет билет сеанса доступа и аутентификатор при первом сетевом подключенииРис. 11.14. Лес доменов и междоменная аутентификацияРис. 11.14. Лес доменов и междоменная аутентификацияКонтроллеры доменаиз доменов, вкоторых нетзапрошенногосервера,предоставляютбилет ТОТ длянужного домена
Домен В
Домен В
Домен А
Домен А
Домен С
Домен С
Файловый сервер и сервер печати
Файловый сервер и сервер печати
Контроллер домена в нужном домене предоставляет межсферный билет сеанса доступа
Контроллер домена в нужном домене предоставляет межсферный билет сеанса доступа
Клиент предоставляет билет сеанса доступа и аутентификатор при первом сетевом подключении
Клиент предоставляет билет сеанса доступа и аутентификатор при первом сетевом подключении
Рис. 11.14. Лес доменов и междоменная аутентификация
Рис. 11.14. Лес доменов и междоменная аутентификация
Контроллеры одного домена не могут выдавать билеты сеансов доступа для серверов из другого домена. Вспомните, что домены формируют разные контексты именования в базе данных Active Directory. Контроллер домена может получать доступ только к собственному контексту именования. (Сервер глобального каталога хранит частичную копию всех контекстов именования Domain, но сервер глобального каталога не хранит всей необходимой информации для создания билета сеанса доступа.)
По той же причине клиенты Kerberos из других доменов не могут непосредственно обратиться к центру распространения ключей в удаленном домене для получения билета сеанса для сервера в этом домене. Клиент не имеет доступа к регистрационным данным в удаленном контексте именования Domain.
Локальный контроллер домена поддерживает междоменный доступ, получая межсферный билет TGT у собственного родительского домена от имени пользователя. Контроллер домена возвращает межсферный билет TGT клиенту вместе со ссылкой на родительский домен.
Контроллер домена может получать междоменные билеты TGT благодаря возможности протокола Kerberos, которая называется делегирование (delegation). Делегирование позволяет Службе на одном компьютере получать билет TGT или билет сеанса доступа для пользователя на другом компьютере. Это очень мощная возможность, которая может стать уязвимым местом в системе безопасности при неправильном использовании. Более подробно делегирование будет рассматриваться в следующем разделе.
Клиент переходит по ссылке, отправляя межсферный билет TGT контроллеру домена в родительском домене, и еще раз запрашивает билет сеанса доступа для запрашиваемого сервера. Если сервер отсутствует в родительском домене, контроллер домена получает межсферный билет TGT для своего родительского домена или для домена на вершине дерева, который содержит целевой домен.
Этот процесс позволяет клиенту переходить по дереву, опрашивая каждый домен на пути для получения билета для нужного сервера и получая межсферный билет TGT и ссылку, пока не попадет в домен, который содержит запрашиваемый сервер. В этот момент клиент предоставит межсферный билет TGT контроллеру интересующего домена.
В процессе проверки на стороне контроллера домена выясняется, является ли каждый пересеченный клиентом домен доверенным для соседних доменов. Контроллер домена получает список “пройденных” доменов из межсферного билета TGT. Контроллер домена имеет доступ к информации о структуре леса, которая хранится в базе данных Active Directory (эта информация иногда называется знанием (knowledge)).
С этого момента транзакция выполняется, как обычная транзакция Kerberos. Клиент отправляет билет сеанса доступа и аутентификатор серверу и получает доступ. Сертификат привилегий доступа (РАС) в билете сеанса доступа получен в удаленном домене, поэтому пользователь будет авторизован для доступа к ресурсам сервера, только если кто-то внес пользователя в список контроля доступа DACL.
Прямые доверительные отношения
В примере из предыдущего раздела было показано, как транзитивное двустороннее доверительное отношение Kerberos обеспечивает доступ пользователей к ресурсам в пределах всего леса.
В крупном сетевом окружении, состоящем из множества доменов, при междоменной аутентификации могут возникать проблемы производительности. Такое замедление вызывается необходимостью использования внешних каналов при переходе по дереву для получения межсферной аутентификации (рис. 11.15). ,
Если задержки оказываются слишком долгими и пользователи начинают выражать недовольство, процесс можно ускорить, создав прямое доверительное отношение (shortcut trust) между доменами в пределах леса. Прямое доверительное отношение сообщает центру распро-
странения ключей (KDC), что он может непосредственно обращаться к интересующему домену для получения междоменного билета TGT вместо полного перехода по дереву.
Company.comCompany.comSubsidiary.comSubsidiary.comРис. 11.15. Лес с прямым доверительным отношением, установленным между двумя дочерними доменамиРис. 11.15. Лес с прямым доверительным отношением, установленным между двумя дочерними доменами
Company.com
Company.com
Subsidiary.com
Subsidiary.com
Рис. 11.15. Лес с прямым доверительным отношением, установленным между двумя дочерними доменами
Рис. 11.15. Лес с прямым доверительным отношением, установленным между двумя дочерними доменами
Делегирование Kerberos
В классической схеме аутентификации по протоколу NTLM, показанной на рис. 11.16, не существует поддержки сквозной аутентификации сервера на другом сервере. Это ограничивает возможности операционной системы Windows NT поддерживать так называемые многу- ровневые приложения (n-tier applications). Многоуровневые приложения используют сервер среднего уровня для получения пользовательских запросов и передачи запросов одному или нескольким серверам на нижнем уровне.
Из-за ограничений протокола NTLM такие приложения, как Web-интерфейс и Object Resource Brockers (ORB), должны регистрироваться на серверах нижнего уровня с использованием регистрационных данных, которые хранятся на сервере среднего уровня. Обычно для этого используются учетные записи и пароли, встроенные в соединения ODBC и ActiveX Data Object (ADO) или в структуры данных приложений от сторонних производителей.
Проблемой такой конфигурации является мультиплексирование нескольких учетных записей на сервере среднего уровня в одну учетную запись, которая получает доступ к серверам нижнего уровня. Это приводит к возникновению проблем в системе безопасности при компрометации приложения на сервере среднего уровня. Кроме этого, серверы нижнего уровня не получают информацию о пользователях, которые обращаются к их ресурсам.
Сквозная аутентификацияВыступает от именипользователя для проверкиаутентификационных данныхСквозная аутентификацияВыступает от именипользователя для проверкиаутентификационных данныхLMRepIОсновной контроллер доменареплицирует изменения вSAM на резервныйконтроллер доменаLMRepIОсновной контроллер доменареплицирует изменения вSAM на резервныйконтроллер доменаРезервный контроллер домена Windows NT 4.0Резервный контроллер домена Windows NT 4.0Файловый сервер и серверпечати под управлениемWindows NT 4.0Файловый сервер и серверпечати под управлениемWindows NT 4.0Основной контроллер домена Windows NT 4.0Основной контроллер домена Windows NT 4.0Начальный запрос SMB для создания подключенияНачальный запрос SMB для создания подключенияВызовСлучайное числоВызовСлучайное числоВызов-ОтветХеш вызова параметра Salt и хешированного пароля пользователяВызов-ОтветХеш вызова параметра Salt и хешированного пароля пользователяРабочая станцияпод управлениемWindows NT 4.0Рабочая станцияпод управлениемWindows NT 4.0
Сквозная аутентификация
Выступает от именипользователя для проверкиаутентификационных данных
Сквозная аутентификация
Выступает от именипользователя для проверкиаутентификационных данных
LMRepI
Основной контроллер доменареплицирует изменения вSAM на резервныйконтроллер домена
LMRepI
Основной контроллер доменареплицирует изменения вSAM на резервныйконтроллер домена
Резервный контроллер домена Windows NT 4.0
Резервный контроллер домена Windows NT 4.0
Файловый сервер и серверпечати под управлениемWindows NT 4.0
Файловый сервер и серверпечати под управлениемWindows NT 4.0
Основной контроллер домена Windows NT 4.0
Основной контроллер домена Windows NT 4.0
Начальный запрос SMB для создания подключения
Начальный запрос SMB для создания подключения
Вызов
Случайное число
Вызов
Случайное число
Вызов-Ответ
Хеш вызова параметра Salt и хешированного пароля пользователя
Вызов-Ответ
Хеш вызова параметра Salt и хешированного пароля пользователя
Рабочая станцияпод управлениемWindows NT 4.0
Рабочая станцияпод управлениемWindows NT 4.0
Рис. 11.16. Лес, в котором между дочерними доменами создано прямое доверительное отношение
Протокол Kerberos позволяет серверу среднего уровня получать регистрационные данные пользователя и использовать эти данные для доступа к серверу нижнего уровня. Существует несколько способов использования регистрационных данных.
Перенаправляемые билеты. При такой конфигурации сервер среднего уровня запрашивает у клиента билет сеанса доступа для сервера нижнего уровня. Этот билет будет использоваться для создания соединения с приложением на сервере нижнего уровня. Билет должен иметь установленный флаг forwardable.
Билеты-прокси. При такой конфигурации сервер среднего уровня запрашивает у клиента билет TGT для домена и предоставления этого билета серверу среднего уровня. После этого сервер среднего уровня воспользуется этим билетом для создания билета сеанса доступа для сервера нижнего уровня от имени пользователя. Такой билет TGT должен иметь флаг proxiable.
Разницу между этими двумя типами билетов можно описать следующим образом. Вы можете одолжить другу 10 долларов на обед или предоставить ему полное право использовать вашу чековую книжку.
Сервер среднего уровня может получать билеты Kerberos, выступая от имени любого пользователя в пределах леса, поэтому сервер среднего уровня занимает исключительное место в системе безопасности. В связи с этим стандартные серверы не могут получать билеты forwardable и proxiable. Для сервера должен быть установлен флаг “Trusted for Delegation” (“Доверенный для делегирования”) перед тем, как получать билеты от имени пользователя.
Дополнительные преимущества Kerberos
Можно посмотреть на все эти возможности Kerberos и подумать: “Хорошо. Мне это нравится. Но у нас в сети все еще тысячи рабочих станций под управлением Windows 98 и Windows NT 4.0 и сотни серверов под управлением Windows NT 4.0. Никто не планирует их мо-
дернизацию за одну ночь. Думаю, что использование всех этих интересных возможностей придется отложить на долгое время”.
К счастью, ждать придется недолго. Как только домены в пределах леса будут переключены в режим Native, клиенты более старых версий смогут принимать участие в транзитивных доверительных отношениях. В режиме Windows 2000 Native контроллеры домена используют транзитивные отношения Kerberos для получения междоменных билетов TGT и билетов сеанса доступа от имени клиентов более старых версий. Вот как это происходит.
Если клиент LM или NTLM обращается к серверу Windows NT в другом домене, работающем в режиме Windows 2000 Native, сервер удаленного домена использует сквозную аутентификацию NTLM для связи с контроллером клиентского домена.
Контроллер домена использует делегирование для обратного перехода по дереву и получения межсферного билета TGT от имени клиента. Этого билета достаточно для аутентификации пользователя в удаленном домене.
■ После этого контроллер домена завершает сквозную аутентификацию и сообщает серверу, что пользователь прошел аутентифицию. В межсферный билет TGT добавляется классическая структура данных с идентификатором безопасности пользователя и привилегиями, которые предоставлены в сертификате привилегий доступа.
Другими словами, если в пределах леса существуют домены, работающие в режиме Windows 2000 Native, клиенты Windows NT, Windows 98 и Samba получат следующие преимущества;
Локальные для домена группы могут быть включены в локальные списки контроля доступа (ACL).
Пользователи клиентов более старых версий могут получать доступ к ресурсам любого сервера в любом домене (если пользователи включены в локальные списки контроля доступа).
Почему это не работает в режиме Windows 2000 Mixed? Потому что в этом режиме домены Active Directory сохраняют классические ограничения WindowsNT. В конце концов, клиент может пройти аутентификацию на классическом резервном контроллере домена (ВВС), а не на контроллере домена Active Directory, что делает невозможной межсферную транзакцию.
Политики Kerberos
Некоторые параметры протокола Kerberos можно изменить с помощью групповых политик. Эти политики устанавливаются в групповой политике Default Domain и находятся в разделе Computer Configuration*Windows Settings*Security Settings1*Account Policies*Kerberos Policies (Конфигурация компьютера*Конфигурация Windows*Параметры безопасности* Политики учетных записей*Политики Kerberos). Рассмотрим эти политики подробнее.
Enforce user logon restrictions (Использовать ограничения при регистрации пользователей). Каждый сервер в пределах домена хранит набор политик для ограничений локальных учетных записей. В этих ограничениях определяются допустимые параметры для локальной регистрации, доступа к компьютеру по сети и т.д. По умолчанию центр распространения ключей (КОС) проверяет соответствие пользователя локальным ограничениям учетных записей перед выдачей билета сеанса доступа для конкретного сервера. Это приводит к усложнению процедуры регистрации, но позволяет сократить объем передаваемых по сети данных, избавляя пользователей от необходимости получения билета сеанса доступа, который все равно не может быть использован из-за локальных ограничений.
Maximum lifetime for service ticket (Максимальное время жизни билета службы). Билет службы (service ticket) ничем не отличается от билета сеанса доступа. Каждый билет сеанса доступа обладает временем жизни 10 часов. Этот интервал можно сократить, но при слишком коротком времени жизни клиентам придется получать новые билеты
слишком часто. Значение должно находиться в диапазоне от 10 минут до значения времени, заданного в политике Maximum lifetime for user ticket (Максимальное время жизни билета пользователя).
Maximum lifetime for user ticket (Максимальное время жизни билета пользо-
вателя). Билет пользователя (riser ticket) ничем не отличается от билета TGT. По умолчанию для билета TGT задано время жизни 10 часов, по истечении которых билет должен быть обновлен. Значение должно быть больше 10 минут и не должно быть меньше значения времени, заданного в политике Maximum lifetime for service ticket(Максимальное время жизни билета службы) .
Maximum lifetime for user ticket renewal (Максимальное время возобновления билета пользователя). По умолчанию билет TGT может быть обновлен в течение семи дней. После этого срок действия такого билета истекает и клиент должен получить новый билет TGT.
Maximum tolerance for computer clock synchronization (Максимальная разница во времени). По умолчанию максимальная разница во времени составляет пять минут. Это значение менять не стоит.
Совместимость MITvS Kerberos
Если в существующей сети для аутентификации уже используется протокол MITvS Kerberos, любого администратора заинтересует возможность интеграции Windows Kerberos в существующую инфраструктуру. Точно так может существовать домен Active Directory, в котором необходимо использовать приложение Kerberos, запрограммированное на работу в среде MITvS. В любом случае потребуются значительные усилия для интеграции обеих систем.
Существует возможность одновременного использования сферы Kerberos и домена Active Directory. Пользователям одной системы может потребоваться доступ к службам и ресурсам другой системы. Задача администратора заключается в обеспечении максимальной прозрачности такого перехода. В этом разделе рассматриваются общие процедуры создания меж- сферного доверительного отношения, которое может связать службы Kerberos и участников системы безопасности из обеих систем.
Реализация протокола Kerberos в операционной системе Windows соответствует требованиям документов RFC, которые разрабатывались вместе с протоколом MITvS Kerberos, поэтому обе версии протокола могут сосуществовать, но особенности такого сосуществования . могут отличаться в зависимости от применяемых платформ и приложений.
Даже если протокол MITvS Kerberos не используется и его использование не планируется, стоит просмотреть этот раздел. В каждом подразделе рассматриваются отличия реализации компонентов MITvS в операционной системе Windows и описываются потенциальные затруднения при совместном использовании этих реализаций.
Ссылки на документацию
по протоколу MITvS Kerberos
Ниже приведено несколько ссылок на отличную документацию, на которую стоит обратить внимание при создании классической сферы MITvS Kerberos.
The Moron's Guide to Kerberos (Руководство no Kerberos для полных идиотов), л
www.isi.edu/~brian/security/kerberos.html. Однозначно предназначенное совсем не для “идиотов”, это описание Брайана Тунга (Brian Tung) затрагивает принципы работы протокола Kerberos и реализации протокола в среде UNIX.
Kerberos: An Authentication Service for Computer Networks, www.isi.edu/gost/ publications/kerberos-neuman-tso.html. Этот труд Клиффорда Ньюмена (В. Clifford Neuman) и Теодора Тео (Theodore Ts’o) все еще остается лучшим описанием работы протокола Kerberos (написан в 1994 году). Здесь не затрагиваются подробности реализации, но описываются такие детали особенностей работы, которые недоступны в других источниках.
Kerberos FAQ (Список часто задаваемых вопросов по Kerberos), www.nrl.navy. mil/CCS/people/kenh/kerberos-faq.html. Как и большинство списков часто задаваемых вопросов, это постоянно увеличивающийся в объеме документ. Запускайте механизмы поиска и готовьтесь к длительному ожиданию.
Kerberos V5 Installation Guide (Руководство по установке протокола Kerberos V5), www.Ins.Cornell.edu/public/C0MP/krb5/install/install_toc.html. Авторитетное справочное руководство описывает процедуру установки протокола MITv5 Kerberos на основе операциЬнной системы UNIX в разветвленной университетской среде. В документации делается предположение, что используются выполняемые файлы, созданные на основе исходных кодов MIT, но последовательность действий применима к другим реализациям протокола.
Step-by-step Guide to Kerberos 5 Interoperability (Пошаговое руководство по совместимости Kerberos 5), www.microsoft.com/windows2000/techinfo/plarming/security/ kerbsteps. asp. Это руководство появилось одновременно с операционной системой Windows 2000 в ответ на множество запросов от университетов о совместимости протоколов Windows Kerberos и MITv5 Kerberos. Степень детализации документа оказалась на высоком уровне, и документ остается справедливым для множества реализаций Kerberos.
Red Hat v7.1 Reference Guide (Справочное руководство по операционной системе Red Hat v7.1), www. redhat. com/support/manuals. Эту документацию стоит просмотреть всем администраторам, которые желают реализовать протокол Kerberos в операционной системе Red Hat Linux. Не воспринимайте инструкции слишком буквально, так как в некоторых случаях они не актуальны для версии 7.1 (и более поздних версий операционной системы. — Примеч.ред.).
Документация проекта Debian, www.mit.edu/afs/sipb/project/debian/cvs/krb5/ doc/krb5-inst'all. info-1, v. Это более подробная документация, чем предоставленная в составе операционной системы Red Hat, что в целом характерно для операционных систем проекта Debian, но актуальность документации иногда оставляет желать лучшего.
Services for UNIX (SFU). Эту подсистему компании Microsoft и Mortis Kern Systems (MKS) создали совместно. Этот пакет содержит расширения, которые обновляют схему Active Directory для хранения таких атрибутов UNIX, как UID (идентификатор пользователя), GID (идентификатор группы), домашние каталоги и т.д. Эта возможность может оказаться полезной, если необходимо хранить и предоставлять информацию UNIX в базе данных Active Directory для поддержки приложений Kerberos.
Приложения Kerberos
Перед тем как начинать интеграцию, стоит определить цели. Недостаточно сказать “Я хочу, чтобы все пользователи проходили аутентификацию с помощью протокола Kerberos”, поскольку это только половина задачи. Вторая половина заключается в подключении пользователей к службам, которые принимают регистрационные данные Kerberos.
Так называемые приложения Kerberos в основном являются приложениями типа кли- ент/север, где сервер ожидает, что клиентский процесс предоставит билет сеанса доступа Kerberos при каждой попытке доступа к ресурсам приложения. Клиентский процесс запро-
граммирован на получение билета сеанса доступа от центра распространения ключей с помощью функций операционной системы.
Это значит, что для работы приложения Kerberos в операционной системе Windows разработчик должен использовать вызовы функций с параметрами, совместимыми с реализацией Windows Kerberos. Клиенты Kerberos, которые нормально работают в среде MITvS Kerberos, могут отказаться работать в среде Windows Kerberos, и наоборот. Например, приложение Kerberos LDAP, запущенное на узле UNIX/Linux, может не поддерживать корректное подключение к Active Directory, поскольку разработчик не использовал вызовы функций, которые ожидает пакет безопасности Kerberos в составе операционной системы Windows.
В операционной системе Windows Server 2003 следующие приложения используют протокол Kerberos для аутентификации.
Подключения LDAP к базе данных Active Directory (SASL/GSSAPI)
Доступ к файлам CIFS/SMB
Безопасные динамические обновления DNS
Подключения IPSec с использованием Internet Key Exchange (IKE)
Защищенные Web-службы
Запросы сертификатов Enterprise Certification Authority (CA)
DCOM/RPC
Из всех служб служба CIFS/SMB, возможно, привлекает больше всего внимания, так как многие организации используют Samba, бесплатную реализацию протокола SMB, для подключения к серверам Windows. Администраторы организаций, использующих Samba, часто применяют единственную реализацию Kerberos, будь то MITvS или Windows.
В этой области новости не утешительны. Версия Samba с поддержкой протокола Kerberos существует, но она не дает возможности клиентам UNIX/Linux получать доступ к службам CIFS/SMB в домене Windows с использованием аутентификационных данных Kerberos. Последняя (на момент создания этой книги) версия Samba все еще ограничена протоколом аутентификации NTLMv2. Дополнительная информация о текущем состоянии разработки в этой области доступна на сайтеwww.us2 . samba. огд/samba/development. html.
Некоторые приложения Windows не поддерживают использование протокола Kerberos. Это значит, что клиенты UNIX/Linux должны использовать другой протокол аутентификации (NTLMv2, дайджест или пароль открытым текстом) для получения доступа к службам сервера под управлением операционной системы Windows.
Telnet. Реализация протокола Telnet от компании Microsoft не поддерживает спецификацию GSSAPI, поэтому интерфейс для реализации билетов Kerberos отсутствует. На момент написания книги компания Microsoft не заявила ни о каких планах по переработке клиента Telnet или службы Tlntsvc для поддержки протокола Kerberos.
FTP. Служба Microsoft FTP работает под управлением инфраструктуры IIS. Компания Microsoft имеет все возможности использовать протокол Kerberos вместе с этой службой, но версия службы в составе операционной системы Windows Server 2003 не предоставляет этой функциональной возможности. Клиент FTP с интерфейсом командной строки в составе операционной системы Windows Server 2003 не претерпел никаких изменений со времен выхода операционной системы Windows 2000 и поддерживает аутентификацию только с помощью протокола NTLMv2, дайджеста или пароля открытым текстом.
Transport Layer Security (TLS). В документе RFC 2712, “Addition to Kerberos Cipher Suites to Transport Layer Security (TLS)’’, описывается механизм интеграции протокола Kerberos в TLS, но компания Microsoft не реализовала этот документ ни в TLS в составе операционной системы Windows Server 2003, ни в клиенте Internet Explorer.
Internet Mail Access Protocol (IMAP). Служба IMAP4 в операционной системе Windows Server 2003 работает как часть службы IIS. Эта служба не поддерживает аутентификацию Kerberos от таких клиентов, как Netscape Communicator или Eudora. Клиент IMAP в составе Outlook и Outlook Express не поддерживает аутентификацию по протоколу Kerberos.
Secure Shell (SSH). В операционных системах Windows Server 2003 и Windows ХР отсутствует собственная реализация службы SSH. Платные серверы SSH для операционной системы Windows предоставляются компаниями SS Н Communications (www. s sh. com) и Pragma Systems (www.pragmasys.com). Служба OpenSSH и связанный с ней тоннель VNC доступны по адресу www. cygwin. com.
Межсферная архитектура
Для начала рассмотрим компоненты MITvS Kerberos и сравним их с компонентами Kerberos в операционной системе Windows Server 2003.
База данных Kerberos
В базе данных Kerberos хранятся имена и секретные ключи участников системы безопасности в пределах сферы. Секретные ключи используются для шифрования различных фрагментов билетов Kerberos и билетов TGT.
MITvS Kerberos хранит базу данных Kerberos в файле principal. db. (В операционных системах Linux этот файл может называться просто Principal.) Обычно файл расположен в каталоге /var/kerberos/krb5kdc.
Доступ с правами администратора к базе данных Kerberos управляется согласно информации файла Kadm5. acl. Это текстовый файл, который также хранится в каталоге /var/ kerberos/krb5kdc.
Другими важными с точки зрения безопасности файлами являются Kadm5 .keytab, который содержит ключи аутентификации центра распространения ключей, и .kSstash, содержащий главный ключ, которым шифруется база данных Kerberos. Эти файлы должны быть защищены для предотвращения атаки на базу данных Kerberos.
Администратор создает базу данных Kerberos вручную с помощью утилиты kdb5_util:
[root@rhsl sbin]#kdb5_util create -s
Initializing database '/var/kerberos/krb5kdc/principal'
% for realm 'RH>COM',
master key name 'K/M@RH.COM'
Будет выдан запрос на ввод главного пароля.
Очень важно не забыть этот пароль.
Введите главный пароль для базы данных КОС:
Повторите главный пароль для базы данных КОС:
В операционной системе Windows этот процесс автоматизирован. Мастер DCPROMO создает базу данных Active Directory и заполняет ее участниками системы безопасности. Объекты LDAP, которые представляют участников системы безопасности, содержат хешированные пароли, удовлетворяющие тем же требованиям, что и записи в классической базе данных Kerberos.
Используемые в операционной системе Windows Server 2003 хешированные пароли создаются по алгоритму MD4. Для шифрования билетов TGT и билетов сеансов доступа в операционной системе Windows используется алгоритм RC4-HMAC. Этот метод выбран из-за совместимости с хешированными паролями в операционной системе Windows Server 2003 и в предыдущих версиях операционной системы Windows.
Алгоритм RC4-HMAC не является стандартным алгоритмом шифрования Kerberos. Компания Microsoft предложила изменить список стандартных алгоритмов шифрования Kerberos, но предложение так и осталось предложением. По этой причине клиенты Kerberos
под управлением UNIX/Linux при аутентификации в Active Directory должны поддерживать отдельную локальную учетную запись. На администратора возлагается задача синхронизации паролей локальной и доменной учетных записей. Обычно для этого используется сценарий, вызывающий функции смены пароля на обеих платформах.
Политики Kerberos
Классическая сфера Kerberos использует небольшой набор параметров конфигурации, которые называются политиками (policies). Сфера может содержать несколько политик. Каждая политика может управлять несколькими участниками безопасности. Список доступных политик можно просмотреть с помощью команды kadmin listpols. Для просмотра содержимого конкретной политики можно воспользоваться командой kadmin getpol <имя_политики> :
kadmin: Policy: Maximum Minimum Minimum Minimumkadmin: Policy: Maximum Minimum Minimum Minimumgetpol Standard_Policy Standard_Policy password life: 31536000"
kadmin: Policy: Maximum Minimum Minimum Minimum
kadmin: Policy: Maximum Minimum Minimum Minimum
password life: 0 password length: 1
number of password character classes: 2
Number of old keys kept: 5 ■
Reference count: 20 ’
Запись password character class определяет, сколько различных элементов должно 1 присутствовать в пароле. Существует пять классов содержимого пароля: верхний регистр, : нижний регистр, числа, знаки пунктуации и управляющие символы. Чем больше классов бу- i дет присутствовать в пароле, тем надежнее он будет, но его сложнее запомнить. ' 1
В операционной системе Windows классические политики Kerberos определяются как 1 подмножество политик паролей. Политики Kerberos в операционной системе Windows опре- 1 деляют такие параметры, как время жизни билета и допустимое смещение времени. В реали- j зации MITvS Kerberos эти параметры описываются в файле Krb5kdc. conf. Обычно этот 1 файл хранится в каталоге /va г/ke гbe го s/. |
Службы Kerberos ■
Демон krb5kdc ожидает запросов на получение билета на TCP- и UDP-порты 88. Демон | kadmin ожидает административных запросов на TCP- и UDP-порты 749, а также обрабаты- 1 вает изменения паролей, полученные по протоколу kpasswd на UDP-порт 464. |Демон krb5kdc ожидает запросов на получение билета на TCP- и UDP-порты 88. Демон | kadmin ожидает административных запросов на TCP- и UDP-порты 749, а также обрабаты- 1 вает изменения паролей, полученные по протоколу kpasswd на UDP-порт 464. |Классическая реализация MITv5 Kerberos разделяет функции выдачи билетов и аутентификации между двумя службами (демонами), которые называются krb5kdc (выдача билетов) и kadmin (аутентификация и администрирование базы данных).
Демон krb5kdc ожидает запросов на получение билета на TCP- и UDP-порты 88. Демон | kadmin ожидает административных запросов на TCP- и UDP-порты 749, а также обрабаты- 1 вает изменения паролей, полученные по протоколу kpasswd на UDP-порт 464. |
Демон krb5kdc ожидает запросов на получение билета на TCP- и UDP-порты 88. Демон | kadmin ожидает административных запросов на TCP- и UDP-порты 749, а также обрабаты- 1 вает изменения паролей, полученные по протоколу kpasswd на UDP-порт 464. |
В операционной системе Windows функцию базы данных выполняет служба Directory. 1 Аналога демона kadmin не существует. Операционная система Windows не ожидает запросов | на порт 749. Служба kdc в операционной системе Windows работает в составе Local Security 1 Authority (LSA) и обрабатывает аутентификацию и выдачу билетов на порту 88 и классиче-1 ские изменения паролей Kerberos на порту 464. Эта функциональная возможность задоку- 3 ментирована в файле draft-trostle-win2k-cat-kerberos-set-passwd-02 . txt, “Win- 1 dows 2000 Kerberos Change Password and Set Password Protocols”. 1
Клиенты Kerberos j
Клиенты Kerberos под управлением UNIX получают билет TGT с помощью приложения 1 kinit. Пользователь вводит пароль (который используется для предоставления доступа к 1 базе данных Principal), и, если аутентификационные данные оказываются правильными, I пользователю предоставляется билет TGT. Утилита kinit кэширует билет TGT, чтобы при- | ложение Kerberos на этом компьютере могло передавать его центру распространения ключей |
при получении билетов сеансов доступа для приложений на других серверах. Администраторы систем UNIX/Linux обычно встраивают транзакцию kinit в процедуру начальной регистрации пользователя.
После завершения сеанса работы пользователя в операционной системе UNIX/Linux запускается утилита kdestroy, которая очищает кэш билетов. Большинство системных администраторов встраивают запуск kdestroy в процедуру завершения сеанса. Если пользователь не завершает сеанс, кэш сохраняется до истечения срока действия билета.
В операционной системе Windows пакет безопасности Kerberos обрабатывает запросы билетов TGT вместе со службой Winlogon. Эта операция выполняется прозрачно для пользователя. Билет TGT и билеты сеансов доступа кэшируются в памяти и никогда не попадают на жесткий диск. После завершения сеанса пользователя билеты удаляются из памяти.
Кроме этого, многие реализации Kerberos предоставляют API, описанный в документе RFC 1964, “The Kerberos Version 5 GEneric Security Service Application Programming Interface (GSS-API) Mechanism”. Протокол Windows Kerberos не поддерживает спецификацию GSSAPI непосредственно. Вместо этого используется подобный набор функций, которые предоставляются через Security Support Provider Interface (SSPI).
Это очень важно для системных администраторов, так как в компании могут присутствовать разработчики, которые пытаются заставить собственные приложения работать как под управлением Windows, так и под управлением UNIX/Linux. Работая с ними для обеспечения совместимости, стоит помнить, что чаще всего базовые механизмы приложений могут не работать из-за различий в поддержке GSS API.
Место хранения службы Kerberos
Клиенты Kerberos под управлением UNIX/Linux обнаруживают центр распространения ключей в файле /etc/rkb5 . conf. Также в этом файле перечислены поддерживаемые пакеты шифрования, файлы библиотек и файлы журналов. Рассмотрим пример сферы, которая называется RH.COM, и центра распространенйя ключей kerberos.rh.com. (Имена в верхнем регистре соответствуют сферам, а имена в нижнем регистре являются полностью определенными именами узлов DNS.)
[logging]
default = FILE: / var/log/krb51ibs'. log
kdc = FILE:/var/log/rkb5kdc.log
admin_server = FILE:/var/log/kadmin.log
[libdefaults]
ticket_lifetime=24000
default_realm=RH.COM
dns_lookup_realm=false
dns_lookup_kdc=false
[realms]
RH.COM = {
kdc = rhsl.rh.com:88
admin_server = rhsl.rh.com:749 default_domain = rh.com
}
[domain_realm]
.rh.com = RH.COM
rh.com = RH.COM
[pam]
debug = false
ticket_lifetime = 36000
renew_lifetime =36000 forwardable = true krb4_convert = false
Клиенты Windows Kerberos не требуют наличия файла Krb5 .conf. Для поиска контроллеров домена они используют записи SRV. Время жизни билетов и другие параметры Kerberos определяются в групповых политиках, связанных с объектом Domain в базе данных Active Directory.
Службы, поддерживающие Kerberos
И в Windows, и в UNIX существуют службы, поддерживающие Kerberos, которые должны получать билеты сеансов доступа (на стороне клиента) и проверять эти билеты (на стороне сервера). Это значит, что клиентские службы должны иметь в своем распоряжении регистрационные данные Kerberos, которые могут быть переданы центру распространения ключей для получения билетов сеансов доступа. С другой стороны, служба на стороне сервера должна иметь регистрационные данные Kerberos для дешифровки билетов сеансов доступа, предоставленных клиентами.
В классической реализации MITvS Kerberos регистрационные данные сервера хранятся в файле /etc/krb5.keytab. В операционной системе Windows регистрационные данные хранятся в системном реестре. Более подробная информация приводится во врезке “LSA Secrets”.
ISA Secrets
Поддерживающие Kerberos службы в операционной системе Windows хранят локальные регистрационные данные Kerberos в разделе системного реестра Security. Этот раздел системного реестра иногда называется базой данных Local Security Authority (LSA). На рис. 11.17 показана стандартная структура LSA Secrets.
< кецМгу f dilor
ЯВ Ww Five*», И*, /
(8 Q (MACHINE. ACC
EB Q _SC_AI=rter
E8 _J _SC_ALG
Ж Ql __5C_Dn$cache
Э Q| _SCJjcenseServtce
® C3 _SC_LmHosts s _SC_MSDTC _SC_RpcLocator
$ Q _SC_5SDPSRV
® Qj __SC_upnphost
$ Q _SC_WebCfent ® Q2 OO83343a-f925-4ed7-bld6-d95dl7aOb57b-RemoteOe$l<topHefc)As$i$tantAccount
Ж Qj 008334За-f925-4ed7-b 1 d6-d95d 17a0b57b-RemoteDe$ktopHelpAs$i$tantSID
Ж Q 20ed87e2-3b82-4114-81l:9-5e219ed4c481-SALEMHELPACC0UNT
Ф-£1 DhcpServer Secret Key For Rogue Detection ®0j dpapi_system
® Ql G${ED8F4747-E13D-47bc-856B-5CEFElA81A7F}
№ -1 L$-(683E6424-AF3E-4bff-ACB6-DA535F0DDC0A};
Ж Q L$BETA3TIMEBOMB_1320153D-8DA3-4e8e-B27B-0De88223A588
Ж Cj L$HYDRAENCKEY_28ada6da-d622-lldi-9cb9-00c04fbl6e75J
®Q)NL$KMX
/•Qisac Q SAI'a
® 0a TermServLiceningSignKey-l2d4b7c8-77d5-lldl-8c24-00c04fa30e0d
Рис. 11.17. LSA Secrets в разделе Securi ty системного реестраРис. 11.17. LSA Secrets в разделе Securi ty системного реестраEB Q] TermServLicensiogExchKey-l2d4b7c8'77d5-lidl-8c24-00c04fa30e0d $ 02 TermServUcerelngServerld-12d4b7c8-77d5-lidl-ec24-00c04fa30e0d ® 03 TermServLicenslng5tatus-12d4b7c8-77d5-lldl-ec24-00c04fa30e0d
Рис. 11.17. LSA Secrets в разделе Securi ty системного реестра
Рис. 11.17. LSA Secrets в разделе Securi ty системного реестра
В этой базе данных хранится удивительно большой объем информации системы безопасности. Часть информации не настолько защищена, как можно представить. Утилита взлома, lsadump2, позволяет отобразить некоторые фрагменты содержимого большого количества разделов этой базы данных. Например, утилита может показывать пароли коммутируемого доступа, сохраненные пользователями. Поскольку пользователи стараются использовать
один и тот же пароль для аутентификации при коммутируемом и сетевом доступе, это может стать серьезной брешью в системе обеспечения безопасности.
На момент написания книги утилита lsadump2 не работала под управлением операционных систем Windows Server 2003 и Windows ХР. Но к моменту выхода книги в печать, скорее всего, кто-то ее обновит.
В классической среде Kerberos администратор выполняет две операции, которые подготавливают поддерживающее Kerberos приложение к аутентификации. Оба действия выполняются с помощью утилиты kadmin.
Создание в базе данных Kerberos учетной записи, которая представляет службу и узел. Учетная запись службы использует формат основного имени службы (Service Principal Name — SPN).
Создание записи в файле Krb5 . key tab на сервере, который поддерживает работу службы. Эта запись содержит тот же секретный ключ, который использовался для создания учетной записи в базе данных Kerberos. Запись генерируется с помощью специального вызова функции, который не передает секретный ключ по сети.
После инициализации поддерживающей Kerberos службы служба проходит аутентификацию у центра распространения ключей и получает билет TGT. При использованйи службы клиент получает билет сеанса доступа, который зашифрован секретным ключом службы. Служба использует собственную копию секретного ключа из файла key tab для дешифровки ключа сеанса и завершения транзакции аутентификации.
Основные имена служб
Kerberos идентифицирует службы с помощью основного имени службы. Это имя используется как в базе данных Kerberos, так и в файле keytab. Например, основное имя службы ftp, которая работает на узле rhsl в домене DNS rh. com и сфере RH. СОМ, будет выглядеть как f tp/rhsl. rh. com@RH. COM. Синтаксис имени можно описать следующим образом:
<первичное_имя>/<экземпляр>@<сфера*
<первйчсное_имя>. Указывает на службу, например ftp или host (используется для служб telnet и rsh). Элемент <первичное_имя> может также указывать на роль Kerberos, например, admin или changepw. Основное имя службы может идентифицировать пользователя, но этот формат обычно называется основным именем пользователя или UPN (User Principal Name). Пользователь mmantle с правами управления базой данных Kerberos в сфере RH.COM будет иметь основное имя пользователя mmantle/ admin@RH.COM
<экземпляр». Идентифицирует полностью определенное доменное имя узла. В случае, если служба предоставляется центром распространения ключей, элемент окземпляр* является именем сферы. Например, служба выдачи билетов TGT будет иметь основное имя службы krbtgt /RH. COM0RH. COM.
<сфера*. Идентифицирует сферу Kerberos. Буквы верхнего регистра отличают имя от имени DNS. В операционной системе Windows имя DNS и имя сферы всегда совпадают, так как домены Windows должны соответствовать пространству имен DNS.
Операционная система Windows хранит основное имя службы в базе данных Active Directory в виде атрибута соответствующего объекта компьютера. Например, служба LanMan Server на сервере serveri в домене Company. com будет регистрировать себя с помощью основного имени службы cif s/serveri. company. com@COMPANY. COM. (CIFS расшифровывается как Common Internet File System и является еще одним названием протокола SMB.)
Как будет показано в следующем разделе, операционная система Windows может использовать основные имена служб, которые отличаются от стандартного формата. Это может привести к проблемам совместимости.
Некоторые классические службы, поддерживающие Kerberos, не используют специальные имена в компоненте <первичное_имя> основного имени службы. Например, службы rlogin, rsh и telnet используют в качестве идентификатора <первичное_имя> имя host, например host /rhsl. rh. com@RH. COM. Компания Microsoft использует идентификатор host для обозначения любого компьютера, на котором работает протокол Kerberos.
Перечень основных имен служб и пользователей в базе данных Kerberos можно получить с помощью команды kadmin getprincs. Рассмотрим пример результата выполнения этой команды. Обратите внимание, что в основном имени пользователя указывается только сфера:
KZM@RH.COM
ftp/rhsl.rh.com@RH.COM
host/rhsl.rh.com@RH.COM
kadmin/admin@RH.COM
kadmin/changepw@RH.COM
kadmin/history@RH.COM
krbtgt/RH.COM@RH.COM root/admin@RH.COM root@RH.COM
Идентификатор R/M@realm указывает на главный ключ, который используется для шифрования всей базы данных. Администратор предоставляет этот ключ при создании базы данных.
Совместимость и основные имена служб
Компания Microsoft внесла некоторые изменения в структуру основных имен служб (SPN), используемых в операционной системе Windows. Это сделано для обеспечения работоспособности в двух ситуациях, которые не возникают при использовании классической реализации MlTv5 Kerberos.
Работа в доменах Windows
Преобразование имен на основе “плоских” имен NetBIOS
Проще всего обнаружить отличия в новой версии, запустив утилиту setspn из состава Resource Kit. С другой стороны, можно воспользоваться инструментом ADSI Editor (Adsiedit .msc) из состава Support Tools для просмотра объекта Computer контроллера домена. Основные имена служб хранятся в атрибуте ServicePrincipalName.
Рассмотрим отчет утилиты setspn относительно основного имени службы (SPN), зарегистрированного на контроллере домена Windows Server 2003. (Каждая из записей получает расширение ©COMPANY. СОМ, чтобы получилось полное основное имя пользователя.)
C:\>setspn -L serverl.company.com
Registered ServicePrincipalNames for CN=SERVER1,OU-Domain
Controllers,DC=company,DC=com:
SMTPSVC/SERVERI
SMTPSVC/serveri.company.com
NtFrs-88f6d2bd-b746-lld2-a6d3-00d04fc9b242/serveri.company.com
DNS/serveri.company.com
exchangeAB/SERVERI
GC/serveri.company.com/company.com
HOST/serveri.company.com/COMPANY
H0ST/SERVER1
HOST/serverl.company.com
HOST/serverl.company.com/company.com
E3514236-4B06-11D1-AB04-00C04FC2DCD2/a54acff0-8185-4086-8d35-:
'Ъ dlcff06ble09/company.com
LDAP/ a54acff0-8185-4086-8d35-dlcff06ble09._msdcs.company.com
LDAP/serveri.company.com/COMPANY
LDAP/SERVERI
LDAP/serveri.company.com
LDAP/serverl.company.com/company.com
Обратите внимание, что некоторые основные имена пользователей обозначают узлы и домены с помощью “плоских” имен NetBIOS, а в некоторых именах используются иерархические имена DNS. Клиенты Windows могут использовать любое имя для получения билета сеанса доступа. По идентификаторам GUID домены уникально идентифицируются в службе DNS; таким образом, клиенты могут отправлять запросы на обслуживание к своим доменам.
Такое изменение формата основного имени службы в операционной системе Windows может отрицательно сказаться на совместимости. Для использования аутентификации по протоколу Kerberos разработчикам придется менять код, в котором используются стандартные вызовы функций, работавшие с классическими основными именами служб Kerberos.
Отображение имен
Формат основного имени службы имеет еще одну незаметную связь с системным администрированием. Операционная система Windows не предоставляет механизмов создания классических составных элементов Kerberos <первичное_имя>. Например, невозможно создать учетную запись Windows, которая называется jane/admin@COMPANY. СОМ. Реализация MITv5 Kerberos распознает составные имена, поэтому администраторы UNIX/Linux могут попытаться пройти аутентификацию, как jane/admin. Для этого необходимо воспользоваться дополнительным механизмом отображения имен (name mapping).
Объект пользователя или компьютера в Active Directory имеет атрибут, который называется AltSecurityldentities и может содержать составное имя Kerberos. Для ввода значения этого атрибута необходимо щелкнуть правой кнопкой мыши на объекте пользователя на консоли Active Directory — Users and Computers (Active Directory — пользователи и компьютеры) и выбрать из контекстного меню команду Name Mappings (Отображение имен), как показано на рис. 11.18.
Рис. 11.18. Объекты пользователей в окне, открывающемся после выбора команды Name Mapping
Создание доверительного отношения между сферами
На этом этапе были рассмотрены все компоненты, необходимые для создания доверительного отношения между доменом Windows Server 2003 и классической сферой Kerberos. Рассмотрим последовательность действий по созданию доверительного отношения.
ЙЙ33Сервер BIND DNSСервер BIND DNSДомен Windows Server 2003Домен Windows Server 2003Центр распространения ключей MITv5 Kerberos Сфера: rh.comЦентр распространения ключей MITv5 Kerberos Сфера: rh.comДвустороннее транзитивное доверительное отношение между сферамиДвустороннее транзитивное доверительное отношение между сферамиПри доступе к службе, поддерживающей Kerberos, клиент предоставляет билет сеанса доступа KerberosПри доступе к службе, поддерживающей Kerberos, клиент предоставляет билет сеанса доступа KerberosОсновной сервер rh.comОсновной сервер rh.com
Й
Й
3
3
Сервер BIND DNS
Сервер BIND DNS
Домен Windows Server 2003
Домен Windows Server 2003
Центр распространения ключей MITv5 Kerberos Сфера: rh.com
Центр распространения ключей MITv5 Kerberos Сфера: rh.com
Двустороннее транзитивное доверительное отношение между сферами
Двустороннее транзитивное доверительное отношение между сферами
При доступе к службе, поддерживающей Kerberos, клиент предоставляет билет сеанса доступа Kerberos
При доступе к службе, поддерживающей Kerberos, клиент предоставляет билет сеанса доступа Kerberos
Основной сервер rh.com
Основной сервер rh.com
Создайте двустороннее доверительное отношение в домене Windows, в котором в качестве партнера указана сфера Kerberos. Это приведет к созданию необходимого участника системы безопасности Kerberos в базе данных Active Directory для поддержки выдачи меж- сферных билетов TGT.
Создайте участников системы безопасности krbtgt в сфере Kerberos, которые будут представлять домен Windows. Такие участники системы безопасности поддерживают доверительные отношения, позволяя центру распространения ключей в сфере Kerberos выдавать межсферные билеты TGT клиентам из домена Windows.
В следующих примерах в качестве центра распространения ключей MITvS используется операционная система Red Hat Linux 7.1. Подробные инструкции доступны по адресу www.redhat.com/support/manuals/RHL-7.l-Manual/reg-guide/sl-kerberos- server. html. Если сфера Kerberos уже существует, этот раздел можно пропустить.
Установка и настройка MITvS Kerberos
На рис. 11.19 показана конфигурация центра распространения ключей (KDC) и конфигурация клиента для доверительных отношений между сферами. Центр распространения ключей MITvS называется rhsl. Для преобразования имен используется сервер BIND. На сервере хранится зона для домена rh. com. Сфера называется RH. СОМ.
Сервер, поддерживающийKerberos
Рис. 11.19. Конфигурация доверительного отношения между сферами
Ниже приведена краткая пошаговая инструкция по созданию сферы MITv5. Для ее выполнения необходимо зарегистрироваться от имени учетной записи с привилегиями администратора, например, root.
Установите пакеты krb5-workstation и krb5-server.
Воспользуйтесь редактором kedit (или любым другим текстовым редактором) для редактирования файла /etc/krb5 . conf. Файл должен выглядеть следующим образом: [logging] default = FILE:/var/log/krb51ibs.log kdc .= FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log
[libdefaults]
ticket_lifetime = 24000 default_realm = RH.COM dns_lookup_realm=false dns_lookup_kdc=false
[realm]
RH.COM = {
kdc = rhsl.rh.com:88
admin_server = rhsl.rh.com:749 default_domain = rh.com
}
[domain_realm]
.rh.com = RH.COM
rh.com = RH.COM
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
[pam]
debug = false
ticket^_lifetime = 36000
renew_lifetime = 36000
( forwardable = true krb4_convert = false
Отредактируйте файл /var/Kerberos/krb5kdc/kdc. conf. Он должен выглядеть следующим образом:
[kdcdefaults]
acl_file = /var/kerberos/krb5kdc/kadm5.acl dict_file = /usr/share/dict/words
admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
[realms]
RH.COM = {
master_key_type = des-cbc-crc
supported_enctypes = desr-cbc-crc:normal des3-cbc-raw:normal ^ des3-cbc-shal:normal des-cbc-crc:v4 des-cbc-crc:afs3 }
Создайте базу данных Kerberos с помощью следующей команды (выполняемые файлы хранятся в каталоге /usr/Kerberos/sbin): kdb5_util create -s
Отредактируйте файл /var/kerberos/krb5kdc/kadm5.acl, чтобы он выглядел следующим образом:
*/admin@RH.COM *
Перейдите в каталог /etc/rc .d/init .d и запустите демоны Kerberos с помощью следующих команд:
sh krb5kdc start
sh kadmin start.
sh krb524 start
Запустите gkadmin для добавления участников системы безопасности в базу данных Kerberos. Как минимум необходимо добавить участников для учетной записи root и собственной учетной записи администратора. Учетная запись уже должна существовать в операционной системе Linux перед ее добавлением в базу данных Kerberos. Автоматическая синхронизация паролей не поддерживается. Для изменения паролей Kerberos пользователи могут использовать утилиту kpasswd.
Запустите утилиту kinit для выдачи себе билета.
Запустите утилиту klist для проверки правильности выдачи билета. (Утилита с графическим интерфейсом называется krb5.) Рассмотрим пример использования этой утилиты:
[root@rhsl Admin]# klist
Ticket cache: FILE:/tmp/krb5cc_p2722
Default principal: Admin@RH.COM
Valid startingExpiresService principal
10/05/01 13:47:5110/05/01 23:47:51 krbtgt/RH.COM@RH.COM
Kerberos 4 ticket cache: /tmp/tktO
klist: You have no tickets cached
Создание доверительного отношения между сферами
На этом этапе созданы домен Windows и классическая сфера Kerberos. Теперь необходимо создать доверительное отношение между сферами, чтобы пользователи, прошедшие аутентификацию в сфере Kerberos или домене Windows, могли получать доступ ко всем ресурсам сети. Рассмотрим основные особенности создания доверительного отношения.
Контроллер домена Windows, на котором создано доверительное отношение, должен “знать” расположение центра распространения ключей (KDC) в сфере MITv5. Для этого используется эквивалент записи keytab в операционной системе Windows. Эта запись хранится в системном реестре и создается с помощью утилиты ksetup.
Мастер создания доверительных отношений (Windows Trust Wizard) создает объект Active Directory с секретным ключом, который известен участникам системы безопасности в сфере Kerberos. Этот объект “представляет” сферу при распространении билетов TGT. Объект находится в контейнере cn=Sy stem, de =<домен>, de=<корень>. Объект имеет то же имя, что и сфера Kerberos. Секретный ключ (пароль) предоставляется администратором при создании доверительного отношения.
В сфере Kerberos необходимо создать двух участников системы безопасности krbtgt, которые будут представлять обе стороны двустороннего доверительного отношения. Для этих участников системы безопасности установлен тот же пароль, что и для объекта доверительного отношения. Один из них выдает пользователям из домена Windows билеты TGT. Второй выдает билеты TGT со ссылкой для пользователей Kerberos, когда они пытаются получить доступ к домену Windows.
Администратор должен создать “соответствие” (mapping) между участниками системы безопасности в сфере Kerberos и пользователями в домене Active Directory. Это соответствие позволяет генерировать локальные маркеры доступа для классических клиентов Kerberos.
Администратор должен предоставить клиентам Windows возможность поиска центра распространения ключей Kerberos. Это необходимо, так как классический центр распростра-
нения ключей Kerberos не регистрирует записи SRV в службе DNS. Операционная система Windows хранит имя сферы и полностью определенное имя DNS классических центров распространения ключей MITv5 в системном реестре. (Для операционной системы Windows это эквивалент записей в файле Krb5 . conf.)
На основе изложенной информации можно создать транзитивное двустороннее доверительное отношение между доменом Windows и классической сферой Kerberos. В примере, описанном в процедуре 11.8, используются участники системы безопасности и серверы, показанные на рис. 11.19.
Процедура 11.8. Настройка доверительного отношения между сферами
Выберите контроллер домена в корневом домене леса Windows.
Зарегистрируйтесь от имени учетной записи Enterprise Administrator (Администратор предприятия).
Установите на сервер пакет Support Tools. При этом будут установлены утилиты MITv5 Kerberos.
Запустите на консоли следующую команду:
ksetup /addkdc RH.COM rhsl.rh.com
Откройте консоль Active Directory — Domains and Trusts (Active Directory — домены и доверия).
Щелкните правой кнопкой мыши на строке для корневого домена леса и откройте окно Properties (Свойства).
Откройте вкладку Тrusts (Доверительные отношения).
Щелкните на кнопке New Trust (Создать доверительное отношение). Запустится мастер создания доверительного отношения (New Trust Wizard).
Щелкните на кнопке Next (Далее). Откроется окно Trust Name (Имя доверительного отношения).
В поле Name (Имя) введите имя сферы Kerberos, например RH.COM.
В поле Trust Password (Пароль) введите надежный по отношению ко взлому пароль, который будет использован для создания доверительного отношения. Этот пароль потребуется при создании участников системы безопасности в сфере Kerberos.
Щелкните на кнопке Next (Далее). Откроется окно Trust Туре (Тип доверительного отношения). Установите переключатель Realm Trust (Доверительное отношение между сферами).
Щелкните на кнопке Next (Далее). Откроется окно Transitivity of Trust (Транзитивность доверительного отношения). Выберите переключатель Transitivity (Транзитивное), чтобы и другие домены леса могли использовать это доверительное отношение.
Щелкните на кнопке Next (Далее). Откроется окно Direction of Trust (Направление). Выберите переключатель Two-Way (Двухстороннее), чтобы предоставить возможность участникам безопасности с каждой стороны получать доступ к ресурсам друг друга.
Щелкните на кнопке Next (Далее). Откроется окно Trust Selections Complete (Выбор завершен). Просмотрите установленные параметры и исправьте все обнаруженные ошибки.
Щелкните на кнопке Next (Далее). Откроется окно Completing the New Trust Wizard (Завершение работы мастера создания доверительного отношения). Щелкните на кнопке Finish (Готово) для сохранения изменений и создания доверительного отношения.
На этом этапе создана первая часть доверительного отношения на стороне Windows. Теперь необходимо перейти к центру распространения ключей в сфере Kerberos для завершения создания доверительного отношения.
Запустите утилиту kadmin и введите регистрационные данные администратора.
Добавьте следующих участников системы безопасности (замените слово password паролем, который использовался при создании отношения доверия в Windows):
ank -pw password krbtgt/COMPANY.COM@RH.COM ank -pw password krbtgt/RH.COM@COMPANY.COM
Теперь осталось создать “соответствие” имен между участниками системы безопасности в сфере Kerberos и учетными записями пользователей Active Directory.
Откройте консоль Active Directory — Users and Computers (Active Directory — пользователи и компьютеры).
Создайте учетную запись пользователя, который соответствует участнику системы безопасности в сфере Kerberos.
Щелкните правой кнопкой мыши на объекте пользователя и выберите команду Name Mappings (Соответствия имен) из контекстного меню.
Откройте вкладку Name Mappings (Соответствия имен).
Щелкните на кнопке Add (Добавить). Откроется окно Add Kerberos Principal Name (Добавить основное имя Kerberos).
Введите имя участника системы безопасности Kerberos, соответствующее пользователю, напримерroot@RH.СОМ.
Щелкните на кнопке ОК, чтобы сохранить изменения.
Последняя операция должна быть выполнена на каждой рабочей станции или сервере в домене Windows, на которых пользователи будут регистрироваться в сфере Kerberos. Эта операция сообщает компьютеру, где найти центр распространения ключей в классической сфере Kerberos, и требует установленной утилиты ksetup из состава Support Tools.
На рабочей станции или сервере запустите следующую команду (rhsl является центром распространения ключей в сфере RH. СОМ):
ksetup /addkdc RH.COM rhsl.rh.com
Тестирование доверительных отношений между сферами
После настройки доверительного отношения между сферами проверьте его работоспособность, чтобы удостовериться, что пользователь получает билеты. Выполните последовательность действий, описанную в процедуре 11.9, на консоли рабочей станции, на которой запускалась утилита ksetup.
Процедура 11.9. Тестирование межсферной генерации билетов по протоколу Kerberos
Нажмите комбинацию клавиш <Ctrl+Alt+Del> для регистрации. В списке окна регистрации Winlogon выберите имя сферы Kerberos.
Введите имя и пароль участника системы безопасности Kerberos, которые были настроены с помощью соответствия имен.
Нажмите клавишу <Enter>. Регистрация должна завершиться успешно.
Откройте приглашение командной строки. х
Запустите команду klist tgt для просмотра содержимого билета TGT, выданного клиенту. Ниже приведен пример результата выполнения этой команды: C:\>klist tgt Cached TGT: ServiceName: krbtgt TargetName: krbtgt FullServiceName: root
DomainName: RH.COM
TargetDomainName: RH.COM
AltTargetDomainName: RH.COM
TicketFlags: 0x40c00000
KeyExpirationTime: 256/0/29920 0:102:8048
StartTime: 10/6/2001 13:19:02
EndTime: 10/6/2001 23:19:02
RenewUntil: 10/6/2001 13:19:02
TimeSkew: 10/6/2001 13:19:02
Воспользуйтесь командой klist tickets для просмотра билетов, выданных пользователю. Обратите внимание, что некоторые билеты выданы доменом Windows (с помощью доверительного отношения), а остальные билеты получены непосредственно из сферы Kerberos.
C:\>klist tickets
Cached Tickets: (6)
Server: krbtgt/RH.COM@RH.COM
KerbTicket Encryption Type: Kerberos DES-CBC-CRC
End Time: 10/6/2001 23:19:02
Renew Time: 10/6/2001 13:19:02
Server: krbtgt/COMPANY.COM0RH.COM
KerbTicket Encryption Type: Kerberos DES-CBC-CRC
End Time: 10/6/2001 23:19:02
Renew Time: 10/6/2001 13:19:02
Server: krbtgt/RH.COM@RH.COM
KerbTicket Encryption Type: Kerberos DES-CBC-CRC
End Time: 10/6/2001 23:19:02
Renew Time: 10/6/2001 13:19:02
Server: cifs/serverl.company.Com@COMPANY.COM
KerbTicket Encryption Type: RSADSI RC4-HMAC (NT)
End Time: 10/6/2001 23:19:02
Renew Time: 10/6/2001 13:19:02
Server: 1dap/serveri.company.com/company.com@COMPANY.COM KerbTicket Encryption Type: RSADSI RC4-HMAC (NT) End Time: 10/6/2001 23:19:02 Renew Time: 10/6/2001 13:19:02
Server: host/serveri.company.com@COMPANY.COM
KerbTicket Encryption Type: RSADSI RC4-HMAC (NT)
End Time: 10/6/2001 23:19:02
Renew Time: 10/6/2001 13:19:02
На этом этапе необходимо проверить доступ к службам, поддерживающим Kerberos, на обеих сторонах доверительного отношения. Некоторые приложения не предназначены для работы на нескольких платформах одновременно. Например, версия утилиты rlogin, поддерживающая Kerberos и работающая под управлением операционной системы Windows, не может подключаться к службе klogin или eklogin, работающей на узле UNIX/Linux.
Аудит безопасности
Работники санитарной службы и квантовые физики давно знают, что если что-то нельзя увидеть, это еще не значит, что этого нет. Даже если организация невелика, все хорошо относятся друг к другу и никто даже не думает наносить вреда системе, администратору все равно стоит принять меры предосторожности.
Вот мы и подошли к последнему из трех китов безопасности — аудиту. Отчеты обо всех действиях по отношению к объектам системы безопасности Windows могут быть сохранены в соответствующем журнале. Это приводит к значительной нагрузке на серверы, поэтому объекты аудита необходимо выбирать очень осторожно.
В этом разделе рассматриваются следующие моменты: настройка аудита, по отношению к чему и когда следует выполнять аудит, как читать журналы аудита, а также настройка системы на отправку уведомлений администратору о предупреждениях от системы аудита, что избавляет администратора от постоянного просмотра журналов. Также рассматриваются различные продукты от сторонних производителей, которые упрощают аудит и создание отчетов о событиях.
В составе операционной системы Windows предоставляется большой набор инструментов для аудита. В основном, эти утилиты предназначены для мониторинга доступа к объектам системы безопасности, например файлам и папкам файловой системы NTFS, разделам системного реестра, объектам Active Directory, объектам принтеров и служб. Администратор- должен понимать, что в данном случае выполняется мониторинг попыток доступа, а не только успешного внесения изменений.
Аудит является аналогом слежки за приглашенной няней. В отчете будут сведения, что няня открывала холодильник, но не будет информации о том, взяла ли она что-либо из холодильника. Не рассматривайте аудит как средство контроля за соблюдением правил. Несмотря на ограничения аудит иногда позволяет ойределить источник проблемы и избавляет администратора от длительного процесса угадывания причин неполадок.
Журнал аудита
После включения аудита используются две службы. Монитор ссылок безопасности сообщает о событиях, связанных с самими объектами безопасности, а служба LSASS сообщает обо всех остальных событиях.
Эти службы записывают результаты аудита в журнал Secevent. evt, который хранится в каталоге \Windows\System32\Conf ig вместе с разделами системного реестра. Содержимое журнала можно просматривать с помощью консоли Event Viewer (Просмотр событий), доступной из меню Starts Programs^ Administrative Tools^Event Viewer (Пуск1^ Программы^ Администрированием Просмотр событий). Кроме этого, Event Viewer (Просмотр событий) можно запустить из командной строки с помощью команды eventvwr. В окне Event Viewer (Просмотр событий) интересующий журнал доступен в разделе Security (Безопасность).
По умолчанию размер журнала событий составляет 512 Кбайт, чего явно недостаточно для хранения информации о большом количестве событий. По умолчанию после заполнения журнала начинается перезапись старых записей, что может привести к потере информации о старых событиях. В процедуре 11.10 рассматривается изменение этого и других параметров файла журнала.
Процедура 11.10. Изменение параметров файла журнала
ставляет сервер отказывать в подключении, если переполняется журнал безопасности. Не забывайте сохранять содержимое журнала и очищать журнал вручную раз в неделю.
. Щелкните на кнопке ОК, чтобы сохранить внесенные изменения и закрыть окно Properties (Свойства).
Управление доступом к журналу безопасности
Стоит внимательно следить за правами доступа к журналу безопасности. Пользователи, которым разрешено очищать журнал событий, могут удалить свои "отпечатки пальцев" с места преступления. Система записывает событие очистки системного журнала, и администратор может спросить у пользователя, какую информацию тот решил скрыть, но детали удаленных записей будут утрачены.
Конфигурацию журнала событий можно изменить с помощью групповых политик, которые распространяются на серверы в пределах домена. Это позволяет создать стандартный набор параметров протоколирования, который упрощает сбор информации для аудита. Эта групповая политика может быть установлена для домена и для организационной единицы, содержащих серверы. Политики хранятся в разделе Computer Configuration^Windows Settings^Security Settings1^ Event Log (Конфигурация компьютерам Конфигурация Windows'^ Параметры безопасности M Журнал событий). Перечислим эти политики.
Maximum log sizes (Максимальный размер журнала). Этот набор политик устанавливает максимальный размер каждого журнала событий. Значение этого параметра не должно быть больше объема свободного дискового пространства. В операционной системе Windows 2000 размер журналов событий не может превышать 4 Гбайт. В операционной системе Windows Server 2003 размер журналов событий ограничен максимальным размером тома NTFS.
Restrict Guest access (Запретить доступ локальной группы Guest к журналу). Установка этой политики никогда не потребуется, так как никогда не следует использовать учетную запись Guest.
Retain logs (Сохранение событий в журнале). Включите эту политику, чтобы заставить администраторов периодически сохранять копию журналов событий. Эта возможность не дает серьезного выигрыша в отношении производительности, поскольку автоматическая архивация и очистка журналов событий не выполняется.
Retention methods (Методы сохранения). Необходимо всегда сохранять журналы событий безопасности для этой политики, установив флажок Do Not Overwrite Events (He затирать события). Важно периодически выполнять архивацию журналов событий, так как в противном случае будут утеряны события, которые происходят после переполнения журнала.
Shutdown the computer when the Security log is full (Завершать работу компьютера при переполнении журнала безопасности). Включение этой политики может потребоваться в системах с повышенными требованиями к безопасности. При переполнении журналов будет выполнена стандартная процедура завершения работы. После этого только администратор сможет зарегистрироваться и очистить журнал. При включении этой политики никогда не забывайте периодически очищать журнал событий.
Включение аудита
Аудит может потребовать заметной доли ресурсов системы, поэтому по умолчанию он не включен. Можно включить аудит на локальном сервере или установить политику, которая включит аудит на всех серверах в пределах организационной единицы или всего домена.
Политики аудита устанавливаются в групповых политиках в разделе Computer Configura- tion^Windows Settings^Security Settings^Local Policies^Audit Policy (Конфигурация компьютера^ Конфигурация Windows1^ Параметры безопасности ■$ Локальные политики1^ Политика аудита). Можно включить аудит успешных событий, неудачных событий или обоих типов событий. Поддерживается аудит следующих событий.
Account Logon (Аудит входа в систему). В этом случае контролируется сетевой доступ к системе (начало и завершение сеанса). Локальный доступ к системе контролируется политикой Logon Events (Аудит событий входа в систему). Устанавливайте эту политику только в том случае, если необходимо получить список учетных записей, которые получают доступ к серверу, и список привилегий, которые назначаются этим учетным записям.
Account Management (Аудит управления учетными записями). Записываются события добавления, удаления или изменения атрибутов участника системы безопасности. Это особенно полезно при делегировании административных привилегий сотрудникам за пределами отдела, когда необходимо проконтролировать их действия.
Directory Services Access (Аудит доступа к службам каталога). Записываются события доступа к объектам Active Directory. Дополнительную информацию по этому вопросу можно получить в разделе “Активизация аудита доступа к объектам”.
Logon Events (Аудит событий входа в систему). Записываются события локальной регистрации и завершения сеанса на консоли компьютера. Сетевая регистрация и завершение сеансов управляются политикой Account Logon (Аудит входа в систему). Дополнительная информация приводится во врезке “Ошибки аудита при регистрации и завершении сеанса”.
Object Access (Аудит доступа к объектам). Регистрируются события доступа к объектам системы безопасности, например файлам и папкам NTFS, разделам системного реестра. Аудит доступа к объектам Active Directory управляется политикой Directory Services Access (Аудит доступа к службе каталогов). Кроме этого, необходимо настроить аудит каждого файла, каталога или раздела в отдельности. Дополнительная информация приводится в разделе “Активизация аудита доступа к объектам".
Policy Change (Аудит изменения политики). Записываются события изменения групповых политик. Эту политику необходимо устанавливать всегда, поскольку она позволяет получить информацию об отключении политик для сокрытия определенных действий.
Privilege Use (Аудит использования привилегий). Записываются события привилегированного доступа к ресурсам системой или учетными записями с системными привилегиями. Например, только администраторы могут открывать журнал безопасности. При открытии журнала безопасности в раздел Privilege Use заносится запись, содержащая имя учетной записи и действие, которое привело к использованию привилегии.
Process Tracking (Аудит отслеживания процессов). Записываются события доступа к выполняемому коду, например к файлам с расширениями . ехе, . <^11 и . осх. Это может потребоваться для определения того, кто получал доступ к определенному файлу. Также эта возможность упрощает отслеживание вирусов, хотя большинство продуктов антивирусного сканирования предоставляет более мощный инструментарий.
■ System Events (Аудит системных событий). Регистрируются события различных обновлений системы, которые возникают во время работы. Если проводится диагностика службы, которая по непонятной причине отказывается работать, эта политика аудита оказывается очень полезной. Вместе с политикой Process Tracking (Аудит отслеживания процессов) эта политика позволяет проверить, не выполняет ли служба запрещенных или некорректных действий или не запрашивает ли таких действий от системы. Кроме этого, результат использования этой политики показывает последовательность инициализации различных поставщиков безопасности."
Управление журналом событий с помощью утилиты auditpol
Утилита auditpol позволяет изменить параметры аудита на отдельных серверах. Утилита не устанавливает политики Active Directory, поэтому она не настолько полезна при корпоративных сетях, но она очень помогает при управлении политиками аудита с помощью командной строки.
Утилита auditpol управляет следующими политиками аудита:
System
Logon
Object Access
Privilege Use
Process Tracking
Policy Change
Account Management
Directory Service Access
Account Logon
Синтаксис команды выглядит следующим образом:
auditpol \\<имя_сервера> /enable /logon:failure
Активизация аудита доступа к объектам
После установки аудита доступа к объектам или доступа к службам каталога в групповой политике необходимо включить аудит интересующих объектов. Для этого группу или пользователя необходимо добавить в список контроля доступа для интересующего объекта или группы.
Для добавления записей аудита выберите Start^Properties1^ Security1^ Advanced^Auditing. Для объектов Active Directory группа Everyone добавляется по умолчанию для всех объектов домена.
При включении аудита соблюдайте осторожность с наследованием разрешений. Случайно можно связать запись аудита со списком контроля доступа для большого количества файлов и папок, что минимизирует эффективность аудита и приводит к заполнению журнала безопасности бесполезными записями.
Аудит доступа к объектам (Object Access) стоит включать в политике, связанной с организационной единицей, в которую входит интересующий объект. Если включение аудита на большом количестве компьютеров не планируется, интересующий компьютер можно добавить в список контроля доступа самого компьютера.
Аудит доступа к службам каталога (Directory Service Access) желательно включать в политике, связанной с организационной единицей, в которую включены контроллеры домена.
Применение изменений в групповых политиках
После изменения политики безопасности необходимо обновить содержимое базы данных безопасности, чтобы политика вступила в силу. Для этого необходимо воспользоваться утилитой gpupdate. Утилита gpupdate выполняет то же обновление, которое выполняется автоматически каждые пять минут на контроллере домена и каждые 90 или 120 минут на остальных компьютерах, входящих в домен. Перезагрузка компьютера не требуется.
После обновления политик аудита проверьте их действие, выполнив соответствующую операцию. Например, при включении аудита учетных записей, входящих в систему (Audit Account Logon Events) и аудита событий входа в систему (Audit Logon Events) зарегистрируйтесь на рабочей станции и попытайтесь получить доступ к контроллеру домена через общий ресурс. Это должно привести к регистрации двух событий: одного — для регистрации на консоли рабочей станции, а второго — для сетевого доступа.
Ошибки аудита при регистрации и завершении сеанса
Во время аудита событий при регистрации и завершении сеанса для записи журнала относительно неудачной регистрации указывается код события. В некоторых случаях вместе с кодом не предоставляется описание. Ниже приведено описание этих кодов.
528 Успешная регистрация
529 Неудачная регистрация: Причина: Неизвестное имя пользователя или неправильный пароль
530 Неудачная регистрация: Причина: Превышение допустимого времени регистрации
531 Неудачная регистрация: Причина: Учетная запись отключена
532 Неудачная регистрация: Причина: Истек срок действия учетной записи пользователя
533 Неудачная регистрация: Причина: Пользователю запрещена регистрация на этом компьютере
534 Неудачная регистрация: Причина: Пользователю запрещен такой тип регистрации на этом компьютере
535 Неудачная регистрация: Причина: Истек срок действия пароля
536 Неудачная регистрация: Причина: Компонент NetLogon не активен
537 Неудачная регистрация: Причина: Неожиданная ошибка во время регистрации
538 Завершение сеанса пользователя
539 Неудачная регистрация: Причина: Учетная запись заблокирована
540 Успешная сетевая регистрация
541 Установлена ассоциация безопасности IPSec
542 Завершена ассоциация безопасности IPSec
Режим: Защита данных (Quick mode)
543 Завершена ассоциация безопасности IPSec
Режим: Обмен ключами (Main mode)
544 Установка ассоциации безопасности IPSec завершилась неудачно, так как узел не смог пройти аутентификацию■
545 Аутентификация узла IPSec завершена неудачно
546 Установка ассоциации безопасности IPSec завершилась неудачно, так как узел отправил некорректное предложение
547 Переговоры об ассоциации безопасности IPSec завершились неудачно
672 Выдан билет на аутентификацию
673 Выдан билет службы
674 Билет возобновлен
675 Предварительная аутентификация завершилась неудачно
676 Запрос билега на аутентификацию завершился неудачно ■
677 Запрос билета службы завершился неудачно
678 Учетная запись отображена для регистрации
679 Учетная запись не может быть отображена для регистрации
680 Учетная запись использована для регистрации
681 Регистрация от имени учетной записи: <имя_клиента> из: <источник> с рабочей станции: <рабочая_станция> завершилась неудачно. Код ошибки: <код>
682 Сеанс.связи с рабочей станцией восстановлен
683 Сеанс связи с рабочей станцией прерван
Если ошибка 681 исходит от пакета аутентификации NTLM (MSV1_0), потенциальными причинами могут быть такие ошибки:
С0000064 Регистрация пользователя с неверно указанным именем
С000006А Регистрация пользователя с неверно указанным паролем
C000006F Регистрация пользователя в нерабочее время
С0000070 Регистрация пользователя с неавторизованной рабочей станции
С0000071 Регистрация пользователя с истекшим сроком действия пароля
С0000072 Регистрация пользователя с помощью отключенной администратором учетной записи
С0000193 Регистрация пользователя с помощью учетной записи с истекшим сроком действия
С0000224 Регистрация пользователя с установленным флагом
|
Ч>"Изменить пароль при следующей регистрации"
С0000234 Регистрация пользователя с помощью заблокированной
Ч>учетной записи
Если после включения аудита и запуска утилиты gpupdate в журнале безопасности отсутствуют записи, нажмите клавишу <F5> или выберите из меню консоли команду Refresh (Обновить). Если записи по-прежнему не появились, значит, ниже по дереву Active Directory может существовать политика, которая устанавливает параметр No Auditing (Отключить аудит). Дополнительная информация о диагностике заданных групповых политик приводится в главе 12, Управление групповыми политиками”.
Рекомендации по аудиту
Перед включением аудита стоит определить спектр интересующей информации. Это позволяет сократить объем журналов и избежать лишней нагрузки на серверы, которым приходится поддерживать журнал безопасности. Ниже приведено несколько примеров событий, за которыми стоит регулярно следить.
Неавторизованный доступ к каталогу
Администратор обязан отслеживать попытки пользователя или группы пользователей получить неавторизованный доступ к определенному каталогу. Выполните последовательность действий, описанную в процедуре 11.11.
Процедура 11.11. Отслеживание неавторизованного доступа к каталогу
На консоли Active Directory — Users and Computers (Active Directory — пользователи и компьютеры) создайте rpyntiy, которая называется AccessCheck (тип группы должен соответствовать интересующему составу списка управления доступом), и добавьте в эту группу подозреваемых пользователей.
Создайте новую политику Unauthorized Folder Access Detection (Обнаружение неавторизованного доступа к каталогу) для организационной единицы, в которую входит сервер.
В новой политике активизируйте функцию Audit Object Access for Failure (Контролировать неудачный доступ к объекту).
Добавьте группу AccessCheck в список контроля доступа политики и предоставьте ей разрешения Apply Group Policy (Применение групповой политики). Удалите все остальные группы, кроме группы Administrators. Предоставьте группе Administrators права на чтение, запись, создание и удаление, но не предоставляйте права применения групповой политики.
Сохраните политику.
На сервере с общим ресурсом откройте окно свойств каталога.
Откройте вкладку Security (Безопасность). Щелкните на кнопке Advanced (Дополнительно) и перейдите на вкладку Auditing (Аудит).
Добавьте группу AccessCheck в список контроля доступа для этого объекта.
Щелкните на кнопке ОК для сохранения изменений.
Запустите утилиту gpupdate для применения групповой политики на сервере с общим ресурсом.
Периодически проверяйте журнал для контроля за попытками подозреваемых пользователей получить неавторизованный доступ к каталогу.
Неавторизованный доступ к объекту службы каталогов
Администратор должен отслеживать попытки пользователей просматривать и изменять содержимое базы данных Active Directory. Пользователь не имеет прав на эти операции, но администратору желательно прекратить даже эти попытки. Для этого выполните последовательность действий, описанную в процедуре 11.12.
Процедура 11.12. Контроль за доступом к объектам службы каталогов
Откройте окно Group Policy (Групповая политика) для организационной единицы Domain Controllers (Контроллеры домена).
Создайте новую групповую политику, которая называется Unauthori zed. DS Access Detection (Обнаружение неавторизованного доступа к службе каталогов).;
В созданной политике включите политику Audit Directory Service Access (Аудит доступа к службе каталогов) для аудита успешных и неудачных попыток доступа.
В окне свойств политики добавьте учетную запись пользователя и предоставьте ей разрешение Apply Group Policy (Применять групповую политику).■;
Удалите остальные записи из списка контроля доступа, кроме группы Administrators. J Запретите группе Administratorsприменятьгрупповуюполитику, сняв соответст- ’
вующий флажок.',
Примените политику с помощью утилиты gpupdate или подождите пять минут до стан- -;
дартного обновления.1
Мониторинг регистрации изавершения сеанса]
Администратору следует контролировать все события по регистрации и завершению сеан- j сов пользователей домена, а также все регистрации и завершения сеансов пользователей на ] конкретном сервере. Выполните последовательность действий, описанную в процедуре 11.13. |
Процедура 11.13. Аудит регистрации и завершения сеанса|
В политике Default Domain включите политики Account Logon и Logon Events для I регистрации успешных и неудачных событий входа в систему.|
В организационной единице, в которую входит интересующий сервер, создайте новую по- | литику Logon Monitoring (Мониторинг регистрации).|
В новой групповой политике включите политику Account Logon для сохранения ин- 1 формации об успешной и неудачной регистрациях пользователей.|
В свойствах безопасности новой групповой политики добавьте имя контролируемого сер- | вера и установите разрешение Apply Group Policy (Применять групповую политику). | Сбросьте флажок Apply Group Policy (Применять групповую политику) для всех осталь- 1 ных записей." 1
Запустите утилиту gpupdate на сервере или подождите от 90 до 120 минут до момента J применения политики.'|
Мониторинг принтераI
В большинстве случаев всю интересующую информацию о печати можно получить из ■ журнала безопасности, в который записывается каждое событие печати. Иногда возникает 1 необходимость мониторинга управления очередями печати. Например, в сети может сущест- I вовать пользователь, блокирующий очереди или удаляющий и перемещающий задания для 1 изменения очередности распечатки своих заданий.1
Использование этой утилиты аудита может стать сюрпризом для администратора. Когда открыто окно принтера, то его обновление (т.е. связь с сетевым принтером) осуществляется каждые пять минут. При активном использовании сервера печати генерируется огромный объем событий доступа к объектам. Этот аудит необходимо использовать очень избирательно. Последовательность действий описана в процедуре 11.14.
Процедура 11.14. Аудит доступа к принтерам
В подразделении объекта сервера печати создайте групповую политику Printer Monitoring (Мониторинг принтера).
В новой политике включите мониторинг успешного и неудачного доступов к объектам (Object Access).
Откройте окно свойств принтера; перейдите на вкладку Security (Безопасность) и щелкните на кнопке Advanced (Дополнительно). После этого откройте вкладку Audit (Аудит).
Добавьте группу Everyone в список контроля доступа.
Сохраните внесенные изменения и примените политику с помощью утилиты gpupdate.
Следите за журналом безопасности некоторое время, чтобы убедиться, что никто не оставил другие объекты с включенным аудитом. Это приведет к заполнению журнала безопасности лишней информацией.
Мониторинг резервного копирования и восстановления
Резервное копирование и восстановление файлов должно быть привилегированной операцией. Пользователь, обладающий правами на резервное копирование и восстановление файлов, может скрыться со всей ценной информацией. В операционных системах Windows 2000 и Windows Server 2003 эта операция является еще более привилегированной, так как утилита ntbackup поддерживает резервное копирование в файл или на сменный носитель.
Если есть причины подозревать, что пользователь пытается воспользоваться привилегиями на резервное копирование и восстановление в обход авторизации, можно включить политику Audit use of backup and restore privilege (Аудит использования привилегии на резервное копирование и восстановление). Эту политику необходимо включить для организационной единицы, в которой содержатся компьютеры, подвергающиеся такой неавторизованной деятельности. Политика расположена в разделе Computer ConfigurationMWindows Settings^ Security SettingsMLocal PoliciesMSecurity Options (Конфигурация компьютерам Конфигурация WindowsM Параметры безопасностиМЛокальные политикиМ Параметры безопасности).
Дополнительный мониторинг системы
Рассмотрим дополнительные рекомендации по политикам аудита. Не забудьте увеличить размер журнала безопасности, чтобы обеспечить выполнение следующих рекомендаций.
Всегда контролируйте успешные и неудачные события регистрации и завершения сеансов для домена и для всех серверов.
Всегда контролируйте неудачные попытки доступа к службе каталогов.
Всегда контролируйте неудачные события управления учетными записями.
Всегда контролируйте неудачные попытки использования привилегий.
В следующей главе
Тема безопасности слишком важна, чтобы рассмотреть ее в одной главе. Мы рассказали о том, как инфраструктура безопасности работает в операционной системе Windows Server 2003 и как операционная система реализует аутентификацию, авторизацию и аудит. В следующих главах будут описаны конкретные способы защиты Active Directory, шифрованная файловая система и инфраструктура открытого ключа. '
Аудит объектов ядра
Существует возможность контроля за доступом к объектам ядра, которые управляют доступом к потокам в подсистеме Windows Executive. Автор этой книги никогда не сталкивался с необходимостью такого аудита в работающей системе. Разработчики могут использовать такой аудит для тестирования собственного кода. .
Аудит ядра включается с помощью политики Audit the access of global system objects (Аудит доступа к глобальным системным объектам). Этот параметр устанавливается в локальной системной политике. Политика хранится в разделе Computer Configuration-*Windows Settings* Security Settings^Local Policies^Security Options (Конфигурация компьютера* Конфигурация Windows*napaMerpbi безопасности-*Локальные политики*Параметры безопасности).
Н
ам постоянно приходится сталкиваться с корпоративными политиками. Например, если припарковать автомобиль слишком близко к зданию, кто-то обязательно сделает замечание: “Эти места зарезервированы для сотрудников фирмы. Работающие по контракту должны парковаться вон там”. Или, если сделать предложение, которое слишком далеко выходит за пределы требований клиента, менеджер может показать на длинный список правил своей организации и объяснить, что “здесь так не принято”.
Я — дитя шестидесятых, поэтому мне очень тяжело быть связанным правилами и политиками, но я осознаю их необходимость. Любая организация, в которой работает больше двух человек, нуждается в политиках для определения ролей и описания поведения. Это в полной мере касается и компьютеров. Пользователи рассчитывают на возможности своих компьютеров, и персонал отдела информационных технологий не сможет удовлетворить их ожидания, если не постарается добиться определенного уровня равных возможностей на рабочих станциях и серверах.
Компания Microsoft осознала эту потребность и предложила реализовать управление рабочими станциями на основе политик. В операционной системе Windows 95 эта возможность называлась системными политиками (system policies). Эти политики представляли собой заранее заготовленные обновления системного реестра. Загрузка файла с обновлением выполнялась при регистрации клиента. После этого обновление вносилось в локальную копию системного реестра.
Классические системные политики были шагом в правильном направлении, но они обладали рядом серьезных ограничений.
Системные политики навсегда изменяют системный реестр на клиентском компьютере.
Компания Microsoft называла этот процесс tattooing (дословно — “татуировка”). Каждый, кто когда-либо ошибался в параметрах системной политики и рассылал файлы политики клиентам, знает, как сложно восстановить предыдущее состояние, поскольку изменения записываются непосредственно в системный реестр.
Системные политики позволяют управлять только ограниченным количеством процессов. В стандартный набор системных политик входит очень небольшое количество записей системного реестра, и системные политики не могут использоваться для управления процессами, которые не используют записей системного реестра.
■ Системные политики могут распространяться только из одного файла. В операционной системе WindowsNT это файл Ntconfig.pol. В операционной системе Windows 9х это файл Config.pol. Требование по упаковке всех изменений в один файл делает системные политики очень негибкими и сложными в управлении. Существует возможность указать конкретную группу в файле с расширением .pol, но в таком случае получается большой файл, который сложно редактировать и долго загружать.
Начиная с операционной системы Windows 2000, компания Microsoft значительно изменила механизм управления на основе политик. Компания отказалась от статических системных политик на основе системного реестра и ввела новую возможность, которая называется групповые политики (group policies). В составе операционной системы Windows Server 2003 предоставляются все групповые политики, которые были доступны в операционной системе Windows 2000, а также дополнительные политики, которые позволяют использовать новые возможности операционных систем Windows Server 2003 и Windows ХР.
В этой главе рассматриваются вопросы создания и распространения групповых политик, а также управление ими. Основное внимание уделяется вопросам реализации. Как работают групповые политики? Каковы требования к использованию групповых политик? Почему может нарушиться работа групповых политик в корпоративных сетях и как лучше восстановить их работу? Подробное описание групповых политик, включая большое количество примеров и рекомендаций по реализации отдельных политик приводится в книге Windows 2000: Group Policy, Profiles, and IntelliMirror Джереми Московица (Jeremy Moskowitz).
Новые возможности операционной системы Windows Server 2003
В составе операционной системы Windows Server 2003 компания Microsoft предоставила большое количество новых групповых политик, а также добавила новые возможности политик, которые помогают при устранении неисправностей и улучшают гибкость групповых политик. Рассмотрим эти усовершенствования.
■ Свыше 160 новых групповых политик, которые позволяют управлять динамической регистрацией записей DNS, перемещаемыми профилями, серверами терминалов и работой Control Panel (Панель управления).
■ Полностью интегрированная программа вычисления результирующего набора политик. Такая программа упрощает планирование и устранение неполадок в работе групповых политик в организациях с несколькими уровнями контейнеров и большим количеством политик, связанных с этими контейнерами. Расчет результирующего набора политик может осуществляться из командной строки или с помощью мастера.
■ Полный журнал расчетов результирующего набора политик на каждом компьютере при регистрации пользователя. Этот журнал хранится в той же базе данных, в которой хранятся параметры работы аппаратных средств и параметры операционной системы, доступные с помощью инструментария управления WMI (Windows Management Instrumentation).
■ Возможность фильтрации основанных на системном реестре политик, благодаря которой можно просмотреть только те политики, которые относятся к определенной версии Windows. Это позволяет упорядочить содержимое консоли управления и подобрать политики для соответствующих платформ. 1
■ Новая утилита обновления групповых политик, которая называется gpupdate и заменяет собой непонятные переключатели утилиты secedit, использовавшейся в операционной системе Windows 2000. Теперь утилита secedit используется исключительно для применения содержимого базы данных системы безопасности и создания отчетов.
Консоль Group Policy Management (Управление групповыми политиками), созданная в виде отдельной утилиты, предоставляет единый инструмент администрирования групповыми политиками.
Обзор функций групповых политик
Компьютерные политики имеют много общего с корпоративными политиками. Любой сотрудник отдела кадров может объяснить, что корпоративная политика может быть эффективной только в том случае, если она соответствует нескольким критериям.
Политика должна быть изложена в ясной и простой форме.
Пользователь должен иметь возможность выполнить действия, определенные политикой.
Необходимо часто напоминать о политике, чтобы не допускать ее нарушения.
В следующих нескольких разделах рассматривается соответствие групповых политик Windows Server 2003 перечисленным критериям.
Назначение групповых политик
На самом простом уровне групповые политики предоставляют возможность эффективного управления большим количеством компьютеров. Иногда не удается дать точное определение термина “управлять”. Например, в школах бизнеса учат, что людьми на самом деле нельзя “управлять". Люди могут разрешить, чтобы их направляли, подгоняли, заманивали или тащили по направлению к определенной цели, но они никогда не остаются без собственного мнения.
Компьютеры более податливы, чем люди, но принцип остается таким же. Компьютерами нельзя управлять насильно; они позволяют, чтобы ими управляли. Как будет показано далее, каждый клиент под управлением операционных систем Windows Server 2003, Windows 2000 и Windows ХР имеет набор служб, которые знают, как обрабатывать инструкции, распространяемые в групповых политиках. От администратора зависит предоставление нужных инструкций нужным клиентам в нужные моменты времени.
В нескольких разделах будет рассказано, как создаются групповые политики, откуда клиенты знают, где получать групповые политики, как загружаются групповые политики и что происходит при обработке групповых политик. Вы узнаете, как реализовать каждый тип политики и устранить неполадки в работе групповых политик.
Компоненты групповых политик
Развертывание групповых политик в пределах предприятия быстро превращается в лабиринт узких проходов. Автору этой книги кажется, что компания Microsoft слишком усложнила эту операцию, связав с компонентами групповых политик перегруженную терминологию. Сначала вкратце будет описан каждый компонент, после чего компоненты будут рассмотрены более подробно.
Объект групповой политики (Group Policy Object — GPO). He пытайтесь искать в базе данных Active Directory такой объект. Компания Microsoft использует термин объект групповой политики в качестве синонима для идентификации двух компонентов групповой политики: контейнера групповой политики (Group Policy Container) и шаблона групповой политики (Group Policy Template). Такие контейнеры Active Directory, как сайты, домены и организационные единицы, могут быть связаны (linked) с объектом групповой политики. При этом параметры объекта групповой политики применяются к объектам пользователей и компьютеров в соответствующем контейнере.
■ Шаблон групповой политики (Group Policy Template — GPT). Шаблон групповой политики представляет собой набор инструкций, которые реализуют набор политик. Например, политики обновления системного реестра хранятся в файле шаблона групповой политики, который называется Registry.pol. Файлы шаблонов групповых политик хранятся в папках политик в каталоге Sysvol на каждом контроллере домена. Пример показан на рис. 12.1.
■ Контейнер групповой политики (Group Policy Container — GPC). Контейнер групповой политики представляет собой объект Active Directory, в котором перечислены имена шаблонов групповой политики, связанных с определенным объектом групповой политики. Клиенты Windows используют информацию из контейнера групповой политики для определения загружаемых и обрабатываемых шаблонов групповой политики. (В документации от компании Microsoft термины объект групповой политики и контейнер групповой политики иногда заменяют друг друга.)
■ Расширение на стороне клиента (Client-Side Extension — CSE). Групповые политики позволя(от управлять различными функциями клиентов Windows. Для этих функций существуют службы, которые знают, как получать и обрабатывать предназначенные для них групповые политики. Такие службы называются расширениями на стороне клиента и предоставляются в виде динамически загружаемых библиотек DLL. Например, политики перенаправления папок обрабатываются расширением Fdeploy. dll.1
WINDOWS'.SYSV1H sysvol conipany.com\Poltuc* .{.f>ACi/061" Olbf-LIDS-945f-WINDOWS'.SYSV1H sysvol conipany.com\Poltuc* .{.f>ACi/061" Olbf-LIDS-945f-»102£f»102£foa«*~jD2»jri7^oa«*~jD2»jri7^± О sy$tern32 e sysvol№ ^ domain £3 stagingS £2 staging areas15 sysvolS ^ company,com± О sy$tern32 e sysvol№ ^ domain £3 stagingS £2 staging areas15 sysvolS ^ company,comО DO_NOT_REMOVE_NtFrs_PreInsteiJ*ectoryto О PottiesS Q (6AC1796C-016F-llD2-945F-00C04fB984F9}S £3 MACHINES ^ McrosoftSp Windows NTSi НИН ,USER® ^l31B2F340-016C4lD2-945F4DC04FB984F9} scriptsО TAPIО DO_NOT_REMOVE_NtFrs_PreInsteiJ*ectoryto О PottiesS Q (6AC1796C-016F-llD2-945F-00C04fB984F9}S £3 MACHINES ^ McrosoftSp Windows NTSi НИН ,USER® ^l31B2F340-016C4lD2-945F4DC04FB984F9} scriptsО TAPI?T5SS«<5t*frewwr.lw<8> •:?T5SS«<5t*frewwr.lw<8> •:H «0 fH «0 fВлв® . 2 m, сачил»Влв® . 2 m, сачил»
WINDOWS'.SYSV1H sysvol conipany.com\Poltuc* .{.f>ACi/061" Olbf-LIDS-945f-
WINDOWS'.SYSV1H sysvol conipany.com\Poltuc* .{.f>ACi/061" Olbf-LIDS-945f-
»102£f
»102£f
oa«*~jD2»jri7^
oa«*~jD2»jri7^
± О sy$tern32 e sysvol
№ ^ domain £3 staging
S £2 staging areas
15 sysvol
S ^ company,com
± О sy$tern32 e sysvol
№ ^ domain £3 staging
S £2 staging areas
15 sysvol
S ^ company,com
О DO_NOT_REMOVE_NtFrs_PreInsteiJ*ectory
to О Potties
S Q (6AC1796C-016F-llD2-945F-00C04fB984F9}
S £3 MACHINE
S ^ McrosoftSp Windows NT
Si НИН ,
USER
® ^l31B2F340-016C4lD2-945F4DC04FB984F9} scripts
О TAPI
О DO_NOT_REMOVE_NtFrs_PreInsteiJ*ectory
to О Potties
S Q (6AC1796C-016F-llD2-945F-00C04fB984F9}
S £3 MACHINE
S ^ McrosoftSp Windows NT
Si НИН ,
USER
® ^l31B2F340-016C4lD2-945F4DC04FB984F9} scripts
О TAPI
?T5SS«<5t*frewwr.lw<8> •:
?T5SS«<5t*frewwr.lw<8> •:
H «0 f
H «0 f
Влв® . 2 m, сачил»
Влв® . 2 m, сачил»
Puc. 12.1. Стандартный каталог Sysvol, в котором присутствуют каталоги групповых политик и файл шаблона групповой политики
Редактор групповой политики (Group Policy Editor — GPE). Редактор представляет собой оснастку ММ С, которая позволяет создавать объекты групповых политик и управлять ими. На рис. 12.2 показано редактирование групповой политики Default Domain (одного из двух объектов групповой политики, установленного в каждом домене).
Политики компьютеров и политики пользователей. Параметры политик в объекте групповой политики могут относиться к объектам компьютеров или к объектам пользователей. Компьютеры загружают свои политики в процессе загрузки операционной системы.
Пользователи загружают свои политики при регистрации в домене. Двойственный характер объектов групповых политик является основным источником проблем при развертывании групповых политик.
Групповые политики и локальные политики. Не все политики загружаются из домена. Каждый клиент имеет свой набор локальных политик, которые вступают в силу, если компьютер не является членом домена или регистрация пользователя выполняется с помощью локальной базы данных SAM, без регистрации в домене.
Теперь рассмотрим особенности совместного функционирования этих компонентов при создании, развертывании групповых политик и управлении ими.
Объекты групповых политик
Custom user interfaceCustom user interfaceDisplay PropertiesDisplay PropertiesThe Explorer program (% $ystemdrtve%[proyam ffestynternet explorer\Explorer.exe) creates the famfar Windows intarface, but you can use this setting to sperfy an atemate interface. If you enable this setting, the system start the interface you spedfy instead of Explorer.exe.The Explorer program (% $ystemdrtve%[proyam ffestynternet explorer\Explorer.exe) creates the famfar Windows intarface, but you can use this setting to sperfy an atemate interface. If you enable this setting, the system start the interface you spedfy instead of Explorer.exe.Requirements:At least Microsoft Windows 2000Requirements:At least Microsoft Windows 2000Don't cisplay the Getting Started welcome screen at logc- Century Interpretation for Year 2000 Configure driver search locations Code signing for device diversDon't cisplay the Getting Started welcome screen at logc- Century Interpretation for Year 2000 Configure driver search locations Code signing for device diversDescription:Specifies an afcemate user interface for Windows 2000.Description:Specifies an afcemate user interface for Windows 2000.X C^User Profiles , LjScnpts ^ £3CtrH-Alt+0el Options CjLogon• CiGrom Poky О Power ManagementX C^User Profiles , LjScnpts ^ £3CtrH-Alt+0el Options CjLogon• CiGrom Poky О Power Management.■n dompol [Console Pout Default Domain Policy [serverl.compatiy.com] Potky\User CoafigurationXArtlmifi^ ten.■n dompol [Console Pout Default Domain Policy [serverl.compatiy.com] Potky\User CoafigurationXArtlmifi^ ten4» "4 ' SnifiH11? Q' S4» "4 ' SnifiH11? Q' SТермин объект групповой политики (GPO) является общим и означает сразу две составляющие групповой политики: контейнер групповой политики (GPC) и шаблон групповой политики (GPT). Очень удобно воспринимать объект групповой политики как единый элемент, поскольку составляющие групповой политики всегда должны быть синхронизированы.
Custom user interface
Custom user interface
Display Properties
Display Properties
The Explorer program (% $ystemdrtve%[proyam ffestynternet explorer\Explorer.exe) creates the famfar Windows intarface, but you can use this setting to sperfy an atemate interface. If you enable this setting, the system start the interface you spedfy instead of Explorer.exe.
The Explorer program (% $ystemdrtve%[proyam ffestynternet explorer\Explorer.exe) creates the famfar Windows intarface, but you can use this setting to sperfy an atemate interface. If you enable this setting, the system start the interface you spedfy instead of Explorer.exe.
Requirements:
At least Microsoft Windows 2000
Requirements:
At least Microsoft Windows 2000
Don't cisplay the Getting Started welcome screen at logc- Century Interpretation for Year 2000 Configure driver search locations Code signing for device divers
Don't cisplay the Getting Started welcome screen at logc- Century Interpretation for Year 2000 Configure driver search locations Code signing for device divers
Description:
Specifies an afcemate user interface for Windows 2000.
Description:
Specifies an afcemate user interface for Windows 2000.
X C^User Profiles , LjScnpts ^ £3CtrH-Alt+0el Options CjLogon
• CiGrom Poky О Power Management
X C^User Profiles , LjScnpts ^ £3CtrH-Alt+0el Options CjLogon
• CiGrom Poky О Power Management
.■n dompol [Console Pout Default Domain Policy [serverl.compatiy.com] Potky\User CoafigurationXArtlmifi^ ten
.■n dompol [Console Pout Default Domain Policy [serverl.compatiy.com] Potky\User CoafigurationXArtlmifi^ ten
4» "4 ' SnifiH11? Q' S
4» "4 ' SnifiH11? Q' S
; _J Console Root
(3 ^ Def auk Domain Poky [server! .company
S g Computer Configuration
$ Qj Software Settings
® • !?1 Windows Settings
IS £5 Adnrtstrative Templates
Q User Configuration;
S- 25 Software Settings
S ^3 Windows Settings
[3 {^ Administrative Templates
У Pl Windows Components';
. • Г.1 Start Menu and Taskbar
@ Q} Desktopi
• j Shared Folders
Prevent access to the command prompt Prevent access to registry edting took Rui only slowed Windows appkations Doni run spedfied Windows appkationsPrevent access to the command prompt Prevent access to registry edting took Rui only slowed Windows appkations Doni run spedfied Windows appkationsTo use this setting, copy your 2j \ Extended Sir.To use this setting, copy your 2j \ Extended Sir.®- у Network ♦ xJ System
Prevent access to the command prompt Prevent access to registry edting took Rui only slowed Windows appkations Doni run spedfied Windows appkations
Prevent access to the command prompt Prevent access to registry edting took Rui only slowed Windows appkations Doni run spedfied Windows appkations
To use this setting, copy your 2j \ Extended Sir.
To use this setting, copy your 2j \ Extended Sir.
Puc. 12.2. Редактирование политики Default Domain с помощью редактора групповых политик
Просмотр и изменение объектов групповых политик
Для просмотра объектов групповых политик, связанных с определенными контейнерами Active Directory, откройте окно свойств контейнера на консоли Active Directory — Users and Computers (Active Directory — пользователи и компьютеры) или Active Directory — Sites and Services (Active Directory — сайты и службы), если речь идет о групповых политиках сайтов. Откройте вкладку Group Policy (Групповая политика). На рис. 12.3 показан пример набора групповых политик для организационной единицы.
В каждом домене Active Directory присутствуют как минимум два объекта групповых политик.
Default Domain. Этот объект групповой политики содержит параметры безопасности, которые относятся ко всем компьютерам в пределах домена. Объект групповой политики связан с объектом Domain.
Default Domain Controller. Этот объект групповой политики содержит параметры безопасности и параметры конфигурации, которые относятся ко всем контроллерам домена. Объект групповой политики связан с организационной единицей Domain Controllers.
Обычно групповые политики оказывают влияние только на объекты в связанных контейнерах (и на объекты в дочерних контейнерах при включении наследбвания). Политики объекта групповых политик Default Domain Controller работают немного по-другому. Этот объект групповой политики содержит множество критических параметров системы безопасности, которые важны для правильной работы контроллера домена. Таким образом, политики объекта групповой политики Default Domain Controller буквально отслеживают объекты контроллеров домена по всей базе данных Active Directory. Организационная единица Domain Controller выступает в роли якоря для объекта групповой политики.
Рис. 123. Окно свойств организационной единицы, в котором показан список групповых политик
Применение групповых политик с помощью утилиты gpupdate
Обычно новая групповая политика для пользователя не вступает в силу до завершения сеанса и повторной регистрации пользователя, а новая групповая политика для компьютера не вступает в силу до перезагрузки компьютера. Кроме этого, групповые политики периодически обновляются в результате работы фонового процесса.
Если новая групповая политика должна быть применена немедленно, можно воспользоваться утилитой gpupdate. Откройте приглашение командной строки и введите команду gpupdate. Утилита предоставлена вместо специальных параметров утилиты Secedit, которые использовались в операционной системе Windows 2000 для применения групповых политик. Параметр /target утилиты gpupdate позволяет указать политики для пользователей или компьютеров, например gpupdate /target: user или gpupdate /target :computer.
Если применяется пользовательская групповая политика, которая требует завершения сеанса пользователя и последующей регистрации, можно воспользоваться параметром / logoff, например gpupdate /target :user /logoff. Если политика, примененная таким образом, не оказывает влияния на расширения на стороне клиента, требующее завершения сеанса, то завершения сеанса не происходит.
Если применяется групповая политика для компьютеров, которая требует перезагрузки компьютеров для вступления в силу, можно воспользоваться параметром /boot, например gpupdate /target: computer /boot. Если такая политика не оказывает влияния на расширения на стороне клиента, требующие перезагрузки, перезагрузка не выполняется.
Обычно утилита gpupdate загружает и применяет только те групповые политики, которые изменились с момента последней загрузки групповых политик. Это позволяет сэкономить пропускную способность сети. Если необходимо загрузить и применить все политики, воспользуйтесь параметром / force, например gpupdate /force.
Номера версий объектов групповых политик
Система отслеживает изменения в групповых политиках, увеличивая атрибут номера версии при каждом изменении объекта групповой политики. Номер версии имеет интересный формат, так как система отслеживает обновления раздела Computer Configuration (Конфигурация компьютера) отдельно от изменений раздела User Configuration (Конфигурация пользователя) с тем же номером версии. Рассмотрим, как увеличивается номер версии объекта групповой политики.
При внесении изменений в параметры политик в разделе Computer Configuration (Конфигурация компьютера) номер версии объекта групповой политики увеличивается на единицу.
При внесении изменений в параметры политик в разделе User Configuration (Конфигурация пользователя) номер версии объекта групповой политики увеличивается на 65 536.
Система рассматривает два компонента номера версии объекта групповой политики как номер редакции (revision number) каждого компонента. Чтобы узнать номер версии объекта групповой политики, сначала номер версии нужно разделить на 65 536. Результат является номером редакции раздела User. Остаток является номером редакции раздела Computer. Например, номер версии объекта групповой политики 131 075 дает номер редакции User, равный 2, и номер редакции Computer, равный 3.
Номера редакций компонентов объекта групповой политики доступны в окне свойств объекта GPO (рис. 12.4).
Рис. 12.4. Окно свойств объекта GPO, в котором показаны номера редакции каждого компонента
Хранение номера версии объекта групповой политики
На самом деле отдельного объекта групповой политики не существует, поэтому номер версии должен храниться где-то в другом месте. Объект групповой политики состоит из контейнера групповой политики и шаблона групповой политики. Копия номера версии хранится в каждом компоненте следующим образом.
Объект контейнера групповой политики в базе данных Active Directory хранит номер версии в атрибуте VersionNumber. Ниже приведен фрагмент списка атрибутов контейнера групповой политики:
versionNumber 65538,
gPCFunctionalityVersion: 2;
gPCFileSysPath: \\company.com\SysVol\company.com\Policies\
(5D769292-2424-4D93-ABBC-3EDD73BC58FB);
gPCMachineExtensionNames; [{35378EAC-683F-11D2-A89A-00C04FBBCFA2} ^> {0F6B957E-509E-11D1-A7CC-0000F87571E3}] ;
gPCWQLFilter: [company.com;{F76FB374-E3B3-434E-953D-0FDDFB634FCF};0];
Номер версии контейнера групповой политики хранится в файле Gpt. ini в корневом каталоге политики в папке Sysvol:
[General]'
Version=65538
displayName=TestGPO
Исправление ошибок при синхронизации объектов GPO
Номера версий контейнеров групповых политик (GPC) и шаблонов групповых политик (GPT) всегда должны совпадать в пределах одного объекта групповой политики (GPO). Содержимое двух компонентов GPO всегда должно совпадать на конкретном контроллере домена. Любое отличие на протяжении длительного периода времени означает, что произошла ошибка репликации.
Номера версий GPT и GPC могут различаться в течение коротких периодов времени из-за использования различных методов репликации для распространения изменений.
Изменения в контейнере групповой политики распространяются с помощью механизма репликации Active Directory. Для распространения обновлений в пределах сайта требуется 15 минут. Для распространения обновления за пределами сайта требуется 3 часа.
Изменения в шаблоне групповой политики, который расположен в каталоге Sysvol, реплицируются средствами службы репликации файлов. Служба репликации файлов работает значительно быстрее, чем репликация Active Directory. В большинстве случаев изменения в каталоге Sysvol реплицируются (немедленно.
Во избежание проблем, связанных с более медленной репликацией GPC по сравнению с репликацией GPT, клиент загружает обновленный GPT, даже если номер версии не совпадает с номером версии соответствующего GPC. Это значит, что не существует явного метода определения различия в номерах версий шаблонов и контейнеров групповых политик. Придется периодически проверять номера версий.
■ Лучшей утилитой для отслеживания различий в номерах версий шаблонов и контейнеров групповых политик, а также различий в содержимом объектов групповых политик на разных контроллерах домена является gpotool, которая предоставляется в составе Resource Kit. Эта утилита должна запускаться каждый вечер с помощью Sheduler (Планировщик заданий). Результаты запуска утилиты должны быть сохранены в файле для просмотра администратором на следующее утро.
Для быстрой проверки совпадения номеров версий шаблонов и контейнеров групповых политик можно воспользоваться утилитой Replmon (монитор репликации), которая предоставля-
ется в составе Support Tools. Щелкните правой кнопкой мыши на пиктограмме сервера и выберите из контекстного меню команду Show Group Policy Object Status (Показать состояние объекта групповой политики). Пример использования этой утилиты показан на рис. 12.5.
Журнал диагностики службы репликации файлов
Если предполагается, что проблема несовпадения номеров версий шаблонов и контейнеров групповых политик на различных контроллерах домена связана с ошибками в работе службы репликации файлов, попытайтесь включить отладочный журнал службы. Для этого придется внести изменения в системный реестр. Добавьте следующую запись (значение записи 5 включает наиболее полную диагностику):
Раздел: HKLM\System\CurrentControlSet\Services NtFrs\Parameters
Запись: DebugLogSeverity (REG_DWORD)
Значение: 5
WR.*—-(1334F0A1-5F57-4147-A958-CF82CA87DECF) (31В2РЭ4О-ХЛ 60-11D2-945F-00C04FB984F9) (6AC1786C-016F-11D2-945F-00C04fB984F9) (DFF7DD80-5BFD4E81-9FF0-329273759D91){E9FF5729-608E-4ED7-B5E5-E00423E79E70}WR.*—-(1334F0A1-5F57-4147-A958-CF82CA87DECF) (31В2РЭ4О-ХЛ 60-11D2-945F-00C04FB984F9) (6AC1786C-016F-11D2-945F-00C04fB984F9) (DFF7DD80-5BFD4E81-9FF0-329273759D91){E9FF5729-608E-4ED7-B5E5-E00423E79E70}0 24248525 6554000 24248525 6554000 24248525 6554000 24248525 655400* ConbectofsDefault Domain PolicyDefault Domain Conbotetf PolicyLockdown Desktops Phoenix Admins* ConbectofsDefault Domain PolicyDefault Domain Conbotetf PolicyLockdown Desktops Phoenix Admins
WR.*—-
(1334F0A1-5F57-4147-A958-CF82CA87DECF) (31В2РЭ4О-ХЛ 60-11D2-945F-00C04FB984F9) (6AC1786C-016F-11D2-945F-00C04fB984F9) (DFF7DD80-5BFD4E81-9FF0-329273759D91)
{E9FF5729-608E-4ED7-B5E5-E00423E79E70}
WR.*—-
(1334F0A1-5F57-4147-A958-CF82CA87DECF) (31В2РЭ4О-ХЛ 60-11D2-945F-00C04FB984F9) (6AC1786C-016F-11D2-945F-00C04fB984F9) (DFF7DD80-5BFD4E81-9FF0-329273759D91)
{E9FF5729-608E-4ED7-B5E5-E00423E79E70}
0 2424852
5 65540
0
0 2424852
5 65540
0
0 2424852
5 65540
0
0 2424852
5 65540
0
* Conbectofs
Default Domain Policy
Default Domain Conbotetf Policy
Lockdown Desktops Phoenix Admins
* Conbectofs
Default Domain Policy
Default Domain Conbotetf Policy
Lockdown Desktops Phoenix Admins
Рис. 125. В окне утилиты Replmon отображается состояние синхронизации объектов GPO
Расширения на стороне клиента
Если у вас есть дети, если вы сами росли в многодетной семье или знакомы с другими людьми, которые имеют детей (я никого не пропустил?), то вы отлично себе представляете принципы работы групповых политик.
Когда пятилетнему ребенку говорится “Не пачкай туфли в грязи”, родитель ожидает, что размазывание грязи по туфлям немедленно прекратится. Не нужно объяснять, как поднять ногу и как сохранять равновесие при разном расстоянии от ног до земли, так как ребенок уже обладает этими навыками. Короткая и простая директива должна побудить к правильному поведению. (В разделах, посвященным вопросам устранения неисправностей, на протяжении всей главы приводятся рекомендации на случай, если компьютер начнет себя вести, как настоящий пятилетний ребенок.)
Операционная система Windows Server 2003 предоставляет 11 функций, которые до определенной степени управляются групповыми политиками. За двумя исключениями (служба удаленной установки и программные ограничения) каждая из функций имеет службу, которая работает на клиенте и обрабатывает групповые политики. Эти службы называются расширениями на стороне клиента (Client-Side Extension — CSE). Каждое расширение работает, как часть динамически расширяемой библиотеки. В табл. 12.1 перечислены управляемые групповыми политиками функции и связанные с ними расширения на стороне клиента.
Таблица 12.1. Типы групповых политик и расширения на стороне клиента
Тип групповой политики
Библиотека реализации
Administrative Templates (Административные шаблоны (реестр))
Userenv.dll
Folder Redirection (Перенаправление папок)
Fdeploy.dll
Scripts (Сценарии загрузки/завершения работы)
Gptext.dll
Security (Параметры безопасности)
Scecli.dll
Software Installation (Установка программного обеспечения)
Appmgmt.dll
Microsoft Disk Quota (Квоты на пространство на диске)
Dskquota.dll
efs Recovery (Восстановление зашифрованной файловой системы и инфраструктура открытого ключа PKI)
Scecli.dll
Internet Explorer Branding (Обслуживание Internet Explorer)
Iedkcs32.dll
IP Security (IPSEC)
Gptext.dll
Ris (Службы удаленной установки)
См. примечание 1
QoS Packet scheduling (Составление расписания для пакетов QoS)
Gptext.dll
Software Restrictions (Программные ограничения)
См. примечание 2
wireless Networking (Беспроводные сети)
Gptext.dll
Примечание 1. Политики служб удаленной установки (RIS) не используют расширения на стороне клиента. RIS-сервер получает содержимое политики при получении службой Binary Negotiation Layer (BINL) запроса на соединение от RIS-клиента. Политика определяет, какие файлы с расширением . osc сервер служб удаленной установки (RIS-сервер) будет использовать как часть мастера установки.
Примечание 2. Программные ограничения реализуются непосредственно операционной системой на основе записей системного реестра, добавленных политикой. Отдельное расширение на стороне клиента не используется.
Запоминать расширения на стороне клиента не обязательно, но желательно помнить, что каждое расширение использует специальные методы обработки для полученных групповых политик. Можно назвать такие методы специальной обработки.
Фоновое обновление
Синхронная обработка
Обработка по низкоскоростному каналу
Принудительные обновления
Обработка сценариев
Ниже приводится подробная информация о специальных методах обработки и способах их настройки.
Совет по использованию системного реестра: список расширений на стороне клиента
Список расширений на стороне клиента доступен в разделе HKLM\Software\Microsoft\ Windows NT\CurrentVersion\Winlogon\GPExtensions.
Для идентификации расширений на стороне клиента в списке используется идентификатор класса (Classi D— еще один термин для обозначения глобально уникального идентификатора). За одним исключением (Default) в записи для раздела расширения на стороне клиента указано легко понятное имя. Исключением является политика Administrative Templates, которая показана в списке полужирным Шрифтом и не имеет значения (Default).
(25537BA6-77A8-11D2-9B6C-0000F8080861) = Folder Redirection
{35378EAC-683F-11D2-A89A-00C04FBBCFA2} - <AdminiBtrative Templates>
(3610eda5-77ef-lld2-8dc5-00c04fa31a66) = Microsoft Disk Quota
(426031c0-0b47-4852-b0ca-ac3d37bfcb39} = QoS Packet Scheduler
(42B5FAAE-6536-lld2-AE5A-000OF87571E3} = Scripts
(827D319E-6EAC-11D2-A4EA-00C04F79F83A) = Security
{A2E30F80-D7DE-lld2-BBDE-00C04F86AE3B} = Internet Explorer Branding
(B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A) = EFS Recovery
(c6dc5466-785a-lld2-84d0-00c04fbl69f7) = Software installation
(e437bclc-aa7d-lld2-a382-00c04f991e27) = IP Security
(0ACDD40C-75AC-47ab-BAA0-BF6DE7E7FE63} = Wireless
Этот список можно использовать при включении отладки для отслеживания проблем в работе групповых политик. В некоторых журналах отладки расширения указываются с помощью идентификатора класса, а не дружественного имени.
При просмотре списка расширений в редакторе системного реестра можно обратить внимание, что четыре расширения на стороне клиента управляются одной библиотекой Gptext. dll, которая содержит функции для составления расписания для пакетов QoS, IPSec, беспроводной сети и сценариев. Это не оказывает влияния на работу системы, но может ввести в заблуждение при просмотре журналов отладки.
Фоновое обновление
Компьютерные политики применяются при загрузке компьютера. Пользовательские политики применяются при регистрации пользователя. Это кажется достаточно простым, но это не все. В течение дня политики могут меняться, а принудительное завершение пользовательских сеансов и перезагрузка компьютеров не всегда допустимы. По этой причине расширения на стороне клиента время от времени запрашивают обновления групповых политик.
По умолчанию контроллеры домена обновляют групповые политики каждые 5 минут, а обычные серверы и рабочие станции обновляют групповые политики от 90 до 120 минут. (Период выбирается случайным образом, чтобы предотвратить одновременное обращение клиентов к регистрационному серверу.) Два типа политик не поддерживают фоновое обновление, так как это приведет к нестабильности в работе.
Folder Redirection (Перенаправлениепапок)
Software Distribution (Распространение программного обеспечения)
Политики сценариев обрабатываются в процессе фонового обновления, но не вступают в силу, пока пользователь не завершит сеанс и не зарегистрируется в системе повторно (или, в случае компьютера, др перезагрузки).
Политики программных ограничений обновляются в фоновом режиме и вступают в силу немедленно. Но способ реализации программных ограничений может привести к странному “поведению” системы.
При запуске клиентского процесса программные ограничения читаются из системного реестра. Ограничения кэшируются для ускорения последующей обработки. Это значит, что работающий процесс не обнаружит новых ограничений до перезапуска процесса. Так как
большинство приложений запускается из Explorer, такая инициализация требует завершения сеанса. (Explorer можно остановить и перезапустить из Task Manager (Диспетчер задач), но обычные пользователи нечасто выполняют такие операции.)
Существует исключение из требования завершения сеанса при использовании политик программных ограничений. Консоль интерпретатора командной строки (CMD) работает независимо от Explorer, поэтому при получении новых программных ограничений они становятся доступными в командной строке, но никак не влияют на оболочку Explorer. Это может ввести пользователей в заблуждение, поэтому подготовьте службу поддержки к получению нескольких звонков от опытных пользователей после введения политик программных ограничений.
Синхронная обработка ,
Загрузка и обработка политик расширениями на стороне клиента требует некоторого времени. Для пользователей это выглядит, как задержка при утренней регистрации, а одной из главных целей проектирования Windows ХР (и Windows Server 2003) считалась минимизация таких задержек при регистрации. Чтобы понять принципы минимизации задержек в результате обработки групповых политик, рассмотрим два варианта обработки.
Синхронный. При такой обработке все расширения на стороне клиента должны завершить свою работу до передачи управления вызвавшему процессу. В случае компьютерных политик вызывающим процессом является Winlogon. В случае пользовательских политик вызывающим процессом является Userenv. Термин “синхронный” в данном случае не совсем корректен, поскольку под “синхронным” обычно подразумевается “одновременный” процесс. Здесь “синхронный” означает, что процессы выполняются последовательно.
Асинхронный. Управление передается вызывающему процессу сразу после начала обработки расширением на стороне клиента.
Изменение интервала фонового обновления
■ Интервал фонового обновления можно изменить с помощью двух групповых политик, расположенных в разделе Computer Configuration^Administrative Templates^System^Group Policy (Конфигурация компьютера1*Административные шаблоны^Система^Групповая политика).
Group Policy Refresh Interval for Computers (Интервал обновления групповых политик для компьютеров)
Group Policy Refresh interval for Domain Controllers (Интервал обновления групповых политик для контроллеров домена)
Кроме стандартного интервала обновления от 90 до 120 минут, клиенты обновляют политики безопасности каждые 16 часов. В процессе обновления клиент загружает все политики безопасности, не обращая внимания на отсутствие изменений.
В отличие от интервалов фонового обновления, составляющих 5 и 90 минут, которые управляются значениями в разделе Policies в системном реестре, интервал обновления 16 часов (960 минут) жестко закодирован в системном реестре в разделе Winlogon\Parameters. Интервал контролируется следующей записью:
Раздел:HKLMXSoftware\MicrosoftXWindows NT\CurrentVersion\Winlogon\ GPExtensions\(82 . . . }
Запись: MaxNoGPOLi st Changes Interval
Значение: 3c0 (960)
При использовании синхронной обработки пользователю не предоставляется регистрационное окно до завершения обработки компьютерных политик и не предоставляется доступ к рабочему столу до завершения обработки пользовательских политик. В операционной сис-
теме Windows 2000 такой метод обработки принят по умолчанию, кроме обработки пользовательских регистрационных сценариев, которые обрабатываются асинхронно.
При использовании асинхронной обработки регистрационное окно предоставляется пользователю, когда компьютерные политики продолжают обрабатываться, а рабочий стол предоставляется, пока обрабатываются пользовательские политики. Это позволяет ускорить доступ к рабочему столу. По умолчанию в операционных системах Windows ХР и Windows Server 2003 используется асинхронная обработка.
Асинхронная обработка может привести к нестабильной работе системы, если параметры компьютера или компоненты пользовательской среды зависят от параметров групповых политик. По этой причине два типа политик требуют специальной обработки: перенаправления папок и развертывания программного обеспечения. Если сценарии должны выполняться последовательно или завершаться до того, как пользователь получит доступ к рабочему столу, включите групповую политику, которая называется Run Logon Script Synchronously (Запускать регистрационные сценарии синхронно).
Тщательно проверьте сценарии перед включением этой политики. Если сценарий “зависнет”, пользователь не сможет получить доступ к рабочей станции. Максимальное время на обработку каждого сценария составляет 10 минут. Все групповые политики должны быть обработаны в течение 60 минут. Это слишком долго, чтобы ждать завершения “зависшего” сценария.
Ограничение в 60 минут не может быть изменено с помощью групповой политики или записи в системном реестре. Время обработки отдельного сценария можно изменить с помощью групповой политики Maximum Wait Time For Group Policy Scripts (Максимальное время ожидания для сценария групповой политики). Политика хранится в разделе Computer Configurationc>Administrative Templates^Systemc>Scripts (Конфигурация компьютерам Административные шаблоныМ Системам Сценарии).
Обработка по низкоскоростному каналу
Уже почти можно сделать вывод, что ничего сложного в развертывании групповых политик нет, но мы забыли рассмотреть клиенты, которые подключаются с использованием удаленного доступа по низкоскоростным коммутируемым каналам или линиям ISDN/DSL.
Обработка групповых политик и инициализация сети
Еще одной уловкой компании Microsoft для ускорения регистрации является предоставление пользователю рабочего стола до окончания инициализации сетевой подсистемы. Это позволяет значительно ускорить процесс регистрации, но "побочные эффекты" такого решения отражаются на групповых политиках.
Отложенная проверка сетевой инициализации заставляет выполнять две регистрации для реализации политики развертывания программного обеспечения. При первой регистрации политика устанавливается, а при второй регистрации загружается программный пакет.
Еще одним примером является использование расширенных возможностей в политике перенаправления папок для выбора определенной группы. В этом случае необходимы три регистрации: при первой устанавливается политика, при второй обнаруживается группа, а при третьей реализуется перенаправление папок.
Метод проверки сети можно вернуть в режим, использовавшийся в операционной системе Windows 2000. Для этого можно воспользоваться политикой Always Wait For The Network At Computer startup And Logon (Всегда ожидать завершения инициализации сети при загрузке компьютера и регистрации). Эта политика хранится в разделе Computer Configuration^ Administrative TemplatesMSystemMLogon (Конфигурация компьютераМАдминистративные шабло- нымСйстемам Регистрация).
Каждое расширение на стороне клиента использует свой способ обработки политик при низкоскоростном подключении. Следующие типы политик всегда обрабатываются независимо от скорости подключения.
Политики безопасности (включая политики шифрованной файловой системы и IPSec)
Административные шаблоны (системный реестр)
Программные ограничения
Следующие типы политик не обрабатываются при использовании низкоскоростного подключения, если их обработку не настроить специально.
Параметры квот
Перенаправление папок
Регистрационные сценарии (загрузка/завершение работы)
Обслуживание Internet Explorer
Создание расписания для пакетов QoS
У становка программного обеспечения
Для переопределения использования расширения через низкоскоростной канал можно воспользоваться параметром Allow Processing Across A Slow Network Connection (Разрешить обработку через низкоскоростное соединение) соответствующей политики в разделе Computer ConfiguratiorrM Administrative Templates^System^Group Policy (Конфигурация компьютерам Административные шаблоныМ Системам Групповая политика).
Принудительные обновления
По умолчанию клиент сохраняет пропускную способность сети и сокращает длительность регистрации, загружая только те групповые политики, которые изменились с момента последней загрузки.
Для проверки актуальности объекта групповой политики клиент проверяет номер версии, назначенный компонентам объекта групповой политики:
номер версии в файле Gpt. ini в корневом каталоге политики в папке Sysvol;
номер версии объекта GPC в базе данных Active Directory.
Изменение предельной скорости низкоскоростного соединения
Операционная система Windows Server 2003 определяет низкоскоростное подключение как подключение со скоростью передачи данных менее 500 Кбит/с. Система определяет скорость соединения с помощью отправки последовательности ICMP-запросов с заданной полезной нагрузкой и измерения времени до получения ответа.
Если некоторые пользователи подключаются к локальной сети офиса через виртуальную частную сеть по высокоскоростному соединению DSL или через кабельный модем, скорость соединения может превышать 500 Кбит/с и пользователи будут загружать групповые политики. По ряду причин эту возможность желательно отключить. Соединение со скоростью передачи данных 500 Кбит/с отлично подходит для работы в Интернет, но оказывается слишком медленным для загрузки программного обеспечения. Кроме этого, не стоит применять групповые политики на домашних компьютерах пользователей, на которых пользователи не имеют доступа к корпоративной службе поддержки.
Предельную скорость, согласно которой определяется низкоскоростной канал, можно изменить с помощью групповой политики Group Policy Slow Link Detection (Определение низкоскоростного соединения для групповых политик). Политика хранится в разделе Computer ConfiguratoinMAdministrative Templates^System^Group Policy (Конфигурация компьютерам Административные шаблоны'МСистема'МГрупповая политика).
Каждый раз, когда клиент загружает содержимое объекта групповой политики, клиент сохраняет номер версии из контейнера групповой политики. Номер версии хранится в системном реестре в разделе HKLM\Software\Microsoft\Windows\CurrentVersion\GroupPolicy\ History.
В следующий раз при сканировании объектов групповых политик клиент сравнивает номер версии в файле Gpt. ini и в контейнере групповой политики. Если номер любой из версий больше, чем номер версии, сохраненный в системном реестре, клиент обрабатывает групповую политику.
Можно заставить клиента игнорировать номера версий при обработке объектов групповых политик. В этом случае клиент загрузит все политики, даже если они не изменились. Для этого используется групповая политика Process Even If The Group Policy Objects Have Not Changed (Обрабатывать объекты групповых политик, даже если они не изменились). Эту политику необходимо указать для каждого расширения на стороне клиента. Политики для расширений на стороне клиента хранятся в разделе Computer Configuration м Administrative TemplatesMSystemMGroup Policy (Конфигурация компьютерам Административные шаблоныМ Системам Групповая политика). '
Обработка сценариев
В операционной системе Windows 2000 пользовательские сценарии входа в систему запускаются асинхронно, даже если все остальные политики, включая сценарии загрузки компьютеров, запускаются синхронно. В операционных системах Windows Server 2003 и Windows ХР все политики обрабатываются асинхронно. Если сценарии входа пользователей в систему должны быть завершены до предоставления доступа к рабочему столу, включите групповую политику, которая называется Run Logon Script Synchronously (Синхронно выполнять сценарии входа в систему). Политика расположена в разделе User Configura- tionMAdministrative TemplatesMSystemMScripts (Конфигурация пользователям Административные шаблоныМ Системам Сценарии).
Перед установкой этой политики тщательно проверьте сценарии. Если сценарий “зависнет”, пользователь длительное время не сможет получить доступ к рабочему столу. Сценарию предоставляется 10 минут на завершение. Если сценарий все еще не завершил работу, система завершает его обработку и переходит к обработке следующего сценария. Если и следующий сценарий “зависнет”, пользователю придется ждать еще 10 минут.
Обработка всех групповых политик должна завершиться в течение 60 минут. Это ограничение не может быть изменено с помощью групповой политики или записи системного реестра. Ограничение в 10 минут на обработку сценария можно изменить с помощью групповой политики Maximum Wait Time For Group Policy Scripts (Максимальное время завершения сценариев групповых политик). Политика хранится в разделе Computer Configura- tionMAdministrative TemplatesMSystemMScripts (Конфигурация компьютерам Административные шаблоныМ Системам Сценарии).
Шаблоны групповых политик
Параметры, составляющие конкретную групповую политику, хранятся в одном или нескольких шаблонах групповых политик (Group Policy Template — GPT). Большинство групповых политик сохранено в виде файлов, которые загружаются и обрабатываются клиентами. Существует два исключения: политики инфраструктуры открытого ключа и политики IPSec. Они хранятся непосредственно в базе данных Active Directory. Файлы GPT хранятся в каталоге Sys vol на каждом контроллере домена.
Принудительная обработка политик из командной строки
Команда gpupdate /force заставляет клиент игнорировать номера версий и загружать все политики независимо от параметров расширений на стороне клиента.
За исключением двоичных файлов с расширениями .aas, которые используются при развертывании программного обеспечения, файлы шаблонов групповых политик являются текстовыми файлами. В них нет ничего сложного. Групповые политики не используют загадочные клиент/серверные операции. Клиент загружает текстовый файл и выполняет инструкции, описанные в этом файле.
В табл. 12.2 перечислены типы групповых политик и связанные с ними шаблоны GPT.
Таблица 12.2. Типы групповых политик и соответствующие файлы шаблонов
Тип групповой политики
Файл групповой политики
Системный реестр (административные шаблоны)
Перенаправление папок
Регистрационные сценарии (загрузка/отключение)
Параметры безопасности
Развертывание программного обеспечения
Дисковые квоты
Восстановление шифрованной файловой системы (EPS Recovery) и инфраструктура открытого ключа (PKI)
IP Security
Registry.pol.
Fdeploy.ini
Script. ini и сами файлы сценариев
Gpttmpl.inf
Файлы с расширением . aas
Registry.pol (см. примечание 1)
Сертификаты хранятся в базе данных
Active Directory
Политики хранятся в базе данных Active
Directory
Обслуживание Internet Explorer
Службы удаленной установки
Составление расписания для пакетов QoS
Программные ограничения
Install.ins
Oscfilter.ini
Нет
Registry.pol (см. примечание 1)
I
Примечание 1. Параметры квот и программных ограничений распространяются в файле Registry.pol, но обрабатываются раздельно
Создание шаблонов групповых политик
Рассмотрим пример использования редактора групповых политик для создания файлов GPT. Предположим, что создается объект групповой политики (GPO) под названием Desktop Lockdown, который связывается с организационной единицей Phoenix. В объекте групповой политики определяются три параметра.
Параметр в системном реестре, который скрывает пиктограмму Му Network Places (Мое сетевое окружение) на рабочем столе.
Параметры безопасности, которые предоставляют аутентифицированным пользователям возможность устанавливать время на локальных рабочих станциях.
Параметры перенаправления папок, которые перемещают папки Му Documents (Мои документы) всех пользователей в папку с именем пользователя на совместно используемом ресурсе \\Server\Docs.
При создании такого GPO редактор создает объект GPC в базе данных Active Directory и папку политики в каталоге 5у8Уо1\<имя_домена>\Ро11с1е8. Контейнеру GPC и каталогу назначаются одинаковые имена. Имя создается с помощью того же алгоритма, который используется для создания глобально уникальных идентификаторов GUID. Это позволяет сохранять уникальность групповых политик даже в случае изменения дружественного имени. Дружественное имя является одним из атрибутов объекта GPC в базе данных Active Directory.
Папка политики в этом примере будет содержать три файла шаблона групповой политики.
Файл Regi stry. pol, в котором хранится значение параметра NoNetHood.
Файл GptTempl. inf, в котором содержится запись, предоставляющая привилегию SeSystemTimePrivilege идентификатору безопасности S-1-5-11.
Файл Fdeploy. ini, в котором содержатся следующие строки:
[Folderstatus]
МуDocuments=ll
[Му Documents]
S-l-l-0=\\serverl\docs\%username%\My Documents
Новая папка политики и файлы GPT реплицируются на другие контроллеры домена с помощью службы репликации файлов. Служба репликации файлов (FRS) распространяет изменения в каталоге Sysvol немедленно. Эта служба не подчиняется правилам пятиминутных уведомлений в пределах сайта и частоте опроса, заданной для связей сайтов между связующими серверами.
Контейнеры групповых политик
Контейнер групповой политики (Group Policy Container — GPC) является объектом в базе данных Active Directory. Для GPC созданы атрибуты, которые указывают на файлы шаблона GPT, связанного с определенной политикой и расширениями на стороне клиента, необходимыми для обработки GPT. Ниже приведен фрагмент списка атрибутов контейнера групповой политики Default Domain:
cn: {31B2F340-016D-11D2-945F-00C04FB984F9};
displayName: Default Domain Policy;
gPCFileSysPath: \\company.com\sysvol\company.com\Policies\
(31B2F340-016D-11D2-945F-00C04FB984F9) ;
gPCFuntionalityVersion: 2;
gPCmachineExtensionNames: [{35378EAC-683F-11D2-A89A-00C04FBBCFA2} ^{53D6ABlB-2488-llDl-A28C-00C04FB94F17}(53D6AB1D-2488-11D1-A28C-
00C004FB94F17}][{827D319E-6EAC-11D2A4EA-00C04F79F83A}
{803E14A0-B4FB-11D0-A0D0-00A0C90F574B}][(B1BE8072-6EAC-11D2-A4EA-
00C04F79F83A}(53D6AB1B-2488-11D1-A28C-00C04FB94F17)
(53D6AB1D-2488-11D1-A28C-00C04FB94F17)];
gPCUserExtensionNames: [(3060E8D0-7020-11D2-842D-00C04FA372D4}
(3060E8CE-7020-11D2-842D-00C04FA372D4}];
gPCWQLFilter: [company.com;(F76FB374-E3B3-434E-953D-0FDDFB634FCF);0]; 1>
Ниже приводится описание атрибутов.
Атрибут GPCFileSysPath указывает путь, по которому необходимо искать файлы GPT.
Атрибут GPCMachineExtensionNames указывает идентификатор класса расширений на стороне клиента, которые клиент будет использовать для обработки файлов GPT для политик компьютера.
Атрибут GPCUserExtensionNames указывает идентификатор класса расширений на стороне клиента, которые клиент будет использовать для обработки файлов шаблона групповой политики для пользовательской политики.
Атрибут GPCWQLFilter содержит информацию о фильтрах WMI, которые применяются к объекту групповой политики.
Объекты GPC хранятся в контексте именования Domain в разделе cn=Policies, сп= System, <3с=<имя_ломена>, с1с=<корень>. Важно помнить, что отдельные домены в пределах леса поддерживают собственные списки GPC. Контекст именования Domain не реплицируется на другие контроллеры домена (кроме серверов глобального каталога, но эти копии
предназначены только для чтения). Это налагает ограничения на связь групповых политик с контейнерами Active Directory.
Избегайте связывания объекта групповой политики из одного домена с контейнером в другом домене.
Избегайте создания политик сайтов в пределах леса, состоящего из нескольких доменов.
В следующих главах рассматриваются возможные последствия нарушения таких ограничений.
Связывание объектов GPO через границы доменов
Файлы GPT, связанные с объектом групповой политики (GPO), хранятся в каталоге Sy svol контроллеров того же домена, в котором хранится объект GPC.
Если связать объект групповой политики (GPO) из одного домена с контейнером в другом домене, клиенты, для которых назначена эта групповая политика, должны будут связываться с контроллерами другого домена для,загрузки файлов GPT. Для этого требуется дополнительная аутентификация. Если контроллер домена доступен через внешнее соединение и находится в географически удаленном месте, то транзакция будет выполняться очень медленно.
Если используется лес из нескольких доменов и планируется развертывание целостного набора политик, создайте политики в каждом домене. Это повысит нагрузку на администратора, так как при каждом изменении политики в пределах предприятия придется редактировать несколько объектов групповой политики. Альтернативным решением является загрузка политик предприятия через внешнее соединение каждое утро при регистрации клиентов.
Политики сайтов в лесу из нескольких доменов■
Информация о сайтах хранится в базе данных Active Directory в отдельном контексте именования Configuration, который реплицируется на все контроллеры доменов в пределах леса. С другой стороны, информация о доменах хранится в контексте именования Domain, который реплицируется только на контроллеры домена в пределах того же домена.
К сожалению, в контексте именования Configuration нет возможности для хранения информации о групповых политиках сайтов. Контейнер групповой политики (GPC) может храниться только в контексте именования Domain/Для этого есть ряд причин.
В пределах любого сайта может присутствовать любое количество доменов конкретного леса, поэтому компания Microsoft приняла решение о хранении контейнеров групповых политик (GPC) для всех политик сайтов в одном контексте именования Domain (соответствующем корневому домену). Корневым является первый домен леса.
Так как только контроллеры домена в корневом домене хранят контейнеры GPC для политик сайтов, соответствующие файлы GPT хранятся только в каталоге Sysvol на контроллерах домена в корневом домене.
Комбинация этих инженерных решений ограничивает функциональные возможности политик сайтов в лесу из нескольких доменов (рис. 12.6). На схеме показано, как будут назначаться политики в лесу, состоящем из нескольких доменов.■
На рисунке показано два домена: NA и PACRIM. Контроллеры доменов и пользователи находятся в двух сайтах: LA и Tokyo. Для сайтов LA и Tokyo назначены групповые политики. Вспомните, что файлы GPT хранятся в каталоге Sysvol на контроллерах корневого домена леса независимо от расположения сайта и доменов, находящихся в пределах сайта.
Когда клиент из домена NA регистрируется в пределах сайта LA, он загружает файлы GPT для политик сайта LA с контроллера домена NA. Так как контроллер домена NA присутствует в пределах сайта LA, загрузка файлов шаблона групповой политики (GPT) выполняется достаточно быстро.
Клиент должен получать шаблоны групповых политик сайта с контроллера корневого домена
Рис. 12.6. Политики сайта в лесу, состоящем из нескольких доменов
Но у клиента домена PacRim, который регистрируется на сайте Tokyo, дела обстоят не так хорошо. Файлы GPT для сайта Tokyo хранятся на контроллере домена NA, корневого домена леса. Клиент из Tokyo должен использовать внешнее соединение для загрузки файлов GPT с контроллера домена NA, который находится в LA. Если в качестве внешнего соединения используется спутниковый канал со скоростью передачи данных 56 Кбайт/с, пользователи в Tokyo будут слишком долго ждать завершения регистрации.
Поэтому для реализации политик сайтов в лесу, состоящем из нескольких доменов, контроллеры корневого домена должны находиться в пределах каждого сайта, использующего политики сайта. Кроме этого, можно обеспечить быстрое внешнее соединение с ближайшим сайтом, в котором присутствует контроллер корневого домена. (Клиенты определяют ближайший сайт по ссылкам контроллера домена, который может проверять топологию сайта на основе IP-адресов, связанных с объектами IP Subnet, создаваемых для каждого сайта.)
Иерархия политик
Объекты групповых политик (GPO) связаны с объектами контейнеров в базе данных Active Directory. На основе таких связей клиенты определяют назначенные им политики. Объекты групповых политик можно связывать только с контейнерами трех типов.
Сайты (site)
Домены (domain)
Организационные единицы (OU)
Связи политик в базе данных Active Directory отслеживаются с помощью атрибута GPLink объекта контейнера. Ниже приведен фрагмент списка атрибутов организационной единицы Phoenix, с которым связаны две групповые политики:
ou: OU=Poenix,DC=Company,DC=com
gPLink: [LDAP://CN={91c0a3bc-141e-49bf-ad38-2da7905dbf09),CN=Policies, ^ CN=System,DC=Company,DC=com;0][LDAP;//CN=(205d4bee-acc2-465a-9aba-
Ь d84575d72523},CN=Policies,CN=System,DC=Company,DC=com;0];
gPOptions: 0;
Атрибут GPLink содержит характерные имена всех контейнеров групповых политик (GPC), связанных с контейнером. Вспомните, что для обеспечения уникальности имен используется формат GUID. Контейнер может быть связан с несколькими объектами групповых политик, и объект групповой политики может быть связан с несколькими контейнерами.
Атрибут GPOptions содержит значение параметра Block Policy Inheritance (Блокировать наследование политик), который рассматривается далее в этой главе. (Значение 0 отключает блокирование наследования. Значение 1 включает блокирование наследования для этого контейнера.)
Клиенты определяют список контейнеров по собственному характерному имени. Получив список контейнеров, клиент может запросить в базе данных Active Directory атрибуты GPCLink для каждого контейнера. Эта информация позволяет клиенту собрать параметры групповых политик из каждого объекта групповой политики в соответствии со следующими правилами приоритета (рис. 12.7).
dc=Company,dc=com
Компьютер
'Пользователь
Рис. 12.7. Схема наследования политик
Локальные политики (политики, определенные на локальном компьютере) имеют наименьший приоритет.
Объекты групповой политики (GPO), связанные с контейнером сайта.
Объекты групповой политики, связанные с контейнером домена.
Объекты групповой политики, связанные с организационной единицей.
Объекты групповой политики, связанные с ближайшей организационной единицей объекта пользователя или компьютера, имеют более высокий приоритет, чем объекты групповой политики, связанные с организационными единицами выше по дереву.
Последовательность символов LSDOU часто используется для представления этого порядка приоритетов. Порядок приоритетов реализует иерархию наследования (inheritance hierarchy). Эту иерархию можно переопределить двумя способами.
Можно установить политику, которая противоречит такому же параметру в объекте групповой политики, связанном с организационной единицей выше по дереву.
В базе данных Active Directory можно установить атрибут, который будет блокировать наследование всех объектов групповых политик, связанных выше по дереву.
Несложно догадаться, что оба варианта имеют свои преимущества. Рассмотрим их.
Отслеживание политики в системном реестре
Объект групповой политики, загруженный клиентом, хранится в локальном системном реестре в разделе HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\ shadow. Каждой политике назначается последовательный номер, начиная с нуля. Эта последовательность определяется приоритетом объектов групповых политик. Больший номер имеет больший приоритет.
Записи всех загруженных клиентом групповых политик хранятся в разделе системного реестра HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy .
Переопределение наследования политик
Существует возможность переопределить наследование политик для определенной организационной единицы. После этого объекты в пределах организационной единицы (и всех дочерних организационных единиц) прекращают получать параметры политик из контейнеров выше по дереву.
Обратитесь к рис. 12.7 из предыдущего раздела. Предположим, что создан объект групповой политики и он связан с контейнером домена. В этом объекте групповой политики определена политика безопасности Message Text For Users Attempting To Logon (Текстовое сообщение для регистрирующихся пользователей). Эта политика выводит информационное сообщение при регистрации пользователей. В сообщении указывается, что все компьютерное оборудование принадлежит компании и компания оставляет за собой право просматривать все данные, хранящиеся на компьютерах.
Эта групповая политика связывается с контейнером домена, так как каждый пользователь в пределах организации должен видеть это сообщение при каждой регистрации, чтобы никто не мог заявить, что он ничего не знал об ограничениях.
Администраторы организационной единицы Phoenix устали от жалоб пользователей на это сообщение. Администраторы решили отказаться от вывода этого сообщения в пределах своей организационной единицы. Это очень просто сделать: достаточно открыть окно свойств организационной единицы на консоли Active Directory — Users and Computers (Active Directory — пользователи и компьютеры) и установить флажок Block Policy Inheritance (Блокировать наследование политик) в свойствах групповой политики (рис. 12.8).
После внесения изменений пользователи перестанут получать уведомление при регистрации. Это нравится пользователям, но не нравится аудиторам компании, которые нанесут визит на следующей неделе. Аудиторы сообщают о нарушениях руководству компании, и администратору верхнего уровня дается задание прекратить нарушение общей политики. Администратор использует свои права Domain Administrator (Администраторы домена) для сброса флажка Block Policy Inheritance (Блокировать наследование политики) в организационной единице Phoenix. ,
Через некоторое время, когда страсти улягутся, администраторы организационной единицы Phoenix опять устанавливают флажок Block Policy Inheritance (Блокировать наследование политик). Главный администратор замечает изменение и сбрасывает флажок. Они уста-
навливают. Это происходит некоторое время, после чего администраторы организационной единицы Phoenix сдаются. Они прекращают менять параметр Block Policy Inheritance (Блокировать наследование политики).
Внимательное изучение ситуации показывает, что администраторы организационной единицы Phoenix создали новый объект групповой политики, который связан с организационной единицей Phoenix и отключает параметр Message Text For Users Attempting To Logon (Текстовое сообщение для регистрирующихся пользователей). Так как объект групповой политики связан с ближайшей организационной единицей, он имеет больший приоритет и блокирует вывод уведомления.
Рис. 12.8. В свойствах организационной единицы можно установить флажок Block Policy Inheritance (Блокировать наследование политики )
Автор этой книги не знает, где ее будут читать, но в южном Нью-Мехико такое состязание имеет собственное название. Обычно вопрос решается с помощью шестизарядного револьвера в полдень перед салуном на главной улице. Жителей более мягких климатических зон может заинтересовать следующее, менее драматическое, решение.
Переопределение блокирования политики
Администратор домена или предприятия может установить параметр объекта групповой политики выше по дереву, который приведет к переопределению всех блокировок наследования. Установка этого параметра описывается в процедуре 12.1.
Процедура 12.1. Переопределение блокирования наследования
Откройте окно свойств контейнера верхнего уровня, например контейнера домена или организационной единицы.
Откройте вкладку Group Policy (Групповая политика).
Выделите объект групповой политики, для которого необходимо задать принудительное наследование.
Щелкните на кнопке Options (Параметры).
Выберите переключатель No Override (Не перекрывать), как показано на рис. 12.9.
Щелкните на кнопке ОК для сохранения изменений.
Рис. 12.9. Окно параметров для контейнера организационной единицы с переключателем No Override (Не перекрывать) для выбранной групповой политики
Переключатель No Override (Не перекрывать), установленный в каждом объекте групповой политики, сделает все параметры политики, определенные в этом объекте, обязательными для компьютеров и пользователей ниже по дереву. Администраторы могут установить флажок Block Policy Inheritance (Блокировать наследование политики), но этот параметр будет проигнорирован. Если локальные администраторы попытаются переопределить конкретные параметры, они обнаружат, что различные параметры политики, определенные в объекте групповой политики более высокого уровня, неактивны и недоступны для изменения в редакторе групповых политик.
Определение результирующего набора политик
Объекты групповых политик (GPO) могут быть связаны, отфильтрованы, заблокированы и разблокированы тысячей способов. Компания Microsoft сделала большой шаг в сторону упрощения управления групповыми политиками, включив в состав операционной системы Windows Server 2003 программу, лицензированную у компании Full Armor Software (ww. fullarmor.com). Программа называется FAZAM или Full Armor Zero Administration Management.
Как и в случае большинства технологий от сторонних производителей, лицензированных компанией Microsoft, возможности результирующего набора политик (Resultant Set of Policies — RSoP), предоставляемые Windows-версией программы FAZAM, являются только частью возможностей коммерческой версии программы FAZAM. Часть программы FAZAM, лицензированная компанией Microsoft, позволяет рассчитывать и протоколировать результирующий набор политик (RSoP) на основе расположения определенного пользователя или компьютера в базе данных Active Directory.
Определение результирующего набора политик можно использовать для проверки того, что произойдет, когда определенный пользователь зарегистрируется на определенном компьютере. При определении принимаются во внимание расположение объекта пользователя и объекта компьютера, имя узла и все фильтры, которые применяются на основе членства в группах и используемых аппаратных средств.
Кроме этого, в операционных системах Windows Server 2003 и Windows ХР сохраняется журнал с отчетом о последнем определенном результирующем наборе политик для каждого регистрирующегося на компьютере клиента. Программу подсчета RSoP можно использовать для просмотра содержимого этого журнала для любого компьютера в пределах домена. Журнал расположен в хранилище Common Information Model (CIM). Дополнительная информация приводится в разделе “Фильтрация WMI”.
Планирование результирующего набора политик
Программа просмотра результирующего набора политик может быть запущена несколькими способами. Самый простой способ описан в процедуре 12.2.
Процедура 12.2. Запуск мастера результирующего набора политик в режиме планирования
Щелкните правой кнопкой мыши на объекте пользователя или компьютера на консоли Active Directory — Users and Computer (Active Directory — пользователи и компьютеры) и выберите из контекстного меню команду All Tasks* RSoP (Planning) (Все задачи1*Результирующая политика (Планирование)). Запустится мастер результирующего набора политик, начиная с окна User and Computer Selection (Выбор компьютера и пользователя). Пример показан на рис. 12.10.
User end Coeputec Selection
You can view simLiaied policy settings for a selected user (or a container with user information) and computer (or a container with computer information)
Puc. 12.10. Окно User and Computer Selection (Выбор компьютера u пользователя) мастера результирующего набора политик
В разделе Computer information (Сведения о компьютере) выберите переключатель Container (Контейнер), щелкните на кнопке Browse (Обзор) и выберите организационную единицу объекта пользователя.
На этом этапе мастер имеет достаточно информации для расчета результирующего набора политик, поэтому можно установить флажок Skip to the final page... (Перейти к последней странице, не собирая дополнительных данных) и щелкнуть на кнопке Next (Далее). Но мы рассмотрим дополнительные параметры, которые позволяют диагностировать потенциальные проблемы.
Щелкните на кнопке Next (Далее). Откроется окно Advanced Simulation Options (Дополнительные параметры эмуляции). В окне можно установить следующие параметры.
Slow Network Connection (Низкоскоростное сетевое подключение). В этом случае моделируется обработка объекта групповой политики по коммутируемому подключению, ISDN или подключению DSL.
Loopback Processing (Обработка по методу обратной петли). Моделируется обмен данными между Computer Configuration и User Configuration, который возникает при использовании политики работы по методу обратной петли для объекта компьютера.
Site (Сайт). Указывается сайт, в котором регистрируется пользователь.
Щелкните на кнопке Next (Далее). Откроется окно Alternate Active Directory Paths (Альтернативные пути Active Directory). Это позволит выбрать другую организационную единицу для учетных записей пользователя и компьютера.
Щелкните на кнопке Next (Далее). Откроется окно User Security Groups (Группы безопасности пользователя). В окне отображаются группы, в которые входит пользователь. Можно выбрать дополнительные группы или удалить существующие группы с целью планирования и устранения неисправностей.
Щелкните на кнопке Next (Далее). Откроется окно Computer Security Groups (Группы безопасности компьютера). В окне показаны группы, в которые входит компьютер. Можно выбрать дополнительные группы или удалить существующие группы с целью планирования и устранения неисправностей.
Щелкните на кнопке Next (Далее). Откроется окно WMI Filters for Users (Фильтры WMI для пользователей). В окне перечислены связанные фильтры WMI. С целью устранения неисправностей можно выбрать другие фильтры.
Щелкните на кнопке Next (Далее). Откроется окно WMI Filters for Computers (Фильтры WMI для компьютеров). В окне перечислены связанные с компьютером фильтры WMI. С целью устранения неисправностей можно выбрать другие фильтры.
Щелкните на кнопке Next (Далее). Откроется окно Summary of Selections (Выбранные параметры). Для изменения параметров щелкните на кнопке Back (Назад). Если необходимо сравнить результаты на различных контроллерах домена, можно выбрать другой контроллер домена, на котором будут обрабатываться выбранные параметры.
Щелкните на кнопке Next (Далее). После того как мастер завершит обработку, появится окно Finish (Готово). Щелкните на кнопке Finish (Готово), чтобы открыть окно с информацией о результирующем наборе политик.
Утилита просмотра результирующего набора политик напоминает стандартный редактор групповых политик, но он содержит только те параметры групповых политик, которые входят в объекты групповых политик, соответствующие указанным критериям. Еще одна утилита просмотра результирующего набора политик предоставляется в составе Help and Support Center. Эта утилита предоставляет список политик в формате XML. Список содержит всю информацию о групповых политиках, которые применяются на компьютере. Для запуска этой утилиты необходимы привилегии локального администратора на компьютере.
Утилита gpresult
Ели для просмотра результирующего набор» политик предпочтительнее использовать , утилиту с интерфейсом командной строки, воспользуйтесь утилитой gpresult. В отличие от утилиты gpresult из состава Windows 2000 Resource Kit, утилита из состава Windows Server 2003 выполняет те же расчеты, что и мастер результирующего набора политик. Кроме этого, утилиту gpresult можно использовать для просмотр» журнала результирующего набора политик.
Отчет утилиты gpresult слишком велик для цитирювания на страницах этой книги, но в него входит вся информация, необходимая для прюслеживания каждого параметра политик к исходному объекту групповой политики и связанному с ним контейнеру. Утилиту gpresult можно запускать в режиме планирования и в режиме протоколирювания.
Протоколирование результирующего набора политик
В утилите просмотра результирующего набора политик можно включить режим протоколирования (Logging), который позволяет просматривать результат определения результирующего набора политик для любого клиента на компьютере. Для просмотра журнала на компьютере необходимо иметь права администратора. Необходимая последовательность действий приведена в процедуре 12.3.
Процедура 12.3. Запуск мастера результирующего набора политик в режиме протоколирования
На консоли Active Directory — Users and Computers (Active Directory — пользователи и компьютеры) щелкните правой кнопкой мыши на объекте компьютера и выберите из контекстного меню команду Resultant Set Of Policy (Logging) (Результирующая политика (Протоколирование)). Запустится мастер результирующего набора политик и откроется окно Computer Selection (Выбор компьютера).
Щелкните на кнопке Next (Далее). Откроется окно User Selection (Выбор пользователя). Выделите имя пользователя, для которого необходимо просмотреть результаты работы мастера.
Щелкните на кнопке Next (Далее). Откроется окно Summary of Selections (Выбранные параметры).
Щелкните на кнопке Next (Далее). Мастер получит записи журнала пользователя с выбранного компьютера и выведет их на экран.
Сравнивая результаты работы мастера результирующего набора политик в режиме планирования и фактический результирующий набор политик, можно обнаружить различие и внести необходимые изменения.
Дополнительные утилиты диагностики
Если настроенные групповые политики работают не совсем так, как предполагалось, обра: тите внимание на следующие компоненты.'
Event Viewer (Просмотр событий). Обратитесь к журналу приложений и просмотрите записи службы Userenv. Предупреждения от этой службы указывают, что в процессе загрузки групповых политик что-то пошло не так.
Права доступа. Одной из распространенных проблем в работе групповых политик являются неверно назначенные права доступа, связанные с системой безопасности. Всегда проверяйте, имеет ли пользователь права на политику, которую необходимо применить. Для этого откройте соответствующую консоль Active Directory, откройте окно свойств групповой политики для соответствующего контейнера и перейдите на вкладку Security (Безопасность). Пользователь должен являться членом группы с правами доступа Read (Чтение) и Al 1 ow Group Policy (Разрешить применение групповой политики).
Неправильные связи групповых политик. Еще одной проблемой в работе групповых политик является неправильная настройка связей. Политику можно связать с одним контейнером, а проверку выполнять с помощью учетной записи пользователя из другого контейнера. Кроме этого, кто-то может разместить групповую политику в контейнере выше по дереву, которая перезаписывает параметры политики или полностью ее блокирует.
Утилита gpotool. Как было показано в разделе о контейнерах групповых политик, утилита gpotool позволяет отследить несовпадения номеров версий шаблонов и контейнеров групповых политик, связанных с одним объектом групповой политики.
Проблемы в работе сети. Удостоверьтесь, что клиент успешно устанавливает соединение с контроллером домена, сервером глобального каталога и сервером DNS. Невозможность подключения к одному из этих серверов приводит к проблемам в работе групповых политик. Для обнаружения ошибок можно воспользоваться утилитой netdiag.
Отладка службы Userenv. Последней попыткой обнаружить проблему является включение журнала групповых политик. Добавьте следующую запись в раздел win logon системного реестра:
I
Раздел:HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon Запись: UserEnvDebugLevel
Значение: 0x10002 (шестнадцатеричное), rnnREG_DWORD
После добавления записи перезагрузите компьютер. Журнал сохраняется в файле \Windows\ DebugXUserenv. log. Журнал большой, поэтому при его чтении стоит запастись чаем и пирожками.
Политики для компьютеров и политики для пользователей
Объекты групповых политик делятся на две части.
В разделе Computer Configuration (Конфигурация компьютера) содержатся параметры политик для объектов компьютеров.
В разделе User Configuration (Конфигурация пользователя) содержатся параметры политик для объектов пользователей.
В редакторе групповых политик эти разделы отображаются в вершине дерева разделов.
Некоторые параметры политик доступны в обоих разделах. Если возникает конфликт между параметрами в разных разделах, более высокий приоритет имеет раздел Computer Configuration (Конфигурация компьютера). Это справедливо, даже если параметры политик находятся в различных объектах групповых политик.
Рассмотрим пример, в котором организационная единица Phoenix содержит объекты пользователей и компьютеров. Существует два объекта групповой политики, которые связаны с организационной единицей Phoenix.
Объект групповой политики Phx-Computers
Объект групповой политики Phx-Users
Каждый объект групповой политики содержит политику в разделе Task Scheduler (Планировщик заданий), которая называется Prohibit New Task Creation (Запретить создание новых заданий). При включении этой политики в Control Panel (Панель управления) пиктограмма Add Scheduled Task (Добавить задание) не отображается в аплете Scheduled Tasks (Назначенные задания).
Объект групповой политики Phx-Users содержит политику в разделе User Configuration (Конфигурация пользователя), а объект Phx-Computers содержит политику в разделе Computer Configuration (Конфигурация компьютера). Рассмотрим, как обрабатывается эта политика.
В объекте групповой политики Phx-Users политика отключена, а это значит, что можно создавать новые задания.
В объекте групповой политики Phx-Computers политика включена, т.е. новые задания создавать невозможно.
При такой конфигурации пользователь из организационной единицы Phoenix, регистрирующийся на компьютере из организационной единицы Phoenix, не сможет получить доступ к пиктограмме Add Scheduled Task (Добавить задание), которая находится в аплете Scheduled Tasks (Назначенные задания). Создание новых запланированных заданий отклю-
чено, так как политика из раздела Computer Configuration (Конфигурация компьютера) имеет более высокий приоритет, чем политика из раздела User Conf igurat ion (Конфигурация пользователя).
Если администратор переключит политику в объекте групповой политики Phx-Computers из Disabled (Отключена) в Not Configured (Не задана), сразу же после обновления политик на рабочих станциях пользователи смогут получить доступ к пиктограмме Add Scheduled Task (Добавить задание).
Использование интерфейса обратной петли
В предыдущем разделе рассматривалась ситуация, когда параметры политики в разделе Сomputer Con f i gur at ion (Конфигурация компьютера) переопределяют параметр политики из раздела User Configuration (Конфигурация пользователя). Существует еще одна ситуация, когда система должна определить приоритет политики на основании ее расположения.
Рассмотрим сценарий, похожий на последний пример, но в организационной единице Phoenix существуют еще две организационные единицы.
В организационной единице Users хранятся объекты пользователей организационной единицы Phoenix. Эта организационная единица связана с объектом групповой политики Phx-Users.
В организационной единице Computers хранятся объекты компьютеров организационной единицы Phoenix. Эта организационная единица связана с объектом групповой политики Phx-Computers.
Для объектов групповой политики (GPO) могут быть установлены различные параметры. Подробная информация о каждом параметре в данном случае не важна.
Для объекта групповой политики Phx-Users заданы два параметра политик: политика безопасности в разделе Computer Configuration (Конфигурация компьютера) и политика распространения программного обеспечения в разделе User Conf igurat ion (Конфигурация пользователя).
Для объекта групповой политики Phx-Computers заданы два параметра политик: политика аудита в разделе Computer Configuration (Конфигурация компьютера) и политика регистрационного сценария в разделе User Configuration (Конфигурация пользователя).
Как только пользователь из организационной единицы Users зарегистрируется на компьютере из организационной единицы Computers, результирующий набор политик будет содержать следующие политики.
Политика распространения программного обеспечения из объекта групповой политики
Phx-Users
Политика аудита из объекта групповой политики Phx-Computers
В обычных условиях это вполне допустимо. Но иногда имеет смысл применять параметры раздела User Configuration (Конфигурация пользователя) из объектов групповой политики, связанных с контейнерами, в которых хранятся объекты компьютеров. Чаще всего такая ситуация возникает при использовании лабораторных компьютеров или серверов терминалов, на которых необходимо сохранять один и тот же внешний вид и одни и те же правила использования рабочего стола, а также поддерживать одинаковые наборы программного обеспечения независимо от зарегистрировавшегося пользователя.
В таких ситуациях систему можно настроить на применение параметров раздела User Configuration (Конфигурация пользователя) из объекта групповой политики, который связан с контейнером, содержащим объекты компьютеров. Этот метод называют обработкой с использованием интерфейса обратной петли (loopback processing).
Обработку с использованием интерфейса обратной петли можно включить с помощью групповой политики, которая называется User Group Policy Loopback Processing Mode (Режим обработки по методу обратной петли для пользовательской групповой политики). Эта политика хранится в разделе Computer Configuration^Administrative Templates^System^ Group Policy (Конфигурация компьютерам Административные шаблоныМ Системам Групповая политика).
Можно использовать два режима обработки по методу обратной петли.
Режим замены. В этом режиме клиентский компьютер игнорирует политики из раздела User Conf igurat ion (Конфигурация пользователя), полученные из объекта групповой политики, связанного с пользовательским контейнером, и применяет групповые политики из раздела User Configuration (Конфигурация пользователя) из объекта групповой политики, связанного с контейнером компьютера.
Режим объединения. В этом режиме клиентский компьютер сначала применяет политики из раздела User Configuration (Конфигурация пользователя) объекта групповой политики, связанного с контейнером компьютера. После этого применяются политики из раздела User Configuration (Конфигурация пользователя) объекта групповой политики, связанного с контейнером пользователя. Больший приоритет предоставляется параметрам политик пользователя.
Если обработка по методу обратной петли включена в режиме замены, клиент получит следующий результирующий набор политик.
Политика аудита для организационной единицы Phx-Computer
Политика регистрационного сценария для организационной единицы Phx-Computer
Политика из раздела User Configuration (Конфигурация пользователя) при обработке по методу обратной петли игнорируется. Политика из раздела Computer Configuration (Конфигурация компьютера) из пользовательского контейнера игнорируется независимо от режима обработки по методу обратной петли.
Если обработка по методу обратной петли включена в режиме объединения, клиент получит следующий результирующий набор политик.
Политика аудита для организационной единицы Phx-Computer
Политика регистрационного сценария для организационной единицы Phx-Computer
Политика распространения программного обеспечения для организационной единицы
Phx-Users
Политика из раздела Computer Configuration (Конфигурация компьютера) для пользовательского контейнера игнорируется независимо от режима обработки по методу обратной петли.
Следует избегать обработки по методу обратной петли во всех случаях, кроме случая создания специализированных сред. Обработка по методу обратной петли значительно усложняет диагностику групповых политик. Создавайте отдельные организационные единицы для хранения объектов компьютера. Иногда стоит физически идентифицировать компьютеры, для которых применяется обработка по методу обратной петли (например, с помощью пометки на мониторе), чтобы пользователи не удивлялись невозможности получить собственные параметры.
Редактор групповых политик
Содержимое объекта групповой политики (GPO) управляется с помощью редактора групповых политик (Group Policy Editor — GPE). Редактор является оснасткой ММС, доступной несколькими способами.
Чаще всего, чтобы получить доступ к редактору GPE, открывают окно свойств сайта, домена или организационной единицы, а затем переходят на вкладку Group Policy (Групповая политика).
Кроме этого, можно создать собственную консоль ММС и загрузить в нее оснастку GPE. При этом будет выдан запрос на выбор редактируемого объекта GPO. Щелкните на кнопке Browse (Обзор). Откроется окно Browse for a Group Policy Object (Поиск объекта групповой политики). Перейдите на вкладку АН (Все), чтобы получить доступ к полному списку всех объектов групповой политики домена (рис. 12.11).
Оснастку GPE можно загружать несколько раз на одну и ту же консоль ММС. При каждой загрузке оснастки необходимо выбрать новый объект групповой политики. Это идеальный способ управления несколькими GPO из одного интерфейса.
Кроме этого, собственную консоль можно настроить на конкретную групповую политику или конкретный компьютер (или и то, и другое одновременно). В этих случаях используются параметры командной строки /gpcomputer и /gpobject. Именно так компания Microsoft создала специализированные консоли Local Security Settings и Domain Security Policy. Например, в ярлыке, загружающем консоль Domain Security Policy, в поле Target задано следующее значение:
C:\WINDOWS\system32\dompol.msc /gpobject:"LDAP://CN={3lb2f340-06d 'b -lld2-945f-00c04fb984f9},CN=Policies,CN=System,DC=COmpany,DC=com"
Как будет показано в следующем разделе, консоль Dompol .msc использует возможность консоли ММС, которая позволяет загружать конкретные расширения редактора GPE.
Специальные конфигурации с использованием параметров командной строки
Если для управления консолью ММС необходимо использовать параметры командной строки /gpcomputer и /gpobject, то при загрузке объекта групповой политики на консоль с помощью окна Add/Remove Snap-in (Добавить/удалить оснастку) необходимо установить следующий параметр групповой политики:
Allow The Focus Of The Group Policy Snap-In To Be Changed When Launching From The Command Line (Разрешить изменять фокус оснастки групповой политики при запуске из командной строки).
Рис. 12.11. Окно Browse for a Group Policy Object (Поиск объекта групповой политики), в котором показан список объектов групповой политики в домене Company.сот
Выбор расширения редактора групповых политик
Редактор GPE зависит от нескольких файлов поддержки, которые предоставляют возможность редактирования различных типов политик. В табл. 12.3 перечислены файлы шаблонов групповых политик (GPT) и соответствующие расширения GPE. Если при открытии раздела в редакторе GPE выдается сообщение об ошибке, ищите проблему в работе соответствующего редактора или в файлах, которые он пытается открыть.
Таблица 12.3. Файлы шаблонов групповых политик и соответствующие расширения редактора GPE
Файл GPT
Расширение GPE
Registry.pol
Gptext.dll
GptTmpl.inf
Wsecedit.dll
Script.ini
Gptext.dll
Fdeploy.ini
Fde.dll
* .aas (развертывание программного обеспечения)
Appmgr.dll
Install.ins
Ieaksie.dll
При создании собственной консоли ММС для редактирования групповых политик можно указать отдельные расширения редактора. Для этого перейдите на вкладку Extensions (Расширения) в окне Add/Remove Snap-in (Добавить/удалить оснастку) и сбросьте флажки напротив всех расширений, которые загружать не нужно. На рис. 12.12 показан пример пользовательской консоли, на которой загружается только расширение Logon/Logoff Scripts (Сценарии входа/выхода из системы).
Рис. 12.12: Окно Add/Remove Snap-in (Доба- вшпъ/удалить оснастку) для пользовательской консоли, в котором выбрано несколько расширений
PDC Emulator и редактор групповых политик
При редактировании объектов GPO редактор GPE читает контейнер GPC и шаблон GPT с определенного контроллера домена. По умолчанию выбирается контроллер домена, которому назначена роль PDC Emulator. Выбор контроллера домена не зависит от текущих настроек консоли Active Directory — Users and Computers (Active Directory — пользователи и компьютеры) или консоли Active Directory — Sites and Services (Active Directory - сайты и службы) на момент запуска редактора групповых политик.
Например, если консоль Active Directory — Users and Computers (Active Directory — пользователи и компьютеры) запускается на рабочей станции, использующей контроллер домена DC-37 в качестве регистрационного сервера, то консоль будет настроена на контроллер домена DC-37, но редактор GPE автоматически обратится за информацией на PDC Emulator, а не на контроллер домена DC-37.
На первый взгляд, редактирование групповых политик на единственном контроллере домена противоречит принципу репликации с несколькими хозяевами. В конце концов, изменения в любой копии базы данных Active Directory или каталога Sysvol будут реплицированы на все остальные контроллеры домена, не правда ли?
Использование единственного контроллера домена для редактирования групповых политик предотвращает возможность редактирования политик в объекте GPO двумя администраторами одновременно (в течение одного цикла репликации). Если это произойдет, внесенные одним администратором изменения будут перезаписаны изменениями, внесенными вторым администратором.
Если во время запуска редактора GPE недоступен сервер, выполняющий роль PDC Emulator, то будет выдан запрос следует ли выбрать другой контроллер домена или ожидать доступа к PDC Emulator. Ничего страшного в редактировании объекта GPO на другом контроллере домена нет, но необходимо убедиться, что этот объект групповой политики редактирует один администратор. В случае сомнений стоит подождать доступности PDC Emulator.
Изменение принятого по умолчанию контроллера домена
Если для изменения объектов GPO используется не PDC Emulator, а другой контроллер домена, для изменения критерия выбора контроллера домена можно установить соответствующую групповую политику. Политика называется Group Policy Domain Controller Selection (Выбор контроллера домена для групповых политик). Политика расположена в разделе User Configuration^Administrative Templates^System^Group Policy (Конфигурация пользователя1^ Административные шаблоны^Система^Групповая политика).
Эта политика имеет три параметра.
Use the Primary Domain Controller (Использовать основной контроллер домена). Если политика не включена, этот параметр установлен по умолчанию.
Inherit From The Active Directory Snap-Ins (Унаследовать от оснасток Active Directory).
Это значение заставит редактор GPE выбирать контроллер домена, на который настроена консоль Active Directory — Users and Computers (Active Directory — пользователи и компьютеры) или консоль Active Directory — Sites and Services (Active Directory — сайты и службы), запустившая редактор групповых политик.
Use Any Available Domain Controller (Использовать любой доступный контроллер домена). Это значение позволяет редактору использовать первый доступный контроллер домена. Обычно это сервер, на котором проходит регистрацию администратор, запускающий редактор GPE.
Можно обратить внимание на отсутствие одного очевидного варианта. Нельзя просто указать контроллер домена, который будут использовать все. Если все должны использовать определенный контроллер домена, просто передайте роль PDC Emulator этому серверу.
Групповые политики и локальные политики
Серверы под управлением операционной системы Windows Server 2003 и рабочие станции под управлением Windows ХР не только загружают групповые политики с контроллера домена, но и используют политики из собственного локального хранилища политик в скрытом каталоге \windows\System32\GroupPolicy. Кроме этого, на локальных компьютерах существуют хранилища данных, которые управляются групповыми политиками, а локальные изменения записываются в эти хранилища непосредственно.
Политики “накладываются” одна на другую в процессе применения. Наибольший приоритет получает последний набор политик. Локальные политики всегда применяются первыми, поэтому они чаще всего перекрываются групповыми политиками, загружаемыми с контроллера домена.
Если приходится управлять изолированной рабочей станцией или сервером, изменения в локальные политики можно внести с помощью консоли Local Policy Editor (Редактор локальной политики), Gpedit .msc. Файлы шаблонов групповой политики, созданные средствами консоли Gpedit .msc, хранятся в каталоге \Windows\System32\GroupPolicy.
Загруженные из домена групповые политики кэшируются локально. По этой причине пользователи портативных компьютеров, отключенных о сети, будут продолжать использование последнего набора групповых политик, загруженного с контроллера домена. Об этом важно помнить, так как некоторые групповые политики требуют кэшированной информации для нормального функционирования. В качестве примера можно привести шифрованную файловую систему, которая ищет кэшированную версию сертификата восстановления файлов от доменного агента восстановления данных (Data Recovery Agent — DRA) при шифровании файла пользователем. Если сертификат доменного агента восстановления данных недоступен, пользователю не удастся зашифровать файл.
Различные приоритеты групповых политик приводят к маскированию локальных политик. Иногда администраторы забывают об их существовании. Политики “тихо спят” в системном реестре или базе данных Secedit и никак себя не проявляют, пока компьютер не отключится от домена или пользователь не зарегистрируется с помощью локальной базы данных SAM вместо домена.
Цели групповых политик
В принятой по умолчанию конфигураций параметры из объекта групповой политики оказывают влияние на всех пользователей и все компьютеры, которые находятся в связанном контейнере. Если необходим более избирательный подход в назначении групповых политик, окажется полезной возможность фильтрации получателей политики. Операционная система Windows Server 2003 имеет два критерия фильтрации.
Членство пользователя или компьютера в группе
Аппаратная и программная конфигурация, доступная с помощью инструментария управления Windows (Windows Management Instrumentation — WMI)
Фильтрация групповых политик на основе групп безопасности
Одним из самых распространенных заблуждений является мнение о назначении групповых политик группам. Конечно же, это совершенно не соответствует истине. Групповые политики назначаются объектам пользователей и компьютеров на основе их положения в базе данных Active Directory. Группы для назначения групповых политик не используются.
Но существует возможность фильтрации объектов групповых политик таким образом, чтобы политика применялась только к объектам пользователей и компьютеров, которые являются членами определенной группы. Например, можно создать универсальный набор по-
литик настройки рабочих станций в объекте групповой политики, связанном с региональной организационной единицей, например Phoenix. Параметры этого объекта групповой политики подходят большинству пользователей, но руководитель отдела продаж требует ужесточения ограничений, чтобы обеспечить повышение производительности.
Можно переместить объекты пользователей из отдела продаж в отдельную организационную единицу в организационной единице Phoenix и создать новый объект групповой политики, связанный с этой организационной единицей, но иногда существуют ограничения, не позволяющие пойти на такой шаг. Например, предоставленные административные привилегии могут не позволять создавать новые организационные единицы. Или в организации принят проект развития домена Active Directory, который не допускает создания произвольных организационных единиц. Кроме этого, может потребоваться применение групповой политики к пользователям из различных организационных единиц.
В таких ситуациях можно создать новый объект групповой политики и включить фильтрацию, чтобы групповая политика применялась только к пользователям из группы Sales. Для этого необходимо изменить дескриптор безопасности контейнера групповой политики в базе данных Active Directory, чтобы только определенные группы могли читать и применять шаблоны GPT, определенные в контейнере GPC (рис. 12.13).
Рис. 12.13. Окно ACL Editor для групповой политики, в котором одной группе безопасности предоставлено разрешение Apply Group Policy (Применение групповой политики)
Самый простой способ изменения дескриптора безопасности контейнера групповой политики описан в процедуре 12.4.
Процедура 12.4. Настройка дескриптора безопасности GPO для фильтрации получателей политики
Щелкните правой кнопкой мыши на записи сайта, домена или организационной единицы, связанной с GPO. Из контекстного меню выберите команду Properties (Свойства).
Перейдите на вкладку Group Policy (Групповая политика).
Выделите групповую политику, для которой необходимо включить фильтрацию, и щелкните на кнопке Properties (Свойства). Откроется окно Properties (Свойства).
Перейдите на вкладку Security (Безопасность).
Измените список контроля доступа в соответствии с требованиями к фильтрации. Предоставьте разрешение Apply Group Policy (Применение групповой политики) всем группам, которые должны получать эту политику.
Щелкните на кнопке ОК, чтобы сохранить изменения и закрыть окно редактора.
Если принято решение об использовании фильтрации для предоставления GPO только определенным группам или группе, помните, что фильтр применяется только в том случае, когда объекты пользователей в группе попадают в область действия GPO. Например, перемещение объекта пользователя отдела продаж из организационной единицы Phoenix в организационную единицу Atlanta приведет к тому, что пользователь перестанет получать групповую политику Sales Lockdown.
Фильтрация WMI
WMI (Windows Management Instrumentation), или инструментарий управления Windows, является реализацией инициативы Web-Based Enterprise Management (WBEM) от компании Microsoft. Инициатива предложена рабочей группой Desktop Management Task Force (DMTF). На рис. 12.14 показана блок-схема компонентов WMI.
Рис. 12.14. Схема взаимосвязи компонентов WMI, которые используются при фильтрации WMI для групповых политик
Рассмотрим эти компоненты.
Управляемые объекты. Инструментарий управления Windows собирает информацию от различных устройств и приложений. В качестве примера таких устройств можно привести жесткие диски, центральные процессоры, память и сетевые адаптеры. Эти объекты абстрагируются с помощью объектов СОМ, которые называются провайдерами (providers) и собирают информацию, предоставляемую управляемыми объектами.
Common Information Model (CIM). Инструментарий управления Windows хранит полученную от провайдеров информацию об управляемых объектах в хранилище, которое называется Common Information Model (CIM). Это хранилище больше похоже не на базу данных, а на аудиторию, в которой объекты выдают информацию при их вызове. Вершиной хранилища CIM является \root\cimv2.
Диспетчер объектов CIM. Информация хранилища CIM предоставляется с помощью диспетчера объектов CIM (Common Information Model Object Manager — CIMOM). Диспетчер объектов отвечает за обработку входящей информации от провайдеров и связь с приложениями, которые нуждаются в информации из хранилища CIM.
Язык запросов инструментария управления Windows (WMI Query Language — WQL). Поскольку WMI является реализацией инициативы WBEM от компании Microsoft, для доступа к информации, предоставляемой диспетчером объектов, используется созданный компанией Microsoft язык запросов инструментария управления Windows (WMI Query Language — WQL). Этот язык обеспечивает доступ с правом только для чтения к CIMOM. Обновления вносятся программными средствами с помощью провайдеров.
Триггеры событий. Кроме пассивного ответа на запросы, CIMOM может активно отправлять сообщения и выполнять действия в ответ на события, возникающие в хранилище CIM. Групповые политики не используют события WMI.
Операционная система Windows Server 2003 использует WMI различными способами. В случае групповых политик WMI можно использовать для фильтрации объектов GPO, исходя из результатов запроса оператора на языке WQL.
Операторы языка WQL
Синтаксис языка WQL является подмножеством синтаксиса SQL с расширениями для специальных классов в хранилище CIM. Чаще всего в запросах к WMI используется оператор Select с модификаторами Where, которые определяют результирующее множество. Рассмотрим несколько примеров.
Выдать перечень компьютеров, использующих процессор с частотой выше 600 МГц:
root\cinv2; SELECT * from Win32_Processor
4> WHERE currentclockspeed < 600
Выдать перечень компьютеров, которые работают под управлением операционной системы Windows 2000 Professional. Это необходимо для развертывания конкретных пакетов обновлений или утилит:
root\cinv2; SELECT * from Win32_OperatingSystem
'Ъ WHERE caption = ""Microsoft Windows 2000 Professional"
Выдать перечень компьютеров, на которых установлен клиент для сетей Microsoft:
root\cinv2; SELECT * from Win32_NetworkClient
'Ъ WHERE name = ""Microsoft Windows Network"
Обратите внимание на использование двойных кавычек в операторе выбора. Двойные кавычки зарезервированы в языке WQL в качестве управляющего символа, поэтому их необходимо указывать дважды, чтобы они были переданы диспетчеру объектов CIM (CIMOM).
Вместо большого количества примеров рассмотрим замечательный способ поиска интересных классов WMI, что позволит создавать собственные операторы WQL.
Набор инструментальных средств разработки WMI (WMI SDK) предоставляется вместе с Web-ориентированным CIMOM-браузером CIM Studio. WMI SDK доступен на сайте компании Microsoft по адресу msdn.microsoft. com/downloads. Перейдите по дереву до раздела Windows Development^Windows Management Instrumentation.
Программа CIM Studio имеет интерфейс браузера (рис. 12.15). Этот браузер можно использовать для поиска интересующих классов. Для этого необходимо щелкнуть на кнопке Find (Найти) (пиктограмма бинокля над правой панелью) и ввести слово network. В результате будет выдан список всех классов, в названиях которых содержится слово network.
Классы, начинающиеся с Win32_, предоставляют доступ к провайдерам информации об операционной системе. Для просмотра информации о классе дважды щелкните левой кнопкой мыши в правой панели на одной из записей Win3 2_* в списке.
Чтобы просмотреть содержимое хранилища CIM для определенного класса, выберите класс и щелкните на кнопке Instances (Экземпляры) — четвертая кнопка справа над правой панелью. В панели будет отображен результат универсального запроса, который можно описать как “Покажи мне все экземпляры этого класса и все их атрибуты". Заголовки столбцов можно использовать для создания собственного запроса.
Настройка фильтров WMI
3 Windows Management Instrumentation (WMI) CIM Studio - Microsoft Internet Explorer3 Windows Management Instrumentation (WMI) CIM Studio - Microsoft Internet ExplorerФильтры WMI не могут применяться к отдельным элементам GPO. Например, нельзя использовать фильтрацию только в разделе Administrative Templates (Административные шаблоны) объекта GPO. Это значит, что фильтры WMI управляются, как свойства самого GPO. Необходимая последовательность действий приводится в процедуре 12.5.
3 Windows Management Instrumentation (WMI) CIM Studio - Microsoft Internet Explorer
3 Windows Management Instrumentation (WMI) CIM Studio - Microsoft Internet Explorer
Яв Е* Mew Favcrta» Те* Н*^
J # • S »i ' ‘ / Sw* ■ **■*• <#**> <ь > „ £2
C:\WMt\studio.Htm
WMI CIM Studio» ё ® ♦
> -0 - C1M_ReiatedStatitiic$® О Ю CIMJn$tafiedSo/(wa<eElemen<; □ И Wr>32_PnPDevice, -v<" aM_RoductPioductDependencyI® □ Й Wn32„ManagedSy$temEtementR8soi.^|^<И Win32_ProtocoBinding® О S V/in32_SecurilySettingAcce$s® 0 Q Wh32_Securfo/SettingGroup. CIM_ElementCapacily> -0 - C1M_ReiatedStatitiic$® О Ю CIMJn$tafiedSo/(wa<eElemen<; □ И Wr>32_PnPDevice, -v<" aM_RoductPioductDependencyI® □ Й Wn32„ManagedSy$temEtementR8soi.^|^<И Win32_ProtocoBinding® О S V/in32_SecurilySettingAcce$s® 0 Q Wh32_Securfo/SettingGroup. CIM_ElementCapacilyI j Hee < %id Share ^ И: SharedElement " ;®‘—CiassЦ_DERIVATION " «„DYNASTY 1 1«_GENUS"" ^„namespace W—PATHI j Hee < %id Share ^ И: SharedElement " ;®‘—CiassЦ_DERIVATION " «„DYNASTY 1 1«_GENUS"" ^„namespace W—PATHa._PROPERTY_COt S—RELPATH ' fSjf ccoiftda._PROPERTY_COt S—RELPATH ' fSjf ccoiftdЛивlate ref:Wn32_S <empty> ref:CIM_.Dire <enpty>^string Win32_ShareToDitecto(y array of tirini «6Й tiring-Win32_ShareToDiectofy$int321tiringR00T\aMV2^^4SERVER1V,QOT,OMV2.V|ttint322tiringWin32_ShareToDirectofyetEhtCDiЛивlate ref:Wn32_S <empty> ref:CIM_.Dire <enpty>^string Win32_ShareToDitecto(y array of tirini «6Й tiring-Win32_ShareToDiectofy$int321tiringR00T\aMV2^^4SERVER1V,QOT,OMV2.V|ttint322tiringWin32_ShareToDirectofyetEhtCDi
> -0 - C1M_ReiatedStatitiic$
® О Ю CIMJn$tafiedSo/(wa<eElemen<
; □ И Wr>32_PnPDevice, -
v<" aM_RoductPioductDependencyI
® □ Й Wn32„ManagedSy$temEtementR8soi.^|^<
И Win32_ProtocoBinding
® О S V/in32_SecurilySettingAcce$s
® 0 Q Wh32_Securfo/SettingGroup
. CIM_ElementCapacily
> -0 - C1M_ReiatedStatitiic$
® О Ю CIMJn$tafiedSo/(wa<eElemen<
; □ И Wr>32_PnPDevice, -
v<" aM_RoductPioductDependencyI
® □ Й Wn32„ManagedSy$temEtementR8soi.^|^<
И Win32_ProtocoBinding
® О S V/in32_SecurilySettingAcce$s
® 0 Q Wh32_Securfo/SettingGroup
. CIM_ElementCapacily
I j Hee < %id Share ^ И: SharedElement " ;®‘—Ciass
Ц_DERIVATION " «„DYNASTY 1 1«_GENUS"" ^„namespace W—PATH
I j Hee < %id Share ^ И: SharedElement " ;®‘—Ciass
Ц_DERIVATION " «„DYNASTY 1 1«_GENUS"" ^„namespace W—PATH
a._PROPERTY_COt S—RELPATH ' fSjf ccoiftd
a._PROPERTY_COt S—RELPATH ' fSjf ccoiftd
Ливlate ref:Wn32_S <empty> ref:CIM_.Dire <enpty>^
string Win32_ShareToDitecto(y array of tirini «6Й tiring-Win32_ShareToDiectofy
$int321
tiringR00T\aMV2
^^4SERVER1V,QOT,OMV2.V|t
tint322
tiringWin32_ShareToDirectofy
etEhtCDi
Ливlate ref:Wn32_S <empty> ref:CIM_.Dire <enpty>^
string Win32_ShareToDitecto(y array of tirini «6Й tiring-Win32_ShareToDiectofy
$int321
tiringR00T\aMV2
^^4SERVER1V,QOT,OMV2.V|t
tint322
tiringWin32_ShareToDirectofy
etEhtCDi
■^Doi* ''”"f "| j'"l^WrSewtir /
Puc. 12.15. Интерфейс CIM Studio
Процедура 12.5. Доступ к интерфейсу фильтров WMI
Откройте окно Properties (Свойства) интересующего GPO.
Перейдите на вкладку WMI Filter (Фильтр WMI), которая показана на рис. 12.16.
Выберите переключатель This Filter (Этот фильтр) и щелкните на кнопке Browse/Manage (Обзор и управление). Откроется окно Manage WMI Filters (Управление фильтрами WMI).
Щелкните на кнопке Advanced (Дополнительно). Откроется окно Edit Filter (Изменить фильтр), как показано на рис. 12.17.
Введите оператор WQL, чтобы определить перечень компьютеров или пользователей, для которых будут применяться параметры политики в объекте GPO.
Щелкните на кнопке Save (Сохранить) для сохранения оператора WQL и щелкните на кнопке ОК для сохранения фильтра.
Проверьте работу фильтра, зарегистрировавшись с компьютера, соответствующего требованиям фильтра. Необходимо убедиться, что политика применяется на таком компьютере.
Рис. 12.16. Вкладка WMI Filter (Фильтр WMI) свойств GPO
Рис. 12.17. В окне Edit Filter (Изменить фильтр) отображаются дополнительные параметры для управления фильтром WMI
Для произвольного GPO можно указать только один фильтр WMI. Фильтр может быть любой сложности, но помните, что клиент должен выполнить оператор до полного завершения. Добавление слишком большого количества критериев выбор» в оператор может отрицательно сказаться на времени регистрации клиента.
Хранилище фильтров WMI
Фильтры WMI хранятся в базе данных Active Directory в виде объектов MS-WMI-SOM. Аббревиатура SOM расшифровывается как Scope of Management (Область действия обслуживания). Объекты фильтров хранятся в контейнере SOM с характерным именем cn=SOM, cn=WMIPolicy, cn=System,6с=<имя_домена>, Зс=<корень>.
Ниже приведен фрагмент списка атрибутов объекта фильтра, в котором показаны атрибуты хранения и управления фильтром:
cn: {C3BB1D85-D674-4568-B3BD-BBD4C6EC5A4D};
msWMI-Author: Administrator;
msWMI-ID: {C3BB1D85-D674-4568-83BD-BBD4C6EC5A4D};
ms WMI-Name: Phx-Filter-1;
smWMI-Parml: Computers with CPUs faster than 600 MHz; msWMI-Parm2: 1;3;10;60;WQL;root\cimv2;
^ select * from Win32_Processor where currentclockspeed > 600;
Рассмотрим наиболее интересные элементы списка.
В атрибуте MSWMI-Author хранится имя пользователя, который создал фильтр. Помните об этом, если не можете проанализировать фильтр и хотите понять, что имел в виду автор.
В атрибуте MSWMI - ID хранится имя фильтра. Для обеспечения уникальности имен имя формируется с помощью алгоритма создания GUID.
В атрибуте MSWMI -Name хранится дружественное имя фильтра.
В атрибуте MSWMI-Parml хранится описание фильтра.
В атрибуте MSWMI - Parm2 хранится оператор языка запросов для фильтра.
Делегирование управления политиками
Одной из ключевых особенностей Active Directory является возможность точной настройки административных прав. Например, можно создать организационную единицу для конкретного набора пользователей и групп и делегировать административные права для этой организационной единицы локальному администратору или опытному пользователю.
Делегирование возможности создания объектов групповых политик (GPO) и управления ими оказывается немного более сложным, чем делегирование возможности управления пользователями, компьютерами или совместно используемыми принтерами. Двойственный характер объекта GPO (состоящего из контейнера GPC и шаблона GPT) означает, что локальному администратору необходимо иметь две привилегии:
привилегию создавать и изменять файлы в каталоге Sysvol на контроллере домена;
возможность создавать новый объект групповой политики в базе данных Active Directory.
Эти привилегии по умолчанию пользователям не предоставляются. Их необходимо предоставлять отдельно.
Предоставление прав доступа к GPT
Шаблоны групповой политики (GPT) хранятся в файлах каталога политики в каталоге Sysvol. Предоставление прав доступа к этим файлам подразумевает установку разрешений NTFS для каталога \Sysvol\Sysvol\<HMs^oMeHa>\Policies.
На самом деле этот каталог является точкой функционального монтирования (reparse point), связанной с каталогом \Sysvol\Domain\Policies, поэтому разрешения можно устанавливать для любого из этих двух каталогов.
Начните с создания группы для локальных администраторов. Затем назначьте этой группе разрешения на чтение, запись, создание и изменение для каталога Policies.
С другой стороны, если локальным администраторам необходимо управлять существующими объектами GPO, но не требуется их создавать, можно сначала создать GPO, после чего предоставить доступ к каталогу политики.
Новые разрешения NTFS приводят к изменениям в каталогах, которые реплицируются на другие контроллеры домена средствами службы репликации файлов.
Предоставление прав доступа к GPC
После установки прав доступа к шаблонам групповых политик (GPT) предоставьте группе администраторов разрешения на создание GPO. Для этого добавьте администраторов в группу Group Policy Creator Owners. Эта группа имеет право создавать и изменять объекты в контейнере Policies в базе данных Active Directory: cn=Policies, cn=System, йс=<и№_домеиа>, дс=<корень>.
Если группе администраторов не был предоставлен полный доступ к организационной единице, придется делегировать группе разрешение Create Link (Создавать ссылку) для организационной единицы.',
Управление отдельными типами групповых политик
Теперь, когда были показаны методы распространения различных групповых политик, а также методы их загрузки и применения, рассмотрим использование конкретных типов групповых политик.
В этом разделе рассматриваются механизмы реализации и устранения неисправностей в работе различных типов политик. Дополнительная информация приводится в следующих главах.
Дополнительная информация о перенаправлении каталогов и управлении средой пользователя приводится в главе 19, “Управление операционной средой пользователя”.
Дополнительную информацию об использовании политик безопасности можно получить в главе 11, “Безопасность доступа по сети и протокол Kerberos”.
В главе 17, “Управление шифрованием файлов”, и главе 18, “Управление инфраструктурой открытого ключа”, содержится дополнительная информация о политиках шифрованной файловой системы, инфраструктуры открытого ключа и политиках IPSec.
В главе 2, “Модернизация и автоматизированная установка”, подробно рассматривается использование политик служб удаленного доступа для управления мастером установки клиентов (Client Installation Master).
Политики управления Internet Explorer в данной книге не рассматриваются.
Политики безопасности
Ранее в этой главе рассматривались особенности развертывания групповых политик безопасности в пределах домена. В этом разделе показано, как работает механизм развертывания групповых политик и как настраивать систему безопасности без использования групповых политик.
На компьютерах под управлением операционных систем Windows Server 2003, Windows ХР и Windows 2000 параметры безопасности хранятся в локальной базе данных Secedit. sdb. Эта база данных находится в каталоге \Windows\Security\Database. Групповые политики безопасности реализовываются с помощью изменения значений в базе данных Secedit. sdb.
Кроме записей, в базе данных Secedit. sdb политики безопасности могут менять права доступа к файлам и каталогам файловой системы NTFS, разделам системного реестра и локальным службам.
Файлы шаблонов групповых политик безопасности
При создании параметра политики безопасности в GPO средствами редактора групповых политик (Group Policy Editor) редактор сохраняет параметры в файле шаблона групповой политики (GPT), GptTmpl. inf.
Клиенты, к которым относится GPO, загружают файл GptTmpl. inf и копируют его в локальный каталог \Windows\Security\Templates\Policy. Если на клиент оказывают действие несколько объектов GPO с параметрами безопасности, он копирует все файлы GptTmpl. inf, добавляя порядковые номера в имя файла с расширением . inf. Последовательность номеров совпадает с иерархией приоритета объекта групповой политики. Единственное исключение составляет политика Default Domain, которая получает специальное расширение .dom.
При регистрации пользователя процесс Winlogon извлекает содержимое файлов . dom и . inf и заносит полученные параметры в базу данных системы безопасности локального компьютера и в системный реестр. Результаты этой транзакции можно увидеть в файле Winlogon. log в каталоге \windows\Security\Log. Политики безопасности вступают в силу сразу после загрузки.
Кроме этого, локальные клиенты загружают изменения политик безопасности при каждом обновлении групповых политик. Обновление выполняется с периодичностью от 90 до 120 минут для обычных компьютеров и каждые 5 минут для контроллеров домена. Дополнительное обновление политик безопасности выполняется каждые 16 часов. При стандартном фоновом обновлении загружаются только политики, в которые были внесены обновления. При обновлении каждые 16 часов загружаются все политики безопасности независимо от наличия изменений.
Специальная обработка политик учетных записей
Такие политики учетных записей, как политики паролей, политики блокирования учетных записей и политики Kerberos, могут устанавливаться только в объекте групповой политики Default Domain. Эти политики доступны и в других объектах групповых политик, но их установка ни на что не влияет.
Для просмотра политик безопасности, применяемых на локальном сервере, запустите консоль Local Security Settings (Локальная политика безопасности), воспользовавшись командой Starts Programs ^Administrative Tools^Local Security Policy (Пуск1* Программы ^Администрирование^ Локальная политика безопасности). На рис. 12.18 показан пример локальных политик безопасности для сервера, входящего в домен.
Просматривая параметры политики, можно обратить внимание, что для обозначения одних из них используется пиктограмма с небольшими синими символами, а для других — пиктограмма в виде изображения сервера с небольшим рулоном бумаги. Пиктограммы второго типа указывают, что параметр политики получен вместе с групповой политикой. Пиктограммы первого типа указывают, что параметр получен из локальной базы данных системы безопасности.
Принятые по умолчанию шаблоны безопасности
Групповые политики являются идеальным инструментом для управления параметрами безопасности на контроллерах домена и компьютерах, входящих в домен. Но параметры безопасности можно менять и непосредственно с помощью утилиты Secedit. Утилита Secedit исполь-
зует файл шаблона для предоставления параметров, заносимых в базу данных Secedit. sdb, и другие объекты системы безопасности.
Reset account lockout counter after Not AppkableReset account lockout counter after Not AppkableAccount lockout durationAccount lockout thresholdAccount lockout durationAccount lockout thresholdNotAppkable 0 hvalti logon attemptsNotAppkable 0 hvalti logon attemptsСуществует два набора шаблонов безопасности. Первый набор хранится в каталоге \Windows\lNF. Система использует эти шаблоны для значительных изменений параметров безопасности при изменении роли сервера. Ниже перечислены эти шаблоны и их назначение.
Reset account lockout counter after Not Appkable
Reset account lockout counter after Not Appkable
Account lockout duration
Account lockout threshold
Account lockout duration
Account lockout threshold
NotAppkable 0 hvalti logon attempts
NotAppkable 0 hvalti logon attempts
и ^ toed Computer Poky
■ H 0 Computer Configuration @ . 1 Software Settings
.a C3 Windows Settings
; Scripts (Startup/Shutdown)
;. В -у Security Settings
Я £9 Account Pokies
:- ® @9 Password Poky
. s £l Local Pokes ’1
S Q9 Audi Poky|
:ГЭ User Rights AssignmentI
•S- £9 Security Options|
'EflCJPubk Key PokiesI
:®JjSoftware Restriction Pokies :|
..SIP Security Pokies on Local Computi]
® (^ Administrative Templates
S User Configuration S- -^) Software Settings * '* I Windows Satinas
11X .«^.Фм.
Puc. 12.18. Консоль Local Security Settings (Локальная политика безопасности ) для сервера в домене
DEFLTSV.INF. Применяется при первой установке сервера.
DEFLTDC.INF. Применяется при повышении сервера до контроллера домена.
DSUP.INF. Применяется при модернизации сервера с операционной системой Windows NT 4.0 или Windows 2000.■
DCUP5.INF. Применяется при модернизации контроллера домена под управлением операционной системы Windows 2000.
DSUPT.INF. Применяется при модернизации сервера под управлением операционной системы Windows NT 4.0 Terminal Server или сервера под управлением операционной системы Windows 2000, работающего в режиме приложений.
DCFIRST.INF. Применяется на сервере, который первым повышается до контроллера домена в пределах домена. В этом шаблоне присутствуют специальные политики Kerberos, политики учетных записей, группы с ограниченными привилегиями и информация о членстве в группах.
Специальные шаблоны безопасности
Кроме шаблонов безопасности, которые применяются во время процедуры установки и повышения до контроллера домена, существуют дополнительные шаблоны безопасности, которые хранятся в каталоге \Windows\Security\Templates. Эти шаблоны содержат предварительно созданные параметры простой, безопасной и “сверхбезопасной” конфигурации серверов, рабочих станций и контроллеров домена. Кроме этого, присутствует пакет для удаления группы Terminal Server User из разрешений файловой системы NTFS на сервере.
Совет по использованию системного реестра: текущий файл шаблона
Имя шаблона безопасности, который применяется программой установки или вручную добавляется в базу данных Secedit, хранится в записи системного реестра HKLMXSoftwareX MicrosoftXWindows NT\CurrentVersion\Secedit\TemplateUsed .
Предварительно созданные шаблоны безопасности можно использовать для анализа параметров системы и модернйзации системы с использованием новых параметров безопасности. Обычно это требуется только при управлении изолированным сервером. Контроллером домена необходимо управлять с использованием групповых политик.
Оснастка Security Configuration and Analysis
(Анализ и настройка безопасности)
Эта оснастка ММС позволяет сравнить текущие локальные параметры безопасности с содержимым шаблона безопасности. Также эту оснастку можно использовать для применения параметров из шаблона безопасности.
Для использования оснастки необходимо создать собственную консоль ММС. После создания консоли необходимо загрузить шаблон безопасности и использовать его в качестве эталона для сравнения с текущими параметрами безопасности. Любое обнаруженное отличие должно привлечь внимание администратора и быть выделено большой пиктограммой красного цвета (рис. 12.19). Если параметры из шаблона безопасности вас полностью устраивают, их можно применить на данном компьютере. Необходимая последовательность действий приводится в процедуре 12.6.
Рис. 12.19. Консоль Security Configuration and Analysis (Анализ и настройка безопасности), на которой выделены обнаруженные различия между конфигурацией в шаблоне безопасности и текущей конфигурацией компьютера
Процедура 12.6. Использование оснастки Security Configuration and Analysis
(Анализ и настройка безопасности)
Откройте консоль ММС с помощью команды mmc в окне Run (Выполнить).
В меню консоли выберите Console^Add/Remove Snap-in (Консоль^Добавить/удалить оснастку). Откроется окно Add/Remove Snap-in (Добавить/удалить оснастку).
Щелкните на кнопке Add (Добавить). Откроется окно Add Standalone Snap-in (Добавить изолированную оснастку).
Выберите оснастки Security Configuration and Analysis (Анализ и настройка безопасности) и Security Templates (Шаблоны безопасности).
Закройте окно, чтобы вернуться в окно Add/Remove Snap-in (Добавить/удалить оснастку). В списке появятся две оснастки без расширений.
Щелкните на кнопке ОК, чтобы сохранить выбранные элементы и вернуться на консоль ММС.
Выберите Console^Save As (Консоль^Сохранить как) и сохраните консоль под легко запоминаемым именем, например Security Analysis .msc.
Разверните дерево обеих оснасток. В разделе Security Templates (Шаблоны безопасности) будет отображен список шаблонов безопасности из каталога \Windows\Security\Templates.
В разделе Security Configuration and Analysis (Анализ и настройка безопасности) будет отображен набор команд для выполнения анализа.
Раскройте раздел для одного из шаблонов и просмотрите параметры в разделах Account Policies (Политики учетных записей) и Local Policies (Локальные политики). Параметры шаблона можно изменить, чтобы они больше соответствовали реальной ситуации на локальном компьютере. Результат изменений лучше сохранить в виде нового шаблона.
Щелкните правой кнопкой мыши на пиктограмме Security Configuration and Analysis (Анализ и настройка безопасности) и выберите из контекстного меню команду Open Database (Открыть базу данных). Откроется окно Open Database (Открыть базу данных).
Введите имя базы данных, в которой будет храниться результат анализа. Не пытайтесь открыть существующую базу данных Secedit.sdb. Если попытаться это сделать, будет выдано сообщение об отказе в доступе (access denied).
Щелкните правой кнопкой мыши на пиктограмме Security Configuration and Analysis (Анализ и настройка безопасности) и выберите из контекстного меню команду Analyze Computer Now (Анализ компьютера). Откроется окно Perform Analysis (Выполнить анализ), в котором указан каталог для хранения журнала анализа.
Щелкните на кнопке ОК. После завершения анализа раскройте раздел Security Configuration and Analysis (Анализ и настройка безопасности), чтобы просмотреть параметры безопасности. Каждое отличие между локальными параметрами и параметрами шаблона безопасности выделяется пиктограммой красного цвета.
Распространение шаблонов безопасности
Если используются изолированные серверы, например серверы в демилитаризованной зоне, серверы приложений, работающие за пределами домена, или серверы под управлением Windows Server 2003, входящие в состав домена Windows NT, обновления безопасности для этих компьютеров можно распространять с помощью шаблонов безопасности и утилиты Secedit.
Для утилиты Secedit предусмотрено четыре режима работы, каждый из которых включается с помощью соответствующего параметра командной строки.
Analyze (Анализ). Утилита сравнивает существующие параметры безопасности с файлом шаблона и записывает результат в указанную базу данных SDB и файл журнала. Команда выглядит следующим образом: secedit /analyze /db somename.sdb /cfg template.inf /log 'b somename. log
Configure (Настройка). Обновляет существующие параметры безопасности, используя содержимое файла шаблона безопасности. Можно выбрать определенные разделы шаблона вместо всего содержимого. Результат операции сохраняется в указанной базе данных.
Предупреждение. Применение шаблона безопасности может или снизить уровень безопасности до неприемлемого уровня, или заблокировать компьютер вплоть до полной невозможности получить доступ. Используйте этот параметр с осторожностью. Пример команды показан ниже:
secedit /configure /db somename.sdb /cfg template.inf /log 'b somename.log /area areal area2
Export (Экспорт). Извлекает текущие параметры безопасности и записывает их в файл шаблона. Эта операция полезна при настройке группы серверов с одинаковыми параметрами безопасности. Настройте параметры одного компьютера и скопируйте параметры в шаблон безопасности для распространения шаблона с помощью утилиты Secedit. Команда выглядит следующим образом:
secedit /export /cfg template.inf /log somename.log
Validate (Оценить). Извлекает содержимое шаблона и проверяет правильность синтаксиса для импорта. Пример команды показан ниже: secedit /validate template.inf
Утилиту Sec edit можно использовать для установки файлов шаблонов на компьютерах под управлением Windows Server 2003 в классическом домене Windows NT 4.0. Для этого файл Secedit. ехе и шаблон безопасности необходимо разместить на общем ресурсе Netlogon каждого контроллера домена и добавить в регистрационный сценарий строку для применения шаблона безопасности. Удостоверьтесь, что регистрационный сценарий применяет шаблон безопасности только на серверах под управлением операционной системы Windows Server 2003. (Можно создать несколько шаблонов и при помощи ветвления в регистрационном сценарии выбирать подходящую платформу, но такую функциональную возможность достаточно сложно реализовать в стандартных файлах пакетной обработки.)
Резюме о политиках безопасности
Вот основные моменты применения политик безопасности на локальных компьютерах.
Политики безопасности для локального компьютера хранятся в базе данных Security Editor, \Windows\Security\Database\Secedit.sdb.
Групповые политики безопасности загружаются всегда, независимо от скорости соединения. ■ Такие политики учетных записей, как история паролей, сложность пароля, политики блокирования и т.д., должны определяться в политике Default Domain и не могут быть изменены в других групповых политиках.
Локальные политики безопасности применяются в процессе установки и в процессе повышения до контроллера домена. Для этого используются шаблоны безопасности из каталога \Windows\INF.
Локальные политики безопасности могут быть изменены с помощью утилиты Secedit благодаря применению шаблонов безопасности из каталога \windows\Secur ity\Templates.
Политики административных шаблонов
Самым очевидным применением административных шаблонов является внесение изменений в системный реестр одновременно на сотнях и тысячах компьютеров. До этого уже было показано большинство механизмов создания и изменения политик административных шаблонов. Вот краткое описание принципов работы административных шаблонов.
В редакторе групповой политики (GPE) параметры административных шаблонов выводятся на основе файлов шаблонов ADM. Файлы ADM хранятся в каталоге \ Windows \ INF.
■ ■ При включении или отключении политик административных шаблонов GPE создает запись в файле GPT, который называется Registry.pol. Этот файл хранится в каталоге политики в подкаталоге Sysvol. Для каждой политики существует два файла Registry. pol: один в каталоге Machine, где хранятся политики раздела Computer -Configuration (Конфигурация компьютера), и один в каталоге User, где хранятся политики раздела User Configuration (Конфигурация пользователя).
Клиенты, связанные с объектом групповой политики, который содержит административные шаблоны, загружают файлы Registry. pol и вносят их содержимое в специальные разделы системного реестра Policies.
Настроенные на поиск параметров в разделах Policies приложения в своей работе зависят от содержимого групповой политики.
Рассмотрим эти процессы более подробно. Желательно полностью понять принципы обработки административных шаблонов. Большинство возможностей распределенного управления в операционной системе Windows Server 2003 в том или ином виде основано на политиках системного реестра.
Специальные разделы системного реестра
для использования политик
Политики административных шаблонов в файле Registry.pol записываются в специальные разделы системного реестра, предназначенные для хранения временных записей групповых политик. Такие политики хранятся в четырех разделах. Политики из раздела Computer Configuration (Конфигурация компьютера) записываются в раздел системного реестра HKLM, а политики из раздела User Configuration (Конфигурация пользователя) записываются в раздел нкси."
HKLMXSoftwareXPolicies
HKLMXSoftwareXMicrosoft\Windows\CurrentVersion\Policies
HKCUXSoftwareXPolicies
HKCUXSoftwareXMicrosoft\Windows\CurrentVersion\Policies.
Записи в этих разделах обновляются каждый раз при загрузке компьютера или при регистрации пользователя. Если из объекта групповой политики (GPO) удалить административный шаблон или разорвать связь с GPO, содержащим административные шаблоны, записи будут удалены из локального системного реестра клиента. Это позволяет устранить недостаток, характерный для классических системных политик Windows NT, когда в системном реестре навсегда сохранялись внесенные изменения.
Постоянное хранение внесенных изменений и классические системные политики
Рассмотрим пример постоянного хранения изменений. При использовании классических системных политик Windows NT можно определить фоновое изображение рабочего стола для группы пользователей. Если внести пользователя в такую группу, политика будет внесена в раздел системного реестра нкси и выбор фонового изображения вступит в силу.
Если удалить пользователя из такой группы, выбор фонового изображения останется в силе на рабочей станции пользователя. Для удаления фонового изображения придется вручную внести изменения на рабочей станции или определить другую группу с системной политикой, удаляющей фоновое изображение. Во втором случае пользователя придется включить в новую группу.
При использовании групповых политик такая ситуация решается значительно проще. Сначала определяется политика для фонового изображения. С этой целью создается объект группо-
вой политики с политикой административного шаблона, который называется Active Desktop wallpaper, в разделе User Configuration^Administrative Templates^Desktop1*Active Desktop (Конфигурация пользователя^Административные шаблоны^Рабочий cron^Active Desktop). Этот GPO необходимо связать с организационной единицей, в которую входят учетные записи пользователей. После этого все пользователи получат одинаковое фоновое изображение на рабочем столе.
При удалении пользователя из организационной единицы параметр политики удаляется и используется оригинальное фоновое изображение, которое использовалось до назначения групповой политики ("статус-кво", как говорят в Вашингтоне).
Политики и предпочтения
Гибкость и непостоянство основанных на системном реестре групповых политик делают их привлекательным инструментом, но есть одна особенность, которую стоит запомнить. Такие политики работают только в том случае, если приложения запрограммированы на использование соответствующих записей в системном реестре. Другими словами, управление приложением XYZ с помощью групповых политик невозможно, если приложение XYZ не знает, что нужно просматривать один из разделов Policies в системном реестре для получения параметров.
Групповые политики можно использовать для изменения параметров в системном реестре за пределами разделов Policies. В таком случае будут внесены постоянные изменения, как при использовании классических системных политик Windows NT. Компания Microsoft называет такие постоянные изменения системного реестра предпочтениями (preferences). Они отличаются от политик (policies), которые могут свободно добавляться в системный реестр и удаляться из него.
Политики оказываются намного гибче и проще в управлении, чем предпочтения, но если нужно управлять устаревшими приложениями, изменения в системный реестр приходится вносить с помощью предпочтений. Далее будет показано, как создавать предпочтения, но сначала рассмотрим, как с помощью редактора групповых политик создавать стандартные политики.
Файлы шаблонов ADM
Политики административных шаблонов получили такое название из-за того, что параметры извлекаются из текстовых файлов шаблонов ADM. Это напоминает классические системные политики Windows NT, но структура файлов ADM и их использование значительно отличаются.
Файлы шаблонов ADM хранятся в каталоге \Windows\INF. Редактор групповых политик по умолчанию загружает четыре таких файла.
System.adm. В этом файле содержится полный список параметров политик для управления большинством возможностей Explorer (Проводник).
Inetres.adm. Политики Internet Explorer, которые оказывают влияние на такие компоненты, как Internet Explorer, Control Panel (Панель управления), автономные страницы, меню браузера, Persistence Behavior и Administrator Approved Controls.
Conf.adm. Политики NetMeeting.
Wmplayer.adm. Политики Windows Media Player.
Устаревшие шаблоны
Кроме стандартных шаблонов ADM, в составе операционной системы Windows Server 2003 предоставляются дополнительные шаблоны для обратной совместимости с классическими системными политиками Windows NT. За одним исключением такие шаблоны ADM не могут
загружаться в редактор групповых политик. Для доступа к таким шаблонам (кроме шаблона Inetset. adm) необходимо воспользоваться редактором системных политик (System Policy Editor или Poledit). Ниже перечислены доступные шаблоны для обратной совместимости.
Inetset.adm. В этом шаблоне содержатся предпочтения для управления параметрами Internet Explorer (дополнительную информацию о предпочтениях можно получить в предыдущем разделе).
Inetcorp.adm. В этом файле содержатся системные политики, которые управляют языками Internet Explorer, ограничениями коммутируемого доступа и кэшированием.
Winnt.adm. Системные политики для операционной системы Windows NT 4.0.
Windows.amd. Системные политики для операционных систем Windows 9х.
Common.adm. Системные политики, общие для параметров операционных систем Windows NT 4.0 и Windows 9х.
Загрузка дополнительных шаблонов ADM
Купив приложение, в котором используются временные групповые политики, например Office 2003 или Office ХР, в редактор групповых политик можно загружать шаблоны ADM, как описано в процедуре 12.7.-
Процедура 12.7. Загрузка шаблонов ADM в редактор групповых политик
Откройте редактор групповых политик для объекта групповой политики, в который следует добавить дополнительные шаблоны.
Раскройте подраздел Administrative Templates (Административные шаблоны) в разделе Computer Configuration (Конфигурация компьютера) или в разделе User Configuration (Конфигурация пользователя) — разница не существенна.
Щелкните правой кнопкой мыши на пиктограмме Administrative Templates (Административные шаблоны) и выберите из контекстного меню команду Add/Remove Templates (Добавление и удаление шаблонов).'
Щелкните на кнопке Add (Добавить). Откроется список шаблонов, хранящихся в каталоге \Windows\INF.
Найдите каталог, в котором хранятся нужные шаблоны, и выберите интересующий шаблон.
Закройте окно Add/Remove Templates (Добавление/удаление шаблонов), чтобы загрузить выбранный шаблон. (Выбор шаблона сохраняется в параметрах консоли ММС, поэтому шаблон будет открыт при следующем запуске консоли.)
Убедитесь, что политики загруженного шаблона доступны для просмотра. Если используется некорректный формат шаблона, то в процессе загрузки будет выдано сообщение об ошибке.
Если шаблон содержит только классические системные политики без инструкций по обработке, он будет расположен в разделе внешних политик и содержимое политик окажется недоступным.
Редактор системных политик Poledit и операционная система
Windows Server 2003
В составе операционной системы Windows Server 2003 предоставляется редактор системных политик Poledit, который можно использовать для создания файлов Config.pol и Ntconfig. pol для клиентов более старых версий Windows и управления ими.
Сохраните файлы с расширением .pol в каталоге \Windows\Sysvol\Sysvol\<имя_домена>\ Scripts. Этот каталог предоставляется для совместного доступа под именем Netlogon.
Современные клиенты Windows (Windows Server 2003, Windows XP и Windows 2000), входящие в домен Windows NT 4.0, будут загружать и применять системные политики. Как только домен будет модернизирован до Windows Server 2003 или Windows 2000, все современные клиенты Windows прекратят использование системных политик и перейдут к использованию групповых политик.
Групповые и системные политики
Пользователи и компьютеры под управлением операционной системы Windows Server 2003 обрабатывают классические системные политики только в том случае, если групповые политики Active Directory недоступны. Рассмотрим несколько примеров.
Пользователь в домене Active Directory регистрируется на компьютере под управлением Windows Server 2003, который также входит в домен Active Directory. Системные политики не обрабатываются.
Пользователь в домене Active Directory регистрируется на компьютере под управлением Windows Server 2003, который входит в домен Windows NT 4.0: система обрабатывает политики компьютера из файла Ntconf ig.pol.
Пользователь в домене Windows NT 4.0 регистрируется на компьютере Windows Server 2003, который входит в домен Active Directory: система обрабатывает политики пользователя ИЗ файла Ntconfig.pol.
Файлы Registry.pol
После того, как администратор включает параметры политик административных шаблонов в редакторе групповых политик (GPE), редактор GPE извлекает параметры политик из шаблона ADM и использует их для создания записей в файле Registry.pol. Это текстовый файл в кодировке Unicode.
Редактор групповой политики предоставляет три альтернативных значения групповой политики: Enabled (Включена), Disabled (Отключена) и Not Configured (Не установлена). Вот что редактор групповой политики записывает в файл Regi stry. pdl в зависимости от значения политики.
Enabled (Включена). Редактор групповых политик (GPE) извлекает содержимое соответствующего файла шаблона . adm и на его основе создает запись в файле Registry.pol. Например, при включении политики Hide Му Network Places (Скрывать Мое сетевое окружение) GPE добавляет следующую запись в файл Registry. pol:
[Software\Microsoft\Windows\CurrentVersion\Policies\Explorer 'Ъ ;NoNetHood ; ; ; ]
Disabled (Отключена). Редактор GPE добавляет в файл Registry.pol запись, которая отключает фрагмент файла ADM. Например, при отключении политики Hide Му Network Places (Скрывать Мое сетевое окружение) редактор добавляет следующую запись в файл Registry.pol:
[Software\Microsoft\Windows\CurrentVersion\Policies\Explorer 9> ;**del.NoNetHood ; ; ;]
Not Configured (He установлена). Редактор GPE удаляет из файла Registry.pol все записи, связанные с листингом. Это не оказывает влияния на другие файлы Registry.pol, поэтому, если запись внесена в другой объект групповой политики, политика будет применяться.
При загрузке клиентом файла Registry.pol записи вносятся во временный раздел Policies, указанный в шаблоне. Эта операция выполняется расширением на стороне клиента Userenv. dl 1 и не требует вмешательства администратора.
Подробное описание записей в файлах ADM
Листинги групповых политик ADM предназначены для занесения во временные разделы системного реестра Policies. Рассмотрим фрагмент файла System, a dm, чтобы продемонстрировать, как это работает:
CLASS USER
CATEGORY !!Desktop
KEYNAME "Software\Microsoft\Windows\CurrentVersion\Policies\
^ Explorer"
POLICY !'NoNetHood
#if version >= 4
SUPPORTED !!SUPPORTED_Win2k
#endif
EXPLAIN !!NoNetHood_Help
VALUENAME "NoNetHood"
END POLICY
END CATEGORY
[strings]
Desktop="Desktop"
NoNetHood="Hide My Network Places icon on desktop"
NoNetHood_Help="removes the My Network Places icon from the desktop.
'b \n\n Этот параметр влияет только на пиктограмму. Он не позволяет
'Ъ заблокировать пользователям доступ в сеть или доступ к совместно используемым сетевым ресурсам."
SUPPORTED_Win2k="At least Microsoft Windows 2000"
Чтобы упростить чтение шаблонов ADM, компания Microsoft активно использует ярлыки строк (string token). Если возле слова присутствует строка из двух восклицательных знаков (!!), можно сделать вывод, что это ярлык строки. В каждом файле ADM присутствует список ярлыков строк и полных версий этих строк, для которых созданы ярлыки.
Ниже приведено краткое описание различных элементов содержимого файла ADM.
■ CLASS USER. Указывает на фрагменты кода, которые отображаются как подразделы в разделе User Configuration (Конфигурация пользователя) в редакторе групповой политики.
■ CATEGORY. Указывает на фрагменты кода, которые отображаются как подразделы раздела, обозначенного ярлыком строки. В этом случае ярлык ! ! Desktop “разворачивается" в слово Desktop.
■ KEYNAME. Указывает на фрагменты кода, которые превращаются в одноименные записи системного реестра. Отдельные листинги могут переопределять принятую по умолчанию запись KEYNAME. Обратите внимание, что в этом примере показана запись в одном из временных разделов системного реестра, Software\Microsoft\Windows\Currentversion\ Policies.
POLICY. Этот фрагмент кода отображается в редакторе групповых политик в разделе, идентифицированном ярлыком строки ! 'NoNetHood. Этот ярлык строки “разворачивается” в имя Hide Му Network Places icon on desktop.
SUPPORTED. Это новое ключевое слово Windows Server 2003, которое идентифицирует платформу, поддерживающую политику. Это ключевое слово используется фильтром GPE для отображения подмножества политик.
EXPLAIN. Этот ярлык содержит справочное сообщение, которое отображается вместе с политикой в редакторе групповой политики. Текст выводится на вкладке Explain (Описание) в окне политики и на панели консоли ММС в режиме Web-обозревателя. Ярлык строки ! !NoNetHood_Help “разворачивается” в полный текст описания.
VALUENAME. Этот ярлык содержит точное значение, которое будет записано в файл Registry.pol при активизации этого фрагмента кода. По умолчанию используется тип значения REG_SZ. Параметр NUMERIC= позволяет указать тип значения REGvDWORD или REG_BINARY.
При загрузке файла Registry.pol с этими записями расширение на стороне клиента запишет в системный реестр следующее:
I
Раздел: HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer Запись: NoNethood
После этого файла ADM пиктограмма My Network Places (Мое сетевое окружение) исчезнет с рабочего стола в операционной системе Windows Server 2003) и меню Start (Пуск) исчезнет в операционной системе Windows ХР. Помните, что это работает только из-за того, что программа Explorer запрограммирована на получение конкретной записи системного реестра при создании рабочего стола для пользователя. Explorer использует сотни записей в системном реестре, но с помощью политик можно установить всего несколько десятков таких записей.
Политики и предпочтения
Существует возможность создания собственных шаблонов ADM, которые будут записывать значения за пределами временных разделов Policies. Эти записи будут обработаны расширениями на стороне клиента точно так же, как обычные групповые политики, но результатом обработки станет запись в системном реестре.
Компания Microsoft использует термин предпочтение (preference) для описания групповой политики, которая вносит запись в системный реестр за пределами временных разделов Policies. В редакторе GPE предпочтение обозначается красной точкой на пиктограмме. Стандартные групповые политики обозначаются синей точкой.
Для просмотра предпочтений удобно загрузить шаблон inetres. adm. Этот шаблон содержит записи, которые вносятся за пределами временных разделов Policies. Содержимое шаблона отображается, как предпочтения с красной точкой на пиктограмме.
Иногда стандартные политики называют управляемыми (managed) политиками. По умолчанию редактор групповых политик отображает информацию только об управляемых политиках. Для отображения предпочтений щелкните правой кнопкой мыши на пиктограмме Administrative Templates (Административные шаблоны) и выберите из контекстного меню команду Filtering (Фильтрация). В окне Filtering (Фильтрация) сбросьте флажок Only Show Policy Settings That Can Be Fully Managed (Показывать только управляемые параметры политик) и сохраните внесенное изменение.
После этого можно будет просматривать предпочтения из шаблона Inetres. adm. Будут доступны следующие варианты.
Если активизировать (Enable) предпочтение, запись в файле Registry.pol содержит полный путь в системном реестре. Расширение на стороне клиента внесет запись непосредственно в системный реестр.
Если отключить (Disabled) предпочтение, запись в файле Registry.pol меняется, и к названию записи добавляется префикс **del. Расширение на стороне клиента удалит запись из системного реестра.
Если переключить предпочтение в состояние Not Configured (Не определено), в силе останется последняя запись, которая была добавлена в системный реестр.
Для удаления предпочтения его сначала нужно отключить, подождать, пока клиенты загрузят политику, после чего установить для предпочтения значение Not Configured (Не определено).
Создание собственного шаблона ADM
С помощью копирования существующего шаблона можно создавать собственные шаблоны ADM. Перед этим убедитесь, что политики уже не существует. Утилита Help and Support (Справка и поддержка) позволяет просмотреть все политики. В составе Resource Kit предоставляется файл справки по групповым политикам (Gp. chm), в котором политики перечислены в более удобной форме.
Помните, что создание шаблона, который добавляет запись в раздел Policies, оказывает влияние только на те приложения, которые запрограммированы на поиск параметров в этих разделах. В большинстве случаев все эти записи уже описаны в шаблонах ADM. Если создать шаблон, который добавляет запись за пределы временных разделов Policies, GPE создаст предпочтение с красной точкой на пиктограмме.
Политики распространения программного обеспечения]
Если верить шумихе торговой прессы, то XXI век является веком расцвета инструмента- I рия Application Service Provider (ASP). Даже если это правда, пройдет еще очень много вре- 1 мени, пока все приложения вашего предприятия станут использовать интерфейсы браузера. | До этого момента возможность предоставления необходимого программного обеспечения, 1 предназначенного для конкретного пользователя на конкретном компьютере и настроенного J соответствующим образом сразу после запуска, остается мечтой системных администраторов. 1
Развертывание программного обеспечения в операционной системе Windows Server 2003 | не совсем похоже на мечту, но эта технология все-таки лучше, чем хождение от одного рабо- | чего места к другому с пачкой компакт-дисков. В этом разделе рассматриваются механизмы | развертывания программного обеспечения в операционной системе Windows Server 2003, I а также требования к пакетам, предназначенным для развертывания.j
Шаблоны ADM могут быть неожиданно перезаписаныI
Каждый раз, когда редактор GPE открывает политику, он обновляет собственную локальную ] копию шаблонов ADM, используя главные шаблоны из каталога \windows\TNF. По этой при- I чине стоит избегать модификации существующих шаблонов. Вместо этого создавайте новые 1 шаблоны ADM и храните их в центральном хранилище, где к ним может получить доступ лк> 1 бой администратор, который вносит изменения в объекты групповых политик.я
Альтернативные инструменты развертывания программного обеспечения 1
Программное обеспечение на основе политик хорошо справляется с распространением фай- ■ лов, но не более того. При наличии сложных требований к развертыванию или необходимо- Я сти мониторинга и создания отчетов рекомендуется воспользоваться другими инструментами. я Ниже перечислены возможные решения.Я
System Management Server (SMS) от компании MicrosoftЯ
Tivoli от компании IBMЯ
ShipIT от компании Computer Associates■
Iя
|•Программные решения для развертывания предприятия InstallShieldя
f•Mobile AutomationI
Развертывание программного обеспечения
Как и большинство возможностей на основе политик, развертывание программного обеспечения зависит от целого ряда компонентов.
■ Служба Windows Installer. Эта служба распространяет содержимое пакета приложения и вносит в системный реестр соответствующие записи, необходимые для установки. Доступны версии службы для операционных систем Windows NT 4.0, Windows 9х и Windows ME, но для развертывания программного обеспечения на основе политик в операционной системе Windows Server 2003 необходимы клиенты, способные взаимодействовать с Active Directory. Развертывание программного обеспечения на клиентах более старых версий, например Windows 9х и Windows NT, не поддерживается.
■ Пакет установки Microsoft (Microsoft installer package — MSI). Установочный пакет, который состоит из файлов приложения, каталога файлов и инструкций, которые описывают процедуру установки для операционной системы Windows.
■ Пакет развертывания программного обеспечения (Software deployment package — AAS). Файл шаблона групповой политики, в котором указано расположение файла MSI и инструкции по его развертыванию: Объект Class Store в базе данных Active Directory содержит информацию о программном пакете.
■ Сервер развертывания. Это сервер, на котором хранятся пакеты MSI. Сервер не обязательно должен работать под управлением операционной системы Windows Server 2003 или другой операционной системы Windows, но на нем должен храниться совместно используемый каталог, к которому могут получать доступ клиенты, получающие политики развертывания программного обеспечения.
Кроме этого, развертываемое приложение должно предоставляться в виде файла MSI. (Устаревшее приложение можно упаковать в файл ZAP, который представляет собой пакетный файл, запускающий программу установки приложения.)
Служба Windows Installer
Служба Windows Installer выполняет следующие функции.
■ Проверяет версию каждого файла и подсчитывает ссылки на каждый файл, чтобы минимизировать проблемы, возникающие при перезаписи одной версии другой версией. Служба Installer работает совместно с функцией Side-by-Side (SxS) операционной системы Windows Server 2003.
Выполняет отложенную установку, ожидая, пока пользователь выберет приложение из меню Start (Пуск) или выполнит двойной щелчок на файле данных, связанном с приложением.
Поддерживает журнал транзакций установки, чтобы была возможность продолжить установку с момента останова. Также поддерживается возможность возврата к предыдущему состоянию даже в процессе процедуры установки. .
Поддерживает каталог установленных компонентов и изменений системного реестра, которые могут быть удалены вместе с приложением. Эта возможность поддерживает параметр групповой политики, который позволяет удалить приложение при удалении пользователя из области действия GPO с политикой распространения программного обеспечения.
Поддерживает самовосстанавливающиеся приложения, автоматически загружая компоненты, которые были случайно удалены или перезаписаны.
Может устанавливать приложения, используя расширенные права доступа. Это позволяет пользователям устанавливать приложения без привилегий локального администратора. (Мне показалось, или читатели вскричали “Слава Богу!”?)
Пакеты MSI
Основанное на политиках развертывание программного обеспечения зависит от службы Windows Installer, а служба Windows Installer требует упаковки приложений в файлы MSI.
Не обязательно интегрировать в файл MSI все компоненты приложения, но они должны быть доступны в хранилище, к которому служба Windows Installer может получить доступ, следуя инструкциям из файла MSI. Обычно это означает, что файлы и каталоги в пакете MSI должны находиться в стандартной конфигурации.
Часто установку пакетов MSI можно настраивать с помощью файлов Microsoft Transform (MST). Эти файлы предоставляют сценарии установки (scripted installation) базового пакета MSI. Например, Office Resource Kit (ORK) предоставляет утилиты для отображения окон процесса установки Office 2000 и Office ХР и сохранения выбранных параметров в файле MST.
Создание собственных пакетов для развертывания программного обеспечения
Любое приложение, получившее логотип Windows 2000 и Windows Server 2003, должно распространяться в пакете MSI. Этому требованию не соответствует большое количество приложений. Если необходимо развернуть 32-разрядное приложение Windows, которое не имеет пакета MSI, пакет можно создать самостоятельно с помощью нескольких утилит. Ниже показан список доступных утилит (в порядке возрастания стоимости, но не обязательно доступных возможностей).
Wininstall 2000. От компании Veritas, www.veritas.com. На установочном компакт- диске операционной системы Windows Server 2003 предоставляется урезанная версия программы Wininstall.
Wise Installer. От компании Wise Solutions, www. wisesolutions. com.
InstallShield Professional (Installer Edition). От компании InstallShield, www.instalIshield.com.
Расширение привилегий при установке программного обеспечения
Возможность службы Windows Installer устанавливать пакет MSI, используя расширение привилегий, решает основной вопрос, по которому пользователи обращаются в службу поддержки рабочих станций.
По умолчанию установка с расширением привилегий разрешена только при развертывании приложений с помощью групповых политик. Можно установить групповую политику, которая позволяет службе Windows Installer устанавливать все пакеты MSI с расширением привилегий. Это дает возможность использовать утилиты от сторонних производителей и даже вложения сообщений электронной почты для распространения программного обеспечения, которое будет установлено обычными пользователями.
Политика называется Always Install with Elevated Privileges (Всегда устанавливать с расширением привилегий) и хранится в разделе Computer Configuration^Administrative Templates ^Windows Components^Windows Installer (Конфигурация компьютера^Админист- ративные шаблоны^Компоненты Windows^Windows Installer).
Расширенные права доступа получает только поток процесса, который устанавливает программное обеспечение, поэтому не стоит беспокоиться, что пользователь получит дополнительные привилегии, "вломившись" в процедуру установки. Но включение этой политики действительно приводит к возможности установки "троянской" программы, которая маскируется под пакет MSI и пытается получить расширенные привилегии. Не активизируйте эту политику, не защитив все уязвимые места системы.
Пакет развертывания программного обеспечения
Файл шаблона групповой политики для пакета развертывания программного обеспечения предоставляется в виде двоичного файла и имеет расширение . aas. Этот файл хранится в каталоге политики, связанном с объектом групповой политики, в каталоге Sys vol.
Пакет развертывания сообщает расширению на стороне клиента, где можно найти пакет MSI (обычно пакет доступен на сетевом ресурсе, указанном с помощью пути UNC), и предоставляет инструкции по специальной обработке пакета. Существует два способа развертывания пакета.
Публикация. Приложение становится доступным в меню аплета Add/Remove Programs (Установка и удаление программ) в Control Panel (Панель управления). Пользователю достаточно дважды щелкнуть на интересующем приложении, и служба Windows Installer установит приложение из пакета MSI, хранящегося на сервере распространения.
Если публикуется множество приложений, для упрощения выбора интересующего приложения можно присвоить приложениям категории. Для установки категорий для опубликованных приложений откройте окно Properties (Свойства) для пиктограммы Software Distribution (Распространение программного обеспечения) и перейдите на вкладку Categories (Категории).
Назначение. Пакет установки добавляет соответствующие ярлыки в меню Start (Пуск) и регистрирует приложение в системном реестре, как будто приложение уже установлено. При выборе соответствующего пункта в меню Start (Пуск) или двойном щелчке на файле данных, связанном с приложением, служба Windows Installer перехватывает управление и устанавливает пакет MSI с сервера распространения.
В любом случае приложение устанавливается таким образом, чтобы сервер распространения не оказался под пиковой нагрузкой в часы массовой регистрации пользователей. Можно открыть окно с дополнительными параметрами политики развертывания программного обеспечения и установить параметр для принудительной установки назначенного пакета при регистрации пользователя. Это бывает полезно, когда необходимо обеспечить актуальность версии клиентского программного обеспечения при изменении серверной части приложения.
Кроме этого, доступны следующие дополнительные возможности (параметр Advanced).
Поддержка адреса URL для опубликованных приложений, щелчок на котором приводит к предоставлению дополнительной информации о приложении.
Возможность удаления приложения, если объект пользователя перемещается за пределы контейнера, связанного с объектом групповой политики.
Возможность удаления существующих копий приложений, которые устанавливались без помощи групповых политик.
Инструкции по модернизации существующих копий приложения.
Возможность назначения файлов MST (Microsoft Transform) или другие изменения к основному пакету MSI.
Устранение неисправностей при развертывании программного обеспечения
Если при попытке обеспечить работоспособность пакета программного обеспечения возникают проблемы, начните с проверки применения всех остальных политик из объекта групповой политики. Если остальные политики успешно применяются, проверьте возможность доступа к файлу MSI со стороны клиента и возможность получения пакета для своего пользовательского объекта, помещенного в связанный с объектом групповой политики контейнер.
Если все проверки завершились удачно, придется применять тяжелую артиллерию: журнал диагностики и утилиту addiag.
Журнал диагностики управления приложениями
Расширение на стороне клиента Appmgmt отвечает за загрузку и обработку пакетов развертывания . aas. Существует возможность включения журнала диагностики для расширения Appmgmt. Это позволит проследить за работой расширения и обнаружить все ошибки и проблемы.
Включение журнала диагностики требует внесения изменений в системный реестр. Создайте следующую запись в системном реестре.
I
Раздел: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics
Запись: AppMgmtDebugLevel (REG_DWORD)
Значение: 4b
Внесение этой записи приведет к созданию журнала Appmgmt. log в каталоге \Windows\ Debug\Usermode.
Журнал диагностики службы Windows Installer
После загрузки и обработки пакета . aas расширением Appmgmt служба Windows Installer перехватывает управление и переходит к обработке пакета MSI. Включение журнала диагностики для службы Windows Installer позволяет определить, что делает служба для установки приложения, и увидеть все сообщения об ошибках. Для включения этого журнала также требуется внесение записи в системный реестр.
I
Раздел: HKLM\Software\Policies\Microsoft\Windows\installer
Запись: Logging (REG_SZ)
Значение: voicewarmup
Важна каждая буква в значении записи. Порядок может быть произвольным. Ниже расшифровано значение каждой буквы.
i — сообщения о состоянии
w — некритические предупреждения
е — все сообщения об ошибках
а — начало операций
г — записи, характерные для операций
и — пользовательские запросы
с — начальные параметры пользовательского интерфейса
m — недостаток памяти или информация о фатальном завершении
о — сообщения о недостатке дискового пространства
р — свойства терминала
v — подробный отчет
+ — добавить к существующему файлу
! — заносить в журнал каждую строку
* — использовать все параметры, кроме v
l*v —шаблон с подробным отчетом
Эта запись приводит к созданию журнала в каталоге %ТЕМР%. Имя журнала начинается строкой MSI, после чего указывается последовательность цифр и расширение . log.
Утилита addiag
Утилита addiag входит в состав Support Tools. Утилита предоставляет информацию об установленных пакетах MSI и источнике этих пакетов. Ниже показан листинг, в котором расшифрованы разделы отчета, выдаваемого утилитой addiag.
<Info> — отображает общую информацию
<TS> — отображает информацию о службах терминалов,
<LocalApps> — отображает список локальных управляемых приложений <ServerApps> - отображает список приложений, развернутых сервером <MSIApps> — отображает список локальных приложений MSI
<GPOList> — отображает список локальных объектов групповой политики
<ScriptList> - отображает список сценариев локальных приложений <ADHistory> — отображает историю локальных политик Active Directory <MSIFeatures> — отображает список локальных возможностей MSI
<EventDump> — отображает события приложений для журнала
<Check> — отображает проверку целостности Active Directory
Рассмотрим пример отчета утилиты addiag:
Z:\Program FilesXSupport Tools>addiag /v
Microsoft (R) Software Installation Diagnostics. Version 1.00 Copyright (C) Microsoft Corp 1998-1999. All rights reserved. Collecting info...
Initializing Remote DS Data...
Initializing Local AppMgmt Registry Data...
Initializing Local AppMgmt File Data...
Initializing Local Windows Installer Data...
Initializing Local Shell Data...
Initializing Local Event Data...
========================= General Info =============================
User — NameSamCompatible: COMPANYXphxuserl
User — NameFullyQualifiedDN: CN=phxuserl,OU=Phoenix,DC=company,DC=com
User — Logon Server: \\SERVERI
User - SID: S-l-5-21-2000478354-746137067-1957994488-1117
User — Profile Type: LOCAL
User — Locale: 1033
Processor Architecture: x86
System Locale: 1033
========================= TS Info =========================
Not running TS ========================= Managed Apps (Local List) === No Managed applications were found.
========================= Managed Applications (Server)
User dump for COMPANY.COM
Dumping GPO list (1 items)...
GPO GUID:(B672BEFE-7815-44C4-9F28-E482AEC2CBAD)
Name:Distrol
Administration Tools Pack
Object GUID:{D34A6C2A-5D4D-4005-85F6-CBDBB5136C57}
Package Flags:
Published
PostBeta3
Userinstall OnDemandlnstall OrphanOnPolicyRemoval
Productcode:{5E076CF2-EFED-43A2-A623-13E0D62EC7E0} UI Level:Full.
========================= windows Installer Apps ===================
Found 2 MSI application(s)
E'asy CD Creator 5 Platinum
WebFldrs
========================= Local AD History =========================
Found 1 Applied GPO(s)in the history
Distrol
GPO QUID:(B672BEFE-7815-44C4-9F28-E482AEC2CBAD)
Version:OxfOOOf
========================= Application log events ===================
EventID: 1004
Type: WARN
Date: 20:32:41.0000 - 2/02/2002
User: N/A
Computer: PRO10
Source: Msilnstaller
Description: Product: Detection of product 1{5E076CF2-EFED-43A2-A623
*^ -13E0D62EC7E0}1,feature 'FeDNSConsole '.component
4> '(455FE9A8-07D6-11D3-9C52-00A0C9F14522)' failed..
The resource 'D:\Windows \System32 \dnsmgmt.msc 1 does not exist..
Data:.
Политики перенаправления каталогов
При сохранении файлов пользователем приложение обычно предлагает сохранение в приня- том по умолчанию каталоге. Если приложение имеет логотип Windows 98, Windows 2000, Windows ХР или Windows Server 2003, по умолчанию предлагается каталог Му Documents (Мои документы). Такая стандартизация помогает управлять нагромождением файлов на рабочей станции пользователя, но дополнительных действий по копированию файлов на сервер для последующего резервного копирования и сканирования на предмет наличия вирусов не выполняется.
Это касается и других каталогов в профиле пользователя. Например, в каталоге Desktop (Рабочий стол) хранятся файлы и ярлыки, которые будут потеряны, если откажет локальный жесткий диск. В каталоге Application Data хранится информация о конфигураций программ, загруженных на рабочей станции, а также другие важные данные, например открытые ключи. Меню Start (Пуск) содержит ярлыки для всех приложений, установленных на компьютере.
Переместив критические компоненты Explorer, можно добиться централизации хранения и управления. Наиболее простая реализация предоставляется политиками перенаправления каталогов.
Политика перенаправления каталогов реализована в виде файла Fdeploy. ini, который указывает нмя UNC ресурса, на котором должен находиться системный каталог. Расширение на стороне клиента fde.dll обрабатывает этот файл, внося изменения в разделы системного реестра, связанные с каталогами Explorer. При этом меняется пространство имен объектов, используемых Explorer и другими компонентами в операционной системе Windows.
С точки зрения пользователей, перенаправление оказывается совершенно незаметным. Единственный момент, когда пользователь может догадаться об удаленном хранении файлов, возникает при разрыве сетевого соединения. С этим часто сталкиваются пользователи портативных компьютеров. В этом случае стоит обратить внимание на автономные каталоги, в которых можно хранить локальные копии файлов из перенаправленных каталогов.
Политики сценариев
В классической операционной системе Windows NT предоставлялся только один способ доставки сценария пользователю. Сценарий размещался в сетевом каталоге Net logon на каждом контроллере домена. После этого в профиле пользователя указывалась ссылка на этот сценарий. Предоставлялась возможность запуска только одного сценария, и сценарий не мог находиться в другом месте.
В современных операционных системах Windows ситуация со сценариями заметно изменилась. Политики сценариев позволяют запускать несколько сценариев из любого места. Кроме этого, предоставляется возможность запуска сценариев во время завершения сеанса пользователя и запуска сценариев при загрузке и завершении работы компьютера.
Операционная система все еще поддерживает классические сценарии для клиентов более старых версий. В Active Directory предоставляется атрибут объекта пользователя, в котором можно указать регистрационный сценарий. Клиенты более старых версий получают имя сценария при регистрации. Контроллер домена продолжает поддерживать ресурс Netlogon для хранения классических сценариев. Но расположение этого ресурса изменилось. В современных операционных системах Windows ресурс Netlogon связан с каталогом \Windows\ Sysvol\Sysvol\<HMs_/roMeHa>\Scripts. В классической операционной системе WindowsNT для совместного доступа предоставляется каталог \WlNNT\System32\Repl\lmport\ Scripts.
Классическая репликация сценариев
Все, что хранится в каталоге Sysvol, реплицируется на все контроллеры в пределах домена, и сценарии не являются исключением. Но если домен работает в режиме Windows 2000 Mixed и использует резервные контроллеры домена под управлением операционной системы Windows более старой версии, могут возникнуть проблемы.
В классической операционной системе WindowsNT содержимое ресурса Netlogon синхронизировалось между контроллерами домена средствами службы LanMan Replication (LMRepl). Служба LMRepl реплицировала содержимое каталога \WINNT\System32\Repl\ Export на основном контроллере домена в каталог Import на резервных контроллерах домена. Именно этот каталог предоставлялся для совместного доступа как ресурс Netlogon.
В операционной системе Windows Server 2003 служба LMRepl не поддерживается. Для синхронизации сценариев придется настроить классический резервный контроллер домена в качестве сервера экспорта LMRepl вместо основного контроллера домена. (В режиме Windows Mixed контроллер домена, которому предоставлена роль PDC Emulator, должен работать под управлением операционной системы Windows Server 2003.)
После этого необходимо использовать какой-либо метод копирования содержимого каталога Scripts с контроллера домена под управлением Windows Server 2003, выполняющего роль PDC Emulator, на классический резервный контроллер домена, который выступает в роли сервера экспорта. Можно воспользоваться Task Scheduler (Планировщик заданий) для запуска утилиты хсору, одной из утилит массового копирования из состава Resource Kit или утилитой от стороннего производителя. Утилита LMBridge из состава Resource Kit успешно справляется с этой задачей.
Типы сценариев
Сценарии могут иметь любой формат, который может интерпретироваться клиентом. Это могут быть файлы пакетной обработки (. bat) или командные файлы (. cmd), а также сценарии на более сложных языках сценариев.
Операционные системы Windows Server 2003 и Windows ХР поддерживают языки VBScript и JavaScript как часть стандартной инфраструктуры Windows Script Host (WSH). Кроме этого, можно использовать другие языки сценариев, например Perl и Python. Для этого на рабочих станциях необходимо установить соответствующие интерпретаторы команд. (Самые актуальные версии интерпретаторов ActivePerl и ActivePython предоставляются в виде пакетов MSI для обеспечения простой процедуры установки. Ознакомительные копии интерпретаторов команд доступны по адресу www. activestate . com.)
Язык VBScript и компьютерные вирусы
Известно, что многие компьютерные вирусы используют распространенную поддержку языка VBScript в операционной системе Windows для запуска вредоносного кода. Вирусы l-Love-You и AnnaKomikova являются примерами таких вредоносных программ. Если честно, то это уязвимое место не является неотъемлемым свойством языка VBScript. Если бы компания Microsoft приняла решение распространять вместе с операционной системой Windows интерпретатор ActivePerl, то вредоносный код писали бы на языке Perl.
В операционной системе Windows Server 2003 можно установить групповые политики, которые запрещают запускать вложения VBScript из сообщений электронной почты, но это не блокирует другие уязвимые места. Еще одним решением, предложенным Джейсоном Фоссе- ном (Jason Fossen) из компании SANS, является привязка расширения файлов . vbs к редактору Notepad (Блокнот) вместо механизма выполнения сценариев Cscript/Wscript.
В последнем случае все еще можно использовать язык VBScript для создания регистрационных сценариев. Для этого имя сценария необходимо указать в качестве параметра выполняемого файла Cscript. На рис. 12.20 показано, как это будет выглядеть в окне Edit Script (Изменить сценарий) редактора групповой политики.
Рис. 12.20. Окно Edit Script редактора GPE. Имя сценария VBScript указывается в качестве параметра приложения Cscript.ехе .
Развертывание сценариев
Политики сценариев состоят из двух компонентов.
Файл Script. ini, в которомперечисляются сценарии и указывается их расположение для клиента.
Собственно сценарий. Всегда храните сценарии в каталогах политик, чтобы они реплицировались на все контроллеры домена. Это предотвращает обращение клиентов через внешние соединения для загрузки необходимых сценариев.
Для развертывания сценариев необходимо создать файл Script. ini в редакторе групповых политик. Для этого откройте окно свойств интересующего сценария (рис. 12.21).
Возможность Show Files (Показать файлы) позволяет просмотреть файлы в каталоге Scripts. Это простой способ копирования сценариев в необходимый каталог политики. В противном случае пришлось бы просматривать каталог Sysvol и угадывать, какая из папок с именем в виде глобально уникального идентификатора соответствует обновляемой политике.
После размещения файла сценария в каталоге Policies воспользуйтесь кнопкой Add (Добавить), чтобы добавить сценарий в файл Script. ini.
Клиенты загружают файл Script. ini и передают его расширению на стороне клиента Gptext. После этого расширение загружает сам сценарий, который запускается под управлением соответствующего интерпретатора.
Если клиент загружает сценарии из различных объектов групповых политик, сценарии запускаются одновременно. По этой причине не стоит вставлять в один сценарий операции, которые зависят от операций в других сценариях.
Рис. 12.21. В окне Logon Properties отображается список выбранных сценариев
Кроме этого, пользователи получают доступ к рабочему столу, когда регистрационные сценарии еще выполняются. Это значит, что не стоит создавать ярлыки и параметры оболочки Explorer, которые зависят от действий регистрационных сценариев.
Многие организации используют многоуровневые регистрационные сценарии. Например, администраторы домена верхнего уровня могут создать сценарий, который устанавливает стандартные параметры настольного компьютера, например подключает сетевые диски и запускает стандартные приложения. Администраторы организационной единицы хотели бы дополнить такой регистрационный сценарий, но они не могут предполагать, что во время запуска их собственного регистрационного сценария уже подключены сетевые диски.
Чтобы использовать многоуровневые регистрационные сценарии или блокировать доступ к рабочему столу до завершения выполнения всех сценариев, необходимо настроить систему на синхронный запуск регистрационных сценариев (дополнительную информацию по этому вопросу можно получить в разделе “Синхронная обработка” ранее в этой главе.)
Консоль управления групповыми политиками
Консоль управления групповыми политиками (Group Policy Management Console — GPMC) является альтернативой механизму управления объектами групповых политик на основе контейнеров, который реализован на консоли Active Directory — Users and Computers (Active Directory — пользователи и компьютеры).
Консоль управления групповыми политиками предоставляет многие из возможностей программы Fazam2000 от компании Full Armor, например моделирование и резервное копирование политик. Кроме этого, устанавливается новый объект автоматизации, Gpmgmt, который предоставляет большое количество операций для использования в сценариях.
Поиск объектов групповых политик
Создание и удаление объектов групповых политик
Резервное копирование и восстановление объектов групповых политик
Импорт и экспорт
Копирование объектов групповых политик
Связывание объектов групповых политик с контейнерами
Изменение фильтров WMI■
Делегирование прав доступа для объектов групповых политик
Создание собственных отчетов для объектов групповых политик, включая результирующий набор политик
Компания Microsoft выпускает консоль управления групповыми политиками (GPMC) отдельно от операционной системы Windows Server 2003. Консоль может быть загружена с сайта Microsoft и установлена на любой компьютер под управлением операционной системы Windows Server 2003 или Windows ХР SP1. Для установки консоли на операционную систему Windows ХР требуется установка исправления (hotfix), предоставленного вместе с установочным пакетом.
В следующей главе
На этом этапе развертывания операционной системы Windows Server 2003 в пределах предприятия система способна принимать входящие соединения пользователей. Перед тем как распахивать двери, рассмотрим настройку хранилища данных, чтобы предоставить безопасный и надежный способ хранения пользовательских данных.
13
Управление безопасностью Active Directory
Т
акие большие проекты, как развертывание операционной системы Windows Server 2003 в пределах предприятия, обычно выполняются в несколько этапов.
На предпоследнем этапе необходимо ознакомиться с проблемами в системе безопасности Active Directory, чтобы подготовиться к последнему этапу, когда можно будет начинать фактическую эксплуатацию сети.
В этой главе рассматриваются следующие темы.
Администрирование Active Directory с помощью делегирования разрешений
Использование групп для управления разрешениями Active Directory, включая пошаговое описание междоменного взаимодействия групп
Работа службы запуска программ от имени другого пользователя (Secondary Logon Service — SLS) и использование команды RunAs для выполнения ежедневных операций без применения учетной записи администратора
Использование инструментария управления Windows для уведомления администратора о событиях Active Directory
Часть информации из этой главы дублирует информацию из главы И, “Безопасность доступа по сети и протокол Kerberos". Это связано с тем, что та же система безопасности используется множеством структурных компонентов, включая Active Directory.
Новые возможности операционной системы Windows Server 2003
В операционной системе Windows Server 2003 изменилось несколько настроек, обеспечивающих безопасность Active Directory.
Наборы разрешений. Для предоставления возможности управления результирующим набором политик были добавлены дополнительные наборы разрешений. Кроме этого, были добавлены наборы разрешений для класса объектов InetOrgPerson с целью обеспе-
чения совместимости со службами Novell Directory Services (NDS) и Netscape Directory Services (тоже NDS).
Программа вычисления действующих разрешений. В редакторе списков контроля доступа появилась новая программа вычисления действующих разрешений (Effective Permissions), которая значительно упрощает управление перекрывающимися унаследованными правами в Active Directory.
Поддержка смарт-карт. Теперь команда Run As поддерживает аутентификацию по смарт- картам. Благодаря использованию командного интерпретатора реализация команды RunAs получила специальные механизмы защиты от некорректно работающих приложений.
Обзор системы безопасности
Active Directory
Как и в главе И, “Безопасность доступа по сети и протокол Kerberos”, рассмотрим ключевые элементы механизмов аутентификации и авторизации в операционной системе Windows Server 2003..
Участник системы безопасности — пользователь, компьютер или группа, которая должна получать доступ к ресурсам на локальном компьютере или сервере.
Основным методом аутентификации участника системы безопасности является протокол Kerberos. Механизмы аутентификации NTLMv2 (NT LanMan version 2) и LM (LanMan) доступны для поддержки клиентов более старых версий.
Прошедшие аутентификацию участники системы безопасности получают сертификат привилегий доступа, который содержит информацию для системы безопасности (Privilege Access Certificate — РАС). В сертификате РАС содержатся идентификатор безопасности (SID) участника системы безопасности, а также идентификаторы безопасности всех групп, в которые входит этот участник системы безопасности, и идентификаторы безопасности всех групп, в которые входят эти группы. Кроме этого, в сертификате привилегий доступа указывается список системных привилегий, предоставленных пользователю, и список ограничений, установленных для участника системы безопасности.
На основе сертификата РАС служба LSA создает маркер доступа, который присоединяется к любому процессу, запущенному участником системы безопасности.
Ключевые объекты операционной системы защищены специальной структурой безопасности, которая называется дескриптором безопасности (security descriptor). В дескрипторе безопасности содержится список DACL, который определяет, кто может получать доступ к объекту и какие операции могут быть выполнены над объектом.
При попытке доступа к защищенному объекту монитор ссылок безопасности (Security Reference Monitor — SRM) сравнивает содержимое DACL с содержимым маркера доступа и типом доступа, который запрошен процессом. В зависимости от результата сравнения монитор ссылок безопасности предоставляет процессу эффективные (действующие) права доступа.
Права доступа определяются по каноническому методу, согласно которому разрешения Deny (Запретить) учитываются прежде, чем разрешения Allow (Разрешить), а явно заданные разрешения учитываются прежде, чем унаследованные разрешения.
Помня об этом, рассмотрим, как служба Active Directory использует подсистему безопасности для предоставления разрешений с привилегиями администратора и управления доступом к объектам.
Просмотр содержимого дескриптора безопасности
Для просмотра содержимого дескриптора безопасности объекта Active Directory можно открыть окно свойств объекта на соответствующей консоли управления Active Directory. Например, откройте консоль Active Directory — Users and Computers (Active Directory — пользователи и компьютеры) и раскройте раздел контейнера Users. Щелкните правой кнопкой мыши на объекте и выберите из контекстного меню команду Properties (Свойства). Откройте вкладку Security (Безопасность). Откроется редактор списка управления доступом (ACL Editor), в котором можно просмотреть содержимое дескриптора безопасности.
После запуска редактора ACL Editor используется универсальный режим просмотра, согласно которому отображаются участники системы безопасности, указанные в DACL. Элементы списка отсортированы в алфавитном порядке. Конкретный участник системы безопасности может быть указан в списке DACL несколько раз. При выборе конкретного участника системы безопасности его полный список прав доступа отображается в нижней части окна. На рис. 13.1 показан универсальный режим просмотра редактора ACL Editor для объекта пользователя.
[РЬк User Properties[РЬк User PropertiesEnwomert | ЯМк» | H*e»«erwt| he*VSfnewfk*| (ИМ* Gengrei | AM**» ] UpeqM | Mb'| Tdehaerf ttgetaellen AWedCweaw j МийНИ | OWk 1 Ойв- - S«*Enwomert | ЯМк» | H*e»«erwt| he*VSfnewfk*| (ИМ* Gengrei | AM**» ] UpeqM | Mb'| Tdehaerf ttgetaellen AWedCweaw j МийНИ | OWk 1 Ойв- - S«*dd0 Administrators (COMPANYXAdmmtrators) Authenticated Usersfl Cwt №$hers (COMPAWACert Pub6sher$|^ Domain Admins (COMPANYSDomain Admins)0 Administrators (COMPANYXAdmmtrators) Authenticated Usersfl Cwt №$hers (COMPAWACert Pub6sher$|^ Domain Admins (COMPANYSDomain Admins)Fid ControlRead v/riteCreate Al Child ObjectsDelete AB Chid Objects Change PasswordFid ControlRead v/riteCreate Al Child ObjectsDelete AB Chid Objects Change Passwordи и 0 0 0 0и и 0 0 0 0□ □ □ □□ □ □ □Puc. 13.1. В окне редактора ACL Editor отображаются основные разрешения для объекта пользователяPuc. 13.1. В окне редактора ACL Editor отображаются основные разрешения для объекта пользователя
[РЬк User Properties
[РЬк User Properties
Enwomert | ЯМк» | H*e»«erwt| he*VSfnewfk*| (ИМ* Gengrei | AM**» ] UpeqM | Mb'| Tdehaerf ttgetaellen AWedCweaw j МийНИ | OWk 1 Ойв- - S«*
Enwomert | ЯМк» | H*e»«erwt| he*VSfnewfk*| (ИМ* Gengrei | AM**» ] UpeqM | Mb'| Tdehaerf ttgetaellen AWedCweaw j МийНИ | OWk 1 Ойв- - S«*
d
d
0 Administrators (COMPANYXAdmmtrators) Authenticated Users
fl Cwt №$hers (COMPAWACert Pub6sher$|
^ Domain Admins (COMPANYSDomain Admins)
0 Administrators (COMPANYXAdmmtrators) Authenticated Users
fl Cwt №$hers (COMPAWACert Pub6sher$|
^ Domain Admins (COMPANYSDomain Admins)
Fid Control
Read v/rite
Create Al Child Objects
Delete AB Chid Objects Change Password
Fid Control
Read v/rite
Create Al Child Objects
Delete AB Chid Objects Change Password
и и 0 0 0 0
и и 0 0 0 0
□ □ □ □
□ □ □ □
Puc. 13.1. В окне редактора ACL Editor отображаются основные разрешения для объекта пользователя
Puc. 13.1. В окне редактора ACL Editor отображаются основные разрешения для объекта пользователя
Если объекту предоставлены дополнительные разрешения, то напротив элемента Special Permissions (Дополнительные разрешения) будет установлен флажок. Это значит, что для просмотра всех разрешений участника системы безопасности необходимо задать в редакторе ACL Editor режим отображения Advanced view (Дополнительные параметры). На рис. 13.2 показан пример окна редактора ACL Editor при использовании режима отображения Advanced view (Дополнительные параметры) для того же объекта пользователя.
Записи в режиме отображения Advanced view (Дополнительные параметры) отображаются в том порядке, в котором их будет оценивать монитор ссылок безопасности (SRM) при
принятии решения о предоставлении доступа к объекту системы безопасности. Унаследованные разрешения выделяются отдельно, чтобы показать их отличие от разрешений, предоставленных непосредственно в дескрипторе безопасности. В списке отображается исходный контейнер, из которого были унаследованы разрешения, что может пригодиться для устранения неисправностей.
ЛЛOf* ОТ*Of* ОТ*Alow Alow Alow Alow Alow Alow AlowAlow Alow Alow Alow Alow Alow AlowThis object or* This object or* This object or* This object or* This object or* This object or* This object or*This object or* This object or* This object or* This object or* This object or* This object or* This object or*This ThisThis This<not merited» Knot inherited» Knot inherited» к not inherited» < not inherited» Knot inherited» < not inherited» < not inherited» < not inherited-<not merited» Knot inherited» Knot inherited» к not inherited» < not inherited» Knot inherited» < not inherited» < not inherited» < not inherited-Ri Control Ri Control Specie! Change Passw.. Send As Receive As ReadAVrite Per... ReadAVrite Ph... ReadAVrite WRi Control Ri Control Specie! Change Passw.. Send As Receive As ReadAVrite Per... ReadAVrite Ph... ReadAVrite WSYSTEMAccount Operators (... SELF SELFSELF SELF SELF SELF SELFSYSTEMAccount Operators (... SELF SELFSELF SELF SELF SELF SELF'-Й ”" Л Alow'-Й ”" Л AlowГГPuc. 13.2. При использовании режима отображения Advanced view (Дополнительные параметры) редактора ACL Editor отображаются специальные разрешения, предоставленные участнику системы безопасностиPuc. 13.2. При использовании режима отображения Advanced view (Дополнительные параметры) редактора ACL Editor отображаются специальные разрешения, предоставленные участнику системы безопасностив*** 4в*** 4ШаШа
Л
Л
Of* ОТ*
Of* ОТ*
Alow Alow Alow Alow Alow Alow Alow
Alow Alow Alow Alow Alow Alow Alow
This object or* This object or* This object or* This object or* This object or* This object or* This object or*
This object or* This object or* This object or* This object or* This object or* This object or* This object or*
This This
This This
<not merited» Knot inherited» Knot inherited» к not inherited» < not inherited» Knot inherited» < not inherited» < not inherited» < not inherited-
<not merited» Knot inherited» Knot inherited» к not inherited» < not inherited» Knot inherited» < not inherited» < not inherited» < not inherited-
Ri Control Ri Control Specie! Change Passw.. Send As Receive As ReadAVrite Per... ReadAVrite Ph... ReadAVrite W
Ri Control Ri Control Specie! Change Passw.. Send As Receive As ReadAVrite Per... ReadAVrite Ph... ReadAVrite W
SYSTEM
Account Operators (... SELF SELF
SELF SELF SELF SELF SELF
SYSTEM
Account Operators (... SELF SELF
SELF SELF SELF SELF SELF
'-Й ”" Л Alow
'-Й ”" Л Alow
Г
Г
Puc. 13.2. При использовании режима отображения Advanced view (Дополнительные параметры) редактора ACL Editor отображаются специальные разрешения, предоставленные участнику системы безопасности
Puc. 13.2. При использовании режима отображения Advanced view (Дополнительные параметры) редактора ACL Editor отображаются специальные разрешения, предоставленные участнику системы безопасности
в*** 4
в*** 4
Ша
Ша
Программа вычисления действующих разрешений
В операционной системе Windows Server 2003 предоставляется новая программа вычисления действующих прав доступа, позволяющая показать список разрешений, которые конкретный пользователь получит при доступе к объекту. После того как вы откроете вкладку Effective Permissions (Действующие разрешения) и введете интересующее имя, система выполнит оценку параметров безопасности и выведет результат в виде списка параметров с флажками, установленными напротив действующих разрешений (рис. 13.3).
Типы прав доступа
Кроме стандартных прав доступа Read (Чтение), Write (Запись), Modify (Изменить) и т.д., операционная система Windows Server 2003 предоставляет более 50 дополнительных прав доступа, которые могут быть предоставлены объектам Active Directory. Рассмотрим лишь некоторые права из этого набора.
ChangePDC. Предоставляет право на передачу роли хозяина операций PDC Emulator.
GenerateRSoPPlanning. Предоставляет право на вычисление результирующего набора политик (Planning).z
Domainpassword. Предоставляет право на сброс пароля объекта пользователя.
Q List Content# Q Reed AB Properties Я Write Al Properties ■ Delete Q Delete Sitiree Q Read Permission# Q Modfy Permission# Q Modfy Owner Q AB Extended Rights □ Create AB Chid Objects □ Delete AB Chid Objects ■ Change Password Q Receive A#
Puc. 13.3. Окно программы для вычисления действующих разрешений
Разрешения можно назначать отдельным свойствам объекта. Например, предположим, что было создано приложение для отдела Facilities, которое вносит изменения в определенные атрибуты объектов Active Directory, например, TelephoneNumber и Location. Разрешения для свойств можно использовать с целью предоставления персоналу отдела Facilities возможностей чтения и записи соответствующих свойств объектов User без предоставления им возможностей изменения других свойств объектов.
Для просмотра разрешений (permission), предоставленных отдельным свойствам (property), можно воспользоваться режимом Edit (Правка) в редакторе ACL Editor (рис. 13.4).
Рис. 13.4. В расширенном режиме отображения ACL Editor отображаются разрешения для отдельных свойств, предоставляемые участникам системы безопасности
Read Al Properties Write Al Properties Read Account Restrictions Write Account Restrictions Read General Information Write General Information Read Group Membership Write Group Membership Read Logon Information Write Logon Information Read Personal Information Write Personal Information
□ □ □ □ □ □ □ и □ □ □
□ □ □ □ □ □ □ □ □ □ □
Наследование записей контроля доступа
Наследование определяет, влияет ли запись контроля доступа (АСЕ) на дочерние объекты, а также определяет множество объектов, на которые оказывает влияние запись контроля доступа. Обычно запись контроля доступа наследуется всеми дочерними объектами во всех дочерних контейнерах.
В режиме Edit (Правка) редактора ACL Editor можно назначать специальные правила наследования записи контроля доступа (Access Control Entry — АСЕ). Существует возможность очень тонкого управления наследованием. Например, можно включить наследование набора разрешений только объектами групп в определенном контейнере, не включая дочерние контейнеры.
Естественно, во время обычной эксплуатации не приходится так глубоко нырять в особенности прав доступа Active Directory. Но желательно об этом помнить, так как они могут потребоваться для решения сложной проблемы администрирования.
В процедуре 13.1 показан пример использования консоли Active Directory— Users and Computers (Active Directory — пользователи и компьютеры) для применения унаследованных прав к фиктивной (тестовой) организационной единице.
Дескрипторы безопасности и репликация
Изменение списка DACL, управляющего доступом к объекту, который располагается близко к . вершине дерева Active Directory, приводит к обновлениям множества дескрипторов безопасности, расположенных ниже по дереву в результате наследования. Но это не приводит к наводнению репликации. Реплицируются только те объекты, в которых внесено изменение. Как только обновление достигнет партнера по репликации, механизм управления базой данных Active Directory внесет необходимые изменения в дескрипторы безопасности дочерних объектов. Это позволяет максимально уменьшить объем данных, передаваемых при репликации во время делегирования разрешений, связанных с безопасностью (security permissions).
Процедура 13.1. Назначение наследуемых прав контейнеру Active Directory
Откройте консоль Active Directory — Users and Computers (Active Directory — пользователи и компьютеры).
Воспользуйтесь командой View^Advanced Features (Вид1^Дополнительные функции). В свойствах объектов Active Directory откройте вкладку Security (Безопасность).
Создайте фиктивную организационную единицу. Это защитит используемые контейнеры от случайной ошибки. Создайте в тестовом контейнере несколько объектов пользователей. Если это промышленный сервер и корпоративные политики запрещают создавать идентификаторы пользователей, создайте объекты контактов. Эти рбъекты ведут себя, как объекты пользователей, но не имеют прав в системе безопасности.
Щелкните правой кнопкой мыши на записи новой организационной единице и выберите из контекстного меню команду Properties (Свойства).
Откройте вкладку Security (Безопасность), которая показана на рис. 13.5. На этой вкладке отображается список записей контроля доступа.
Сбросьте флажок Allow Inheritable Permissions (Разрешить наследование разрешений). Будет выдан запрос на копирование или удаление унаследованных записей контроля доступа в дескрипторе безопасности.
Щелкните на кнопке Remove (Удалить). Унаследованные записи исчезнут. В среде корпоративных сетей всегда выбирайте вариант Copy Previously Inherited Permissions (Копировать унаследованные разрешения). Это позволит сохранить критически важные записи контроля доступа. Отсутствие записи контроля доступа эквивалентно записи контроля доступа Deny (Запретить).'
Щелкните на кнопке Advanced (Дополнительно). Откроется окно Advanced Security Settings (Дополнительные параметры безопасности).
На рис. 13.6 показан набор записей контроля доступа для организационной единицы. Права, связанные с записями контроля доступа Allow (Разрешить), суммируются, поэтому участник системы безопасности с несколькими записями контроля доступа получает каждое право, предоставленное в записи контроля доступа, после учета всех записей контроля доступа Deny (Запретить).
Ganati| MaiagedВ,} Obed Sen* |сВМ*| в*1»Р*»|
GflM>»uiWfwm
"jjJCkdnwwtrataTf^^
fl Phx_Admtns (COMPANY\Phx_Admr»} fl US_Admn$ (COMPANY\US„Admn$)
PerMtMinsPerMtMinsFul ControlReadWriteCreate Al Child ObjectsDelete AU Child Ob|ectsGenerate Resultant Set of Po6cy(Logging)Ful ControlReadWriteCreate Al Child ObjectsDelete AU Child Ob|ectsGenerate Resultant Set of Po6cy(Logging)Мм□0Мм□0cick Advanced.cick Advanced.D D ПD D П□ □□ d□ □□ dPuc. 13.5. Окно свойств организационной единицы, в котором отображается вкладка Security (Безопасность) с записями контроля доступаPuc. 13.5. Окно свойств организационной единицы, в котором отображается вкладка Security (Безопасность) с записями контроля доступа
PerMtMins
PerMtMins
Ful Control
Read
Write
Create Al Child Objects
Delete AU Child Ob|ects
Generate Resultant Set of Po6cy(Logging)
Ful Control
Read
Write
Create Al Child Objects
Delete AU Child Ob|ects
Generate Resultant Set of Po6cy(Logging)
Мм□0
Мм□0
cick Advanced.
cick Advanced.
D D П
D D П
□ □
□ d
□ □
□ d
Puc. 13.5. Окно свойств организационной единицы, в котором отображается вкладка Security (Безопасность) с записями контроля доступа
Puc. 13.5. Окно свойств организационной единицы, в котором отображается вкладка Security (Безопасность) с записями контроля доступа
То vow тм rtomwfai abed Speed Мшееом. мМ • рбпанйкеее. •*Ben tM М
Ж^^жда? UH^^d ” ^‘' ^^fi^JjpctarST1'1
AlowAdiwiistratesfCtiMP... FulContioT6U-USJ)C-companyI>... This object and a'.
AlowUS_Admins (COMPA... Ful Control00-US.DC-company.D... This object and a
Puc. 13.6. Окно Advanced Security Settings (Дополнительные параметры безопасности) для организационной единицы, в котором показаны связанные с участником системы безопасности типы записей контроля доступа, типы разрешений и параметры наследования
Выделите одну из записей контроля доступа и щелкните на кнопке Edit (Изменить). Откроется окно Permission Entry (Запись разрешения). В раскрывающемся списке Apply Onto (Применять к) будут показаны параметры наследования, которые можно назначить этой записи контроля доступа. .
Закройте открытые окна и возвратитесь на консоль Active Directory — Users and Computers (Active Directory — пользователи и компьютеры).
Делегирование прав доступа-
Можно потерять большую часть жизни, пытаясь выяснить точный набор разрешений, необходимых для получения нужного администратору результата. И это даже не рассматривая параметры наследования, которые придется учесть при предоставлении новых разрешений.
В операционной системе Windows Server 2003 этот процесс значительно упрощен благодаря использованию возможности, которая называется делегирование (delegation). Эта возможность позволяет выбрать административные параметры из меню и переложить на операционную систему задачу изменения отдельных разрешений.
Существует малозаметная разница между наследованием (inheritance) и делегированием (delegation). Наследование определяет механизм применения изменений к дочерним дескрипторам безопасности на основе родительского дескриптора безопасности. Делегирование подразумевает выбор наследуемых прав доступа. Это похоже на установку пляжного зонта. Зонт отбрасывает тень (делегирование), а владелец зонта находится в тени (наследование).
Делегирование может привести к неожиданным последствиям. Например, в рассказе Уловка 22 Майло Майндербиндер смог воспользоваться делегированной властью офицера снабжения небольшой эскадрильи ВВС, чтобы парализовать военную экономику Италии. Того же эффекта можно добиться при беспорядочном делегировании административных привилегий.
Вместо того чтобы проверять 200 свойств пользователей, групп и компьютеров, пытаясь понять, какие свойства предоставлять, а какие могут привести к нежелательным последствиям, проще воспользоваться мастером делегирования управления. Автора этой книги нельзя назвать сторонником использования различных мастеров администрирования в операционной системе Windows Server 2003. В большинстве случаев они усложняют простые операции. Но как только дело доходит до предоставления административных прав в Active Directory, желательно все-таки использовать мастер делегирования управления (Delegation of Control Wizard). Благодаря ему значительное количество прав доступа к объектам, дополнительных разрешений и разрешений для свойств представлено в виде разумного набора окон, в которых можно выбирать нужные параметры. Кроме этого, мастер может использоваться для точного выбора конкретных разрешений.
В процедуре 13.2 описано использование мастера делегирования управления. В этом примере используется объект консоли Active Directory — User and Groups (Active Directory - пользователи и компьютеры), так как именно здесь делегирование применяется чаще всего, но делегирование прав доступа допустимо практически в любом контейнере любой консоли.
Процедура 13.2. Делегирование прав доступа
На консоли Active Directory — Users and Computers (Active Directory — пользователи и компьютеры) щелкните правой кнопкой мыши на записи организационной единицы, созданной в предыдущей процедуре, и выберите из контекстного меню команду Delegate Control (Делегирование управления). Запустится мастер делегирования управления.
Щелкните на кнопке Next (Далее). Откроется окно Group or User Selection (Пользователи или группы).
Щелкните на кнопке Add (Добавить). Откроется окно Select Users, Computers or Group (Выберите категорию: Пользователи, Компьютеры или Группы).
Введите несколько букв имени добавляемого участника системы безопасности и щелкните на кнопке ОК. Если критерию поиска удовлетворяет больше одного участника системы безопасности, выберите интересующее имя из открывшегося списка.
Щелкните на кнопке Next (Далее). Откроется окно Tasks to Delegate (Делегируемые задачи), как показано на рис. 13.7.
Tasks Io DelegateYou can select common tacks or customize you own.Tasks Io DelegateYou can select common tacks or customize you own.□ Deate, delete, and manage user accounts□ Reset uset passwords and force password change at next logon□ Read al user information□ Deale, delete and manage groups0 Modfy the membersh? ol a grot»□ Deate, delete, and manage user accounts□ Reset uset passwords and force password change at next logon□ Read al user information□ Deale, delete and manage groups0 Modfy the membersh? ol a grot»Puc. 13.7. Окно Tasks to Delegate (Делегируемые задачи) мастера делегирования управленияPuc. 13.7. Окно Tasks to Delegate (Делегируемые задачи) мастера делегирования управления
Tasks Io Delegate
You can select common tacks or customize you own.
Tasks Io Delegate
You can select common tacks or customize you own.
□ Deate, delete, and manage user accounts
□ Reset uset passwords and force password change at next logon
□ Read al user information
□ Deale, delete and manage groups
0 Modfy the membersh? ol a grot»
□ Deate, delete, and manage user accounts
□ Reset uset passwords and force password change at next logon
□ Read al user information
□ Deale, delete and manage groups
0 Modfy the membersh? ol a grot»
Puc. 13.7. Окно Tasks to Delegate (Делегируемые задачи) мастера делегирования управления
Puc. 13.7. Окно Tasks to Delegate (Делегируемые задачи) мастера делегирования управления
Можно выбрать любой или все варианты в группе Predefined Tasks (Делегировать стандартную задачу) или Custom Task (Создать задачу для делегирования). Если выбрать предопределенную (стандартную) задачу и щелкнуть на кнопке Next (Далее), откроется окно с заданными параметрами. Щелкните на кнопке Finish (Готово), и права будут применены. Выберите переключатель Custom Task (Создать задачу для делегирования) хотя бы для просмотра доступных параметров.
Рис. 13.8. Окно Active Directory Object Туре (Тип объекта Active Directory) мастера делегирования управленияРис. 13.8. Окно Active Directory Object Туре (Тип объекта Active Directory) мастера делегирования управления
Рис. 13.8. Окно Active Directory Object Туре (Тип объекта Active Directory) мастера делегирования управления
Рис. 13.8. Окно Active Directory Object Туре (Тип объекта Active Directory) мастера делегирования управления
Щелкните на кнопке Next (Далее). Откроется окно, которое показано на рис. 13.8.
Если выбрать переключатель This Folder, existing objects in this folder, and creation of new objects in this folder (Этой папке, существующим и новым объектам в этой папке), то выбранные в следующем окне права будут назначены всем подчиненным объектам независимо от их типа. Если выбрать Only the Following Objects in the Folder (Только следующим объектам в этой папке), можно выбрать один или несколько типов объектов, которые унаследуют назначенные права.
Флажки Create (Создать) и Delete (Удалить) могут быть полезны для предоставления разрешений на добавление и удаление объектов выбранного типа.
Прокрутите список Object Туре (Тип объекта) и выберите User Objects (Объекты Пользователь).
Щелкните на кнопке Next (Далее). Откроется окно Permissions (рис. 13.9). В этом окне доступны следующие параметры.
Рис. 13.9. Окно Permissions мастера делегирования управления
Флажок General (Общие) позволяет получить доступ к стандартным разрешениям для объектов, а также расширенным разрешениям, которые применяются к классу объектов.
Флажок Property-Specific (Разрешения для свойств) предоставляет свойства, связанные с классом объектов с возможностью разрешить или запретить чтение или запись каждого свойства.
Параметр Creation/Deletion of Specific Child Objects (Права для создания или удаления дочерних объектов) предоставляет список типов объектов, что позволяет добавлять или удалять экземпляры этого класса.
Выберите интересующие разрешения и щелкните на кнопке Next (Далее). Откроется окно с выбранными параметрами. Щелкните на кнопке Finish (Готово) для сохранения изменений. Будут обновлены все объекты выбранного типа.
Файл Dssec.dat и отображение предоставленных разрешений
Можно обратить внимание, что при редактировании отдельных свойств объекта список доступных свойств меньше, чем список возможных свойств для этого класса объектов.
Выводимый список управляется текстовым файлом, который называется Dssec. dat и хранится в каталоге \windows\System32. Ниже приведен фрагмент этого файла:
[user]
aCSPolicyName=7
adminCount = 7
allowedAttributes=7
allowedAttributesEffective=7
allowedChildClasses=7
allowedChildClassesEffective=7
badPasswordTime=7
badPwdCount=7
bridgeheadServerListBL=7
c=7
canonicalName=7
co=7
codePage=7
Значение 7 означает, что свойство не будет отображаться. Это предотвращает назначение разрешений свойствам, которые управляются системой.
Если необходимо отобразить какое-либо свойство, замените значение 7 значением 0. Для вступления изменения в силу необходимо завершить сеанс и зарегистрироваться повторно.
Управление списками контроля доступа с помощью утилиты dsacls
До этого момента для управления разрешениями использовалась консоль Active Directory — Users and Computers (Active Directory — пользователи и компьютеры). Если предпочтение отдается утилите с интерфейсом командной строки, то для управления разрешениями Active Directory можно воспользоваться утилитой dsacls из состава Support Tools.
Формат команды при использовании утилиты dsacls для просмотра содержимого дескриптора безопасности объекта cn=Average User в домене Company . com будет выглядеть следующим образом:
dscacls cn=average user,cn=users,dc=company,dc=com
Рассмотрим пример использования утилиты dsacls (показана только одна запись контроля доступа):
C:\>dsacls "cn=average user,cn=users,dc=company,dc=com"
Displaying ACTRL_ACCESS list: AccessList
Entries: 1
Flags: 1
cEntries: 3
Entry 0:
Trustee.Name: COMPANY\Domain Admins fAccessFlags: 1 Access: 0x78001ff
ProvSpecificAccess: 0
Inheritance: 0x2
IpInheritProperty:
Entry 1:
Truste'e.Name: NT AUTHORITY\SELF fAccessFlags: 1 Access:- 0x7800Iff ProvSpecificAccess: 0 Inheritance: 0x0
IpInheritProperty:
Entry 2:
Trustee.Name: NT AUTHORITYXSYSTEM fAccessFlags: 1
Access: 0x78001ff
ProvSpecificAccess: 0
■ Inheritance: 0x0
IpInheritProperty:
DSACLS succeeded
В записи Access (Доступ) в каждом листинге хранится шестизначное шестнадцатеричное число, которое называется маска доступа (access mask). В табл. 13.1 перечислены стандартные права доступа и соответствующие маски доступа. Эти значения можно встретить в других утилитах с интерфейсом командной строки и в некоторых журналах событий.
Таблица 13.1. Типы масок доступа Directory Service Objects и значения масок
Тип маски доступа
Маска
Delete
08000000
Read Properties
00000010
Read Permissions
10000000
Modify Properties
00000020
Modify Permissions
20000000
Delete Subtree
00000040
Modify Owner
40000000
List Object
00000080
Generic Delete (только наследуется)
80000000
Control Access
00000100
Create A Child Object
00000001
Delete A Child Object
00000002
List Contents
00000004
Add/Remove Self As Member
00000008
При назначении разрешений участнику системы безопасности маска записи контроля доступа содержит сумму различных разрешений. Если предоставить права доступа для определенного свойства, в отчете утилиты dsacls будут указаны имя свойства и соответствующая маска записи контроля доступа, как показано ниже:
Property: Change Password
Flags: 1
cEntries: 1
Entry 0:
Trustee.Name: COMPANYXHelpDesk Admins fAccessFlags: 1
Access: 0x100
ProvSpecificAccess: 0
Inheritance: 0x2
IpInheritProperty:
В этом случае администраторам службы поддержки (HelpDesk Admins) предоставлены права Control Access (0x100) для свойства Change Password объекта. Это позволяет члену этой группы сбрасывать пароль пользователя.
Утилиту dsacls можно использовать для изменения прав, а также для их чтения. Например, если группе Daily Operations необходимо предоставить право Full Control
(Полный доступ) для всех объектов в организационной единице Sales и для всех вложенных контейнеров организационной единицы Sales, можно воспользоваться следующей командой: dsacls ou=Sales,dc=Company,dc=com /s:co /g "Daily Operations":780001ff
Возможно, утилита dsacls слишком неуклюжа для ежедневного использования. Но ее можно использовать как часть сценария или файла пакетной обработки для более простого назначения прав или для быстрого просмотра предоставленных привилегий для последующего анализа.
Использование групп для управления объектами Active Directory
Практически всегда стоит распределять пользователей по группам в зависимости от выполняемых этими пользователями действий. Группы не только проще в управлении, но и позволяют увеличить производительность работы администратор» при управлении безопасностью объектов. При работе со списком контроля доступа намного проще проверить один идентификатор безопасности группы, в которую входят 3000 пользователей, чем 3000 идентификаторов отдельных пользователей.
Поэтому правильное создание групп и управление ими является важной задачей при использовании операционной системы Windows Server 2003.
В этом разделе приводится описание групп каждого типа и даются советы по их использованию. Предоставляются также пошаговые описания использования операционной системой членства в группах для формирования разрешений Active Directory. Понимание этих процессов позволяет предоставлять необходимые разрешения и без труда выявлять причину возникающих неполадок.
Типы групп
Существует несколько основных типов групп в операционной системе Windows Server 2003.
Локальные для компьютера. Определяются в базе данных SAM на компьютере, не входящем в домен. Эти группы поддерживаются для обеспечения обратной совместимости с операционной системой Windows NT и не должны использоваться в операционной системе Windows Server 2003.
Локальные для домена. Это группы, в которые могут быть добавлены члены из любого домена в пределах леса, но применяются только в списках контроля доступа внутри локального домена.
Глобальные. Определяют группы, в которые могут быть добавлены члены только из локального домена, но могут применяться в списках контроля доступа в пределах всего леса.
Универсальные. Это группы, в которые могут быть добавлены члены из любого домена в пределах всего леса, и могут применяться в списках контроля доступа в любом домене в пределах леса. Такие группы поддерживаются только в режиме Windows 2000 Native.
Встроенные. Это специальная часть локальных для домена групп, которая существует для обратной совместимости с операционной системой Windows NT. Локальные экземпляры этих групп хранятся в базе данных SAM, как и локальные учетные записи Administrator и Guest.
Различные типы групп предназначены для того, чтобы администраторы не начали заниматься самостоятельным творчеством, хотя иногда это все же происходит. Типы групп существуют для совместимости, гибкости и минимизации объема данных, передаваемых при репликации. Ниже описаны различия между этими типами групп.
Встроенные
В классической операционной системе Windows NT и в операционной системе Windows Server 2003 некоторым группам предоставлены изначальные системные привилегии. Например, группа Backup Operators (Операторы архива) обладает системными привилегиями, необходимыми для перемещения файлов из архива и в архив независимо от прав владения и прав доступа к файлам. Эти группы существуют в разделе базы данных SAM, который называется Builtin. Пример показан на рис. 13.10.
:.\ Registry Editor
"3"3Hb MB ** ГмгЩ H*
"3
"3
[£] SAM
E3'£j SAM
S CJ Domans
® O Account
: a -C3 Builtin
. S £3 Ateses £j 00000220
•£3 00000221
□ 00000222
•£j 00000223
•0 00000226
Q 00000227 Q 00000228
■ QJ 00000228
•D 0000022C
:® Q Members
1^3 Administrators-£3 Backup OperatorsО Guests■ £51 Network Configuration Opera•Si Power Users£j Print Operators-£3 Remote Desktop Users'-I*! Repkator1£3 Users1^3 Administrators-£3 Backup OperatorsО Guests■ £51 Network Configuration Opera•Si Power Users£j Print Operators-£3 Remote Desktop Users'-I*! Repkator1£3 Users*c<iwe»»«tv3«^jwowww^*c<iwe»»«tv3«^jwowww^;в о ИИ
1^3 Administrators
-£3 Backup Operators
О Guests
■ £51 Network Configuration Opera
•Si Power Users
£j Print Operators
-£3 Remote Desktop Users'
-I*! Repkator1
£3 Users
1^3 Administrators
-£3 Backup Operators
О Guests
■ £51 Network Configuration Opera
•Si Power Users
£j Print Operators
-£3 Remote Desktop Users'
-I*! Repkator1
£3 Users
*c<iwe»»«tv3«^jwowww^
*c<iwe»»«tv3«^jwowww^
Рис. 13.10. Раздел Builtin базы данных SAM в окне редактора системного реестра
Эти группы создаются при каждой установке операционной системы Windows Server 2003 (или Windows ХР, что в данном контексте — одно и то же). При модернизации сервера до контроллера домена Windows Server 2003 существующая база данных SAM удаляется и создается новая база данных SAM, в которой присутствуют принятые по умолчанию встроенные группы.
Большинство системных привилегий, назначенных этим группам, хранятся в базе данных Secedit, но некоторые привилегии спрятаны в операционной системе глубже, чем тайник Бэтмена под особняком Уэйна. Встроенные группы невозможно удалить или переименовать. Администраторов стоит включать в эти группы только в том случае, если им необходим высокопривилегированный доступ к локальному компьютеру. Встроенные группы в базе данных Active Directory управляют доступом к контроллерам домена и компонентам Active Directory.
Локальные для компьютера группы (из базы данных SAM)
Распределенное управление серверами, входящими в домен, и классическими рабочими станциями Windows NT требовало двухуровневого решения.
Отвечающий за сервер администратор добавлялся во встроенную группу Server Operators (Операторы сервера) на локальном компьютере. Это давало администратору возможность управления локальной базой данных SAM без предоставления дополнительных привилегий в домене.
Выбранный оператор сервера создавал локальные для компьютера группы и добавлял их в списки контроля доступа для локальных ресурсов, например для файлов и каталогов NTFS, разделов системного реестра и принтеров. Операторы сервера заполняли локальные для компьютера группы, указывая отдельных пользователей и глобальные группы из домена.
Использование такого метода управления серверами приводило к созданию на каждом сервере уникального набора записей базы данных SAM, которые приходилось архивировать и сохранять. При отказе жесткого диска с операционной системой и невозможности его восстановления с ленты данные на других дисках сохранялись, но списки контроля доступа оказывались некорректными.
Кроме этого, попытка использования общей политики управления на разнородном множестве серверов требовала всеобщей вежливости. (Попробуйте объяснить независимому системному администратору, характер которого напоминает характер параноика в танке, что создание нестандартных локальных групп — это плохая идея.)
В операционной системе Windows Server 2003 предпринята попытка решить эту проблему с помощью отказа от использования локальных для компьютера групп. В режиме Windows 2000 Native доменные группы любого из трех типов могут быть добавлены в список контроля доступа к локальному компьютеру. Операторам локальных серверов может быть делегировано право на создание групп в Active Directory. Намного проще администрировать централизованный набор групп, и не придется беспокоиться о потере прав доступа к данным на локальных жестких дисках.
Локальные для домена группы
Локальные для домена группы являются идеальным носителем делегирования разрешений в Active Directory, поскольку они могут быть добавлены в списки контроля доступа только в пределах локального домена. Это позволяет администраторам одного домена создавать необходимые группы и не беспокоиться, что эти группы будут использованы некорректно администраторами из других доменов леса.
В локальные для домена группы могут входить члены из любого домена в пределах леса. Это позволяет делегировать разрешения администраторам и пользователям других доменов. Например, может существовать централизованная служба поддержки, которой необходимо предоставить право менять пароли в пределах всего предприятия. Предположим, что существует пять доменов (по одному для каждого континента). Вот что можно сделать.
Создайте локальную для домена группу в каждом домене. Назовите ее, например, Password Operators.
В корневом домене делегируйте группе Password Operators разрешение Password Reset.
Создайте в корневом домене универсальную группу Help Desk Operators.
Вложите группу Help Desk Operators из корневого домена в группу Password Operators из локального домена.
Членство в универсальных группах реплицируется по всему лесу, поэтому необходимость использования каждой универсальной группы придется оценивать отдельно. В этом примере состав группы Help Desk Operators не будет меняться слишком часто, поэтому добавление отдельных пользователей в эту группу вполне допустимо. Если список членов группы меняется достаточно часто, стоит рассмотреть альтернативные варианты, которые не предполагают добавление отдельных пользователей в универсальные группы.
При переключении леса на функциональный уровень 2 членство в универсальных группах реплицируется отдельно для каждого объекта. В таком случае можно не задумываться о размещении универсальных групп, но все-таки стоит подумать, нужно ли хранить на контроллерах домена Asia Pacific копию группы, которая используется исключительно в домене NorthAmerica.
Глобальные группы
Глобальные группы можно использовать как хранилища учетных записей пользователей и компьютеров в домене. В глобальные группы не могут входить члены других доменов, но они могут добавляться в списки контроля доступа в пределах всего леса. Преимуществом глобальных групп в Active Directory является возможность ограничения внешнего членства. Можно делегировать разрешения глобальной группе и быть уверенным, что другой администратор не добавит в группу внешнего пользователя, предоставив пользователю недопустимые привилегии. -
Глобальные группы можно включать в локальные для домена группы, универсальные группы и другие глобальные группы. Эту возможность можно использовать во многих ситуациях. Например, предположим, что в компании существует внутренняя группа аудиторов, которые принадлежат тому же отделу, но регистрируются с помощью учетных записей из доменов, соответствующих их континенту. Например, аудиторы из Киото регистрируются в домене AsiaPacif ic ит.д.
Аудиторам необходимо разрешение Audit для всех объектов Active Directory в каждом домене в пределах леса. Аудит является крайне привилегированной возможностью, которая не должна предоставляться случайным людям. Можно создать в каждом домене глобальную группу Auditors и предоставить этой группе разрешение Audit.
Но аудиторам может потребоваться доступ и к контекстам именования Configuration и Schema. Поскольку эти контексты именования назначены корневому домену леса, можно создать локальную для корневого домена группу, которая называется Central Auditing, и делегировать этой группе разрешение Audit для контекстов именования Configuration и Schema. Создание локальной для домена группы позволяет обеспечить невозможность ее использования за пределами корневого домена.
После этого включите глобальные группы Auditors из каждого домена в группу Central Auditing. Это предоставит членам группы возможность аудита всех объектов в соответствующих контейнерах. Еще одним преимуществом локальных для домена групп является невозможность просмотра списка членов группы Central Auditing администраторами локальных доменов.
Универсальные группы
У ниверсальные группы могут создаваться только после переключения домена в режим Windows 2000 Native. Преимуществом универсальных групп является их широкая область действия. В универсальные группы могут входить члены любого домена в пределах леса, и универсальные группы могут указываться в списках контроля доступа для любого объекта Active Directory любого домена в пределах леса.
Может возникнуть вопрос, зачем использовать глобальные группы, если универсальные группы предоставляют такую гибкость. В следующем разделе рассматриваются различия между глобальными и универсальными группами, а также принципы использования этих типов групп в правильно спроектированной системе. ■
Сравнение глобальных и универсальных групп
Для понимания принципов использования универсальных и глобальных групп стоит обратить внимание на использование протокола Kerberos контроллерами домена при распространении информации о членстве в группах на серверы и рабочие станции, входящие в домен.
Каждый объект группы в базе данных Active Directory имеет атрибут Member. В этом атрибуте содержатся характерные имена каждого члена группы. Объекты User имеют атрибут MemberOf, который содержит обратную ссылку на атрибут Member соответствующего объекта группы. Обратная ссылка используется исключительно для обеспечения ссылочной цело-
стности. Она не используется для проверки членства в группах. Членство в группах определяется в результате поиска в базе данных Active Directory и просмотра характерных имен пользователей в списке членов.
Например, если пользователь GWBush входит в группы Presidents, CmdrlnChief, Republican и Texans, то служба Local Security Authority (LSA) создаст для этого пользователя сертификат привилегий доступа (РАС), в котором указан его идентификатор безопасности (SID) и перечислены идентификаторы безопасности всех четырех групп. Кроме этого, LSA просканирует Active Directory для поиска всех групп, в которые входят указанные четыре группы. Если такие группы существуют, их идентификаторы безопасности также будут добавлены в сертификат привилегий доступа. После этого пользователь получит локальный доступ на основе суммы всех прав доступа, предоставленных каждой вложенной группе.
Вот здесь и вступают в игру различные типы групп. Информация о членах локальных для домена и глобальных групп хранится в локальном контексте именования Domain, а не в глобальном каталоге. С другой стороны, информация о членах универсальных групп хранится в глобальном каталоге. Эта разница может показаться незначительной, но она приводит к значительным последствиям.
Каждый контроллер домена хранит копию собственного контекста именования Domain. Этот контекст именования содержит списки членов локальных для домена и глобальных групп, но не содержит информации об универсальных группах.
Таким образом, запрос LDAP о членстве в группах, отправленный на стандартный контроллер домена, предоставит информацию только о локальных для домена и глобальных группах локального для контроллера домена.
Серверы глобального каталога хранят полную копию собственного контекста именования Domain и частичную копию каждого контекста именования Domain в пределах леса. Частичные копии контекстов именования содержат информацию о членстве в универсальных группах, но не содержат информации о локальных для домена и глобальных группах.
Таким образом, запрос LDAP о членстве в группах, отправленный на сервер глобального каталога, предоставит информацию о локальных для домена и глобальных группах собственного домена сервера глобального каталога и информацию об универсальных группах в пределах всего леса.
Любой контроллер домена, который не является сервером глобального каталога, должен обратиться к глобальному каталогу перед авторизацией пользователя. Если глобальный каталог недоступен, локальный администратор безопасности отказывается выдавать билет Kerberos. Вместо этого выдается сообщение об ошибке Authentication Denied (В аутентификации отказано) с кодом ошибки, который указывает на недоступность сервера глобального каталога. В операционной системе Windows Server 2003 стандартный контроллер домена может быть настроен на кэширование членства в универсальных группах. Дополнительная информация по этому вопросу приводится в главе 7, “Управление репликацией Active Directory”.
Просмотр отличий в списках членов групп
С помощью следующих нехитрых экспериментов можно увидеть различия в механизмах хранения членов групп.
В лабораторных условиях создайте два разных домена в пределах одного леса. Контроллер первого домена (корневого домена леса) является сервером глобального каталога. Контроллер второго домена является стандартным контроллером домена.
Переключите оба контроллера домена в режим Windows 2000 Native.
В каждом домене создайте универсальную группу.
Добавьте учетную запись Administrator из каждого домена в универсальную группу другого домена.
Откройте консоль Active Directory— Users and Computers (Active Directory— пользователи и компьютеры) на втором контроллере домена, зарегистрировавшись от имени администратора во втором домене.
Откройте окно свойств учетной записи Administrator и перейдите на вкладку Member Of (Член групп). Обратите внимание, что членство в универсальной группе корневого домена не указано. Это связано с тем, что контроллер домена не является сервером глобального каталога и не имеет доступа к копии контекста именования другого домена, где хранится атрибут Member объекта универсальной группы. Без этой информации он не может получить обратную ссылку MemberOf.
Откройте консоль Active Directory— Users and Computers (Active Directory— пользователи и компьютеры) на первом контроллере домена, зарегистрировавшись от имени администратора в первом домене.
Откройте окно свойств учетной записи Administrator^ перейдите на вкладку Member Of (Член групп). Обратите внимание, что членство в универсальной группе из второго домена указано. Это связано с тем, что контроллер домена одновременно является сервером глобального каталога, поэтому он в состоянии получить сведения о членах универсальной группы второго домена и создать обратную ссылку.
Не забывайте о различных методах хранения информации о членстве в группах при изучении следующих примеров, в которых описывается влияние членства в группах на права доступа в Active Directory. Существует всего три возможных сценария:
защита объекта Active Directory с помощью глобальной группы;
защита объекта Active Directory с помощью локальной для домена группы;
защита объекта Active Directory с помощью универсальной группы.
Защита объекта Active Directory с помощью глобальной группы
На схеме, показанной на рис. 13.11, для работающего по контракту администратора Eager Temp была создана учетная запись в организационной единице Phoenix в домене Company. com. Этот администратор входит в глобальную группу, которая называется PhxContractors. 1
Из-за инцидентов в прошлом, связанных с работающими по контракту администраторами, для группы PhxContractors в списке ACL организационной единицы Phoenix установлено право доступа Deny (Запретить) для создания дочерних объектов (Deny Create Child Object).
Администратор Eager Temp открывает консоль Active Directory— Users and Computers (Active Directory — пользователи и компьютеры), щелкает правой кнопкой мыши и выбирает из контекстного меню команду New=>User (Создать^Пользователь). Система выдает сообщение Access Denied (Доступ запрещен). В этом разделе описывается причина такого ответа.
Если коротко, то пользователь домена пытается создать объект в организационной единице того же домена. Пользователь входит в глобальную группу, которой было отказано в праве создавать новые объекты в организационной единице. В процедуре 13.3 описывается последовательность событий, которые блокируют доступ пользователю при попытке создания объекта.
Рис. 13.11. Схема Active Directory, на которой показаны группы и управляемые объекты
Процедура 13.3. Функциональное описание проверки пользователя и группы в пределах одного домена
При регистрации в домене пользователя Eager Temp служба LSA, первой обрабатывая запрос на регистрацию на контроллере домена, выполняет аутентификацию и начинает создание сертификата привилегий доступа (РАС). Для этого служба запрашивает в базе данных идентификатор безопасности (SID) пользователя. (Во всех примерах следите за сертификатом привилегий доступа. Он как маленькая девочка в красном платье из Списка Шиндлера. Очевидно, что он играет важную роль, но пока непонятно, в чем, собственно, эта роль заключается.)
После этого LSA запрашивает в базе данных Active Directory список групп, в атрибутах Member которых указано характерное имя пользователя. LSA обнаруживает одну группу, PhxContractors. С помощью запроса в Active Directory быстро предоставляется SID этой группы.
Затем LSA проверяет информацию о членстве в универсальных группах. Для этого выполняется поиск для пользователя Eager и для группы PhxContractors. Поиск выполняется средствами протокола LDAP с помощью запроса к серверу глобального каталога. Если на запрос в глобальный каталог возвращается информация о членстве в универсальных группах, LSA получает SID этой группы и выполняет поиск групп, в которые входит эта универсальная группа.
В этом случае пользователь Eager Temp не входит в универсальные группы, поэтому локальный администратор безопасности завершает создание сертификата привилегий доступа (РАС), добавляя привилегии, назначенные пользователю Eager, а также соответствующие ограничения учетной записи.
LSA передает РАС службе центра распространения ключей (Key Distribution Center — КОС), которая добавляет поле данных авторизации (Authorization Data) в билет TGT, который предоставляется пользователю Eager. Дополнительную информацию о билетах Kerberos и билетах TGT можно получить в главе И, “Безопасность доступа по сети и протокол Kerberos”.
Сетевой клиент на компьютере пользователя Eager кэширует билет TGT и возвращает его контроллеру домена для получения билета сеанса доступа. Этот билет необходим для выполнения поиска в базе данных Active Directory по протоколу LDAP. Полученный в результате билет содержит копию сертификата РАС из оригинального билета TGT.
Как только пользователь Eager Temp пытается создать нового пользователя в подразделении Phoenix, консоль Active Directory— Users and Computers (Active Directory — пользователи и компьютеры) отправляет команду Create Object (Создать объект) на контроллер домена, воспользовавшись безопасным соединением Remote Procedure Call (RPC). Вместе с запросом LDAP передается билет Kerberos, который содержит сертификат привилегий доступа (РАС).
После получения запроса Create Ob j ect (Создать объект) и связанного с ним билета Kerberos контроллер домена извлекает сертификат РАС и использует его для создания локального маркера доступа для пользователя Eager. Служба LSA на контроллере домена присоединяет маркер к потоку, который представляет пользователя.
Поток пользователя пытается получить доступ к базе данных Active Directory для создания объекта User в организационной единице Phoenix. Монитор ссылок безопасности (SRM) сравнивает маркер доступа, связанный с потоком, с содержимым списка DACL в дескрипторе безопасности организационной единицы Phoenix. SRM обнаруживает, что идентификатор безопасности пользователя Eager Temp совпадает с SID, который связан с записью контроля доступа Deny Create Child Object (Запретить создание дочерних объектов). Выполнение запрошенной операции прерывается.
Последовательность действий в итоге завершается сообщением Access Denied (Доступ запрещен), отображающимся на консоли Active Directory — Users and Computers (Active Directory — пользователи и компьютеры) на рабочей станции пользователя Eager Temp.
Можно сделать вывод, что способность пользователя получать доступ к объектам в базе данных Active Directory зависит от сертификата привилегий доступа (РАС) в билете TGT, выпущенном при первой аутентификации пользователя в домене. Сертификат привилегий доступа содержит идентификаторы безопасности (SID) групп, полученные при сканировании локального контекста именования Domain и глобального каталога.
Расширим рассматриваемую область и посмотрим, что происходит, когда администратор пытается получить доступ к объекту в базе данных Active Directory из другого домена. В этом случае будет показано, как служба LSA и центр распространения ключей (КОС) из разных доменов обмениваются информацией о членстве в группах.-
Защита объекта Active Directory с помощью локальной для домена группы .
На рис. 13.12 показаны два домена, Company. com и Subsidiary. com, которые совместно используют доверительное отношение корневого домена к дереву. Это значит, что домены совместно используют контексты именования Configuration и Schema. (При использовании доверительного отношения между лесами домены связаны транзитивным доверительным отношением по протоколу Kerberos, но используют разные контексты именования Configuration и Schema.)
В такой ситуации управляющий персонал обеих компаний принял решение о распределении обязанностей между отделами информационных технологий в обеих компаниях. Для этого администратор домена Subsidiary создает локальную для домена группу Outside Admins и предоставляет этой группе набор разрешений для создания и изменения объектов в домене Subsidiary.
dc=Company,dc=comdc=Company,dc=com
dc=Company,dc=com
dc=Company,dc=com
Доверительноеотношение корневогодомена к дереву(транзитивное)
dc=Subsidiary,dc=com
Группе Outside Adminsпредоставленыограниченные права вэтом домене
Tlightly
OU=Houston
Рис. 13.12. Лес из двух доменов. Администратор из одного домена входит в группу второго домена
Администратор в домене Subsidiary добавляет администратора Теда Лайтли из домена Company в группу Outside Admins. (Администратор домена Subsidiary не смог бы сделать это с помощью глобальной группы, так как в глобальные группы нельзя включать членов других доменов.)
Пользователь Ted проверяет новые права, пытаясь создать объект пользователя в домене Subsidiary. Попытка завершается успешно. В этом разделе рассматривается, почему это произошло.
Вкратце ситуация выглядит так: пользователь из доверенного домена добавлен в группу в другом домене. Группе предоставлены ограниченные административные привилегии в локальном домене. Пользователь может применять разрешения, предоставленные группе. В процедуре 13.4 описана подробная последовательность событий.
Процедура 13.4. Проверка прав доступа пользователей и групп из разных доменов при использовании локальных для домена групп
Когда пользователь Ted регистрируется в домене Company, служба LSA на регистрационном сервере создает сертификат привилегий доступа (РАС). Сначала сканируется собственная копия контекста именования Domain. После этого сканируется глобальный каталог. Ни в том, ни в другом случае членство пользователя Ted в группе Outside Admins в домене Subsidiary не будет обнаружено. (В глобальном каталоге хранится информация только о членстве в универсальных группах.)
Пользователь Ted открывает консоль Active Directory— Users and Computers (Active Directory — пользователи и компьютеры) и подключается к домену Subsidiary для создания объекта пользователя. Сетевой клиент на компьютере пользователя должен получить билет для контроллера домена в домене Subsidiary. Клиент пытается получить билет у регистрационного сервера в домене Company.
Контроллер домена Company не может ответить на запрос создания билета, поскольку он не имеет доступа к контексту именования домена Subsidiary. Вместо этого контроллер домена от имени пользователя получает в домене Subsidiary билет TGT и передает его клиенту в ответ на запрос.
После получения запроса на выдачу билета TGT контроллер домена Subsidiary создает сертификат РАС для пользователя Ted, сканируя собственный контекст именования Domain и глобальный каталог Для получения информации о членстве пользователя Ted в группах. Контроллер домена обнаруживает информацию о членстве пользователя Ted в локальной для домена группе Outside Admins. Идентификатор безопасности этой группы добавляется в оригинальный сертификат привилегий доступа. Кроме этого, в сертификат РАС добавляются все привилегии и ограничения учетной записи, которые относятся к пользователю Ted в домене Subsidiary.
Служба KDC на контроллере домена Subsidiary добавляет созданный РАС в билет TGT для пользователя Ted и передает билет TGT запросившему контроллеру домена Company. Контроллер домена передает билет TGT клиенту Kerberos на компьютере пользователя Ted.
Клиент передает билет TGT из домена Subsidiary контроллеру домена Subsidiary, запрашивая билет сеанса доступа LDAP. Служба LSA на контроллере домена Subsidiary извлекает РАС из билета TGT и добавляет его в билет.
Как только пользователь Ted пытается создать новый объект пользователя, консоль Active Directory — Users and Computers (Active Directory — пользователи и компьютеры) отправляет билет Kerberos вместе с командой Create Object. Контроллер домена Subsidiary извлекает сертификат РАС из билета и использует его для создания маркера доступа для пользователя Ted.
Сертификат привилегий доступа содержит идентификатор безопасности группы Outside Admins, которой предоставлены права на создание дочерних объектов в домене Subsidiary, поэтому монитор ссылок безопасности (SRM) предоставляет пользователю Ted возможность создания новой учетной записи пользователя.
Таким образом, пользователи из одного домена в пределах леса, которые являются членами локальных для домена групп из другого домена, получают права доступа, предоставленные группе, так как сертификат привилегий доступа (РАС) изменяется в результате междоменной аутентификации.
Для глобальных групп использование таких механизмов не требуется, поскольку пользователи одного домена не могут быть добавлены в глобальные группы в других доменах. Кроме этого, локальные для домена группы не могут входить в глобальные группы, так как пользователи из доверяющих доменов могут быть членами локальных для домена групп.
Теперь все готово для рассмотрения сложного сценария, в котором пользователь из глобальной группы в одном домене, вложенной в универсальную группу в другом домене, пытается получить доступ к объекту Active Directory, защищенному с помощью этой универсальной группы. Готовы? Тогда поехали.
Защита объекта Active Directory с помощью универсальной группы
На рис. 13.13 показана схема, на которой администратор из домена Company воспользовался несколькими возможностями управления группами и настроил права доступа для организационной единицы в домене Subsidiary. Администратор внес следующие изменения.
Создал глобальные группы в обоих доменах для использования в целях внутридоменно- го администрирования. Администратор домена Company может создавать группы в домене Subsidiary, если администратор входит в группу Enterprise Admins (Администраторы предприятия) или в группы, которые вложены в группу Enterprise Admins.
Создал универсальную группу в домене Subsidiary. Универсальные группы могут быть созданы в любом домене, который работает в режиме Windows 2000 Native.
Делегировал универсальной группе разрешение на создание дочерних объектов (Create Child Objects) в организационной единице. Универсальные группы могут быть использованы в качестве участников системы безопасности для любого объекта в пределах леса.
Вложил глобальные группы из обоих доменов в универсальную группу из домена Subsidiary. В режиме Windows 2000 Native существует множество возможностей для домена по вложению групп.
В примере, описанном в процедуре 13.5, показана последовательность событий при попытке администратора из домена Company получить доступ к организационной единице в домене Subsidiary. Администратор входит в глобальную группу из домена Company, которая вложена в универсальную группу из домена Subsidiary.
Доверительное accompany, dc=com отношение корневого домена к дереву (транзитивное)Доверительное accompany, dc=com отношение корневого домена к дереву (транзитивное)dc=Subsidiary,dc=comdc=Subsidiary,dc=comOU=PhoenixOU=PhoenixOU=HoustonOU=HoustonГруппе Forest Admins были предоставлены права для этой организационной единицыГруппе Forest Admins были предоставлены права для этой организационной единицы
Доверительное accompany, dc=com отношение корневого домена к дереву (транзитивное)
Доверительное accompany, dc=com отношение корневого домена к дереву (транзитивное)
dc=Subsidiary,dc=com
dc=Subsidiary,dc=com
OU=Phoenix
OU=Phoenix
OU=Houston
OU=Houston
Группе Forest Admins были предоставлены права для этой организационной единицы
Группе Forest Admins были предоставлены права для этой организационной единицы
OU=Global GroupsOU=Global GroupsCompany AdminsCompany AdminsOU=Global GroupsOU=Global GroupsOU=Universal GroupsOU=Universal GroupsForestAdmins ।ForestAdmins ।Subsidiary AdminsSubsidiary Admins
OU=Global Groups
OU=Global Groups
Company Admins
Company Admins
OU=Global Groups
OU=Global Groups
OU=Universal Groups
OU=Universal Groups
Forest
Admins ।
Forest
Admins ।
Subsidiary Admins
Subsidiary Admins
Группы Company
Admins И Subsidiary Admins ВХОДЯТ в эту группу
Рис. 13.13. Администратор из одного домена, входящий в универсальную группу, пытается получить доступ к организационной единице из другого домена. Универсальная группа указана в списке ACL для организационной единицы
Процедура 13.5. Проверка прав доступа пользователя и группы из разных доменов при использовании универсальных групп
Когда администратор регистрируется в домене Company, служба LSA на контроллере домена Company проверяет членство в группах в локальном контексте именования Domain и в глобальном каталоге. Локальный администратор безопасности обнаруживает членство пользователя в глобальной группе в локальном контексте именования Domain и при сканировании глобального каталога обнаруживает, что глобальная группа входит в универсальную группу.
Служба LSA добавляет идентификаторы безопасности (SID) этих групп в сертификат привилегий доступа (РАС), который отправляется службе распространения ключей (KDC).
Центр распространения ключей добавляет сертификат привилегий доступа в билет TGT, который передает клиенту.
Когда администратор активизирует консоль Active Directory — Users and Computers (Active Directory — пользователи и компьютеры) и подключается к домену Subsidiary, сетевой клиент запрашивает билет для контроллера домена Subsidiary у регистрационного сервера в домене Company.
Контроллер домена Company не может выдать билет, поэтому он получает билет TGT в домене Subsidiary от имени пользователя.
Служба LSA на контроллере домена Subs idiary создает сертификат РАС для администратора, сканируя собственный контекст именования Domain и глобальный каталог. Ни там, ни там не хранится информация о членстве в глобальной группе, поэтому универсальная группа, в которую входит глобальная группа, также не обнаруживается. Но это ничего не значит, так как идентификаторы безопасности доступны в оригинальном РАС. Служба LSA добавляет все локальные привилегии и ограничения, связанные с учетной записью, и возвращает получившийся сертификат РАС центру распространения ключей.
Центр распространения ключей возвращает билет TGT клиенту, а клиент использует билет TGT для получения билета сеанса доступа LDAP к контроллеру домена Subsidiary. Служба LSA на контроллере домена Subsidiary создает локальный маркер доступа на основе содержимого сертификата РАС. Монитор ссылок безопасности обнаруживает совпадение с идентификатором безопасности универсальной группы в маркере доступа и записи контроля доступа в DACL для организационной единицы и предоставляет пользователю доступ.
Если пользователь является членом универсальной группы в любом домене или членом группы, вложенной в универсальную в любом домене, он получает разрешения, предоставленные универсальной группе в любом домене.
Резюме относительно возможностей групп
В операционной системе Windows Server 2003 поддерживается три типа групп: локальные для домена, глобальные и универсальные. На основе предыдущих примеров можно выделить несколько основных принципов проектирования.
Для защиты объектов Active Directory, к которым должны получать доступ только пользователи внутри домена, необходимо использовать локальные для домена и глобальные группы.
Для защиты объектов Active Directory, к которым должны получать доступ пользователи из других доменов, необходимо использовать универсальные группы или локальные для домена группы, в которые входят универсальные группы.
Убедитесь, что пользователи имеют доступ к глобальному каталогу в момент регистрации. Это позволяет полностью проверить членство в универсальных группах. Если сервер глобального каталога недоступен в пределах сайта, настройте стандартные контроллеры домена в пределах сайта на кэширование информации о членстве в универсальных группах.
Минимизируйте изменения членства в универсальных группах, чтобы сократить объем данных, передаваемый при репликации в пределах всего леса. В меньшей мере эта проблема проявляется при переключении леса на функциональный уровень 2, на котором выполняется раздельная репликация членов групп.
Не пытайтесь найти информацию о членстве пользователей в группах из других доменов в свойствах учетной записи пользователя. При опросе сервера глобального каталога и при опросе контроллера домена будут выданы разные результаты.
Может показаться, что сочетание слов “простое управление информационными системами” является бессмысленным, и, скорее всего, это так и есть, но по крайней мере можно стремиться к элегантности и экономии. При управлении Active Directory старайтесь использовать минимальное количество групп. Старайтесь не добавлять пользователей в группу Enterprise Admins (Администраторы предприятия), поскольку этой группе предоставляются слишком широкие привилегии. Создайте группы локальных администраторов подразделений и предоставляйте им только те права, которые действительно необходимы.
Завершающий совет: при добавлении пользователей и групп из одного домена в группу из другого домена система поддерживает ссылочную целостность, создавая фантомный объект в локальном контексте именования Domain. В фантомном объекте содержится несколько атрибутов (SID, GUID и характерное имя) внешнего участника системы безопасности. Фантомные объекты отображаются на консоли Active Directory— Users and Computers (Active Directory — пользователи и компьютеры) в контейнере Foreign Security Principals.
При изменении характерного имени участника системы безопасности (это происходит при перемещении или переименовании объекта) система должна изменить фантомный объект в другом домене для отображения изменений характерного имени. До этого момента в поле Member в окне свойств группы отображается прежнее характерное имя. Меняется внешний вид пиктограммы, указывая на недействительность имени.
Задача изменения содержимого фантомного объекта возлагается на хозяина инфраструктуры (Infrastructure Master). В операционной системе Windows 2000 хозяин инфраструктуры выполнял эту задачу слишком редко, поэтому изменение имени занимало несколько часов. В операционной системе Windows Server 2003 можно рассчитывать на быстрое изменение имени. Скорость изменения зависит от длительности интервала межсайтовой репликации.
Эго незначительное изменение в работе системы, но оно позволяет устранить раздражающий недостаток.
Учетные записи служб
Для запуска фоновой службы необходим контекст безопасности учетной записи. В операционной системе Windows NT службы работают от имени учетной записи Localsystem. Это приводит к проблемам в системе безопасности, так как процессам в контексте безопасности учетной записи Localsystem предоставляются практически неограниченные привилегии.
В операционной системе Windows Server 2003 компания Microsoft решила устранить это уязвимое место, добавив две учетные записи служб.
LocalService. Эта учетная запись предоставляет контекст безопасности для нескольких служб, которые получат доступ к локальным системным ресурсам.
Networkservice. Эта учетная запись предоставляет контекст безопасности для нескольких служб, которые получат доступ к сетевым ресурсам.
Эти учетные записи имеют собственные профили в каталоге Documents and Settings, поэтому они могут получать сертификаты открытого ключа. Это позволяет службам создавать цифровые подписи для файлов и передаваемых по сети данных.
Если просмотреть список служб на консоли Services .msc, то можно обратить внимание, что от имени учетной записи Localsystem работает большинство служб. Учетная запись LocalService является владельцем нескольких процессов, например Alerter, Remote Registry и Web Client. Учетная запись Networkservice является владельцем клиента DNS, процессов RPC Locator, License Logging и нескольких других. В будущем можно ожидать, что роль этих учетных записей возрастет; но на данный момент локальные учетные записи служб не в состоянии предотвратить большинство атак.
Использование службы SLS
и команды RunAs
В примерах, приведенных в этой главе, локальные администраторы выполняют ежедневные операции от имени собственных учетных записей. Обычно этого делать не стоит. При регистрации от имени учетной записи администратора может произойти достаточное количество неприятных вещей. Вирусы могут активизироваться и внести значительные изменения в систему. Случайные ошибки могут привести к значительному повреждению системы. Забыв завершить сеанс на рабочей станции, администратор может предоставить доступ злоумышленнику. И так далее.
В операционной системе Windows Server 2003 существует служба запуска программ от имени другого пользователя (Secondary Logon Service — SLS), которая позволяет входить в систему от имени учетной записи обычного пользователя и запускать приложения от имени этой учетной записи для выполнения административных задач. Это напоминает команду su или sudo (привилегии суперпользователя) при работе в операционной системе UNIX, но команда реализована немного по-другому.
Служба SLS устанавливается по умолчанию и запускается в процессе загрузки компьютера. Служба запускается с помощью выполняемого файла Service.exe и находится в библиотеке Seclogon.dll.
Синтаксис команды RunAs
Одним из самых простых способов использования службы SLS является запуск интерпретатора командной строки и использование команды RunAs. Рассмотрим синтаксис этой команды:
runas /и:administrator@company.com название_команды runas /и:company\administrator название_команды
Если в качестве названия команды ввести cmd, можно запустить интерпретатор командной строки в другом контексте безопасности. Будет выдан запрос на ввод пароля и откроется окно интерпретатора, в заголовке которого будет показано имя альтернативной учетной записи. Запущенные из этого интерпретатора приложения также будут работать в альтернативном контексте безопасности. Например, с помощью команды dsa.msc можно активизировать консоль Active Directory — Users and Computers (Active Directory — пользователи и компьютеры). При активизации консоли будут использованы аутентификационные данные администратора, что позволит выполнять привилегированные операции.
Puc. 13.14. Окно Run As (Запуск от имени), открытое из оболочки ExplorerPuc. 13.14. Окно Run As (Запуск от имени), открытое из оболочки ExplorerUwnaew. .| Q COHPANVtAdmnstrator~3JPeword:|| OK | Cancel jUwnaew. .| Q COHPANVtAdmnstrator~3JPeword:|| OK | Cancel jЕсли отдается предпочтение использованию оболочки Explorer (Проводник), альтернативные регистрационные данные можно указать, щелкнув правой кнопкой мыши на пиктограмме приложения и одновременно удерживая нажатой клавишу <Shift>. При этом в контекстном меню появится команда RunAs (Запуск от имени). Выбор этой команды приведет к появлению окна Run As (Запуск от имени), в котором можно ввести альтернативные аутентификационные данные (рис. 13.14).
Puc. 13.14. Окно Run As (Запуск от имени), открытое из оболочки Explorer
Puc. 13.14. Окно Run As (Запуск от имени), открытое из оболочки Explorer
Uwnaew. .| Q COHPANVtAdmnstrator~3J
Peword:|
| OK | Cancel j
Uwnaew. .| Q COHPANVtAdmnstrator~3J
Peword:|
| OK | Cancel j
Профили и команда RunAs
По умолчанию команда RunAs запускает приложение с использованием профиля пользователя, указанного с помощью параметра /и:. В операционной системе Windows2000, если пользователь не был указан явно, команда RunAs использовала профиль Default User. Использование собственного пользовательского профиля позволяет обеспечить доступ к пользовательским элементам оболочки, а не к элементам, принадлежащим профилю Default User.
Существует параметр /noprofile, который позволяет использовать профиль Default User вместо профиля пользователя. Это приводит к ускорению запуска приложения, если пользователь не имеет локального профиля на компьютере, но использование этого параметра может привести к неопределенному поведению при обращении приложения к стандартным элементам оболочки. Если используется параметр /noprofile, внимательно следите за местом сохранения документов.
Параметры команды RunAs
Команда RunAs предоставляет ряд других полезных параметров.
/env. Использовать текущие переменные среды, а не переменные среды альтернативного пользователя. Этот параметр может пригодиться при устранении неисправностей в работе приложения на локальной рабочей станции пользователя.
/savecred. Открыть окно с сохраненными регистрационными данными указанного пользователя, если такие данные существуют. Этот параметр полезен при работе на портативном компьютере, не подключенном к сети, и необходимости запуска консоли от имени учетной записи администратора с использованием кэшированных регистрационных данных.
/smartcard. Использовать аутентификацию по смарт-карте вместо стандартных протоколов аутентификации Kerberos и NTLMv2. Это новая возможность операционной системы Windows Server 2003, которая значительно упрощает администрирование сети в организациях с аутентификацией по смарт-картам.
/netonly. Использовать те же регистрационные данные, что и при регистрации на рабочей станции. Этот параметр позволяет избежать проблем при запуске приложения по сети с использованием регистрационных данных, отличных от тех, которые использовались при создании соединения.
При создании сетевого соединения с консоли доступ к нему будет возможен только с консоли, но не с помощью оболочки Explorer. Например, можно, воспользовавшись расширенными привилегиями, смонтировать сетевой диск для совместного использования с помощью команды net use * \\server_name. company. com\c$. Установка соединения произойдет успешно, поскольку указаны правильные регистрационные данные. Но если перейти в окно Му Computer (Мой компьютер) и попытаться просмотреть содержимое диска, то можно заметить, что доступ к диску невозможен, так как оболочка все еще работает с привилегиями пользовательской учетной записи.
Будьте особенно внимательны при запуске с помощью команды RunAs пользовательских интерфейсов из командной строки, которые непосредственно связываются с оболочкой Explorer. Например, если автор этой книги использует интерпретатор командной строки и ему необходимо графическое представление содержимого каталога, он вводит команду start, (start и точка) в приглашении командной строки. Откроется окно Му Computer (Мой компьютер), в котором отображается содержимое текущего каталога. Если выполнить эту операцию с использованием команды RunAs, окно откроется, но контекст безопасности все равно будет соответствовать учетной записи пользователя, которая использовалась при регистрации.
Если необходимо повысить привилегии и для оболочки, завершите работу Explorer и запустите его из Task Manager (Диспетчер задач) с использованием команды RunAs. Необходимая последовательность действий приведена в процедуре 13.6.
Процедура 13.6. Запуск оболочки Explorer с помощью команды RunAs
Откройте окно Task Manager (Диспетчер задач). Для этого нажмите комбинацию клавиш <Ctrl+Alt+Del> и щелкните на кнопке Task Manager (Диспетчер задач).
Перейдите на вкладку Processes (Процессы).
Выделите Explorer и щелкните на кнопке End Process (Завершить процесс). Подтвердите необходимость завершения процесса.
После завершения работы Explorer из меню Task Manager (Диспетчер задач) выберите команду File^Run (Файлс>Выполнить) и запустите Explorer с помощью следующей команды: runas /и:administrator@company.com explorer.exe
После запуска оболочки Explorer некоторые компоненты, например строка состояния и область уведомлений, продолжают работать в оригинальном контексте безопасности, поэтому они становятся недоступными для оболочки Explorer.
Использование WMI для уведомления о событиях Active Directory
Многие компоненты Active Directory сигнализируют о проблемах, записывая сообщения в журнал событий. Иногда полезно, чтобы контроллер домена уведомлял о таких событиях, избавляя администратора от постоянного просмотра журналов. Такое уведомление может быть реализовано средствами инструментария управления Windows (Windows Management Instrumentation —WMI).-
Инструментарий WMI в операционной системе Windows Server 2003 позволяет получить доступ практически ко всей информации о работе компьютера, начиная с состояния сетевых соединений и заканчивая объемом свободного дискового пространства и температурой центрального процессора. Для получения информации достаточно отправить запрос.
Справочное руководство по инструментарию управления Windows
Полное описание инструментария WMI в этой книге не приводится. В качестве отличного справочного руководства можно порекомендовать Windows Management Instrumentation (WMi) от Мэттью Лэви (Matthew Lavy) и Эшли Меггит (Ashley Meggitt).
Инструментарий WMI предоставляет обработчик событий, который запускает триггер в случае выполнения операции интересующим элементом или выхода элемента за рамки предельных значений. Обработчик событий можно опрашивать с помощью сценария. Код сценария “ожидает” указанного события в обработчике событий WMI. Такой сценарий называется потребителем события (event consumer). Создав собственный потребитель событий, можно настроить сервер на уведомление о появлении интересующего события. Это дает возможность активно следить за появлением проблем.
Ниже представлен пример кода, которым создается потребитель события для журнала событий. Сценарий использует интерфейс MAPI для отправки сообщения при появлении в журнале соответствующего события. (Оператор сценария Set Events разбит на несколько строк в связи с ограничением ширины страницы.) Ниже приведен код потребителя событий:
Set Events = GetObject("WinMgmts:{(Security)}").ExecNotificationQuery ^("select * from InstanceCreationEvent where Targetinstance
^. ISA 1Win32_NTLogEvent'")
Do
Set NTEvent = Events.nextevent
Notify (NTEvent.Tar.getlnstance .Message) Loop
Funstion Notify(Subject)
Set objSession = CreateObject("mapi.session") objSession.Logon ("Microsoft Outlook Internet Settings") Set objMessage = objSession.Outbox.Messages.Add Set objRecipient = objMessage.Recipients.Add objMessage.subject = "Произошло событие" objMessage.Test = Subject objRecipient.Name = "administrator@company.com" objRecipient.Type = 1 objRecipient.Resolve objMessage.Send Wscript.Echo "Сообщение успешно отправлено!" objSession.Logoff
End Function
Рассмотрим некоторые интересные моменты сценария.
Запись WinMgmts: вызывает интерфейс WMI, который является поставщиком СОМ (COM provider).
Запись (Security) позволяет сценарию видеть изменения в журнале безопасности. (WMI требует явного указания на использование привилегированных операций, даже если такое право уже предоставлено текущей учетной записью.) Для просмотра журнала безопасности необходимо иметь права администратора, поэтому при регистрации от имени стандартной учетной записи придется воспользоваться командой RunAs.
Запись ExecNotif icationQuery отправляет запрос на языке WQL обработчику событий WMI. Обработчик событий в ответ на запрос создает сеанс для потребителя.
Метод .NextEvent заставляет обработчик событий включать триггер при появлении события.
Подпрограмма Not i fy использует стандартные команды интерфейса MAPI для создания сообщения электронной почты.
Это простой пример использования инструментария WMI для упрощения административных операций. Поэкспериментируйте в собственной среде для поиска методов экономии времени. Такая оптимизация может привести к тому, что у администратора время от времени будут появляться незапланированные выходные.
В следующей главе
На этом завершается обсуждение службы Active Directory (по крайней мере, непосредственное обсуждение). Практически все возможности Windows Server 2003 так или иначе завязаны на Active Directory, поэтому объекты, LDAP и репликация будут затрагиваться и в следующих главах.
С точки зрения развертывания операционной системы Windows Server 2003 в пределах предприятия теперь можно начинать настройку инфраструктуры: файловых систем, сетей и т.д. В следующей главе настройка инфраструктуры рассматривается с точки зрения подсистемы хранения данных.
1414Настройка подсистемы хранения данных
14
14
Н
а фундаментальном уровне задача системного администратора заключается в предоставлении данных в любой форме, затребованной пользователем.
Компания IBM недавно праздновала 25-ю годовщину выхода компьютера IBM PC. Оригинальная модель персонального компьютера могла хранить 128 Кбайт данных на гибком диске диаметром 5,25 дюйма и поддерживала загрузку с магнитной ленты. После этого компания IBM выпустила модель XT, которая поддерживала большой жесткий диск объемом 5 Мбайт, который гремел, как стиральная машина, и стоил, как автомобиль.
Объемы жестких дисков значительно выросли за последние годы, а цены, наоборот, снизились. На сервере, который хранит файлы автора этой книги, установлен массив жестких дисков по 80 Гбайт. При этом каждый диск стоит около 200 долларов. Удовлетворен ли я таким объемом? Нет. Требования к подсистеме хранения данных растут постоянно.
Каждый раз, когда профессионал находит нового клиента, конструкторская фирма проектирует новую фабрику, доктор получает цифровой рентгеновский снимок пациента или рекламное агентство создает новую мультимедиапрезентацию, еще одна порция информации попадает в огромную “пасть” того, что называется подсистемой хранения.
Объем данных постоянно растет. Но практически ничто не удаляется. Пользователи обращаются с клавишей <Delete>, как будто она покрыта контактной взрывчаткой. Они сохраняют, сохраняют и сохраняют, пока администратор не откажется хранить еще больший объем бесполезных данных и не закрутит гайки в квотах дискового пространства или не откажется покупать дополнительные жесткие диски. Такие компании, как EMC, Compaq и IBM, ведут войны за контроль хотя бы над долей этого рынка.
Альтернативные варианты подсистем хранения можно разделить на следующие категории (в каждой категории оказывается огромное количество предложений).
Подсистема хранения на фиксированных дисках. В эту категорию попадают жесткие диски, подключаемые по шине, которые не поддерживают удаление носителя информации, например интерфейсы IDE, АТА и SCSI.
Подсистема хранения, поддерживающая отключение носителя информации. В эту категорию попадают жесткие диски, подключаемые по гибкой шине, например FireWire, USB и PCMCIA. Также это относится к твердотельным носителям.
Подсистема хранения на сменных носителях. В эту категорию попадают приводы со сменным носителем информации, например приводы компакт-дисков, дисков CD-RW, DVD, DVD-RAM, Zip, JAZ, Orb и магнитооптических дисков, а также приводы гибких дисков, гибких дисков большого объема и др.
Ленточная подсистема хранения. В эту категорию попадают практически все вообразимые устройства, в которых конструктор реализовал способ протягивания пластиковой ленты, покрытой оксидом металла, по поверхности магнитной головки.
В этой главе подробно рассматривается подсистема хранения на основе жестких дисков. Особое внимание уделяется работе диспетчера логических дисков (Logical Dish Manager — LDM). Компания Microsoft лицензировала технологию LDM у компании Veritas Software. Диспетчер LDM отслеживает установленные диски, их разбиение на разделы и необходимые методы ввода-вывода. Кроме этого, диспетчер LDM обеспечивает отказоустойчивость и восстановление данных.
Отключаемые диски и сменные носители управляются службой RSM (Removable Storage Management — служба управления сменными носителями). Эта служба также обеспечивает работу устройств чтения и записи магнитных лент. В большинстве случаев служба RSM не предназначена для работы с приводами на основе вращающегося шпинделя. Эта служба позволяет управлять магазинами компакт-дисков, но при обычных операциях с компакт-дисками она не используется.
В этой главе рассматриваются следующие темы.
Функциональное описание диспетчера логических дисков LDM
Изменения, вносимые диспетчером LDM
Модернизация Windows NT 4.0 до Windows 2000
Начальная конфигурация диска
Создание разделов и томов
Восстановление отказавших отказоустойчивых дисков
Кроме этого, 64-разрядные версии операционных систем Windows Server 2003 и Windows ХР поддерживают новый метод управления дисками, принятый на платформе Itanium. Этот метод называется таблица GPT (GUID Partition Table). В главе 2, “Модернизация и автоматизированная установка”, рассказано, как использовать интерфейс EFI (Extensible Firmware Interface) для настройки подсистемы хранения на компьютере Itanium. Целый раздел этой главы посвящен настройке подсистемы хранения на основе таблиц GPT после инициализации.
Дополнительная информация об аппаратных средствах подсистемы хранения доступна на сайте Storage Review по адресу www. storagereview.com. На этом сайте появляется самая актуальная информация о жестких дисках и других носителях информации, включая великолепные непредвзятые технические обзоры.
Кроме этого, рекомендуем посетить сайт www.storage.ibm.com/hdd/support/ download.htm и загрузить утилиту Drive Fitness Test от компании IBM. Утилита предоставляет быстрый способ тестирования различных параметров жесткого диска.
Новые возможности операционной системы Windows Server 2003
Самым значительным отличием операционной системы Windows Server 2003 с точки зрения подсистемы хранения является поддержка компьютеров Itanium и их системы разделов GPT. Кроме этого, предоставляется несколько возможностей, упрощающих работу на архи-
тектуре IA32. Но одно из этих улучшений немного мешает обратной совместимости. Ниже перечислены эти новые возможности.
Расширяемые разделы. В операционной системе Windows 2000 для добавления дискового пространства к тому требовалось преобразование базового диска в динамический. В операционной системе Windows Server 2003 поддерживается расширение базовых разделов. Это справедливо и для системного раздела.
Улучшенная модернизация динамических дисков. При преобразовании в динамический диск запись MBR модифицируется для удаления всех необязательных-записей в таблице разделов. Это позволяет отказаться от произвольных ограничений на использование динамических дисков.
Утилита Diskpart. Новая утилита, Diskpart, позволяет выполнять все операции над дисками из командной строки. Эта возможность ожидалась очень давно. Теперь можно создать сценарий для полностью автоматической установки операционной системы Windows Server 2003, включая дополнительные разделы.
Возможности создания дискового хранилища на основе SAN. Оснастка Storage Management for SANs (Управление сетями хранилищ данных) предоставляет администратору возможность настройки и управления окружением SAN.
Отказ от поддержки классических отказоустойчивых массивов дисков. А вот и хорошие и плохие новости. Хорошая новость — код диспетчера логических дисков значительно модифицирован для повышения производительности. Измерения производительности подсистемы ввода-вывода показывают, что операционная система Windows Server 2003 работает значительно быстрее Windows 2000, которая, в свою очередь, работала быстрее Windows 9х. Плохая новость — эти изменения нарушили обратную совместимость с классическими отказоустойчивыми массивами дисков Windows NT 4.0.
Последний пункт требует более подробного обсуждения. В операционной системе Windows 2000 поддерживалась модернизация сервера с отказоустойчивым массивом дисков, если он не содержал зеркало системного раздела. После преобразования диска в динамический диск можно было преобразовать отказоустойчивый массив в динамический том.
Операционная система Windows Server 2003 требует удаления составного или чередующегося отказоустойчивого массива до модернизации. Для удаления отказоустойчивого массива необходимо создать резервную копию данных и удалить массив, выполнить модернизацию, преобразовать диски в динамические, настроить том и восстановить данные из резервной копии.
Если отказоустойчивый массив используется для зеркалирования диска операционной системы Windows NT, необходимо разбить зеркало, выполнить модернизацию, преобразовать диски в динамические и восстановить зеркало.
При попытке модернизации системы с отказоустойчивым массивом дисков сразу после запуска программы установки будет выдано сообщение об ошибке. Смысл сообщения немного запутан, поскольку в сообщении указываются базовые диски Windows NT 4.0, а должен быть указан отказоустойчивый массив Windows NT 4.0. Если операционная система находится на зеркалированном диске, такая конфигурация рассматривается как критическая ошибка, делающая модернизацию невозможной. Если на зеркалированном томе (mirrored), томе с чередованием (striped) или составном (volume span) томе хранятся данные, ошибка рассматривается как предупреждение. Если продолжить модернизацию, отказоустойчивый массив с данными получит букву диска, но окажется недоступным.
Если до модернизации не была создана резервная копия данных, можно воспользоваться специальной возможностью. На установочном компакт-диске Windows Server 2003 в составе Support Tools предоставляется утилита f tonline, которая позволяет смонтировать отказоустойчивый массив в режиме только для чтения и восстановить данные.
Описание подсистемы хранения
Windows Server 2003
Подсистема хранения Windows Server 2003 поддерживает различные схемы разбиения дисков на разделы, которые компания Microsoft привела в соответствие трем типам дисков.
Базовые диски MBR. Эта схема разбиения на разделы использует классическую главную загрузочную запись (Master Boot Record — MBR), предложенную компанией Intel. Запись MBR содержит структуру данных, которая называется таблица разделов (partition table) и определяет до четырех разделов, которые могут хранить данные.
Базовые диски GPT. Эта схема разбиения на разделы доступна на компьютерах на основе архитектуры IA64. В этой схеме используется новый формат таблицы разделов, который определяет до 128 разделов, каждый из которых идентифицируется глобально уникальным идентификатором.
Динамические диски. Эта схема разбиения на разделы используется на динамических дисках (dynamic disk) в операционных системах Windows Server 2003, Windows ХР и Windows 2000. Информация о разделах хранится в базе данных, которая управляется службой диспетчера логических дисков (Logical Disk Manager — LDM). Динамические диски поддерживаются как на архитектуре IA32, так и на архитектуре IA64. На архитектуре IA32 копия базы данных диспетчера логических дисков хранится на последнем цилиндре каждого динамического диска. На архитектуре IA64 база данных диспетчера логических дисков хранится в зарезервированном разделе Microsoft (Microsoft Reserved Partition — MSR) в начале диска.
Конфигурации томов диспетчера
логических дисков
Управляемая диспетчером логических дисков (LDM) база данных заменяет собой основанные на системном реестре массивы дисков Windows NT, которые управлялись с помощью утилиты Ftdisk. Драйвер Ftdisk был перемещен на средний уровень, где на него возложено управление базовыми дисками MBR и GPT.
В обычных условиях при хранении на каждом диске собственных данных достаточно использования базовых дисков MBR на архитектуре IA32 или базовых дисков GPT на архитектуре IА64. Это справедливо и для аппаратных массивов RAID, где созданный средствами адаптера RAID логический диск выглядит для операционной системы как большой базовый диск.
Диспетчер логических дисков используется при создании более сложных дисковых конфигураций, реализованных программными средствами. При этом возникает необходимость преобразования базовых дисков в динамические. После этого можно будет воспользоваться диспетчером LDM и создать одну или несколько перечисленных ниже конфигураций томов.
Простой том. Это эквивалент раздела MBR или GPT. При создании простого тома выделяется небольшой фрагмент диска, который будет использоваться файловой системой. В базе данных LDM достаточно места для сотен простых томов, но обычно не требуется более нескольких экземпляров.
Составной том. Этот тип тома позволяет объединить свободное пространство на одном или нескольких дисках для создания единого логического диска. Составной том является эквивалентом массива томов в операционной системе Windows NT.
Том с чередованием. Это конфигурация по схеме RAID 0. Поток данных делится на фрагменты, которые записываются на разные диски. Тома с чередованием предоставляют
преимущества с точки зрения производительности, особенно при использовании вместе с быстрой шиной передачи данных, но за это приходится платить большей вероятностью потери данных, так как отказ одного диска приводит к отказу всего тома.
Зеркалированный том. Это конфигурация по схеме RAID 1. В данном случае поток данных направляется на два диска одновременно. При отказе одного диска файловая система на втором диске остается доступной. Если диски подключены к разным контроллерам, том называется дублированным (duplexed). Зеркалированный том обеспечивает большую скорость поиска, так как на запрос чтения может ответить любой из томов, но при операциях записи производительность не превышает производительности одного диска, поскольку данные должны записываться на два диска одновременно.
Том RAID 5. В такой конфигурации поток данных делится на фрагменты, которые записываются на несколько дисков одновременно с информацией о четности. Дополнительная информация об этой конфигурации приводится во врезке “Использование массива RAID 5”. Массив RAID 5 является компромиссом между производительностью, отказоустойчивостью и гибкостью. Эта схема работает медленнее, чем том с чередованием или составной том, но обладает отказоустойчивостью. Также эта схема медленнее зеркалированного тома, но дисковое пространство используется более эффективно.
Диспетчер логических дисков не поддерживает более новые конфигурации массива, например RAID 0+1 (чередование с зеркалированием) или RAID 10 (зеркалирование с чередованием).
Фрагменты данных и производительность
Драйверы подсистемы хранения данных в операционной системе Windows Server 2003 (а также в Windows NT и Windows 2000) обмениваются данными с дисковой подсистемой фрагментами по 64 Кбайт. Задав на контроллере RAID размер фрагмента чередования 64 Кбайт, который совпадает с размером блока данных в операционной системе, можно увеличить производительность аппаратных массивов RAID.
Использование массива RAID 5
Если у вас нет опыта использования отказоустойчивых массивов, настройте в лабораторных условиях массив RAID 5 из трех дисков и отключите питание одного из дисков. Будет выдано короткое уведомление, но логический диск останется доступным, хотя производительность снизится.
Массив RAID 5 обеспечивает такую работу с помощью расчета и хранения информации о четности, которая может быть использована для восстановления содержимого потерянного диска. Расчет четности использует логическую операцию XOR (исключающее ИЛИ). Операция XOR описывается следующим образом.
Если два значения совпадают, результат — 0
Если два значения не совпадают, результат — 1
В табл. 14.1 описана функция XOR.
Таблица 14.1. Функция XOR
А
о о
1
1
в о
1
о
1
с
о
1
1
о
Чтобы понять, как происходит восстановление данных с помощью операции XOR, закройте любой из столбцов таблицы. Значение в закрытом столбце можно быстро вычислить по двум другим значениям в строке.
Точно так при удалении диска из массива RAID 5 система быстро вычисляет значения доступных данных, применив функцию XOR к данным на двух оставшихся дисках (“данные XOR- четность” или “данные XOR - данные для получения четности”).
По этой причине для создания массива RAID 5 необходимо иметь как минимум три диска. Для расчета фрагмента четности системе нужно как минимум два фрагмента с данными. В отличие от других схем RAID, фрагменты с четностью распределяются по всем дискам массива. Это позволяет устранить единственную точку отказа.
Помните, что при использовании RAID 5 объем, эквивалентный объему одного жесткого диска, используется для хранения четности. Если в массиве используется четыре диска объемом 20 Гбайт, будет потеряно 25 % общего объема и полезный объем составит 60 Гбайт.
Чем больше дисков подключено к массиву RAID 5, тем более эффективной становится конфигурация с точки зрения дискового пространства. Но увеличение количества дисков отрицательно сказывается на производительности, если переполняется шина SCSI. Если к шине Ultra Wide SCSI 3 подключено 15 дисков, будет потеряно только 6,7 % общего дискового пространства, но уровень производительности может оказаться неприемлемым.
В обычных томах с чередованием информация о четности не вычисляется, поэтому производительность тома с чередованием значительно выше, но при этом отсутствует устойчивость к сбоям.
Структура базы данных LDM,
Не будем рассматривать подробности и обратим внимание на общую структуру базы данных LDM, которая хранится на жестком диске. Эта информация позволит разобраться в том, что отображают утилиты работы с дисками. Кроме этого, эта информация позволит определить изменения, которые могут сделать базу данных недоступной (как и хранящиеся на диске данные).
На рис. 14.1 показана блок-схема базы данных LDM, которая хранится на жестком диске. Ниже перечислены компоненты этой базы данных.,
Закрытый заголовок. В заголовке присутствуют записи, которые описывают расположение базы данных LDM и в общем определяют ее содержимое. Существует несколько копий этого заголовка для обеспечения отказоустойчивости.
Таблица содержимого. Это индекс содержимого базы данных. Избыточные копии хранятся в конце диска для обеспечения отказоустойчивости.
Диспетчер томов. Сама база данных.
Виртуальные блоки. Записи базы данных, по одной для каждого раздела, диска и тома. На каждую запись выделяется 256 байт. В базе данных достаточно места для нескольких тысяч записей. Компания Microsoft рекомендует хранить в базе данных не более 32 элементов. Лично я считаю, что, если на сервере необходимо более одного отказоустойчивого элемента подсистемы хранения, стоит переходить на аппаратную реализацию массива RAID.
Журнал транзакций. Набор из двух секторов, в котором хранятся не внесенные в базу данных обновления. Журнал используется для защиты от возможного отказа питания или другого критического отказа.
При добавлении в систему нового динамического диска с помощью преобразования базового диска или создания нового тома на существующем динамическом диске система добавляет новый виртуальный блок в базу данных диспетчера томов (это эквивалентно добавлению новой записи в базу данных LDM). Каждый элемент (запись) базы данных получает глобально уникальный идентификатор, который выступает в роли ключа для записи.
Зеркалированный томЗеркалированный томБаза данных LDM на последнем цилиндре или в последнем мегабайте диска(полная копия хранится на каждом динамическом диске)Блок ТОСБлок ТОСVMDBVBLKKLOGKLOG' PrivHeadБлок ТОСБлок ТОСPrivHeadБаза данных LDM на последнем цилиндре или в последнем мегабайте диска(полная копия хранится на каждом динамическом диске)Блок ТОСБлок ТОСVMDBVBLKKLOGKLOG' PrivHeadБлок ТОСБлок ТОСPrivHeadТом RAID 5Том RAID 5Дополнительные тома на других дискахДополнительные тома на других дискахБлоки ТОС(Table of Contents) —таблица содержимогоБлоки ТОС(Table of Contents) —таблица содержимогоЗаписи базы данныхЗаписи базы данных|Журнал транзакций|Журнал транзакцийИзбыточная копия дляобеспеченияотказоустойчивостиИзбыточная копия дляобеспеченияотказоустойчивости
Зеркалированный том
Зеркалированный том
База данных LDM на последнем цилиндре или в последнем мегабайте диска(полная копия хранится на каждом динамическом диске)
Блок ТОС
Блок ТОС
VMDB
VBLK
KLOG
KLOG
' PrivHead
Блок ТОС
Блок ТОС
PrivHead
База данных LDM на последнем цилиндре или в последнем мегабайте диска(полная копия хранится на каждом динамическом диске)
Блок ТОС
Блок ТОС
VMDB
VBLK
KLOG
KLOG
' PrivHead
Блок ТОС
Блок ТОС
PrivHead
Том RAID 5
Том RAID 5
Дополнительные тома на других дисках
Дополнительные тома на других дисках
Блоки ТОС(Table of Contents) —таблица содержимого
Блоки ТОС(Table of Contents) —таблица содержимого
Записи базы данных
Записи базы данных
|
Журнал транзакций
|
Журнал транзакций
Избыточная копия дляобеспеченияотказоустойчивости
Избыточная копия дляобеспеченияотказоустойчивости
MBRJ |
В таблице разделов присутствует одна запись для целого диска
—
LDM Private Header
Локатор базы данных LDM
Второй том на другом диске
Рис. 14.1. Схема дисковых структур LDM
Большой объем информации о базе данных диспетчера логических дисков, ее содержимом и структуре предоставляется утилитой dmdiag, которая доступна в составе Support Tools. Ниже приведен пример отчета этой утилиты (параметр /v позволяет предоставить в десять раз больше информации):
C:\>dmdiag.exe
Dynamic Disk Information
DiskGroup: S1DgO
Group-ID: e129db61-e6d5-4ff0-9d2e-66-f570cc315
Sub Disk
Rei Sec
Tot Sec
Tot Size
Plex
Vol Type
Col/Ord
DevName
State
Disk1-O1
0
10667097
0
Volume1-01
Simple
1/1
MISSING
Disk1-02
10667097
204800
0
Volume2-O1
Simple
1/1
MISSING
Dlsk1-03
10871897
204800
0
Volume3-O1
Simple
1/1
MISSING
Dlsk1-04
11076697
1042177
0
Volume4-01
Mirror
1/1
MISSING
Disk1-O5
12118874
473088
0
Stripe1-01
Stripe
1/2
MISSING
LDM-DATA
0
0
Disk2-O1
63
8385867
12594960
Volumes-01
Simple
1/1
HarddlskO
ONLINE
Disk2-03
10442250
2136645
12594960
Volume7-01
Simple
1/1
HarddiskO
ONLINE
Disk2-04
8385930
1028160
12594960
Volume4-02
Mirror
1/2
HarddlskO
ONLINE
Disk2-05
12578895
14017
12594960
Volume4-02
Mirror
1/2
HarddiskO
ONLINE
Dlsk2-O2
9414090
473088
12594960
Stripe1-01
Stripe
2/2
HarddiskO
ONLINE
LDM-DATA
12592912
2048
- LDM Volume
Information
Volume
Volume Mnt
Subdisk Plex
Physical
Size
Total
Col
Plex
Rei
Name
Type Nme
NameName
Disk
Sectors
Size
Ord
Offset
Sectors
Volumel
Simple
C
Dlsk1-01
Volumel-01
10667097
10667097
1/1
0
0
Volume?
Simple
R
Disk1-02
Volume2-01
204800
204800
1/1
0
10667097
Volumes
Simple
S
Disk1-03
Volume3-01
204800
204800
1/1
0
10871897
Volumes
Simple
Dlsk2-01
Volume5-O1 HarddiskO
8385867
8385867
1/1
0
63
Volume?
Simple
Disk2-03
Volume7-01 HarddiskO
2136645
2136645
1/1
0
10442250
Volume4
Mirror
D
Dlsk1-04
Volume4-01
1042177
1042177
1/1
0
11076697
Volume4
Mirror
D
Disk2-04
Volume4-02 HarddiskO
1042177
1028160
1/2
0
8385930
Volume4
Mirror
D
Disk2-05
Volume4-O2 HarddiskO
1042177
14017
1/2
1028160
12578895
Strlpel
Stripe
E
Dlsk1-05
Stripe1-01
946176
473088
1/2
0
12118874
Strlpel
Stripe
E
Disk2-02
Strlpel-01 HarddiskO
946176
473088
2/2
0
414090
В конце отчета из таблицы были удалены столбцы Vol State и Plex State, во всех строках содержащие запись ACTIVE (это было сделано в связи с ограничением ширины страницы).
Имена групп LDM
Каждый динамический диск входит в группу дисков (disk group). Члены группы дисков используют общую базу данных LDM. Операционная система Windows Server 2003 поддерживает использование только одной группы дисков (коммерческая версия диспетчера LDM от компании Veritas поддерживает несколько групп дисков).
Имя группы дисков состоит из имени компьютера, после которого указывается последовательность символов DgO. Например, динамические диски на сервере SRV1 будут входить в группу SrvlDgO.
Преобразование всех динамических дисков на сервере в базовые диски (для этого необходимо удалить все тома, преобразовать диски и восстановить данные из резервной копии) и добавление следующего динамического диска приведет к созданию группы дисков SrvlDgl.
Имена групп играют важную роль при перемещении динамических дисков между серверами. При подключении к серверу динамического диска предоставляется возможность импорта базы данных LDM, которая хранится на динамическом диске. При этом диски становятся частью локальной группы дисков. Например, если отключить диски от сервера SRV1 и импортировать их в базу данных LDM на сервере SRV2, группа дисков получит имя Srv2DgO.
В системном реестре отслеживаются группы дисков, присутствующие на компьютере. Загрузка с динамического диска из другой группы не поддерживается. Например, предположим, что импортированный на сервер SRV2 диск был загрузочным. Во время импорта диск был добавлен в группу Srv2DgO. Если извлечь этот диск и подключить его к первому серверу, будет выдан голубой экран с сообщением об ошибке 0x0000007В, Inaccessible Boot Device. Сообщение будет выдано сразу после того, как система сравнит группу дисков в системном реестре и группу в базе данных LDM. Решения этой проблемы не существует, поэтому при перемещении динамических дисков будьте особенно внимательны.
Если извлечь динамические диски из одного сервера и подключить их к другому серверу, на котором собственные динамические диски отсутствуют, система поведет себя, как бездетная волчица, и примет динамические диски, как свои. Диск сохранит имя группы диска, в котором присутствует имя оригинального сервера. Система будет назначать это имя всем подключаемым после этого динамическим дискам. Это наиболее вероятная причина несовпадения имени системы и имени группы дисков.
Ограничения динамических томов
При создании динамических томов существуют некоторые ограничения.
Консоль Disk Management (Управление дисками) поддерживает форматирование динамических томов только с использованием файловой системы NTFS. Можно создать том и воспользоваться командой format для форматирования тома с использованием файловых систем FAT и FAT32.
Составной том, состоящий из нескольких дисков, не поддерживает зеркалирование.
Том с чередованием и тома RAID 5 также не поддерживают зеркалирование.
Составной том может создаваться только на основе простых томов.
Системный и загрузочный тома поддерживают зеркалирование, но не поддерживают чередование и не могут быть составными.
Даже учитывая ограничения, на динамических дисках можно создавать любое количество томов. Помните, что подсистема хранения должна отвечать на запросы файловой системы на всех томах, поэтому не снижайте производительность, создавая избыточное количество томов.
Кроме этого, старайтесь не смешивать диски IDE/АТ А и SCSI в пределах одного массива томов. Отслеживание пакетов данных из двух очень разных источников налагает дополнительную нагрузку на подсистему хранения. Это справедливо и для одновременного использования радикально отличающихся дисков SCSI на одной шине или различных адаптеров SCSI в пределах одного массива.
В большинстве случаев допустимый уровень производительности и отказоустойчивости обеспечивается зеркалированием пары дисков для хранения операционной системы и созданием массива RAID 5 из еще трех дисков для хранения данных. Интерфейс SCSI обеспечивает большую производительность за счет улучшенной обработки потоков и более быстрой подсистемы управления.
Windows ХР и LDM
Диспетчер логических дисков (LDM) в операционной системе Windows ХР не поддерживает создание таких отказоустойчивых томов, как RAID 5 и зеркалированные диски. Поддерживается создание простых томов или томов с чередованием, а также возможность создания составных томов. Это ограничение не связано с архитектурными особенностями; это просто инструмент разделения продуктов для рабочих станций и серверов. Такое ограничение характерно для всех версий операционных систем Windows NT и Windows 2000.
В Windows ХР поддерживается импорт отказоустойчивого тома, созданного на сервере. Автор этой книги не рекомендует использовать это решение, так как нельзя быть уверенным, что компания Microsoft не модифицирует код для отключения такой возможности.
Стоит обратить внимание, что операционная система Windows ХР Home Edition вообще не поддерживает динамические диски, установку на динамический диск и импорт динамических дисков, созданных в другой операционной системе.
Когда использовать динамические диски
Динамические диски имеют одно преимущество: они позволяют распределять данные по нескольким жестким дискам. Использование простого тома динамического диска не дает никакого прироста производительности по сравнению с использованием раздела базового диска. Производительность определяется скоростью вращения дисков, маршрутом ввода-вывода и файловой системой. Динамические диски так же подвержены действию вирусов, как и базовые диски, поскольку выполняемый код в записи MBR и загрузочном секторе раздела не изменились.
Это значит, что использовать динамический диск на компьютере с одним жестким диском не имеет смысла. Преобразование дисков портативного компьютера явно запрещено в системном реестре, так как портативный компьютер может подключаться к док-станции, на которой могут быть установлены дополнительные жесткие диски. Если база данных LDM на разных дисках рассинхронизируется, могут возникнуть проблемы в работе LDM.
На многих серверах используются аппаратные массивы RAID. Контроллеры RAID выглядят для операционной системы как виртуальный диск. Преобразование такого виртуаль-
ного диска из базового в динамический не дает вообще никаких преимуществ. В операционной системе Windows 2000 иногда возникала потребность в расширении томов посредством добавления нового диска в массив и добавления нового диска в составной том. В операционной системе Windows Server 2003 поддерживается увеличение размера разделов на базовых дисках, поэтому необходимости преобразования просто не возникает.
Если принято решение об использовании программного массива RAID на основе операционной системы Windows Server 2003, могут оказаться полезными следующие возможности.
Изменение конфигурации диска (кроме начального преобразования системного и загрузочного дисков) не требует перезагрузки компьютера.
Динамический том может управляться удаленно, как с использованием консоли Disk Management (Управление дисками), так и с помощью утилиты Diskpart.
База данных LDM реплицируется на каждый динамический диск, что позволяет добиться увеличения надежности.
База данных хранится на самих дисках, поэтому массив дисков можно перенести на другой компьютер и получить доступ к данным.
С помощью отказоустойчивого загрузочного диска можно загрузиться с использованием ' второго диска зеркалированного тома, не разбивая зеркало. В операционной системе Win
dows NT с использованием драйвера Ftdisk эта возможность не поддерживалась, так как системный реестр в зеркалированном томе был заблокирован.
Диски можно переключать внутри сервера, сохраняя при этом логическое расположение дисков внутри массивов томов. Это позволяет добиться большей гибкости по сравнению с классическими массивами Ftdisk в операционной системе Windows NT.
Динамические диски и портативные компьютеры
Можно обратить внимание, что некоторые портативные компьютеры поддерживают преобразование дисков в динамические. Это связано с ошибкой интерпретации BIOS конкретного компьютера.
В операционной системе Windows 2000 в системном реестре существовала недокументированная запись, которая позволяла использовать динамические диски на портативных компьютерах. В операционных системах Windows Server 2003 и Windows ХР эта запись не работает (служба LDM аварийно завершает работу), но для интересующихся эта запись здесь приводится:
Раздел: HKLM\System\CurrentControlSet\Services\dmload
Запись: Start
Значение: 0 (reg_dword)
Динамические диски и аппаратные массивы RAID
Главным преимуществом программного массива RAID является цена. Дешевле, чем бесплатно, не бывает. Но даже бесплатное решение имеет свою цену. Вспомните хотя бы цену соединения в мобильной связи при разговоре по “бесплатному" тарифу.
Динамические диски не предоставляют всего набора возможностей, характерного для аппаратных контроллеров RAID. Ниже приведен список отсутствующих возможностей.
“Горячая” замена дисков
Резервные диски с автоматической оперативной заменой
Динамическое увеличение объема массива при добавлении жесткого диска
Автоматическое управление разделами
Возможность защиты данных при некоторых отказах дисков
Кроме этого, даже при прочих равных характеристиках аппаратные массивы RAID предоставляют большую производительность по сравнению с программными. Если цена важнее производительности, имейте в виду, что такие производители, как Promise, IBM, Adaptec и другие, начали предлагать контроллеры АТА RAID по приемлемым ценам.
Но дешевле бесплатного предложения не найти. Если бюджет ограничен, а исполнительный директор, владелец или заказчик не намерен тратить деньги на аппаратный массив RAID, воспользуйтесь возможностями динамических дисков.
Преобразование базовых дисков
Динамические тома под управлением LDM предоставляют ряд преимуществ по сравнению с классическими разделами MBR, но существует и ряд особенностей, которые связаны с процедурой загрузки и обратной совместимостью. Чтобы разобраться в этих особенностях, сначала придется ознакомиться с базовыми структурами дисков MBR.
На рис. 14.2 показана структура главной загрузочной записи MBR (Master Boot Record). В записи MBR содержится несколько сотен байтов выполняемого кода, который предназначен для сканирования структуры данных, называющейся таблицей разделов (Partition Table) и хранящейся в записи MBR. Одна из записей в таблице разделов должна быть помечена как “активная”. Это значит, что запись будет использована для загрузки компьютера.
Код в записи MBR переходит по ссылке в активной записи таблицы разделов и загружает указанный сектор в память. Это загрузочный сектор раздела. В загрузочном секторе присутствует код начальной загрузки (bootstrap), способный найти и загрузить операционную систему или вторичный загрузчик. В случае операционной системы Windows Server 2003 в качестве вторичного загрузчика выступает Ntldr.
Код загрузчикаКод загрузчикаСигнатура дискаСигнатура дискаТаблица разделовТаблица разделовГлавная загрузочная запись (MBR)ЕВ ЗС 90 40 53 44 4F 53 35Главная загрузочная запись (MBR)ЕВ ЗС 90 40 53 44 4F 53 352Е 30 002Е 30 00Сигнатура MBRСигнатура MBR02 04 010002 04 0100A35CD36A9F38C2A35CD36A9F38C2Тип OB-FAT32Тип OB-FAT32Раздел 4 - РасширенныйРаздел 4 - РасширенныйТипов-FAT32Типов-FAT32Логический диск D: - NTFSЛогический диск D: - NTFSТип 05 - РасширенныйТип 05 - РасширенныйЛогический диск Е: ■ FAT32Логический диск Е: ■ FAT3202 00 02 00 00 F0 С8 00 20 00 40 00 20 00 00 00 Е01F03 00 80 00 29 20 24ED644E4F2Q4E41 40 45 20 20 20 20 46 4154 3136 20 20 20 33 0902 00 02 00 00 F0 С8 00 20 00 40 00 20 00 00 00 Е01F03 00 80 00 29 20 24ED644E4F2Q4E41 40 45 20 20 20 20 46 4154 3136 20 20 20 33 09Раздел 2 - Основной Диск F.-FAT32Раздел 2 - Основной Диск F.-FAT32Раздел 1 - Основной Диск С: • NTFSРаздел 1 - Основной Диск С: • NTFSРаздел 3 - Основной Диск G: - FATРаздел 3 - Основной Диск G: - FATАктивная - Тип 07 - Инсталлируемая файловая системаАктивная - Тип 07 - Инсталлируемая файловая система
Код загрузчика
Код загрузчика
Сигнатура диска
Сигнатура диска
Таблица разделов
Таблица разделов
Главная загрузочная запись (MBR)
ЕВ ЗС 90 40 53 44 4F 53 35
Главная загрузочная запись (MBR)
ЕВ ЗС 90 40 53 44 4F 53 35
2Е 30 00
2Е 30 00
Сигнатура MBR
Сигнатура MBR
02 04 0100
02 04 0100
A35CD36A9F38C2
A35CD36A9F38C2
Тип OB-FAT32
Тип OB-FAT32
Раздел 4 - Расширенный
Раздел 4 - Расширенный
Типов-FAT32
Типов-FAT32
Логический диск D: - NTFS
Логический диск D: - NTFS
Тип 05 - Расширенный
Тип 05 - Расширенный
Логический диск Е: ■ FAT32
Логический диск Е: ■ FAT32
02 00 02 00 00 F0 С8 00 20 00 40 00 20 00 00 00 Е01F03 00 80 00 29 20 24
ED644E4F2Q4E41 40 45 20 20 20 20 46 4154 3136 20 20 20 33 09
02 00 02 00 00 F0 С8 00 20 00 40 00 20 00 00 00 Е01F03 00 80 00 29 20 24
ED644E4F2Q4E41 40 45 20 20 20 20 46 4154 3136 20 20 20 33 09
Раздел 2 - Основной Диск F.-FAT32
Раздел 2 - Основной Диск F.-FAT32
Раздел 1 - Основной Диск С: • NTFS
Раздел 1 - Основной Диск С: • NTFS
Раздел 3 - Основной Диск G: - FAT
Раздел 3 - Основной Диск G: - FAT
Активная - Тип 07 - Инсталлируемая файловая система
Активная - Тип 07 - Инсталлируемая файловая система
Рис. 142. Схема ключевых элементов записи MBR и информация о разделах
При преобразовании базового диска в динамический эта конфигурация немного меняется. На рис. 14.3 показаны запись MBR и информация о разделах после преобразования базового диска в динамический. Во время преобразования происходит несколько изменений.
В конце диска добавляется раздел диспетчера логических дисков LDM.
Записи из таблицы разделов MBR добавляются в базу данных LDM в виде простых томов. Для каждого основного раздела и каждого логического диска в расширенном разделе создается простой том.
Если в системе уже присутствуют динамические диски, новый диск и его тома будут добавлены в существующую базу данных LDM, а результат будет скопирован в базу данных на новом диске.
Логические буквы дисков, заданные для базовых разделов в системном реестре, сохраняются для созданных динамических томов.
Таблица разделов изменяется для сохранения только тех разделов, которые необходимы для доступа к диску при использовании вызова INT13.
Изменения в пользовательском интерфейсе практически незаметны. Интерфейс Explorer остается без изменений. На консоли Disk Management (Управление дисками) состояние дисков указано как Dynamic (Динамический) и On-Line (Исправен). Тома выделяются другими цветами. Нераспределенное место на диске теперь можно добавлять в структуры динамических томов, например в составные и зеркалированные тома, а также массивы RAID 5 и массивы с чередованием.
Раздел 1 - Основнойтом LDM
Таблица разделовТаблица разделовКод загрузчикаКод загрузчика2ЕЗО0О2ЕЗО0О02 04 01 0002 04 01 00Сигнатура дискаСигнатура диска55АА55ААСигнатура MBRСигнатура MBRA35CD36A9F38C2A35CD36A9F38C2Главная загрузочная запись (MBR)ЕВ ЗС 90 40 53 44 4F 53 35Главная загрузочная запись (MBR)ЕВ ЗС 90 40 53 44 4F 53 3502 00 02 00 00 F8 С8 00 2000 40 00 20 00 00 00EO 1F03006000292024ED 64 4£ 4F 20 46 41 40 45 20 20 20 20 46 4154 31 36 20 20 20 33 С902 00 02 00 00 F8 С8 00 2000 40 00 20 00 00 00EO 1F03006000292024ED 64 4£ 4F 20 46 41 40 45 20 20 20 20 46 4154 31 36 20 20 20 33 С9Том 1 - Обычный томДиск С:-NTFSТом 1 - Обычный томДиск С:-NTFSТом 2 - Обычный томДиск F: - FAT32Том 2 - Обычный томДиск F: - FAT32Раздел 3 - Расширенный томДиск G: - FATРаздел 3 - Расширенный томДиск G: - FATАктивная - Тип 07 • ИнсталлируемаяФайловая системаНет записиАктивная - Тип 07 • ИнсталлируемаяФайловая системаНет записиРаздел 4 - РасширенныйРаздел 4 - РасширенныйНет записиНет записиТип 05 - РасширенныйТип 05 - РасширенныйЛогический диск D: - NTFSЛогический диск D: - NTFSЛогический диск Е: - FAT32Логический диск Е: - FAT32
Таблица разделов
Таблица разделов
Код загрузчика
Код загрузчика
2ЕЗО0О
2ЕЗО0О
02 04 01 00
02 04 01 00
Сигнатура диска
Сигнатура диска
55АА
55АА
Сигнатура MBR
Сигнатура MBR
A35CD36A9F38C2
A35CD36A9F38C2
Главная загрузочная запись (MBR)
ЕВ ЗС 90 40 53 44 4F 53 35
Главная загрузочная запись (MBR)
ЕВ ЗС 90 40 53 44 4F 53 35
02 00 02 00 00 F8 С8 00 20
00 40 00 20 00 00 00
EO 1F03006000292024
ED 64 4£ 4F 20 46 41 40 45 20 20 20 20 46 4154 31 36 20 20 20 33 С9
02 00 02 00 00 F8 С8 00 20
00 40 00 20 00 00 00
EO 1F03006000292024
ED 64 4£ 4F 20 46 41 40 45 20 20 20 20 46 4154 31 36 20 20 20 33 С9
Том 1 - Обычный томДиск С:-NTFS
Том 1 - Обычный томДиск С:-NTFS
Том 2 - Обычный томДиск F: - FAT32
Том 2 - Обычный томДиск F: - FAT32
Раздел 3 - Расширенный томДиск G: - FAT
Раздел 3 - Расширенный томДиск G: - FAT
Активная - Тип 07 • ИнсталлируемаяФайловая система
Нет записи
Активная - Тип 07 • ИнсталлируемаяФайловая система
Нет записи
Раздел 4 - Расширенный
Раздел 4 - Расширенный
Нет записи
Нет записи
Тип 05 - Расширенный
Тип 05 - Расширенный
Логический диск D: - NTFS
Логический диск D: - NTFS
Логический диск Е: - FAT32
Логический диск Е: - FAT32
Рис. 14.3. Схема MBR после преобразования базового диска в динамический
Типы преобразования, требующие перезагрузки
Для завершения преобразования дисков может потребоваться перезагрузка, если на дисках хранятся следующие компоненты.
Системные файлы
Загрузочные файлы
Файлы подкачки
Файлы аварийного дампа
Перезагрузка позволяет системе создать необходимые записи в базе данных LDM и записи системного реестре до монтирования файловой системы. Вот краткое описание операций. ■ Раздел Encapsulation Info добавляется в системный реестр в раздел HKLM\System\
CurrentControlSet\Services\DMlO. Двоичное значение для записи FDISK Data описывает структуру разделов на диске.
Раздел Encapsulat ionPending добавляется в раздел HKLM\System\CurrentControl Set\Services\DMLOAD. Записи в этот раздел не добавляются. Раздел выступает в роли флага для уведомления системы о необходимости изменений в записи MBR и необходимости создания базы данных LDM с использованием информации из раздела Encapsulation Info.
Система перезагружается, вносит необходимые изменения и выдает запрос на еще одну перезагрузку в связи с обнаружением новых аппаратных средств. Это связано с тем, что динамические диски находятся в другом месте пространства имен объектов операционной системы Windows Server 2003 по сравнению с базовыми дисками.
Требования и ограничения при преобразовании базовых дисков
Ниже приведен краткий перечень требований и ограничений, который стоит использовать при планировании преобразования дисков. Если одно из ограничений не позволяет выполнить преобразование, единственной альтернативой является удаление существующих разделов (после резервного копирования данных), преобразование диска, настройка динамических томов и восстановление данных из резервной копии.
Преобразование дисков с существующими разделами невозможно, если в конце диска нет места для хранения базы данных диспетчера LDM. База данных требует минимум 1 Мбайт дискового пространства, но должна быть “подогнана” согласно ограничениям цилиндра, поэтому фактический размер зависит от геометрии диска.
Система изменит размер любых существующих разделов, чтобы освободить дисковое пространство для хранения базы данных LDM. Если изменение размера завершится неудачно, преобразование окажется невозможным. Так происходит в единственном случае — если в конце диска присутствуют разделы других операционных систем (диспетчера разделов от стороннего производителя, разделы Linux и т.д.).
Если используются диски SCSI, система разместит базу данных LDM в области, которая выделена диском для замены поврежденных секторов. Это значительно сократит способность диска заменять поврежденные секторы. Файловая система NTFS поддерживает программную замену поврежденных секторов, поэтому к серьезным проблемам это не приводит.
Преобразование отключаемых дисков и сменных носителей также не поддерживается. На каждом динамическом диске хранится копия базы данных LDM. Копия базы данных на сменном носителе может нарушить стабильность работы LDM.
Чтение динамических дисков поддерживается только в операционных системах Windows Server 2003, Windows ХР и Windows 2000.
Преобразование динамического диска в базовый не поддерживается, если предварительно не удалить каждый том. В результате удаления тома удаляются все хранящиеся на нем данные, поэтому перед удалением необходимо создать резервную копию данных.
Системные файлы Ntldr, Ntdetect. com, Boot. ini, Bootsect .dos и Ntbootdd. sys могут храниться на динамическом диске, но они должны находиться на простом или зеркалированном томе.
Загрузка и динамические диски
При загрузке компьютера на основе архитектуры Intel программа BIOS осуществляет последовательность вызовов INT13 для поиска кода загрузчика операционной системы. (Персональные компьютеры, соответствующие спецификации РС97, используют расширенные вызовы INT13, которые позволяют работать с новыми типами дисков.)
Служебные подпрограммы INT13 не поддерживают чтение базы данных LDM. Без стандартных записей в таблице разделов BIOS не способна обнаружить раздел операционной системы. По этой причине при преобразовании базового диска в динамический диск система сохраняет запись в таблице разделов, как для системного раздела (раздела, который содержит код загрузчика). Рассмотрим несколько особенностей этой операции.
Системный раздел не обязательно является первым разделом на диске. В таком случае будет сохранено достаточно записей в таблице разделов, чтобы обеспечить возможность вызовам INT13 обнаруживать системный раздел.
■ Операционная система может загружаться с логического диска в расширенном разделе. По этой причине сохраняются все записи таблицы разделов, соответствующие расширенным разделам.
Помните, что загрузка с диска, который содержит только динамические тома, невозможна. При зеркалировании системного диска сначала разбейте диск на разделы, после чего удалите разделы и создайте зеркало. При этом в записи MBR будет создана запись для загрузочного раздела.
Вызов INT13 не “видит” границ данных, созданных базой данных диспетчера логических дисков. По этой причине необходимо соблюдать осторожность при использовании дисковых утилит, которые работают за пределами операционной системы Windows. Это касается программ Bootit и Partition Magic, а также возможностей дефрагментации, доступных в программах Diskeeper и PerfectDisk. Также это касается программы установки и консоли восстановления (Recovery Console), которые используют драйверы из программы установки (Setup). Дополнительная информация приводится в следующем разделе.
Программа установки и динамические диски
Операционную систему Windows Server 2003 можно установить на жесткий диск, который был конфигурирован, как динамический. Перед тем как рассматривать ограничения и требования, рассмотрим последовательность событий при запуске программы Setup на базовом диске. (Неопытные администраторы операционных систем Windows могут обратиться к врезке “Загрузочные и системные разделы”.) Рассмотрим последовательность событий.
Если загрузочные файлы и системные файлы помещаются в один раздел, программа установки создает один основной раздел и присваивает ему букву диска С. Обычно это первый раздел диска, хотя это не обязательно. Кроме этого, программа установки помечает раздел как “активный". Это означает, что в процедуре загрузки BIOS будет загружаться первый сектор этого раздела.
Создание загрузочного диска
Если разбиение зеркалированного диска на разделы не выполнялось и основной диск зеркала отказал, второй диск зеркала не способен обеспечить загрузку, так как на нем отсутствуют запись MBR и таблица разделов. Для размещения на диске загрузочной информации можно воспользоваться утилитой Diskpart, но сначала необходимо загрузить операционную систему. Для этого можно воспользоваться загрузочным гибким диском. Дополнительная информация о создании загрузочной дискеты приводится в разделе "Создание загрузочного гибкого диска".
После загрузки операционной системы загрузите консоль Diskpart и введите следующие команды (в этом примере предполагается, что диск является первым диском массива и том расположен в начале диска):
DISKPART> Select Disk 0
DISKPART> Select Volume 1
DISKPART> Retain
■ Если задать помещение загрузочных и системных файлов в разные разделы, программа установки пометит как “активный" раздел с системными файлами и назначит ему букву диска С. Обычно это первый раздел на диске. Остальные указанные в программе установки разделы станут логическими дисками в расширенном разделе. Программа установки не позволяет создать более одного основного раздела.
Эти правила обеспечивают вызову INT13 возможность загрузить код загрузчика из системного раздела и файлы операционной системы — из загрузочного раздела.
При установке операционной системы Windows Server 2003 на динамический диск BIOS по-прежнему должна находить код загрузчика и файлы операционной системы. Помня об этом, можно перечислить требования и ограничения.
■ Если зеркалирован системный или загрузочный раздел, перед установкой операционной системы Windows Server 2003 необходимо разбить зеркало. Зеркало можно будет восстановить после установки.
■ Необходимо выбрать раздел, отображенный программой установки. Эти разделы соответствуют томам, связанным с классическими разделами в таблице разделов записи MBR. Другие динамические тома не отображаются, поэтому не удаляйте их, если нет уверенности, что на них нет никаких ценных данных.
■ Свободное дисковое пространство после перечисленных разделов будет отсутствовать. При выборе раздела программа установки, скорее всего, обнаружит существующую операционную систему Windows. Можно выбрать перезапись обнаруженной операционной системы.
Для защиты от потери данных стоит избегать установки операционной системы Windows Server 2003 на динамический диск, кроме случаев установки еще одной версии операционной системы с целью исправления неполадок.
Загрузочные и системные разделы
Читатели, которые не знакомы с неуклюжей терминологией компании Microsoft и не хотят полагаться на интуицию при определении загрузочного (boot) и системного (system) разделов, должны ознакомиться с этими определениями.
Загрузочный раздел содержит системные файлы операционной системы Windows Server 2003. По умолчанию эти файлы хранятся в каталоге \windows.
Системный раздел содержит файлы, которые используются для загрузки операционной системы Windows Server 2003: Nt Idr, Ntdetect. com, Ntbootdd. sys, Boot. ini, Bootsect. dos. Эти файлы находятся в корневом каталоге диска, который используется для загрузки операционной системы.
Запутанно? Естественно. Терминологию исправят? Скорее всего, нет.
Консоль восстановления (Recovery Console) использует драйверы программы установки, поэтому не вводите команду тар на консоли восстановления, ошибочно предполагая, что видимые диски являются единственными логическими дисками в системе.
Разделы и расширение тома
Рост наблюдается во всем. 50 миллионов лет назад лошади были размером с современную собаку. В 1930 году астроном Эдвин Хьюбелл (Edwin Hubell) доказал, что Вселенная расширяется. В 1965 году Гордон Мур (Gordon Moore) высказал мысль, что плотность транзисторов на кристаллах микросхем будет расти с более-менее стабильной скоростью. В 1999 году Майкл Делл (Michael Dell) поставил рекорд обогащения за один месяц.
Но никто так не понимает процесс расширения, как системный администратор. Это не касается расширения, которое происходит от поглощения шоколадных пончиков при устране-
нии неполадок отказавшей службы. Это касается увеличения объема данных. Независимо от начального объема подсистемы хранения в один миг она заполняется на 90 %. Рассмотрим, как диспетчер логических дисков (LDM) позволяет реагировать на такой рост.
Увеличение объема разделов на базовых дисках
Обычно для увеличения объема подсистемы хранения в массив определенного типа добавляются жесткие диски. Это может быть массив RAID или модуль архитектуры SAN (Storage Area Network — архитектура “сервер — хранилище данных”). Добавленное дисковое пространство в операционной системе выглядит, как нераспределенное.
В операционной системе Windows 2000 для расширения существующего тома на новое дисковое пространство без создания нового логического диска требовалось преобразование виртуального диска контроллера RAID в динамический с последующим увеличением размера тома. В операционной системе Windows Server 2003 увеличение размера базовых разделов поддерживается без преобразования в динамический диск. Если на компьютере поддерживается альтернативная загрузка операционных систем Windows Server 2003 и Windows 2000 или Windows NT, увеличенный раздел будет доступен и другой операционной системе.
Рассмотрим ограничения на расширение раздела базового диска.
Раздел должен быть отформатирован с использованием файловой системы NTFS. Если используется файловая система FAT или FAT32, ее можно преобразовать с помощью утилиты convert. Новая утилита convert в составе операционной системы Windows Server 2003 предоставляет большую производительность и позволяет указывать размер кластера.
Нераспределенное дисковое пространство должно находиться на том же диске, что и существующий раздел. Увеличение раздела на несколько дисков не поддерживается.
Нераспределенное дисковое пространство должно находиться рядом с базовым разделом, который будет расширен.
После увеличения размера раздела дисковое пространство отображается в Explorer (Проводник) как свободное пространство на существующем логическом диске. Дополнительная информация о процедуре расширения базового раздела приводится в разделе “Дисковые операции на компьютерах IA32”.
Расширение томов на динамических дисках (составные тома)
Для увеличения размера динамического тома к нему можно добавить нераспределенное пространство в любом месте диска. Кроме этого, поддерживается добавление свободного пространства с других дисков. Такая конфигурация имеет ряд ограничений.
Поддерживается расширение простого тома или существующего составного тома. Расширение тома с чередованием, тома RAID 5 или зеркалированного тома не поддерживается.
Не поддерживается расширение системного тома (тома, который используется для загрузки операционной системы). Это связано с использованием вызовов INT13, которые зависят от стандартной информации о разделах из записи MBR.
Не поддерживается расширение загрузочного тома (тома, который используется для хранения операционной системы). Причина та же, что и при расширении системного тома.
Не поддерживается расширение тома, связанного с записью в классической таблице разделов. Эта проблема характерна для операционной системы Windows 2000, так как в этой операционной системе сохраняется старая таблица разделов. В операционной системе Windows Server 2003 структура таблицы разделов претерпела изменения с целью устранения большинства основных разделов.
Основным преимуществом расширения томов на динамических дисках по сравнению с расширением разделов на базовых дисках является возможность создания составных томов на не-
скольких жестких дисках. Обычно стоит избегать такой конфигурации, так как она не обеспечивает отказоустойчивости. Но если используется архитектура SAN или другая отказоустойчивая подсистема хранения, способная предоставить несколько виртуальных дисков, можно создавать составные тома на основе нескольких виртуальных дисков, сохраняя отказоустойчивость.
Процедура расширения динамического тома рассматривается в следующем разделе.
Дисковые операции на компьютерах IA32
Теперь, когда рассмотрены принципы работы диспетчера логических дисков (LDM), воспользуемся его возможностями для создания различных конфигураций подсистемы хранения. Основным инструментом для преобразования и настройки подсистемы хранения на основе жестких дисков является консоль Disk Management (Управление дисками), файл Di skmgmt. msc.
Оснастка для этой консоли входит в состав консоли Computer Management (Управление компьютером). Для запуска консоли Computer Management (Управление компьютером) воспользуйтесь командой Start* Programs* Administrative Tools*Computer Management (Пуск* Программы* Администрирование1* Управление компьютером).
Кроме этого, для запуска консоли Computer Management (Управление компьютером) можно щелкнуть правой кнопкой мыши на пиктограмме Му Computer (Мой компьютер) и выбрать из контекстного меню команду Manage (Управление).
Консоль Disk Management (Управление дисками) не управляет конфигурацией дисков непосредственно. Консоль связывается со службой Logical Disk Server (Сервер логических дисков) при помощи программы Logical Disk Manager Administrator (Администратор диспетчера логических дисков), Dmadmin, которая запускается одновременно с консолью Disk Management (Управление дисками). Это значит, что поддерживается управление дисками на удаленных серверах.
Рис. 14.4. На консоли Disk Management (Управление дисками) отображается информация о томах и их параметрах '
На рис. 14.4 показан интерфейс консоли Disk Management (Управление дисками). В верхней части консоли Disk Management (Управление дисками) отображается текстовая информация о каждом логическом разделе и/или томе. В графической интерпретации логические диски и тома отображаются в виде прямоугольных блоков, внутри которых указаны сведения об этом логическом разделе или томе. Если щелкнуть правой кнопкой мыши на прямоугольнике тома или раздела, станут доступными команды форматирования, назначения или изменения буквы диска и удаления. Если щелкнуть правой кнопкой мыши на неразбитом дисковом пространстве, станут доступными команды по созданию раздела или тома (для базовых или динамических дисков соответственно). Кроме этого, предоставляются сведения о диске.
Все эти операции можно выполнить из командной строки с помощью утилиты Diskpart, которая входит в состав Support Tools. Утилита Diskpart предоставляет текстовый интерфейс для этих операций и может использоваться для быстрого и удобного управления удаленными серверами, а также для управления дисками с помощью сценариев. Дополнительная информация приводится в разделе “Управление дисками из командной строки”, который находится в конце этой главы.
Выбор правильной конфигурации диска
В операционной системе Windows Server 2003 предоставляется несколько возможных конфигураций диска. Для базовых дисков доступны два варианта.
Основной раздел (primary partition). Этот вариант оказывается полезным при использовании одного диска, который необходимо разделить на один или несколько логических дисков. Несколько дисков позволяют разделить операционную систему и данные, разделить данные из разных источников и ограничить размер раздела. Например, создание одного раздела для массива дисков объемом 500 Гбайт приведет к тому, что файловой системе придется отслеживать слишком большое количество кластеров, что вызовет увеличение времени доступа к данным.
Расширенный раздел (extended partition). Этот вариант необходимо использовать, если требуется загрузка операционной системы DOS или Windows 9х и необходимо получать доступ к файлам, расположенным не только в основном разделе, из которого загружается операционная система. В операционных системах Windows NT и Windows 2000 не требуется использовать вариант расширенного раздела, если достаточно четырех логических дисков.
■Mil■MilNTFSNTFS0(6:)0(6:)NTFS NTFS FAT32NTFS NTFS FAT32Regenerating:.. Formatting Formatting Regenerating Healthy Healthy (Active)Regenerating:.. Formatting Formatting Regenerating Healthy Healthy (Active)18.35 GB 17.21GB6.12 GB9.71GB238 MB18.35 GB 17.21GB6.12 GB9.71GB238 MB2.93 GB 18.35 GB 17.21GB6.16 GB2.93 GB 18.35 GB 17.21GB6.16 GBMkror Striped Shute RAID-5 Spanned PartitionMkror Striped Shute RAID-5 Spanned PartitionBaskBask236 MB236 MB8S3RAID5 (El) ^Spanned (F:) s8ziP2SO(D:)8S3RAID5 (El) ^Spanned (F:) s8ziP2SO(D:)JJ(41%) (System)(41%) (System)»,®e»,®e(G)(G)iv.Meiv.MeZIP250 (D:) ■ 239>»fat32 j Heathy (Active)ZIP250 (D:) ■ 239>»fat32 j Heathy (Active)(G) 9.17GB ^Formatting(G) 9.17GB ^FormattingRAIDS (В)3.06 GB NTFS Regenerating: (9%)RAIDS (В)3.06 GB NTFS Regenerating: (9%)j (Ci)12.93 GB NTFS ; Regeneratingj (Ci)12.93 GB NTFS ; RegeneratingSpanned (R) 4.88 GB NTFS HealthySpanned (R) 4.88 GB NTFS HealthyRAIDS (Б)3.08 GB NTFS Regenerating: (9%)RAIDS (Б)3.08 GB NTFS Regenerating: (9%)(K:) t 17.21 GBFormatting(K:) t 17.21 GBFormatting1 ] Formatting1 ] FormattingRAIDS (В)RAIDS (В)3.08 О NTFS3.08 О NTFSRegenerating: (<Regenerating: (<(Ci)(Ci)2.93 a NTFS2.93 a NTFSRegenerating: (Regenerating: (
■Mil
■Mil
NTFS
NTFS
0(6:)
0(6:)
NTFS NTFS FAT32
NTFS NTFS FAT32
Regenerating:.. Formatting Formatting Regenerating Healthy Healthy (Active)
Regenerating:.. Formatting Formatting Regenerating Healthy Healthy (Active)
18.35 GB 17.21GB
6.12 GB
9.71GB
238 MB
18.35 GB 17.21GB
6.12 GB
9.71GB
238 MB
2.93 GB 18.35 GB 17.21GB
6.16 GB
2.93 GB 18.35 GB 17.21GB
6.16 GB
Mkror Striped Shute RAID-5 Spanned Partition
Mkror Striped Shute RAID-5 Spanned Partition
Bask
Bask
236 MB
236 MB
8S3RAID5 (El) ^Spanned (F:) s8ziP2SO(D:)
8S3RAID5 (El) ^Spanned (F:) s8ziP2SO(D:)
J
J
(41%) (System)
(41%) (System)
»,®e
»,®e
(G)
(G)
iv.Me
iv.Me
ZIP250 (D:) ■ 239>»fat32 j Heathy (Active)
ZIP250 (D:) ■ 239>»fat32 j Heathy (Active)
(G) 9.17GB ^Formatting
(G) 9.17GB ^Formatting
RAIDS (В)
3.06 GB NTFS Regenerating: (9%)
RAIDS (В)
3.06 GB NTFS Regenerating: (9%)
j (Ci)
12.93 GB NTFS ; Regenerating
j (Ci)
12.93 GB NTFS ; Regenerating
Spanned (R) 4.88 GB NTFS Healthy
Spanned (R) 4.88 GB NTFS Healthy
RAIDS (Б)
3.08 GB NTFS Regenerating: (9%)
RAIDS (Б)
3.08 GB NTFS Regenerating: (9%)
(K:) t 17.21 GB
Formatting
(K:) t 17.21 GB
Formatting
1 ] Formatting
1 ] Formatting
RAIDS (В)
RAIDS (В)
3.08 О NTFS
3.08 О NTFS
Regenerating: (<
Regenerating: (<
(Ci)
(Ci)
2.93 a NTFS
2.93 a NTFS
Regenerating: (
Regenerating: (
rr7T
r
r
Puc. 14.5. Консоль Disk Management (Управление дисками) для системы, в которой используются практически все возможные конфигурации динамических дисков
При использовании динамических дисков количество доступных вариантов возрастает. На рис. 14.5 показана консоль Disk Management (Управление дисками) для системы, в которой используются практически все конфигурации динамических дисков.
Простой том (simple volume). Этот вариант используется при наличии одного динамического диска, который необходимо разбить на один или несколько логических дисков.
Составной том (spanned volume). Этот вариант используется при наличии аппаратного массива RAID в системе, в которой добавлены дополнительные диски. Составной том позволяет сохранить имя тома и букву диска при увеличении размера тома. Не стоит включать в составной том сразу несколько дисков, поскольку такая конфигурация повышает вероятность потери данных.
Том с чередованием (striped volume). Этот вариант стоит использовать, когда отказоустойчивость не имеет первостепенного значения и прежде всего необходимо повышение производительности операций ввода-вывода. Это популярная конфигурация на рабочих станциях CAD и мультимедиа, где рабочие файлы сохраняются локально на протяжении дня, после чего копируются на файловый сервер для ночного резервного копирования. Использование одного контроллера IDE не позволяет добиться повышения производительности. Для заметного эффекта необходимо использовать два контроллера IDE. Иногда требуется несколько контроллеров SCSI, если в том с чередованием входит несколько жестких дисков.
Зеркалированный том (mirrored volume). Этот вариант используется для повышения производительности и обеспечения отказоустойчивости. Для максимального эффекта необходимо использовать несколько контроллеров. Кроме этого, такая конфигурация позволяет обеспечить устойчивость к отказу контроллера. В операционной системе Windows ХР Professional зеркалирование не поддерживается.
Том RAID 5. Этот вариант обеспечивает отказоустойчивость и эффективен при использовании больших локальных жестких дисков, которые делают зеркалирование невыгодным с точки зрения стоимости. В операционной системе Windows ХР Professional конфигурация RAID 5 не поддерживается.
В следующих нескольких разделах описывается создание таких конфигураций.
Создание основного раздела на базовом диске
При создании второго основного раздела на компьютере с возможностью загрузки альтернативной операционной системы операционные системы более старых версий, например DOS и Windows 9х, не смогут использовать этот раздел. На диске можно создать до четырех основных разделов. Последовательность действий для создания основного раздела на базовом диске описана в процедуре 14.1.
Процедура 14.1. Создание основного раздела на базовом диске
Откройте консоль Disk Management (Управление дисками).
Щелкните правой кнопкой мыши на прямоугольнике, который соответствует разбиваемому диску, и выберите из контекстного меню команду Create Partition (Создать раздел). Запустится мастер создания разделов (New Partition Wizard).-
Щелкните на кнопке Next (Далее). Откроется окно Select Partition Туре (Выберите тип раздела)..
Выберите переключатель Primary Partition (Основной раздел).
Щелкните на кнопке Next (Далее). Откроется окно Specify Partition Size (Задайте размер раздела). Введите размер раздела в мегабайтах. Минимальный размер, указанный в окне,
является только рекомендацией. Очень маленькие разделы стоит создавать только для тестирования.
Щелкните на кнопке Next (Далее). Откроется окно Assign Drive Letter or Path (Назначьте букву диска или путь).
Обычно достаточно выбрать следующую доступную букву диска. Установка флажка Mount This Volume at an Empty Folder... (Монтировать этот том к пустой папке) указывает на необходимость использования точки функционального монтирования NTFS для монтирования раздела к папке на существующем диске NTFS.
Щелкните на кнопке Next (Далее). Откроется окно Format Partition (Форматировать раздел). Выберите файловую систему, которая будет использоваться для форматирования раздела.
Щелкните на кнопке Next (Далее). В открывшемся окне будут показаны выбранные параметры.
Щелкните на кнопке Finish (Готово) для создания и форматирования раздела.
После этого информация о новом разделе отображается на консоли Disk Management (Управление дисками).
Создание расширенного раздела и логических дисков
На диске может существовать только один расширенный раздел. При необходимости расширенный раздел может занимать весь диск, но такая конфигурация подходит только для хранения данных. Системные файлы (которые используются для загрузки операционной системы) должны находиться в основном разделе. Необходимая последовательность действий для создания расширенного раздела приведена в процедуре 14.2.
Процедура 14.2. Создание расширенного раздела и логических дисков
Откройте консоль Disk Management (Управление дисками).
Щелкните правой кнопкой мыши на неразбитом дисковом пространстве, в котором необходимо создать расширенный раздел. Из контекстного меню выберите команду Create Partition (Создать раздел). Откроется мастер создания раздела (New Partition Wizard).
Щелкните на кнопке Next (Далее). Откроется окно Select Partition Туре (Выберите тип раздела).
Выберите переключатель Extended Partition (Расширенный раздел).
Щелкните на кнопке Next (Далее). Откроется окно Specify Partition Size (Введите размер раздела). Введите размер раздела в мегабайтах.
Щелкните на кнопке Next (Далее). В открывшемся окне будут показаны выбранные параметры.
Щелкните на кнопке Finish (Готово) для завершения настройки и создания расширенного раздела.
После создания раздела необходимо создать как минимум один логический диск, на котором можно хранить данные. Щелкните правой кнопкой мыши на зеленой области в гра-, фическом отображении расширенного раздела и выберите из контекстного меню команду Create Logical Drive (Создать логический диск). Запустится мастер создания раздела (New Partition Wizard).
Щелкните на кнопке Next (Далее). Откроется окно Partition Туре (Тип раздела). По умолчанию в окне будет выбран переключатель Logical Drive (Логический диск).
Щелкните на кнопке Next (Далее). Откроется окно Specify Partition Size (Задайте размер раздела). Введите размер раздела.
Щелкните на кнопке Next (Далее). Откроется окно Assign Drive Letter or Path (Назначьте букву диска или путь). Назначьте букву диска или выберите том и каталог, которые будут использованы в качестве точки монтирования диска.
Щелкните на кнопке Next (Далее). Откроется окно Format Partition (Форматировать раздел).
Выберите файловую систему, которая будет использоваться на логическом диске.
Щелкните на кнопке Next (Далее). Откроется окно с выбранными параметрами.
Щелкните на кнопке Finish (Готово) для завершения настройки, создания и форматирования логического диска.
Теперь на консоли Disk Management (Управление дисками) должен отображаться расширенный раздел и соответствующие логические диски. Логические диски можно создавать, пока не закончится свободное дисковое пространство. Единственным ограничением является количество доступных букв диска, но даже в этом случае можно использовать точки монтирования без назначения букв дисков.
Расширение раздела базового диска
При наличии нераспределенного непрерывного дискового пространства рядом с разделом базового диска существует возможность расширения раздела базового диска. Но консоль Disk Management (Управление дисками) не предоставляет этой функциональной возможности. В этом случае необходимо воспользоваться утилитой Diskpart, которая предоставляется в составе Support Tools и работает в интерфейсе командной строки. Необходимая последовательность действий для расширения раздела базового диска приведена в процедуре 14.3. В процедуре указаны команды, которые необходимо вводить в окне утилиты Diskpart.
Процедура 14.3. Расширение раздела базового диска с помощью утилиты Diskpart
Запустите интерпретатор команд.
Запустите утилиту Diskpart. Откроется консоль утилиты.
Для отображения списка дисков на компьютере воспользуйтесь командой list disk.
Выберите диск, на котором содержится расширяемый раздел, с помощью команды select disk 0.
Для отображения списка разделов на выбранном диске воспользуйтесь командой list partitions.
Определите объем свободного дисков'ого пространства: detail volume.
Определите порядок и размер разделов: list volume.
Выберите раздел, который необходимо расширить: select partition 1.
Возле расширяемого раздела должно находиться свободное дисковое пространство. Получить эту информацию с помощью утилиты Diskpart невозможно, поэтому для проверки расположения разделов и нераспределенного дискового пространства необходимо воспользоваться консолью Disk Management (Управление дисками).
Расширьте раздел, указав объем дополнительного дискового пространства в мегабайтах: expand size=1024.
Проверьте размер нового раздела с помощью утилиты chkdsk или средствами Explorer (Проводник).
Преобразование базового диска в динамический ■
Проверьте выполнение приведенных ранее требований к базовому диску и выполните по- Щ следовательность действий, описанную в процедуре 14.4.
Процедура 14.4. Преобразование базового диска в динамический
Откройте консоль Disk Management (Управление дисками).
Щелкните правой кнопкой мыши на графическом представлении диска и выберите из контекстного меню команду Convert to Dynamic Disk (Преобразовать в динамический диск). Откроется окно Convert to Dynamic Disk (Преобразование в динамические диски).
Убедитесь, что выбран нужный диск.
Щелкните на кнопке ОК. Откроется окно Disks to Convert (Диски для преобразования). Убедитесь в правильности выбора дисков.
Щелкните на кнопке Convert (Преобразовать). Будет выдан запрос на подтверждение.
Щелкните на кнопке ОК для запуска преобразования. Если выполняется преобразование диска с операционной системой, загрузочного диска, диска с файлом подкачки или фай- лом аварийного дампа, будет выдан запрос на перезагрузку.
После перезагрузки будет выдан запрос на еще одну перезагрузку, так как диспетчер Plug- and-Play обнаружит динамические диски, как новые устройства.
После второй перезагрузки на диске можно будет создавать новые простые тома. Если на компьютере существуют другие динамические диски, нераспределенное дисковое простран- ство на диске можно будет использовать для создания томов, включая другие диски.
Создание простых томов на динамических дисках
На единственном динамическом диске можно создать несколько простых томов, что по- зволит получить несколько логических дисков. Кроме этого, поддерживается создание cd- ставных томов (кроме системного или загрузочного тома). Последовательность действий для создания простого тома описана в процедуре 14.5.
Процедура 14.5. Создание простых томов
Откройте консоль Disk Management (Управление дисками).
Щелкните правой кнопкой мыши на нераспределенном дисковом пространстве, в котором необходимо создать том, и выберите из контекстного меню команду Create Volume (Соз- дать том). Запустится мастер создания тома (New Volume Wizard).
Щелкните на кнопке Next (Далее). Откроется окно Select Volume Туре (Выберите тип тома).
Выберите переключатель Simple Volume (Простой том).
Щелкните на кнопке Next (Далее). Откроется окно Select Disks (Выберите диски), как показано на рис. 14.6. Задайте размер тома.^^Щ
Щелкните на кнопке Next (Далее). Откроется окно Assign Drive Letter or Path (Назначьте букву диска или путь). Назначьте букву диска или выберите пустой каталог на диске NTFS для монтирования тома.
Щелкните на кнопке Next (Далее). Откроется окно Format Volume (Форматирование тома). Для форматирования доступна только файловая система NTFS. Для выбора другой фай- ловой системы необходимо воспользоваться командой format.
Рис, 14.6. Окно Select Disks (Выберите диски) мастера создания тома
Щелкните на кнопке Next (Далее). В открывшемся окне будут показаны выбранные параметры.
Щелкните на кнопке Finish (Готово). Начнется создание и форматирование тома.
Расширение томов на динамических дисках (создание составного тома)
Для расширения простого тома к нему можно добавить нераспределенное дисковое пространство любого динамического диска. Расширение системного или загрузочного тома не поддерживается. Последовательность действий для создания составного тома изложена в процедуре 14.6.
Процедура 14.6. Настройка составного тома
Откройте консоль Disk Management (Управление дисками).
Щелкните правой кнопкой мыши на простом томе и выберите из контекстного меню команду Extend Volume (Расширить том). Запустится мастер расширения тома (Extend Volume Wizard).
Щелкните на кнопке Next (Далее). Откроется окно Select Disks (Выберите диски). Выберите диск, который будет использован для создания составного тома. В списке отображаются только динамические диски. Для создания составного тома подходит любой диск с нераспределенным (свободным) дисковым пространством.
Щелкните на кнопке Next (Далее). В открывшемся окне будут показаны выбранные параметры.
Щелкните на кнопке Finish (Готово). Начнется создание и форматирование тома.
Результат будет показан на консоли Disk Management (Управление дисками). Обратите внимание, что при расширении базового диска в результате создается новый раздел. При расширении динамического тома даже на прилегающее дисковое пространство на том же томе создается новый том. Составной том не приводит к проблемам отказоустойчивости, кроме того случая, когда компоненты составного тома находятся на разных дисках.
Создание томов с чередованием
Если необходим большой объем дискового пространства с повышенной производительностью, но без требований к отказоустойчивости, можно создать том с чередованием. Для создания такого тома необходимо свободное дисковое пространство как минимум на двух динамических дисках. Для получения максимального прироста производительности необходимо использовать раздельные контроллеры для каждого диска. Последовательность действий для создания тома с чередованием описана в процедуре 14.7.
Процедура 14.7. Создание тома с чередованием
Откройте консоль Disk Management (Управление дисками).
Щелкните правой кнопкой мыши на нераспределенном дисковом пространстве, которое будет включено в состав тома с чередованием, и выберите команду Create Volume (Создать том) из контекстного меню. Запустится мастер создания тома (New Volume Wizard).
Щелкните на кнопке Next (Далее). Откроется окно Select Volume Туре (Выберите тип тома).
Выберите переключатель Striped (Чередующийся).
Щелкните на кнопке Next (Далее). Откроется окно Select Disks (Выберите диски). Выберите как минимум еще один динамический диск, который будет входить в состав тома. В списке будут отображены только динамические диски. Для создания тома с чередованием можно использовать любой диск, на котором есть свободное дисковое пространство. Общее дисковое пространство на любом диске равняется размеру минимального объема сво- ' бодного дискового пространства на любом из выбранных дисков.
Щелкните на кнопке Next (Далее). Откроется окно Assign Drive Letter or Path (Назначьте букву диска или путь).’
Назначьте букву диска или смонтируйте том в пустой каталог тома NTFS.f
Щелкните на кнопке Next (Далее). Откроется окно Format Volume (Форматирование тома).
Доступна только файловая система NTFS.f
Щелкните на кнопке Next (Далее). Откроется окно с выбранными параметрами.
Щелкните на кнопке Finish (Готово). Начнется создание и форматирование тома.
Создание зеркалированных томов
При создании зеркалированных томов оставляйте свободное пространство в начале первого диска. Диски с одинаковыми характеристиками и даже диски от одного производителя часто имеют разные полезные объемы в зависимости от производственных допусков и общего • количества поврежденных секторов, выявленных во время низкоуровневого форматирования. Если вторичный диск хотя бы на один сектор меньше основного, система откажется создавать зеркало. Последовательность действий для создания зеркалированного тома описывается в процедуре 14.8.■
Процедура 14.8. Создание зеркалированных томов'
Откройте консоль Disk Management (Управление дисками).;
Щелкните правой кнопкой мыши на зеркалируемом томе и выберите из контекстного меню : команду Add Mirror (Добавить зеркало). Откроется окно Add Mirror (Добавить зеркало).j
Выберите диск, который будет использован в качестве зеркала, и щелкните на кнопке Add j
Mirror (Добавить зеркало).1
При зеркалировании загрузочного диска будет выдано предупреждение о необходимости добавить в файл Boot. ini строку для загрузки с зеркалированного диска. Например, ниже приведена запись из файла Boot. ini для включения загрузки со второго диска на том же контроллере SCSI, к которому подключен основной диск (описание диска загрузки придумано автором этой книги; можно указать любой другой заголовок):
multi(0)disk(0)rdisk(1)partition(1)\Windows="Windows
. 'Ъ Server 2003 Mirrored Secondary Disk" /fastdetect
Если на зеркалированном диске до создания зеркала никогда не существовало загрузочного раздела, загрузка системы с его помощью невозможна.
Щелкните на кнопке ОК для подтверждения. Система начнет создание зеркала. На это указывает состояние Regenerating (Регенерация) в графическом представлении дисков.
При регенерации содержимое основного диска посекторно копируется на вторичный диск. Для большого тома это может потребовать некоторого времени. Пользователи могут обращаться к файловой системе во время регенерации, но это приводит к увеличению времени регенерации. После завершения процедуры регенерации на консоли Disk Management (Управление дисками) отображается состояние диска Healthy (Исправен).
Разбиение зеркалированного тома
Если необходимо разбить зеркалированный том, зеркало можно разбить или удалить. Рассмотрим, что происходит при разбиении зеркала.
Файловая система сохраняется на обоих томах, что приводит к получению двух копий.
Для тома на вторичном (резервном) диске выделяется следующая доступная буква диска.
Если первичный (основной) диск является загрузочным, на нем сохраняется файл подкачки.
Если на зеркалированном томе существует каталог, который использован в качестве точки монтирования для другого тома, точка монтирования сохраняется на основном диске.
Совместно используемые ресурсы зеркалированного тома сохраняются на основном томе.
При удалении зеркала удаляется копия на одном или на обоих дисках. Сохраненный том получает ту же букву диска.
Разбиение зеркала — несложная операция. Сложнее решить проблемы, которые возникают в результате ее выполнения. Если зеркало содержит загрузочный том, при разбиении зеркала может возникнуть несколько проблем.
Последовательность действий по разбиению зеркала приведена в процедуре 14.9.
Процедура 14.9. Разбиение зеркала
Откройте консоль Disk Management (Управление дисками).
Щелкните правой кнопкой мыши на зеркалированном томе и выберите команду Break Mirror (Разбить зеркало) из контекстного меню.
Будет выдан запрос и предупреждение о нарушении отказоустойчивости дисков. Щелкните на кнопке Yes (Да).
Если выполняется разбиение зеркала с загрузочным диском, система предупредит о преобразовании используемого тома и запросит подтверждение. Щелкните на кнопке Yes (Да).
Система выполнит разбиение зеркала и назначит тому на вторичном диске следующую доступную букву диска.
Теперь, когда зеркало разбито, попытайтесь загрузиться с помощью второго диска. Будет выдано сообщение об ошибке Inaccessible Boot Device (Недоступно загрузочное уст-
ройство). Это связано с тем, что второй диск никогда не разбивался на разделы для поддержки загрузки, поэтому на нем отсутствует таблица разделов в записи MBR. В таком случае воспользуйтесь утилитой Diskpart для добавления разделана диск.
Сначала загрузитесь с зеркалированного диска с использованием загрузочного гибкого диска. После этого запустите утилиту Diskpart и введите следующие команды (в этом примере предполагается, что диск является первым диском массива и том расположен в начале диска): DISKPART> Select disk О DISKPART> Select volume 1 DISKPART> Retain
Кроме этого, может возникнуть проблема из-за несоответствия буквы диска. Система ожидает, что загрузка будет выполнятся с диска С. Если загрузить систему с зеркалированного диска, буква диска будет отличаться, что может вызвать определенные проблемы.
Этих проблем можно избежать, если все вовремя предвидеть. Перед разбиением зеркала загрузитесь со вторюго тома с помощью загрузочного гибкого диска. Воспользуйтесь консолью Disk Management (Управление дисками) для разбиения зеркала. В таком случае буква “С” будет назначена вторичному диску зеркала.
Создание томов RAID 5
Если в системе присутствует как минимум три динамических диска со свободным дисковым пространством, их можно использовать для создания тома RAID 5. Размер тома ограничен доступным дисковым пространством на самом маленьком диске. Например, если в системе присутствует два диска объемом 4 Гбайт и один диск объемом 2 Гбайт, общий объем массива RAID 5 составит 6 Гбайт, а эффективный объем составит 4 Гбайт. Для создания такого массива выполните последовательность действий, описанную в процедуре 14.10.
Процедура 14.10. Создание тома RAID 5 j.
Откройте консоль Disk Management (Управление дисками).
Щелкните правой кнопкой мыши на графическом представлении одного из дисков, который будет входить в состав тома RAID 5, и выберите из контекстного меню команду Create Volume (Создать том). Запустится мастер создания тома (New Volume Wizard).
Щелкните на кнопке Next (Далее). Откроется окно Select Volume Туре (Выберите тип тома).
Выберите переключатель RAID 5.
Щелкните на кнопке Next (Далее). Откроется окно Select Disks (Выберите диски). Выберите как минимум два других диска, которые будут составлять том.
Щелкните на кнопке Next (Далее). Откроется окно Assign Drive Letter or Path (Назначьте букву диска или путь).
Назначьте тому букву диска или выберите пустой каталог на томе NTFS.
Щелкните на кнопке Next (Далее). Откроется окно Format Volume (Форматирование тома). Доступна только файловая система NTFS.
Щелкните на кнопке Next (Далее). В окне будут показаны выбранные параметры.
Щелкните на кнопке Finish (Готово). Начнется создание и форматирование тома.
Удаление тома, содержащего точки монтирования
При удалении тома, на котором существуют точки монтирования NTFS, данные на смонтированном томе сохраняются. Позднее том можно будет смонтировать в другой каталог или назначить тому собственную букву диска.
Создание тома и его форматирование с файловой системой займет некоторое время (соответствующее состояние будет показано в разделе свойств тома). Если создается том очень большого размера, можно пойти на длительный обед.
Удаление тома
Диспетчер логических дисков (LDM) поддерживает изменение размера только для простых томов. Для изменения размера тома его необходимо удалить и создать повторно. После создания резервной копии можно выполнить последовательность действий, описанную в процедуре 14.11.
Процедура 14.11. Удаление тома
Откройте консоль Disk Management (Управление дисками).
Щелкните правой кнопкой мыши на удаляемом томе и выберите из контекстного меню команду Delete Volume (Удалить том).
Система выдаст запрос на подтверждение. Щелкните на кнопке Yes (Да).
Если появится сообщение об ошибке, в котором указано, что преобразуемый том используется, можно отменить удаление и найти открытые файлы. Если список открытых файлов не очевиден, обратитесь к списку запущенных процессов в Task Manager (Диспетчер задач). Возможно, том блокируется одним из этих процессов. Обратите особое внимание на антивирусное программное обеспечение.
После удаления тома на консоли Disk Management (Управление дисками) будет отображаться свободное дисковое пространство.
Преобразование динамического диска в базовый
После преобразования базового диска в динамический обратное преобразование невозможно. В отличие от LDM в операционной системе Windows 2000, LDM в операционной системе Windows Serve 2003 вносит постоянные изменения в таблицу разделов. Для преобразования сначала придется создать резервную копию данных и удалить все тома. Это касается и дисков, задействованных в создании составных и зеркалированных томов, томов с чередованием и томов RAID 5. После этого диск можно преобразовать в базовый. Если на этом диске находится операционная система, ее придется переустановить. В процессе установки удалите все существующие разделы.
Изменение буквы диска
Операционная система Windows всегда отличалась странным алгоритмом назначения букв логическим дискам. В главе 1, “Установка и настройка Windows Server 2003”, этот алгоритм рассматривался подробно. Но буквы дисков можно менять и после установки. Это может удивить некоторых пользователей, которые привыкли работать только с операционными системами Windows 98 и Windows ME.
В операционных системах Windows Server 2003 и Windows ХР буквы дисков меняются при добавлении и удалении подключаемых дисков. Это касается и приводов сменных носителей. При наличии носителя во время загрузки привод отображается и получает букву диска. Если носителя во время загрузки нет, привод не отображается и букву диска получает какой- то другой привод.
Если забыть отключить сетевой диск перед созданием нового тома или раздела, новому тому или разделу могут быть назначены необычные буквы дисков.
Если буква диска назначается фиксированному диску, она сохраняется. Это справедливо даже в случае модернизации более старой версии операционной системы Windows. Это позволяет сохранить доступ к подсистеме хранения для тех приложений, которые используют буквы диска в записях системного реестра.
Если необходимо изменить букву, связанную с определенным диском, воспользуйтесь консолью Disk Management (Управление дисками). Существует несколько ограничений.
Нельзя менять букву раздела или тома, на котором хранятся загрузочные или системные файлы. .
Изменение буквы диска может привести к отказу при запуске некоторых приложений. Может потребоваться изменение связанной с этим приложением информации в системном реестре.
Изменение буквы диска приводит к недоступности всех совместно используемых ресурсов, связанных с этим томом. Записи системного реестра, соответствующие именам совместно используемых ресурсов, хранятся в разделе HKLM\System\CurrentControlSet\ Services\LanManServer\Shares. Запишите или сделайте копию жрана с этими записями перед изменением буквы диска. Если не изменить информацию для совместно используемого ресурса, то служба поддержки получит множество звонков от раздраженных пользователей.
При наличии ярлыков для файлов и каталогов на томах NTFS и в разделах система распределенного отслеживания ссылок автоматически исправит ярлыки при перемещении или переименовании файлов. При изменении буквы диска система отслеживания ссылок не вносит автоматические изменения в базу данных. Несмотря на это, клиент отслеживания ссылок пытается “угадать” правильное расположение файла, подставляя новую букву диска.
Изменение буквы диска никак не влияет на точки монтирования (папки, в которых содержатся символьные ссылки на файловые системы или другие папки). Во внутренней базе данных используются идентификаторы GUID, а не буквы диска.
В примере, описанном в процедуре 14.12, показано, как изменить букву диска привода компакт-дисков. Этот же метод может использоваться для изменения буквы диска фиксированного диска или привода сменных носителей.
Совет по использованию системного реестра: информация
о точке монтирования
Записи системного реестра с информацией о точках монтирования хранятся в разделе нкси\ Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints .
Процедура 14.12. Изменение буквы диска
Откройте консоль Disk Management (Управление дисками).
Щелкните правой кнопкой мыши на пиктограмме диска в текстовом разделе окна или на ’ области состояния в графическом представлении диска и выберите из контекстного меню < команду Change Drive Letter and Path (Изменить букву диска или путь). Откроется окно 1 Drive Letter and Path (Буква диска или путь).j
Щелкните на кнопке Modify (Изменить). Откроется окно Modify Drive Letter or Path (Изме- : нить букву диска или путь).:
Выберите новую букву диска из раскрывающегося списка Assign a Drive Letter (Назна- i чить букву диска).j
Щелкните на кнопке ОК для сохранения внесенных изменений. Будет выдан запрос на j подтверждение. Щелкните на кнопке Yes (Да). В системный реестр будут внесены изме- J нения, которые отображаются на консоли Drive Management (Управление дисками). j
Управление дисками из командной строки
В составе операционной системы Windows Server 2003 предоставляется мощная и удобная утилита для управления конфигурацией дисков. Эта утилита называется Diskpart и входит в состав пакета Support Tools, который доступен на установочном компакт-диске Windows Server 2003. При помощи утилиты Diskpart можно создавать, настраивать и удалять все базовые разделы и динамические тома на локальном и удаленных компьютерах.
Утилита представляет собой текстовую консоль с набором пространств имен, между которыми можно перемещаться с помощью интерактивных команд. Команды можно использовать для выбора компьютер», просмотра параметров и выполнения операций. Например, для получения списка параметров всех разделов и томов на диске можно воспользоваться следующими командами:
DISKPART> select disk 0
Disk 0 is now selected disk.
DISKPART> detail disk
Maxtor 90651U2 Disk ID: 30063005
Type:IDE
Bus:0
Target:0
LUN ID: 0
Volume ### Ltr Label Fs TypeSize Status Info
Volume
1
С
NTFS
Partition
4103
MB
Healthy
System
Volume
2
Е
NTFS
Partition
196
MB
Healthy
Volume
3
F
NTFS
Partition
502
MB
Healthy
Создание раздела базового диска
Ниже приводится последовательность команд утилиты Diskpart для создания раздела на базовом диске. Для форматирования раздела можно воспользоваться утилитой format, работающей в интерфейсе командной строки. Последовательность команд выглядит следующим образом:
DISKPART> Select Disk 0
DISKPART> Create Partition Primary Size=2048
DISKPART> Assign Letter=h
DISKPART> Exit
C:\>format h: /fs:ntfs
Обратите внимание, что утилитой Diskpart можно воспользоваться для назначения или изменения буквы диска. Если время от времени возникают проблемы со сменой букв дисков при подключении или отключении приводов сменных носителей, можно создать файл пакетной обработки, который будет переназначать буквы диска для каждой конфигурации.
Создание динамического тома
С помощью утилиты Diskpart можно создать том с чередованием или том RAID 5, а также зеркало существующего простого тома. Рассмотрим пример создания тома RAID 5: DISKPART> List Disk
Disk
###
Status
Size
Free
Dyn
Gpt
Disk
0
Online
6142
MB
1341
MB
*
Disk
1
Online
12288
MB
12288
MB
*
Disk
2
Online
12288
MB
12288
MB
*
Disk 3 Online 12288 MB 12288 MB *
DISKPART> Create Volume Raid Disk=l,2,3
Расширение раздела на базовом диске
Утилита Diskpart позволяет расширять разделы на базовых и динамических дисках. Для утилиты Diskpart справедливы те же ограничения, что и для консоли Disk Management (Управление дисками) (обратите внимание: в утилите Di^kpart термин том (volume) используется для описания как базовых разделов, так и динамических томов).
Следующие команды позволяют добавить 2 Гбайт к существующему базовому разделу; это может быть системный или загрузочный раздел:
DISKPART> list volume
DISKPART> select volume 0
DISKPART> extend size=2048
Ту же последовательность команд можно использовать для расширения простого динамического тома, но такой том не может содержать системные или загрузочные файлы.
Дополнительные операции утилиты Diskpart
Утилиту Diskpart также можно использовать для выполнения следующих операций.
Преобразование базового диска в динамический и наоборот.
Операции с дисками GPT.5
Удаление томов и разделов (с минимальной проверкой или вообще без проверки, поэтому j следует соблюдать осторожность).1
Импорт внешних дисков в локальную базу данных LDM.j
Создание записей в таблице разделов в записи MBR, соответствующих тому в базе данных I
LDM. Это необходимо для создания загрузочного динамического диска, который никогда | не был базовым диском.I
Восстановление данных на отказоустойчивых дисках i
Если данные хранятся на единственном диске или в томе без свойств отказоустойчивости, на- 1 пример в составном томе или томе с чередованием, то при отказе диска можно с полной уверенно- j стью утверждать, что данные потеряны. Поскольку отказ диска является неизбежным фактом при ] эксплуатации компьютеров, предполагается, что используется надежная система резервного копи- 1 рования, которая позволяет быстро восстановить нужные данные. Если отказал один диск тома с 1 чередованием, то необходимо удалить том с остальных дисков, заменить диск и восстановить том. 1
С другой стороны, если нет желания общаться с массами паникующих пользователей и их обе- | зумевшими менеджерами, которые собираются возле “серверной”, как разъяренная французская | толпа, ищущая, кого бы засунуть в гильотину, используйте для хранения данных тот или иной тип | отказоустойчивой подсистемы хранения. В этом разделе рассматривается восстановление системы 1 после отказа диска. Во время восстановления могут выполняться следующие операции. |
Замена отказавшего диска в томе RAID 5 1 ■ Создание загрузочного гибкого диска 1 ■ Замена отказавшего диска в зеркалированном томе 1 ■ Перемещение динамических томов между компьютерами 1
Замена отказавшего диска в томе RAID 5
При отказе диска в томе RAID 5 в зоне уведомлений на панели задач будет выдано совсем небольшое предупреждение в течение очень короткого промежутка времени. В сообщении сказано, что A disk that is part of a fault-tolerant volume can no longer be accessed (Диск в составе отказоустойчивого тома больше недоступен). Это сообщение выдается процессом FT Orphan. Это специальный процесс, который логически отключает диск от системы и позволяет избежать повреждения данных.
Файловая система на томе отказавшего диска остается активной. Единственным признаком отказа (если не установлена утилита от стороннего производителя, которая уведомляет о таких сообщениях в журнале событий) является незначительное снижение производительности при операциях ввода-вывода.
Обнаружив отказавший диск, откройте консоль Disk Management (Управление дисками). На консоли должны отображаться сведения наподобие тех, которые показаны на рис. 14.7. Каждый диск в составе тома будет иметь состояние Failed Redundancy (Отказ избыточности), а напротив отказавшего диска будет отображаться пиктограмма Stop красного цвета.
Отказоустойчивые свойства массива RAID 5 позволяют системе оставаться в работоспособном состоянии. Но с этого момента ситуация становится угрожающей. Отказ следующего диска приведет к потере данных. Если диски произведены одновременно на одной сборочной линии, после отказа первого диска остается очень мало времени (в зависимости от природы отказа).
Найдите запасной диск, объем которого как минимум не меньше объема отказавшего диска. Диск должен быть настроен на использование того же SCSI ID, который использовался старым диском. Это позволит упростить установку, хотя и не является обязательным требованием.
Рис. 14.7. На консоли Disk Management (Управление дисками) отображается отказавший диск в составе тома RAID 5
Воспользуйтесь консолью Disk Management (Управление дисками) для проверки идентификатора SCSI ID, назначенного отказавшему диску. Щелкните правой кнопкой мыши на области состояния и выберите из контекстного меню команду Properties (Свойства). Будут показаны значения параметров SCSI ID (или Target ID) и Local Unit Number (LUN). Рекомендую
вложить распечатку копии экрана в корпус сервера, чтобы иметь представление о конфигурации при замене отказавшего диска. Подробная карта позволит не заблудиться в лабиринтах кабелей SCSI внутри корпуса сервера. Нет ничего хуже ошибочной замены не того диска.
После того как получен запасной диск и закончился рабочий день пользователей, можно начинать работу. Завершите работу сервера и замените диск. Проверьте работоспособность диска с помощью аппаратных утилит IDE или SCSI.
После этого загрузите операционную систему. Массив RAID 5 начнет инициализацию, и будет смонтирована файловая система. Откройте консоль Disk Management (Управление дисками). Консоль должна выглядеть так, как показано на рис. 14.8.
Том RAID 5 все еще будет в состоянии Failed Redundancy (Отказ избыточности). Появится блок состояния отказавшего диска, так как информация в базе данных LDM хранится на других дисках. Поскольку установлен новый диск, на нем отсутствует отказоустойчивая сигнатура или запись MBR. Система будет показывать состояние диска, как Unknown (Нет данных). Дополнительная информация приводится в процедуре 14.13.
Задержки при обновлении консоли Disk Management (Управление дисками)
Иногда при загрузке консоли Disk Management (Управление дисками) происходит неправильная инициализация диспетчера LDM. В таком случае состояние тома RAID 5 может отображаться как Healthy (Исправен), хотя на самом деле том поврежден. В таком случае воспользуйтесь командой Actions Rescan Disks (Действие^Повторить сканирование дисков), закройте консоль Disk Management (Управление дисками) и откройте ее повторно. Эти действия, возможно, придется выполнить несколько раз, пока не отобразится статус диска Failed Redundancy (Отказ избыточности).
Рис. 14.8. На консоли Disk Management (Управление дисками) отображаются диск в состоянии Unknown (Нет данных) и том RAID 5 в состоянии Failed Redundancy (Отказ избыточности)
Storage Management for SANs (Управление сетями хранилищ данных)
Оснастка для операционной системы Windows Server 2003 R2 Storage Management for SANs (Управление сетями хранилищ данных) является консолью ММС, которая поможет создавать и управлять номерами логических устройств (LUNs) на оптоволоконных каналах и дисковыми устройствами iSCSI в вашей сети хранилищ данных. Данная оснастка может быть использована для управления подсистемами хранилищ которые поддерживают VDS.
Решение Storage Management for SANs (SMfS) позволяет находить системы SAN на базе Fibre Channel или iSCSI, включая низкоуровневую информацию SAN о свойствах системы хранения. Вы можете создавать, уничтожать и расширять номера LUN (logical unit number) системы хранения, которые идентифицируют области хранения. Можно назначать LUN для определенных серверов в SAN и следить за статусом, работоспособностью и размещением. Доступ к большей части основных функций SMfS осуществляется с помощью простых мастеров.
Процедура 14.13. Замена отказавшего диска в томе RAID 5
Запишите сигнатуру на новый диск. Для этого выполните последовательность действий, предложенную мастером.
Обновите диск до динамического диска.
Щелкните правой кнопкой мыши на томе RAID 5 и выберите из контекстного меню команду Repair Volume (Восстановить том).
Выберите новый диск, который будет использован для замены отказавшего диска. После этого новый диск станет частью массива RAID 5 и система начнет регенерацию тома. Эта операция может потребовать длительного времени, иногда нескольких часов. Если пользователи продолжают обращаться к диску, регенерация займет еще больше времени.
Во время регенерации щелкните правой кнопкой мыши на области состояния отказавшего диска и выберите команду Remove Disk (Удалить диск) из контекстного меню (убедитесь в том, что удаляете именно отказавший диск). Область состояния исчезнет, а графическое представление изменит форму, соответствуя новой конфигурации дисков.
Создание загрузочного гибкого диска
При зеркалировании загрузочного тома (наиболее популярный метод обеспечения отказоустойчивости) одним из самых важных инструментов восстановления после отказа является загрузочный гибкий диск. Второй диск зеркала необязательно является загрузочным, поэтому необходим способ загрузки системы с зеркалированного тома на вторичном диске, если основной диск откажет.
Даже если вторичный диск поддерживает загрузку, в файле Boot. ini может отсутствовать запись, которая будет указывать на вторичный диск.
Иногда загрузочный гибкий диск полезен при устранении неполадок, связанных с ошибками в записи MBR или в загрузочном секторе раздела. Такие неполадки не дают загрузить сервер, а основной причиной возникновения подобных проблем являются компьютерные вирусы.
Загрузочный гибкий диск не позволяет загрузить всю операционную систему Windows Server 2003. Для загрузки операционной системы используются только загрузочные файлы, которые обычно расположены в корневом каталоге жесткого диска с операционной системой.
В процедуре 14.14 показана краткая последовательность действий для создания загрузочного гибкого диска. Дополнительная информация о путях ARC и записях файла Boot. ini приводится в главе 3, “Добавление аппаратных средств”.
Процедура 14.14. Создание загрузочного гибкого диска
Отформатируйте гибкий диск. Предварительно отформатированный гибкий диск использовать нельзя, поскольку код в загрузочном секторе должен пытаться обнаружить загрузчик Ntldr. Можно использовать гибкий диск, отформатированный на компьютере под управлением Windows NT 4.0.
Скопируйте системные файлы в корневой каталог диска А. В корневом каталоге должны присутствовать следующие файлы.
Ntldr
Ntdetect.com
Boot.ini
Ntbootdd. sys (при необходимости)
Воспользуйтесь командой attrib для снятия атрибута Only Read (Только чтение) для файла Boot.ini.
Отредактируйте файл Boot. ini на гибком диске и добавьте следующий путь ARC к загрузочному тому на втором диске:
multi(0)disk(0)rdisk(1)partition(1)\Windows="Windows
4> Server 2003 Mirrored Secondary Disk" /fastdetect
Кроме этого, можно отключить счетчик времени, задав значение [ms ] 1.
Перезагрузите компьютер и загрузитесь с помощью загрузочного гибкого диска.
При появлении меню загрузчика выбёрите вторичный диск. Система загрузится с вторичного диска. На этом этапе гибкий диск больше не нужен. Его можно извлечь из привода.
Замена отказавшего диска в составе зеркалированного тома
При отказе диска, который входит в зеркалированный том, система реагирует точно так же, как при отказе диска в составе тома RAID 5. При попытке системы записать данные и отсутствии ответа от диска процесс FT Orphan отключает диск от системы и выдает сообщение с помощью пиктограммы в области уведомлений. По возможности процесс FT Orphan блокирует системный реестр на отказавшем диске, поэтому даже если удастся восстановить работоспособность диска, загрузка операционной системы с этого диска окажется невозможной.
Если после отказа диска запустить консоль Disk Management (Управление дисками), содержимое консоли должно быть похоже на изображение, показанное на рис. 14.9. Для отказавшего диска отображается состояние Missed (Отсутствует). Для зеркалированного тома отображается состояние Failed Redundancy (Отказ избыточности). Вторичный диск переместится на вершину списка дисков. Так происходит не во всех системах (в зависимости от конфигурации SCSI ID).
Можно заметить, что по информации на консоли очень сложно определить, какой диск отказал. Внимательно записывайте идентификаторы SCSI и номера контроллеров IDE.
Как и в случае с отказом массива RAID 5, действия по восстановлению массива необязательно выполнять непосредственно после отказа, но чем дольше выполняется восстановление массива, тем выше вероятность потери данных.
Подберите новый диск, объем которого как минимум не меньше объема отказавшего диска. Настройте новый диск на использование того же идентификатора SCSI или конфигурацию главного/подчиненного диска IDE для более простого восстановления. После завер- ; шения всех подготовительных мероприятий можно заменить отказавший диск, как описа- ; но в процедуре 14.15.)
Процедура 14.15. Замена отказавшего диска в зеркалированном томе
Завершите работу сервера и замените диск.
Перезагрузите компьютер с помощью загрузочного гибкого диска. Если новый диск на- строен на использование того же идентификатора SCSI, что и старый, выберите пункт загрузчика из файла Boot. ini, который соответствует значению параметра rdisk () для старого диска. Если использован другой идентификатор SCSI, определите новое значение параметра rdisk () на основе порядка сканирования шины SCSI. Воспользуйтесь утилитой настройки адаптера SCSI для просмотра порядка сканирования и отредактируйте файл Boot. ini на загрузочном гибком диске для использования нового идентификатора SCSI.
После завершения загрузки операционной системы откройте консоль Disk Management (Управление дисками). На новом диске отсутствует отказоустойчивая сигнатура или копия базы данных диспетчера LDM, поэтому запустится мастер инициализации и преобразования диска (Initiate and Convert Disk Wizard), который поможет записать на диск сигнатуру и преобразовать диск в динамический.
Рис. 14.9. На консоли Disk Management (Управление дисками) отображается отказавший основной диск зеркалированного тома
После завершения работы мастера становится доступной консоль Disk Management (Управление дисками). Может удивить, что старый дйск присутствует одновременно с новым. Это сделано специально, чтобы напоминать об оригинальной конфигурации (рис. 14.10).
Щелкните правой кнопкой мыши на зеркалированном томе и выберите из контекстного меню команду Remove Mirror (Удалить зеркало). Откроется окно Remove Mirror (Удалить зеркало).
Выберите отказавший диск из списка и щелкните на кнопке Remove Mirror (Удалить зеркало). Система выдаст запрос на подтверждение удаления. Щелкните на кнопке Yes (Да). Оставшийся диск зеркала теперь будет иметь состояние Healthy (Исправен).
Щелкните правой кнопкой мыши на блоке состояния отказавшего диска и выберите команду Remove Disk (Удалить диск) из контекстного меню. Диск немедленно исчезнет из консоли.
Убедившись в способности основного диска зеркала обеспечивать загрузку, восстановите зеркалированный том, выполнив последовательность действий, описанную в процедуре 14.8. Если новый основной диск не поддерживает загрузку, создайте резервную копию данных, переустановите операционную систему и восстановите данные из копии. Это позволит сделать основной диск загрузочным. После этого восстановите зеркалированный том.
Рис. 14.10. Консоль Disk Management (Управление дисками) после замены диска перед восстановлением нового диска
Перенос динамических дисков между компьютерами
Иногда сервер или рабочая станция полностью и безвозвратно выходит из строя. (Обычно это происходит за полчаса до отъезда в отпуск, который планировался в течение последнего года.) Если проблема не связана с работоспособностью подсистемы хранения, одним из быстрых методов решения проблемы является перенос дисков на другой компьютер.
Перенос дисков на другой компьютер может стать причиной целого ряда проблем. Операционная система Windows Server 2003 хранит в системном реестре достаточно большой объем информации, связанной с используемой аппаратной платформой. Если будете перемещать загрузочный диск (диск с файлами операционной системы) на другую платформу, не удивляйтесь повышенной активности подсистемы Plug-and-Play во время загрузки операционной системы. Могут потребоваться дополнительные драйверы для аппаратных средств. Если подсистема управления памятью не сможет интерпретировать конфигурацию памяти или набора микросхем, операционная система может отобразить синий экран, сигнализирующий о критической ошибке. Можно практически не сомневаться в возникновении проблем, если новый сервер требует использования другой библиотеки уровня аппаратных абстракций (Hardware Abstraction Layer — HAL). '
Перенос на другой компьютер диска с данными связан со значительно меньшими сложностями. Если переносится базовый диск, система просто обнаруживает новый диск, читает таблицу разделов и назначает разделам следующие доступные буквы дисков.
Перенос динамического диска, особенно содержащего составные тома, немного сложнее. Необходимо выполнить слияние базы данных LDM с нового диска и уже присутствующей на компьютере базы данных LDM. .
Операционная система на другом компьютере идентифицирует новые диски как внешние и обозначает их с помощью имени foreign disks (посторонние диски). Последовательность действий, описанная в процедуре 14.16, заставляет операционную систему импортйровать базу данных LDM и изменить имя группы дисков, чтобы перенесенные диски можно было использовать в другой системе. .' .
SNB3SFRE.EN (D:) SdNew Volume (Et)SNB3SFRE.EN (D:) SdNew Volume (Et)SimplePartitionSimplePartitionDynamicDynamicNTFS CDFSNTFSNTFS CDFSNTFSHealthy (5... 4.88 GBHealthy (5... 4.88 GBHealthyHealthyHealthyHealthy549 MB5.86 GB549 MB5.86 GBТакяЗ^ТакяЗ^2.73 GB 0 MB5.37 GB2.73 GB 0 MB5.37 GB91 *91 *9dm о Dyan*: 18.64 GB9dm о Dyan*: 18.64 GB(C:)4.88 GB NTFS Healthy (System)(C:)4.88 GB NTFS Healthy (System)[l4ew Volume (Б) 5.86 GB NTFSJ Healthy[l4ew Volume (Б) 5.86 GB NTFSJ Healthy.„.Ц,.,.*,»^...,,. ■ ■„« „I*. .*»,...»H .**I*.M*|..„.Ц,.,.*,»^...,,. ■ ■„« „I*. .*»,...»H .**I*.M*|.jUnaiocatedjUnaiocatedJjJj
SNB3SFRE.EN (D:) SdNew Volume (Et)
SNB3SFRE.EN (D:) SdNew Volume (Et)
Simple
Partition
Simple
Partition
Dynamic
Dynamic
NTFS CDFS
NTFS
NTFS CDFS
NTFS
Healthy (5... 4.88 GB
Healthy (5... 4.88 GB
Healthy
Healthy
Healthy
Healthy
549 MB
5.86 GB
549 MB
5.86 GB
ТакяЗ^
ТакяЗ^
2.73 GB 0 MB
5.37 GB
2.73 GB 0 MB
5.37 GB
91 *
91 *
9dm о Dyan*: 18.64 GB
9dm о Dyan*: 18.64 GB
(C:)
4.88 GB NTFS Healthy (System)
(C:)
4.88 GB NTFS Healthy (System)
[l4ew Volume (Б) 5.86 GB NTFS
J Healthy
[l4ew Volume (Б) 5.86 GB NTFS
J Healthy
.„.Ц,.,.*,»^...,,. ■ ■„« „I*. .*»,...»H .**I*.M*|.
.„.Ц,.,.*,»^...,,. ■ ■„« „I*. .*»,...»H .**I*.M*|.
jUnaiocated
jUnaiocated
Jj
Jj
Процедура 14.16. Перенос отказоустойчивого тома на другой компьютер
Завершите работу серверов и перенесите диски. Может потребоваться дополнительное пространство для установки дисков, переключение терминаторов, назначение новых идентификаторов SCSI и т.д. Целью этих приготовлений является размещение дисков поблизости друг от друга, хотя это и необязательно.
После установки дисков убедитесь в их подключении и правильности порядка установки. База данных LDM поддерживает изменение порядка дисков, но работа администратора значительно усложнится, если на консоли Disk Management (Управление дисками) перенесенным дискам будут назначаться случайные буквы.
Загрузите операционную систему и удостоверьтесь в правильности ее загрузки. Данные на новых дисках будут недоступны, пока не завершится импорт дисков. Кроме этого, любые совместно используемые ресурсы для каталогов на подключаемых дисках необходимо создать заново.
Откройте консоль Disk Management (Управление дисками). После инициализации графическое представление дисков будет выглядеть так, как показано на рис. 14.11. Для дисков с другого компьютера отображается состояние Foreign (Чужой).
Щелкните правой кнопкой мыши на блоке состояния внешнего диска или дисков и выберите из контекстного меню команду Import Foreign Disks (Импорт чужих дисков). Откроется окно Import Foreign Disks (Импорт чужих дисков), в котором отображается имя оригинального сервера, с которого взяты диски. Эта информация извлекается из базы данных LDM, которая хранится в конце каждого диска.
, Disk Management
Dynamic
Foray
■ Urebcatod ■ РпнемМ* ■ SeebyoUw
Puc. 14.11. На консоли Disk Management (Управление дисками) отображаются динамические диски, перенесенные с другого компьютера и подключенные на новом компьютере
Щелкните на кнопке ОК. Система выполнит анализ дисков. После этого откроется окно Verify Volumes on Foreign Disks (Проверка томов на чужих дисках).
Система может выдать состояние данных как Data Incomplete (Неполные данные). Это значит, что перенесены не все диски из дисковой группы. Так бывает, если загрузочный/ системный диск оригинального сервера был динамическим или в группе присутствовали другие динамические диски, которые не переносились умышленно. Удостоверьтесь, что
перенесены все диски, которые составляют общий том. Можно перенести и часть дисков группы, но для этого придется выполнить дополнительные операции.
7.7.8.8.9.9.Щелкните на кнопке ОК. Система сообщит, что восстановление данных может завершиться неудачно, если в предыдущем окне было выдано состояние Data Incomplete (Неполные данные).
7.
7.
8.
8.
9.
9.
Щелкните на кнопке ОК, чтобы согласиться с предупреждением. Система начнет импорт дисков, после чего попытается создать тома и инициализировать файловую систему. Для дисков может быть выдано состояние Failed (Отказавший). Не беспокойтесь (пока). Это нормально, если перенесены не все диски группы.
Щелкните правой кнопкой мыши на блоке состояния любого из новых дисков и выберите из контекстного меню команду Reactivate Disk (Реактивизировать диск). Система “заду мается” на долгое время, в течение которого будут слышны звуки активного обращения к дискам. Если повторная активизация завершилась успешно, тому будет назначена бу ква диска и состояние диска изменится на Regenerating (Регенерация). Регенерация требует много времени и занимает значительную долю ресурсов центрального процессора. В процессе регенерации файловая система уже активна и обеспечивает доступ к файлам, но этого делать не рекомендуется, так как дополнительное обращение к диску замедляет процесс регенерации. После завершения регенерации новые тома получат состояние Healthy (Исправен).
Существует вероятность, что после импорта любой из дисков будет иметь состояние Errof (Ошибка). Это связано с наличием в базе данных LDM значений, которые не поддаются интерпретации. В таком случае щелкните правой кнопкой мыши на блоке состояния диска и выберите команду Reactivate Disk (Реактивизировать диск) из контекстного меню. Использование этой команды должно привести к немедленному устранению проблемы.
Работа с дисками GPT,
Как было показано в начале этой главы, на платформе Itanium используется новая схема разделов дисков, которая называется GUID Partition Tables, или GPT. Новая схема разрабо тана для устранения некоторых недостатков классической схемы MBR, перечисленных ниже.
Диск MBR может иметь только четыре основных раздела.
Максимальный размер раздела ограничен сокращенной записью геометрии Цилиндр/ Головка/Сектор.
Нет координации между разными схемами разделов. Это вызывает проблемы у произво дителей дисковых утилит, которые должны предполагать, как конкретная схема “выравнивается" по границам цилиндров для обычных дисков и виртуальных дисков, предоставленных контроллерами RAID.
За время существования дисков MBR возникло множество утилит и операционных систем, которые используют скрытые секторы, содержащие критические параметры и компоненты подсистемы хранения.
На диске хранится единственная копия записи MBR, что приводит к отказу диска в случае отказа соответствующего сектора.
В главе 1, “Установка и настройка Windows Server 2003", рассматривалось использование программы установки для разбиения дисков GPT на разделы для операционной системы Windows Server 2003, а в главе 3, “Добавление аппаратных средств”, рассматривались установка и настройка нового диска GPT. В этом разделе содержится общая информация для сравнения использования дисков GPT и дисков MBR.
Усовершенствования в схеме GPT
В дисках GPT ограничения классической схемы MBR решаются благодаря полной замене системы. В первом секторе диска GPT существует запись MBR, но она предназначена исключительно для защиты диска. Стандартные дисковые утилиты расценивают отсутствие записи MBR как отсутствие разделов на диске. В этом случае утилиты стараются автоматически разбить диск на разделы, что приводит к потере данных в разделах GPT.
Вместо классической записи MBR диск GPT использует базу данных, в которой отслеживаются идентификаторы и расположение разделов. Тип раздела идентифицируется в базе данных с помощью глобально уникального идентификатора, а не по имени. Создав глобально уникальный идентификатор, производитель может определить новый тип раздела и иметь уверенность, что этот идентификатор не используется другим производителем.
Диски GPT предоставляют следующие преимущества по сравнению с дисками MBR.
Разделы начинаются на границе сектора, а не на границе цилиндра. Это позволяет значительно упростить взаимодействие дисков в пределах одного компьютера.
Диски GPT поддерживают создание до 128 разделов.
Один раздел может иметь размер до 18 Эбайт, что эквивалентно подключению 19 миллионов терабайтных дисковых массивов.
Создаются избыточные копии записей разделов GPT. Кроме этого, вместе с данными раздела хранится значение CRC, которое используется для контроля целостности.
Все данные хранятся в определенных разделах. Операционная система скрывает разделы, которые не используются для хранения данных, а имеют другое назначение.
Компьютеры Itanium могут использовать диски MBR, но загрузка возможна только с диска GPT. Интерфейс Extensible Firmware Interface (EFI) на компьютере Itanium пытается найти информацию загрузчика операционной системы на загрузочном диске. В спецификации EFI допускается хранение такой информации на диске MBR, но операционные системы Windows Server 2003 и Windows ХР поддерживают загрузку только с диска EFI.
Диск MBR можно преобразовать в диск GPT и наоборот, но при этом необходимо удалить все разделы, что приведет к потере данных, если предварительно не была создана резервная копия. Обратите внимание, что эта операция отличается от преобразования базового диска в динамический. Разделы GPT не описываются в базе данных диспетчера логических дисков, пока диск не преобразован в динамический.
Формат GPT
На рис. 14.12 показаны принятые по умолчанию разделы загрузочного диска GPT. Ниже приведено описание каждого элемента.
EFI System Partition (ESP)
В разделе ESP хранятся файлы загрузчика для каждой операционной системы, установленной на диске. Файлы загрузчика операционной системы Windows Server 2003 для архитектуры IA64 называются Ia641dr.efi и Fpswa.efi. Расширение .efi означает выполняемый код для Extensible Firmware Interface. В файле Fpswa .efi содержится информация в формате чисел с плавающей запятой, которая используется операционной системой. В главе 3, “Добавление аппаратных средств”, приводится информация по установке и форматированию дисков GPT. Вот некоторые особенности раздела ESP.
Диск GPT
Для устаревшихприложенийпредоставляетсястандартная записьMBR, чтобы они неповредили таблицуразделов GPTДля устаревшихприложенийпредоставляетсястандартная записьMBR, чтобы они неповредили таблицуразделов GPTЗащитная запись MBRЗащитная запись MBRТаблица разделовТаблица разделовЗаголовок таблицы разделовЗаголовок таблицы разделовРазделОРаздел 1Раздел 2... 128РазделОРаздел 1Раздел 2... 128РазделОРазделОЗагрузочный секторЗагрузочный секторДанныеДанныеЗапись таблицы разделов ОРТЗапись таблицы разделов ОРТQUID разделаQUID разделаQUID разделаНачальный адресКонечный адресАтрибутыQUID разделаНачальный адресКонечный адресАтрибутыКопия таблицыразделов в концедиска для обеспеченияотказоустойчивостиКопия таблицыразделов в концедиска для обеспеченияотказоустойчивостиИмя разделаИмя раздела
Для устаревшихприложенийпредоставляетсястандартная записьMBR, чтобы они неповредили таблицуразделов GPT
Для устаревшихприложенийпредоставляетсястандартная записьMBR, чтобы они неповредили таблицуразделов GPT
Защитная запись MBR
Защитная запись MBR
Таблица разделов
Таблица разделов
Заголовок таблицы разделов
Заголовок таблицы разделов
РазделО
Раздел 1
Раздел 2... 128
РазделО
Раздел 1
Раздел 2... 128
РазделО
РазделО
Загрузочный сектор
Загрузочный сектор
Данные
Данные
Запись таблицы разделов ОРТ
Запись таблицы разделов ОРТ
QUID раздела
QUID раздела
QUID раздела
Начальный адрес
Конечный адрес
Атрибуты
QUID раздела
Начальный адрес
Конечный адрес
Атрибуты
Копия таблицыразделов в концедиска для обеспеченияотказоустойчивости
Копия таблицыразделов в концедиска для обеспеченияотказоустойчивости
Имя раздела
Имя раздела
Таблица разделовТаблица разделов
Таблица разделов
Таблица разделов
Заголовок таблицы разделов
РазделО
Раздел 1
Раздел 2... 128
Рис. 14.12. Схема структуры диска GPT,
Если раздел ESP создается средствами программы установки Windows Server 2003, для него выделяется 1 % дискового пространства объемом до 100 Мбайт. При добавлении дисков в аппаратный массив RAID этот процент не пересчитывается.
Раздел ESP не может входить в зеркалированный или составной том, не поддерживает увеличение размера и не может входить в состав тома с чередованием.
Раздел ESP должен быть первым разделом на диске, чтобы не мешать преобразованию диска в динамический. Диск GPT не поддерживает преобразование в динамический диск, если раздел ESP находится между разделами данных.
Производителям систем рекомендуется размещать свои диагностические утилиты и дополнительные файлы в собственном разделе, который называют разделом OEM (OEM partition), а не в разделе ESP. Компания Microsoft не является производителем систем, поэтому дисковые утилиты размещаются в каталоге Msut i 1 корневого каталога раздела ESP.
Для форматирования раздела ESP используется файловая система FAT. В отличие от других разделов, использующих файловую систему FAT, разделу ESP не назначается буква диска в операционной системе Windows и раздел не отображается на консоли Disk Management (Управление дисками). Для просмотра содержимого раздела ESP можно воспользоваться утилитой mountvol. Для этого необходимо выполнить команду mountvol <буква_диска> /s.'
Microsoft Reserved Partition (MSR)
Раздел MSR (Microsoft Reserved Partition — зарезервированный раздел Microsoft) выделен компанией Microsoft для хранения специальных структур. Например, в разделе MSR хранится база данных LDM. Другие производители операционных систем могут создавать собственные разделы. Рассмотрим основные особенности раздела MSR.
Как и раздел ESP, раздел MSR должен создаваться прежде разделов с данными, чтобы при необходимости диск можно было преобразовать в динамический. Если диск разбивается на разделы средствами программы установки операционной системы Windows Server 2003, раздел MSR будет расположен вторым в начале диска.
Размер раздела MSR составляет 32 Мбайт для дисков объемом меньше 16 Гбайт и 128 Мбайт для дисков объемом больше 16 Гбайт.
Раздел MSR не содержит распознаваемой файловой системы. В разделе хранятся структуры данных, понятные только системным службам Windows Server 2003.
Просмотр содержимого раздела MSR невозможен как для пользователей, так и для администраторов.
Разделы производителей
Производитель аппаратной платформы может создать раздел, в котором будут храниться диагностические приложения и приложения для настройки. Этот раздел напоминает решение компании Compaq использовать набор утилит Smart Start.
Производитель отвечает за генерацию глобально уникального идентификатора для раздела, а также за создание и форматирование собственного раздела на диске GPT до предоставления системы покупателю. Обычно пользователи и администраторы не могут просматривать содержимое раздела производителя. Раздел доступен только при использовании утилит, предоставленных производителем.
Разделы данных
Разделы этого типа могут использоваться для хранения пользовательских данных, которые включают в себя файлы операционной системы. Можно создать несколько разделов данных. Все разделы данных должны быть расположены по соседству, чтобы диск GPT можно было преобразовать в динамический диск.
Разделы данных для продуктов компании Microsoft могут быть отформатированы в операционной системе Windows Server 2003 с использованием любой из трех поддерживаемых файловых систем: FAT, FAT32 и NTFS.
Если в других разделах установлены другие операционные системы, операционная система Windows может не распознать файловые системы в этих разделах. Все разделы с поддерживаемыми файловыми системами получают буквы дисков.
Требования к дискам GPT
Следующие ограничения относятся к управлению дисками GPT.
Чтение дисков GPT поддерживается только операционной системой Windows Server 2003 для архитектуры IA64.
Диски GPT могут создаваться только на фиксированных жестких дисках. Для отключаемых дисков и приводов со сменными носителями необходимо использовать схему разделов MBR. Из-за этого загрузка компьютера Itanium с жесткого диска с интерфейсом FireWire не поддерживается (в отличие от компьютеров IA32).
Диски GPT не поддерживаются программами создания образа диска, так как создание образа приводит к клонированию глобально уникального идентификатора. Предоставленный компанией Microsoft OEM Preinstallation Kit (ОРК) поддерживает клонирование с помощью обнуления глобально уникальных идентификаторов при инициализации разделов во время первой загрузки компьютера.
На компьютерах IA64 поддерживаются загрузочные диски только в формате ОРТ. Остальные диски могут иметь формат как MBR, так и ОРТ.
Модернизация диска MBR до диска ОРТ не поддерживается. Необходимо удалить все разделы MBR и создать новую таблицу разделов ОРТ.
Работа с дисками GPT
Как и на компьютерах IA32, основным инструментом управления дисками ОРТ в операционной системе Windows Server 2003 является консоль Disk Management (Управление дисками). Консоль запрограммирована на создание разделов ОРТ на дисках ОРТ и разделов MBR на дисках MBR. Консоль Disk Management (Управление дисками) на компьютере IA32 не может использоваться для удаленного управления дисками ОРТ.
Если предпочтение отдается утилите с интерфейсом командной строки, можно воспользоваться утилитой Diskpart, которая предоставляется в составе операционной системы Windows Server 2003 для архитектуры IA64 и поддерживает чтение и модификацию конфигурации дисков GPT. Утилиту Diskpart можно использовать для создания разделов ESP и MSR на другом диске. Загрузившись в оболочку EFI Shell, можно воспользоваться ее возможностями по разбиению диска GPT на разделы. Пошаговые инструкции для этих операций приводятся в главе 3, “Добавление аппаратных средств”.
Значительным преимуществом дисков GPT по сравнению с дисками MBR является гибкость разбиения на разделы, которая обеспечивается таблицей разделов GPT. На базовом диске GPT поддерживается создание до 128 разделов. На рис. 14.13 показана консоль Disk Management (Управление дисками) отображающая информацию о базовом диске GPT с 40 разделами.
1
я
*-j*jaj^a^^
6Э(О:) М(Е:)
6а» (F:) St (G:) ® (1:) (^XRIPIFRE^N (Н:)
Л
Partition Partition Partition Partition Partition Partition Partition Partition
Bask Bask Bask Bask Bask Bask Bask
NTFS FAT FAT FAT
NTFS
COPS
Heathy ’
Heathy (P...
Heathy Heathy Heathy Heathy
Heathy (B...
Heathy
100 MB 5.86 GB 100 MB
100 MB
100 MB 2.93 GB 2.93 GB 51ЭМВ
100 MB
2.81 GB
100 MB
100 MB
100 MB
2.93 GB
100%
100% 100% 100% 100%
36%
No No No No No No No No
‘1 I i
XR1P1FREEN (H:)
'ф‘
Puc. 14.13. На консоли Disk Management (Управление дисками) для системы IA64 можно создать большое количество разделов на базовом диске
Если необходимы более сложные конфигурации с использованием чередования, RAID 5 или зеркалирования, базовый диск GPT нужно преобразовать в динамический диск. Таблица разделов GPT будет заменена базой данных LDM, которая хранится на разделе MSR. Служба диспетчера логических дисков работает в системе IA64 точно так, как в системе IA32. Допускаются те же отказоустойчивые конфигурации и те же процедуры используются для переноса дисков между компьютерами. Существует несколько ограничений службы диспетчера логических дисков, характерных для дисков GPT.
Все базовые разделы данных должны находиться рядом
Загрузочный диск GPT не может быть зеркалирован на диске MBR
Раздел ESP не поддерживает зеркалирование
В следующей главе
Теперь, когда настроена подсистема хранения, пришло время настраивать файловую систему. В следующей главе рассматриваются настройка трех файловых систем, поддерживаемых в операционной системе Windows Server 2003 (FAT, FAT32 и NTFS), а также управление ими. Затем будут рассмотрены системы безопасности стандартных файловых систем и шифрованная файловая система.
15
Управление файловыми системами
В
нескольких предыдущих главах рассматривалось разбиение дисков на разделы. Этот процесс напоминает покупку строительной компанией участков земли в южной части Мехико. Конечно, на купленном участке может быть прекрасный вид на старые пусковые установки ракет и на высохшие озера, но ни один покупатель не купит собственность в этом районе, если его не разбить на равные участки и не установить базовую инфраструктуру в виде водопровода, электросети, канализации и быстрого подключения к Интернет.
С точки зрения хранения данных разбиение и создание инфраструктуры обеспечиваются с помощью файловой системы. В операционной системе Windows Server 2003, как и в предыдущих версиях операционной системы, используются модульные драйверы IPS (Installable File System — устанавливаемая файловая система), которые позволяют получать доступ к данным в хранилище. Рассмотрим список поддерживаемых файловых систем и соответствующих драйверов.
Файловая система NT (NT File System), Ntfs.sys. Это основная файловая система компании Microsoft, которая используется во всех операционных системах Windows Server 2003 и Windows ХР.
Шифрованная файловая система (Encrypting File System), Bfs.sys. Этот драйвер находится выше драйвера файловой системы NTFS и обеспечивает выполнение операций по шифрованию/дешифровке данных.
FAT и FAT32, Fastfat. вув. Операционная система Windows Server 2003 поддерживает обе эти файловые системы.
CD-ROM, Cdfs.sys. Эта файловая система поддерживает диски формата ISO9660, в число которых входят CD-ROM, CD-R и CD-RW. Поддерживается чтение как стандартных дисков объемом 700 Мбайт, так и расширенных дисков объемом 850 Мбайт.
Universal Disk Format, Udfs.sys. Эта файловая система используется для поддержки приводов DVD. Файловая система поддерживает чтение дисков Universal Data Format (UDF) и дисков FAT32.
Драйвер служб удаленного хранилища (Remote Storage Services — RSS), Ref liter. вув. Эта файловая система предоставляет практически оперативный (online) доступ к файлам, хранящимся на магнитной ленте. Файловая система входит в иерархическую систему
управления хранилищем. Драйвер Rsfilter загружается только при установке служб удаленного хранилища.
File System Recognizer, Рв_гес. sys. Этот драйвер определяет файловую систему при доступе к диску или носителю.
Сетевые интерфейсы также реализованы в виде драйверов файловых систем IFS. Это касается служб LanMan Server, LanMan Workstation, Microsoft NetWare Client и файловых систем Mailslot (почтовый ящик) и Named Pipe (именованный конвейер), а также нового перенаправителя WebDAV (Web-based Distributed Authoring and Versioning). Эти службы рассматриваются в главе 19, “Управление операционной средой пользователя”.
В этой главе приводится подробное функциональное описание трех файловых систем, поддерживаемых в операционной системе Windows Server 2003: FAT16, FAT32 и NTFS. Кроме этого, рассматриваются новые возможности последней версии файловой системы NTFS. (Дополнительная информация о версиях файловой системы NTFS приводится во врезке “Версии NTFS”.)
В конце этой главы приводятся пошаговые инструкции для настройки следующих возможностей файловых систем и управления ими.
Преобразование файловых систем FAT/FAT32 в файловую систему NTFS
Сжатие
Точки функционального монтирования и точки монтирования
Распределенное отслеживание ссылок
Дефрагментация диска
Индексирование
Форматирование носителей CD-R/RW и DVD-RAM (новая возможность, появившаяся в операционных системах Windows Server 2003 и Windows ХР)
Справочные руководства IFS
Дополнительная информация о проектировании файловых систем предоставляется в книге Developing Windows NT Device Drivers Эдварда Деккера (Edward Dekker) и Джозефа НьюкЭ- мера (Joseph Newcomer).
Версии NTFS
На протяжении многих лет большинство авторов технической литературы, включая и автора этой книги, использовали в качестве номера версии файловой системы NTFS номер версии соответствующей операционной системы Windows NT. Такая терминология была продиктована удобством использования. Внутренний номер версии NTFS обычно интересовал только разработчиков.
С выходом операционной системы Window Server 2003 ситуация изменилась, так как компания Microsoft предоставила в составе операционной системы утилиту Fsutil, которая предоставляет доступ к большому объему информации о файловой системе, включая внутренний номер версии NTFS.
В этой главе используется внутренний номер версии NTFS, хотя это и может привести к путанице в еще более запутанной теме. Вот внутренние номера версий NTFS и их соответствие версиям Windows NT.
. Windows NT 3.x — NTFS 1.0
. Windows NT 4.0 — NTFS 1.2
. Windows 2000 —NTFS 3.0
Windows Server 2003/Windows XP — NTFS 3.1
Новые возможности операционной системы Windows Server 2003
В файловой системе NTFS версии 3.1 изменилось расположение таблицы MET (Master File Table — главная таблица файлов) и двух файлов с метаданными, а также изменена информация в заголовке записей файлов. Все эти изменения нацелены на повышение производительности.
При модернизации операционных систем Windows NT и Windows 2000 выполняется обновление всех существующих разделов NTFS до версии 3.1. Запрос на преобразование не выдается, и способа отключить преобразование не существует. Если на компьютер установлены две операционные системы, установите на операционную систему Windows NT 4.0 пакет обновлений Service Pack 6а, а на операционную систему Windows 2000 — Service Pack 1 или более позднюю версию. Если этого не сделать, при попытке загрузиться с помощью второй операционной системы может возникнуть критическая ошибка (синий экран).
В операционной системе Windows Server 2003 добавлены или модифицированы следующие возможности файловой системы.
Улучшенный механизм дефрагментации. Предоставляется утилита дефрагментации с интерфейсом командной строки, что позволяет выполнять дефрагментацию по расписанию. Новая утилита дефрагментации поддерживает дефрагментацию таблицы MFT, что значительно повышает производительность файловой системы.
Повышенная производительность. Система автоматически размещает критически важные системные файлы в стратегических местах диска. Кроме этого, периодически для повышения производительности перемещаются часто используемые файлы.
Улучшенное преобразование NTFS. Процедуры преобразования файловых систем FAT и FAT32 в файловую систему NTFS изменены с целью минимизировать фрагментацию и ускорить преобразование. Кроме этого, при преобразовании устанавливаются ограниченные права доступа к файлам, а не предоставляются права на полный доступ для группы Everyone. Это позволяет повысить безопасность преобразованных томов.
Предварительное чтение файлов. В операционных системах Windows Server 2003 и Windows ХР при запуске выполняемого файла запись о связанных с ним динамически загружаемых библиотеках заносится в файл с расширением .pf в каталоге \Windows\Prefetch. Кроме этого, система отслеживает периодичность выполнения файла. Каждые три дня система перемещает часто используемые файлы к началу диска. Кроме этого, выполняется дефрагментация файлов для ускорения чтения.
Сохранение коротких имен файлов. В предыдущих версиях операционной системы Windows при создании резервной копии или копировании файлов короткие имена файлов не попадали в резервную копию. При восстановлении из резервной копии файлы с короткими именами регенерировались. Это могло приводить к проблемам в работе приложений, которые ожидали обнаружить определенное короткое имя файла. В операционной системе Windows Server 2003 интерфейс резервного копирования позволяет копировать файл вместе с оригинальным коротким именем.
Поддержка записи компакт-дисков и дисков DVD. Компания Microsoft лицензировала эту технологию у компании Roxio (отделение компании Adaptec). Технология позволяет записывать компакт-диски и диски DVD. Это не полноценный механизм пакетной записи, который доступен в составе продуктов сторонних производителей, но он позволяет просто перетащить файлы на CD-R, CD-RW или DVD-RAM и начать запись.
Поддержка подсистемы Posix. После того как эта подсистема долгое время была в составе операционной системы Windows NT, компания Microsoft решила вывести ее из состава ядра операционной системы. Поддержка Posix предоставляется в виде платной надстройки
над операционной системой Windows Server 2003, которая называется Microsoft Interix. На момент создания этой книги Доступна версия 2.2 этого продукта.
Улучшенная поддержка WebDAV. В операционной системе Windows 2000 появилась возможность передачи файлов по сети с использованием протокола HTTP вместо протокола SMB. Это реализация развивающегося семейства технологий под общим названием WebDAV(Web-based Distributed Authoring and Versioning). В операционных системах Windows Server 2003 и Windows XP поддержка WebDAV значительно улучшена за счет предоставления выделенного перенаправителя. Кроме этого, информация о свойствах файла, которая используется WebDAV, теперь хранится в именованном потоке данных внутри записи файла NTFS.
Консоль File Server Management (Управление файловым сервером). В этой консоли, предоставляемой в поставке Windows Server 2003 R2, объединены функциональные возможности следующих утилит: Shared Folders, Disk Defragmenter и Disk Management. Фактически File Server Management является .единой консолью для управления файл-серверами.
Улучшенное управление ресурсами файловых серверов. В версию операционной системы Windows Server 2003 R2 добавлен новый диспетчер FSRM (File Server Resource Manager — диспетчер ресурсов файловых серверов). Этот подключаемый компонент ММС 3.0 предлагает средства создания квот и управления ими, позволяет блокировать сохранение пользователями определенных типов файлов, планировать и создавать отчеты по загрузке сервера файлов. Для создания квот доступны шесть шаблонов, а в дополнение к ним можно создавать и собственные.
Надежная система журналирования. В операционной системе Windows Server 2003 R2 предоставляется мощная система журналирования происходящих событий CLFS (Common Log File System). Эта система разработана для ситуаций, когда требуется непрерывное чтение и запись данных.,
Администраторам Windows NT может быть интересен список нововведений в файловой системе NTFS 3.0, которая предоставлялась в составе Windows 2000.
Улучшенные дескрипторы безопасности. Файлы и каталоги NTFS защищены дескрипторами безопасности, которые управляют доступом и определяют операции, которые можно выполнять над файлами. Начиная • с файловой системы NTFS 3.0, дескрипторы безопасности были перемещены из отдельных записей MFT в выделенную базу данных. Это позволяет увеличить производительность и упростить операции файловой системы для поддержки наследования разрешений..
Распределенное отслеживание ссылок. Расположение файлов, для которых созданы ярлыки или другие ссылки связывания и встраивания объектов (Object Linking and Embedding OLE), при перемещении отслеживается автоматически. Этот механизм работает как в пределах локальной системы, так и при перемещении файла на другой компьютер в пределах домена
Точки функционального монтирования (reparse point). Эти точки в литературе еще называют точками повторной обработки. Они позволяют монтировать локальные тома И- устройства как каталоги существующего тома независимо от их формата, например компакт-диски и диски DVD или даже приводы магнитной ленты. При открытии каталога с точкой функционального монтирования система открывает заданное этой точкой устройство или том.
Отслеживание квот. Позволяет ограничить общий объем дискового пространства тома, который пользователь может применять для хранения данных.
Журнал изменений. Предоставляет приложениям способ быстрого обнаружения модифицированных файлов. Эта возможность используется службой индексирования, службой репликации файлов и службой теневого копирования тома.
Шифрованная файловая система. Позволяет шифровать файлы, допуская чтение только владельцем и привилегированными администраторами. Дополнительную информацию по этому вопросу можно получить в главе 17, “Управление шифрованием файлов”.
Разреженные файлы (sparse file). Эта возможность позволяет приложениям использовать большие файлы, хотя при этом файлом в действительности не используется весь объем выделенного дискового пространства.
Индексация. Эта возможность позволяет создать каталог файлов для ускорения поиска слов и фраз. Каталог доступен как сетевым клиентам, так и локальным пользователям.
Также пользователи файловых систем FAT и FAT32 могут обратить внимание на следующие возможности файловой системы NTFS, которые доступны уже достаточно давно.
Генерация коротких имен файлов. Для обратной совместимости с клиентами и приложениями DOS файловая система автоматически генерирует короткие имена файлов (в формате 8.3), если файл или папка имеет длинное имя. Алгоритм генерации короткого имени отличается от алгоритма, принятого в операционной системе Windows 98.
Сжатие. 'В файловой системе NTFS поддерживается выборочное сжатие отдельных файлов и каталогов. Распаковка сжатых файлов выполняется оперативно, во время доступа.
Именованные потоки данных. Файл NTFS может содержать более одного дискретного набора данных в одной записи файла. Стандартные “данные” хранятся в неименованном потоке данных. Дополнительные потоки идентифицируются по имени. Эта возможность используется для многих компонентов операционной системы Windows Server 2003.
Журналирование. Файловая система NTFS защищает критические системные файлы, сохраняя изменения в файле журнала перед внесением изменений в записи файловой системы.
Обзор файловых систем
Windows Server 2003
Файловая система напоминает риэлтора. Она выступает в качестве посредника между арендодателем, у которого есть свободная площадь, и арендатором, который хочет нанять эту площадь. В случае файловой системы подсистема хранения определяет доступное пространство, а приложения выступают в роли арендаторов, которые хотят получить часть дискового пространства.
Администраторы должны знать о составляющих процесса транзакций файловой системы, чтобы определять требования к подсистеме хранения и прогнозировать возможные проблемы. Это значит, что необходимо иметь представление о структурах диска, которые поддерживают операции файловой системы.
Секторы. Используются для базового разделения данных на диске. Расположение сектора определяется геометрией диска и фиксировано производителем. Диски для рынка США обычно имеют секторы размером 512 байт.
Кластеры. Файловая система использует кластеры для адресации. Кластер представляет собой группу секторов. Группирование секторов в кластеры позволяет файловой системе сократить адресное пространство.
Разделы и тома. Дисковое пространство делится на разделы, в каждом из которых может использоваться отдельная файловая система. В системах IA32 для описания разделов базового диска используется запись Master Boot Record (MBR). На компьютерах IA64 для
базовых дисков могут использоваться схемы GUID Partition Tables (GPT) или Master Boot Record (MBR). Динамические диски на любой из архитектур обрабатываются диспетчером логических дисков (Logical Disk Manager — LDM). Для деления динамических дисков на тома диспетчер логических дисков использует специальную базу данных. С точки зрения файловой системы разделы и тома выглядят одинаково: как место для хранения файлов.
Загрузочный сектор раздела. Это первый сектор раздела. В этом секторе хранятся информация о файловой системе и небольшой код загрузчика, который начинает загрузку операционной системы.
Чтобы понять, как файловая система превращает дисковое пространство в хранилище данных, необходимо ознакомиться со структурами, которые используются для хранения критической информации. Рассмотрим эти структуры.
Файлы. Адресуемые позиции на диске, в которых хранятся отдельные фрагменты пользовательских данных. Файл имеет имя и атрибуты, которые обозначают его содержимое.
Папки. Папка представляет собой список имен файлов. Папки позволяют структурировать файловую систему с помощью иерархической системы, что упрощает поиск отдельных файлов.
File Allocation Table (FAT). Это карта кластеров (cluster шар) раздела, который отформатирован с использованием файловой системы FAT или FAT32. Файловая система использует карту кластеров для поиска файлов и папок.
Master File Table (MET). База данных, в которой хранится информация об элементах файловой системы NTFS, использованной для форматирования раздела.
Записи метаданных MFT. Специальные записи NTFS, в которых хранится информация о структуре таблицы MFT. Записи метаданных используются для поддержки критических операций файловой системы.
С практической точки зрения необходимо знать, что может и чего не может делать каждая файловая система и какие критерии использовать при выборе файловой системы. Начнем с подробного рассмотрения методов хранения. (Обратите внимание на врезку “Дополнительная информация о файловых системах”.)
Секторы и кластеры
Данные на жестком диске хранятся на концентрических дорожках, которые разделены на поддерживающие адресацию фрагменты — секторы (sectors) (рис. 15.1). В большинстве жестких дисков для продаж в США используется сектор размером 512 байт.
Запрашивая данные ра диске, файловая система должна предоставить сведения о расположении интересующих данных относительно начала тома. После этого драйвер подсистемы хранения совместно с контроллером устройства перемещает головки в нужное положение, считывает интересующую информацию (и немного дополнительной информации для кэширования), помещает информацию в буфер и передает ее файловой системе.
^^<MtfOtf^^^^<MtfOtf^^Сектор является минимальной адресуемой единицей диска. В идеальном случае файловая система назначала бы адрес каждому сектору диска. Такая схема позволила бы наиболее эффективно использовать дисковое пространство, так как пространство между концом файла и концом последнего сектора оказывается потерянным.
^^<MtfOtf^^
^^<MtfOtf^^
На определенном этапе в томе может стать так много секторов, что непроизводительные операции по поддержке адресного пространства могут привести к снижению производительности. Для увеличения производительности файловая система группирует отдельные секторы в единицы выделения памяти (allocation units) или кластеры (clusters).
1
Дополнительная информация о файловых системах
В книге Inside Windows 2000 Server всю исследовательскую работу относительно файловых систем выполнил автор этой книги. Это потребовало многих часов изучения шестнадцатеричного дампа дисковых структур, так как компания Microsoft отказывалась публиковать спецификации файловой системы NTFS. Часть информации просочилась из Редмонда в виде рекомендаций и статей в составе Resource Kit, но конкретные технические подробности были недоступны.
Для написания этой книги была частично использована работа, проведенная сообществом поддержки открытого кода (Open Source), в частности участников проекта "Linux-NTFS". Тем, кому интересно ознакомиться с деталями структур данных файловой системы NTFS и получить информацию о других работах в области межплатформенного управления подсистемами хранения, рекомендую посетить сайт linux-htfs.sourceforge.net.
Еще одним источником информации о дисковых структурах файловой системы NTFS стала книга Windows NT/2000 Native AR! Reference Гарри Ниббита (Gary Nebbett). Это хороший справочник, который может пригодиться всем, кого интересует работа внутренних механизмов Windows.
Подробная информация о дисковых структурах файловых систем FAT и FAT32 доступна в документе от компании Microsoft, который называется "FAT: General Overview of On-Disk Structure" и хранится по адресу www.nondot.org/sabre/os/files/FileSystems. На этом сайте хранится достаточно большой объем информации практически обо всех файловых системах.
Авторитетное высокоуровневое описание файловой системы NTFS доступно в книге Inside Windows 2000Дэвида Соломона (David Solomon) и Марка Русиновича (Mark Russinovich). Кроме этого, обратите внимание на статьи Марка Русиновича о файловой системе NTFS в журнале Windows 2000 Magazine и других периодических изданиях.
Неплохое описание файловых систем в Windows Server 2003 предоставляется в составе Resource Kit. Когда-нибудь компания Microsoft может разрешить создателям Resource Kit включить в его состав технические спецификации.
Кластер содержит четное количество секторов. Это размер кластера (cluster size). Размер кластера может равняться только числу, являющемуся степенью двойки, что приводит к получению
размеров кластера 512 байт, 1 Кбайт, 2 Кбайт, 4 Кбайт, 16 Кбайт, 32 Кбайт и 64 Кбайт. Все файловые системы в Windows Server 2003 поддерживают максимальный размер кластера (64 Кбайт).
Если файл не занимает полностью выделенный ему кластер, лишнее дисковое пространство оказывается неиспользуемым. Операционная система Windows не поддерживает выделение отдельных секторов внутри кластера. Это значит, что размер кластера непосредственно влияет на полезное использование дискового пространства. Например, в практике автора этой книги бывали случаи, когда около 25 % дискового пространства в томе становилось доступным после преобразования файловой системы FAT с размером кластера 32 Кбайт в файловую систему NTFS с размером кластера 512 байт.
Иногда полезно, чтобы размер кластера совпадал со средним размером файла. Если в томе хранится большое количество небольших файлов, необходимо использовать небольшой размер кластера. Это кажется очевидным. Но том с небольшим количеством больших файлов может получить дополнительные преимущества за счет эффективного управления кластерами большого размера. В большинстве случаев автоматическое определение размера кластера при форматировании средствами операционной системы Windows позволяет добиться оптимальной производительности.
Изменение размера кластера требует повторного форматирования. Если принято решение об увеличении размера кластера на большом массиве сервера базы данных, придется создать резервную копию данных, отформатировать массив с другим размером кластера и восстановить данные с магнитной ленты.
Каждая из трех файловых систем, поддерживаемых в операционной системе Windows Server 2003, использует кластеры размером 512 байт, пока размер тома не превышает определенного значения. После превышения этого значения поведение файловых систем отличается. В файловой системе FAT размер кластера удваивается при двукратном увеличении размера тома. В файловых системах FAT32 и NTFS размер кластера 4 Кбайт сохраняется как можно дольше. В табл. 15.1 перечислены принятые по умолчанию размеры кластеров в зависимости от размера тома для каждой файловой системы.
Предельный размер кластера NTFS 4 Кбайт связан с тем, что интерфейс сжатия не поддерживает кластеры размером больше 4 Кбайт. Файловая система FAT32 рассматривается как промежуточный этап перед переходом к файловой системе NTFS, поэтому размеры кластеров FAT32 также удерживаются на уровне 4 Кбайт как можно дольше.
Таблица 15.1. Зависимость размера кластеров от файловой системы и размера тома
Размер тома
FAT
FAT32
NTFS
До 32 Мбайт
512 байт
Нет данных
512 байт
До 64 Мбайт
1 Кбайт
512 байт
512 байт
До 128 Мбайт
2 Кбайт
1 Кбайт
512 байт
До 256 Мбайт
4 Кбайт
■2 Кбайт
512 байт
До 512 Мбайт
8 Кбайт
4 Кбайт
512 байт
До 1 Гбайт
16 Кбайт
4 Кбайт
1 Кбайт
До 2 Гбайт
32 Кбайт
4 Кбайт
2 Кбайт
До 4 Гбайт
64 Кбайт
4 Кбайт
4 Кбайт
До 8 Гбайт
Недоступно
4 Кбайт
4 Кбайт
До 16 Гбайт
Недоступно
8 Кбайт
4 Кбайт
До 32 Гбайт
Недоступно
16 Кбайт
4 Кбайт.
Более 32 Гбайт
Недоступно
Недоступно
4 Кбайт
Размер кластера и размер фрагмента чередования
Размеры кластеров не связаны с буферами данных, которые используются диспетчером логических дисков. Часто размер буфера данных в аппаратных массивах RAID называется размером полосы (stripe size). Диспетчер логических дисков всегда перемещает данные между контроллером и диском блоками по 64 Кбайт, не учитывая размер кластера.
Исторически так сложилось, что интерфейс дефрагментации стал еще одной причиной ограничения максимального размера кластера NTFS на уровне 4 Кбайт. Как будет показано в разделе “Дефрагментация”, в операционных системах Windows Server 2003 и Windows ХР поддерживается дефрагментация томов, которые имеют размер кластера не менее 4 Кбайт.
Структура файловой системы FAT
На рис. 15.2 показана структура первых нескольких секторов диска, отформатированного с помощью файловой системы FAT. В загрузочном секторе раздела содержится запись, которая идентифицирует тип файловой системы и расположение основной и резервной копий таблицы размещения файлов (File Allocation Table — FAT). Обычно таблица FAT расположена в начале диска, где обеспечивается большая скорость чтения. (Дорожки на внешней стороне диска имеют большую линейную скорость.)
Рис. 15.2. Структура файловой системы FAT
Драйвер Fast fat. sys в операционной системе Windows Server 2003 поддерживает три схемы нумерации кластеров.
FAT12. В этом формате для идентификации кластера используется 12 бит. Этот формат использовался в файловой системе FAT с самого начала. Это достаточно компактная форма записи, поэтому она используется для форматирования гибких дисков и томов размером до 16 Мбайт.
FAT16. В этом формате для нумерации кластеров используется 16 бит, что обеспечивает максимальный размер тома 216 (OxFFFF), или 65 535 кластеров. (Размер тома на один кластер меньше теоретически возможного значения 65 536.) В операционной системе Windows Server 2003 поддерживается максимальный размер кластера FAT16, равный 64 Кбайт, что обеспечивает поддержку максимального размера раздела FAT, равного 65 535 х 64 Кбайт, или 4 Гбайт. (В операционных системах Windows 9х и DOS поддерживается максимальный размер кластера (32 Кбайт); в результате допустимый размер тома составляет 2 Гбайт.)
FAT32. В этом формате для нумерации кластеров используется длинное целое число (32 бит). Это должно обеспечивать очень большой размер тома, но операционная система Windows Server 2003 ограничивает размер тома FAT32 на уровне 32 Гбайт. Стандартная версия операционной системы Windows 95 и операционные системы Windows NT не поддерживают чтение разделов FAT32.
Существует специальная версия файловой системы FAT32, которая называется FAT32x и используется в операционных системах Windows 9х и Windows ME для форматирования дисков размером более 8 Гбайт. В файловой системе FAT32x преодолевается ограничение традиционной трансляции формата цилиндр/головка/сектор. Это достигается за счет использования операционной системой адресации LBA (Logical Block Addressing — логическая адресация блоков), которая назначает номер каждому доступному сектору на диске. Схема адресации LBA увеличивает допустимый максимальный размер раздела до максимального теоретического значения, поддерживаемого файловой системой. Для файловой системы FAT32 это значение составляет 2 Тбайт (терабайт).
В томах FAT32x таблица FAT хранится в конце диска, а не в начале. Это заставляет операционную систему использовать адресацию LBA. Операционная система Windows Server 2003 поддерживает чтение томов FAT32x, но не использует такое форматирование, поскольку драйвер Fast fat. sys всегда использует адресацию LBA, если не указано обратное. При модернизации Windows 9x/Windows ME до Windows ХР ни в одной из утилит с интерфейсом командной строки или на консоли Disk Management (Управление дисками) не указывается, что используется файловая система FAT32x, а не FAT32. Более подробную информацию по этому вопросу можно получить по адресу www. win98pr ivate. net / f at 32x, htm.
Расположение и использование дисковых структур FAT
В файловых системах FAT12 и FAT16 таблица расположения файлов должна начинаться с первого доступного сектора после загрузочного сектора раздела. В разделах MBR часто существуют скрытые секторы между загрузочным сектором раздела и началом файловой системы. Назначение таких скрытых секторов часто остается непостижимым. На дисках GPT в компьютерах IA64 они не используются.
Зеркальная копия таблицы размещения файлов (FAT) находится непосредственно после основной копии таблицы размещения файлов. Фиксированное расположение таблиц FAT является слабым местом файловых систем FAT12 и FAT16. Отказ сектора может привести к недоступности всей файловой системы. Этот недостаток был устранен в файловой системе FAT32, в которой таблица размещения файлов может храниться в любом месте файловой системы, хотя обычно она все-таки хранится сразу после загрузочного сектора.
Первая запись в таблице размещения файлов соответствует корневому каталогу раздела. Корневой каталог имеет особое значение, так как его длина — ровно 32 сектора, чего достаточно для хранения 512 элементов. По этой причине в корневом каталоге файловой системы FAT может храниться не более 500 файлов и каталогов. Как известно, в файловых системах
FAT и FAT32 длинные имена файлов поддерживаются за счет пространства, выделенного для хранения записей каталогов. Использование длинных имен в корневом каталоге может значительно сократить общее количество файлов и каталогов, которые можно хранить в корневом каталоге.
Размер таблицы FAT определяется количеством кластеров раздела. Чем больше раздел, тем больше записей должно быть в таблице размещения файлов. Например, раздел FAT размером 2 Гбайт с размером кластера 32 Кбайт потребует 128 Кбайт для хранения таблицы размещения файлов. Еще 128 Кбайт потребуется для хранения копии таблицы размещения файлов. По сравнению с файловыми системами FAT32 и NTFS это достаточно эффективное использование дискового пространства, но такая эффективность имеет свою цену: снижение надежности, снижение производительности для некоторых дисковых операций, снижение производительности даже при минимальной фрагментации, а также недостаточные возможности для обеспечения безопасности и заполнения журналов.
Карты кластеров
Позиции кластеров в таблице размещения файлов(FAT)Позиции кластеров в таблице размещения файлов(FAT)00010203040506070001020304050607Пустые кластеры в позициях 2 и 3Пустые кластеры в позициях 2 и 3Один заполненный кластер в позиции 4 — возможно, каталогОдин заполненный кластер в позиции 4 — возможно, каталогФайл начинается с позиции 5 и продолжается в позиции 6Файл начинается с позиции 5 и продолжается в позиции 6Файл заканчиваетсяв позиции 7Файл заканчиваетсяв позиции 7Таблица FAT является большой картой кластеров (cluster map), в которой каждый кластер раздела представлен записью размером 16 бит (2 байт). Если том содержит 65 535 клас- теров, в таблице размещения файлов будет 65 535 записей размером 2 байт каждая. (В файловой системе FAT12 используется упаковка битов для экономии дискового пространства.) На рис. 15.3 показана схема нескольких записей кластеров в таблице размещения файлов для файловой системы FAT 16.
Позиции кластеров в таблице размещения файлов(FAT)
Позиции кластеров в таблице размещения файлов(FAT)
0001020304050607
0001020304050607
Пустые кластеры в позициях 2 и 3
Пустые кластеры в позициях 2 и 3
Один заполненный кластер в позиции 4 — возможно, каталог
Один заполненный кластер в позиции 4 — возможно, каталог
Файл начинается с позиции 5 и продолжается в позиции 6
Файл начинается с позиции 5 и продолжается в позиции 6
Файл заканчиваетсяв позиции 7
Файл заканчиваетсяв позиции 7
Первая запись зарезервирована для корневого каталога (позиция 1)
Рис. 15.3. Типичная карта кластеров FAT для файловой системы FAT16
Первые две записи таблицы размещения файлов зарезервированы и соответствуют корню раздела. Следующая запись соответствует первому файлу или папке, созданной в разделе. На схеме этот кластер пуст, так как оригинальный файл (или папка) был удален.
Пустой кластер описывается значением 0000. При создании файла или папки файловая система выбирает пустой кластер и записывает данные на диск в указанном расположении. Если файл или папка не помещается в один кластер и записывается в еще один, в записи кластер» в таблице размещения файлов указывается номер следующего кластера. Этот так называемая цепочка кластеров (cluster chain). Последний кластер файла идентифицируется по специальному значению FFFF.
В идеальном случае каждый следующий кластер файла находится на диске сразу за предыдущим. Такой файл называется непрерывным (contiguous). При удалении файла или папки запись в таблице размещения файлов устанавливается равной значению 0000. Это означает, что кластер свободен. При добавлении и удалении файлов файловая система повторно ис-
пользует освободившиеся кластеры. В результате повторного использования возникает ситуация, известная под названием фрагментация (fragmentation).
На рис. 15.4 показан фрагмент таблицы размещения файлов для фрагментированного файла. На карте кластеров показан файл, который начинается с позиции 8. Файл слишком велик, чтобы уместиться в один кластер, а следующий кластер занят другим файлом. Драйвер файловой системы выбирает следующий доступный пустой кластер и продолжает запись файла. Помните, что номер в записи таблицы размещения файлов указывает на следующий кластер в цепочке, а не на текущий кластер.
0809 ОА0809 ОА0D DE 0F0D DE 0F
0809 ОА
0809 ОА
0D DE 0F
0D DE 0F
Рис. 15.4. Карта кластеров для фрагментированного файла
При доставке файла диспетчеру ввода-вывода из подсистемы Windows Server 2003 Executable средствами драйвера Fast fat драйвер должен пройти по цепочке записей таблицы размещения файлов и найти все номера кластеров, соответствующие файлу. Головка диска должна переместиться по диску, поместить данные в буфер, отсортировать и передать результаты на более высокий уровень. Если файлы и папки значительно фрагментированы, сбор данных из отдельных кластеров занимает у дисковой подсистемы значительно больше времени. Это приводит к снижению производительности.
Как будет описано далее, в составе операционных систем Windows Server 2003 и Win- tiows 2000 предоставляются утилиты дефрагментации, которые позволяют собрать воедино кластеры файлов. В составе операционных систем Windows Server 2003 и Windows ХР предоставляется одна и та же утилита дефрагментации. В операционной системе Windows Server 2003 поддерживается дефрагментация по расписанию. Для выполнения дефрагментации по расписанию в операционной системе Windows 2000 требовались утилиты от сторонних производителей.
Каталоги FAT
Файловая система не может найти файл по имени только на основе карты кластеров в таблице размещения файлов. Для поиска определенного файла по имени требуется индекс, в котором указано соответствие между именем файла и номером первого кластера, указанного в таблице размещения файлов. Такой индекс называется каталогом или папкой.
Кроме имен файлов, запись каталога FAT содержит один байт, определяющий атрибуты файла (только для чтения, скрытый, системный и архивный), и метку времени (timestamp), в которой указано время создания файла. Записи каталогов хранятся в дисковых кластерах, как обычные файлы. На рис. 15.5 изображена схема дисковых кластеров, содержащих набор записей каталога.
Запись каталога может быть фрагментирована, если количество записей превышает объем кластера. Это еще одна причина использования кластеров большого размера в больших томах FAT.
Если при добавлении нескольких файлов каталог не может занять соседний кластер, каталог становится фрагментированным. Это приводит к значительному снижению производи-
телвности. Представьте, какой объем работы выполняется файловой системой для сборки фрагментированных каталогов и связанных с ними файлов для просмотра результатов в окне Explorer (Проводник).
Кластер каталогаКластер каталогаУказывает на себяУказывает на себяУказывает на родителяУказывает на родителяфрагментированный каталог. Продолжение имени файла хранится в другом секторефрагментированный каталог. Продолжение имени файла хранится в другом сектореПомечен как удаленный (первая буква заменена шестнадцатеричным значением Е5)Помечен как удаленный (первая буква заменена шестнадцатеричным значением Е5)Имя каталога Кластер OFИмя каталога Кластер OFИмя файла Кластер 10Имя файла Кластер 10Рис. 15.5. Дисковые кластеры с фрагментированными записями каталогаРис. 15.5. Дисковые кластеры с фрагментированными записями каталога
Кластер каталога
Кластер каталога
Указывает на себя
Указывает на себя
Указывает на родителя
Указывает на родителя
фрагментированный каталог. Продолжение имени файла хранится в другом секторе
фрагментированный каталог. Продолжение имени файла хранится в другом секторе
Помечен как удаленный (первая буква заменена шестнадцатеричным значением Е5)
Помечен как удаленный (первая буква заменена шестнадцатеричным значением Е5)
Имя каталога Кластер OF
Имя каталога Кластер OF
Имя файла Кластер 10
Имя файла Кластер 10
Рис. 15.5. Дисковые кластеры с фрагментированными записями каталога
Рис. 15.5. Дисковые кластеры с фрагментированными записями каталога
Разделы FAT и размер файлов '
Из-за ограничений реального режима процессора размер кластера для разделов FAT в операционной системе DOS и Windows 9х должен быть не больше половины предела адресации. Таким образом, максимальный размер кластера составляет 215 байт, или 32 Кбайт. Максимальный размер раздела FAT в операционных системах DOS и Windows 95 составляет 65 535 х 32 Кбайт, или около 2 Гбайт.
Файловая система FAT в операционной системе Windows Server 2003 (которая переключается в защищенный режим до загрузки драйвера Fast fat) поддерживает размер кластера 216 байт, или 64 Кбайт.
Файловая система FAT поддерживает до 216 кластеров в томе, но 12 кластеров резервируются для специальных целей, что оставляет для хранения файлов и папок 65 534 кластера. Практически невозможно создать том максимального поддерживаемого объема из-за выравнивания тома по границе цилиндра. Не стоит тратить усилия и время, чтобы получить несколько кластеров максимально (теоретически) возможного объема.
В операционной системе Windows Server 2003 (и других операционных системах семейства WindowsNT) поддерживается максимальный размер раздела FAT, равный 4 Гбайт (65 534 кластера по 64 Кбайт). Операционные системы DOS и Windows 9х не поддерживают доступ к разделам с размером кластера больше 32 Кбайт, поэтому избегайте использования кластеров размером 64 Кбайт на компьютерах с Двумя операционными системами.
Размер файла FAT указывается в записи каталога. Для хранения этого значения используется 32-разрядное слово, поэтому размер файла ограничен значением 232 байт, или 4 Гбайт.
Фактический максимальный размер на 1 байт меньше и составляет 4 294 967 295 байт, так как 32-разрядное слово, заполненное единицами, будет иметь значение OxFFFFFFFF.
Это можно проверить экспериментальным путем с помощью утилиты Fsutil из состава Support Tools. Утилита позволяет создавать файлы любой длины с точностью до байта. В процессе эксперимента создайте раздел FAT32, размер которого превышает 4 Гбайт. В корневом каталоге раздела введите следующую команду:
fsutil file createnew 4294967296
Будет выдано сообщение об ошибке, связанное с недостатком дискового пространства. Уменьшите размер файла на единицу, и файл будет создан без ошибок.
Файловая система FAT32
Файловая система FAT32 была создана для устранения некоторых вопиющих недостатков файловой системы FAT. Самым значительным отличием является карта кластеров FAT32, в которой для идентификации кластеров используются 32-разрядные слова вместо 16-разрядных. Это позволяет значительно увеличить количество адресуемых кластеров. Первые 4 разряда 32-разрядного адреса кластера зарезервированы, поэтому максимальное количество кластеров составляет 228. Вместе с максимальным размером кластера в операционной системе Windows Server 2003, составляющим 64 Кбайт, это позволяет получить теоретический размер тома 4 Эбайт.
Вернемся к реальности. Размер раздела диска MBR определяется значением Volume Size в таблице разделов. Это значение описывает количество секторов, предоставленных разделу, и не учитывает файловую систему, которая использовалась для форматирования раздела. Значение Volume Size является 32-разрядным словом, поэтому максимальный размер раздела на диске MBR составляет 232 сектора или 2 Тбайт.
При использовании динамических дисков с архитектурой IA32 или дисков GPT архитектуры IA64 можно обойти это ограничение. В таком случае том может достигать теоретического размера. Но операционная система Windows Server 2003 отказывается форматировать том FAT32 размером больше 32 Гбайт.
Том FAT32 можно отформатировать под управлением операционной системы Windows 98 или Windows Me, которые не ограничивают том размером 32 Гбайт, и добавить отформатированный том в компьютер под управлением Windows Server 2003. Драйвер Fast fat сможет читать и записывать данные в этот том. Максимальный практический предел для тома FAT32 в операционных системах Windows 98 и Windows ME составляет 2 Тбайт. Это связано с записью Vo 1 ume S i z е в загрузочном секторе.
Размер таблицы FAT и эффективность работы диска
Таблица размещения файлов файловой системы FAT32 занимает значительно больше места. Размер таблицы размещения файлов FAT32 примерно вдвое превышает размер такой таблицы в файловой системе FAT16, поскольку для хранения каждой записи требуется четыре байта вместо двух. Поскольку цепочки кластеров часто повреждаются и утрачиваются, большие структуры FAT32 требуют большего объема обслуживания. В большинстве случаев файловая система NTFS предоставляет сопоставимый уровень производительности и намного большую надежность. Если ваше знакомство с файловой системой NTFS происходило в старых операционных системах, оцените значительный прирост производительности в файловой системе NTFS версии 3.1.
Недостатки файловых систем FAT и FAT32
Файловые системы FAT и FAT32 напоминают водевиль. Все хорошо и интересно, но пользы маловато. Рассмотрим основные недостатки этих файловых систем, которые были устранены в файловой системе NTFS.
В файловых системах FAT12 и FAT16 расположение таблицы размещения файлов жестко определено. Если отказывает сектор с фрагментом таблицы размещения файлов, система использует копию таблицы FAT. Если отказывают обе копии таблицы, расположенные рядом, файловая система становится недоступной для монтирования. В файловой системе FAT32 за счет отказа от фиксированного расположения таблицы размещения файлов этот недостаток удалось устранить.
Файловая система FAT поддерживает не более 512 файлов в корневом каталоге раздела. Файловая система FAT32 поддерживает до 65 534 файлов в корневом каталоге. И в FAT, и в FAT32 длинные имена файлов поддерживаются за счет записей каталогов, поэтому при использовании длинных имен файлов допустимое количество файлов в корневом каталоге значительно сокращается.
Ограниченное адресное пространство файловой системы FAT16 приводит к нерациональному использованию дискового пространства из-за использования кластеров большого размера. В файловой системе FAT32 поддерживается большее количество кластеров, но не настолько большое, как в файловой системе NTFS.
Цепочка записей в таблице размещения файлов для файла или каталога может разорваться или повредиться. Кроме этого, файловая система FAT подвержена значительной фрагментации. Это справедливо и для файловой системы FAT32. Файловая система NTFS значительно лучше справляется с фрагментацией, поэтому снижение производительности незначительно.
При случайном поиске файлов и работе с большими файлами драйвер Fast fat не настолько эффективен, как драйвер NTFS.
Файловые системы FAT и FAT32 не обеспечивают безопасности. Любой пользователь, получивший доступ к компьютеру, может получить доступ к любому файлу.
Механизмы сжатия, которые использовались для разделов FAT и FAT32 в операционной системе Windows 9х, были неуклюжими и являлись частой причиной звонков в службу поддержки. Тома DriveSpace не поддерживаются в операционной системе Windows Server 2003. Если необходимо использовать сжатие для экономии дискового пространства в операционных системах Windows Server 2003 и Windows ХР, придется переходить к фай- ( ловой системе NTFS.
Адресация и размер кластеров в файловой системе NTFS
В файловой системе NTFS для нумерации кластеров используется 64-разрядное слово, но в реализациях файловой системы NTFS для адресации используются первые 32 разряда. При максимальном размере кластер» 64 Кбайт такое количество разрядов для нумерации позволяет создавать разделы размером 256 Эбайт. Для дисков MBR максимальный размер раздела остается равным 2 Тбайт даже при использовании файловой системы NTFS. Это связано с максимальным значением размера раздела в таблице разделов. Чтобы преодолеть это ограничение, необходимо использовать динамические диски или диски GPT на компьютерах с архитектурой IA64.
Максимальный принятый по умолчанию размер кластера NTFS составляет 4 Кбайт, но если сжатие не требуется, при форматировании раздела можно указать больший размер кластера.
Максимальный размер файла в файловой системе NTFS искусственно ограничен на уровне 2м байт, хотя теоретический максимум составляет 2“ байт или около 16 Тбайт. Во время разработки файловой системы NTFS этот размер считался невероятно большим, но если экстраполировать рост современных решений в области хранения, то через некоторое время
дорогостоящие серверы на основе платформы Intel начнут перешагивать предел в 16 Тбайт. Компания Microsoft не озвучивала свою стратегию в отйошении таких файлов, но ходят слухи, что следующая после Windows Server 2003 операционная система будет использовать файловую систему, способную работать с файлами гигантского размера.
Структура NTFS
В отличие от карт кластеров, которые использовались для поиска файлов в файловых системах FAT и FAT32, в файловой системе NTFS для этих целей используется настоящая база данных, которая называется главная таблица файлов (Master File Table — MFT).
Таблица MFT состоит из набора записей фиксированной длины размером 1 Кбайт. Каждая запись содержит набор атрибутов, которые в комбинации идентифицируют расположение и содержимое соответствующего файла, папки или компонента файловой системы. (Существует несколько незначительных исключений из правила “одна запись — один файл”, но они возникают только при использовании очень больших или очень фрагментированных файлов.)
Существует три класса записей MFT.
Записи файлов. В этих записях хранится информация, воспринимаемая как “данные”, например файлы приложений, файлы драйверов, системные файлы, файлы баз данных и т.д.
Записи каталогов. В этих записях хранятся и индексируются имена файлов. Кроме этого, записи каталогов используются для индексации других атрибутов, например точек функционального монтирования, дескрипторов безопасности и информации для отслеживания ссылок.
Записи метаданных. С помощью этих записей контролируются структура и содержимое самой таблицы MFT. Некоторые из этих записей имеют структуру записей файлов. В других записях используется структура записей каталогов. Есть записи, которые имеют уникальный набор атрибутов и уникальную структуру.
Рассмотрим структуру каждой записи, чтобы понять принципы работы файловой системы.
Записи метаданных
На рис. 15.6 показана иерархия записей метаданных, если представить их в виде каталогов и файлов. Имена записей начинаются с символа $.
Записи метаданных недоступны через пользовательский интерфейс или из командной строки. Утилита chkdsk позволяет обнаружить дисковое пространство, выделенное для хранения этих записей. Ниже показан пример отчета этой утилиты (выделенные полужирным шрифтом строки описывают дисковое пространство для хранения записей метаданных): 635008 kilobytes total disk space.
535691 kilobytes in 8206 user files.
1894 kilobytes in 592 indexes.
14176 kilobytes in use by the system.
7647 kilobytes in use by the log file.
83247 kilobytes available o.n disk.
Несложно заметить, что файловая система NTFS может занять значительную долю дискового пространства небольшого тома. Но если размер тома превышает 10 Гбайт, процент дискового пространства, выделенный для файловой системы NTFS, будет меньше, чем при использовании файловой системы FAT32 с сопоставимым размером кластера.
Порядок и структура записей метаданных тщательно контролируются, так как их расположение влияет на производительность и функциональность. Например, в таблице MFT содержатся записи, описывающие загрузочный сектор раздела. Вторичный загрузчик Ntldr
загружает несколько первых записей метаданных и использует эту информацию для поиска и чтения загрузочного диска, что позволяет смонтировать оставшуюся часть файловой системы.
$МП
SMftMirrSMftMirr$Logfile$LogfileSVolumeSVolume$AttrDef$AttrDefSBitmapSBitmap$Boot$BootSBadClusSBadClusМестоположение этих записей изменилось в NTFS 3.1 (Windows Server 2003 и Windows ХР)Местоположение этих записей изменилось в NTFS 3.1 (Windows Server 2003 и Windows ХР)SSecureSSecureSUpcaseSUpcaseSReparseSReparseSUSNJrnlSUSNJrnlHe используется — зарезервированоHe используется — зарезервированоРис. 15.6. Записи метаданных в таблице MFTРис. 15.6. Записи метаданных в таблице MFT$ Extend$ Extend$ObjlD$ObjlD$Quota$QuotaКопия этих записейхранится всередине тома
SMftMirr
SMftMirr
$Logfile
$Logfile
SVolume
SVolume
$AttrDef
$AttrDef
SBitmap
SBitmap
$Boot
$Boot
SBadClus
SBadClus
Местоположение этих записей изменилось в NTFS 3.1 (Windows Server 2003 и Windows ХР)
Местоположение этих записей изменилось в NTFS 3.1 (Windows Server 2003 и Windows ХР)
SSecure
SSecure
SUpcase
SUpcase
SReparse
SReparse
SUSNJrnl
SUSNJrnl
He используется — зарезервировано
He используется — зарезервировано
Рис. 15.6. Записи метаданных в таблице MFT
Рис. 15.6. Записи метаданных в таблице MFT
$ Extend
$ Extend
$ObjlD
$ObjlD
$Quota
$Quota
Таблица MFT представляет собой файл. Первая запись в таблице MFT является записью файла, которая соответствует самой таблице MFT. Это запись $MFT. Если сектор, в котором хранится запись $MFT, поврежден или недоступен для чтения по другой причине, операционная система не сможет запуститься. Для предотвращения такой ситуации первые четыре записи MFT ($MFT, $MFTMirr, $LogFile и $Volume) копируются в центр тома. Если загрузчик Ntldr не может открыть эти записи по стандартному адресу, он загружает копии записей и использует информацию из записи $MFTMirr для получения содержимого поврежденного сектора и монтирования файловой системы.
В файловой системе NTFS 1.2, которая использовалась в операционной системе Windows NT 4.0, первые 16 записей таблицы MFT использовались для хранения метаданных. Информация содержалась только в первых 11 записях, а остальные записи были зарезервированы для будущего использования. В файловой системе NTFS 3.0 и следующих версиях для метаданных выделено 26 записей, 15 из которых содержат информацию.
Имена записей метаданных встречаются во многих ситуациях, чаще всего — в сообщениях об ошибках, особенно при серьезном повреждении файловой системы. Но в большинстве случаев знание имен и функций записей метаданных настолько же полезно, как знание названий всех костей человеческого скелета. Это позволяет точно указывать источник проблемы. В противном случае приходится показывать пальцем.
Ниже приведен краткий список записей метаданных и их функций. Более подробное описание приводится далее в главе.
$MFT. Файловая система NTFS рассматривает любую информацию на диске в виде файла Это касается и таблицы MFT. Запись $MFT указывает на таблицу MFT. Запись $MFT является записью гибридного типа и содержит атрибуты данных и атрибуты каталогов. В состав атрибутов каталогов входит битовая карта (bitmap), которая описывает структуру таблицы MFT и показывает используемые и неиспользуемые записи.
$MFTMirr. Файловая система NTFS создает копию первых нескольких записей MET в центре тома. Если кластер основной записи $MFT поврежден, система воспользуется копией для восстановления оставшихся фрагментов таблицы MFT. Запись $MFTMirr является стандартной файловой записью таблицы MFT, которая содержит указатель на расположение копии записи $MFT. .
$LogFlle. Эта запись содержит информацию о расположении файлов журнала, которые поддерживают отслеживание транзакций. Файловая система NTFS записывает обновления критических записей MFT в журнал до записи изменений на диск. Запись $LogFile указывает на два файла журналов, основной и копию, которые расположены посередине тома.
$Volume. В этой записи хранится имя тома NTFS, размер тома и версия файловой системы NTFS, которая использовалась для форматирования тома. В записи $Volume используется уникальный формат со специализированными атрибутами. Кроме этого, в записи хранится флаг, который используется для обозначения аномального завершения работы файловой системы.
$AttrDef. Эта запись указывает на файл, в котором перечислены поддерживаемые файловой системой NTFS атрибуты, а также информация об этих атрибутах (должны ли атрибуты храниться в таблице MFT или их можно хранить в любом месте диска). В записи $AttrDef используется стандартный формат записи файла.
$ \. В этой записи хранится корневой каталог файловой системы. Корневой каталог очень важен для обеспечения целостности файловой системы, так как все остальные каталоги ссылаются на корневой каталог. Запись $ \ использует стандартный формат записи каталога.
$BitMap. Как и файловые системы FAT и FAT32, файловая система NTFS поддерживает карту кластеров тома, которая позволяет быстро определить расположение неиспользуемых кластеров. В карте кластеров NTFS используются отдельные биты вместо байтов, поэтому том огромного размера может быть представлен компактной структурой. В записи $BitMap используется стандартный формат записи файла. В разделе “Улучшения для повышения производительности” далее в этой главе показано, какие изменения были внесены в эту запись с выходом файловой системы NTFS 3.1.
$Boot. Этот файл указывает на загрузочный сектор раздела, расположенный в кластере 0. Загрузчик Ntldr использует эту информацию для монтирования файловой системы. Кроме этого, в записи хранятся два атрибута данных. Один указывает на основной загрузочный сектор, а второй — на копию загрузочного сектора в конце тома.
$BadClus. В этом файле хранится информация о расположении поврежденных класте-, ров, которые были обнаружены во время форматирования и использования файловой системы. (Если выбрать быстрое форматирование (quick format), система не будет скани- • ровать том на наличие поврежденных кластеров, поэтому в эту запись информация добавлена не будет.) В записи $BadClus используется стандартный формат записи файла.
$ Secure. Эта запись появилась в файловой системе NTFS 3.0. В ней хранятся дескрип-' торы безопасности для всех записей таблицы MFT. Объединение дескрипторов безопас- ’ ности в единственную запись вместо их хранения во всех записях MFT позволяет повысить производительность и обеспечивает наследование разрешений. В записи $ Secure1. используется специальный формат, содержащий как данные, так и индексы.i
$UpCaee. В этом файле содержится таблица преобразования символов нижнего регистра Unicode в символы верхнего регистра. В записи $UpCase используется стандартный формат записи файла.
$Extend. Эта запись появилась в файловой системе NTFS 3.0. С ее помощью формируется папка, в которой хранятся дополнительные записи метаданных, добавленные в файловой системе NTFS 3.0 ($Quota, $Obj ID, $Reparse), и журнал изменений ($UsnJrnl). В записи $ Ext end используется стандартный формат записи каталога.
$0uota. Запись $Quota представляет собой каталог, в котором хранятся записи для идентификаторов безопасности пользователей и принадлежащих им файлов. Эта запись поддерживает выделение дискового пространства тома на основе квот. Запись $ Quota существовала в файловой системе NTFS с самого начала, но она не была реализована до выхода файловой системы NTFS 3.0 (операционная система Windows 2000). В записи $Quota используется стандартный формат записи каталога.
$ObjID. Эта запись также появилась в файловой системе NTFS 3.0. Запись $Ob j ID хра- нйт индекс файлов и папок, который содержит глобально уникальные идентификаторы. Этот индекс используется службой отслеживания ссылок для поиска исходных файлов для ссылок OLE, например ярлыков и вложенных документов.
$Reparee. Эта запись также появилась в файловой системе NTFS 3.0. В записи хранится информация о точках функционального монтирования (reparse point). Точка функционального монтирования перенаправляет вызывающий процесс в другое хранилище (другую папку или файл) или даже в другую файловую систему, например на компакт- диск, DVD или привод магнитной ленты.
$UsnJrnl. Еще одна запись, которая появилась в файловой системе NTFS 3.0. Это запись файла, в котором содержится журнал изменений. В журнале отслеживаются изменения файлов, что позволяет приложениям отказаться от полного сканирования файловой системы. Одним из приложений, использующих возможности журнала изменений, является служба индексации.
“Грязный” флаг
Файловая система NTFS хранит большой объем данных в кэше, чтобы записать их на диск в удобное время. В случае отключения питания (или “зависания” операционной системы) существует вероятность, что некоторые критические данные не будут записаны на диск. Отсутствие таких данных может привести к разрушению файловой системы.
Если в памяти находятся страницы, не записанные на диск, файловая система NTFS устанавливает флаг в записи $volume. Обычно этот флаг называется “грязным” (“dirty”). Если флаг установлен, диск и кэш находятся в несинхронизированном состоянии. После записи всех страниц на диск файловая система NTFS сбрасывает флаг.
Если при запуске операционной системы после аварийного завершения работы “грязный” флаг установлен, перед инициализацией операционной системы запускается специальная версия утилиты chkdsk, которая называется autochk. Результаты проверки файловой системы отображаются на консоли. Если система обнаружит ошибки на диске, предупреждение будет выведено на консоль и записано в журнал событий (если система сможет загрузиться).
Отображение поврежденных кластеров
Если запись кластера завершается неудачно, файловая система NTFS отмечает кластер как поврежденный и отображает этот кластер на запасной кластер в другом месте диска. Данные записываются в отображенный кластер.
Для этого логический номер кластер» заносится в запись метаданных $BadClus. Каждая запись в $BadClus имеет форму именованного потока данных с указателем на поврежден-
ный кластер. По сути, для блокирования доступа к поврежденному кластеру система назначает этому кластеру файл.
Отображение поврежденных кластеров не требуется при использовании дисков SCSI, поскольку эти диски обладают возможностями самовосстановления. Если сектор,диска SCSI поврежден (не удается записать данные), контроллер диска отображает адрес сектора на другой сектор из специальной области, предназначенной для этих целей. Возможность динамической замены секторов (sector sparing) позволяет обеспечивать нормальное функционирование диска в течение многих лет. Если файловая система NTFS не может записать кластер на диске SCSI, сначала ожидается решение проблемы с помощью замены секторов средствами диска SCSI. Если на диске закончились запасные секторы, файловая система NTFS начинает использовать отображение поврежденных кластеров. Для дисков IDE, USB и FireWire используется только отображение поврежденных кластеров средствами файловой системы NTFS.
Файловая система NTFS и сменные носители
Файловая система NTFS поддерживает форматирование таких сменных носителей, как ZIP, Jaz и Orb, но привод должен быть настроен на безопасное извлечение носителя и не допускать внезапного отключения от системы. Этот параметр является свойством драйвера устройства. Для доступа к этому параметру необходимо открыть окно свойств устройства. Откройте вкладку Hardware (Оборудование), выделите устройство привода сменных носителей и щелкните на кнопке Properties (Свойства), чтобы открыть окно свойств этого устройства. Откройте вкладку Policies (Политики), как показано на рис. 15.7.
Рис. 15.7. В окне свойств привода сменных носителей на вкладке Policies (Политики) включено кэширование записи
В разделе Write Caching and Safe Removal (Кэширование записи и безопасное извлечение) доступны настройки кэширования. По умолчанию выбран переключатель Optimize for Quick Removal (Оптимизировать для быстрого извлечения). В этом случае отключается кэширование записи и пользователь может извлечь носитель из привода в любой момент. При выборе переключателя Optimize for Performance (Оптимизировать для производительности)
придется самостоятельно щелкать на пиктограмме Safe Removal (Безопасное извлечение) в области уведомлений строки состояния для остановки устройства перед его извлечением.
Конечно, в данном случае все зависит от поведения пользователя. Если выдернуть кабель USB или FireWire из разъема интерфейса, компьютер никак не сможет помешать пользователю. Но желательно все делать по правилам. По умолчанию кэширование записи отключено, что позволяет избежать ненужной потери данных.
Улучшения для повышения производительности
Слияние потребительского и корпоративного кодов в операционной системе Windows ХР заставило компанию Microsoft рассматривать проблему производительности не в самую последнюю очередь. Особенно это касается производительности операций ввода-вывода для дисков. Традиционно файловая система NTFS отставала от файловой системы FAT32 с точки зрения полной производительности. В конце концов, непроизводительные затраты на обеспечение безопасности и надежности в файловой системе NTFS усложняли конкуренцию с другими файловыми системами с точки зрения производительности из-за применения механизма поиска данных в больших таблицах.
Для удовлетворения запросов производительности пользователей файловой системы FAT32 и одновременного сохранения надежности файловой системы NTFS компании Microsoft пришлось решить множество мелких проблем. На микроуровне пришлось переработать заголовки записей таблицы MFT, чтобы они попадали на четные границы байтов, а также немного изменить порядок хранения информации. Это позволило сократить объем работы при чтении заголовка записи. Это небольшое изменение, но файловая система считывает информацию заголовка записи миллионы раз в сутки, поэтому пара тактов тут и там позволяет экономить достаточно времени.
На макроуровне компания Microsoft изменила место хранения двух ключевых записей метаданных: $BitMap и $LogFile. Рассмотрим перечень изменений.
Запись $BitMap выполняет ту же функцию, которая выполнялась таблицей размещения файлов (FAT) в файловой системе FAT. В записи хранится карта использованных кластеров, что позволяет драйверу файловой системы NTFS быстро находить свободное дисковое пространство. Расположение этой записи очень важно, поскольку головки жесткого диска часто считывают информацию из этой записи.
Запись $LogFile также важна, поскольку поддерживает протоколирование информации о файловой системе. Это ключевая возможность, обеспечивающая надежность файловой системы NTFS по сравнению с файловой системой FAT.
Кроме этого, таблица MFT была перемещена в томе примерно на одну треть от начала. Это позволяет разместить таблицу MFT раньше файлов приложений, которые файловая система NTFS 3.1 переносит в начало тома для увеличения производительности. Копия таблицы MFT сохранилась в центре тома.
Эти критические записи метаданных размещаются в указанных местах, если при установке операционной системы выполняется форматирование раздела или преобразование файловой системы FAT/FAT32. Если выполняется модернизация предыдущей версии Windows с последующим преобразованием файловой системы, изменение положения записей для увеличения производительности не выполняется.
Перемещение файлов приложений играет важную роль в увеличении реальной производительности. Операционная система Windows Server 2003 отслеживает запускаемые системой и пользователями приложения. Каждые три дня система выполняет дефрагментацию критических файлов и размещает их в начале тома. Это делается во время простоев системы, поэтому не удивляйтесь активному использованию жесткого диска по вечерам.
Протоколирование файлов NTFS
Файловая система NTFS кэширует в памяти значительный объем данных и ожидает подходящего момента для их записи на диск. При неожиданном отключении питания компьютера можно рассчитывать на длительную процедуру перезагрузки из-за выполнения проверки диска утилитой autochk.
Существует вероятность, что утилита autochk не сможет восстановить содержимое критических записей метаданных. В таком случае монтирование файловой системы окажется невозможным и придется потратить целый день на восстановление тома с ленты.
Для предотвращения такой ситуации файлы метаданных протоколируются (journaled), т.е. все изменения записей таблицы MFT сначала записываются в журнал в центре диска, после чего через некоторое время записи журнала переносятся в основную таблицу MFT.
Перенос записей из журнала в таблицу MFT выполняется средствами службы файла журнала (Log File Service — LFS). Каждый перенос выполняется в виде неделимой транзакции (atomic transaction), которая обеспечивает сохранение целостности записей даже в случае отказа во время переноса записи.
Ведение журналов для файловой системы позволяет быстро восстанавливать таблицу MFT после неожиданного отключения питания или “зависания” системы. Все, что требуется от утилиты autochk, — это проверить целостность таблицы MFT и внести оставшиеся записи из журнала.
Атрибуты NTFS
Как было указано ранее, таблица MFT представляет собой базу данных. Записи в базе данных содержат атрибуты, определяющие такие элементы файловой системы, как файлы, каталоги, имена файлов и т.д. Атрибуты определяются записью метаданных $AttrDef. Каждый атрибут получает кодовый номер, который идентифицирует атрибут в таблице MFT.
Ниже приводится краткое описание каждого атрибута. В работающей файловой системе эти атрибуты определены в записи метаданных $Attribute. Из командного интерпретатора операционной системы эта запись недоступна, но том NTFS можно просмотреть с помощью шестнадцатеричного редактора и найти любой интересующий атрибут по имени. Помните, что перед именем атрибута всегда указывается символ $.
Заголовок. Первая часть каждой записи MFT всегда состоит из информации заголовка, который не имеет атрибута. В этой информации указываются номер записи MFT, счетчик для отслеживания изменений, а также номер записи MFT для каталога, в котором хранится файл (или папка), представленный этой записью.
$standard_lnformation. Хранит стандартные атрибуты файла (только чтение, скрытый, системный и архивный), а также набор меток времени. Кроме этого, в файловой системе NTFS 3.0 и следующих версиях атрибут $Standard_lnformation содержит указатель на дескриптор безопасности в записи метаданных $Secure. Дополнительную информацию можно получить в разделе “Дескриптор безопасности”.
$File_Name. Содержит имя записи MFT. Если запись представляет собой длинное имя, добавляется второй атрибут $File_Name, в котором хранится короткое имя, совместимое ; с операционной системой DOS (если генерация коротких имен не была отключена). :
$Securlty_Descriptor. Этот атрибут больше не используется. Начиная с файловой ; системы NTFS 3.0, атрибут $Security_Descriptor заменен записями в записи мета- - данных $Secure. Атрибут $Standard_Information в записи MFT содержит номер • индекса для записи $ Secure, который соответствует дескриптору безопасности для i записи MFT.-■ s
1
J
1
I
"3
3
л
-Я
2
я
-j
$Data. В этом атрибуте хранится то, что обычно воспринимается как содержимое файла. Запись MFT может иметь несколько атрибутов $Data. Дополнительная информация приводится в разделе “Именованные потоки данных”.
$Index_Root, $Index_Allocation и $Bitmap. Эти атрибуты используются для индексирования атрибутов MFT и ускорения доступа. В основном, они используются записями каталогов для индексирования имен файлов. Кроме этого, они используются для индексации других атрибутов и поддержки Таких возможностей, как отслеживание ссылок и точки функционального монтирования.
$Reparse_Point. Этот атрибут содержит указатель на том, запись папки или устройство. При открытии записи с этим указателем файловая система открывает указанное в записи хранилище. Атрибут $Reparse_Point поддерживает такие возможности, как точки монтирования и службы удаленного хранилища (Remote Storage Services).
$Logged_Utility_Stream. Этот атрибут используется шифрованной файловой системой. Дополнительная информация приводится в главе 17, “Управление шифрованием файлов”.
$Ва и $Ea_Information. Эти атрибуты изначально использовались для поддержки файловой системы High Performance File System (HPFS), которая применялась подсистемой OS/2. Операционные системы Windows 2000 и Windows Server 2003 не поддерживают подсистему OS/2 и файловую систему HPFS.
Дескриптор безопасности
Перед тем как рассматривать использование дескрипторов безопасности в файловой системе NTFS 3.x, рассмотрим обработку атрибутов в целом.
Атрибуты NTFS классифицируются по методу хранения в таблице MFT (резидентные) и по методу хранения в другом месте диска с указателем в записи таблицы MFT (нерезидентные).
Метки времени
Атрибут $standard_information каждой записи MFT содержит четыре метки времени, которые описывают время следующих событий.
Создание записи
Модификация атрибута
Модификация данных или индекса
Последний доступ
При первом создании файла или папки для всех меток времени устанавливаются одинаковые значения. Метка создания записи сохраняет свое первоначальное значение.
Метка модификации данных обновляется при модификации атрибута записи файла $Data или атрибута записи каталога $lndex_Root. При модификации любого другого атрибута записи MFT обновляется метка времени модификации атрибута.
Можно предположить, что метка времени последнего доступа обновляется при каждом открытии записи, но это приведет к значительной нагрузке на файловую систему. Представьте, сколько необходимо обновлений при запуске Explorer (Проводник)! Вместо этого метка времени последнего доступа модифицируется каждый час независимо от числа операций доступа к файлу. Точность метки времени последнего доступа для файловой системы FAT32 установлена на уровне одного дня.
Отключив обновление этой метки времени, можно увеличить производительность файловой системы. Это может привести к проблемам в процессе аудита, поэтому не отключайте обнов-
пение, не рассмотрев все проблемы, связанные с безопасностью. Обновлением управляет следующая запись системного реестра: :
Раздел: HKLM\System\CurrentControlSet\Control\FileSystem i
Запись: NtfsDisableLastAccessUpdate j
Значение: 1 (reg_dword) |
Одни атрибуты, например $Standard_Information и $File_Name, должны всегда ос- 1 таваться в пределах таблицы MFT. Системе постоянно требуется информация из этих атри- ’ бутов, и нельзя допустить, чтобы эта информация собиралась по всему диску. Другие атрибу- | ты, например, $Data и $lndex_Root, могут быть перемещены в другое место на диске, если ; их размер не позволяет хранить их непосредственно в таблице MFT. 1
Как только атрибут становится нерезидентным, возникает возможность фрагментации. 1 Это являлось проблемой для более ранних версий-файловой системы NTFS, в которых боль- | шие дескрипторы безопасности должны были храниться за пределами таблицы MFT. Это за- 1 ставляло файловую систему обращаться к другому месту на диске для просмотра дескриптора ] безопасности перед предоставлением доступа к файлу или папке, что приводило к значитель- I ному снижению производительности файловой системы. |
Кроме этого, в операционной системе Windows 2000 появилась возможность наследова- ] ния разрешений. Это позволяет внести изменения в дескриптор безопасности родительского I каталога, а изменение автоматически “распространится” по всему дереву файлов и подкатало- 1 гов. Если бы компания Microsoft реализовала наследование разрешений средствами старых ] резидентных/нерезидентных дескрипторов безопасности, производительность файловой сис- 1 темы снизилась бы до совершенно неприемлемого уровня. I
Вместо этого в файловой системе NTFS 3.0 была предложена новая запись метаданных I MFT, которая называется $ Secure. Эта запись представляет собой скрытую базу данных, ко- I торая содержит все дескрипторы безопасности для файловой системы, а также несколько ин- Ж дексов, которые ускоряют поиск записей. Структура этой базы данных показана на рис. 15.8. Я
Сами дескрипторы безопасности хранятся в атрибуте данных, который называется $SDS. Я Вместе с дескриптором безопасности хранятся дополнительные значения каждой записи Я $ SDS, которые перечислены ниже. Я
Я Хеш дескриптора безопасности, который используется в качестве ключа для индекса Я Я Порядковый номер, назначенный каждому дескриптору безопасности для использования Я
в качестве идентификатора
Размер дескриптора безопасности
Смещение дескриптора безопасности от начала потока данных $ SDS
Последние два значения имеют большое значение, так как дескрипторы безопасности могут иметь разные размеры и алгоритмы поиска записей фиксированной длины в данном случае не подходят..
Связи дескрипторов безопасности
Атрибут $Standard_Information для каждой записи MFT содержит порядковый номер соответствующего дескриптора безопасности. Это значительно упрощает реализацию наследования прав доступа. При создании нового файла файловая система NTFS связывает запись MFT с тем же дескриптором безопасности, с которым связаны другие файлы в каталоге. В таком случае в атрибуте $Standard_lnf ormation используется тот же порядковый номер $SDS.
При модификации дескриптора безопасности файла или папки с помощью добавления записей в список контроля доступа или при установке флажка Don't Inherit (Не наследовать) в редакторе списка контроля доступа (ACL Editor) для разрыва цепочки наследования в $SDS создается новый дескриптор безопасности и атрибут $Standard_Inf ormation записи MFT связывается с созданным дескриптором безопасности.
База данных $Secure (скрытая запись метаданных)
Поток данных $sds
Дескриптор безопасности №1 1. Хеш (ключ индекса) 2. Порядковый номер SSDSСмещениеРазмерДескриптор безопасностиДескриптор безопасности №1 1. Хеш (ключ индекса) 2. Порядковый номер SSDSСмещениеРазмерДескриптор безопасностифайл, папка илифайл, папка илизапись метаданных МПзапись метаданных МПДескриптор безопасности №2Дескриптор безопасности №2Дескриптор безопасности №3Дескриптор безопасности №3Дескриптор безопасности №...Дескриптор безопасности №...$Standard_InformationМетки времениАтрибутыМаксимальное количество редакцийТекущая редакцияЗарезервированоИдентификатор квотыПорядковый номер $SDSРазмер квотыПорядковый номер обновления$Standard_InformationМетки времениАтрибутыМаксимальное количество редакцийТекущая редакцияЗарезервированоИдентификатор квотыПорядковый номер $SDSРазмер квотыПорядковый номер обновления
Дескриптор безопасности №1 1. Хеш (ключ индекса) 2. Порядковый номер SSDS
Смещение
Размер
Дескриптор безопасности
Дескриптор безопасности №1 1. Хеш (ключ индекса) 2. Порядковый номер SSDS
Смещение
Размер
Дескриптор безопасности
файл, папка или
файл, папка или
запись метаданных МП
запись метаданных МП
Дескриптор безопасности №2
Дескриптор безопасности №2
Дескриптор безопасности №3
Дескриптор безопасности №3
Дескриптор безопасности №...
Дескриптор безопасности №...
$Standard_Information
Метки времени
Атрибуты
Максимальное количество редакций
Текущая редакция
Зарезервировано
Идентификатор квоты
Порядковый номер $SDS
Размер квоты
Порядковый номер обновления
$Standard_Information
Метки времени
Атрибуты
Максимальное количество редакций
Текущая редакция
Зарезервировано
Идентификатор квоты
Порядковый номер $SDS
Размер квоты
Порядковый номер обновления
Индекс $sdhИндекс $sdhЗапись №2Запись №2Запись №3Запись №3Запись №...Запись №...Запись №11. Хеш (ключ индекса)2. Порядковый номер $SDS3. Смещение записи $sds4. Размер записи $SDSЗапись №11. Хеш (ключ индекса)2. Порядковый номер $SDS3. Смещение записи $sds4. Размер записи $SDSИндекс$511
Индекс $sdh
Индекс $sdh
Запись №2
Запись №2
Запись №3
Запись №3
Запись №...
Запись №...
Запись №1
1. Хеш (ключ индекса)
2. Порядковый номер $SDS
3. Смещение записи $sds
4. Размер записи $SDS
Запись №1
1. Хеш (ключ индекса)
2. Порядковый номер $SDS
3. Смещение записи $sds
4. Размер записи $SDS
Запись №1
Порядковый номер $SDS
Хеш (ключ индекса)
Порядковый номер
Смещение записи $SDS
Запись №3Запись №3Запись №...Запись №...Размер записи $SDS Запись №2
Запись №3
Запись №3
Запись №...
Запись №...
Рис. 15.8. Структура базы данных $Secure
На практике файловая система NTFS использует отдельные дескрипторы безопасности для файлов и папок. Поэтому, если не вносить изменения в разрешения безопасности для файлов и папок тома NTFS, в $SDS будет существовать только два дескриптора безопасности: один — для всех файлов и другой — для всех папок.
Поиск дескрипторов безопасности
Запись $Secure поддерживает два индекса, которые называются $SDH и $SII. Эти индексы показаны на рис. 15.8 и описываются ниже.
Индекс $SDH сортирует записи $SDB по хешу, использующемуся в качестве ключа
Индекс $ S11 сортирует содержимое индекса $ SDH по номеру дескриптора безопасности
Индекс $SDH позволяет ограничить количество дескрипторов безопасности благодаря использованию дескрипторов безопасности, уже существующих в $SDS. Если содержимое дескриптора безопасности файла или папки совпадает с содержимым дескриптора безопасности другого файла или папки, включая все унаследованные разрешения, система воспользуется порядковым номером существующей записи $SDB.
Для этого система должна иметь способ быстрого сканирования одинаковых дескрипторов безопасности. Именно в этой ситуации полезен индекс хешей $SDH. Статистическая вероятность одинаковости хеша у двух дескрипторов безопасности ничтожно мала, поэтому система рассчитывает хеш нового дескриптора безопасности и пытается найти такой же хеш в $SDH. Если такой хеш найден, порядковый номер из индекса используется для обновления атрибута $Standard_Inf ormation в записи MFT.
Конечный результат? Том NTFS использует компактное множество дескрипторов безопас- | ности с полной перекрестной индексацией для управления правами доступа к файлам и папкам. 1 Это позволяет увеличить производительность и приводит к упрощению наследования.|
Особенности дескрипторов безопасности1
Не стоит запоминать подробную информацию о каждом компоненте базы данных 1 $Secure. Ниже приведено краткое описание требований, основанных на принципах работы ] базы данных $ Secure.I
При добавлении записей контроля доступа в список ACL файла или папки с сохранением на- 1 следования создается новая запись $SDS с дескриптором безопасности, в списке ACL которого 1 содержатся унаследованные и непосредственно назначенные записи контроля доступа.1
При перемещении файла в другое место в пределах тома расположение записи MFT не I меняется, как не меняется и порядковый номер $SDS. Таким образом, файл сохраняет ста- 1 рые параметры безопасности и наследует новые параметры из нового каталога.|
При копировании файла в другое место в пределах того же тома создается новая запись | MFT. Новая запись получает тот же номер индекса $SDS, что и в родительском каталоге.
При перемещении файла в другой том также создается новая запись MFT. Запись получа- 1 ет номер индекса $ SDS из родительского каталога.|
Если воспользоваться командой хсору / о для копирования файла с сохранением разре- Я шений безопасности, результат будет зависеть от наличия явно назначенных разрешений 1 в дескрипторе безопасности файла.Я
Если файл имеет собственный дескриптор безопасности в $SDS, порядковый номер этой я записи копируется в новую запись MFT.1
Если файл имеет унаследованные записи контроля доступа одновременно с явно назна- а ценными записями контроля доступа, система пытается найти другую запись $SDS с та- ■ кой же комбинацией прав доступа. Если такая запись не найдена, создается новая запись Я $ SDS, порядковый номер которой заносится в запись MFT.я
Если файл не имеет явно назначенных записей контроля доступа, система использует по- Я рядковый номер $ SDS дескриптора безопасности, назначенного другим файлам в катало- ■ ге. (Не забывайте, что файлы и каталоги используют разные дескрипторы безопасности.) Я
Записи файлов. I
Запись файла используется для хранения данных операционной системы или пользова- Я тельских приложений. Также запись файла MFT используется для хранения информации о Я файле, например имени файла, времени создания, размере файла и специальных атрибутах Я Read-Only (Только чтение), Hidden (Скрытый), Compressed (Сжат).Я
На рис. 15.9 показана структура простой записи файла. Запись имеет заголовок и три ат- Я рибута: $Standard_Information, $File_Name и $Data.Я
Информация заголовкаЯ
Ниже описаны некоторые наиболее важные элементы заголовка файла.Я
Номер записи MFT. Назначенный записи порядковый номер, который позволяет идеи-Д тифицировать запись. Эта информация используется индексами каталогов для созданияД связи между именами файлов и записями MFT.-Д
Флаг типа записи. Определяет, является ли запись записью файла или записью каталога, Я Если этот флаг установлен равным 0, запись рассматривается как помеченная для удале- Д
ния и может быть перезаписана. Записи файла соответствует значение флага 1, а записи каталога — значение 2.
Фактический размер и выделенный размер. Фактический размер соответствует количеству байтов в файле. Выделенный размер описывает количество байтов в кластерах, выделенное для хранения файла. Чем больше размер кластера, тем больше разница между этими значениями.
Запись файла MFTЗаголовок
$Standard_Information
$File_Name (Короткое имя - не обязательно)$File_Name (Длинное имя)
$Data(резидентная)It's very clean. [10][13] Well, it Is certainlyuncontaminated by cheese.
Puc. 15.9. Атрибуты простой записи файла
Порядковый номер обновления. Выступает в роли номера версии. При каждой модификации файла значение этого параметра увеличивается на единицу. При удалении файла и последующем повторном использовании записи MFT этот параметр устанавливается равным начальному значению — 2. Это указывает системе, что на удаленный файл ссылок не существует.
Элементы $Standard_Information
Этот атрибут MFT содержит набор меток времени, указатель на дескриптор безопасности записи MFT и флаг, который обычно рассматривается как атрибуты файла. Рассмотрим важные параметры флага атрибутов файла.
Стандартные атрибуты файла DOS: только чтение, скрытый, системный и архивный
Сжат
Точка функционального монтирования
Разреженный файл
Не индексирован (флаг службы индексации)
Зашифрован
Работая с файлами и каталогами, не забывайте, что эти атрибуты хранятся отдельно от содержимого файла, которое хранится в атрибуте $Data. Например, при копировании файла в новое место создается новая запись MFT с новым атрибутом $standard_Information, а значит, и новыми атрибутами файла. Но при перемещении файла запись MFT сохраняется, как сохраняются и флаги атрибутов в атрибуте $Standard_lnformation.
$File_Name
Каждая запись MFT содержит как минимум один атрибут $File_Name. В этом атрибуте можно хранить имя файла длиной до 256 символов. Это ограничение связано с однобайтной размерностью поля Length, связанного с именем.
Файл может иметь больше одного имени. Например, если имя файла не соответствует формату DOS 8.3, файловая система генерирует короткое имя и сохраняет его во втором атрибуте $File_Name. Это обеспечивает поддержку клиентов DOS/Windows 3.1, а также приложений DOS. Во врезке “Жесткие ссылки” приводится дополнительный пример нескольких имен одного файла.
Атрибуты папок
Если установить флаги атрибутов в атрибуте $standard_lnformation папки, а не файла, файловая система будет устанавливать такие же флаги для всех файлов, которые будут создаваться в этой папке. Обычно Explorer (Проводник) предлагает возможность применения изменений и к существующим файлам.
В операционных системах Windows Server 2003 и Windows ХР компания Microsoft изменила стандартный способ отображения атрибутов папки. Теперь вместо двоичной модели (включено или отключено) используется модель трех состояний (включено, отключено или индикатор состояния содержимого).
Индикатор состояния атрибута показывает, имеют ли файлы в папке этот атрибут. Например, если в папке присутствует файл только для чтения, флажок атрибута "только для чтения" в свойствах папки будет окрашен определенным цветом. Не перепутайте эту индикацию с установленным флажком, так как установленный флажок приводит к установке этого атрибута для всех создаваемых в папке файлов.
Жесткие ссылки 1
Автор этой книги является большим поклонником американского комедийного ансамбля 1970-х | годов, который назывался Firesign Theater. Для всех любителей странного юмора их альбомы I выпущены на компакт-дисках. Одно из моих любимых выступлений называется "Как ты мо- 1 жешь находиться в двух местах одновременно, если тебя вообще не существует?". ■ | Я вспомнил об этом, так как тема напоминает давно отключенную возможность файловой 1 системы NTFS, которая называется жесткие ссылки (hard links). Эта возможность позволяет 1 создавать дополнительные атрибуты файла и индексировать их в разных каталогах. Другими ] словами "создается" несколько копий одного файла в разных каталогах. я
До выхода операционной системы Windows Server 2003 единственным способом создания 1 жестких ссылок являлось использование программного интерфейса. В операционной системе 1 Windows Server2003 предоставляется новая утилита, которая называется Fsutil и предос- Я тавляет очень простую возможность создания новых ссылок. В данном случае необходимо я использовать такой синтаксис: Я fsutil hardlink create <конечный_файл> <исходный_файл> я Здесь конечный_файл — новое имя файла, а исходный_файл — имя существующего файла, Я для которого создается жесткая ссылка. Кроме этого, команда увеличивает на единицу зна- Я чение счетчика жестких ссылок в заголовке файла. При удалении одного экземпляра жесткой Я ссылки на файл удаляются только атрибут имени файла и индекс в записи каталога. Файл не Я может быть удален, пока не будут удалены все связанные с ним жесткие ссылки. я
Генерация коротких имен ■
Совместимость с операционной системой DOS все еще важна, и эта ситуация будет со- Я храниться в течение нескольких лет. (Автор уверен, что последний адвокат, настаивающий на ■ использовании WordPerfect 5.1, уйдет на пенсию в 2020 году.) Поддержка DOS требует ис- Ж пользования имен файлов в формате 8.3. Все файловые системы в операционной системе Я Windows Server 2003 автоматически генерируют совместимые с операционной системой DOS ■
короткие имена при назначении длинного имени. Для просмотра коротких имен можно воспользоваться командой dir /х.
Создание короткого имени файла в формате 8.3, представляющего имя файла длиной 256 символов, оказывается не такой простой задачей, как можно себе представить. Система не может просто взять первые восемь символов длинного имени и первые три символа расширения. Что если несколько имен файлов имеют одинаковые первые восемь символов? Как различать файлы с расширениями . htmn .html?
Операционная система Windows Server 2003 использует два алгоритма для генерации коротких имен файлов. Оба алгоритма сохраняют первые буквы длинного имени для сортировки в алфавитном порядке. Алгоритм меняется, если имена пяти или более файлов в одном каталоге начинаются с одинаковых букв. Рассмотрим алгоритм, который используется, если таких файлов меньше пяти.
Удаляются все символы Unicode, для которых нет соответствия стандартным символам ANSI.
Удаляются пробелы, внутренние точки и другие символы, недопустимые в именах DOS. Имя Long. File .Name. Test превращается в LongFileName .Test.
Первые три символа после последней точки сохраняются, например расширение LongFileName . Test превращается в LongFileName. Tes.
Отбрасываются все символы после первых шести. LongFileName.Tes превращается в LongFi.Tes.
Добавляется символ тильды (~), после которого указывается номер имени файла для обеспечения уникальности имен. LongFi . Tes превращается в LongFi~l .Tes.
Наконец выполняется преобразование символов имени файла в символы верхнего регистра. В результате имя файла Long. File. Name. Test превращается в LONGFI-1. TES.
Пятое и последующие имена файлов, которые начинаются с тех же шести символов, что и другие файлы в папке, обрабатываются немного по-другому.
Удаляются символы Unicode, пробелы и дополнительные точки.
Первые три символа после последней точки сохраняются как расширение.
Удаляются все символы после первых двух вместо первых шести. На этом этапе имя Long. File. Name. Tests превращается в Lo.Tes.
Добавляются четыре шестнадцатеричных числа, полученных с помощью алгоритма на основе оставшихся символов длинного имени файла. В результате преобразования строки Long.File.Name.Tests получается число D623, а имя Long. File. Name. Test6 преобразуется в число Е623. На этом этапе короткое имя выглядит как LoD623 . Tes.
Добавляются символ тильды (~) и порядковый номер. Это делается на случай, если алгоритм создаст одинаковые имена файлов. LoD623 . Tes превращается в LoD623~l. Tes.
Наконец символы имени преобразуются в символы верхнего регистра. В результате преобразования длинного имени файла Long.File.Name.Tests получается короткое имя LOD623-1.TES.
Длинные имена используются уже многие годы, поэтому их подводные камни хорошо известны. Помните он них.
Перемещение файлов с длинными именами между компьютерами. Алгоритм генерации коротких имен в операционных системах Windows NT работает не так, как алгоритм в операционных системах Windows 9х. Эти алгоритмы отличаются от алгоритмов операционной системы NetWare — Os2 . nam в версиях 3.x и Longname. nam в версиях 4.1х и выше.
■ Избыточное использование длинных имен приводит к снижению производительности. Желательно использовать имена длиной до 32 символов. Если каталог значительно фрагментирован, атрибуты для коротких и длинных имен могут храниться в разных местах, что значительно замедляет поиск файлов.
Сохранение коротких имен
При копировании файлов в операционной системе Windows Server 2003 короткое имя генерируется при создании файла на новом месте. Если на новом месте уже существует файл с такими же первыми шестью символами, короткое имя скопированного файла изменится. Если необходимо сохранить оригинальное короткое имя файла при копировании, воспользуйтесь параметром /п команды сору или хсору.
В операционной системе Windows Server 2003 программный интерфейс резервного копирования также сохраняет короткие имена, поэтому при восстановлении резервной копии файла в каталог, в котором уже существует файл с такими же первыми шестью символами, администратору придется указывать необходимость перезаписи существующих файлов.
■ Соблюдайте осторожность при использовании файлов пакетной обработки. Интерпретатор командной строки cmd. ехе в операционной системе Windows Server 2003 работает не так, как интерпретатор command.com. Например, при использовании cmd для смены каталога не требуется заключать в кавычки длинное имя. Можно ввести команду cd c:\dir one и попасть в интересующий каталог. Но это правило не распространяется на все команды. Если ввести команду del dir one*, то будет удален каждый файл, который начинается с dir, и каждый файл, который начинается с one (должны удаляться только файлы dir и все файлы, которые начинаются с one. — Примеч. пер.).
■ Специальная обработка расширений файлов. Расширения файлов также влияют на работу шаблонов. Рассмотрим в качестве примера файлы Long. File.Name. Testi.htm и Long. File. Name. Test2. html. Если с помощью командной строки просмотреть список файлов * . htm, в списке будут присутствовать оба файла, а не только файл с расширением . htm. Это может показаться безобидной ошибкой, но что будет, если ввести команду del * . htm, чтобы удалить только файл с расширением . htm? Вместе с файлом .htm будет удален файл с расширением . html.
Приложения DOS удаляют длинные имена. Если приложение DOS меняет короткое имя, длинное имя удаляется. Это может огорчить пользователей Windows.
Атрибут $Data
Запись файла хранит пользовательские данные внутри атрибута, который называется $Data. Атрибут $Data напоминает птенца. Он невелик, около нескольких сотен байтов, и на- . ходится внутри таблицы МЕТ. Как только атрибут становится слишком большим для гнезда,' файловая система находит свободное дисковое пространство и выталкивает атрибут из таб- " лицы МЕТ. Так атрибут $Data становится нерезидентным.
Данные в нерезидентном атрибуте $Data хранятся в непрерывной последовательности ; кластеров, которая называется цепочкой (run). Фрагмент атрибута $Data, который хранит- : ся в>таблице МЕТ, содержит указатель на такую цепочку. В указателе доступна следующая > информация.;
Номер кластера, с которого начинается цепочка. Это логический номер кластера (Logical ; Cluster Number — LCN). Логический номер кластера отсчитывается от начала тома, по- i этому 1500-й кластер от начала тома будет иметь логический номер кластера 1500. j
Длина цепочки в кластерах. Файл длиной 1024 байт на диске с кластером 512 байт будет j иметь длину цепочки 2.|
При добавлении данных к файлу файловая система просто добавляет байты к существующей цепочке и при необходимости добавляет кластеры.
Отключение генерации имен 8.3
Для повышения производительности файловой системы можно отключить генерацию имен в формате 8.3. Это также приводит к сокращению дискового пространства, которое используется для хранения индексных буферов. Отключать генерацию таких имен стоит только при отсутствии клиентов под управлением DOS и Windows 3.x. Для этого можно воспользоваться следующей записью системного реестра:
Раздел:HKLM\SystenACurrentControlSet\Control\FileSystem
Запись: NTFSDisable8dot3NameCreation
Значение: О
С ростом объема файла файловая система может натолкнуться на кластер, который уже занят другим файлом или каталогом. В таком случае файловая система выбирает следующий пустой кластер и начинает новую цепочку кластеров. В атрибут $Data в таблице MFT добавляется второй указатель, который определяет положение второй -цепочки. На этом этапе атрибут $Data становится фрагментированным (fragmented). На рис. 15.10 показана схема фрагментированного атрибута $Data.
Запись файла MET
ЗаголовокЗаголовок$Standard_Information$Standard_Information$File_Name (Короткое имя — не обязательно)$File_Name (Короткое имя — не обязательно)$File_Name (Длинное имя)$File_Name (Длинное имя)$Data (Нерезидентный)$Data (Нерезидентный)Первая цепочка — логический номер кластера и длина Вторая цепочка — виртуальный номер кластера и длина Третья цепочка — виртуальный номер кластера и длинаПервая цепочка — логический номер кластера и длина Вторая цепочка — виртуальный номер кластера и длина Третья цепочка — виртуальный номер кластера и длинаКластерыКластерыДругойфайлДругойфайлДругойфайлДругойфайл
Заголовок
Заголовок
$Standard_Information
$Standard_Information
$File_Name (Короткое имя — не обязательно)
$File_Name (Короткое имя — не обязательно)
$File_Name (Длинное имя)
$File_Name (Длинное имя)
$Data (Нерезидентный)
$Data (Нерезидентный)
Первая цепочка — логический номер кластера и длина Вторая цепочка — виртуальный номер кластера и длина Третья цепочка — виртуальный номер кластера и длина
Первая цепочка — логический номер кластера и длина Вторая цепочка — виртуальный номер кластера и длина Третья цепочка — виртуальный номер кластера и длина
Кластеры
Кластеры
Другойфайл
Другойфайл
Другойфайл
Другойфайл
Рис. 15.10. Фрагментированный атрибут $pata
В отличие от указателя на первую цепочку, в котором для идентификации начала цепочки используется логический номер кластера, в указателях на вторую и последующие цепочки указывается положение цепочки относительно предыдущей цепочки. Это так называемый виртуальный номер кластера (Virtual Cluster Number — VCN). Например, если первая цепочка начинается в кластере 100, а вторая — в кластере 350, то виртуальный номер кластера в указателе на вторую цепочку будет равен 250.
При дальнейшем увеличении объема файла будет встречаться все больше занятых кластеров. Это заставит файловую систему фрагментировать файл еще больше. Чем сильнее фрагментирован файл, тем больше указателей должно храниться в таблице MFT.
На определенном этапе файл становится настолько фрагментированным, что указатели не умещаются в 1 Кбайт записи MFT. В этот момент файловая система создает еще одну запись MFT для хранения указателей. В атрибуте $Attribute_List создается еще один указатель. Этот указатель содержит номер записи MFT, в которой хранятся дополнительные указатели. Это происходит только в случае значительной фрагментации файла.
Таблица MFT и фрагментация
Таблица MFT является таким же файлом NTFS, как и любой другой файл, а значит, таблица MFT может быть фрагментирована, если при увеличении размера ее файла будут достигнуты кластеры, занятые другими файлами.
Фрагментация таблицы MFT может привести к значительному снижению производительности, поэтому файловая система NTFS старается по возможности избегать такой фрагментации. Файловая система NTFS использует для защиты таблицы MFT ту же стратегию, которая используется государствами для защиты своей территории. Файловая система создает защитную зону перед таблицей MFT и избегает назначать файлам кластеры из этой зоны.
По умолчанию буферная зона таблицы MFT составляет до 12,5 % от общего объема тома. В томе объемом 18 Гбайт буфер таблицы MFT займет около 2,25 Гбайт. Этого объема достаточно для хранения таблицы MFT для более чем двух миллионов файлов и папок.
При переполнении диска файловая система ведет себя, как пират, и начинает распределять буфер таблицы MFT. На определенном этапе в случае продолжения такого поведения таблица MFT может подвергнуться фрагментации. Не стоит допускать сокращения свободного дискового пространства в томе NTFS ниже 15 % от общего объема. Обычно 25 % свободного дискового пространства можно рассматривать как оптимальную нижнюю границу, которая оставляет достаточно пространства для выполнения дефрагментации.
При желании можно увеличить размер буфера MFT, но если не перегружать том данными, выделенного по умолчанию объема должно быть достаточно. Размер буфера определяется в следующей записи системного реестра:
I
Раздел: HKLM\System\CurrentControlSet\Control\FileSystem
Запись: NtfsMftZoneReservation
Значение: 1-4 (reg_dword)
Значение 1 соответствует принятому по умолчанию размеру буфера: 12,5 % от общего объема тома. Значение 2 приводит к выделению 25 % дискового пространства, значение 3 соответствует 50 %, а значение 4 — 75 %. Система старается не использовать буфер MFT, поэтому при выделении большего буфера таблицы MFT необходимо снизить максимальную нагрузку на том.
Именованные потоки данных
Как было показано ранее, данные файла NTFS сохраняются в атрибуте $Data. Оказывается, в записи MFT может существовать несколько атрибутов $Data. Принятый по умолчанию атрибут $Data не имеет имени. Если приложение вызывает функцию интерфейса для чтения или записи данных в файл, файловая система NTFS предоставляет содержимое неименованного атрибута $Data, если явно не указан другой атрибут.
Изменения буферной зоны таблицы MET
В предыдущих версиях файловой системы NTFS использование буферной зоны МЕТ не начиналось до использования всего остального дискового пространства. Это очень мешало утилитам дефрагментации, так как область буфера могла оставаться последней областью свободного дискового пространства.
В файловой системе NTFS 3.1 компания Microsoft взяла пример с администрации Буша (учла его обращение с Обществом защиты арктической природы) и ослабила границу буферной зоны таблицы MFT. Граница стала не непроницаемым барьером, а подсказкой. Это позволило утилите defrag использовать пространство буферной зоны для хранения временных кластеров при их перемещении в ходе дефрагментации.
Дополнительные атрибуты $Data в записи файла должны идентифицироваться по именам. Поэтому они называются именованными потоками данных (named data streams). Рассмотрим пример создания именованного потока данных.
Создайте файл, который называется Superman.txt. Для этого достаточно ввести несколько символов в командной строке и перенаправить их в файл: c:\>echo It1s a bird. > Superman.txt
Будет создана запись MFT для файла Superman. txt с атрибутом неименованного потока данных, в котором содержится последовательность символов It's a bird.
Добавьте второй атрибут данных, перенаправив текст в именованный атрибут этого же файла:
c:\>echo It's a plane. > superman.txt:streaml
Добавьте третий атрибут данных с другим именем:
c:\>echo It's a SUPERMAN. > superman.txt:stream2
Просмотр содержимого именованных потоков данных может вызвать затруднения. Используемое приложение должно уметь ссылаться на поток по имени. Эта возможность поддерживается немногими приложениями. В этом простом примере воспользуемся командой more: c:\>more < superman.txt It's a bird. c:\>more < superman.txt:streaml It's a plane.
c:\>more < superman.txt:stream2 It's a SUPERMAN.
Реализация именованных потоков данных
Именованные потоки данных применяются не только для фокусов. Компания Microsoft использует их для поддержки некоторых возможностей, например Services for Macintosh (SFM). Том SFM использует именованные потоки данных для поддержки разветвленных (dual-fork) файлов Macintosh.
Еще одна возможность, в которой используются именованные потоки данных, называется Summary Information (Сводка). Для доступа к этой возможности можно открыть окно Properties (Свойства) для файла и активизировать вкладку Summary (Сводка), как показано на рис. 15.11.
При сохранении сводки для файла данные записываются в именованный поток данных, имя которого соответствует глобально уникальному идентификатору файла. Так как именованные потоки данных поддерживаются более ранними версиями файловой системы NTFS, файлы из операционных систем Windows Server 2003 и Windows 2000 можно копировать в операционную систему Windows NT без потери данных сводки. Но в Windows NT доступ к этой информации невозможен, так как для ее отображения не существует соответствующего интерфейса.
Рис. 15.11. Вкладка Summary (Сводка) для обычного файла
Именованные потоки данных и WebDAV
Именованные потоки данных используются еще одной функцией под названием Webbased Distributed Authoring and Versioning, или WebDAV.
Функция WebDAV поддерживает управление файлами по протоколу HTTP и является открытым стандартом, поддерживаемым IETF (Internet Engineering Task Force) и другими организациями. Со временем этот стандарт должен заменить протокол FTP в качестве стандартного метода перемещения файлов по сети Интернет. Возможности WebDAV подробно рассматриваются в главе 16, “Управление совместно используемыми ресурсами”.
В данном разделе WebDAV рассматривается потому, что эта технология оригинально использует именованные потоки данных. Для того чтобы понять, как это работает, создайте совместно используемый ресурс на компьютере под управлением Windows Server 2003, на котором запущена служба IIS. Для этого откройте окно Properties (Свойства) для папки и активизируйте вкладку Web Sharing (Web-доступ). Выберите переключатель Share This Folder (Предоставить эту папку для совместного доступа) и оставьте параметры, выбранные по умолчанию. В метабазе IIS будет создана новая виртуальная папка.
Кроме этого, необходимо настроить IIS на предоставление сведений о совместно используемых ресурсах WebDAV. По умолчанию такие сведения не предоставляются. Откройте консоль Internet Information Services, щелкните правой кнопкой мыши на пиктограмме сервера и выберите из контекстного меню команду Security (Безопасность). Запустится мастер Security Lockdown (Мастер настройки безопасности). Пройдите по всем окнам мастера и в окне Enable Request Handlers (Активизировать обработчики запросов) установите флажок Enable WebDAV Publishing (Разрешить публикацию WebDAV) в разделе ISAPI Handlers (Обработчики ISAPI).
Для подключения к Web-каталогу вместо браузера воспользуйтесь новым перенаправителем WebDAV, предоставленным в составе Windows Server 2003 и Windows ХР. Откройте приглашение командной строки и введите следующую команду:
net use * http://<имя_сервера>/<имя_меЬ-каталога>
Может быть выдан запрос на ввод регистрационных данных. После установки соединения и перенаправления диска, создайте несколько файлов на сетевом диске. Если в этот момент проследить за передаваемыми по сети данными, то можно заметить, что связь с ресурсом осуществляется по протоколу HTTP, а не по протоколу SMB, который обычно используется для связи между компьютерами под управлением операционной системы Windows.
Откройте окно свойств для одного из созданных файлов. Легко заметить, что можно изменить несколько атрибутов. Это атрибуты Read-Only (Только чтение), Hidden (Скрытый) и Archive (Архивный). Кроме этого, можно установить атрибут Encryption (Шифрование), что приведет к шифрованию локальной копии файла и копированию шифрованного файла по сети на удаленный ресурс. Дополнительная информация об этой функциональной возможности приводится в главе 17, “Управление шифрованием файлов”.
Если установить атрибуты Read-Only (Только чтение), Hidden (Скрытый) и щелкнуть на кнопке ОК, можно обратить внимание, что эти атрибуты будут показаны в окне Explorer (Проводник). Теперь перейдите на сервер и откройте свойства файла. Атрибуты не изменились.
В чем же йричина такого дуализма атрибутов? При установке атрибута по протоколу WebDAV атрибуты сохраняются в именованном потоке данных файла. Флаги в атрибуте $Standard_inf ormation не меняются. Это позволяет системе управлять атрибутами WebDAV по протоколу HTTP с использованием методов PropFind и PropSet. Также это означает, что атрибуты WebDAV должны управляться отдельно от атрибутов NTFS. Помните об этом при копировании файла WebDAV за пределы файловой системы NTFS. В таком случае все атрибуты WebDAV будут потеряны.
Записи каталогов
В каждой базе данных для поиска записей и ускорения просмотра используются индексы. Файловая система NTFS не является исключением. Самым известным индексом атрибутов является каталог, в котором индексируется атрибут $File_Name. Таблица MFT поддерживает индексирование любого атрибута. Ниже приводятся атрибуты, для которых в файловой системе NTFS существуют отдельные индексы.
Дескрипторы безопасности. Эти атрибуты хранятся в записи метаданных $ Secure и индексируются в записях $ SDH и $ S11.
Глобально уникальные идентификаторы. Если запись файла становится целью связи OLE, ей назначается глобально уникальный идентификатор. Глобально уникальные идентификаторы хранятся в атрибуте $Object_lD записи файла в таблице MFT и индексируются в записи метаданных $Ob j ID.
Значения квот. Заголовок записи файла содёржит информацию о квотах, которая индексируется в каталоге метаданных $Quota.
Точки функционального монтирования. Каталоги с символьными ссылками на другие каталоги, тома или устройства содержат атрибут $Reparse_Point. Эти атрибуты индексируются в каталоге метаданных $Reparse.
Компоненты записи каталога
Запись каталога в таблице MFT является специальной формой записи файла.. Запись содержит заголовок, атрибут $Standard_Inf ormation и как минимум один атрибут $File_Name. Но вместо атрибута $Data в записи присутствуют три дополнительных атрибута, в которых хранится информация об индексе. На рис. 15.12 показана структура типичной записи каталога.
$lndex_Root. В этом атрибуте содержится копия индексированного атрибута. Напри- - мер, в записи каталога атрибут $lndex_Root содержит копию атрибутов $File_Name каждого файла и папки в каталоге. Атрибут $lndex_Root всегда остается резидентным.
$index_Allocation. Если в результате увеличения объема индексированных записей атрибут $lndex_Root не помещается в записи MFT, индексированные записи перемещаются на диск буферами по 8 Кбайт. Атрибут $lndex_Root не может быть нерезидентным, поэтому записи переносятся в новый атрибут $lndex_Allocation, в котором хранятся логический номер кластера начала цепочки кластеров, размер буфера и длина цепочки.
$Bitmap. В этом атрибуте сохраняются сведения о свободном пространстве в индексных буферах.
Запись каталога MFTЗапись каталога MFTЗаголовокЗаголовок$Standard_Information$Standard_Information$Folder_Name (Короткое имя • не обязательно)$Folder_Name (Короткое имя • не обязательно)$Folder_Name (Длинное имя)$Folder_Name (Длинное имя)$Index_Root$Index_Root$Index_Allocation (карта буфера)$Index_Allocation (карта буфера)SBitmap (использование буфера)SBitmap (использование буфера) Буфер индакса (4 Кбайт)| SFile Name [ $File Name | $File Name J $File Name Буфер индакса (4 Кбайт)| SFile Name [ $File Name | $File Name J $File Name Буфер индекса (4 Кбайт)| $File Name | $FLle Name | $File Name | $File Name Буфер индекса (4 Кбайт)| $File Name | $FLle Name | $File Name | $File NameБуфер индекса (4 Кбайт)| $File NameP $File Name | $File Name | $File NameБуфер индекса (4 Кбайт)| $File NameP $File Name | $File Name | $File Name
Запись каталога MFT
Запись каталога MFT
Заголовок
Заголовок
$Standard_Information
$Standard_Information
$Folder_Name (Короткое имя • не обязательно)
$Folder_Name (Короткое имя • не обязательно)
$Folder_Name (Длинное имя)
$Folder_Name (Длинное имя)
$Index_Root
$Index_Root
$Index_Allocation (карта буфера)
$Index_Allocation (карта буфера)
SBitmap (использование буфера)
SBitmap (использование буфера)
Буфер индакса (4 Кбайт)
| SFile Name [ $File Name | $File Name J $File Name
Буфер индакса (4 Кбайт)
| SFile Name [ $File Name | $File Name J $File Name
Буфер индекса (4 Кбайт)
| $File Name | $FLle Name | $File Name | $File Name
Буфер индекса (4 Кбайт)
| $File Name | $FLle Name | $File Name | $File Name
Буфер индекса (4 Кбайт)
| $File NameP $File Name | $File Name | $File Name
Буфер индекса (4 Кбайт)
| $File NameP $File Name | $File Name | $File Name
Рис. 15.12. Пример структуры записи каталога
Сортировка по технологии В-дерева
При создании нерезидентных индексов атрибут $index_Root сохраняет первую запись каждого буфера и использует ее для сортировки. Корневые записи формируют В-дерево (B-tree) — структуру данных, ускоряющую сортировку. На рис. 15.13 показана структура В-дерева для каталога с неглубокой структурой. Поиск в В-дереве не требует выполнения сложных вычислений со стороны файловой системы. Если в этом примере от файловой системы требуется найти имя файла, лексикографически меньшее, чем 120 . txt (т.е. при сортировке по алфавиту эти значения будут ниже значения 120 . txt), в списке используется левая половина дерева. В противном случае используется правая половина дерева.
Рис. 15.13. Запись каталога, в которой показаны узлы В-дерева и несколько нерезидентных индексных буферовРис. 15.13. Запись каталога, в которой показаны узлы В-дерева и несколько нерезидентных индексных буферов
Рис. 15.13. Запись каталога, в которой показаны узлы В-дерева и несколько нерезидентных индексных буферов
Рис. 15.13. Запись каталога, в которой показаны узлы В-дерева и несколько нерезидентных индексных буферов
Короткие имена и сортировка по технологии В-дерева
Короткие имена привносят сложность в схему сортировки В-дерева. Имена файлов заносятся в индексные буфера в алфавитном порядке без разделения на короткие и длинные имена. Например, если в одном каталоге существует три длинных имени (Twilight of the Gods.txt, Twilight Double-Header.txt и Twilight Zone.txt), то короткие имена TWILIG-1, TWILIG-2 и TWILIG-3 окажутся на вершине списка перед длинными именами.
Если открыть папку в окне Explorer (Проводник) или ввести команду dir в приглашении командной строки, файловая система извлечет короткое и длинное имена. Если в каталоге существует множество файлов с длинными именами и одинаковыми первыми символами имени, производительность серьезно пострадает, так как системе придется провести полное сканирование всех индексных буферов в поисках соответствующих коротких имен.
Если короткие имена необходимы для поддержки клиентов DOS или других клиентов более старых версий, старайтесь создавать схемы именования, которые не предполагают использование одинаковых первых букв имени. Если это невозможно, разбейте дерево каталогов на меньшие папки, что позволит сократить размер индексных буферов.
Фрагментация каталогов
Каталоги могут быть фрагментированы, как и обычные файлы. Если цепочка индексных буферов наталкивается на кластер, занятый другим файлом или папкой, файловая система будет вынуждена начать следующую цепочку. Это приводит к созданию второго указателя в атрибуте $lndex_Allocation.
Значительная фрагментация каталогов моэрет привести к заполнению записи МЕТ указателями, так как каждый раз, когда система переносит указатель в другую запись МЕТ, в атрибуте $Attribute_List создается еще один указатель.
Фрагментация каталогов приводит к такому же или большему снижению производительности, поскольку файловой системе приходится собирать индексные буфера по всему диску. Рассмотрим, как файловая система NTFS обеспечивает дефрагментацию файлов и папок.
Дефрагментация
Как и в операционной системе Windows 2000, в операционных системах Windows Server 2003 и Windows ХР предоставляется утилита для дефрагментации, код которой лицензирован у компании Executive Software. Код вызывает функции API, которые созданы компанией Microsoft. Функции API предназначены для безопасного перемещения кластеров без повреждения файловой системы в случае неожиданного отказа источника питания или “зависания" системы.
Механизм дефрагментации состоит из двух выполняемых файлов, Dfrgfat.exe и Dfrgntfs.exe. Механизм Dfrgfat позволяет обслуживать файловые системы FAT и FAT32. Интерфейс управления дефрагментацией доступен на консоли Disk Defragmenter (Дефрагментация диска), файл Dfrg.msc. Пример отчета о фрагментированности диска показан на рис. 15.14.
Подробные сведения о способах дефрагментации дисков, включая использование новой утилиты дефрагментации с интерфейсом командной строки, приводится в разделе “Операции дефрагментации” далее в этой главе.
В операционной системе Windows Server 2003 предоставляется значительно улучшенный по сравнению с операционной системой Windows 2000 механизм дефрагментации. Исчезло множество неприятных ограничений. Ниже приведен краткий список улучшений.
Дефрагментация таблицы MFT. Теперь программный интерфейс дефрагментации поддерживает дефрагментацию таблицы MFT. Более того, поддерживается интерактивная дефрагментация таблицы MFT. В более ранних версиях операционной системы Windows
для дефрагментации таблицы MFT требовался запуск коммерческой версии программы дефрагментации во время загрузки системы. Это улучшение обрадует всех, кто хоть раз ждал несколько часов завершения дефрагментации во время загрузки.
AndyzedAndyzedQFAT32(E:)QFAT32(E:)FAT32 477MB 477MB 99%FAT32 477MB 477MB 99%д| Computer Managemert (Locaij-I Д System ToolsS jJ Event Viewer ® -S Shared FoldersIS M Performance Logs and^ Device ManagerВ Storage ' ® Removable Storageд| Computer Managemert (Locaij-I Д System ToolsS jJ Event Viewer ® -S Shared FoldersIS M Performance Logs and^ Device ManagerВ Storage ' ® Removable Storage® Ди«® Ди«■ I1 I■ I1 IЛЛ5 Disk ManagementEi Ц> Services and Appkations5 Disk ManagementEi Ц> Services and AppkationsDHCP Telephony Services WMI Control Indexing Service WINSDHCP Telephony Services WMI Control Indexing Service WINS
Andyzed
Andyzed
QFAT32(E:)
QFAT32(E:)
FAT32 477MB 477MB 99%
FAT32 477MB 477MB 99%
д| Computer Managemert (Locaij
-I Д System Tools
S jJ Event Viewer ® -S Shared Folders
IS M Performance Logs and
^ Device Manager
В Storage ' ® Removable Storage
д| Computer Managemert (Locaij
-I Д System Tools
S jJ Event Viewer ® -S Shared Folders
IS M Performance Logs and
^ Device Manager
В Storage ' ® Removable Storage
® Ди«
® Ди«
■ I1 I
■ I1 I
Л
Л
5 Disk Management
Ei Ц> Services and Appkations
5 Disk Management
Ei Ц> Services and Appkations
DHCP Telephony Services WMI Control Indexing Service WINS
DHCP Telephony Services WMI Control Indexing Service WINS
Puc. 15.14. В окне утилиты дефрагментации отображаются результаты отчета о фрагментированности диска
Более глубокая дефрагментация. Механизм дефрагментации был модифицирован с целью дефрагментации тех компонентов файловой системы, которые были недоступны в предыдущих версиях. Например, предыдущие версии механизма дефрагментации не поддерживали дефрагментацию значительно фрагментированных файлов, в которых использовались записи $Attribute_List. Кроме этого, не поддерживалась дефрагментация больших битовых массивов и точек функционального монтирования. Новый механизм поддерживает дефрагментацию всех этих компонентов.
Дефрагментация сжатых файлов. Теперь дефрагментация работает и для сжатых файлов, хотя полная дефрагментация сжатого и значительно фрагментированного тома не поддерживается. В реальных условиях даже при регулярной дефрагментации сжатый том постоянно остается фрагментированным. Единственным решением является создание резервной копии, очистка тома и восстановление копии.
Усиленная безопасность шифрованных файлов. Теперь шифрованные файлы дефрагментируются без открытия. Это позволяет закрыть потенциальную брешь в системе безопасности, когда конфиденциальные данные становятся доступны в виде временных файлов процесса дефрагментации.
Более “либеральные” правила фрагментации. С помощью того же исправления, которое защищает шифрованные файлы, обеспечивается возможность запуска программы дефрагментации файлов при наличии установленных атрибутов Read (Читать) и Synchronize (Синхронизировать). Дефрагментация становится менее “жесткой", но для ее запуска все еще требуются административные привилегии.
Гибкие размеры кластера. Теперь механизм дефрагментации работает с кластерами любого размера. Предыдущие механизмы дефрагментации поддерживали кластеры размером до 4 Кбайт. Это значит, что в томе с большой базой данных можно увеличить размер кластера и не беспокоиться, что не удастся дефрагментировать файлы.
Запуск из командной строки. Новый интерфейс для командной строки, который называется defrag, позволяет запускать дефрагментацию из файлов пакетной обработки. Объединение возможностей пакетного файла и Task Scheduler (Планировщик заданий) позволяет автоматически регулярно запускать дефрагментацию.
Кроме этого, служба настройки производительности запускается каждые три дня и перемещает часто используемые файлы в более подходящие места на диске. Служба не выполняет полной дефрагментации, но позволяет поддерживать содержимое диска в порядке.
Сохранились два ограничения механизма дефрагментации.
Файл подкачки. Не поддерживается дефрагментация файла подкачки.
Реестр. Не поддерживается дефрагментация системного реестра.
Для предотвращения фрагментации файла подкачки можно указать одинаковые значения максимального и минимального размеров файла подкачки. Это предотвратит рост файла, а значит, и фрагментацию. Для решения проблемы фрагментации системного реестра можно воспользоваться утилитой Pagedefrag, доступной на сайте www. sysinternals . com.
Компания Executive Software распространяет коммерческую версию утилиты Di skeeper, которая предоставляет дополнительные функциональные возможности и работает значительно быстрее, чем механизм в составе операционной системы Windows Server 2003. Среди других утилит дефрагментации от сторонних производителей можно назвать следующие.
PerfectDisk от компании Raxco Software, www. raxco .com
SpeedDisk от компании Symantec, www. Symantec. com
Defrag Commander от компании Winternals, www. winternals . com
Программа SpeedDisk использует собственный метод дефрагментации, который не использует механизмы, предоставленные компанией Microsoft. Это позволяет выполнять более полную дефрагментацию. Осторожные администраторы высказывают опасения в связи с использованием неизвестного механизма, но автор этой книги не встречал сообщений о возникших проблемах. Удостоверьтесь, что используемый продукт сертифицирован для работы под управлением операционной системы Windows Server 2003.
Сжатие файлов
Если речь идет о возможностях жестких дисков, то диски никогда не бывают слишком большими или слишком “быстрыми”. На момент написания книги жесткие диски UltraSCSI 160 со скоростью вращения шпинделя 15 000 об/мин обеспечивали стоимость 1,6 цента за мегабайт. К моменту выхода книги объем диска увеличится вдвое, но диски будут продаваться по той же цене.
Даже при таких ценах хранилище не бесплатно, а время на установку и настройку стоит еще больших денег. Это особенно справедливо для дисков на компьютерах пользователей, данные на которых должны быть скопированы до замены диска и создания образа. Сжатие позволяет быстро и дешево решить проблемы подсистемы хранения, но сжатие обладает собственными ограничениями.
Файловая система NTFS поддерживает сжатие отдельных файлов, всех файлов в каталоге или всех файлов тома. Алгоритм сжатия обеспечивает баланс между скоростью доступа и объемом занимаемого дискового пространства. Механизм сжатия в операционной системе
Windows Server 2003 улучшен и поддерживает сжатие файлов любого размера, если атрибут $Data является нерезидентным. В более ранних версиях файловой системы NTFS сжатие поддерживалось только для файлов размером более 16 кластеров.
Максимальный размер кластера, поддерживаемый интерфейсом сжатия, составляет 4 Кбайт. Если использовать сжатие не планируется и приложения хранят данные в больших файлах, том можно отформатировать с использованием большего кластера, что позволяет добиться повышения производительности.
Совет по использованию системного реестра: параметры дефрагментации
Параметры работы Disk Defragmenter (Дефрагментация диска) хранятся в системном реестре в разделе HKLM\Software\Microsoft\Dfrg.
Путь к консоли Disk Defragmenter (Дефрагментация диска), файл ofrg.msc, хранится в записи системного реестра HKLM\Software\Microsof t:\Wiridows\CurrentVersion\Explorer\ MyComputer\DefragPath. '
По умолчанию консоль запускается с помощью команды %systemroot%\Systejn32\ dr f g. ms c % с:, в которой выбирается дефрагментация диска С.
Сжатый файл идентифицируется флагом в атрибуте $Standard_lnformation, но управление сжатием осуществляется с помощью флага в атрибуте $Data. Этот же флаг используется для шифрования и разреженных файлов, поэтому сжатие, шифрование и разреженность являются взаимоисключающими. ,
При установке флага сжатия данные сжимаются и распаковываются в процессе записи и чтения с диска. Это относится и к резервным копиям, поэтому, если на сервере хранятся сжатые файлы, рассчитывайте на увеличение размера резервной копии. Если установить флаг сжатия для папки, сжимаются новые файлы, созданные в этой папке или скопированные в нее. Существующие файлы не сжимаются, если не указать необходимость сжатия при установке флага для папки.
Дополнительная информация приводится в разделе “Операции при сжатии файлов” далее в этой главе. В этом разделе приводятся процедуры управления сжатием файлов из интерфейса Explorer (Проводник) и интерфейса командной строки при использовании утилиты compact.
Сжатие файлов и производительность
Сжатие приводит к увеличению нагрузки на файловые серверы и серверы печати. Компания Microsoft признает от 5 до 15 % снижения производительности передачи данных. Личный опыт автора подсказывает более значительное падение производительности.
Точно подсчитать снижение производительности сложно, так как обычно сервер обслуживает сотни соединений с пользователями, которые выполняют различные операции с помощью приложений, баз данных и файлов данных от тысяч различных производителей. Включение сжатия в этом зоопарке программного обеспечения может отрицательно сказаться на отношении пользователей к администратору. Сжатие личных файлов на сервере оказывается более подходящим применением этой возможности по сравнению с тотальным сжатием всех файлов. Поскольку пользователи могут выполнять сжатие собственных файлов, учитывайте эту возможность при переносе данных.
Никогда не сжимайте файлы баз данных. Снижение производительности при обработке случайного доступа в сжатом файле является слишком существенным. Если необходимо дополнительное дисковое пространство, перенесите файлы баз данных на больший жесткий диск.
Особенности сжатия файлов
Работа со сжатыми файлами в реальных условиях может преподнести несколько сюрпризов. Рассмотрим некоторые особенности сжатия файлов.
Сжатые тома могут подвергаться значительной фрагментации. Утилиты дефрагментации не справляются с дефрагментацией сжатых томов. Учитывайте эту особенность при выполнении сжатия на сервере. Может возникнуть необходимость копирования тома на ленту с последующим восстановлением для обеспечения полной дефрагментации.
При копировании или перемещении файлов в другой том NTFS создается новый файл. Допустим, для новой папки заданы параметры сжатия. Это может привести к распаковке очень большого файла в небольшой том. Соблюдайте осторожность.
В файловых системах NTFS 1.2, NTFS 3.0 и NTFS 3.1 используется один и тот же алгоритм сжатия, поэтому к сжатым файлам можно получать доступ из операционных систем Windows NT 4.0, Windows 2000 и Windows Server 2003. Удостоверьтесь, что на более старых версиях операционных систем стоят последние версии пакетов обновлений, в которых предоставляются новые драйверы файловой системы NTFS.
Операционная система Windows Server 2003 не поддерживает чтение томов DriveSpace. Перед модернизацией операционных систем Windows Эх и Windows ME необходимо распаковать все тома DriveSpace.
Флаг сжатия остается установленным при копировании файла на ленту. При восстановлении файла из резервной копии он сжимается в процессе записи на диск независимо от параметров родительской папки.
Внимательно следите за дисковой статистикой, предоставляемой Explorer (Проводник) для сжатых файлов. Отображаемый размер файла соответствует размеру несжатого файла. В свойствах каталога всегда стоит включать параметр Show Compressed Files in Color (Отображать сжатые файлы другим цветом).
Разреженные файлы
Базы данных и приложения создания образов часто выделяют большие объемы дискового пространства, которые не обязательно используются сразу после выделения. В операционной системе Windows Server 2003 поддерживается интерфейс создания специальных файловых структур, которые называются разреженными файлами (sparse files).
Для разреженного файла резервируется определенный размер, но такой файл не занимает все выделенное для него дисковое пространство, пока файл не заполнен. Поскольку разреженные файлы обрабатываются на уровне приложений, экономия дискового пространства не приводит к снижению производительности, характерной для сжатия файлов.
Создание разреженного файла с помощью простого заполнения текстового файла нулями не поддерживается. Точно так нельзя создать разреженный файл, просто создав большую базу данных, когда дисковое пространство расходуется на создание записей. Для этого приложение базы данных должно использовать специальный интерфейс разреженных файлов. Единственным приложением в составе Windows Server 2003, использующим разреженные файлы, является служба индексирования, которая хранит информацию каталога в разреженном формате. Не существует специальных параметров или записей в системном реестре, предназначенных для обработки разреженных файлов.
Преобразование файловой системы в формат NTFS'
Операционная система поддерживает преобразование файловых систем FAT и FAT32 в NTFS без потери данных. Это хорошая новость. Плохая новость заключается в том, что обратная операция не поддерживается. Чтобы вернуться к использованию файловых систем FAT и FAT32, необходимо создать резервную копию данных, отформатировать раздел и восстановить данные из резервной копии.
Операционные системы Windows Server 2003 и Windows ХР предоставляют множество улучшений файловых систем, которые связаны с преобразованием в NTFS. Это связано с тем, что файловая система NTFS поддерживается Windows ХР Home Edition, что является первым случаем предоставления файловой системы NTFS в составе продукта потребительского уровня. За несколько следующих лет многие компьютеры под управлением- Windows 98 и Windows ME будут модернизированы до Windows ХР. Это значит, что преобразование файловой системы в NTFS должно проходить быстро и без проблем.
Преобразование и программа установки
Одним из первых улучшений механизма преобразования является отказ от необходимости преобразования при установке Windows Server 2003. Программа установки теперь может непосредственно форматировать разделы с использованием файловой системы NTFS вместо файловой системы FAT/FAT32 в качестве промежуточной с последующим преобразованием. Это значит, что при начальном копировании с установочного компакт-диска файлы записываются сразу в файловую систему NTFS, что позволяет избежать неприятной фрагментации системных файлов и таблицы MFT во время установки.
Немногие компании устанавливают операционную систему на сервер или рабочую станцию с компакт-диска. Часто администраторы предпочитают устанавливать операционную систему по сети с помощью сценария установки или службы удаленной установки (RIS).
Если установка выполняется по сети, сначала системный раздел должен быть отформатирован с помощью файловой системы FAT или FAT32 с последующим копированием установочных файлов на локальный диск средствами утилиты winnt. Преобразование такого раздела в NTFS приводит к фрагментации, но в операционной системе Windows Server 2003 эта ситуация улучшена двумя способами.
В составе Deployment Tools предоставляется новая утилита о format (ирландская родственница утилиты format). Эта утилита предназначена для размещения кластеров FAT/FAT32 таким образом, чтобы не мешать преобразованию в NTFS.
В программу convert добавлена новая функциональная возможность. Утилита предоставляет “зал ожидания” для таблицы MFT на время преобразования. Таблица MFT копируется в том только после преобразования всех остальных файлов. Это позволяет избежать фрагментации таблицы MFT.
Кроме этого, улучшения внесены в саму процедуру преобразования. За счет увеличения доступного объема памяти преобразование выполняется значительно быстрее. Кроме этого, поддерживается сохранение размера кластера для кластеров до 4 Кбайт, если раздел форматировался средствами операционных систем Windows Server 2003 и Windows ХР. В устаревших версиях программ преобразования предусматривалось использование кластеров размером 512 байт независимо от размера тома.
Сохранение размера кластера в томе, отформатированном в Windows 9х или Windows NT, поддерживается только при попадании кластеров FAT/FAT32 в границы кластеров, определенные в NTFS. В противном случае для преобразования используются кластеры размером 512 байт.
Преобразование и свободное дисковое пространство
В процессе преобразования целостность таблицы размещения файлов сохраняется до самого последнего момента. Все временные модификации записываются в свободное дисковое пространство, поэтому при преобразовании понадобится пространство “для маневра”. Попробуем грубо рассчитать объем необходимого дискового пространства.
Умножьте количество файлов и каталогов на диске на 1280.
Разделите размер тома в байтах на 100. Нижняя граница составляет 1 048 576, а верхняя —
4 194 304. Добавьте результат к результату, полученному в п. 1.
Разделите размер тома в байтах на 803 и добавьте результат к результату п. 2.
К результату п. 3 добавьте 196 096.
Например, расчеты для тома размером 4 Гбайт, на котором сохранено 100 000 файлов, будут выглядеть следующим образом:
100000 *1280 = 128000000
4 Гбайт *1024 = 4096Е6 /100 = 4960000
40690000 + 128000000 = 132096000
4069Е6 / 803 = 5100871 + 132096000 = 137196871 137196871 + 196096 = 137392967
Для преобразования в NTFS потребуется около 134 Мбайт свободного дискового пространства. Это менее 5 % от общего дискового пространства. Может хватить и меньшего объема, но желательно предоставить больший объем дискового пространства. В противном случае полученный том будет значительно фрагментирован и придется потратить дополнительное время на его дефрагментацию. Кроме этого, стоит указать файл преобразования в другом разделе, который позволит создать таблицу MFT и избежать ее фрагментации.
Преобразование и безопасность файлов
Еще одним недостатком устаревших версий утилит преобразования являлось предоставление полного доступа к файловой системе посредством добавления группы Everyone (Все) в дескрипторы безопасности каждого файла и папки.
В операционной системе Windows 2000 ситуация немного улучшилась, особенно в отношении того, насколько проще стало изменять права доступа NTFS. Права доступа можно было указать на вершине файловой системы, а наследование распространяло эти изменения на все остальные файлы. Но необходимо было помнить о выполнении дополнительного действия. В операционной системе Windows Server 2003 эта проблема полностью решена. Преобразованным разделам назначаются те же списки контроля доступа, что и во время установки операционной системы. Списки контроля доступа выглядят следующим образом.
Права полного доступа предоставляются учетной записи Localsystem, учетной записи Administrator (Администратор) и локальным группам Creator-Owner (Создатель- владелец) и Administrators (Администраторы).
Общее право доступа Read (Чтение) и специальные разрешения Write_Data/Append_ Data для локальной группы Users (Пользователи).
После завершения преобразования в список разрешений можно добавить и другие группы.
Служба отслеживания ссылок
Вы как администратор тратите дни и недели на планирование перемещения данных из-за того, что приходится координировать свои действия с действиями пользователями, которые создают ярлыки и вложенные документы, ссылающиеся на файлы глубоко в дереве каталогов
совместно используемого ресурса? Решением этой проблемы является служба отслеживания ссылок (Link Tracking Service — LTS). Эта возможность впервые появилась в операционной системе Windows 2000. ■
Эта служба отслеживает расположение исходных файлов для ссылок и приложений OLE. В качестве примера можно привести документ Word, в котором содержится ссылка на электронную таблицу Excel. Файл со ссылкой на другой файл называется клиентом ссылки (link client). Файл, на который указывает ссылка, называется источником ссылки (link source).
Обычно при перемещении источника ссылки клиент ссылки не может его обнаружить самостоятельно и выдает пользователю сообщение об ошибке. В операционной системе Windows Server 2003 служба отслеживания ссылок находит источник ссылки и автоматически модифицирует указатель клиента ссылки, чтобы он указывал на новое расположение файла- источника. Этот механизм работает даже в том случае, если файл перемещается на другой сервер в домене.
Классическое обнаружение источника ссылки в системах Windows NT и Windows 9х
Если в операционных системах Windows NT и Windows 9х клиенты ссылки не могли найти источник ссылки, Explorer (Проводник) возвращался к достаточно неуклюжему алгоритму поиска. Он начинал вести себя, как суслик, который потерял морковку: посмотрел вниз, посмотрел вверх, посмотрел вокруг и пошел искать другую морковку. Этот механизм поиска рассматривается в процедуре 15.1.
Процедура 15.1. Классический механизм поиска ссылок . в операционной системе Windows NT
Просмотреть четыре уровня вниз по дереву каталогов.
Перейти на один уровень вверх и опять просмотреть четыре уровня вниз.
Перейти к рабочему столу и просмотреть четыре уровня вниз.
Перейти в корневой каталог каждого диска и просмотреть четыре уровня вниз.
Повторять попытки поиска без ограничения на четыре уровня, пока не закончится период ожидания приложения или терпение пользователя.
Функциональное описание отслеживания ссылок
Служба отслеживания ссылок (LTS) позволяет при поиске источника ссылки отказаться от действий по принципу осмотра окружающей местности. Служба LTS хранит индекс всех источников ссылок в томе NTFS. Если один из источников перемещается, это указывается в индексе, что позволяет LTS обновить клиент ссылки.
Для этого LTS необходим метод уникальной идентификации файлов-источников в пределах предприятия. В этой ситуации также используется глобально уникальный идентификатор. При указании клиентом ссылки файла или папки в качестве источника ссылки система назначает файлу-источнику глобально уникальный идентификатор (GUID).
Базовая часть GUID относится к тому и увеличивается для каждой записи источника ссылки. Это позволяет файловой системе и Active Directory индексировать атрибуты $Object_lD по исходному тому, а также по расположению в таблице МЕТ.
После генерации глобально уникальный идентификатор сохраняется в записи файла источника ссылки. Для этого используется атрибут $Object_lD. Он индексируется в записи метаданных $ObjlD. В этой записи используется стандартный формат каталога с хранили-
щем индексов, в котором находятся глобально уникальные идентификаторы, назначенные источнику ссылки, и номера записей в таблице MFT. Эта информация позволяет системе находить любой файл с известным глобально уникальным идентификатором.
Запись метаданных $ob j idЗапись метаданных $ob j idЗапись файла источника ссылкиЗапись файла источника ссылкиЗапись файла ярлыкаЗапись файла ярлыка
Запись метаданных $ob j id
Запись метаданных $ob j id
Запись файла источника ссылки
Запись файла источника ссылки
Запись файла ярлыка
Запись файла ярлыка
ЗаголовокЗаголовокЗаголовокЗаголовокЗаголовокЗаголовок
Заголовок
Заголовок
Заголовок
Заголовок
Заголовок
Заголовок
$Standard_Information$Standard_Information$Standard_Information$Standard_Information$Standard_Information$Standard_Information
$Standard_Information
$Standard_Information
$Standard_Information
$Standard_Information
$Standard_Information
$Standard_Information
$File_Name$File_Name$File Name$File Name$File_Name$File_Name
$File_Name
$File_Name
$File Name
$File Name
$File_Name
$File_Name
$Index_RootIНазначенный тому GUID .Назначенный источнику ссылки QUIDИсходный файлIНомер записи MFT источника ссылки I Исходный файл$Index_RootIНазначенный тому GUID .Назначенный источнику ссылки QUIDИсходный файлIНомер записи MFT источника ссылки I Исходный файл$Ob)ect_IDНазначенный файлу GUID$Ob)ect_IDНазначенный файлу GUID$DataIt's not pinin', it's passed on! This parrot is no more! It has ceased to be! It has expired ...$DataIt's not pinin', it's passed on! This parrot is no more! It has ceased to be! It has expired ...$DataТип источника ссылкиРасположение источника ссылкиПуть к источнику ссылки GUID источника ссылки$DataТип источника ссылкиРасположение источника ссылкиПуть к источнику ссылки GUID источника ссылки
$Index_RootI
Назначенный тому GUID .
Назначенный источнику ссылки QUID
Исходный файлI
Номер записи MFT источника ссылки I Исходный файл
$Index_RootI
Назначенный тому GUID .
Назначенный источнику ссылки QUID
Исходный файлI
Номер записи MFT источника ссылки I Исходный файл
$Ob)ect_ID
Назначенный файлу GUID
$Ob)ect_ID
Назначенный файлу GUID
$Data
It's not pinin', it's passed on! This parrot is no more! It has ceased to be! It has expired ...
$Data
It's not pinin', it's passed on! This parrot is no more! It has ceased to be! It has expired ...
$Data
Тип источника ссылки
Расположение источника ссылки
Путь к источнику ссылки GUID источника ссылки
$Data
Тип источника ссылки
Расположение источника ссылки
Путь к источнику ссылки GUID источника ссылки
Puc. 15.15. Компоненты службы отслеживания ссылок
Рассмотрим пример использования атрибута индекса службой отслеживания ссылок для поиска перемещенного источника ссылки. На рис. 15.15 показаны компоненты транзакции поиска ссылки. Создадим пару “источник/клиент” ссылки, создав ярлык в Explorer (Проводник). Ярлык представляет собой файл с расширением . Ink, которым определяется клиент ссылки OLE. Целевой файл ярлыка является источником ссылки. Принцип работы службы отслеживания ссылок (LTS) рассматривается в процедуре 15.2.
Процедура 15.2. Проверка отслеживания ссылок
Создайте файл в томе NTFS.
Создайте ярлык для файла на рабочем столе. При этом файловая система создаст глобально уникальный идентификатор для этого файла и добавит его в атрибут $Ob j ect_lD, который хранится в записи файла в таблице MFT.
Клиент ссылки сохраняет глобально уникальный идентификатор источника ссылки вместе с остальной информацией об источнике, например местом расположения, путем и типом, в атрибуте $Data файла ярлыка.
Переместите источник ссылки в другой каталог в пределах того же тома. Изменится каталог файла, но запись файла в таблице MFT не изменится. Запись индекса $Ob j ID не изменится. Но после этого в файле LNK будет храниться неправильный путь к источнику ссылки.
Выполните двойной щелчок на файле ярлыка. Ссылка неправильная, поэтому клиент ссылки не сможет найти файл. Будет отправлен запрос службе отслеживания ссылок, ко-
торая начнет поиск глобально уникального идентификатора в индексе $Obj ID. С помощью записи MFT будет найден файл, а с помощью обратной ссылки на каталог будет найден каталог, в котором хранится этот файл.
Служба отслеживания ссылок сообщит новый путь файловой системе NTFS, которая обновит информацию в файле ярлыка. После этого клиент ссылки сможет открыть нужный файл.
Если переместить файл в другой том NTFS на этом же компьютере, поиск займет немного больше времени, так как служба отслеживания ссылок вынуждена будет просматривать индекс $Ob j ID в каждом томе. Как только интересующий глобально уникальный идентификатор будет найден, клиент ссылки будет модифицирован с использованием информации о расположении файла.
Отслеживание ссылок по сети
Ситуация немного усложняется, если переместить источник ссылки в том NTFS на другом сервере. В такой ситуации клиенту отслеживания ссылок необходима помощь центрального хранилища информации о ссылках. Это хранилище входит в состав службы Active Directory.
Каждый контроллер домена Active Directory выступает в роли сервера службы отслеживания ссылок (LTS Server). Если переместить источник ссылки на другой сервер в пределах домена Active Directory, клиент службы отслеживания ссылок на исходном сервере отправит обновление LDAP в базу данных Active Directory.
В базе данных Active Directory это обновление будет храниться в контейнере Object Move Table. Этот контейнер расположен в контейнере cn=FileLinks, cn=System,бс=<имя_ домена>, de=<корень>. Для просмотра содержимого этого контейнера можно воспользоваться консолью Active Directory — Users and Computers (Active Directory — пользователи и компьютеры). Для этого необходимо открыть меню View (Вид) и выбрать команду Advanced Features (Дополнительные функции).
На основе информации, полученной от сервера службы отслеживания ссылок, клиент этой службы обновляет запись MFT клиента ссылки и вносит в нее имя UNC для нового расположения источника ссылки. Конечно, при этом предполагается, что такой путь UNС существует. Одной из функций службы отслеживания ссылок является проверка существования совместно используемого ресурса, который предоставляет доступ к файлу. Если такого ресурса не существует, для тома используется административный ресурс ($). Пользователи не могут получать доступ к административному ресурсу, но инженер службы поддержки может быть проинструктирован о распознавании такого сообщения об ошибке и сможет создать новый совместно используемый ресурс.
Особенности отслеживания ссылок
Перечислим еще несколько ключевых особенностей процесса отслеживания ссылок.
Служба отслеживания ссылок (LTS) работает только в операционных системах Windows 2000, Windows Server 2003 и Windows ХР.
Отслеживание ссылок по сети надежно работает только в пределах домена. Иногда удается отследить ссылки на компьютерах из других доменов или рабочих групп, но вероятности успешного обнаружения недостаточно для широкого применения такого механизма.
Когда клиент службы LTS обнаруживает новый путь источника ссылки и обновляет ярлык, то в свойствах ярлыка обновляется только запись Target. Запись Start In сохраняет старое значение. Это может привести к проблемам в работе приложений, которые используют запись Start In для поиска файлов поддержки.
Если файл копируется, а не перемещается, атрибут $Obj ect_!D и соответствующий глобально уникальный идентификатор остаются связанными с оригинальным файлом.
При восстановлении файла, который является источником ссылки, восстанавливается и атрибут $Object_lD. Если восстановление выполняется в другое место, в результате будут получены два одинаковых файла с одинаковыми глобально уникальными идентификаторами в пределах домена. Это может привести к проблемам, когда служба отслеживания ссылок начнет путать эти файлы. Очень внимательно рассматривайте все последствия восстановления файлов.
Точки функционального монтирования
Точка функционального монтирования (reparse point) работает в качестве миниатюрного “перенаправителя” внутри отдельной записи MET. Точка функционального монтирования хранит имя папки, тома или устройства (привода компакт-дисков или дисков DVD). При открытии записи MFT, содержащей точку функционального монтирования, открывается объект, на который указывает точка функционального монтирования. Точки функционального монтирования позволяют представить тома и диски в виде папок, что избавляет от необходимости использовать буквы дисков и точки совместного доступа.
О точках функционального монтирования уже рассказывалось при развертывании операционной системы Windows Server 2003. При каждом открытии папки Sysvol на контроллере домена и просмотре папки с именем домена администратор проходит через точку функционального монтирования, так как папка \Windows\Sysvol\5увуо1\Имя_домена монтируется на папку \Windows\Sysvol\Domain.
Если открыть приглашение командной строки и просмотреть содержимое папки \Windows\Sysvol\Sysvol, то можно заметить, что вместо <DIR> тип файла указывается как < JUNCTION>. Именно так командный интерпретатор распознает точку монтирования (mount point).
Если создать точку монтирования, которая указывает на устройство, например привод компакт-дисков или дисков DVD, то Explorer (Проводник) воспользуется пиктограммой приложения AutoRun на носителе для обозначения устройства, на которое указывает точка монтирования.
Кроме этого, компания Microsoft использует точки функционального монтирования для поддержки возможностей управления иерархическим хранилищем в службах удаленного хранилища (Remote Storage Services — RSS). В службах удаленного хранилища файл физически находится в библиотеке на ленте, а на диске остается заглушка в виде точки функционального монтирования, которая выступает в роли указателя.
Принцип работы точек функционального монтирования
Точка функционального монтирования представляет собой атрибут, который называется $Reparse_Point и добавляется в стандартную запись каталога вместо атрибута $lndex_ Allocation. В атрибуте $Reparse_Point хранится идентификатор, указывающий системе, что монтировать, и содержащий символическую ссылку (symbolic link) на цель точки функционального монтирования. Символическая ссылка является внутренней конструкцией операционной системы в пространстве имен объектов (object namespace). Для просмотра пространства имен объектов можно воспользоваться утилитой winob j из состава Platform SDK или одноименной утилитой (с расширенными возможностями) от компании www. sysinternals.com.
Запись MET с тонкой функционального монтирования ЗаголовокЗапись MET с тонкой функционального монтирования ЗаголовокПривод компактдисков или дисков DVDЛенточный приводПривод компактдисков или дисков DVDЛенточный приводУстройство массового хранения (жесткий диск, диск USB, диск FireWire)Устройство массового хранения (жесткий диск, диск USB, диск FireWire)Папка в любом смонтированном томеПапка в любом смонтированном томеНа рис. 15.16 показана схема взаимодействия компонентов, принимающих участие в транзакции доступа к точке функционального монтирования. Точка монтирования всегда является стандартной папкой. В данном случае цель представляет собой папку в другом томе компьютера. Любой локальный том или устройство с монтируемой файловой системой может стать целью точки функционального монтирования. Создание точек функционального монтирования для сетевой файловой системы не поддерживается.
Запись MET с тонкой функционального монтирования Заголовок
Запись MET с тонкой функционального монтирования Заголовок
Привод компактдисков или дисков DVD
Ленточный привод
Привод компактдисков или дисков DVD
Ленточный привод
Устройство массового хранения (жесткий диск, диск USB, диск FireWire)
Устройство массового хранения (жесткий диск, диск USB, диск FireWire)
Папка в любом смонтированном томе
Папка в любом смонтированном томе
ЗаголовокЗаголовок$File Name$File Name$Index_Root$Index_Root• $Standard_lnformation• $Standard_lnformation$Standard Information$Standard InformationSReparse Ter повторной обработки -> точка монтирования Данные повторной обработки -> \??\D:SReparse Ter повторной обработки -> точка монтирования Данные повторной обработки -> \??\D:Тег повторной обработки -> точка монтированияДанные повторной обработки -> \??\Р:Тег повторной обработки-> точка монтирования Данные повторной обработки -> \??\D:Тег повторной обработки -> точка монтированияДанные повторной обработки -> \??\Р:Тег повторной обработки-> точка монтирования Данные повторной обработки -> \??\D:$File Name$File Name$Index_RootПустой$Index_RootПустойЗапись метаданных $Reparse
Заголовок
Заголовок
$File Name
$File Name
$Index_Root
$Index_Root
• $Standard_lnformation
• $Standard_lnformation
$Standard Information
$Standard Information
SReparse Ter повторной обработки -> точка монтирования Данные повторной обработки -> \??\D:
SReparse Ter повторной обработки -> точка монтирования Данные повторной обработки -> \??\D:
Тег повторной обработки -> точка монтирования
Данные повторной обработки -> \??\Р:
Тег повторной обработки-> точка монтирования Данные повторной обработки -> \??\D:
Тег повторной обработки -> точка монтирования
Данные повторной обработки -> \??\Р:
Тег повторной обработки-> точка монтирования Данные повторной обработки -> \??\D:
$File Name
$File Name
$Index_RootПустой
$Index_RootПустой
Рис. 15.16. Структура точки функционального монтирования
Целевой том или устройство может быть отформатировано с помощью любой файловой системы, поддерживаемой Windows Server 2003. Это относится к файловым системам FAT, FAT32, NTFS, CDFS, UDFS и RSS_FS. Том может содержать сжатые, зашифрованные и разреженные файлы.
Информация о целевой файловой системе хранится в скрытой базе данных в каталоге Root, которая называется $RemoteMountManager. Производители могут добавлять в базу данных драйверы фильтрации файловой системы, которые будут использоваться при открытии определенного устройства. База данных представляет собой именованный поток данных в записи метаданных $ Reparse.
Кроме этого, база $Reparse поддерживает индекс, связывающий содержимое базы данных диспетчера удаленного монтирования с записями MFT, в атрибуте $Reparse_Point которых содержатся символические ссылки.
Когда пользователь выполняет двойной щелчок на точке монтирования, файловая система, воспользовавшись этой информацией, просто открывает запись MFT точки монтирования, просматривает символическую ссылку, проверяет наличие драйверов фильтрации в базе данных диспетчера удаленного монтирования (Remote Mount Manager) и открывает том или устройство. Содержимое тома или устройства предоставляется пользователю как часть файловой системы, содержащей точку монтирования. ' . *
Эта технология используется в библиотеках компакт-дисков. Создавать логические диски для каждого компакт-диска в библиотеке с последующим отображением пользователей на эти диски — слишком утомительно, поэтому можно создать точки монтирования в существующем томе, которые будут указывать на каждый компакт-диск в библиотеке. Пользователи смогут получать доступ к компакт-дискам через каталоги совместно используемого ресурса, будучи полностью уверенными в том, что открывают каталоги на жестком диске.
Пошаговые процедуры создания точек функционального монтирования и управления ими приводятся в разделе “Работа точек функционального монтирования” далее в этой главе.
Основные характеристики точек функционального монтирования
Повторим ключевые моменты, связанные с использованием точек функционального монтирования.
Если в записи каталога содержатся записи файлов или каталогов, она не может использоваться в качестве точки монтирования. Каталог должен быть пуст.
При просмотре свободного и занятого дискового пространства Explorer (Проводник) не добавляет емкость смонтированного тома к емкости исходного тома. Это значит, что к существующему тому размером 4 Гбайт можно примонтировать том размером 30 Гбайт, но Explorer (Проводник) все равно будет уведомлять, что емкость тома составляет 4 Гбайт.
■ Поиск в родительском томе (или запуск такой утилиты DOS, как tree) означает поиск в содержимом всех примонтированных томов.
■ К тому можно получать доступ через несколько точек монтирования. При таком использовании точек монтирования следует соблюдать осторожность, поскольку подобная конфигурация может ввести пользователей в заблуждение. Представьте себе ситуацию при создании двух точек монтирования на двух совместно используемых ресурсах, которые указывают на один и тот же том. В результате можно получить звонок в службу поддержки примерно такого содержания: “Я скопировал свои файлы в папку К: \MyData и удалил папку R: \MyData. Теперь я не вижу своих файлов и в папке К: \MyData. Что произошло?”.
■ Копирование папки с примонтированным томом приводит к копированию содержимого примонтированного тома.
■ При удалении точки монтирования с помощью команды rd удаляется только запись МЕТ с точкой функционального монтирования, а не весь примонтированный том. Но если для удаления точки монтирования использована команда del или точка монтирования отправлена в Корзину в Explorer (Проводник), то из примонтированного тома удаляются все файлы и каталоги.
■ При резервном копировании в состав копии включаются файлы и каталоги смонтированного тома. Помните об этом при использовании нескольких точек монтирования. В такой ситуации может быть выполнено резервное копирование одного и того же каталога несколько раз. Программа Ntbackup предоставляет возможность отказаться от резервного копирования точек подключения смонтированных устройств и всех файлов, которые находятся ниже этих точек.
Восстановление файловой системы и отказоустойчивость
Файловая система является наиболее критическим элементом операционной системы. В случае повреждения файловой системы данные могут быть не только полностью утрачены, но и неявно повреждены. На то есть несколько причин. Диск может быть поврежден или может выдавать множество ошибок обращения к секторам. Может отказать бесперебойный источник питания (если он вообще установлен), что приводит к потере всех кэшированных данных. Система может “зависнуть" в результате работы некорректного драйвера. Некорректный драйвер может повредить файлы метаданных файловой системы.
Восстановление целостности файловой системы является для системного администратора такой же важной задачей, как восстановление стабильного пульса и признаков жизни для врача реанимации. В этом разделе рассматривается несколько проверок, которые позволяют
убедиться в стабильной работе системы. Кроме этого, рассматриваются возможности обеспечения отказоустойчивости, предназначенные для сохранения данных в случае катастрофы. Также рассматривается работа службы защиты файлов Windows. Начнем с вопросов регулярного технического обслуживания и всем известной утилиты chkdsk.
Утилиты chkdsk и autochk{
Первой линией обороны, предотвращающей повреждение файловой системы, является регулярное техническое обслуживание. Утилита обслуживания в операционной системе 1 Windows Server 2003 имеет достаточно древнее имя — chkdsk. Эта утилита используется для ] анализа файловой системы, обнаружения повреждений, нарушений целостности и восстановления всех повреждений.]
Выполняющий анализ программный код утилиты chkdsk в действительности находится ] в драйвере файловой системы — файле Ufat .dll для файловых систем FAT и FAT32 или ] файле Unt fs.dll — для файловой системы NTFS. Кроме применения утилиты chkdsk, су- | ществует еще несколько способов инициализации этого кода. Для этой цели можно использо- I вать Explorer (Проводник). Щелкните правой кнопкой мыши на пиктограмме диска, выбери- 1 те из контекстного меню команду Properties (Свойства), перейдите на вкладку Tools 1 (Сервис) и щелкните на кнопке Check Now (Проверить) в группе Error-Checking (Проверка | ошибок). Проверку во время загрузки можно запустить с помощью утилиты autochk.1
Сравнение утилит autochk и chkdskJ
Утилита autochk предназначена для работы в реальном режиме во время загрузки системы. 1 На этом этапе загрузки системы заблокированные файлы не мешают проверке целостности 1 файловой системы. Утилиту autochk невозможно запустить после загрузки операционной сис- I темы. Для управления утилитой autochk используется следующая запись системного реестра: |
I
Раздел: HKLM\System\CurrentControlSet\Control\SessionManager1
Запись: BootExecute|
Значение: Autocheck AUTOCHK *1
ааВ нормальных условиях утилита autochk запускается только в случае установки так назы- ] ваемого “грязного” (“dirty”) флага в записи $Volume. Этот флаг указывает на некорректное за- ] вершение работы файловой системы. Если утилита autochk запускается при каждой переза- 1 грузке компьютера, в системе, существует очень серьезная проблема. Ищите несовместимый с s операционной системой Windows Server 2003 кэширующий контроллер RAID или другую при- j чину. И ищите такую причину быстро. Многие администраторы наблюдали превращение нахо- ] дящейся в идеальном состоянии файловой системы в последствия празднования китайского но1 | вого года. И всему причиной была неправильная инициализация утилиты autochk. 1
а
а
При запуске утилиты autochk проверка диска выполняется в режиме “только чтение”. 1 Все найденные проблемы заносятся в журнал приложений. Подробная информация доступна ] с помощью консоли Event Viewer (Просмотр событий). Если в журнале присутствуют сооб- 1 щения об ошибках, перезагрузите компьютер и запустите утилиту autochk в режиме ис- ] правления (эквивалент запуска утилиты chkdsk с параметром / f ), чтобы исправить все об- 1 наруженные ошибки. Этот вопрос рассматривается в следующем разделе. j
Использование утилиты chkntfв для настройки утилиты autochk
Утилита chkntf s позволяет принудительно запустить утилиту autochk в режиме исправления. Ниже приводятся параметры утилиты chknt f s и синтаксис для запуска функций autochk. В каждом случае вместо <том> можно задать букву диска или имя тома.
chkntfs <ток> /с. Приводит к запуску утилиты autochk по отношению к указанному тому или диску. В системном реестре к записи autochk добавляется параметр /т.
chkntfs <тою /й. Позволяет вернуться к принятым по умолчанию правилам запуска утилиты autochk: она запускается в режиме “только чтение” при наличии установленного “грязного” флага.
chkntfs <том> /t: time. На завершение работы утилиты autochk может уйти некоторое время. Утилита работает в реальном режиме, поэтому дополнительный объем памяти для ускорения работы недоступен. В системе с большим массивом RAID и сотнями мегабайтов файлов завершение работы утилиты autochk может потребовать нескольких часов. Этот параметр утилиты chkntfs позволяет пропустить проверку autochk, если есть обоснованная уверенность в отсутствии повреждения файловой системы. Например, при отключении сервера для установки сетевого адаптера можно воспользоваться параметром /t:time для отключения длительной задержки. В этом случае в раздел HKLM\System\CurrentControlSet\Control\SessionManager добавляется запись AUTOCHKTimeOut.
chkntfs <том> /х. Указанный диск исключается из проверки autochk. Этот параметр следует использовать с осторожностью. Если забыть об этом параметре, система не сможет выполнять регулярную проверку во время загрузки. В этом случае к записи autochk в системном реестре добавляется параметр / к: <том>.
Функциональное описание утилиты chkdsk (autochk)
После запуска утилита chkdsk (или autochk) выполняет ряд проверок целостности. Для файловой системы NTFS выполняются следующие проверки.
Первый проход
Сканируется таблица MFT и составляется список активных записей файлов и каталогов. Создается битовая карта активных записей MFT и на основе информации о логических номерах кластеров в записях создается битовая карта активных кластеров.
Битовые карты используются для проверки файла $Bitmap в метаданных тома. Если запись недоступна для чтения или имеет неправильный формат, она идентифицируется как проблемная.
Второй проход
Сканируются записи каталогов и выполняется проверка преобразования каждой ссылки на файл в фактическую запись файла. Проверяется соответствие между ссылкой на файл в каталоге и ссылкой на каталог в записи файла.
Проверяется существование циклических ссылок на подкаталоги. Циклическая ссылка представляет собой каталог, который считает себя собственным подкаталогом. Циклические ссылки встречаются очень редко, но их появление приводит к потере большого объема данных в результате отключения от файловой системы большого поддерева каталогов. По этой причине не стоит относиться к циклическим ссылкам слишком легкомысленно.
Проверяется соответствие между атрибутами имен файлов в записях файлов и записями имен файлов в соответствующих записях каталогов. Эта операция может занять несколько минут или даже часов, в зависимости от количества записей в таблице MET и сложности структуры каталогов. Размер тома на скорость проверки не влияет. Том размером 32 Гбайт с 1000 файлов будет проверен в одно мгновение. Том размером 3 Гбайт, в котором создано 100 000 файлов, будет проверяться намного дольше.
Третий проход
Сканируются дескрипторы безопасности. Каждая запись должна ссылаться на дескриптор безопасности и соответствовать ссылке в самом дескрипторе безопасности.
Если для тома существует журнал изменений, система сканирует журнал и проверяет записи индекса. "
Четвертый проход
Выполняется сканирование диска с попыткой чтения каждого сектора, содержащего файл. Поврежденные кластеры добавляются в список $BadClus. Данные из поврежденных кластеров копируются в новые кластеры.
Пятый проход
Выполняется сканирование свободного дискового пространства. Поврежденные кластеры добавляются в список $BadClus.
Параметры утилиты chkdsk
Существует несколько параметров, с помощью которых можно управлять процессом сканирования утилиты chkdsk. В операционной системе WindowsNT4.0 SP4 были добавлены два параметра (/i и /с) для ускорения проверок целостности благодаря отказу от четвертого и пятого проходов. Эти параметры работают и для утилиты autochk.
/f. Запуск утилиты chkdsk в режиме исправления (для утилиты autochk используется параметр /р).
/v. Вывод дополнительных сообщений.
/г. Выполняется полное сканирование диска для поиска поврежденных кластеров. Все найденные поврежденные кластеры добавляются в файл $BadClus.
/1. Отображается размер файла $LogFile. Добавление параметра :размер, например /L: 4096, позволяет изменить размер файла $LogFile.
/х. Принудительное размонтирование тома. Данные всех открытых файлов будут ут-. рачены. Кроме этого, параметр заставляет утилиту chkdsk запускаться в режиме исправления.
/1. Параметр задает пропуск внутренней проверки соответствия между атрибутами имен файлов в записях файлов и связанными записями имен файлов в индексе каталога.
/с. Пропуск проверки циклических ссылок.
Дополнительный параметр /р может использоваться только при запуске утилиты chkdsk из консоли восстановления. Этот параметр заставляет утилиту chkdsk выполнить полную проверку.
Рекомендации по запуску утилиты chkdsk
Утилиту chkdsk стоит периодически запускать для обнаружения аномалий в системе. Запуск утилиты chkdsk для проверки тома с используемыми в данный момент файлами (системного тома или тома с базой данных) невозможен, так как файлы блокируются. Воспользуйтесь утилитой chkntfs для запуска утилиты autochk в режиме исправления во время загрузки.
Если на компьютерах некоторых пользователей операционной системы Windows ХР хранятся поврежденные файлы, избавить их от привычки просто отключать питание компьютера можно, настроив запуск утилиты autochk в режиме исправления при каждой загрузке
компьютера. Четко объясните, что дополнительное время загрузки является обязательным, так как накануне вечером компьютер был выключен некорректно. Со временем пользователи поймут намек.
Ведение журналов для файловой системы
В большинстве случаев утилиты chkdsk и autochk, запущенные в режиме исправления, позволяют исправить все аномалии файловой системы. Но что произойдет, если файловая система находится в неизвестном состоянии из-за аварийного завершения работы системы или отказа источника питания? Файловая система NTFS хранит в кэше большой объем данных для ускорения поиска и синхронизации операций записи на диск с целью достижения максимальной эффективности. Это так называемое “ленивое" кэширование записи или механизм отложенной записи (lazy write caching). Механизм отложенной записи позволяет значительно увеличить производительность системы, но повышение производительности достигается за счет снижения надежности.
Если файловая система оказалась в неизвестном состоянии после аварийного завершения работы или “зависания”, утилита autochk может ее восстановить, но эта задача выполняется крайне медленно. Результатом является простой компьютеров, не говоря уже о испытании терпения системных администраторов, которые вынуждены ожидать загрузки компьютера.
Время от времени серверы аварийно завершают работу. Это объективная реальность, поэтому к данному событию нужно подготовиться, создав способ быстрого восстановления файловой системы. В файловой системе NTFS для этих целей используется служба уровня ядра, которая называется служба файла журнала (Log File Service — LFS). Служба файла журнала является службой регистрации событий общего назначения. На данный момент файловая система NTFS является единственным клиентом этой службы.
Структура службы LFS
Служба LFS сохраняет информацию о записях на диск, затрагивающих ядро файловой системы. Эта информация хранится в файле $LogFile (один из файлов метаданных таблицы MFT). Файл $LogFile состоит из длинной цепочки кластеров, начинающейся в точке диска, выбранной для достижения максимальной производительности.
Большая часть пользовательских данных не защищена службой LFS. Если опустить большой красный рубильник питания сервера, то все данные из кэша будут уничтожены. Служба файла журнала позволит восстановить целостность критически важных файлов, но для восстановления пользовательских файлов придется ждать завершения работы утилиты autochk.
Функциональное описание службы LFS
Файл $LogFile состоит из двух частей: области перезагрузки (restart area) и области бесконечного журнала (infinite logging area). Область перезагрузки (хранящаяся в буферах с приставкой rstr) содержит информацию о расположении данных в области бесконечного журнала. Основным компонентом области перезагрузки является информация о контрольной точке. Контрольная точка позволяет определить, какие записи были внесены в таблицу MFT, а какие нет. Область бесконечного журнала (хранящаяся в буферах с префиксом rcrd) работает как лента с восемью дорожками. При переполнении журнала служба начинает запись сначала, перезаписывая старые записи.
При обновлении основной файловой системы управление процессом записи на диск передается службе LFS для занесения сведений в файл $LogFile. В число критических обновлений входят изменения заголовков атрибутов, атрибутов безопасности, расположения каталогов и модификации файлов метаданных таблицы MFT.
Периодически записи журнала записываются в таблицу MFT и выполняется перемещение контрольной точки. Если система аварийно завершит работу во время операции записи, служба файла журнала быстро восстановит состояние файловой системы. Для этого достаточно найти контрольную точку и просмотреть записи файла $LogFile. Затем служба файла журнала совместно с файловой системой удалит все незавершенные транзакции и выполнит их повторно. Последнее состояние таблицы MET соответствует состоянию файловой системы в момент аварийного завершения работы, за исключением записей, которые были задействованы в механизме отложенной записи и не были сохранены в файле журнала.
Восстановление файловой Системы с использованием файла журнала может занять некоторое время в больших томах, но это намного быстрее, чем восстановление с помощью утилиты autochk. Если восстановление с помощью журнала завершилось неудачно, файловая система выполняет полную перестройку. Если и эта операция завершилась неудачно, единственной альтернативой является восстановление из резервной копии. Для службы файла журнала не существует специальных элементов управления и записей системного реестра.
Единственным индексом, который восстанавливается службой LFS, является индекс имен файлов в записях каталогов. В операционной системе Windows Server 2003 существует несколько возможностей, требующих специальной индексации таблицы MFT. Восстановление этих индексов требует полного сканирования таблицы и много времени. Для ускорения восстановления в файловой системе предоставляется новая возможность, которая называется журнал изменений (Change Journal) и рассматривается в следующем разделе.
Журнал изменений
Никому не нравится мартышкин труд. Например, когда приходит время мыть посуду, ни- \ кто не достает весь сервиз, а моет только грязные приборы. С точки зрения домохозяйки, > “грязный” — это находящийся в мойке.j
Что касается обслуживания файловой системы, то регулярно приходится выполнять ре- 1 зервное копирование, антивирусное сканирование, проверку квот, индексацию содержимого s и т.д. Большинство этих операций не требует обработки Каждого файла. Эти операции требу- J ют открытия файла и сканирования его содержимого, что является накладной операцией 1 с точки зрения расхода ресурсов центрального процессора и подсистемы ввода-вывода. Ес- | ли пропустить файлы, не требующие обслуживания, ресурсы освободятся для более нуж- | ных операций.|
Эта функциональная возможность обеспечивается журналом изменений (Change Journal). 1 В журнале отслеживаются изменения записей таблицы MFT. Приложения могут воспользо- ] ваться функциями соответствующего программного интерфейса для определения записей, | изменившихся с момента последнего запуска приложения. После этого приложение сможет 1 обрабатывать только изменившиеся файлы.1
В операционной системе Windows Server 2003 услугами журнала изменений пользуются | следующие приложения.1
Служба индексирования (Content Indexing Service — CISVC). Эта служба поддерживает I
каталог содержимого текстовых файлов для поддержки быстрого поиска и извлечения I данных.j
Служба репликации файлов (File Replication Service — FRS). Служба репликации фай- 1 лов автоматически копирует данные с одного сервера на другой. Журнал изменений по- Я зволяет службе репликации файлов копировать только те файлы, которые изменились а с момента последнего копирования.1
Служба теневого копирования тома (Volume Shadow Copy Service — VSS). Новая J
служба операционной системы Windows Server 2003 позволяет создать моментальный 1
снимок содержимого тома для резервного копирования и обеспечения возможности одновременного просмотра несколькими пользователями совместно используемого ресурса.
Служба удаленного хранилища (Remote Storage Services — RSS). Эта служба перемещает файлы с диска в хранилище на магнитной ленте, но продолжает обеспечивать почти интерактивный доступ к файлам. Журнал изменений значительно сокращает время восстановления и снижает риск потери данных за счет упрощения проверок целостности.
Журнал изменений представляет собой запись метаданных, которая называется $UsnJrnl и хранится в каталоге метаданных $ Extend. В табл. 15.2 перечислены события, которые приводят к добавлению элемента в журнал изменений для индексированной записи.
Таблица 15.2. События, приводящие к добавлению элемента в журнал изменений
Basic_Info_Change
Hard_Link_Change
Close
Indexable_Chage
Compression_Change
Named_Data_Ext end
Data_Extend
Nained_Data_Overwrite
Data_Overwrite
Named_Data_Truncatlon
Data_Truncation
Object_Id_Change
Ea_Change
Rename_New_Name
Encrypt ion_Change
Rename_01d_Name
File_Create
Reparse_Point_Change
File_Delete
Security_Change
Stream_Change
Система отслеживает модификации журнала изменений с помощью порядкового номера обновления (Update Sequence Number — USN). При добавлении или модификации записи журнала запись получает следующий доступный порядковый номер обновления. Этот механизм похож на механизм отслеживания изменений в базе данных Active Directory. Порядковый номер USN является 64-разрядным числом. Этого хватит для добавления изменений в течение нескольких миллиардов лет.
Нет никаких советов по проблеме устранения неисправностей в работе журнала изменений. Журнал изменений работает полностью прозрачно, как служба файла журнала. Для журнала изменений не существует элементов управления в пользовательском интерфейсе и параметров в системном реестре. В случае повреждёния или случайного удаления журнала использующие его приложения переходят к полному сканированию и переиндексации таблицы MFT. Это может потребовать некоторого времени. Если перезагрузка отнимает слишком много времени, обратите внимание на записи об ошибках в журнале событий.
CLFS (Common Log File System)
В операционной системе Windows Server 2003 была добавлена файловая система стандартного журналирования, или CLFS (Common Log File System). Система CLFS является загружаемым драйвером, который предоставляет привилегированным и непривилегированным приложениям надежную систему журналирования. CLFS — это уникальная технология Windows, которая может быть использована при разработке приложений и промежуточного программного обеспечения, требующего надежной непрерывной записи и чтения данных. В качестве примера можно привести агенты репликации или аудита, базы данных и другие системы управления ресурсами на основе транзакций.
Данная технология предоставляет следующие возможности:
позволяет создавать файлы журнала как единым, так и несколькими потоками данных для совместного использования одним клиентом и более;
обеспечивает как циклическое, так и линейное ведение журнала;
благодаря предварительному резервированию пространства в журнале гарантирует возможность очищать буфер данных;
руководствуясь политиками, управляет размером журнала и объемом занимаемого пространства;■
предоставляет доступ к одному журналу как для привилегированных, так и для непривилегированных клиентов;■
обеспечивает механизм уведомлений, позволяющий координировать одновременное использование журнала несколькими пользователями;
гибко буферизирует данные журнала;
предоставляет прикладные программные интерфейсы (API) резервного копирования, не прерывающие обычных операций;
обеспечивает точную посекторную запись и обнаружение обрывов в записи.
Система CLFS оптимизирована для повышения производительности. Все операции записи в журнал буферизируются до тех пор, пока не появится возможность произвести их совместно с другими клиентами либо буфер не переполнится, либо не будет очищен принудительно. Данные журнала выгружаются из буфера непосредственно на жесткий диск без копирования. Различные потоки данных могут быть записаны в ходе одной операции ввода-вывода, что позволяет осуществить поиск по диску лишь однажды — вместо обычного выполнения нескольких операций чтения и записи. В случае резкого увеличения активности чтения, как и в ходе нормального использования, операции чтения кешируются для снижения количества обращений к диску.
Защита файлов Windows
Одна из форм незаметного повреждения данных связана с перезаписью критических системных файлов при установке приложений. Предоставленная вместе с приложением копия файла берется с платформы, которая использовалась для компиляции приложения. Нет никакой гарантии, что на этой платформе использовались те же двоичные файлы, что и на сервере.
Практически все системные администраторы имели опыт работы с приложениями, которые пытаются играть в опасные игры с системными службами. Сервер работает месяц за месяцем, и вдруг после установки безобидного приложения выдается синий экран критической ошибки.
Защита системных файлов от повреждения возложена на службу загциты файлов Windoms (Windows File Protection — WFP). Служба сравнивает цифровую подпись критически важных системных файлов с каталогом подписей, который предоставлен вместе с оригинальны-' ми системными файлами.
Если приложение заменит один из системных файлов, служба защиты файлов Windows сравнит цифровую подпись файла с записью в каталоге. Если сравнение подписей для нового файла даст положительный результат, служба защиты файлов Windows сохранит этот новый файл. (Это происходит, если пакет приложения создавался под управлением той же операционной системы и той же версии пакета обновлений, что и операционная система на сервере.)
Если цифровая подпись не совпадает (т.е. отсутствует в каталоге) или замененный файл вообще не имеет подписи, служба защиты файлов Windows извлекает оригинальную версию файла из папки кэша и перезаписывает оригинальную версию поверх новой версии файла. У ведомление о предпринятых действиях записывается в журнал изменений.•
Выполняемые файлы, для которых компанией Microsoft создаются цифровые подписи, распространяются в составе следующих приложений.
Пакеты обновлений, запускаемые с помощью Update. ехе
Исправления (hotfix), запускаемые с помощью Hotfix.exe
Обновления операционной системы, запускаемые с помощью winnt 3 2 . ехе
Служба Windows Update
Диспетчер устройств/Установщик классов ( Device Manager/Class Installer)
Одновременно с пакетом обновлений в системе устанавливается еще один файл каталога. Подкаталоги хранятся в каталоге \Windows\System32\Catroot. Новый каталог получает имя SP#. CAT, где # — номер пакета обновлений.
Служба защиты файлов Windows хранит копии контролируемых файлов в сжатом каталоге \windows\System32XDllCache. В этом каталоге хранится копия каждого файла, установленного с компакт-диска операционной системы Windows Server 2003. Если один из этих файлов обновляется с использованием четырех разрешенных методов, кэшированный файл заменяется обновленной версией.
Описание работы службы WFP
Проверка работы службы защиты файлов Windows (WFP) рассматривается в процедуре 15.3.
Процедура 15.3. Проверка работы службы WFP
Откройте Explorer (Проводник) и перейдите в каталог \Windows\System32. Если Explorer поддерживает просмотр каталогов в виде Web-папок, будет выдан запрос на подтверждение доступа к папкам \Windows и \Windows\System32. Это подсказывает, что каталоги защищены службой защиты файлов Windows.
Прокрутите список файлов и найдите один из файлов, установленных вместе с операционной системой.
Щелкните правой кнопкой мыши на пиктограмме файла и выберите из контекстного меню команду Delete (Удалить). Щелкните на кнопке Yes (Да) для подтверждения удаления.
Некоторое время ничего не делайте. Ждите и наблюдайте. Через несколько секунд пиктограмма файла появится на старом месте. Это значит, что служба защиты файлов Windows работает.
Элементы службы WFP
Служба защиты файлов Windows не работает в виде отдельного процесса. Это одна из функций ядра операционной системы. Для управления службой можно воспользоваться записями системного реестра в разделе HKLMXSof twareXMicrosof tXWindows NTXCurrent versionXwinlogon. Для управления службой защиты файлов Windows доступны следующие записи.
SFCQuota. Объем дискового пространства, выделенного для хранения каталога DlICache. По умолчанию используется значение FFFFFFFF, которое выделяет для хранения каталога практически неограниченный объем величиной 4 Гбайт. Тот же эффект дает значение -1.
SFCDisable. Если установить для этой записи значение 1, защита системных файлов будет отключена при следующей перезагрузке. После еще одной перезагрузки служба защиты файлов включится автоматически. Этот параметр можно использовать для замены файлов версиями, одобренными производителем системы, или для установки специальных версий файлов, предназначенных для отладки.
■ SFCBugCheck. В обычных условиях при попытке замены или удаления защищенного файла система выдает предупреждение на локальную консоль. Если установить для этой записи значение 1, система останавливает работу и выдает синий экран с сообщением об ошибке. Этот параметр можно установить на рабочей станции, пользователь которой время от времени старается заменить системные файлы..
■ SFCScan. Заставляет службу WFP просматривать папку DllCache во время загрузки и находить отсутствующие файлы. Значение 1 заставляет службу сканировать файлы при каждой загрузке. Значение 2 заставляет службу провести однократное сканирование.
Использование сканера системных файлов SFC
Для изменения параметров службы WFP необязательно “копаться” в системном реестре. Для этих целей в операционной системе Windows Server 2003 предоставляется утилита, запускающаяся из командной строки. Утилита называется System File Checker (SFC) и может использоваться для восстановления каталога DllCache при случайном удалении файлов. Параметры утилиты SFC рассматриваются в следующих разделах.
sfc /scanon.ce !
Этот параметр заставляет службу просканировать папку DllCache и проверить соответствие подписей файлов сигнатурам в каталоге. После этого выполняется сканирование файлов в защищенных каталогах. Это сканирование начинается после завершения регистрации.
Во время сканирования на консоли выдается сообщение с предложением подождать окончания сканирования. В это время можно запускать другие приложения и выполнять другие задачи, но это замедляет сканирование. Если система находит в кэше отсутствующий файл или системный файл с неправильной версией, выдается запрос на предоставление установочного компакт-диска Windows Server 2003, что позволит восстановить правильную версию файла.
Если операционная система Windows Server 2003 устанавливалась по сети или из каталога 13 86 на локальном жестком диске, компакт-диск все равно потребуется для восстановления защищенных файлов. Если на компьютере привод компакт-дисков не установлен, единственным решением является сравнение содержимого папки DllCache с такой же папкой на другом компьютере и копирование отсутствующих файлов вручную.
sfc /scanboot
Этот параметр позволяет включать проверку защищенных файлов при каждой загрузке. На серверах, управляемых профессиональными администраторами, сканирование при загрузке требуется крайне редко. С другой стороны, рабочие станции требуют более тщательного контроля.
Параметр / scanboot стоит использовать на компьютерах тех пользователей, которые постоянно удаляют кэшированные файлы, чтобы заставить этих пользователей самостоятельно пройти процесс исправления внесенных изменений. Кроме этого, в системном реестре можно установить параметр SFCBugCheck, который заставит компьютер выдавать синий экран с сообщением об ошибке, если пользователь пытается продолжить эксперименты с защищенными файлами.-
sfc /quiet
Использование этого параметра приводит к замене отсутствующих файлов без дополнительного запроса.
sfc /cancel
Этот параметр позволяет отменить сканирование во время следующей загрузки.
Особенности службы WFP
Повторим ключевые моменты, связанные с работой службы защиты файлов Windows.
Служба WFP защищает системные файлы, установленные вместе с операционной системой.
Служба защиты файлов Windows разрешает модификацию системных файлов только небольшому количеству доверенных выполняемых файлов.
Удаленные или поврежденные системные файлы заменяются правильными версиями из специального кэша на диске.
Утилита s f с позволяет вручную запустить сканирование и исправление системных файлов.
Квоты
В составе операционной системы Windows 2000 предоставлялась файловая система с одной возможностью, которую администраторы ждали очень долго: возможностью ограничивать выделенное пользователю дисковое пространство на основе заданных администратором правил. Другими словами, была предоставлена возможность настройки квот.
К сожалению, первая попытка управления квотами от компании Microsoft оставляла желать лучшего. Система управления квотами имела несколько фундаментальных недостатков.
Во-первых, использование дискового пространства рассчитывалось по размеру файлов, владельцем которых был тот или иной пользователь. Это являлось проблемой, и вот почему. Часто бывает, что один пользователь создает набор файлов, которые другие пользователи заполняют данными. Один из примеров — юридические документы. Такими же примерами являются графические файлы или компьютерные публикации. Система квот на основе владения файлами указывала на создателя файлов, а не на пользователей, которые заполняли файлы данными.
Во-вторых, система отслеживала использование дискового пространства на основе томов, а не отдельных папок. Это усложняло управление большим файловым сервером с несколькими совместно используемыми точками доступа для одного массива. “Я получил сообщение «Диск полон» для своего диска К, поэтому я решил сохранить данные на диске М, но он тоже оказался полным”
В-третьих, система квот не имела интерфейса управления на уровне предприятия. Консоль управления квотами поддерживала копирование отдельных параметров квот между томами, но централизованного инструмента для управления квотами в пределах всей системы с хранением параметров в базе данных Active Directory не было.
Автор с огромным удовольствием написал бы, что компания Microsoft исправила все эти недостатки с выходом операционной системы Windows Server 2003. Но, к сожалению, это не так. Вместо потери времени на управление квотами средствами операционной системы Windows Server 2003 автор рекомендует применять несколько продуктов управления ресурсами хранилищ от сторонних производителей. Эти продукты позволяют более эффективно управлять дисковым пространством.
StorageCentral SRM от компании Precise Software, www.precise.com. Это ведущий продукт для управления квотами в операционной системе Windows. Он поддерживает определение параметров квот для пользователей и групп, позволяет устанавливать ограничения по типам файлов, а также предоставляет большое количество отчетов.
Quota Server от компании Northern Software, www.northernparklife.com. Этот продукт имеет более функциональный пользовательский интерфейс, но он сложнее в использовании в пределах предприятия, чем программа Wquinn.
Quota and File Sentinel от компании NTP Software, www.ntpsoftware.com. Интерфейс этого продукта сложнее в использовании и управлении.
Эти программы стоят достаточно дорого, но, если сравнить их со стоимостью покупки, установки и резервного копирования хранилища большего объема, они могут обеспечить более эффективное использование средств. -
Консоль File Server Management (Управление файловым сервером)
В версии Windows Server 2003 R2 предоставляется единая консоль для управления работой файлового сервера, которая сочетает в себе возможности, предоставляемые ранее отдельно Shared Folders, Disk Defragmenter и Disk Management. Вы можете использовать File Server Management для выполнения ряда таких задач, как форматирование и дефрагментация томов, создание общих ресурсов и управление ими, установка квот, создание отчетов об использовании хранилища, репликация данных с файлового сервера и на него, управление Storage Area Networks (SANs) и выделение файлов для общего доступа систем UNIX и Macintosh.
Управление ресурсами файлового сервера
Спрос на ресурсы хранилищ данных увеличивается, так как сейчас организации зависят от информации более сильно, чем когда-либо, и системные администраторы сталкиваются с требованием обслуживать все более и более объемные и сложные системы хранилищ и в то же время отслеживать содержащиеся в них различные типы информации.
Новая оснастка операционной системы Windows Server 2003 R2 — оснастка File Server Resource Manager (Управление ресурсами файлового сервера) — предоставляет администраторам комплект инструментов для отслеживания и контроля количества и типов информации, хранящейся на серверах, а также для управления ею. Используя File Server Resource Manager, администраторы могут задавать квоты на папки и тома, оперативно классифицировать и отбирать файлы и получать исчерпывающие отчеты о хранилище.
Функции FSRM представляют собой набор средств, которые помогают администраторам управлять квотами по томам или по каталогам. Реализовано два дополнительных приложения, которые загружаются при запуске FSRM — Storage Resource Management и Scheduled Storage Tasks. Первое приложение используется для создания квот и файловых списков для блокировки использования определенных типов файлов, а второе — для планирования отчетов о хранении данных в автоматическом режиме и по запросу.
В R2 квоты могут быть жесткими и мягкими. В случае жесткой квоты пользователи не могут сохранять документы, если предел квоты ресурса хранения достигнут. В случае мягкой квоты администратор получает предупреждение о том, что предел достигнут, но пользователям разрешается добавление файлов к ресурсам. Предусмотрены также разные настройки, с помощью которых можно информировать администратора о достижении определенного процента квоты. Это дает администратору время для увеличения объема хранения или извещения пользователя о невозможности увеличения объема.
Можно устанавливать квоты автоматически, т.е. установить шаблон квоты на главную папку; тогда каждая папка внутри первой сможет использовать этот" шаблон. Такая возможность особенно полезна в домашних каталогах и в других ситуациях, когда создается много одинаковых квот. .
Квоты R2 поддерживают несколько механизмов отчетов, которые, безусловно, лучше сценария по умолчанию, реализованного в прежних версиях, когда проблемы дисковых квот становились очевидными только после заполнения диска. В выпуске R2 сообщения о проблемах с дисковыми квотами отправляются администратору заранее, поэтому можно автоматически отправлять пользователю по почте сообщения с предупреждением об исчерпании дисковых
квот. В выпуске R2 поддерживается широкий спектр типов сообщений, в том числе ряд простых заранее настроенных сообщений. Можно отсылать и специальные сообщения, которые используются внутри компании. Заранее настроенные сообщения показывают самые большие файлы, наиболее давно и недавно использованные файлы, файлы по владельцам и по группам и т.д. Специальные сообщения могут генерироваться для охвата многих томов, папок и общих ресурсов. Сообщения могут использовать форматы DHTML или HTML, XML, CSV (comma separated values) или текстовые. Они могут запускаться по мере необходимости или 'регулярно.
Еще есть квоты хранения, которые поддерживают проверку файлов; они определяют, какие типы файлов пользователи могут сохранять в данной папке. Эта функция проверки файлов может использоваться для усиления корпоративной политики. Для современных систем Windows Server фирмы могут накладывать ограничения на хранение определенных типов файлов, например файлов MP3 и других, либо могут разрешать пользователям сохранять выполняемые файлы или только определенные типы файлов (документы Word и т.д.), но тогда им придется вручную искать файлы неразрешенных типов и только после этого предпринимать какие-то шаги. С новой функциональностью проверки файлов администраторы могут создавать шаблоны, которые задают разрешенные и неразрешенные типы файлов.
В версии R2 поддерживаются два типа проверки файлов — активный и пассивный. При активной проверке пользователям не разрешается сохранять заблокированные типы файлов. В случае попытки это сделать администратору отправляется предупреждение. При пассивной проверке пользователям разрешают хранить заблокированные типы файлов, однако вместе с тем отправляются сообщения о таких событиях администратору. Проверка типов файлов реализована хорошо, хотя при попытке сохранить заблокированный тип файла пользователь увидит только стандартное диалоговое окно с сообщением о том, что доступ к файлу запрещен.
Квоты File Server Resource Manager (Управление ресурсами файлового сервера) в сравнении с дисковыми квотами NTFS
В следующей таблице отражены преимущества инструмента управления квотами File Server Resource Manager.
Функция квоты
File Server Resource Manager (Управление ресурсами файлового сервера)
Дисковые квоты NTFS
Отслеживание квоты
По папкам или по томам
По пользователю относительно всего тома
Оценка загрузки диска
Фактическое дисковое пространство
Логический размер файлов
Механизмы уведомления
Электронная почта, настраиваемый отчет, выполнение команд журналы событий
Только журналы событий
Работа файловой системы
Теоретические описания завершены. Теперь пришло время заняться настоящей работой. В следующих нескольких разделах рассматриваются такие темы.
Сжатие файлов
Точки функционального монтирования
Дефрагментация
Преобразование в файловую систему NTFS
Запись на диски CD-R/RW и DVD-RAM
Операции при сжатии файлов
Не существует элементов управления пользовательского интерфейса или параметров в системном реестре, позволяющих изменить механизм сжатия файлов. Единственный доступный параметр позволяет включить или отключить сжатие. Для этого можно использовать Explorer (Проводник) или утилиту compact, запускающуюся из командной строки. В процедуре 15.4 описано, как выполнить сжатие с помощью Explorer (Проводник).
Процедура 15.4. Выполнение сжатия
Откройте Explorer (Проводник) и перейдите к файлу (или папке), который необходимо сжать.
Щелкните правой кнопкой мыши на пиктограмме нужного элемента и выберите из контекстного меню команду Properties (Свойства). Откроется окно Properties (Свойства), которое показано на рис. 15.17.
Рис. 15.17. Окно Properties (Свойства) для большого несжатого файла
В поле Attributes (Атрибуты) щелкните на кнопке Advanced (Другие). Откроется окно Advanced Attributes (Дополнительные атрибуты). В этом окне можно управлять несколькими флагами атрибутов в записи МЕТ. Дополнительная информация приводится во врезке “Использование дополнительных атрибутов файлов”.
Использование дополнительных атрибутов файлов
В окне Advanced Attributes (Дополнительные атрибуты) для файла или папки (рис. 15.18) доступно несколько флажков, которые управляют способом хранения файла. Рассмотрим эти флажки.
Рис. 15.18. В окне Advanced Attributes (Дополнительные атрибуты) отображается состояние таких атрибутов файла, как сжатие и шифрование
Флаг Archive (Архивный) сохранился еще со времен операционных систем Windows NT и DOS. Этот флаг указывает, что файл изменился, но не был архивирован.
Флаг Index появился в операционной системе Windows Server 2003 и указывает, что служба индексирования содержимого должна просканировать файл. Изначально служба являлась надстройкой над Internet Information Services, но теперь она включена в состав операционной системы. К счастью, по умолчанию эта служба отключена.
Атрибут Compress (Сжимать) заставляет систему сжимать файл.
Атрибут Encrypt (Шифровать) заставляет систему шифровать файл.
Атрибуты Compress (Сжимать) и Encrypt (Шифровать) являются взаимоисключающими. На то существуют две причины.
В зашифрованных файлах очень мало повторяющихся символов, поэтому, с точки зрения компании Microsoft, зашифрованные файлы являются неудачными кандидатами на сжатие.
Система не может восстановить сжатый зашифрованный файл с магнитной ленты. Процесс восстанавливает сжатый файл с ленты, выполняя чтение заголовка сжатого файла с ленты, чтобы найти начальный кластер, в котором находился файл во время резервного копирования. Однако процесс восстановления (Restore) работает с правами учетной записи Backup Operator (Оператор архива) и не имеет прав на чтение шифрованного файла для определения начального кластера.
Установите флажок Compress Contents to Save Space (Сжимать содержимое для экономии места на диске) и щелкните на кнопке ОК, чтобы сохранить изменения и закрыть окно.
Щелкните на кнопке ОК, чтобы сохранить изменения и закрыть окно Properties (Свойства). Время сжатия зависит от размера файла.
Закройте окно Properties (Свойства) и откройте его повторно. Значение Size on Disk (Размер на диске) будет соответствовать размеру файла после сжатия.
Если при сжатии и распаковке файлов отдается предпочтение утилитам с интерфейсом командной строки, можно воспользоваться утилитой compact. Для выполнения сжатия воспользуйтесь командой compact /с. Для сброса флага сжатия примените команду compact /и.
Если необходимо установить флаг сжатия для каталога с последующим сжатием всех файлов внутри каталога и его подкаталогов, введите команду compact /с /s.
Для просмотра файлов и информации о степени их сжатия введите команду compact без аргументов. Например, рассмотрим список сжатых стандартных файлов с расширением . bmp, которые предоставляются в составе операционной системы Windows Server 2003:
С:\TestDir\>compact
Listing C:\TestDir\
New files added to this directory will not be compressed.
1272 :17062 :16730 :17336 :1272 :17062 :16730 :17336 :10241706215872133121024170621587213312.2 to 1 C Blue Lace 16.bmp
1272 :
17062 :
16730 :
17336 :
1272 :
17062 :
16730 :
17336 :
1024
17062
15872
13312
1024
17062
15872
13312
.0 to 1 C Coffee Bean.bmp
to 1 C FeatherTexture.bmp
to 1 C Gone Fishing.bmp
Of 4 files within 1 directories
4 are compressed and 0 are not compressed.
46310 total bytes of data are stored in 32430 bytes.
The compression ratio is 1.2 to 1&
Работа точек функционального монтирования
Для создания точек функционального монтирования (reparse point), или просто точек монтирования (mount point), можно воспользоваться консолью Disk Management (Управление дисками) или утилитой linkd, запускающейся из командной строки. После этого для управления точкой функционального монтирования можно применять утилиту Fsutil.
Консоль Disk Management (Управление дисками) позволяет монтировать только всю файловую систему. Утилита linkd позволяет выбрать для монтирования определенный каталог. Монтирование сетевого диска или устройства с использованием имени UNC не поддерживается.
Создание точки монтирования средствами консоли
Disk Management (Управление дисками)
В процедуре 15.5 рассматривается использование консоли Disk Management (Управление дисками) для создания точки монтирования для другого тома.
Процедура 15.5. Создание точки монтирования средствами консоли Disk Management (Управление дисками)
Создайте пустой каталог в томе NTFS. Этот каталог будет выступать в роли точки монтирования. Каталог может находиться в любом другом каталоге. Если в каталоге находятся файлы или другие подкаталоги, его нельзя использовать в качестве точки монтирования.
Откройте консоль Computer Management (Управление компьютером) с помощью команды Start^Programs^Administrative Tools^Computer Management (Пуск^Программы^ Администрирование1^ Управление компьютером).
Откройте раздел Storage^Disk Management (Запоминающие устройства^Управление дисками).
Щелкните правой кнопкой мыши на пиктограмме привода компакт-дисков и выберите из контекстного меню команду Change Drive Letter and Path (Изменить букву диска или путь к диску). Откроется окно Change Drive Letter and Path (Изменить букву диска или путь к диску), которое показано на рис. 15.19.
khange Drive letter and Paths for E: (FAT32)khange Drive letter and Paths for E: (FAT32)Рис. 15.19. Окно Change Drive Letter and Path (Изменить букву диска или путь к диску)Рис. 15.19. Окно Change Drive Letter and Path (Изменить букву диска или путь к диску)
khange Drive letter and Paths for E: (FAT32)
khange Drive letter and Paths for E: (FAT32)
Рис. 15.19. Окно Change Drive Letter and Path (Изменить букву диска или путь к диску)
Рис. 15.19. Окно Change Drive Letter and Path (Изменить букву диска или путь к диску)
Щелкните на кнопке Add (Добавить). Откроется окно Add New Drive Letter or Path (Добавление буквы диска или пути).
Выберите переключатель Mount This Volume at an Empty Folder Which Supports Drive Paths (Подключить том как пустую NTFS-папку) и щелкните на кнопке Browse (Обзор). Откроется окно Browse for Drive Path (Поиск пути к диску).
Перейдите в том NTFS, который содержит созданный каталог для точки монтирования. Кроме этого, можно щелкнуть на кнопке New Folder (Создать) и создать папку в любом томе NTFS. Допускается использование длинного имени папки.
Щелкните на кнопке ОК для выбора новой папки и закрытия окна.
В окне Add New Drive Letter and Path (Добавление буквы диска или пути) щелкните на кнопке ОК, чтобы смонтировать диск. Монтирование одного тома к другому никак не отображается на консоли Disk Management (Управление дисками).
Создание точки монтирования средствами утилиты linkd
Нормальный процесс монтирования тома, описанный в предыдущем разделе, позволяет монтировать к папке только целый каталог. В составе Windows Server 2003 Resource Kit предоставляется утилита linkd, которая поддерживает монтирование папки к другой, пустой, папке или монтирование целого тома. Утилита 1 inkd использует следующий синтаксис: linkd <пустая_папка> <исходная_папка>
Например, для монтирования папки С: \Windows к папке D: \test (пустая папка) введите следующую команду:
linkd d:\test c:\Windows
Утилита 1 inkd не поддерживает монтирование папки на сетевом диске. Удаление папки приводит к удалению только ссылки. Пиктограмма папки не содержит специальной пиктограммы монтирования, которая отображается при обычном монтировании тома.
Управление точками функционального монтирования с помощью утилиты Fsutil
Консоль Fsutil предоставляет пространство имен точек функционального монтирования для управления точками монтирования и другими точками соединения каталогов. Например, для проверки содержимого точки функционального монтирования в записи точки монтирования введите команду fsutil reparsepoint query <имя>. Ниже приведен пример результата выполнения этой команды:
C:\>fsutil reparsepoint query mountpointname
Reparse Tag Value: ОхаООООООЗ
Tag value: Microsoft
Tag value: Name Surrogate
Tag value: Mount Point
QUID: {000E0000-0010-0006-5C00-3F003F005C00}
Data Length: 0x00000020
Reparse Data:
0000: 48 00 3a 00 5c 00 00 00 58 00 3a 00 5c 00 00 00 H.:.\...H.:.\... 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
С помощью утилиты Fsutil можно удалить точку функционального монтирования без удаления находящихся за ней файлов. Введите команду fsutil reparsepoint delete <имя>. К сожалению, утилита Fsutil не предоставляет команды для создания точек функционального монтирования. Для этого придется использовать утилиту linkd из состава Resource Kit.
Операции дефрагментации
Существует два способа запустить дефрагментацию тома. Можно воспользоваться консолью с графическим интерфейсом, Dfrg.msc, или утилитой для командной строки, defray. Оба интерфейса запускают один и тот же код, поэтому выбор стоит делать исключительно из соображений удобства. Одним из преимуществ утилиты с интерфейсом командной строки является возможность планирования запуска утилиты с помощью Task Scheduler (Планировщик заданий).
В этом разделе рассматриваются процедуры для очистки диска перед дефрагментацией, дефрагментация тома с помощью графической консоли и планирование дефрагментации из командной строки.
Очистка тома перед дефрагментацией
Пользовались ли вы услугами домработницы? Что обычно приходится делать перед приходом домработницы? Правильно, заниматься уборкой. В конце концов, кто хочет, чтобы незнакомый человек считал вас неряхой? Это правило относится и к подготовке диска к дефрагментации. Нет смысла оставлять на диске множество бесполезных файлов, которые будут зря занимать время утилиты дефрагментации. Поэтому выполните две операции до начала дефрагментации.
■ Запустите утилиту chkdsk (chkdsk /f) для каждого тома, который планируется деф- рагментировать. Если это потребует перезагрузки для запуска утилиты autochk, сделай- тё это. Автор этой книги сталкивался с ситуациями, когда после успешного завершения работы утилиты chkdsk система аварийно завершала работу во время дефрагментации.
■ Удалите ненужные файлы. В операционной системе Windows Server 2003 для этих целей существует утилита Disk Cleanup (Очистка диска). Утилита предоставляется в виде отдельного выполняемого файла, Clnmgr. ехе. Утилита Disk Cleanup (Очистка диска) сканирует жесткий диск и находит устаревшие каталоги индексации, временные файлы Интернет, временные и устаревшие автономные файлы, загруженные аплеты Java и ActiveX, а также содержимое Корзины, которое можно безболезненно удалить.
Утилита Disk Cleanup (Очистка диска) позволяет быстро и эффективно удалить ненужные файлы. Использование утилиты рассматривается в процедуре 15.6.
Процедура 15.6. Использование утилиты Disk Cleanup (Очистка диска)
Запустите утилиту Disk Cleanup (Очистка диска), выбрав Start^Programs^ Accessories^ Disk Cleanup (Пуск^Программы^Стандартные^Системные^Очистка диска). Откроется окно Disk Cleanup (Очистка диска).
Выберите букву диска для тома, который должен быть очищен. Утилита ищет файлы, которые можно удалить. Если диск содержит точку монтирования, поиск выполняется и в примонтированном томе. После завершения поиска утилита Disk Cleanup (Очистка диска) предоставляет результаты в виде списка вариантов (рис. 15.20).
Удалив содержимое каталога Temporary Internet files (Временные файлы Интернет), вы не удалите файлы “cookie”. Удаляются только кэшированные Web-страницы, что приведет к некоторой задержке при доступе к сайтам в следующий раз, когда будет запущен Internet Explorer.
Удаление содержимого каталога Temporary Off-Line Files (Временные автономные файлы) допустимо, даже если пользователь отключен от сети и не синхронизировал файлы. Утилита Disk Cleanup (Очистка диска) удаляет только те файлы, которые синхронизированы с источником.
Рис. 15.20. Окно Disk Cleanup (Очистка диска) и список вариантов удаления
Установите флажки для выбранных пунктов списка и щелкните на кнопке ОК, чтобы удалить файлы. После завершения работы утилиты Disk Cleanup (Очистка диска) окно закрывается без участия пользователя.
Дефрагментация тома NTFS с помощью консоли ММС
Консоль Disk Defragmenter (Дефрагментация диска) можно открыть несколькими способами.
Непосредственно из меню Start (Пуск). Воспользуйтесь командой Start^Programs^Ac- cessories^System Tools^Disk Defragmenter (Пуск^Программы^Стандартные^Служеб- ныес>Дефрагментация диска).
Из консоли Computer Management (Управление компьютером). Разскройте раздел Storage^ Disk Defragmenter (Запоминающие устройства ^Дефрагментация диска).
Из окна Explorer (Проводник) или окна Му Computer (Мой компьютер). Щелкните на пиктограмме диска правой кнопкой мыши, выберите команду Properties (Свойства), а затем Tools ^Defragment Now (Сервис^Дефрагментировать).
Из окна Run (Выполнить). С помощью команды df rg. msc.
Открыв консоль Disk Defragmenter (Дефрагментация диска), можно запустить анализ фрагментированности тома или сразу дефрагментацию. Начинайте с анализа (процедура 15.7). Не удивляйтесь, когда увидите, что множество файлов разбросаны по всему тому, а в результатах анализа указывается, что дефрагментация не требуется. Том NTFS считается фрагмен- тированным только в случае разделения нерезидентных атрибутов данных по разным цепочкам кластеров. Автоматическая подстройка системы переместит часто используемые файлы в стратегические позиции на диске автоматически.
Процедура 15.7. Анализ фрагментации тома
Выделите том и щелкните на кнопке Analyze (Анализ). Система просмотрит фрагментированные файлы и создаст отчет в графической и текстовой форме (рис. 15.21).
Рис. 15.21. Окно Disk Defragmenter (Дефрагментация диска), в котором показаны результаты анализа фрагментации
Щелкните на кнопке View Report (Отчет). В отчете предоставляются сведения о статистике использования тома, фрагментации тома, фрагментации файлов, фрагментации файла подкачки, фрагментации каталогов и фрагментации таблицы MFT. Из этого списка утилита может исправлять только фрагментацию файлов и каталогов. Практически все узлы системного реестра будут находиться на вершине списка фрагментации.
Щелкните на кнопке Defragment (Дефрагментировать). Это можно сделать в окне Report (Отчет) или в основном окне консоли. Система проведет еще один анализ и начнет дефрагментацию. Дефрагментация тома большого объема с большим количеством фрагментированных файлов может занять несколько часов. Дефрагментацию тома на сервере стоит проводить после завершения рабочего дня. Проблема не только в снижении производительности в процессе дефрагментации, но и в блокировании пользовательских файлов, которые не будут дефрагментированы. Время дефрагментации зависит от производительности подсистемы ввода-вывода, мощности центрального процессора и пропускной способности системной шины.
После завершения дефрагментации утилита Disk Defragmenter (Дефрагментация диска) проведет еще один анализ фрагментации и выдаст результаты в новом отчете. Если том значительно фрагментирован, может потребоваться многократная дефрагментация.
Дефрагментация средствами утилиты defrag
В операционной системе Windows Server 2003 исправлен недостаток системы дефрагментации Windows: в состав операционной системы включена версия утилиты дефрагментации, которая запускается из командной строки и поддерживает составление расписания дефрагментации с помощью Task Manager (Планировщик заданий). Параметр -а позволяет запустить утилиту в режиме анализа, а параметр -v заставляет утилиту выдавать на экран более подробную информацию. Рассмотрим отчет этой утилиты для русскоязычной версии Windows ХР.
C:\Documents and Settings\AflMHHHCTpaTop>defrag с: -a -v
Программа дефрагментации дисков Windows
(С) Корпорации Майкрософт и Executive Software International,
^ Inc., 2003.
Отчет об анализе
Размер тома
Размер кластера
Занято
Свободно
Процент свободного места
= 2,00 ГБ
= 2 КБ
= 1,68 ГБ
= 327 МБ
= 15 %
Фрагментация тома
Всего фрагментировано
= 13 %
Фрагментация файлов
= 27 %
Фрагментация свободного места
= 0 %
Фрагментация файлов
Всего файлов
= 12 390
Средний размер файла
= 157 КБ
Всего фрагментировано файлов
= 1 614
Всего лишних фрагментов
= 4 389
В среднем фрагментов на файл
= 1,35
Фрагментация файла подкачки
_ Размер файла подкачки
= 192 МБ
, Всего фрагментов
= 499
Фрагментация папок
Всего папок
= 1 105
Фрагментировано папок
= 51
Лишних фрагментов папок
= 626
Фрагментация МЕТ (Master File Table)
Общий размер MET
= 13 МБ
Счетчик записей МЕТ
= 13 522
Процент использования МЕТ
= 99
Всего фрагментов МЕТ
= 2
Необходимо выполнить дефрагментацию этого тома.
Если на диске меньше 15% свободного пространства, утилита defrag выдаст сообщение об ошибке и откажется выполнить дефрагментацию. Механизм дефрагментации можно заставить использовать ■ буферную зону таблицы МЕТ (с помощью параметра -f). При этом дефрагментация будет проходить немного медленнее, но должна завершиться успешно.
Операции по преобразованию файловой системы в формат NTFS
Несмотря на все механизмы защиты, встроенные в программу преобразования, существует вероятность повреждения файловой системы, поэтому перед преобразованием файловой системы в NTFS создайте резервную копию данных.
На консоли Disk Management (Управление дисками) не предоставляется возможности преобразования. Преобразование запускается с помощью утилиты convert из командной строки. Команда имеет следующий синтаксис: convert имя_тома /fs:ntfs
В качестве объекта преобразования можно указать имя тома, букву диска или точку монтирования. Если указать букву диска, будет выдан запрос на ввод имени тома, чтобы убедиться, что выбран правильный том. Чтобы проверить имя нужного тома, введите команду vol.
Принятый по умолчанию размер кластера 512 байт обеспечивает наиболее эффективное использование дискового пространства во время преобразования. Изменить размер кластера без форматирования файловой системы невозможно.
Для преобразования система должна установить эксклюзивную блокировку на все файлы. Если система не может получить эксклюзивный доступ, выдается запрос на преобразование файловой системы при следующей перезагрузке. Если щелкнуть на кнопке Yes (Да), в системном реестре будет создана следующая запись:
I
Раздел:HKLM\System\CurrentControlSet\Control\SessionManager
Запись: BootExecute ■
Значение: autochk autoconv \??\с: /FS:ntfs
Фрагмент \ ? ? \с: является символьной ссылкой в пространстве имен объектов Windows Server 2003, которая соответствует тому. Если будет принято решение об отмене преобразования, удалите ключевое слово autoconv и все параметры до конца строки из записи BootExecute.
Операции с дисками CD-RW и DVD-RAM
Есть один секрет, который позволит сделать приятным использование возможностей записи компакт-дисков в операционной системе Windows Server 2003 или Windows ХР. Для этого нужно постоянно повторять себе “Это не машина для копирования компакт-дисков. Это не машина для копирования компакт-дисков”..
Смысл этой мантры заключается в том, что, хотя компания Microsoft и лицензировала программный код у компании Roxio (производитель Easy CD Creator), в лицензированный код не включен механизм пакетной записи, который позволяет копировать компакт-диски. В операционных системах Windows Server 2003 и Windows ХР для структурирования содержимого используется стандартная файловая система ISO9660/Joliet, а значит, операционная система рассматривает компакт-диск как стандартное хранилище файлов.
Если необходимы возможности механизма пакетной записи компакт-дисков, обратите внимание на несколько продуктов от сторонних производителей. Для нормальной работы под управлением операционной системы Windows Server 2003 обратите внимание на последние версии продуктов следующих компаний:
■ Roxio (www. roxio. com). Флагманский продукт этой компании называется Easy CD Creator Platinum. (Компания Roxio является подразделением компании Adaptec.)
■ Ahead Software (www. ahead. com). Компания выпускает пакет Nero CD Burner. Эта программа популярна как из-за своей цены (очень низкой), так и из-за возможности простого создания музыкальных компакт-дисков на базе набора файлов MP3. Кроме этого, продукт предоставляет расширенные возможности по созданию загрузочных компакт-дисков.
■ Golden Hawk Technologies (www. goldenhawk. com). Эта компания выпускает программу CDRWIN, который долго занимал нишу самой быстрой программы для записи компакт-дисков с минимальным набором возможностей. Документация и интерфейс оставляют место для улучшений, но программа справляется со своими задачами.
Если привод для записи дисков CD-R и CD-RW не полностью соответствует стандарту ММС2, придется использовать один из этих продуктов. Для проверки совместимости привода с операционной системой Windows Server 2003 обратите внимание на логотип “Ready for Windows ХР” или проверьте список совместимых аппаратных средств операционной системы Windows Server 2003.
Функциональное описание записи компакт-дисков
Для копирования файлов на диск CD-R или CD-RW перетащите пиктограммы файлов в Explorer (Проводник) на пиктограмму привода и отпустите кнопку мыши. Файлы будут скопированы во временный каталог. Из этого каталога файлы могут быть записаны на компакт- диск. Существует несколько способов запуска процедуры записи.
Щелкните правой кнопкой мыши на пиктограмме диска в окне Му Computer (Мой компьютер) и выберите из контекстного меню команду Write These Files to CD (Записать файлы на компакт-диск).
Выполните двойной щелчок на пиктограмме привода для просмотра файлов, которые уже находятся на диске или хранятся во временном каталоге для последующей записи. В группе CD Writing Tasks (Задачи записи компакт-дисков) на боковой панели выберите пункт Write These Files То CD (Записать файлы на компакт-диск). Если боковая панель недоступна, воспользуйтесь командой Tools^Folder Options (Сервис1* Свойства папки) и установите флажок Show Common Tasks In Folders (Показывать общие задачи в папках).
Извлеките компакт-диск из привода, воспользовавшись кнопкой на приводе или пунктом контекстного меню для пиктограммы привода компакт-дисков. Запустится мастер, который предложит записать файлы на компакт-диск, сохранить файлы во временном каталоге или отказаться от записи файлов и удалить временный каталог.
Roxio DirectCD
Компания Roxio предлагает программу DirectCD, который поддерживает непосредственную запись файлов на диски CD-R, CD-RW и DVD-RAM. Обычно в таком случае диск форматируется с использованием специального формата, поддерживающего сжатие файлов. Чтение такого диска поддерживает только драйвер Roxio. Программа позволяет выбрать стандартный формат диска, который не поддерживает сжатие файлов.
Промежуточное сохранение файлов во временном каталоге необходимо для плавного копирования данных на компакт-диск. Это позволяет избежать ситуации опустошения буфера (buffer underrun), когда у привода заканчивается информация, которую нужно писать на поверхность диска. Любая остановка процесса превращает компакт-диск из хранилища данных в красивый кружочек для метания или украшения.
Современные приводы для записи дисков CD-R/RW имеют очень большие буфера, которые позволяют хранить в памяти практически все содержимое компакт-диска. Это избавляет от проблемы недогрузки буфера. В операционной системе Windows Server 2003 предполагается, что используется базовая модель привода, которая не поддерживает буферизацию. Отключить промежуточное копирование файлов невозможно.
По умолчанию временный каталог с файлами находится на диске С. Можно указать и другой том. Свободного дискового пространства должно быть достаточно для хранения всех файлов, которые поместятся на компакт-диске. Обычно это около 700 Мбайт для стандартного компакт-диска и 850 Мбайт для расширенного компакт-диска.
Пока файлы записываются на компакт-диск, стоит избегать запуска процессов, которые могут прервать поток данных и привести к истощению буфера привода.
Что касается совместного использования привода CD-RW в виде сетевого ресурса, то сетевое подключение обладает недостаточной производительностью для заполнения буфера привода, поэтому механизм записи компакт-дисков по сети недоступен. Но чтение компакт- дисков по сети возможно. (Кстати, в операционной системе Windows Server 2003 административный общий ресурс ($) для компакт-диска не создается, поэтому для тестирования общего доступа совместно используемый ресурс придется создавать отдельно.)
Поддержка дисков DVD-RAM
В операционных системах Windows Server 2003 и Windows ХР поддерживается чтение дисков DVD-RAM, отформатированных с помощью файловой системы Universal Disk Format (UDF) до версии 2.01, но запись дисков UDF не поддерживается.
В операционной системе Windows Server 2003 для дисков DVD-RAM поддерживается только файловая система FAT32. Файловая система NTFS не поддерживается.
Для записи файлов на устройство DVD-RAM их можно перетащить или воспользоваться утилитами с ору/хс ору из командной строки. Кроме этого, можно воспользоваться любым другим приложением, в котором используются стандартные вызовы Win32 API. Система рассматривает диск DVD-RAM как обычный, хотя и медленный, носитель с вращающимся шпинделем.
Запись файлов надиск DVD-RAM буферизируется как драйвером файловой системы, так и самим устройством. Если извлечь носитель из привода с помощью кнопки на корпусе или с помощью пункта контекстного меню, файловая система сбросит кэш в буфер привода перед освобождением устройства. Устройство запишет содержимое буфера на диск до отключения двигателя шпинделя. Время завершения операции зависит от объема информации в кэше и производительности привода.
Если для текущего привода DVD-RAM используются две буквы диска, это значит, что специальный драйвер от производителя комбинирует файловую систему FAT с файловой системой UDF. Операционная система Windows Server 2003 интерпретирует вывод такого драйвера как два интерфейса. Не стоит пытаться записывать файлы на одно из этих устройств. Для этого лучше воспользоваться программным обеспечением, предоставленным производителем. ■
Если необходимо программное обеспечение, поддерживающее запись дисков DVD-RAM в формате UDF, посетите сайт Software Architects по адресу www. softarch. com. Эта компания является передовым разработчиком продуктов для формата UDF и постоянно обеспечивает совместимость с различными платформами.
В следующей главе
На этом этапе развертывание серверов Windows Server 2003, хранилищ данных и файловых систем завершено и можно начинать обслуживание пользователей. Осталось настроить совместный доступ к ресурсам. Эта тема рассматривается в следующей главе.
16
Управление совместно используемыми ресурсами
г*
ервер является компьютером, предоставляющим- свои ресурсы для доступа по сети. Клиент является компьютером, который использует ресурсы сервера. Серверы отдают. Клиенты принимают. Настоящий симбиоз.
В этой главе рассматриваются сетевые службы и предоставление сетевых служб клиентам. В невероятно старой сетевой модели OSI рассматриваемые в этой главе службы находятся на уровне 7, уровне приложений. Службы можно классифицировать по следующим категориям:
службы совместного доступа к файлам, принтерам, факсам и рабочим станциям;
универсальные службы Plug-and-Play;
службы Интернет;
службы телефонии, включая Web-телефонию;
приложения, работающие по технологии “клиент/сервер”.
Здесь вы узнаете о совместном доступе к файлам, принтерам и факсам. В первом разделе главы приводится функциональный обзор классического совместного доступа к файлам и принтерам в одноранговых сетях. В оставшихся разделах рассматриваются новые возможности операционной системы Windows Server 2003, а также по-прежнему полезные службы из операционной системы Windows 2000.
Новые возможности операционной системы Windows Server 2003
В операционной системе Windows Server 2003 улучшено несколько методов общего к ресурсам.
Совместный доступ к факсам. Эта функциональная возможность заимствована из редакции Small Business Server. Она основана на службе Windows 2000 Fax, представлявшей собой изолированную службу. Совместный доступ к факсам в операционной системе Windows Server 2003 позволяет сетевым клиентам отправлять факсы на факс-сервер так, как
задания на печать отправляются на сервер печати. Входящие сообщения факсимильной связи могут преобразовываться во вложения сообщений электронной почты и отправляться администратору офиса для дальнейшего распространения.’
WebDAV. Эта возможность появилась в операционной системе Windows 2000, но была улучшена с помощью специализированного сетевого перенаправителя. Можно использовать протокол HTTP в качестве транспортного протокола для удаленного доступа к файлам. Технологию WebDAV поверх HTTP можно применять вместо классических протоколов LanMan Workstation поверх SMB или FTP.
Удаленный рабочий стол. Доступ администратора (Administrator) на другой узел с помощью служб терминалов, появившийся в операционной системе Windows 2000, стал стандартной функциональной возможностью каждого сервера. Сетевой поставщик прютокола RDP (Remote Desktop Protocol — прютокол удаленного рабочего стола) получил новые возможности, которые совместно с увеличенной прюизводительностью делают удаленный рабочий стол наиболее предпочтительным способом удаленного управления серверами.
Кроме этого, в операционной системе Windows Server 2003 внесено несколько улучшений в технологии совместного доступа к ресурсам.
Управление топологией службы репликации файлов. Поддерживается отдельное определение и управление связями репликации в распределенной файловой системе (Distributed File System — DFS). В операционной системе Windows 2000 топология репликации должна была соответствовать топологии Active Directory, определенной средством проверки согласованности знаний (КСС). Часто такая топология была недостаточно эффективна для копирования больших объемов данных, что случается при использовании распределенной файловой системы.
Служба интеллектуальной передачи в фоновом режиме (Background Intelligent Transfer Service — BITS). Это новый интерфейс, который поддерживает управление портом при передаче файлов по сети Интернет. В момент разрыва соединения или завершения работы компьютера служба запоминает позицию в передаваемом файле и после восстановления соединения продолжает передачу файла с сохраненной позиции. Элементов управления пользовательского интерфейса, позволяющих управлять этой службой, не существует.
Блокировка драйверов в режиме ядра. Эта возможность позволяет заблокировать загрузку устаревших драйверов в операционной системе Windows Server 2003. Новые драйверы, основанные на архитектуре мини-порта, значительно реже приводят к нестабильной работе системы, и их применение предпочтительнее, чем применение устаревших “монолитных” драйверов.
Новые групповые политики. В операционной системе Windows Server 2003 предоставляется несколько новых групповых политик, предназначенных для управления удаленным рабочим столом и совместным доступом к файлам и принтерам.
Отказ от поддержки транспортного протокола Data Link Control (DLC). Если для связи с интерфейсом сервера печати используется транспортный прютокол DLC, это сложно считать улучшением, но, отказавшись от поддержки DLC, компания Microsoft удалила заметный источник повышенного объема передаваемых по сети данных и прюблем в работе маршрутизаторов. Перед модершизацией до Windows Server 2003 убедитесь, что серверы печати поддерживают использование протокола TCP/IP в качестве транспортного.
Простой совместный доступ к ресурсам. Изолирюванная рабочая станция под управлением операционной системы Windows ХР по умолчанию не поддерживает совместного доступа к файлам и принтерам. Это позволяет защитить файлы от случайного предоставления для общего доступа в сети Интернет. Хотя это нельзя считать улучшением в серверной операционной системе, данная возможность может стать для администратора сюрпризом; вот почему эта тема также рассматривается в настоящей главе.
Автоматическое определение места в сети (Network Location Awareness — NLA). Драйвер Winsock был модифицирован и получил новый набор процедур, позволяющих разработчику определить расположение клиента в сети на основе имени домена DNS и сетевого адреса. Разработчики могут использовать эту информацию для автоматизации настройки беспроводных устройств, определения параметров прокси-сервера, монтирования и т.п.
Поддержка 32-разрядных приложений на серверах архитектуры IA64. Сервер Itanium поддерживает запуск 32-разрядных приложений с помощью подсистемы WOW64. Эта подсистема представляет собой 32-разрядный эмулятор, перехватывающий все вызовы Win32 API и заменяющий их 64-разрядными эквивалентами.
Улучшенные возможности взаимодействия филиалов для совместной работы и резервирования информации. Реализация Dfs (Distributed File System — распределенная файловая система) в Windows Server 2003 R2 обеспечивает упрощенный отказоустойчивый доступ к файлам, а также репликацию, способную эффективно функционировать даже через глобальную сеть (WAN).
Возможность взаимодействия с пользователями и службами, работающими на UNIX- компьютерах. Компонент операционной системы Windows Server 2003 R2 под названием Microsoft Services for Network File System (Службы Microsoft для NFS) обеспечивает общий доступ к файлам на предприятиях, которые используют смешанную среду из компьютеров, работающих под управлением Windows и UNIX.
Управление принтерами и серверами печати на новом уровне. В версии операционной системы Windows Server 2003 R2 предоставляется обновленная оснастка Print Management (Управление принтерами) для централизованного управления локальными и удаленными принтерами и серверами печати, работающих под управлением Windows 2000 Server, Windows Server 2003 или Windows Server 2003 R2. Появилась возможность задавать выполнение набора действий согласно сценариям при возникновении тех или иных ситуаций.
Обеспечение командной работы над проектами и Web-интерфейс для управления сервером. Входящий в комплект поставки Windows Server 2003 R2 набор служб Windows SharePoint Services (Службы SharePoint) разработан для обеспечения совместной работы и общения людей, для взаимодействия информационных потоков и систем как в пределах организации, так и за ее брандмауэром.
Функциональное описание совместного доступа к ресурсам Windows
На рис. 16.1 показана общая структура сетевых драйверов в операционной системе Windows Server 2003. Сетевой стек состоит из следующих основных компонентов.
Сетевые приложения
Сетевые поставщики
Перенаправители
Транспортные протоколы
Интерфейсы сетевых адаптеров
Приложения на вершине стека не являются “приложениями” в том смысле, в котором являются приложениями текстовые редакторы или приложения для работы с электронными таблицами. Это приложения, которые применяют активные сетевые вызовы в той или иной форме. Например, приложение клиента электронной почты содержит модули для протоколов POP3 и IM АР4, которые используют сетевые вызовы Winsock для отправки и получения сообщений.
Рис. 16.1. Структура сетевого драйвераРис. 16.1. Структура сетевого драйвера
Рис. 16.1. Структура сетевого драйвера
Рис. 16.1. Структура сетевого драйвера
Сетевые службы, которые взаимодействуют с сетевыми приложениями, состоят из двух компонентов.
Поставщик (provider) работает в пользовательском пространстве памяти и предоставляет сетевые службы сетевым приложениям. Сетевые поставщики хранятся в виде библиотек DLL, которые загружаются и управляются с помощью диспетчера управления службами (Service Control Manager), файл Services . exe.
Перенаправитель (redirector) работает в пространстве памяти ядра. Это драйвер файловой системы, который предназначен для связи с такой же сетевой службой на другом компьютере. Термин “перенаправитель" (redirector) остался со времен начала развития сетей персональных компьютеров, когда сетевые драйверы перехватывали вызовы функций DOS и “перенаправляли” их на сетевой интерфейс. Сетевые перенаправители хранятся в файлах с расширением . sys и работают под управлением диспетчера ввода-вывода (I/O Manager) в подсистеме Windows Executive.
Поставщики и перенаправители работают в тандеме (попарно). Например, поставщик LanMan Workstation работает в тандеме с драйвером перенаправителя Mrxsmb .sys.
Перенаправители работают с драйверами транспортных протоколов через интерфейс транспортных драйверов (Transport Driver Interface — TDI). Уровень TDI работает, как переводчик в ООН. Перенаправители не обязаны знать механизмы работы транспортных протоколов, и наоборот. Они взаимодействуют друг с другом (обмениваются информацией) через уровень TDI.
Как драйверы файловых систем не взаимодействуют непосредственно с драйверами транспортных протоколов, так и драйверы транспортных протоколов не взаимодействуют непосредственно с драйверами сетевого адаптера. Вместо этого используется спецификация NDIS (Network Driver Interface Specification — спецификация стандартного интерфейса сетевых адаптеров), файл Ndis.sys. Драйвер NDIS и вспомогательные драйверы предоставляют сетевой интерфейс драйверу транспортного протокола и аппаратный интерфейс сетевому адаптеру.
Аппаратный интерфейс обменивается информацией с МАС-драйвером NDIS, который предоставляется производителем. Аббревиатура МАС расшифровывается, как Media Access Control (управление доступом к носителю). Кроме этого, NDIS предоставляет интерфейс для асинхронной связи по модему или линии ISDN посредством Telephony API (TAPI).
Рассмотрим каждый из компонентов сетевого стека Windows и методы их взаимодействия. Эта информация полезна при решении проблем, которые возникают при интеграции систем, отказах связи по сети или при попытке увеличить производительность. Например, если используется несколько сетевых поставщиков, то, расположив их в правильном порядке привязки в стеке, можно увеличить производительность.
Сетевые приложения,
Для доступа к сетевым службам большинство сетевых приложений под управлением операционной системы Windows использует одну из четырех библиотек API. Вызовы функций для сетевых служб хранятся в динамически подключаемой библиотеке (DLL) сетевого поставщика и рассматриваются в следующем разделе.
Wnet. Большинство сетевых приложений используют Wnet API в Win32 API для взаимодействия между клиентами и серверами. Например, вызов функции WnetAddConnection позволяет подключить сетевой клиент к совместно используемому ресурсу на сервере.
Именованные каналы. Канал — (pipe) является методом межпроцессного взаимодействия (Interprocess Connection — IPC), в котором два или больше приложений используют одну и ту же область памяти для связи друг с другом путем изменения содержимого этой области памяти. Именованный.канал представляет собой особую форму канала,
отличную от анонимного канала, который имени не имеет. Именованные каналы часто используются такими клиент/серверными приложениями, как приложения баз данных.
Технология Mailslot (почтовый ящик). Технология Mailslot также является методом межпроцессного взаимодействия, но она общедоступна в отличие от ориентированного на соединение метода именованных конвейеров. Приложения Windows обычно используют Mailslot при отправке широковещательных или групповых запросов. Например, при регистрации имен NetBIOS-over-TCP/IP используется Mailslot.
Winsock. Winsock расшифровывается как Windows Sockets. Сокет (socket) является формой межпроцессного взаимодействия, которая впервые появилась в Berkeley Software Distribution (BSD) UNIX. Сокет состоит из IP-адреса, номера порта и флага, который указывает, является ли данный сокет сокетом дейтаграммы или сокетом потока данных.
Поддерживается и пятый метод, NetBIOS, хотя приложения NetBIOS в последнее время стали очень редки. Дополнительная информация приводится во врезке “Поддержка NetBIOS”."
Сетевые поставщики
Сетевые приложения нуждаются в интерфейсе, который поддерживает преобразование сетевых вызовов в команды, которые понятны сетевой файловой системе в составе Windows Executive. Эта роль возложена на сетевого поставщика.
В операционной системе Windows Server 2003 предоставляется несколько сетевых поставщиков. Желательно знать их имена и библиотеки, так как эта информация будет появляться в журнале событий при возникновении каких-либо проблем.
Поставщик Windows. По историческим причинам поставщик Windows называется LanMan Workstation. Поставщик хранится в библиотеке Ntlanman. dll.
Поставщик NetWare. Поставщик NetWare называется NWCWorkstation. Код поставщика хранится в библиотеке Nwwks .dll.
Поставщик удаленного рабочего стола. Этот поставщик обеспечивает многопользовательский доступ к серверу с помощью протокола RDP. Код поставщика хранится в библиотеке Rdpnp.dll. Продукт Citrix Metaframe загружает поставщик Integrated Computing Architecture (ICA) для поддержки многопользовательского доступа клиентов Citrix.
Поставщик Web Client. Это новый поставщик, который появился в операционных системах Windows ХР и Windows Server 2003. Он работает в паре с перенаправителем WebDAV для предоставления интерактивного доступа к файлам (не только команд Put и Get) по протоколу HTTP. Код поставщика хранится в библиотеке Dave Int .dll.
Поставщик Winsock. В операционной системе Windows предоставляются 16-разрядная (winsock.dll) и 32-разрядная (Wsock32 .dll) библиотеки, которые выступают в роли интерфейсов к основной 32-разрядной библиотеке Winsock, Ws_32 .dll. Эта библиотека поддерживает приложения Winsock 1.1 и Winsock 2.0.
Поддержка NetBIOS
В среде администраторов операционной системы Windows существует множество некорректной информации о NetBIOS. Например, многие администраторы верят (или слышали), что сетевая подсистема Windows основана на NetBIOS. Это неверно в настоящее время и было неверно в течение последних десяти лет.
NetBIOS является набором функций, встроенных в аппаратные средства персонального компьютера. Приложение NetBIOS создает в памяти структуру данных, которая называется блоком управления сетью (Network Control Block — NCB), и применяет прерывание BIOS (а именно,
прерывание 5С), которое передает содержимое структуры NCB сетевому драйверу для его доставки контроллеру на плате сетевого адаптера.
В операционной системе Windows приложениям запрещено непосредственно обращаться к аппаратным средствам. Если используется устаревшее приложение NetBIOS, вызов прерывания 5С перехватывается операционной системой и передается NetBIOS Emulator, который является частью TDI.
NetBIOS Emulator преобразовывает вызовы функций NetBIOS в вызовы функций TDI, которые могут выполняться любым из трех транспортных протоколов.
Дополнительная информация о NetBIOS доступна по адресу www.mcgrew.net/Training/ NPS/nps-netbios.htm.
Сервер под управлением операционной системы Windows поддерживает небольшую службу LanMan Server, которая запускается на уровне пользователей и выступает в роли поставщика. Задача этой службы заключается в создании совместно используемых ресурсов, передаче управляющей информации файловой системе сервера, работающей в пространстве ядра, и поддержке устаревшей службы Browser посредством регистрации сервера в базе данных браузеров. Служба LanMan Server не имеет отдельной библиотеки DLL.
Драйверы сетевых файловых систем Named Pipe и Mailslot не требуют использования отдельных поставщиков. Win32 API обрабатывает эти вызовы и устанавливает соединения к соответствующим сетевым файловым системам.
Теоретически приложение можно запрограммировать на непосредственное взаимодействие с TDI или даже с драйверами транспортного уровня. Такие приложения встречаются очень редко, поскольку их создание требует глубоких знаний сетевого программного интерфейса, а эти знания практически недоступны за пределами Редмонда.
Большинство сторонних производителей сетевых операционных систем создают клиенты Windows в виде сетевых поставщиков. В качестве примеров могут быть приведены поставщик NetWare Core Protocol (NCP) от компании Novell, поставщик Andrew Rie System (AFS) от компании Transarc и поставщик Network File System (NFS) от компании Sun.
Поставщики печати
На рис. 16.1 не показаны поставщики печати, но они будут находиться там же, где и поставщики файловых систем. Поставщики печати являются сетевыми приложениями, как и полноценные поставщики файловых систем, но поставщики печати обладают более ограниченными возможностями. Поставщики печати обеспечивают связь со службами печати, запущенными на удаленных компьютерах. В составе операционной системы Windows Server 2003 предоставляется несколько поставщиков печати.
Поставщик печати LanMan. Этот поставщик обрабатывает запросы, выдаваемые клиентами Windows.
Поставщик печати Интернет. Этот поставщик обрабатывает запросы на печать по протоколу HTTP, которые поступают от клиентов под управлением операционной системы Windows и клиентов под управлением других операционных систем.
Поставщик печати NetWare. Этот поставщик поддерживает серверы печати NetWare. Другой поставщик, который устанавливается в составе Services for NetWare (SFN), позволяет серверу Windows принимать задания на печать, отправленные клиентами NetWare.
Поставщик печати Macintosh. Этот поставщик поддерживает печать на хостах Macintosh, подключенных по протоколу AppleTalk.
Поставщика печати для UNIX не существует. Служба поддержки печати из UNIX входит в состав Line Printer Daemon (LPD), Lpdsvc, который загружается вместе с Print Services for Unix — необязательным компонентом операционной системы Windows Server 2003.
Маршрутизатор нескольких поставщиков '
Каждый поставщик, поддерживающий интерфейс Wnet API, связан с многопротокольным маршрутизатором поставщиков (Multiple Provider Router — MPR). Это упрощает программирование, поскольку маршрутизатор MPR обеспечивает простоту взаимодействия для сетевых приложений.
Когда маршрутизатор MRP получает вызов функции для передачи сообщения определенному серверу, он должен выбрать подходящий сетевой поставщик. Для этого поставщики опрашиваются на предмет понимания командного языка, который используется для связи с интересующим сервером. Опрос выполняется в порядке, определенном в записи системного реестра:
I
Раздел: HKLM\SystenACurretControlSet\Control\NetworkProvider\Order Запись: Providerorder
Значение: NWCWorkstation.LanManWorkstation
Для поставщиков печати используются следующие записи системного реестра:
Раздел:HKLM\System\CurretContгоISet \Control\Print\Providers
Запись: Order
Значение: NetWare or Compatible Network, LanMan Print Services, 'b Internet Print Provider
Если в системе одновременно загружены клиенты NetWare и Microsoft, клиент NetWare всегда должен находиться на вершине списка поставщиков. Это справедливо даже в том случае, если большинство серверов работает под управлением операционной системы Windows. Поставщик NetWare очень быстро сообщает о неудачном соединении. С другой стороны, поставщики Microsoft требуют очень много времени из-за просмотра сети и преобразования имен, которые выполняются в процессе соединения.
Поставщик MUP
Кроме конкретных поставщиков сетевых клиентов, которые связываются непосредственно с маршрутизатором MPR, в операционной системе Windows Server 2003 существует универсальный интерфейс, работающий в режиме ядра для приложений, которые не используют вызовы функций, но нуждаются в доступе к сетевым ресурсам. Такой доступ требует указания имени и ресурса в формате UNC. Этот универсальный поставщик называется поставщик MUP (Multiple UNC Provider).
Рассмотрим, как работает этот поставщик. Если открыть файл в текстовом редакторе Notepad (Блокнот) и ввести путь \\srv2\data\textfile.txt, интерфейс Win32 распознает имя как сетевой путь и передаст строку поставщику MUP, который проанализирует строку пр составляющим, чтобы определить имя сервера и имя совместно используемого каталога. После этого поставщик опросит драйверы сетевой файловой системы, как это делал маршрутизатор MPR, чтобы найти драйвер, который может обеспечить подключение к интересующему серверу.
Перед опросом драйверов сетевой файловой системы поставщик MUP обращается к интерфейсу распределенной файловой системы (Distributed File System — Dfs). Если интерфейс распределенной файловой системы возвращает положительный ответ (распознает путь UNC), значит, путь UNC соответствует тому распределенной файловой системы. На этом этапе поставщик MUP проверяет возможность подключения к совместно используемому ресурсу на удаленном сервере. Если такая возможность существует, то MUP устанавливает связь между путем UNC и сервером общего (совместно используемого) ресурса. Если для указанного пути UNC не существует элемента распределенной файловой системы или MUP не получает ответ от сервера, опрос продолжается.
После того как поставщик MUP задает связь между путем UNC и сетевым поставщиком, эта связь записывается в кэш для ускорения последующих транзакций с этим сервером. Например, если MUP определяет, что ресурс \ \ЫдгеЗ\имя_каталога соответствует каталогу на сервере NetWare, поставщик NetWare будет использоваться при каждой попытке пользователей получить доступ к серверу bigred.
Если конкретный путь UNC не используется для связи в течение 15 минут, MUP удаляет соответствующую связь из кэша. Новый запрос для этого пути UNC заставит MUP выполнить полный опрос еще раз. Помните об этом при устранении неисправностей, связанных с большой задержкой при соединении.
Установка сетевых поставщиков
Поставщик SMB, известный под именем Microsoft Client (Клиент для сетей Microsoft), устанавливается по умолчанию и не может быть удален. Дополнительные поставщики могут быть установлены из окна Network Connections (Сетевые подключения). В следующей процедуре в качестве примера рассматривается Client Services for Netware от компании Microsoft. Остальные поставщики предоставляются сторонними производителями программного обеспечения.
Процедура 16.1. Установка дополнительных сетевых клиентов
Щелкните правой кнопкой мыши на пиктограмме Му Network Places (Сетевое окружение) и выберите из контекстного меню команду Properties (Свойства). Откроется окно Network Connections (Сетевые подключения).
Щелкните правой кнопкой мыши на пиктограмме Local Area Connection (Подключение по локальной сети) и выберите из контекстного меню команду Properties (Свойства). Откроется окно Local Area Connection Properties (Свойства подключения по локальной сети), которое показано на рис. 16.2. Если в системе установлено более одного сетевого адаптера, можно выбрать любой из них. Клиент будет установлен и связан со всеми сетевыми интерфейсами.
Рис. 16.2. Окно Local Area Connection Properties (Свойства подключения по локальной сети)
Щелкните на кнопке Install (Установить). Откроется окно Select Network Component Type (Выберите тип сетевого компонента).
Выберите Client (Клиент) и щелкните на кнопке Add (Добавить). Откроется окно Select Network Client (Выбор типа сетевого клиента); По умолчанию в списке присутствует только Client Services for NetWare. Если необходимо установить любой другой клиент, щелкните на кнопке Have Disk (Установить с диска) и укажите системе место расположения драйверов.
Выделите нужный поставщик и щелкните на кнопке Add (Добавить). Система скопирует файлы с компакт-диска, и управление вернется в окно Local Area Connection Properties (Свойства подключения по локальной сети). Могут появиться дополнительные окна для установки параметров.
Убедитесь, что клиент работает правильно. Для этого перезагрузите компьютер и установите подключение к серверу по интересующему протоколу. Если это клиент NetWare, то необходимо пройти аутентификацию в службе Novell Directory Services (NDS) или на сервере NetWare.
Изменение порядка опроса сетевых поставщиков
И маршрутизатор MPR и поставщик MUP опрашивают установленные поставщики и сетевые файловые системы для поиска подходящего компонента для обеспечения связи с интересующим сервером. Если клиент поддерживает несколько сетевых поставщиков, время начального подключения можно уменьшить путем изменения порядка опроса поставщиков. Чем короче время тайм-аута поставщика, тем ближе к началу списка он должен находиться. Обычно самым быстрым поставщиком является поставщик NetWare. Различные сети обеспечивают различное время ответа, поэтому для выбора правильного порядка поставщиков могут потребоваться дополнительные эксперименты. Изменение порядка опроса поставщиков рассматривается в процедуре 16.2.
Процедура 16.2. Изменение порядка опроса сетевых поставщиков
Щелкните правой кнопкой мыши на пиктограмме Му Network Places (Мое сетевое окружение) и выберите из контекстного меню команду Properties (Свойства). Откроется окно Network Connections (Сетевые подключения).
В меню выберите Advanced1^ Advanced Settings (Дополнительной Дополнительные параметры). Откроется окно Advanced Settings (Дополнительные параметры).
Выберите интересующего поставщика и щелкните на кнопке с изображением стрелки (вверх или вниз) для изменения положения поставщика.
Щелкните на кнопке ОК, чтобы сохранить изменения и закрыть окно. Перезагрузка не требуется.
Перенаправители
Поставщики сетевых клиентов и поставщик MUP только предоставляют интерфейс к сети. Реальная работа выполняется драйверами сетевых файловых систем или перенаправителями (redirector). Перенаправители различаются по языку команд, который используется для связи с сервером.
■ Перенаправитель Windows (Mrxsmb. sy s) Этот драйвер используется для связи с серверами Windows с помощью протокола SMB (Server Message Block).
■ Перенаправитель NetWare (Nwrdr. sys). Этот драйвер используется для связи с серверами NetWare по протоколу NetWare Core Protocol (NCP).
■ Перенаправитель RDP (Rdpdr.sys). Этот драйвер используется для связи с серверами терминалов Windows по протоколу Remote Desktop Protocol (RDP).
■ Перенаправитель WebDAV (Mrxdav. sys). Этот драйвер используется для связи с серверами WebDAV (под управлением Windows и других операционных систем) по протоколу WebDAV.
Перенаправитель NetWare предоставляется компанией Microsoft и поддерживает работу с NDS, но не обеспечивает расширенных функций NDS, например Zero Effort Networking (ZENWorks) и NetWare Application Launcher (NAL).
Перенаправители не только получают вызовы функций от поставщиков клиентов Wnet, но и обрабатывают сетевые запросы от других драйверов файловых систем. Например, перенаправитель Mrxsmb используется Named Pipe File System (NPFS)h Mailslot File System (MSFS).
Файловые системы сервера
Служба Server также имеет форму драйвера файловой системы, Srv. sys. Как и перенаправитель Mrxsmb, драйвер Srv. sys работает в пространстве памяти ядра как часть диспетчера ввода-вывода (I/O Manager). Он работает в тандеме со службой LanMan Server, которая находится в пространстве памяти пользователя. Клиентское приложение не может вызывать функции LanMan Server непосредственно, поэтому связь с маршрутизатором MPR не требуется. Драйвер Srv. sys использует перенаправитель Mrxsmb для связи с другими серверами.
Принятые по умолчанию общие ресурсы
Сервер SMB предоставляет сетевые ресурсы в виде обгцих ресурсов (share points). Общий ресурс может быть каталогом или принтером.
Совет по использованию системного реестра: записи для управления перенаправителями
Параметры драйверов файловых систем и поставщиков хранятся в системном реестре и расположены в разделе HKLM\System\CurrentControlSet\Services. Разделы файловых систем имеют те же имена, что и драйверы.
Например, раздел HKLM\System\CurrentControlSet\Services\Mrxsmb содержит параметры перенаправителя файловой системы Windows.
Все серверы под управлением Windows используют принятые по умолчанию общие ресурсы, которые применяются для поддержки сетевых служб и административного доступа. Имена некоторых из принятых по умолчанию общих ресурсов заканчиваются символом доллара ($). Это позволяет скрыть ресурсы в интерфейсах просмотра, например в окне Му Network Places (Мое сетевое окружение). Скрытые ресурсы называются административными ресурсами (administrative share) и рассматриваются ниже.
■ Административные ресурсы. С помощью этих ресурсов предоставляется доступ к корне? вому каталогу каждого диска на сервере и корневому каталогу системы (в операционной системе Windows Server 2003 это каталог \Windows). Доступ к этим ресурсам разрешен только локальной группе Administrators (Администраторы). Глобальная группа Domain Admins (Администраторы домена) вложена в группу Administrators (Администраторы), поэтому членам группы Domain Admins (Администраторы домена) также предоставляется доступ к административным ресурсам. Дополнительная информация приводится во врезке “Административные ресурсы для приводов компакт-дисков”.
1РС$. Этот общий ресурс предоставляет доступ к символической ссылке Interprocess Connection (IPC). Этот ресурс поддерживает RPC-соединения (удаленного вызова процедур) между компьютерами Windows.
Sysvol. Этот общий ресурс доступен на контроллерах домена. С его помощью обеспечивается доступ к папке \windows\Sysvol\Sysvol, в которой хранятся групповые политики и классические регистрационные сценарии.
Net logon. Этот ресурс используется для предоставления доступа к папке \Windows\ Sysvol\Sysvol\Scripts. Все клиенты Windows в составе домена (включая клиенты под управлением Windows 3.11, Windows 9х и Windows ME) пытаются найти общий ре- ’ сурс Net logon на своем регистрационном сервере. В папке хранятся классические системные политики и регистрационные сценарии для клиентов более старых версий.
Prlnt$ • Этот общий ресурс предназначен для предоставления доступа к папке \Winddws\ System32\Spool\Drives. В этой папке хранятся драйверы для каждого подключенного к серверу принтера. Клиенты, которые подключаются к совместно используемому принтеру, загружают драйверы с этого ресурса. Если установлены соответствующие драйверы, это относится и к клиентам более старых версий под управлением Windows NT 4.0, Windows 9х и Windows ME.
FxsSrvCp$. Этот ресурс создается при установке службы факсов и используется для предоставления доступа к папке с совместно используемыми заголовками страниц факсимильных сообщений. По умолчанию это папка \Documents and Settings\All Users\ Application Data\Microsoft\Windows NT\MSFax\Common Coverpages.
Remlnstall. Этот ресурс создается при установке служб удаленной установки (Remote Installation Service — RIS). Он используется для предоставления клиентам Preboot Execution Environment (РХЕ) доступа к инсталляционным файлам.
Для быстрого просмотра списка общих ресурсов на сервере в приглашении командной строки можно ввести команду net share. Ниже приводится пример отчета о выполнении этой команды. На данном сервере установлен продукт Visual Studio, поэтому для обеспечения совместной работы за брандмауэром для совместного доступа предоставлен корневой Web-каталог.
Share name
Resource
Remark
с$
С: \
Default Share
1РС$
Remote IPC
х$
Х:\
Default Share
ADMIN$
С:\WINDOWS
Remote Admin
wwwroot$
с:\inetpub\wwwroot
Used for file share access to web
Административные ресурсы для приводов компакт-дисков
По умолчанию в операционных системах Windows Server 2003, Windows ХР и Windows 2000 административные ресурсы для приводов компакт-дисков не создаются. Если изменить букву диска привода компакт-дисков, система создаст административный ресурс для новой буквы диска.
Настройка совместного доступа к файлам
Точка доступа к общему ресурсу (share point) описывает сетевой путь к локальной файловой системе. В операционной системе Windows не предоставляется принятых по умолчанию общих ресурсов, к которым могут получать доступ обычные пользователи. Перед тем как пользователи будут подключаться к общим ресурсам, эти ресурсы нужно создать на сервере.
Существует несколько способов создания общих ресурсов. Можно воспользоваться оболочкой Explorer (Проводник), консолью Computer Management (Управление компьютером), командой net из командной строки или инструментами из состава Resource Kit. В этом разделе рассматриваются все методы создания общих ресурсов.
Совместный доступ к операционной системе Windows ХР
В этой книге основное внимание уделяется операционной системе Windows Server 2003, но стоит обратить внимание, что совместный доступ к файлам на изолированном (не входящем в домен) клиенте под управлением Windows ХР Professional или Windows ХР Home Edition очень отличается от методов общего доступа в операционной системе Windows Server 2003 или в операционных системах Windows 2000 и Windows NT.
На изолированных рабочих станциях под управлением операционной системы Windows ХР совместный доступ к ресурсам по сети по умолчанию отключен. Кроме этого, разрешения файловой системы NTFS недоступны в оболочке Explorer (Проводник). Доступ к каталогам осуществляется с помощью возможности, которая называется простой общий доступ (simple sharing). Эта возможность по умолчанию включена на всех изолированных компьютерах под управлением операционной системы Windows ХР Professional и является единственной доступной возможностью на компьютерах под управлением операционной системы Windows ХР Home Edition.
Для получения доступа к параметрам простого общего доступа к файлам откройте любую папку и выберите Tools^Folder Options (Сервис^Свойства папки). Перейдите на вкладку View (Вид) и прокрутите список доступных параметров до самого конца, где находится флажок Use Simple File Sharing (Использовать простой общий доступ к файлам), как показано на рис. 16.3.
О Show hidden hies and folder* 0 Hide extensions for known fie types Q Hide protected operatrig system fifes (Recommended) □ Launch foider wridows n a separate process 0 Remember each folder's view settings Q Restore previous folder wridows at logon □ Show Control Panel in My Computer
Рис. 163. Окно Folder Options (Свойства папки), в котором доступен флажок Use Simple File Sharing (Использовать простой общий доступ к файлам)
Совет no использованию системного реестра: общие каталоги в системном реестре
Совместно используемые ресурсы хранятся в системном реестре в разделе HKLM\system\ CurrentControlSet\Services\LanManServer\Shares. Для каждого совместно используемого ресурса создается значение с несколькими свойствами в записи Reg_Multi_SZ.
CSCFlaga. Флаги кэширования на стороне клиента: по умолчанию установлено значение 0, которое соответствует выполнению кэширования вручную; значение 16 означает автомати-
ческое кэширование документов; значение 32 — автоматическое кэширование приложений; значение 4 8 отключает кэширование.
Max Users. По умолчанию используется значение 4294967295 (длинное целое, состоящее из значений F в каждой шестнадцатеричной позиции).
Path. Локальный путь к совместно используемому ресурсу. Если изменить путь таким образом, что он не будет соответствовать записи в системном реестре, совместно используемый ресурс станет недоступным.
permissions. Эта запись используется для поддержки клиентов более старых версий, которые ожидают получить флаги безопасности ресурса в ответе SMB для этого ресурса.
Remark. Содержит комментарии для совместно используемого ресурса.
Туре. Для операционных систем Windows Server 2003, Windows ХР и Windows 2000 всегда устанавливается равным значению 0.
Эти параметры управляют следующей записью системного реестра:
Раздел: HKLM\System\CurrentControlSet\Control\LSA
Запись: ForceGuest
Значение: 1 (блокировать доступ), о (разрешить доступ)
Если параметр ForceGuest установлен равным значению 1, включаются следующие ограничения на простой общий доступ к файлам.
Файлы в каталоге пользователя Му Documents (Мои документы) можно сделать полностью недоступными другим пользователям (разрешения NTFS устанавливаются следующим образом: <Пользователь>: Full (<Пользователь>:Полный доступ) и System: Full (Система:Полный доступ)) или частично доступными для локальной группы Administrators (Администраторы) — в права доступа NTFS добавляется запись Administrators : Full (Администраторы:Полный доступ).
Каталог All Users\Documents становится доступным в оболочке как каталог Shared Documents (Общие документы). Если пользователю необходимо, чтобы к его документам получили доступ другие пользователи, он перетаскивает документы в папку Shared Documents (Общие документы). Разрешения NTFS для этой папки устанавливаются в виде Users:Read,Write,Append, Creatorowner:Full, Administrators:Full, System: Full и Power Users:Change (Пользователи:Чтение,Запись,Добавление, Создатель- Владелец:Полный доступ, Администраторы:Полный доступ, Система:Полный доступ и Опытные пользователи:Изменение).
Папки могут быть предоставлены в общий доступ через сеть с помощью вкладки Sharing (Доступ) в окне свойств папки в оболочке Explorer (Проводник). Если установлен флажок Share This Folder On The Network (Предоставить папку в общий доступ) и сброшен флажок Allow Network Users То Change Му Files (Разрешить сетевым пользователям менять мои файлы), для папки создается ресурс SMB и разрешения NTFS устанавливаются равными Everyone: Read (Все:Чтение).
Если флажок Allow Network Users То Change Му Files (Разрешить сетевым пользователям менять мои файлы) установлен, разрешения NTFS устанавливаются как Everyone: Change (Все:Изменение).
Эти ограничения относятся только к соединениям по протоколу SMB. Изолированная рабочая станция под управлением операционной системы Windows ХР Professional с установленной службой IIS может отвечать на запросы по протоколам HTTP и FTP даже в том случае, если включен простой общий доступ к файлам, но ни одна папка не предоставлена в об-
щий доступ. Рабочая станция также может отвечать на запросы WebDAV. Если не установить соответствующие разрешения NTFS, на запросы по протоколам FTP и WebDAV будет выдаваться отрицательный ответ.
Простой общий доступ к файлам отключается при добавлении рабочей станции под управлением Windows ХР Professional в домен. (Операционная система Windows ХР Ноше не поддерживает работу в составе домена.)
Разрешения совместного доступа
Во всех предыдущих версиях операционной системы Windows при создании нового совместно используемого ресурса группа Everyone (Все) добавлялась в список разрешений для ресурса и получала разрешение Full (Полный доступ). Управление доступом к файлам и папкам в пределах общего ресурса возлагалось на файловую систему NTFS.
Новый дух безопасности, который пропитал операционную систему Windows Server 2003, заставил компанию Microsoft изменить устанавливаемые по умолчанию разрешения для общего ресурса. Группа Everyone (Все) все еще является единственной записью в списке контроля доступа, но вместо разрешения Full (Полный доступ) этой группе предоставляется разрешение Read (Чтение). Это позволяет защитить общие ресурсы, которые соответствуют каталогам в файловых системах FAT и FAT32.
На серверах всегда нужно использовать файловую систему NTFS, что позволяет установить права доступа для каталога равными значению Everyone: Full (Все:Полный доступ). Для этого можно воспользоваться интерфейсом Explorer (Проводник) или интерфейсом командного интерпретатора с помощью команды net share, например:
net share <имя_ресурса>=<луть_к_папке> /grant:everyone,full
Установив разрешение Everyone: Full (Все:Полный доступ), можно избавить себя от головной боли в будущем, когда при решении проблемы доступа вы забудете параметры прав доступа к общему ресурсу.
Если назначить разрешения для общего ресурса, то они будут работать в качестве фильтра для доступа к каталогу в файловой системе. Если пользователь имеет полный доступ к каталогу в файловой системе NTFS, но для ресурса предоставлено разрешение Read (Чтение), пользователь сможет только читать файлы. В то же время, если пользователю предоставлено право Read (Чтение) в файловой системе NTFS и право Full (Полный доступ) для общего ресурса, пользователь тоже сможет только читать файлы.
Выбор каталогов для совместного доступа
Совместно используемые ресурсы множатся, как плохие рок-группы. Когда сервер отправляет список ресурсов клиенту, он предоставляет имя каждого ресурса, включая скрытые. Если создать тысячи ресурсов, производительность клиента снизится.
Операционные системы Windows Server 2003 и Windows 2000 поддерживают подключение сетевых дисков к каталогам внутри общего ресурса. Эту возможность стоит применять для сокращения количества избыточных общих ресурсов.
Кроме этого, стоит избегать создания перекрывающихся общих ресурсов. Это вводит пользователей в заблуждение и может привести к трагичным звонкам в службу поддержки ("Я удалил лишние файлы на диске К, а они исчезли и с диска L. Что произошло?").
Создание общего ресурса с помощью Explorer
Explorer (Проводник) обеспечивает самый простой способ создания общего ресурса. В процедуре 16.3 описано создание нового каталога и общего ресурса для этого каталога.
Процедура 16.3. Создание и предоставление каталога для общего доступа
Зарегистрируйтесь на консоли компьютера с помощью учетной записи с административными привилегиями.
Откройте окно Explorer (Проводник) или Му Computer (Мой компьютер).
Создайте каталог или выберите существующий каталог. В примере на рис. 16.4 показан каталог Sales.
Щелкните правой кнопкой мыши на пиктограмме каталога и выберите из контекстного меню команду Sharing and Security (Общий доступ и безопасность). Откроется окно Properties (Свойства) на вкладке Sharing (Доступ).
Рис. 16.4. Окно свойств папки Sales, вкладка Sharing (Доступ)
Выберите переключатель Share This Folder (Открыть общий доступ к этой папке). Система автоматически подставит имя папки в поле имени ресурса. Если на компьютере уже существует общий ресурс с таким именем, поле имени останется пустым. В таком случае можно указать другое имя.
Обычно стоит оставлять выбранным переключатель Maximum Allowed (Максимально возможное). Устанавливайте значение в поле User Limit (Не более) только в том случае, если необходимо ограничить максимальное количество пользователей, которые смогут получать доступ к общему ресурсу. Эта возможность может пригодиться для обеспечения лицензионных ограничений на доступ к выполняемым файлам, хранящимся на общем ресурсе.
Длина имени общего ресурса
Выберите имя общего ресурса, которое соответствует допустимой длине имени на клиентах под управлением Windows в локальной сети.
Операционная система Windows NT 4.0 и более поздние версии поддерживают имена длиной до 255 символов.
Операционная система Windows NT 3.51 поддерживает имена длиной до 15 символов.
Операционная система Windows 95 поддерживает имена длиной до 12 символов.
Операционные системы Windows 3.x и DOS поддерживают имена длиной до 8 символов.
Если количество символов в имени ресурса превышает установленный предел, некоторые клиенты не смогут видеть ресурс в списке общих ресурсов и подключать к ресурсу сетевой диск.
Щелкните на кнопке Permissions (Разрешения) и назначьте группе Everyone (Все) разрешение Full (Полный доступ). Щелкните на кнопке ОК.
Щелкните на кнопке ОК, чтобы создать общий ресурс и закрыть окно Properties (Свойства). Параметр Caching (Кэширование) рассматривается в главе 19, “Управление операционной средой пользователя”.
Обратите внимание, что на пиктограмме папки появилось изображение руки, которое означает, что папка предоставлена в общий доступ. Если ввести команду net share в командной строке, эта папка будет показана как общий ресурс.
Создание общих ресурсов на удаленных компьютерах
Интерфейс Explorer (Проводник) не предоставляет механизмов для создания общих ресурсов на удаленных серверах. Для создания таких ресурсов на удаленных компьютерах можно воспользоваться консолью Computer Management (Управление компьютером), как описано в процедуре 16.4.
Процедура 16.4. Создание общих ресурсов на удаленных компьютерах с помощью консоли Computer Management (Управление компьютером)
Откройте консоль Computer Management (Управление компьютером). Для этого выберите Starts Programs^ Administrative Tools^Computer Management (Пуск^Программы^ Администрирование^ Управление компьютером).
Щелкните правой кнопкой мыши на пиктограмме Computer Management (Управление компьютером) и выберите из контекстного меню команду Connect to Another Computer (Подключиться к другому компьютеру). Откроется окно Select Computer (Выберите компьютер).
Щелкните на кнопке Browse (Обзор). Откроется стандартное окно поиска объекта. Введите несколько первых букв имени интересующего сервера и щелкните на кнопке Check Names (Проверить имена). Начнется поиск LDAP в базе данных Active Directory. Результат поиска будет выдан в виде списка с возможностью выбора интересующего элемента.
Если с введенных символов начинаются имена более чем одного компьютера, откроется окно Multiple Names Found (Найдено несколько имен) со списком имен. Выполните двойной щелчок на интересующем имени и щелкните на кнопке ОК, после чего еще раз щелкните на кнопке ОК для выбора компьютера.
Разверните дерево в разделе System Tools1^ Shared Folders^Shares (Служебные программна Общие папки^ Общие ресурсы), как показано на рис. 16.5.
Щелкните правой кнопкой мыши на пиктограмме Shares (Общие ресурсы) и выберите из контекстного меню команду New File Share (Новый общий ресурс). Откроется окно Create Shared Folders (Создание общей папки).
Щелкните на кнопке Browse (Обзор), чтобы выбрать папку, которая будет предоставлена для совместного доступа. Откроется окно Browse for Folder (Найти папку), которое показано на рис. 16.6. Для просмотра ресурсов на удаленном компьютере для корневого ката-
лога каждого тома должен существовать административный общий ресурс (имя которого начинается с символа $). Если удалить административные ресурсы, локальный путь к папке придется вводить вручную.
Computer ManagementComputer Management4L ..*®Uf
Computer Management
Computer Management
£ Corrvuter Management (SERVER?) S' Sb System Took. ® Й Event Viewer*-' ^ Shared Folders£ Corrvuter Management (SERVER?) S' Sb System Took. ® Й Event Viewer*-' ^ Shared Folders®"3®"3• ^ OpenFfes fl Local Users and Groups• ^ OpenFfes fl Local Users and GroupsB& agiB& agi8 Performance Logs and Device ManagerServices and Appkations8 Performance Logs and Device ManagerServices and AppkationsAlerts"Alerts"69 ADMIN* вс* в CertConfig вengineering вР* в <5* вн* в1РС* в print* Oreminst вusers69 ADMIN* вс* в CertConfig вengineering вР* в <5* вн* в1РС* в print* Oreminst вusersC:\WINDOSV5c:\cert c:\en0neertngC:\WINDOSV5c:\cert c:\en0neertngG:\Н!\G:\Н!\C:\WINOOW5\Syst... H:\Remotelnstal c:\usetsC:\WINOOW5\Syst... H:\Remotelnstal c:\usetsj^e Windows WindowsWindows Windows WindowsWindows Windows Windows . WindowsWindows Windowsj^e Windows WindowsWindows Windows WindowsWindows Windows Windows . WindowsWindows WindowsUartCam^о00UartCam^о00О ООО ОООООООО
£ Corrvuter Management (SERVER?) S' Sb System Took
. ® Й Event Viewer
*-' ^ Shared Folders
£ Corrvuter Management (SERVER?) S' Sb System Took
. ® Й Event Viewer
*-' ^ Shared Folders
®"3
®"3
• ^ OpenFfes fl Local Users and Groups
• ^ OpenFfes fl Local Users and Groups
B& agi
B& agi
8 Performance Logs and Device Manager
Services and Appkations
8 Performance Logs and Device Manager
Services and Appkations
Alerts"
Alerts"
69 ADMIN* вс* в CertConfig вengineering вР* в <5* вн* в1РС* в print* Oreminst вusers
69 ADMIN* вс* в CertConfig вengineering вР* в <5* вн* в1РС* в print* Oreminst вusers
C:\WINDOSV5
c:\cert c:\en0neertng
C:\WINDOSV5
c:\cert c:\en0neertng
G:\
Н!\
G:\
Н!\
C:\WINOOW5\Syst... H:\Remotelnstal c:\usets
C:\WINOOW5\Syst... H:\Remotelnstal c:\usets
j^e Windows Windows
Windows Windows Windows
Windows Windows Windows . Windows
Windows Windows
j^e Windows Windows
Windows Windows Windows
Windows Windows Windows . Windows
Windows Windows
UartCam^
о
0
0
UartCam^
о
0
0
О О
О
О О
О
О
О
О
О
О
О
Puc. 16.5. Консоль Computer Management (Управление компьютером) co списком общих ресурсов на удаленном компьютере
Рис. 16.6. Окно Browse for Folder (Найти папку), в котором папки верхнего уровня отображаются в виде административных ресурсов удаленного компьютера
Выберите папку для совместного доступа или создайте новую папку.
Щелкните на кнопке ОК, чтобы сохранить сделанный выбор и вернуться в окно Create Shared Folders (Создание общей папки).
Введите значения в поля Share Name (Имя общего ресурса) и Share Description (Описание общего ресурса).
Щелкните на кнопке Next (Далее). Установите параметры разрешений. Щелкнув на кнопке Custom, можно открыть окно Customize Permission (Изменить разрешения). В этом окне доступен список для выбора пользователей и групп, которые будут добавлены в списки авторизованных пользователей общего ресурса.
Щелкните на кнопке Finish (Готово), чтобы внести изменения и закрыть окно.
Система выдаст сообщение об успешном создании общего ресурса. Если при создании ресурса возникла проблема, будет выдано сообщение об ошибке. Чаще всего проблемы при создании общих ресурсов на удаленном компьютере связаны с недостаточными привилегиями. Для папки, используемой для создания общего ресурса, владельцами могут быть установлены очень ограниченные разрешения NTFS.
Создание общих ресурсов из командной строки
Общий ресурс можно создать из командной строки, воспользовавшись командой net share. Рассмотрим синтаксис этой команды:
net share имя_ресурса=диск:\каталог /grant:Everyone,Full
Если необходимо прекратить совместное использование каталога, воспользуйтесь параметром /delete, как показано ниже: net share имя_ресурса /delete
Команда net share работает только с консоли сервера, на котором находится каталог, предоставляемый для совместного доступа. Если из командной строки необходимо задать совместное использование удаленного каталога, воспользуйтесь утилитой rmt share из состава Resource Kit. Эта команда имеет следующий синтаксис:
rmtshare \\имя_сервера\имя_ресурса=диск:путь
[/users:число I /unlimited]
[/remark:"текст"]
[/grant user'.разрешение!
[/remove user]
Чтобы прекратить совместное использование каталога на удаленном компьютере, воспользуйтесь параметром /delete следующим образом: rmtshare \\имя_сервера\имя_ресурса /delete
Восстановление административных общих ресурсов
Доступ к ресурсам С$ и ADMIN$ (и другим ресурсам, которые представляют тома на сервере) разрешен только членам группы Administrators (Администраторы). Если случайно удалить эти ресурсы, можно будет создать новый ресурс с именем С$, но он не будет иметь тех же разрешений. Для восстановления удаленных административных ресурсов можно воспользоваться Poledit (Редактор политик). Последовательность действий рассматривается в процедуре 16.5.
Процедура 16.5. Восстановление удаленных административных ресурсов с помощью редактора Poledit
Запустите редактор Poledit из окна Run (Выполнить).
В меню выберите File^Open Registry (Файл^Открыть реестр).
Выполните двойной щелчок на пиктограмме Local Computer (Локальный компьютер). Откроется окно Local Computer Properties (Свойства локального компьютера).
Разверните раздел Windows NT Network^Sharing (Сеть Windows NT=> Общий доступ).
Выберите Create Hidden Drive Shares (Server) (Создать скрытые ресурсы для дисков (Сервер)).
Щелкните на кнопке ОК, чтобы сохранить изменения и вернуться в основное окно Policy Editor (Редактор политик).
В меню выберите File^Save (Файл1^Сохранить). Изменения будут записаны в системный реестр.
В результате этой последовательности действий в раздел системного реестра HKLM\ System\CurrentControlSet\Services\LanManServer\Parameters добавится запись AutoShareServer.
Теневое копирование тома
Возможно, каждый администратор получал звонок по телефону, подобный следующему. Разговор начинается так: “Я вносил изменения в электронной таблице в макрос, который используется для расчета выплат, и теперь электронная таблица не работает. Можете восстановить электронную таблицу из вчерашней резервной копии?”. По какой-то причине ответ “Да, конечно. Вы сможете получить свою электронную таблицу в следующую среду” никогда не удовлетворяет пользователя.
Резервное копирование на магнитную ленту является исключительно важной процедурой, но восстановление отдельных файлов требует значительных ресурсов и времени персонала отдела информационных технологий. В операционной системе Windows Server 2003 предоставляется новая возможность, которая называется службой теневого копирования тома (Volume Shadow Сору). Эта служба позволяет пользователю получать сохраненные копии файлов данных. Служба теневого копирования тома формирует базу данных, в которой хранятся изменения файлов данных, в виде периодически создаваемых моментальных копий.
Работой базы данных теневого копирования тома можно управлять в окне свойств тома на вкладке Shadow Copies (Теневые копии), которая показана на рис. 16.7.
ВДЩЩЩЗ^^уз $
' 6Ш I Took 1 < Hei**e ’x I SkatingSegui» . 5Ьв**Уее;н | Quota
Shadow sow dkm wen to view the contented sharedfddeis ailheetxiiiwtt edited at prevxMpahtiin lime Fdifamationcin '
Hduied cw* idtwar^. dsk^№
Sel*re<li*r ■-- /’
- .Уаийв"'''|^й«1^. i Used ... i
SCIDisabled1
№PA6/26/200^." 2100MB on
Puc. 16.7. Окно свойств тома NTFS, вкладка
Shadow Copies (Tеневые копии).
Щелкнув на кнопке Settings (Параметры), можно определить размер базы данных и расписание создания моментальных копий тома. По умолчанию моментальные копии данных создаются два раза в день: в 7:00 и 12:00 с понедельника по пятницу. Количество копий зависит от размера базы данных. По умолчанию размер базы данных равен 10 % от размера тома, начиная от 100 Мбайт.
База данных теневого копирования тома хранится в скрытой папке, которая называется System Volume Information и находится в корневом каталоге тома. База данных зашифрована для защиты содержимого файлов. База данных не может быть дефрагментирована. Теневое копирование тома не поддерживается для общего (quorum) накопителя в кластере.
Теневое копирование выполняется для всего тома. Включение теневого копирования для отдельных общих ресурсов не поддерживается. Компания Microsoft рекомендует хранить кэш теневого копирования на отдельном диске или в массиве RAID. Предоставляется возможность отказа от резервного копирования копий файла. Для обеспечения целостности базы данных приложение резервного копирования должно соответствовать требованиям программного интерфейса архивации операционной системы Windows Server 2003.
Для доступа к базе данных теневого копирования на клиентах необходимо установить отдельное расширение оболочки Explorer (Проводник). Установочный пакет называется Twclient.msi и находится в каталоге \Windows\System32\Clients\Twclient. Для распространения пакета можно воспользоваться групповыми политиками.
Расширение Twclient работает только под управлением операционных систем Windows Server 2003 и Windows ХР. Расширение предоставляет доступ к базе данных теневого копирования тома на вкладке Previous Versions (Предыдущие версии) в окне свойств файла (рис. 16.8).
Schedules tKl Pr operties
Cereal] Security] Sunwwy Previou$V*«ion$ |
а
То view a pevioui vecnon of а Не. select the veroon from thefdktwngblandtfwncick View You can ekotaveafietaarifferenUooolionorreetorea ' previous version of a fie.
ffe versions
0 |Schedules.txt T odag. August 24.2002.8:58 AMj
j OK 1 . Caned.. I ' I »* 1
Puc. 16.8. Вкладка Previous Versions (Преды-дущие версии) страницы свойств сетевого файла
Пользователь может просматривать Предыдущие версии и копировать их в новое место или восстанавливать копию вместо оригинального файла, если оригинал был удален. Существует несколько ограничительных функций, которые не позволяют пользователям случайно перезаписать собственные файлы.
Если используется сеть хранения данных или хранилище данных, подключенное к сети, возможность теневого копирования тома поддерживает создание моментальных копий динамических файлов, например баз данных. Эта возможность позволяет безопасно переносить файлы в другое место. В операционной системе Windows Server 2003 предоставляется новая служба Virtual Disk Service (VDS). Эта служба предоставляет программный интерфейс для доступа к параметрам массивов RAID, а также к настройками для SAN/NAS (Сети хранения данных/Хранилища, подключенные к сети) из операционной системы. Этот интерфейс позволяет менять параметры хранилища с консоли компьютера.
Подключение к общим каталогам
Можно совместно использовать все папки, но, если пользователи не смогут найти их с минимальными усилиями, с тем же успехом можно продавать спиртные напитки на встрече членов церкви методистов.
В операционной системе Windows Server 2003 предоставляется три способа поиска совместно используемых ресурсов: просмотр, публикация в Active Directory и распределенная файловая система (Distributed File System — DFS). Первые два способа рассматриваются в этом разделе. Распределенная файловая система рассматривается далее в этой главе, в разделе “Совместный доступ к ресурсам с помощью распределенной файловой системы”.
Просмотр
Просмотр уже давно является одной из возможностей сетевой подсистемы Windows. Это неуклюжий способ, но он помогает найти серверы и созданные на них совместно используемые ресурсы. .
В каждом сегменте сети существует как минимум один обозреватель, который называется главным обозревателем подсети (Subnet Master Browser). Серверы регистрируют свои имена у главного обозревателя подсети при каждом подключении к сети. Главный обозреватель подсети поддерживает базу данных имен серверов, которая называется список просмотра (browse list).
Когда пользователь открывает окно Му Network Places (Мое сетевое окружение) или просматривает список ресурсов в окне Map Network Drive (Подключить сетевой диск), сетевой клиент запрашивает копию списка просмотра у главного обозревателя подсети. Из этого списка сетевой клиент получает имена серверов.
Любой компьютер под управлением Windows с включенным общим доступом к файлам может стать главным обозревателем или резервным обозревателем. Это относится к операционным системам Windows for Workgroups, Windows 9x/ME, всем версиям операционных систем Windows NT, Windows 2000, Windows XP и Windows Server 2003. Главный обозреватель выбирается в результате процесса под названием выборы обозревателя (browser election). Результат выборов зависит от иерархии, согласно которой серверам предоставляется преимущество над рабочими станциями, контроллерам доменов — над серверами, а операционным системам Windows NT — над системами Windows 9х и Windows 3.x.
Существует вероятность, что главный обозреватель подсети будет перегружен обработкой запросов клиентов. Для получения помощи обозреватель ведет себя, как коммерческий капитан времен Британской революции. Он заставляет другие серверы работать в качестве резервных обозревателей (backup browsers). Главный обозреватель реплицирует последний список
просмотра на резервные обозреватели и поочередно передает им запросы клиентов для балансировки нагрузки.
Серверы, которые принимают участие в выборах главного обозревателя, называются потенциальными обозревателями (potential browsers). Если потенциальный обозреватель проигрывает выборы, он становится кандидатом на позицию резервного обозревателя. Каждый раз, когда к сети добавляется 32 клиента, главным обозревателем назначается еще один резервный обозреватель.
В маршрутизируемых сетях TCP/IP главные обозреватели подсетей реплицируют свои списки просмотра на основной контроллер домена, который выступает в роли главного обозревателя домена (Domain Master Browser). В домене Active Directory в роли главного обозревателя домена выступает контроллер домена, для которого назначена роль PDC Emulator. Главный обозреватель домена собирает списки просмотра и распространяет их на главные обозреватели подсетей, которые, в свою очередь, реплицируют списки просмотра на резервные обозреватели.
Поиск вместо просмотра
На больших предприятиях с сотнями и тысячами серверов открытие окна Му Network Places (Мое сетевое окружение) для поиска конкретного компьютера может занять некоторое время. Значительно быстрее работает утилита Search (Поиск), доступная из меню Start (Пуск). Эта утилита выполняет поиск в базе данных просмотра, а не в DNS или Active Directory. Для поиска компьютера необходимо выполнить следующую последовательность действий.
В окне Search (Поиск) в левой панели выберите Printers, Computers or People (Принтеры, компьютеры или пользователи).
Щелкните на ссылке Computer on the Network (Компьютер в сети).
Введите имя компьютера.
Если компьютер будет найден, выполните двойной щелчок на его пиктограмме для просмотра его общих ресурсов.
Устранение неисправностей при просмотре
Кроме печати и безопасности, просмотр является основным источником неудобств для системных администраторов. Ошибки просмотра диагностируются достаточно просто, но нужно помнить об основных функциональных возможностях.
Все просто, так как большая часть этой технологии в старых версиях Windows напоминает рассказы доктора Сейса (Dr. Seuss). Просмотр проектировался человеком, который вырос на рассказах о черепахе Эртли (Yertle the Turtle). Главная фраза черепашки — “Я черепашка Эртли. Я хозяйка всего, что вижу. Я выше всех и вижу дальше всех”.
Главный обозреватель подсети видит только серверы в своей подсети, поэтому в его копии базы данных просмотра присутствуют только эти серверы. Главный обозреватель домена видит все главные обозреватели подсетей, поэтому в его базе данных присутствуют все серверы, но они попадают в базу данных только после получения копий баз данных локальных обозревателей. Потенциально для каждого транспортного протокола может существовать отдельный главный обозреватель, что приводит к появлению нескольких “Эртли” в каждой подсети.
Наконец, если добавить в одну базу данных слишком много подсетей, вся структура “развалится” и главный обозреватель станет хозяином “помойки”, так как больше он ничего не увидит.
Работающий просмотр позволяет пользователям быстро и удобно находить серверы и их ресурсы. Но просмотр имеет гораздо более сложную структуру, чем может показаться на первый взгляд, и эта сложность иногда может вводить пользователей в заблуждение. Перечислим самые заметные недостатки просмотра.
Клиенты Windows отправляют запросы главному обозревателю, используя транспортный протокол, который указан первым в иерархии привязки. Часто это приводит к тому, что два находящихся рядом компьютера предоставляют разные списки серверов.
Регистрация, выборы и запросы просмотра могут привести к передаче по сети большого объема широковещательных запросов. Эти широковещательные запросы должен обрабатывать каждый сетевой клиент.
Репликация списка просмотра выполняется со значительными задержками. Между отключением сервера от сети и исчезновением его из списка просмотра может пройти до 51 минуты. Все это время информация о сервере продолжает предоставляться в окне Му Network Places (Мое сетевое окружение).
Просмотр в сети TCP/IP зависит от службы WINS (Windows Internet Name Service), которая сама по себе обладает рядом недостатков. Главные обозреватели подсетей находят главный обозреватель домена с помощью запроса WINS. В свою очередь, основной контроллер домена находит главные обозреватели подсетей также по записям в базе данных WINS. Если служба WINS станет недоступной, просмотр откажет через некоторое время.
Теоретически существует возможность отключить просмотр в сети, предоставив альтернативные способы поиска серверов и их ресурсов. Одним из способов является публикация общих ресурсов в Active Directory. Как будет показано далее, этот метод оставляет желать лучшего, поэтому более подходящим решением является использование распределенной файловой системы.
Совместный доступ к ресурсам с помощью распределенной файловой системы
Сети часто вводят в заблуждение обычных конечных пользователей. Пользователю можно сказать, что его файлы хранятся “в сети”, но с тем же успехом ему можно сообщить, что где-то в Чикаго для него выписан чек на 10 долларов.
На рис. 16.9 показан типичный набор сетевых ресурсов. Подключение к общим ресурсам требует создания сетевого диска на клиенте. Во многих организациях тратятся время, энергия и интеллектуальные усилия на создание способа предоставления пользователям одинакового набора подключенных дисков. Пользователи не настолько квалифицированы в области сете- ’ вой инфраструктуры, чтобы связать подключенные диски с сервером, поэтому в представлении пользователей сетевые диски становятся сервером. “Мой диск К вчера опять отказал. Может, отделу информационных технологий стоит работать более активно?” (Администраторы UNIX также сталкиваются с подобными суждениями. Точки монтирования Network File System (NFS) тоже часто начинают жить собственной жизнью.)
Еще одной проблемой предоставления ресурсов для совместного доступа является ограниченное количество доступных букв дисков. В больших организациях постоянно приходится тасовать буквы дисков. “Для отдела проектировщиков буква диска Н указывает на совместный ресурс Drawings на сервере S23. Для отдела бухгалтерии буква диска Н указывает на общий ресурс Financial на сервере S13.”
В такой ситуации требуется структура, в которой общие ресурсы в пределах организации будут отображаться в едином логическом формате. В таком случае пользователь, которому ну^кна бухгалтерская информация, перейдет к папке Accounting, а не к какому-то серверу в Цинциннати.
PHX-SRV1
Сервер'данных.
Установлен в центральном офисе организации
D:\Finance
Доступен как ресурс FIN
PHX-SRV-05
Сервер данных. Установлен в офисе филиала
\Accounts Payable
>ступен как ресурс ар
Клиентский компьютер бухгалтера
Диск к: — подключение к ресурсу АР
Диск к: —подключениек ресурсу fin
Сервер баз данных и хранилища данных. Установлен в офисе филиала
D:\Accounts Receivable
Доступен как ресурс ar *~
Диск К: — подключениек ресурсу ar
PHX-SRV-11
Сервер данных.
Расположен в загородном офисе
MSA-SRV-24
F: Maxes
Доступен как ресурс tax
ДискN: — подключение к ресурсу tax
Рис. 16.9. Стандартная структура общих каталогов. Пользователь должен подключать каждый общий ресурс
Объединение общих ресурсов в единую согласованную структуру обеспечивается технологией, которая называется распределенной файловой системой (Distributed File System — Dfs). Компания Microsoft использует комбинацию букв верхнего и нижнего регистра (Dfs), чтобы отличать свой продукт от продукта компании IBM, Distributed File System — DFS.
В этом разделе рассматриваются принципы работы распределенной файловой системы и методы ее эффективного использования для упрощения доступа к ресурсам в сети предприятия/
Структура распределенной файловой системы
Если в двух словах, то распределенная файловая система определяет иерархию общих каталогов. Структура распределенной файловой системы имитирует стандартную структуру каталогов. Распределенную файловую систему можно рассматривать, как файловую систему, состоящую не из обычных каталогов, а из совместно используемых ресурсов.
На рис. 16.10 показано, как выглядят совместно используемые ресурсы в иерархии Dfs. Пользователь входит в структуру Dfs на вершине через единый сетевой диск и перемещается по дереву каталогов, как будто они находятся в пределах одной большой файловой системы на единственном сервере.
Распределенная файловая система позволяет организовать информацию в соответствии со структурой деятельности организации, а не отдела информационных технологий. Например, юридическая компания может структурировать распределенную файловую систему в соответствии с типами юридических процедур. Нефтяная компания может структурировать распределенную файловую систему в соответствии с бизнес-подразделениями — добывающая, перерабатывающая, транспортная и т.д. В таком случае пользователи не должны ничего знать об именах серверов и общих ресурсов. Пользователи просто найдут папку с интересующей их информацией и будут счастливы.
Сервер данных.
Установлен в центральном офисе организации
Рис. 16.10. Структура распределенной файловой системы, которая приходит на смену модели, ориентированной на серверы
На рис. 16.11 показана консоль Dfe, на которой изображены разные элементы архитектуры. Если бы распределенная файловая система была настоящей файловой системой, эту структуру можно было бы назвать томом. В распределенной файловой системе используется название пространство имен (namespace). Ниже перечислены основные элементы пространства имен распределенной файловой системы.
Корень распределенной файловой системы. Каждая файловая система должна иметь корень. Корень распределенной файловой системы хранится в общей папке на сервере. В доменной распределенной файловой системе копии корня можно хранить на нескольких серверах для обеспечения отказоустойчивости.
Связи. Распределенная файловая система состоит из виртуальных папок, которые представляют связи с реальными общими ресурсами на реальных серверах. Связь отображается в Explorer (Проводник) как стандартная папка.
Таблицы знаний о разделах. При подключении клиента к связи распределенной файловой системы клиенту выдается ссылка (referral) на настоящий общий ресурс соответствующего сервера. Ссылка имеет форму таблицы знаний о разделах, или просто таблицы разделов (Partition Knowledge Table — PKT). В таблице содержится информация о сервере и названии общего ресурса. Если для связи задано несколько серверов, в таблице знаний о разделах серверы сортируются по узлам, после чего предоставляются клиенту.
Цели распределенной файловой системы (Dfe target). Это новый термин распределенной файловой системы в операционной системе Windows Server 2003. Термин означает сервер или серверы, на которых хранится общий ресурс, указанный в связи распределен-
ной файловой системы (Dfs). Связь, содержащая несколько целей, называется реплицированной (replicated) связью. За синхронизацию данных между целями связи отвечает служба репликации файлов.
Рассмотрим эти элементы более подробно, чтобы понять, как клиенты перемещаются по структуре Dfs.
Тчч! ribul ed file System
^ Dtoixjted RIe System 1j В- Щ \\company,com\CompanyF^ Accounting^ Dtoixjted RIe System 1j В- Щ \\company,com\CompanyF^ Accounting^\\server3.company.com\Eng Й \\server2. company ,com\Eng ^\\Serverl\Eng^\\server3.company.com\Eng Й \\server2. company ,com\Eng ^\\Serverl\Eng
^ Dtoixjted RIe System 1j В- Щ \\company,com\CompanyF
^ Accounting
^ Dtoixjted RIe System 1j В- Щ \\company,com\CompanyF
^ Accounting
^\\server3.company.com\Eng Й \\server2. company ,com\Eng ^\\Serverl\Eng
^\\server3.company.com\Eng Й \\server2. company ,com\Eng ^\\Serverl\Eng
Puc. 16.11. Консоль DfsPuc. 16.11. Консоль Dfs
Puc. 16.11. Консоль Dfs
Puc. 16.11. Консоль Dfs
Корень Dfs
Структура пространства имен Dfs принимает форму набора каталогов на корневом сервере Dfs. Кроме этого, на корневом сервере хранится таблица знаний о разделах (РКТ), в которой хранятся указатели на папки в этой структуре, а также имена и совместно используемые ресурсы, которые представлены в виде папок. Существует два типа корня Dfs, которые отличаются местом хранения структуры корневой папки и таблицы РКТ.
Изолированный корень. Папки, представляющие пространство имен Dfs, хранятся на единственном корневом сервере. Информация таблицы РКТ хранится в системном реестре такого сервера. Если изолированный корневой сервер недоступен, становится недоступной и структура Dfs.
Доменный корень. Папки, представляющие пространство имен Dis, хранятся на нескольких серверах. Информация таблицы РКТ хранится в базе данных Active Directory и реплицируется на каждый контроллер в пределах домена. Такая схема обеспечивает отказоустойчивость, так как при недоступности одного из корневых серверов остальные серверы смогут передавать клиентам ссылки Dfs.
Несложно догадаться, что более предпочтительным вариантом является доменный корень. Но для доменного корня необходим домен Active Directory. Контроллер домена может работать как под управлением Windows Server 2003, так и под управлением Windows 2000. Распределенная файловая система Dfs полностью совместима между двумя операционными системами. Если используется классический домен Windows NT 4.0 или рабочие группы, придется использовать изолированный корень и самостоятельно обеспечивать его защиту от отказов и сбоев в работе сети.
Ограничения корня Dfs
В операционной системе Windows Server 2003 механизм работы распределенной файловой системы улучшен по сравнению с реализацией в операционной системе Windows 2000.
Это не относится к изолированным серверам распределенной файловой системы. Изолированный сервер распределенной файловой системы поддерживает только один корень.
Корень Dfs должен храниться в томе NTFS. Связи Dfs могут указывать на общие тома FAT и FAT32, но такое решение не рекомендуется из-за проблем в работе системы безопасности.
Хотя, на первый взгляд, это нельзя считать ограничением корня, в этом случае оказывается влияние на схему именования. Распределенная файловая система подчиняется тем же ограничениям, что и все операционные системы Windows. Длина пути не может превышать 260 байт. Используйте имена связей как можно меньшего размера, чтобы самая глубокая связь не превышала это ограничение на длину пути.
Совет по использованию системного реестра: информация о Dfs в системном реестре
Информация о распределенной файловой системе хранится в следующих разделах системного реестра.
HKLM\Software\Microsoft\DfsHost. В этом разделе хранится флаг, указывающий на наличие корня распределенной файловой системы на сервере.
HKLM\Sof tware\Microsof t\Dfs. В этом разделе хранятся имена корней, их общих ресурсов и, в случае изолированных корневых серверов, двоичные данные, необходимые для создания таблицы РКТ.
HKLM\Software\CurrentControlSet\Services\Dfs. В этом разделе хранятся конфигурация и информация о параметрах поставщика Dfs, Df ssvc. exe.
HKLM\Software\CurrentControlSet\Services\DfsDriver. В этом разделе хранятся конфигурация и информация о параметрах драйвера Dfs, of s. sys.
Связи Dfs
При подключении клиента к пространству имен Dfs клиент “видит” структуру папок, напоминающую структуру файловой системы (рис. 16.12).
“Папки” представляют собой указатели, которые называются связями (link), на реальные папки, хранящиеся на серверах в пределах всего предприятия. Распределенную файловую систему можно рассматривать как службу 411 для сетей. “Корень Dfs, чем могу помочь? Файлы бухгалтерского учета? Они хранятся на общем ресурсе Acct сервера S73.”
Как только клиент Dfs открывает папку Dfs, ему выдается ссылка (referral) на целевой сервер, на котором хранится запрошенный общий ресурс. Клиент переходит по ссылке и подключается непосредственно к интересующему серверу. Это защищает Dfs от превращения в узкое место сети. Клиент кэширует ссылки локально и не требует подключения к корню Dfs при повторном подключении к той же папке. Ссылка имеет принятое по умолчанию время жизни 30 минут. В окне Properties (Свойства) ссылки можно удалить вручную. Для этого необходимо активизировать вкладку Dfs и щелкнуть на кнопке Clear History (Очистить журнал).
Пользователь может подключить диск к корню пространства имен, и это будет единственная буква диска, которая потребуется для доступа к общим (совместно используемым) ресурсам. Для изолированного корня путь UNC будет выглядеть как \\<имя_сервера>\<имя_ KopHH_dfs>. В доменной распределенной файловой системе в пути UNC может использоваться имя домена, например \\<и^^я_дoмeнa>\<имя_кopня_dfs>. Клиент выполняет преобразование имени домена в имя сервера с копией корня, что позволит клиенту прочитать структуру папок распределенной файловой системы.
Например, на рис. 16.12 в качестве пути UNC к вершине пространства имен Dfs используется \\company.com\dfsroot. Этот путь можно использовать для монтирования дисков в регистрационном сценарии, что полностью устраняет необходимость монтирования дисков пользователем. Все счастливы: и пользователи, и служба поддержки.
i W Accountingi W Accounting. He E* Ww Favorites Vo*, H* vxJ Ba* - U - ^ 1 / Sw* :< - Folders , #* jt X JO , фе j;Attt«s|o\\^———; Foldersx .Desktop® ^My Documentsp® 5МУ ComputerpВ <УMy Network Placesк{ ВЙ Entire Networkк;93 ^ Mkrosoft Windows Network^j® V' companyrootкв BBBS99® Q Accts PayableI® Q Accts Receivable В TaxesIS Q) Engineering ® О HR'^ Recycle Bin|. He E* Ww Favorites Vo*, H* vxJ Ba* - U - ^ 1 / Sw* :< - Folders , #* jt X JO , фе j;Attt«s|o\\^———; Foldersx .Desktop® ^My Documentsp® 5МУ ComputerpВ <УMy Network Placesк{ ВЙ Entire Networkк;93 ^ Mkrosoft Windows Network^j® V' companyrootкв BBBS99® Q Accts PayableI® Q Accts Receivable В TaxesIS Q) Engineering ® О HR'^ Recycle Bin|Accts ReceivableAccts ReceivableL «jjatdL «jjatd
i W Accounting
i W Accounting
. He E* Ww Favorites Vo*, H* v
xJ Ba* - U - ^ 1 / Sw* :< - Folders , #* jt X JO , фе j;Attt«s|o\\^———
; Foldersx .
Desktop
® ^My Documentsp
® 5МУ Computerp
В <УMy Network Placesк
{ ВЙ Entire Networkк
;93 ^ Mkrosoft Windows Network^
j® V' companyrootк
в BBBS99
® Q Accts PayableI
® Q Accts Receivable В Taxes
IS Q) Engineering ® О HR'
^ Recycle Bin|
. He E* Ww Favorites Vo*, H* v
xJ Ba* - U - ^ 1 / Sw* :< - Folders , #* jt X JO , фе j;Attt«s|o\\^———
; Foldersx .
Desktop
® ^My Documentsp
® 5МУ Computerp
В <УMy Network Placesк
{ ВЙ Entire Networkк
;93 ^ Mkrosoft Windows Network^
j® V' companyrootк
в BBBS99
® Q Accts PayableI
® Q Accts Receivable В Taxes
IS Q) Engineering ® О HR'
^ Recycle Bin|
Accts Receivable
Accts Receivable
L «jjatd
L «jjatd
^3 objectsiii bytes jjfiHemst^
Puc. 16.12. Пространство имен Dfs в Explorer (Проводник)
Поскольку Dfs предоставляет ссылки, а не реальное соединение, целевой сервер необязательно должен работать под управлением операционной системы Windows Server 2003. Если клиент использует подходящий перенаправитель, целевой ресурс может быть томом NetWare, диском Banyan, томом NFS на узле UNIX и т.д.
Исключением являются клиенты более старых версий под управлением Windows 9х и Windows ME. Эти клиенты принимают ссылки только на серверы SMB. Например, для подключения клиентов более старых версий к серверу NetWare придется воспользоваться сервером Windows, как шлюзом в сеть NetWare. Шлюзы работают невероятно медленно и часто непредсказуемы, поэтому такой конфигурации стоит избегать. Клиенты под управлением Windows NT 4.0 принимают ссылки не только на ресурсы SMB, поэтому для них шлюз не требуется.
Ограничения связей Dfs
Самым заметным ограничением связей Dfs является невозможность создания дочерних связей для существующей связи. Например, если существует связь HR, которая указывает на ресурс \\S2 3 \HR, создать еще одну связь в папке HR, которая будет указывать на другой ресурс, на удастся. Другими словами, пространство имен Dfs имеет только один уровень вложенности.
При этом поддерживается создание связей между корнями Dfs или связей с папкой в пространстве имен другого корня Dfs. Это позволяет создать основное пространство имен распределенной файловой системы, в котором будут находиться другие пространства имен (рис. 16.13).
На рисунке показан корень Dfs верхнего уровня, который называется Df sroot и хранится на сервере S1. Связь Acct указывает на другой корень Dfs, который называется Бухгалтерия и хранится на сервере S2 0. При подключении пользователя к пространству имен Wcompany. com\df sroot в окне Explorer (Проводник) корень Бухгалтерия будет показан как папка в пространстве имен. Если пользователь выполнит двойной щелчок на папке Бухгалтерия, клиент распределенной файловой системы получит ссылку на корень, расположенный на сервере S2 0.
Возможность создания связи с другим корнем Dfs позволяет создать иерархию внутри пространства имен Dfs. Но это значит, что корни придется внимательно проектировать, чтобы их структура соответствовала структуре организации. Например, в университете могут использо-
ваться отдельные корни Dfs для разных подразделений (например, Студенты, Выпускники, Факультеты), а также главный корень Dfs, в котором созданы связи со специализированными корнями. Пользователям можно предоставить регистрационный сценарий, который подключает главный или специализированные корни Dfs в зависимости от их потребностей и обстоятельств.
Корень DfsКорень DfsУстановлен в центральномУстановлен в центральномPHX-DC01PHX-DC01OCompanyRoot
Корень Dfs
Корень Dfs
Установлен в центральном
Установлен в центральном
PHX-DC01
PHX-DC01
Отдел кадровОтдел кадровРис. 16.13. Связи с другим корнем Dfs позволяют создать многоуровневое пространство имен DfsРис. 16.13. Связи с другим корнем Dfs позволяют создать многоуровневое пространство имен DfsДоступен как ресурс CompanyRoot
Отдел кадров
Отдел кадров
Рис. 16.13. Связи с другим корнем Dfs позволяют создать многоуровневое пространство имен Dfs
Рис. 16.13. Связи с другим корнем Dfs позволяют создать многоуровневое пространство имен Dfs
Создание структуры пространства имен
Если необходимо сохранить единое пространство имен распределенной файловой системы (без альтернативных корней), ограничение на один уровень вложенности можно обойти с помощью творческого назначения имен для связей.
Например, предположим, что в организации существует отдел кадров (HR) с тремя подразделениями: Americas, Asia и Europe. Три подразделения хранят свои файлы на отдельных серверах, и необходимо собрать общие ресурсы в одной папке Dfs, которая называется HR.
Для этого связям можно присвоить иерархические имена. Например, можно назвать связи следующим образом:
HR\Americas -> доступна как -> \\S23\HR-Americas
HR\Asia -> доступна как -> \\S372\HR-PacRim
HR\Europe -> доступна как -> \\S105\HR-EU
Когда эти связи будут показаны пользователю, они будут выглядеть как один общий каталог HR с тремя подкаталогами в корне Dfs.
Эта хитрость не позволяет построить иерархию с тремя уровнями вложенности. В этом примере нельзя создать связи с именем HR\America\Contractors. Система выдаст сообщение о том, что такая связь уже существует.
По этой причине схему именования стоит хорошо обдумать еще до реализации Dfs. Для выполнения настроек за половину дня требуется подготовка в течение нескольких месяцев. Но это время не будет потрачено впустую, так как пользователям понравится новый простой доступ к файлам.
Таблица знаний о разделах
В таблице знаний о разделах (РКТ) хранятся имя корня Dfs и имена корневых серверов. Кроме этого, в таблице хранится список связей Dfs и соответствующих этим связям целевых серверов. Несложно представить, что этот список может стать достаточно большим, если связей и копий достаточно много. Информация хранится в формате Unicode, поэтому каждая запись занимает в два раза больше места, чем можно предположить, подсчитав количество символов.
На сервере изолированного корня Dfs таблица РКТ хранится в системном реестре. В доменной Dfs информация из таблицы знаний о разделах хранится в базе данных Active Directory. Каждый корень Dfs представлен объектом FTDf s, который имеет атрибут РКТ.
Размер структуры Dfs ограничен максимальным размером таблицы РКТ. Для доменной Dfs компания Microsoft рекомендует использовать атрибут РКТ размером до 5 Мбайт. Этот размер позволяет хранить 5000 связей максимальной длины пути. Если не использовать максимальную длину пути, в атрибуте поместится намного больше связей, хотя управлять несколькими тысячами связей очень сложно. Даже открытие консоли Dfs будет занимать длительное время.
Слишком большая структура Dfs может привести к проблемам при репликации. При каждом изменении Dfs, затрагивающем таблицу РКТ, база данных Active Directory должна будет реплицировать весь атрибут РКТ. Если атрибут имеет размер 3-4 Мбайт и содержит тысячи связей и копий связей, репликация отнимет заметную долю пропускной способности сети, так как атрибут придется копировать на каждый контроллер домена. Кроме этого, при наличии большого количества связей слишком долго запускается сервер корня Dfs.
Размер изолированной Dfs ограничен пространством системного реестра, выделенным для хранения таблицы РКТ. В предыдущих версиях операционной системы Windows это ограничение составляло около 13 Мбайт, исходя из максимального размера раздела System. Раздел System не может быть больше 16 Мбайт. Это ограничение связано с технологией процесса загрузки Windows. Ограничение в 13 Мбайт соответствует размеру, необходимому для хранения 10 000 связей с максимальной длиной пути.
В операционной системе Windows Server 2003 информация из таблицы знаний о разделах хранится в разделе Software. Компания Microsoft все равно рекомендует не превышать ограничение в 10 000 связей для изолированного корня.
При подключении клиента к распределенной файловой системе выдаваемая ссылка извлекается из таблицы РКТ. Вся таблица знаний о разделах не передается, а передается только тот фрагмент, в котором содержится информация о запрошенной клиентом связи. Клиент кэширует эту информацию для ускорения последующего доступа к этой же связи.
Для просмотра содержимого кэша таблицы РКТ можйо воспользоваться утилитой df sutil из состава Support Tools. Для этого необходимо воспользоваться командой dfsutil / pkt inf о. Рассмотрим пример листинга для ситуации, когда пользователь подключался к связи Highways, которая имеет две копии (флаг Active указывает на копию, которая используется клиентом).
C:\Program Files\Support Tools>dfsutil /pktinfo
—mup.sys— 1 enties . . . Entry: \Company.com\Engineering\Highways ShortEntry: \Company.com\Engineering\Highways Expires in 300 seconds UseCount: 0 Type: 0x1 (DFS)
0:[\S2\highways] State:0x21 ()-
1:[\S4\highways] State:0x31 (ACTIVE)
Подобная информация из таблицы PKT требуется не очень часто, но знать о доступных инструментах диагностики никогда не помешает. Умея пользоваться этими инструментами, можно быстро решить проблему в работе Dfs, пока другие администраторы будут чесать затылки. Просмотр информации из таблицы РКТ позволяет быстро понять, что клиент не получает необходимую информацию, имеет просроченную ссылку или сталкивается с другими проблемами при получении информации о связи.
Множественные цели Dfs
Ранее было сказано, что Dfs можно представить в роли оператора справочной службы. На самом деле распределенная система больше похожа на секретаря в приемной, так как она может принять решение о перенаправлении входящего звонка: “Вам нужен вице-президент по продажам? Это мисс Проктор, но ее нет. Я дам вам номер ее помощника, мистера Гембла”. (В отличие от настоящего секретаря Dfs не создает подключения для клиентов. Клиент должен сам проследовать по ссылке.)'
Информация о цели хранится в таблице РКТ. Если та или иная связь указывает более чем на одну цель, Dfs возвращает информацию из таблицы РКТ для всех целей. Клиент сам выбирает интересующую его цель. Существуют две версии Dfs и каждая обрабатывает такую ситуацию по-своему. Дополнительная информация о выборе цели приводится далее.
Если указана связь на несколько целей, предполагается, что в каждой цели доступна одна и та же информация. Задача синхронизации целей возлагается на службу репликации файлов (File Replication Server — FRS). Это та же служба репликации файлов, которая используется для синхронизации содержимого папки Sy svol на всех контроллерах в пределах домена.
Служба репликации файлов и Dfs
Служба репликации файлов (FRS) представляет собой универсальную службу синхронизации файлов. Перечислим несколько особенностей этой службы.
Механизм службы FRS поддерживает многопоточную обработку. По умолчанию между партнерами по репликации могут передаваться восемь файлов одновременно.
Репликация основана на уведомлениях. Партнеры по репликации не опрашивают друг друга в поисках изменений.
Серверы FRS уведомляют своих партнеров по репликации сразу же при изменении в файлах. Пятиминутная задержка, как при репликации Active Directory, отсутствует. Партнеры по репликации загружают изменения сразу же после получения уведомления.
Если изменилась любая часть файла, передается весь файл целиком.
Служба FRS использует Remote Procedure Call (RPC) для внутрисайтовой и межсайтовой репликации. Использование протокола SMTP не поддерживается.
В операционной системе Windows 2000 служба репликации файлов использовала ту же топологию связей, что и Active Directory. Это было неэффективно при перемещении больших объемов данных между копиями Dfs в разных узлах. В операционной системе Windows Server 2003
служба репликации файлов была значительно улучшена для совместимости с Dfs. В новой версии поддерживается управление топологией репликации для каждой связи Dfs.
Топология службы репликации файлов может настраиваться двумя способами. При первом способе во время определения дополнительной цели связи система автоматически запускает мастер настройки репликации (Configure Replication Wizard) для настройки службы репликации файлов. Мастер пытается получить у администратора два важных элемента информации.
Имя “главного” сервера для начальной репликации
Топология репликации
“Главный” сервер предоставляет файлы для начальной репликации. После передачи файлов понятия “главного” и “подчиненного” серверов теряют значение. Изменения на любом сервере реплицируются на остальные серверы.
Если вторичный сервер уже содержит файлы в интересующей папке, настройка репликации для этой папки может таить неожиданные моменты. Для предотвращения перезаписи файлов служба репликации файлов копирует их в скрытую папку NTFrs_PreExisting See_EventLog. Поскольку это скрытая папка, можно подумать, что служба репликации файлов удалила существовавшие файлы. Файлы в папке NTFrs_PreExistingSee_EventLog не предназначены для удаления, хотя в журнале событий сообщается о последующем удалении этих файлов. На рис. 16.14 показан пример записи в журнале событий.
Если необходимо сохранить файлы, которые изначально хранились в папке на вторичном сервере, скопируйте файлы в главную папку после выполнения первичной репликации. Из этой папки служба FRS реплицирует файлы на “главный” сервер.
Рис. 16.14. Запись в журнале событий, в которой сообщается о перемещении существующих файлов в папку NTFrs_PreExisting_ _See_EventLog
Топология репликации службы FRS
Вторая функция мастера настройки репликации предназначена для выбора топологии репликации. Это новая возможность, которая появилась в операционной системе Windows Server 2003. Топологию репликации можно настраивать для каждой связи Dfs отдельно.
Как и при репликации Active Directory, все подключения службы FRS соответствуют входящим потокам данных. Сервер уведомляет партнера о наличии изменившихся файлов. Партнер загружает файлы в процессе транзакции репликации. На рис. 16.15 в окне Properties (Свойства) показана топология репликации для связи Dfe с несколькими целями. В окне доступны следующие варианты топологии.
(ustomizc I opoloyy
¥**W*«<f*alw*oo**Wiw<N*^6^
<еЙ»**"**1И«1*|**1**«***
3 я*# I
Fuimesh ’
End*.. JfWSesiij.TeteiiLJfi*»®» DoS* j И И И И И
serverl.co... SERVER»... serverl.co... SERVER?.... SERVER2... SERVERS.... SERVER?.... serverl.co... SERVERS... serverl.co... SERVERS.... SERVERS...serverl.co... SERVER»... serverl.co... SERVER?.... SERVER2... SERVERS.... SERVER?.... serverl.co... SERVERS... serverl.co... SERVERS.... SERVERS...Derautrss... Deradt-Firs... % Defedt-Fis... Default-Firs... Deladt-Firs... Default-Firs Default-Firs... Defadt-Frs.. Default-Firs... Default-Firs... Defadt-Fiis... Default-Firs...Derautrss... Deradt-Firs... % Defedt-Fis... Default-Firs... Deladt-Firs... Default-Firs Default-Firs... Defadt-Frs.. Default-Firs... Default-Firs... Defadt-Fiis... Default-Firs...NVNV- Я
serverl.co... SERVER»... serverl.co... SERVER?.... SERVER2... SERVERS.... SERVER?.... serverl.co... SERVERS... serverl.co... SERVERS.... SERVERS...
serverl.co... SERVER»... serverl.co... SERVER?.... SERVER2... SERVERS.... SERVER?.... serverl.co... SERVERS... serverl.co... SERVERS.... SERVERS...
Derautrss... Deradt-Firs... % Defedt-Fis... Default-Firs... Deladt-Firs... Default-Firs Default-Firs... Defadt-Frs.. Default-Firs... Default-Firs... Defadt-Fiis... Default-Firs...
Derautrss... Deradt-Firs... % Defedt-Fis... Default-Firs... Deladt-Firs... Default-Firs Default-Firs... Defadt-Frs.. Default-Firs... Default-Firs... Defadt-Fiis... Default-Firs...
NV
NV
СО E-£J
Puc. 16.15. Варианты топологии службы FRS
■ Кольцо (Ring). Эта же топология используется в Active Directory для межсайтовой репликации, но соединения службы FRS могут не совпадать с подключениями КСС. Кольцо позволяет эффективно использовать пропускную способность с небольшим временем сходимости.
■ Полная сеть (Full Mesh). Эта топология позволяет минимизировать время сходимости за счет использования максимальной пропускной способности. Такая топология должна использоваться только в том случае, если сетевые соединения в состоянии пропустить весь объем передаваемых данных.
■ Звезда. Чтобы выбрать эту топологию, необходимо выбрать один сервер, который будет выступать в роли “концентратора”. Остальные серверы будут реплицировать файлы с концентратора. Эта топология позволяет максимально эффективно использовать пропускную способность внешних соединений. Но если откажет сервер-концентратор, репликация станет недоступной для всей системы.
■ Заказная. В этом случае можно создать собственную топологию репликации, которая соответствует структуре вашей сети. При создании связей необходимо следить, чтобы отказ одной связи не приводил к отключению слишком большого количества серверов.
Репликация Active Directory через внешние соединения обрабатывается с помощью сайтов. Сайт соответствует области надежных и высокоскоростных сетевых соединений. Соединения между сайтами определяются связями сайтов, которые используются для управления пропускной способностью сети.
Заданная для службы FRS топология позволяет распознать, что серверы находятся на разных сайтах, но эта информация никак не используется. Если определить топологию полной сети для определенной связи, репликация между серверами будет выполняться независимо от структуры сайтов. При репликации по FRS для всех транзакций используется протокол RPC.
Анализ отказа целевого сервера Dfs
Наличие нескольких копий данных на разных серверах увеличивает отказоустойчивость. Если сервер отказывает, клиент Dfs обращается к другому серверу для получения тех же данных.
Фактическая последовательность событий при отказе сервера зависит от природы отказа и действий клиента во время отказа сервера. Рассмотрим несколько вариантов.
Если клиент уже подключен к серверу на момент его отказа, система обнаруживает проблему немедленно и выбирает новый целевой сервер из ссылки в кэшированной записи таблицы РКТ.
Если во время отказа сервера клиент выполняет переход по пространству имен Dfs, клиент ожидает превышения допустимой задержки, предполагая, что задержка вызвана работой сети. После завершения допустимого времени ожидания клиент выбирает другой целевой сервер из ссылки в кэшированной записи таблицы РКТ.
Если во время отказа сервера пользователь уже открыл данные и пытается их сохранить, система пытается переключить клиента на альтернативный сервер. В этот период времени приложение становится недоступным для пользователя (отображается курсор в виде песочных часов). После завершения переключения файл сохраняется на альтернативном сервере и клиент продолжает нормальную работу.
Для просмотра сервера распределенной файловой системы, который был выбран клиентом для определенной связи, можно воспользоваться командой Properties (Свойства) для связи, доступной в Explorer (Проводник). Информация предоставляется на вкладке Dfs (рис. 16.16).
— I
^^' ‘. IJW* L SWw
«J^XSERVERIVacd No«JWSERVER2 compel No
Puc. 16.16. Свойства связи Dfs на вкладке Dfs
Если необходимо сменить целевой сервер, закройте все файлы, выделите интересующий сервер в окне Properties (Свойства) на вкладке Dfs и щелкните сначала на кнопке Clear History (Очистить журнал), а потом на кнопке Set Active (Сделать активным). Открытый с помощью связи файл будет находиться на выбранном сервере.
В составе Windows Server 2003 Resource Kit предоставляется утилита Sonar, которая отображает сведения о текущем состоянии партнеров по репликации для службы FRS, а также позволяет определить партнеров, репликация с которыми завершилась неудачно. При первой же проблеме в работе службы FRS необходимо установить эту бесценную утилиту устранения несправностей.
Ограничения множественных целей Dfs
Перед тем как радоваться возможностям создавать огромные полностью избыточные файловые системы на основе Dfs, стоит ознакомиться с рядом ограничений.
Во-первых, служба FRS работает только на серверах под управлением операционной системы Windows Server 2003 и/йли Windows 2000. В топологию службы репликации файлов нельзя включать серверы сторонних производителей или серверы под управлением операционной системы Windows более старых версий.
Во-вторых, служба репликации файлов синхронизирует данные между копиями, но не обеспечивает репликацию дескрипторов безопасности. Права доступа придется устанавливать в каждой копии отдельно. Обычно для этого достаточно установить набор прав доступа в корневом каталоге. Права доступа будут унаследованы дочерними файлами и каталогами. Внимательно документируйте внесенные изменения, поскольку их необходимо внести во все копии.
В-третьих, не разрешайте кэширование папки Dfs на стороне клиента. Дополнительная информация о кэшированнии на стороне клиента приведена в главе 19, “Управление операционной средой пользователя", но здесь будут указаны причины, почему этого не стоит делать для Dfs.
Кэширование на стороне клиента позволяет пользователю “приколоть” файлы таким образом, чтобы они кэшировались на компьютере пользователя и оставались доступными даже во время автономной работы. Предположим, что пользователь делает автономными несколько файлов из удаленной папки, которая оказывается связью Dfs. Файлы хранятся на сервере S1, а копия файлов хранится на сервере S2. Предположим, что сервер S1 отказал. Служба диспетчера синхронизации (Synchronization Manager) на стороне клиента обнаруживает, что соединение оборвано, и переключает клиент на работу с локальной версией файла. В это же время клиент Dfs обнаруживает оборванное соединение и переключает клиент на сервер S2.
При последующем включении сервера S1 диспетчер синхронизации (Synchronization Manager) выполнит репликацию локальных изменений, поэтому потери данных не возникнет. Но это будет сложный период для нервной системы пользователя и для оператора службы поддержки, которому придется успокаивать этого пользователя.
Последним и самым важным ограничением при использовании репликации серверов Dfs является одновременное использование файлов. Служба репликации файлов отлично справляется с синхронизацией данных, но служба не предназначена для синхронизации состояния файлов. Это значит, что блокировки файлов не реплицируются. Кроме этого, не существует центральной базы данных с блокировками файлов и другой информацией о состоянии файлов. Это значит, что совместного использования файлов стоит избегать. Несколько пользователей могут открыть один и тот же файл на разных серверах. При обновлении файлов они перезапишут изменения друг друга.
Отсутствие распределенных блокировок файлов является серьезным недостатком Dfs только в том случае, если хранящиеся файлы используются несколькими пользователями. Но репликация файлов между серверами отлично подходит для хранения файлов с неизменным содержимым (выполняемые файлы) или файлов, к которым получает доступ только один пользователь. Распределенную файловую систему можно использовать для распространения файлов служб удаленной установки, что позволит хранить в каждом офисе полный установочный пакет программного обеспечения.
Проектирование нескольких целей Dfs
Принимая решение о том, какие данные подходят для хранения на серверах Dfs, попытайтесь обеспечить защиту файлов от одновременного доступа. Если такая защита невозможна, максимально сократите количество пользователей, которые могут обращаться к файлам в од-
ни и те же моменты времени. Оставшихся пользователей можно будет обучить особенностям и ограничениям механизмов блокировки файлов.
Перечислим подходящих кандидатов на использование нескольких целей Dfs.
Web-страницы (если они управляются небольшой группой Web-мастеров)
Выполняемые файлы
Политики компании, стандарты и процедуры (владельцы которых понимают ограничения на одновременное использование)
Домашние каталоги пользователей, перемещаемые профили и перенаправляемые папки (за исключением пользователей портативных компьютеров и других пользователей с автономными файлами в персональных папках)
А теперь перечислим компоненты, которые никогда не должны храниться в связях Dfs с несколькими целями.
Базы данных (если это не личная база данных, доступная только одному пользователю)
Файлы для совместной работы, например документация рабочего процесса и связанные файлы в базе данных Lotus Notes или SharePoint Portal Server
Файлы данных, доступные нескольким членам одного отдела или рабочей группы
Функциональный обзор ссылок Dfs
При обращении сетевого клиента к связи Dfs служба Dfs, запущенная на хосте, возвращает клиенту ссылку. Ссылка содержит запись таблицы РКТ для соответствующей связи. В записи указывается истинное расположение цели или целей. Клиент выбирает цель (если предоставлено больше одной цели) и устанавливает соединение.
Существует две версии Dfs. В операционных системах Windows NT 4.0, Windows 9х и Windows Me используется распределенная файловая система версии 2. В операционной системе Windows 2000 и в более поздних версиях Windows используется версия 3. Версии обратно совместимы между собой, поэтому клиент Windows 2000 может подключаться к корню Dfs под управлением операционной системы Windows NT 4.0, и наоборот.
От номера версии зависит способ начального соединения клиента с томом Dfs. Кроме этого, в разных версиях используются разные варианты балансировки нагрузки.
Опрос поставщика MUP
Когда клиент SMB пытается получить доступ к папке с помощью пути UNC, поставщик MUP (Multiple UNC Provider) опрашивает сетевые перенаправители в поисках перенаправителя, способного связаться с запрошенным сервером. Это первый случай, в котором разные версии Dfs ведут себя по-разному.
Windows Server 2003, Windows ХР и Windows 2000. На клиентах Dfs версии 3 поставщиком MUP всегда сначала опрашивается поставщик Dfs, чтобы выяснить, не подключен ли общий каталог к Dfs. Если это так, драйвер Dfs обрабатывает ссылку с информацией из таблицы РКТ, полученную от корневого сервера Dfs. Если совместно используемый ресурс не связан с Dfs, поставщик Dfs превышает допустимое время ожидания и поставщик MUP продолжает опрос следующих поставщиков в порядке привязки.
Классические операционные системы Windows. На клиентах Dfs версии 2 поставщиком MUP сначала опрашивается стандартный поставщик SMB для получения атрибутов запрошенного общего ресурса. Если используется Dfs, этот запрос завершается неудачно, поскольку связи Dfs не обладают атрибутами общего ресурса. После этого поставщик MUP проверяет путь UNC, предполагая, что пользователь неправильно ввел имя сервера.
Эта проверка также завершается неудачно, поскольку точка соединения Dfs не предоставляет стандартный путь к общей папке. Наконец, поставщиком MUP опрашивается поставщик Dfs при попытке получить ссылку Dfs. В ответ на запрос сервер вернет информацию из таблицы РКТ..
Основным результатом этого отличия является большая задержка при подключении к папкам Dfs с помощью клиентов более старых версий.
Выбор цели’
Второе отличие между версиями Dfs влияет на балансировку нагрузки, так как изменился механизм выбора запрошенного (целевого) сервера.
Windows Server 2003, Windows ХР и Windows 2000. Серверы под управлением современных версий операционной системы Windows в ответ на запросы современных клиентов Windows возвращают список ссылок, в котором серверы из локального сайта находятся в начале списка. Это так называемый управляемый список (managed list). Клиент Dfs выбирает сервер на вершине списка ссылок. Если ответ сервера получить не удается, клиент переходит к следующему серверу из списка.
Классические операционные системы Windows. Серверы под управлением Windows NT 4.0 и Windows 9х, а также современные серверы Windows при ответе на запрос клиента более старой версии возвращают ссылки в том порядке, в котором они хранятся в системном реестре или в Active Directory. Клиент случайным образом выбирает одну из ссылок. Это ' значит, что классический клиент может получить ссылку на сервер из другого сайта. Чтобы этого избежать, можно загрузить заплатку dsclient на клиенты под управлением Windows 9х и заплатку Active Directory на клиенты под управлением Windows NT 4.0.
Кроме этого, клиент сообщает серверу Dfs о невозможности найти указанный в ссылке хост. Сообщение протокола SMB Report Dfs Inconsistency помогает при очистке системы от поврежденных связей. Но использовать этот механизм необязательно, поэтому иногда система не в состоянии определить, что связь разорвана.
После получения клиентом информации из таблицы РКТ в ссылке от сервера клиент кэширует эту информацию на время, указанное в параметре Time-to-Live (TTL) в записи таблицы. Значение этого параметра можно настроить на консоли Dfs. Откройте окно свойств связи и измените значение параметра Amount Of Time Clients Cache This Referral (in seconds). По умолчанию используется 30-минутный интервал кэширования (1800 секунд). Это достаточно короткий интервал, чтобы обеспечить гибкость при перемещении целевых серверов, и достаточно долгий, чтобы уменьшить нагрузку на сервер Dfs.
Проектирование пространства имен Dfs
При создании пространства имен Dfs начинайте с имени корня предприятия. Пользователи будут видеть это имя не очень часто, так как подключение сетевого диска будет выполняться в регистрационном сценарии. Обычно используется имя Df sroot.
Затем необходимо принять решение о правилах именования основных информационных узлов в пределах предприятия. В идеальном случае структура тома должна соответствовать логической структуре предприятия, чтобы пользователи могли легко перемещаться по распределенной файловой системе, как по структуре своей организации.
Метод создания связей согласно выполняемых функций предполагает создание связи верхнего уровня для каждого крупного отдела, например Accounting (Acct), Engineering (Eng) и Sales, а также создание связей верхнего уровня для хранилища политик, стандартов, Web- страниц и другой совместно используемой информации. Помните о необходимости использования коротких имен, чтобы длина пути не превышала 260 символов.
Кроме этого, могут потребоваться связи для работы отдела информационных технологий, например связь SoftDistro для распространения приложений, связь Apps для хранения серверных приложений, связь Web для хранения файлов Интернет и внутрисетевых файлов и связь Users для хранения домашних каталогов пользователей, перемещаемых профилей и перенаправляемых папок.
Можно создать отдельные корни для каждого элемента верхнего уровня и добавить связи в основной корень Dfs. Производительность не пострадает, но некоторая задержка будет наблюдаться при подключении пользователей с помощью связи между разными корнями Dfs.
Корни Dfs всегда должны реплицироваться на два или три дополнительных сервера для обеспечения отказоустойчивости. В корне Dfs практически отсутствуют файлы, поэтому для сокращения времени сходимости можно использовать топологию, при которой все компьютеры сети непосредственно соединены друг с другом.
Связи, содержащие файлы одного пользователя (или файлы небольшой группы грамотных администраторов), также являются кандидатами на хранение данных на нескольких серверах (т.е. могут стать множественными целями) для обеспечения избыточности и добавления на сайты.
Развертывание Dfs
Наибольшая гибкость и надежность обеспечиваются доменной Dfs. Если выбрать использование изолированного корня, параметры конфигурации будут такими же, но не будут поддерживаться следующие возможности.
Несколько корневых серверов
Несколько целевых серверов для связи
Доступ к копии в пределах сайта
Централизованное именование на основе домена (клиенты должны непосредственно указывать имя сервера)
Рассмотрим этапы развертывания доменной Dfs. Рассмотрим этот список прежде чем переходить к конкретным последовательностям действий.
Определите серверы, на которых будут храниться корни Dfs. Это не обязательно должны быть контроллеры домена, но сервер должен обязательно входить в домен. Домен может работать в режимах Mixed и Native.
Создайте общую папку на сервере Dfs, которая будет выступать в роли корня Dfs. Избегайте размещения файлов в этом томе. Храните файлы на связанных совместно используемых ресурсах. Некоторые администраторы в корне Dfs размещают небольшой текстовый файл или Web-страницу с инструкциями по навигации.
Создайте корень Dfs. Можно использовать любое имя, поскольку пользователи это имя практически не видят.
Назначьте дополнительные серверы корня. Это резервные серверы для хранения корня Dfs.
Создайте связи Dfs для совместно используемых ресурсов. Том распределенной файловой системы не содержит файлов. Необходимо добавить связи для общих папок, хранящихся на других серверах. Это позволяет структурировать Dfs в соответствии с планом проектирования.
Назначьте дополнительные цели связей. Если совместно используемые ресурсы иденти- фицирюваны, как потенциальные кандидаты для реплицированных связей, создайте общие папки на дополнительных серверах и задайте дополнительные цели.
Создание корня Dfs
Для создания всех корней и связей и управления ими можно применить консоль Dfs, файл Dfsgui.msc. Для запуска консоли воспользуйтесь командой Start^Programs^Administrative Tools^Distributive File System (Пуск^Программы^Администрирование^ОРБ). Кроме этого, можно воспользоваться утилитой df scmd, которая запускается из командной строки.
После завершения проектирования пространства имен воспользуйтесь процедурой 16.6 для начала развертывания распределенной файловой системы.
Процедура 16.6. Создание корня распределенной файловой системы
Откройте консоль Dfs.
Щелкните правой кнопкой мыши на пиктограмме Distributed File System (Распределенная файловая система) и выберите из контекстного меню New Root (Создать корень). Откроется окно New Root Wizard (Мастер создания нового корня).
Щелкните на кнопке Next (Далее). В открывшемся окне Root Туре (Тип корня) выберите переключатель Domain Root (Доменный корень).
Щелкните на кнопке Next (Далее). Откроется окно Host Domain (Домен хранения). Выберите домен, в котором будет храниться информация таблицы знаний о разделах для распределенной файловой системы. Корневые серверы должны входить в домен.
Щелкните на кнопке Next (Далее). Откроется окно Host Server (Сервер хранения). Введите полностью определенное имя DNS корневого сервера Dfs или щелкните на кнопке Browse (Обзор), чтобы найти сервер самостоятельно. В этом случае поиск выполняется в базе данных Active Directory. Браузер для этого не используется. Такой механизм обеспечивает выбор серверов из соответствующего домена. Сервер необязательно должен быть контроллером домена.
Щелкните на кнопке Next (Далее). Откроется окно Root Name (Имя корня). Введите выбранное имя корня Dfs. В поле Preview (Предварительный просмотр) будет показано имя UNC, а в поле Share То Be Used (Общий ресурс) будет показано “плоское” имя ресурса, который будет создан на корневом сервере.
Щелкните на кнопке Next (Далее). Если на корневом сервере еще нет ресурса, откроется окно Root Share (Общий ресурс для корня). Введите полный путь к папке, например D: \Df sroot. Если папка еще не существует, она будет создана.
Щелкните на кнопке Finish (Готово). Мастер предоставляет выбранную папку для совместного доступа и создает корень Dfs. Для этого в локальный системный реестр вносятся соответствующие записи и в базе данных Active Directory создается объект FTDfs.
Создание связей Dfs
На этом этапе пространство имен Dfs напоминает только что отформатированный жесткий диск: существует корневой каталог, не существует данных. Пришло время создать связи для совместно используемых ресурсов в соответствии с проектной документацией. Откройте консоль Dfs и выполните действия, приведенные в процедуре 16.7.
Процедура 16.7. Создание связей Dfs
Щелкните правой кнопкой мыши на пиктограмме корня Dfs и из контекстного меню выберите команду New Link (Создать связь). Откроется окно New Link (Создать связь), которое показано на рис. 16.17.
Рис. 16.17. В окне New Link (Создать связь) отображаются поле Link name (Имя связи) и совместно используемый ресурс, на который ссылается связь
Введите имя связи в поле Link Name (Имя связи). Это имя будет отображаться при просмотре содержимого Dfe.
Введите путь UNC к совместно используемому ресурсу на сервере в поле Path to target (Путь к целевой общей папке) или воспользуйтесь кнопкой Browse (Обзор). Поиск будет выполняться в списке просмотра окна Му Network Places (Мое сетевое окружение). Помните, что, если клиенты работают под управлением Windows NT 4.0 или более поздних версий, цель связи не обязательно должна работать под управлением Windows.
Щелкните на кнопке ОК, чтобы сохранить изменения и добавить связь в Dfs.
Теперь пользователи могут просматривать содержимое папки с помощью Dfs. Можно создать дополнительные связи для других совместно используемых ресурсов, и эти папки будут автоматически добавлены в пространство имен.
Если необходимо удалить папку из Dfs, достаточно удалить соответствующую связь. Папка исчезнет из списка, но данные не пострадают.
Назначение дополнительных целей для связей
Если для одного из предоставляемых в совместный доступ ресурсов планируется создать реплицированную связь, создайте совместно используемый ресурс на вторичном сервере и выполните последовательность действий, приведенную в процедуре 16.8. В этой процедуре рассматривается настройка службы репликации файлов (служба FRS).
Процедура 16.8. Назначение дополнительных целей для связей Dfs
На консоли Dfs щелкните правой кнопкой мыши на связи, которую необходимо реплицировать, и из контекстного меню выберите команду New Target (Создать целевую связь). Откроется окно New Target (Создание целевой связи).
Введите путь UNC к совместно используемому ресурсу на вторичном сервере или щелкните на кнопке Browse (Обзор), чтобы выполнить поиск интересующего ресурса вручную.
Установите флажок Add This Target То The Replcation Set (Добавить целевую связь в набор репликации).
Щелкните на кнопке ОК. Если система обнаружит совместно используемый ресурс, будет выдано сообщение The target cannot be replicated until replication is configured. Do you want to configure it now? (Цель не может быть реплицирована до настройки репликации. Настроить репликацию?).
Щелкните на кнопке Yes (Да). Запустится мастер настройки репликации (Configure Replication Wizard).
Щелкните на кнопке Next (Далее). В этом окне показаны пути UNC для исходной связи и новой цели. Выделите цель, которая должна стать основной (с этого сервера файлы будут копироваться на другие серверы).
- Щелкните на кнопке Next (Далее). Выберите топологию. По умолчанию используется топология “кольцо”.
Щелкните на кнопке Finish (Готово). Теперь две цели показаны в правой панели окна. Для связи используется пиктограмма, которая обозначает существование нескольких целей.
Воспользуйтесь этой процедурой для добавления дополнительных целей для связи. Новые цели будут добавлены в топологию репликации службы FRS. Мастер не будет запускаться при добавлении новых связей.
Изменение топологии репликации
Если после создания набора из нескольких целей для связи принято решение о выборе ■ другой топологии репликации, выполните следующие действия.
На консоли Dfs откройте окно Properties (Свойства) для связи, которая будет модифицирована.
Активизируйте вкладку Replication (Репликация).
Щелкните на кнопке Customize (Изменить). Откроется окно Customize Topology (Изменить топологию), которое показано на рис. 16.18.
Выберите новую топологию. Для топологии “звезда” (Hub and Spoke) выберите сервер, который будет выступать в роли главного концентратора.
^ ИSERVER3.rompary.com server1.ro... Defaul-Rrs... Di-^
v:. 0SERVER3.compary.com SERVER2... Defauft-Rrs... Dt J
Рис. 16.18. Окно Customize Topology (Изменить топологию), в котором показаны соединения для ячеистой топологии
Щелкните на кнопке ОК для сохранения изменений. Изменение будет сохранено в объекте Active Directory, который соответствует корню Dfs. После репликации этого объекта на другие контроллеры домена служба FRS на каждом сервере будет менять свое поведение ,при репликации.
Кроме этого, на вкладке Replication (Репликация) можно исключить некоторые типы файлов из процедуры репликации. По умолчанию исключаются файлы с расширениями . bak и . tmp. Можно добавить и другие расширения. Кроме этого, можно исключить из репликации некоторые подкаталоги.
Удаление корня Dfs
При необходимости корень Dfs можно удалить. Это требует небольшого “хирургического” вмешательства в системный реестр на каждом корневом сервере Dfs и изменения базы данных Active Directory. Удостоверьтесь, что пользователи осведомлены о прекращении действия ярлыков к этим папкам. Необходимая последовательность действий приводится в процедуре 16.9.
Процедура 16.9. Удаление корня Dfs
На консоли Dfs щелкните правой кнопкой мыши на пиктограмме корня и выберите команду Delete (Удалить) из контекстного меню.
Щелкните на кнопке Yes (Да), чтобы подтвердить удаление и завершить транзакцию.
В системном реестре каждого корневого сервера удалите раздел HKLM\Software\ MicrosoftXDfsHost.
Откройте консоль Active Directory — Users and Computers (Active Directory — пользователи и компьютеры).
Отобразите дополнительные параметры (если они не отображены) с помощью команды View1* Advanced View (Вид1*Дополнительные функции).
Перейдите в раздел System/Df s-Configuration.
Удалите объект FTDf s, который соответствует удаленному корню Dfs.
Перезапустите Dfs. Для этого откройте интерпретатор командной строки и введите команды net stop dfs и net start dfs.
Управление Dfs из командной строки
Существует две утилиты для управления Dfs из командной строки. Утилита dfsutil из состава Support Tools используется для добавления и удаления корня Dfs и для управления содержимым кэша таблицы РКТ на клиенте. Также эта утилита используется для отображения структуры Dfs. Ранее уже приводился пример информации из таблицы РКТ, доступной с помощью команды dfsutil /pktinfo. Ниже представлен результат выполнения этой команды с параметром /spcinfo:
C:\Program FilesXSupport Tools>dfsutil /spcinfo [ *][si.company.com]
[*][COMPANY]
[*][company.com]
[+][company.com]
[+S1]
[-NET-1]
[+][COMPANY]
[+S1]
[-NET-1]
Администраторы, которые умеют работать с утилитой df sutil из состава Windows 2000, могут обратить внимание, что количество возможностей утилиты было значительно уменьшено. В операционной системе Windows Server 2003 работает и более старая версия утилиты dfsutil.
Вторая утилита, df scmd, не поддерживает создание или удаление корней Dfs, но она предоставляет все остальные возможные операции, включая создание и удаление связей, создание и удаление целей репликации, а также просмотр структуры Dfs.
Отличной особенностью утилиты df scmd является параметр /batch, который позволяет создать пакетный файл, повторно создающий структуру Dfs в случае ее повреждения. В доменной Dfs это не очень актуально, но для изолированного корня Dfs эта возможность очень полезна.
Реализация Dfs в Windows Server 2003 R2
Усовершенствования в реализации возможностей распределенной файловой системы в версии Windows Server 2003 R2 коснулись как упрощенного отказоустойчивого доступа к файлам в Dfs (Dfs Namespace), так и специальной службы репликации данных DFS между серверами (DFSR).
Dfs Namespace]
Версия Dfs в операционной системе Windows Server 2003 R2 позволяет администраторам i группировать папки, которые предоставлены для общего доступа на разных серверах, и представлять их пользователям как виртуальное дерево каталогов, называемое Namespace (Про- j странство имен). Пространство имен обеспечивает ряд преимуществ, включая повышенную 1 доступность данных, распределение нагрузки и упрощенную миграцию данных. Для сер- I веров, входящих в пространство имен, администраторы теперь могут задавать приоритет- | ность обработки аварийных ситуаций.1
Служба DFSR
В R2 добавлена новая Dfs-служба для репликации под названием DFSR (DFS Replication — репликация Dfs). Технология DFS Replication стала преемником службы FRS. Служба DFSR ’ предназначена для решения многих проблем в системе репликации Windows NT (NTFRS), ко- j торая не была предназначена для обработки больших файлов или большого количества файлов. DFSR использует модель репликации с равноправными узлами, основанную на изменении со- ] стояния файла, и поддерживает диспетчеризацию и регулировку нагрузки полосы пропускания, i
DFSR использует новый алгоритм сжатия под названием RDC (Remote Differential • Compression — удаленное сжатие изменений). RDC — это протокол для передачи одних из- ] менений, который может эффективно использоваться при обновлении файлов через канал с ] ограниченной пропускной способностью. RDC определяет вставку, удаление и перестановку 1 данных в файлах и позволяет DFS Replication передавать после изменения файла только его ] обновленную часть. Например, при внесении изменений в базу данных Microsoft Access раз- j мером 20 Мбайт DFSR способна реплицировать лишь несколько измененных байтов.1
11Один из главных аспектов DFSR заключается в решении проблемы сбоев в работе NTFRS а при возникновении ситуаций, подобных проблеме согласования порядковых номеров обнов- i лений (USN) в журналах или проблеме остановки репликации и долгом периоде ожидания ее 1 возобновления. Механизм DFSR не требует вмешательства оператора и теперь поддерживает ] восстановление подключения после отказа. Если сервер, с которым пользователь работает в 1 нормальном режиме, по каким-то причинам недоступен, данный пользователь автоматически 1 направляется на другой сервер DFS. Когда же сервер будет снова доступен, пользователь ав- J тематически переключится к первоначальному серверу.I
1
1
Поскольку DFSR является новой службой, все серверы, которые назначаются в качестве целей DFS и должны использовать новые возможности репликации, должны работать под управлением операционной системы Windows Server 2003 R2 и на каждом из этих серверов должна быть установлена служба DFSR. В схему Active Directory также должны быть внесены небольшие изменения с целью поддержки новых DFSR-объектов. Для внесения изменений в схему можно воспользоваться утилитой Adprep (adprep. ехе), которая доступна в подкаталоге \cmpnents\r2\adprep установочного каталога R2.
Новая консоль управления упрощает репликацию данных целей DFS с помощью объединения оснастки DFS Management и оснастки Replication Management (Управление репликацией). Благодаря планировщику заданий с детальными настройками ситуация становится более управляемой. Теперь администраторы могут планировать репликацию DFS с периодом в 15 минут и следить за выполнением обработки отказа на каждом сайте (от одного сайта к другому). Данные настройки для DFS теперь хранятся в Active Directory.
Совместный доступ к файлам в смешанной среде
Для обеспечения совместного доступа к файлам для UNIX-клиентов и клиентам Microsoft для NFS в новой версии операционной системы Windows Server 2003 R2 предоставляется технология Microsoft Services for Network File System (Службы Microsoft для NFS). Эта технология позволяет пользователям передавать файлы между компьютерами, работающими под управлением Windows Server 2003 R2 и UNIX, используя протокол NFS (Network File System).
Microsoft Services for NFS — это обновленная версия компонентов NFS, которые ранее были доступны в составе Services for UNIX 3.5. Microsoft Services for NFS включают следующие новые функции:
поддержка 64-разрядной архитектуры; Microsoft Services for NFS могут быть установлены на все версии Windows Server 2003 R2, включая 64-разрядные версии;
обновленная оснастка ММС для администрирования Microsoft Services for NFS;
повышенная надежность;
поддержка специальных устройств UNIX (mknod).
Microsoft Services for NFS позволяют поддерживать смешанные среды, состоящие из операционных систем семейств Windows и UNIX, а также производить обновление компьютеров организации, поддерживая устаревшие технологии на время переходного периода. Ниже приведены преимущества, которые может получить предприятие, используя Microsoft Services for NFS.
Обеспечение клиентам UNIX доступа к ресурсам, которые находятся на компьютерах, работающих под управлением Windows Server 2003 R2. Ваша компания может использовать клиенты UNIX, имеющие доступ к таким ресурсам, как файлы на файловых серверах UNIX. Чтобы воспользоваться преимуществами новых возможностей Windows Server 2003 — таких, как Shadow Copies for Shared Folders (Теневые копии общих папок), — можно переместить ресурсы с серверов UNIX на компьютеры, работающие под управлением Windows Server 2003 R2, а затем установить Microsoft Services for NFS для того, чтобы обеспечить доступ клиентам UNIX, использующим NFS. Все клиенты UNIX смогут получить доступ к ресурсам по протоколу NFS без внесения каких-либо изменений.
Обеспечение компьютерам, работающим под управлением Windows Server 2003 R2, доступа к файловым серверам UNIX. Ваша компания может иметь смешанную среду из Windows и UNIX и такие ресурсы, как файлы, хранящиеся на файловых серверах UNIX. Можно использовать Microsoft Services for NFS для того, чтобы обеспечить компьютерам, работающим под управлением Windows Server 2003 R2, доступ к ресурсам файловых серверов, которые используют NFS.
Совместный доступ к принтерам
Пользователи считают печать настолько простой операцией, что думают, что любой дурак сможет ее выполнить. Они не понимают, что сетевая печать требует для своей работы целого ряда сложных технологий, устройств, драйверов и интерфейсов от большого количества производителей.
В этом разделе рассматриваются настройка сетевой печати в операционной системе Windows Server 2003 и методы решения возможных проблем в работе подсистемы печати.
Функциональное описание сетевой печати
На рис. 16.19 показана схема стандартной системы печати. То, что схема напоминает известную игру “Мышеловка”, не является совпадением. Рубе Голдберг (Rube Goldberg) удивился бы сложности транзакций, которые происходят во время превращения слова на экране в слово на бумаге.
8
Рис. 16.19. Структура типичной системы печати
Рассмотрим последовательность событий, которые происходят при отправке пользователем задания на печать на сервер печати под управлением операционной системы Windows.
Приложение пользователя обращается к программному интерфейсу Win32 для отправки выведенного на экран документа соответствующим службам для вывода на принтер.
Интерфейс Win32 совместно с Graphics Rendering Engine преобразовывает документ в промежуточный формат, который называется метафайлом и может быстро передаваться по сети. Задача помещается в очередь спулера до и после этого преобразования.
Спулер (программа-планировщик) передает метафайл поставщику сетевой печати, который доставляет задание службе процессора печати на сервере печати под управлением операционной системы Windows.
Служба процессора печати превращает метафайл в набор команд принтера и сохраняет набор команд в файле, который сохраняется на диске.
В Спулер передает файл службе Printer Monitor, которая доставляет файл устройству печати.
В Устройство печати наносит тонер/лазер/краску на бумагу/пленку/чашку и, как эгоистический актер, присваивает себе славу за всю работу, проделанную системой.
Начальное преобразование задания
Транзакции сетевой печати запускаются после щелчка на кнопке Print (Печать) в окне приложения. Последовательность событий зависит от платформы и типа приложения.
В 32-разрядные приложения Windows используют вызовы программного интерфейса Win32 для визуализации страницы с экрана в форму, поддерживаемую принтером.
В 16-разрядные приложения Windows используют вызовы программного интерфейса Winl6, которые интерпретируются подсистемой Windowsl6-on-Windows32 (WOW) и преобразовываются в соответствующие вызовы программного интерфейса Win32.
Когда принтер — это не принтер
Всем, кто не знаком с жаргоном Windows, термин "принтер" (printer) может показаться не тем, чем он является на самом деле. Физический принтер называется устройством печати (print device). В операционной системе Windows "принтер" — это логический объект, а не физический. Для создания принтера необходимо настроить набор драйверов на сервере или рабочей станции. Принято говорить "Я установил принтер на этом сервере с помощью драйвера HP U8000".
Терминология становится еще более запутанной, когда речь идет о таких устройствах, как HP JetDirect и Intel NetPro. Часто эти устройства называются серверами печати, но в операционной системе Windows сервер печати — это сервер под управлением операционной системы Windows, на котором установлен принтер. Компания Microsoft не использует специального термина для устройств JetDirect и NetPro. В этой книге для таких устройств будет использован термин "сетевые интерфейсы принтеров".
Приложения DOS выдают команды непосредственно принтеру. Эти команды преобразовываются в вызовы программного интерфейса Win32 средствами драйвера виртуальной машины DOS (Virtual DOS Machine — NTVDM).
Приложения UNIX/POSIX, работающие под управлением Interix, в операционной системе Windows Server 2003 выдают команды, которые преобразовываются в вызовы программного интерфейса Win32.
Компьютеры на основе процессора Itanium используют вызовы программного интерфейса Win64, который обеспечивает дополнительный уровень эмуляции, Win32-on-Win64, или WOW64, и обрабатывает вызовы приложений Win32. Эмуляторы WOW16 и NTVDM работают внутри эмулятора WOW64.
Поскольку имена большинства системных файлов в операционной системе Windows для архитектуры IA64 не изменились, 32-разрядные версии системных файлов необходимо разместить в отдельном каталоге. Эмулятор WOW64 скрывает этот каталог с помощью перенаправителя файловой системы. При доступе к системному файлу 32-разрядного приложения приложение перенаправляется к папке \Windows \ SysWOW64.
Вызовы программного интерфейса Win32 запускают набор процедур внутри подсистемы Windows Executive, которые обращаются к службам Graphic Device Interface (GDI). Как не- , сложно понять из названия, интерфейс GDI управляет всеми видами графического вывода в I операционной системе Windows Server 2003. Это касается и вывода на экран, и вывода на j принтер. Это один из трех ключевых компонентов подсистемы Win32. Пользователь и ядро являются двумя оставшимися компонентами.]
Эмулятор WOW64 отображает страницы памяти объемом 8 Кбайт (применяются в опера- j ционной системе Windows Server 2003 для архитектуры IA64) на страницы памяти 4 Кбайт, ко- < торые применяются в архитектуре IA32. Это позволяет приложениям Wind32 непосредственно j обращаться к памяти без проблем с точки зрения совместимости. На многопроцессорных сер- ) верах с количеством процессоров, превышающим 32, подсистема WOW64 отображает привязку 1 к процессорам для 32-разрядных приложений, что позволяет сохранить совместимость с огра- I ничением на 32 процессора в операционных системах Windows для архитектуры Windows.
Механизм печати как можно быстрее должен вернуть управление приложением пользова- ’ телю, поэтому вместо полной визуализации задания с помощью команд управления принте- j ром задание преобразовывается в промежуточный формат, который называется Enhanced I Metafile, или EMF. В каждой новой версии операционной системы Windows используется собственная версия формата метафайла. В операционных системах Windows Server 2003 и Windows ХР используется версия 1.008.■
Расширенные метафайлыI
При получении задания на печать подсистема GDI визуализирует задание в формат i EMF. Создание файла EMF позволяет системе быстро вернуть контроль над приложением пользователю.]
Файл EMF сохраняется средствами спулера для последующей обработки. Если принтер | подключен к удаленному серверу печати, по сети отправляется файл EMF, а не полностью 1 визуализированное задание на печать. Это позволяет сэкономить время процессора на клиен- 1 те и пропускную способность сети.I
Файл EMF не содержит команд для принтера. Вместо этого в файле указывается последо- I вательность команд GDI, которые полностью описывают печатаемую страницу. Некоторые I принтеры поддерживают язык GDI, но большинство принтеров использует собственный | язык команд, которые применяются производителями для предоставления дополнительных | возможностей.1
Файл EMF частично зависит-от драйвера принтера. Интерфейс GDI нуждается в общей 1 информации о принтере, что позволяет “проектировать" страницу в соответствии с возмож- | ностями и спецификациями принтера. Например, нет никакого смысла создавать цветной ме- - 1 тафайл с разрешением 1200 dpi размером 11x17 дюймов при выводе изображения на матрич- I ный принтер.I
Драйверы принтеров от компании Microsoft I
Драйверы принтера (printer drivers) необходимы для преобразования содержащего команды I GDI файла EMF в задание на печать, в котором содержатся команды принтера.1
Интерфейс GDI находится в пространстве ядра. Начиная с операционной системы Win- 1 dows NT 4.0, драйверы печати также должны находиться в пространстве ядра, что обеспечива- 1 ет непосредственную связь драйверов и интерфейса GDI. Это привело к значительному по- I вышению привилегий драйверов принтеров в операционных системах Windows NT. В резуль- тате многие администраторы начали сталкиваться с синими экранами критических ошибок, 1 снижением производительности и повреждением данных при попытке установить непра- Л вильно работающие драйверы принтера.Л
В операционных системах Windows Server 2003, Windows ХР и Windows 2000 эта проблема была решена с помощью перемещения драйвера устройства в пространство пользователя из пространства ядра. Изучение способов создания драйверов1 для режима ядра заняло у разработчиков некоторое время, поэтому особого желания опять создавать драйверы для пользовательского режима разработчики не проявляют. Компания Microsoft повесила перед разработчиками “морковку”, предлагая больший объем стека, доступ к драйверам других устройств, более простую отладку и большую производительность расчетов с плавающей точкой в пространстве пользователя. В другой “руке” компания Microsoft держит “палку”, предупреждая, что рано или поздно поддержка драйверов для режима ядра будет прекращена.
При подключении к принтеру, подключенному к компьютеру IA64 под управлением Windows Server 2003, могут возникнуть проблемы. Драйверы принтеров для архитектуры IA64 могут работать вместе с операционными системами для архитектуры IA32 (Windows Server 2003, Windows ХР), но не работают вместе с операционной системой Windows 2000. На сервере IA64 придется настроить драйверы принтеров Windows 2000 как для совместно используемых принтеров.
Групповые политики для драйвера принтера
Можно опередить компанию Microsoft и включить в операционных системах Windows Server 2003 и Windows ХР групповую политику Disallow Installation of Printers Using Kernel-Mode Drivers (Запретить установку принтеров, использующих драйверы режима ядра). Эта политика доступна в разделе Computer configuration^Administrative Templates^Printers (Конфигурация компьютера1^Административные шаблоны^Принтеры). Если установить эту политику, пользователи и администраторы не смогут устанавливать драйверы принтеров, которые включают в себя библиотеки DLL для режима ядра. Об этом будет ясно сказано в сообщении об ошибке. Кроме этого, будет предложено обратиться к администратору для получения одобренных драйверов.
Большинство драйверов принтеров, созданных компанией Microsoft и предоставляемых в составе операционной системы Windows Server 2003, использует библиотеки DLL для пользовательского режима. Кроме этого, драйверы подписаны цифровой подписью, что указывает на прохождение ими сертификации. Можно установить групповую политику, которая позволит блокировать установку драйверов без цифровой подписи. Это также позволит защитить систему от установки “троянских коней” под видом драйверов принтеров. Политика называется Code Signing For Device Drivers (Подписывание кода для драйверов устройств). Политика расположена в разделе User Configuration^System (Конфигурация пользователя^Система). Включение политики позволяет блокировать установку неподписанных драйверов.
Главные драйверы принтера
Конструкция драйвера принтера в операционных системах Windows 2000 и Windows Server 2003 избавляет производителя от основной работы по созданию кода. Компания Microsoft предоставляет три главных драйвера принтера.
“Универсальный” драйвер принтера, Unidrv.dll. Этот драйвер обеспечивает работу растровых принтеров, которые используют одну из версий языка HP Printer Control Language (PCL).
Драйвер принтера Postscript, Pscript .dll. Этот драйвер обеспечивает работу принтеров, соответствующих стандартам Postscript до версии 3 и Document Structuring Convention до версии 3.1.
Драйвер плоттера, Msplot.dll. Этот драйвер обеспечивает работу перьевых плоттеров и эквивалентных им принтеров, использующих чернила и электростатику.
Эти драйверы поддерживают практически все принтеры, доступные на рынке. От производителей требуется только предоставление пользовательского интерфейса, механизма визуализации и одного из следующих типов файлов с данными о принтере.
Файлы Generic Printer Description (GPD). Это текстовые файлы, в которых предоставляется информация о конфигурации для растрового процессора изображений Unidrv.
Файлы Postscript Printer Description (PPD); Это текстовые файлы, в которых предоставляется информация о конфигурации для процессора Pscript.
Файлы Characterization Data (PCD). Это библиотеки DLL, в которых предоставляется информация о конфигурации для драйвера Msplot.
При установке принтера драйверы копируются в каталог \Windows\Systems2 \Spool\ Drivers. Этот каталог предоставляется для совместного доступа, что позволяет сетевым клиентам загружать драйверы принтера непосредственно с сервера печати.
Просмотр информации о драйвере
Нельзя просто посмотреть на файлы драйверов и определить, какие драйверы связаны с каждым принтером,, подключенным к серверу. Кроме этого, нельзя определить версии драйверов, что очень важно знать, если драйвер вызывает проблемы в работе системы. Последовательность действий для просмотра подробной информации о наборе драйверов приводится в процедуре 16.10.
Процедура 16.10. Просмотр дополнительной информации о драйвере принтера
В окне Printers and Faxes (Принтеры и факсы) выберите в меню команду File^Server Properties (Файл^Свойства сервера).
Активизируйте вкладку Drivers (Драйверы), которая показана на рис. 16.20.
Рис. 16.20. Вкладка Drivers (Драйверы) в окне - свойств сервера печати. На вкладке отображается список принтеров, установленных на сервере печати
Выделите принтер и щелкните на кнопке Properties (Свойства), чтобы открыть окно Driver Properties (Свойства драйвера), которое показано на рис. 16.21.
Рис. 16.21. Окно свойств драйвера принтера с информацией о драйверах, установленных для определенного принтера
Для просмотра версии библиотеки DLL выделите библиотеку, щелкните на кнопке Properties (Свойства) и откройте вкладку Version (Версия).
Этот интерфейс позволяет удалить или изменить драйвер принтера.
Спулер
Служба спулера ведет себя, как охранник на перекрестке возле школы. Спулер следит за заданиями на печать, которые передаются между механизмом визуализации, диском и принтером, пока они не будут переданы на устройство печати.
Спулер представляет собой клиент/серверную систему. Клиентская часть, Winspool. drv, принимает задание на печать от приложения и доставляет ее серверной части спулера, Spoolsv.exe, которая содержит основной код спулера. Кроме этого, спулер принимает задания на печать, полученные по сети с помощью Win32 spl .dll.
. Для запуска и останова этой службы можно воспользоваться утилитой net. Для этого используются команды net stop spooler и net start spooler.
Спулер хранит задания на печать в папке \Windows\System32\Spool\Printers. Для каждого задания создается два файла.
Файл спулера. Для этих файлов используется расширение . spl. В файлах хранится само задание на печать в виде файла EMF или полностью визуализированного задания.
Теневой файл. Для этих файлов используется расширение . shd. В файлах хранятся информация и инструкции, связанные с заданием, например заданное устройство печати, приоритет печати и имя пользователя, запустившего задание на печать.
Перемещение файлов спулера
В процедуре 16.11 рассматривается последовательность действий для изменения принятого по умолчанию каталога для хранения файлов спулера.
Процедура 16.11. Изменение принятого по умолчанию каталога спулера
Откройте окно Printers (Принтеры). Для этего воспользуйтесь командой Start* Settings*
Printers and Faxes (Пуск1*Настройки*Принтеры и факсы).
В меню выберите File^Server Properties (Файл ^Свойства сервера).
Откройте вкладку Advanced (Дополнительно), как показано на рис. 16.22.
В поле Spool Folder (Папка спулера) введите локальный путь к новому каталогу спулера. Убедитесь, что каталогу назначены соответствующие права доступа и прошедшие проверку пользователи могут отправлять задания на печать.
Щелкните на кнопке ОК для сохранения изменений.
Остановите и повторно запустите службу спулера. Для этого воспользуйтесь командами net stop spooler и net start spooler.
Рис. 16.22. На вкладке Advanced (Дополнительно) окна свойств сервера печати указано расположение спулера
Процессор печати
Ответственность за генерацию финального задания на печать на основе содержимого файла EMF возложена на локальный поставщик печати (Local Print Provider), Localspl .dll. Этот драйвер объединяет в себе функции процессора печати Winprint-dlln локального монитора принтеров Localmon.dll. (Это изменение в архитектуре печати появилось с выходом операционной системы Windows 2000 одновременно с другими изменениями, предназначенными для ускорения загрузки.)
Одной из ключевых функций локального поставщика печати Localspl было назначение типа данных (data type) заданию на печать. Тип данных определяет метод обработки задания после его преобразования в команды принтера. Обычно не стоит даже задумываться о типе данных. Эта информация обрабатывается операционной системой и не требует вмешательства пользователя или администратора. Но однажды придется печатать на сервере печати Windows Server 2003 с клиента под управлением другой операционной системы (не Windows). Если в таком случае возникнут проблемы форматирования, придется разобраться в назначении типов данных и назначить соответствующий тин, если это необходимо. Рассмотрим список доступных типов данных.
Raw. Задание на печать полностью преобразовано в команды принтера и не требует дальнейшей обработки.
Raw (с добавлением FF). В конце задания на печать добавлена команда протяжки листа. Этот тип данных полезен для приложений DOS, которые не выбрасывают последний лист из принтера после завершения печати;
Raw (автоматически добавлять FF). Команда протяжки листа автоматически добавляется к заданию на печать, если такая команда отсутствует. Этот вариант подходит для добавления к заданию на печать двух пустых листов. (Звонок в службу поддержки: “Мы печатаем отчет, состоящий из трехсот страниц, и в конце задания принтер выдает две чистые страницы. Нам уже надоело, что отдел информационных технологий так безответственно относится к своим обязанностям и не экономит бумагу!”.)
NT EMF 1.003, 1.006,1.007 и 1.008 (расширенный метафайл). Это версии EMF, которые поддерживаются в операционных системах Windows Server 2003, Windows 2000, Windows NT 4.0 и Windows 98. Более ранние версии Windows и Windows NT 3.5x используют файлы Journal, которые не могут пересылаться по сети.
Текст. Этот параметр заставляет использовать для задания на печать текст, соответствующий стандартам ANSI, без управляющих кодов. Этот тип данных должен назначаться заданиям на печать Postscript от клиентов UNIX.
Локальный поставщик печати Localspl назначает тип данных входящего потока данных на основе критериев, перечисленных в табл. 16.1.
Таблица 16.1. Назначение типа данных процессора печати
Источник задания на печать
Назначенный тип данных
Windows Server 2003, Windows ХР, Windows 2000, Windows NT 4.0 и Windows 98
Тип данных nt_emf любой подходящей версии
Windows NT 3.51, Windows 95 и Windows 3.1x
' RAW
Приложения DOS при локальной печати или печати по сети
RAW
Клиенты Macintosh, отправляющие задания на печать на принтер Postscript на сервере под управлением Windows Server 2003
RAW
Клиенты Macintosh, отправляющие задания на печать на не Postscript-принтер на сервере под управлением Windows Server 2003
PSCRIPT1. Вызывается процессор печати второго уровня, который выполняет преобразование задания на печать Postscript для устройства печати, которое не поддерживает Postscript
Клиент UNIX использующий параметр 1
RAW. Параметр 1 указывает, что в задание включены коды управления принтером.
Клиент UNIX использующий параметр f
TEXT. Параметр f указывает, что в задании отсутствуют коды управления принтером. В таком задании используются символы ESC, которые неправильно печатаются принтерами PCL
Поставщики печати
Кроме этого, в состав спулера входит маршрутизатор (router), Spoolss .dll. Маршрутизатор выбирает поставщик печати (print provider), который используется для связи со службой принтера, которая в конце концов отправит задание на физическое устройство печати. Локальные задания на печать (предназначенные для локально подключенных принтеров)
обрабатываются поставщиком локальной печати (Local Print Provider), Localspl .dll. Кроме этого, локальный поставщик печати обрабатывает задания на печать, предназначенные для сетевых устройств печати, например Jet Direct, NetPro и Castelle.
Задания на печать, предназначенные для серверов печати в сети, передаются следующим сетевым поставщикам печати. ■
Windows (SMB) Network Print Provider (Win32spl.dll). Этот поставщик обрабатывает задания на печать, предназначенные для серверов печати под управлением операционной системы Windows. Для серверов печати под управлением Windows Server 2003, Windows ХР, Windows 2000 или Windows NT 4.0 поставщик Win32 spl.dl1 отправляет файл EMF. В противном случае поставщик сотрудничает с поставщиком Localspl .dll для полного преобразования задания на печать до отправки задания на сервер.
Internet Print Provider (lnetpp.dll). Этот поставщик обрабатывает задания на печать, предназначенные для серверов печати Internet Print Protocol (IPP).-
NetWare Network Print Provider (Nwprovau.dll). Этот поставщик обрабатывает задания на печать, предназначенные для серверов печати NetWare. Задания получают тип данных RAW, а значит, финальная визуализация выполняется на клиенте.
UNIX print jobs. Задания, предназначенные для узлов UNIX, обрабатываются поставщиком Line Printer Protocol (LPR).
Все поставщики доступны в окне Network Connections (Сетевые подключения) после выбора Advanced^Advanced Settings (ДополнительнойДополнительные параметры). Перейдите на вкладку Provider Order (Порядок поставщиков).
Мониторы портов
После преобразования задания на печать в команды принтера спулер передает задание монитору порта (port monitor). Это драйвер пользовательского режима, который связывается с устройством печати с помощью соответствующих драйверов из режима ядра.
Например, задание на печать, предназначенное для локального принтера, который подключен к параллельному или последовательному порту, передается Localspl, на который возлагаются задачи монитора порта и локального поставщика печати. Если в задании используется язык PCL, оно отправляется монитору языка (Language Monitor), Pj Imon, для дополнительного двустороннего управления (PJL расшифровывается как Printer Job Language — язык управления заданиями принтера).
Команда capture в операционной системе NetWare
Приложения DOS часто отправляют задания на печать, в которых сделаны определенные предположения о размере табуляции и кодах конца страницы. В среде Windows 9х при печати на сервере печати под управлением NetWare эти предположения обрабатываются с помощью специальных параметров команды capture из операционной системы NetWare.
В операционных системах Windows NT команда capture не поддерживается. Если устаревшее приложение DOS использует графические возможности, которые требуют использования параметров команды capture на компьютере под управлением Windows 9х, протестируйте эти приложения под управлением операционных систем Windows Server 2003 и Windows ХР, чтобы убедиться в работоспособности приложений до развертывания новой операционной системы. Если приложения не работают, единственным вариантом является сохранение старой версии операционной системы на клиенте или отказ от использования устаревшего приложения.
Мониторы портов доступны через пользовательский интерфейс как порты (ports). Например, при подключении принтера к шине USB активизируется монитор портов Usbmon и для интерфейса USB создается виртуальный порт принтера.
Существуют мониторы портов для сетевых устройств печати. Например, монитор печати Tcpmon управляет заданиями на печать, которые отправляются на сетевые устройства печати по протоколу TCP/IP. Этот монитор используется по умолчанию для печати по сети. (Более старый интерфейс Hpmon для печати по протоколу DLC был удален из операционной системы. Протокол DLC в операционной системе Windows Server 2003 не поддерживается.) Монитор печати Lprmon обрабатывает задания на печать, предназначенные для службы LPD на узле UNIX. Кроме этого, существуют мониторы печати для факс-принтеров, Интернет-принтеров и таких шинных интерфейсов, как IrDa и FireWire.
Финальная доставка задания на печать
После завершения доставки монитором печати спулер удаляет файлы с расширениями . shl и . spd из каталога спулера, если принтер не был настроен на сохранение заданий.
В процессе удаления заданий из спулера файл с расширением . spl остается заблокированным, а файл с расширением . shd — нет. Если удалить задание на печать в процессе работы устройства печати, файл . shd будет удален, а файл . spl отправится в бесконечность. Удалить задание на печать из окна принтера не удастся, сколько ни щелкай на кнопке Cancel (Отмена).
В этом случае остановите службу спулера (команда net stop spooler), удалите файл с расширением . spl вручную и перезапустите службу спулера. Установленные в очередь задания на печать не удаляются при остановке службы спулера. Задания в процессе печати будут прерваны и запущены на печать сначала после запуска службы спулера. Это может вызвать раздражение пользователя, который ждал последние три страницы пятисотстраничного годового финансового отчета, поэтому перед остановкой спулера проверьте состояние очередей.
Настройка печати на клиенте под управлением Windows Server 2003
Существует множество различных способов подключения компьютеров к принтерам (столько же, сколько способов общения между людьми). Подсистема печати Windows Server 2003 общается с этими интерфейсами с помощью монитора печати (print monitor). Обычно топологии печати попадают под одно из следующих определений.
Печать иа локальное устройство печати. Устройство печати подключается непосредственно к серверу через параллельный, последовательный, инфракрасный порты, по шине USB или FireWire либо через интерфейс PCMCIA.
Печать на сетевое устройство печати. Устройство печати подключается к сетевому интерфейсу, с которым сервер печати связывается с помощью поставщика сетевой печати. В качестве примеров можно перечислить HP JetDirect, Castelle LANpress, Intel NetPort, а также Lantronix, Xionics, Emulex и Extended Systems.
Совет no использованию системного реестра: записи системного реестра, связанные с принтерами
Управляющие печатью записи системного реестра находятся в разделе HKLM\System\ CurrentControlSet\Control\Print.
Печать на сервере под управлением Windows. Устройство печати подключено к серверу под управлением Windows и предоставлено для совместного доступа. Сервер печати принимает задания на печать от сетевых клиентов, выполняет преобразование и отправляет задания на устройства печати.
Печать на сервере под управлением UNIX. У стройство печати подключено к узлу под управлением UNIX или другому устройству, в. котором для управления доступом к ресурсам принтера используется демон LPD (Line Printer Daemon).
Печать на сервере от стороннего производителя. Устройство печати подключено к серверу печати от стороннего производителя, например к серверу NetWare или узлу Macintosh, который требует специальной обработки и протоколов для доставки задания на печать.
Печать по сети Интернет. Устройство печати подключено к серверу, настроенному на получение заданий на печать по протоколу Internet Printing Protocol (IPP).
Печать на узлах мэйнфреймов и печать с узлов мэйнфреймов. Устройство печати подключено к мэйнфрейму, AS400 или другому компьютерному “бегемоту”. Этот устаревший вариант выходит за пределы тем, рассматриваемых в этой книге. Такая ситуация подразумевает самый ужасный союз: протокол APPN (Advanced Peer-to-Peer Networking) поверх SNA или SMB поверх IP. Одни только эти аббревиатуры могут заставить администратора сменить профессию. Особенности печати с клиентов Windows в среде мэйнфреймов рассматриваются в документации, которая предоставляется вместе с Microsoft Host Integration Server (ранее известным как SNA Server).
В следующих разделах рассматривается создание принтера для каждой перечисленной конфигурации.
Печать на локальном устройстве печати
Для всех портов, кроме параллельного и последовательного, установка драйвера принтера в операционной системе Windows Server 2003 управляется подсистемой Plug-and-Play (РпР). Если принтер не поддерживает спецификацию Plug-and-Play или подключается к устаревшему порту, необходимо выполнить поиск принтера вручную после подключения. Для этого откройте консоль Device Manager (Диспетчер устройств), файл Devmgmt .msc, щелкните правой кнопкой мыши на пиктограмме вершины дерева и выберите команду Scan for New Hardware (Обновить конфигурацию оборудования). Если сканирование не помогло, выполните последовательность действий, описанную в процедуре 16.12 для установки драйверов вручную.
Процедура 16.12. Установка принтера, не поддерживающего стандарт Plug-and-Play
Щелкните на кнопке Start (Пуск) и выберите Settings*Printers and Faxes (Настройки* Принтеры и факсы). Откроется окно Printers and Faxes (Принтеры и факсы).
Выполните двойной щелчок на пиктограмме Add Printer (Установка принтера). Запустится мастер добавления принтера (Add Printer Wizard) и откроется окно Select Printer port (Выберите порт принтера). В раскрывающемся списке Use Following Port (Использовать следующий порт) выберите порт LPT или СОМ, к которому подключено устройство печати.
Щелкните на кнопке Next (Далее). Откроется окно Install Printer Software (Установка программного обеспечения). Выберите производителя и модель принтера. Если модель принтера отсутствует в списке, щелкните на кнопке Have Disk (Установить с диска) и предоставьте драйверы для интересующего принтера, совместимые с операционной системой Windows Server 2003. Подойдут также драйверы для операционной системы Windows 2000.
Щелкните на кнопке Next (Далее). Откроется окно Name Your Printer (Название принтера). Присвойте принтеру имя, которое не будет слишком длинным, но которое позволит уни-
кально идентифицировать этот принтер. Если это первый принтер, он будет выбран как принятый по умолчанию.
Щелкните на кнопке Next (Далее). Откроется окно Printer Sharing (Общий доступ к принтеру). Если принтер должен быть предоставлен для совместного доступа по сети, присвойте имя общему ресурсу. Помните, что клиенты под управлением Windows 9х не воспринимают имена длиннее 15 символов.
Щелкните на кнопке Next (Далее). Откроется окно Location and Comment (Расположение и комментарий). Введите информацию, которая позволит пользователям выбрать подходящий принтер. Эта информация отображается в окне Print (Печать) в большинстве 32-разрядных приложений.
Щелкните на кнопке Next (Далее). Откроется окно Print Test Page (Печать тестовой страницы). Обычно имеет смысл распечатать тестовую страницу, так как на ней указывается информация о загруженных драйверах, времени создания и номере версии, а также дополнительная полезная информация о принтере. Сохраните результат печати тестовой страницы.
Щелкните на кнопке Next (Далее). В последнем окне будут показаны выбранные параметры. Щелкните на кнопке Finish (Готово), чтобы завершить установку принтера.
Если вручную установить принтер, который на самом деле поддерживает Plug-and-Play, система может обнаружить устройство после следующей перезагрузки и потребует переустановки устройства. Операционная система Windows Server 2003 достаточно хорошо справляется с решением подобных задач, поскольку принтер получает уникальное имя, но иногда случаются ошибки. В случае ошибки придется установить принтер еще раз. Если драйверы уже установлены, повторная установка принтера не займет много времени.
Печать на сетевом устройстве печати
Единственной разницей между печатью на сетевое устройство печати, например JetDirect и NetPort, и локальный принтер, подключенный по шине FireWire или USB, является сложность линий связи.
Монитор печати выступает в качестве сетевого поставщика печати и отправляет задание на печать сетевому устройству печати. Каждый монитор связан с собственным поставщиком, а каждый поставщик обрабатывает один и только один протокол.
В операционных системах Windows Server 2003 и Windows ХР для печати на сетевые интерфейсы печати по протоколу TCP/IP используется поставщик Tcpmon. Перечислим несколько проблем, которые могут возникать при настройке.
IP-адрес. Сервер печати должен знать IP-адрес устройства печати. Обычно указывается статический адрес, так как в большинстве организаций для принтеров используется статическая адресация. Это имеет свои исторические причины. Устройства DHCP/BootP не умеют устанавливать связь со службой DNS, поэтому в случае изменения адреса устройства сервер печати потеряет подключение. При использовании Dynamic DNS (Windows или BIND) устройство может зарегистрировать новый IP-адрес, поэтому острота проблемы снижается.
Несколько хостов печати. Многие пользователи ненавидят серверы печати. Такие пользователи предпочитают отправлять задания непосредственно на устройство печати. Иногда это вопрос контроля, а иногда — результат ненадежной работы сервера. Очень редко имеет смысл разрешать пользователям настраивать локальные принтеры на использование сетевого интерфейса печати. Такие устройства обладают ограниченным размером буфера и могут отказать, если получат слишком большое количество заданий на печать.
Simple Network Management Protocol (SNMP). Сетевые устройства печати, поддерживающие протокол SNMP, становятся все более распространенными. Потратив некоторую
сумму, можно получить устройство, перехватывающее сообщения об ошибках на консоль управления и поддерживающее управление из центральной консоли. Эта возможность особенно полезна при существующей инфраструктуре управления SNMP. Но не стоит тратить деньги на дополнительные функциональные возможности, если планируется только управление печатью. ,
Печать на хосте UNIX
С помощью протокола LPR (Line Printer Protocol) можно отправлять задания на сервер печати под управлением UNIX. На узле должна работать вспомогательная служба LPD (Line Printer Daemon). Эта служба ждет запросов по протоколу LPR и обрабатывает полученные задания на печать.
По умолчанию в операционной системе Windows Server 2003 служба LPR не устанавливается. Для ее установки в аплете Add/Remove Programs (Установка и удаление программ) в Control Panel (Панель управления) необходимо установить Print Services for UNIX. Этот компонент доступен в разделе Other Nework File and Print Services.
После установки протокола LPR в мастере добавления принтера будет доступен новый тип порта: LPR Port. Если выбрать этот порт, откроется окно Add LPR Compatible Printer (Добавить LPR-совместимый принтер), в котором нужно ввести IP-адрес и имена очереди для сервера LPD и устройства печати. '
При установке Printer Services for UNIX устанавливается служба LPD для сервера Windows. Это позволяет клиенту UNIX отправлять задания на сервер печати под управлением Windows по протоколу LPR.
Печать на сервере печати Windows
Клиент Windows Server 2003 может отправлять задания на печать на сервер печати под управлением любой версии Windows — Windows 3.1х, Windows Эх, Windows NT, Windows 2000, Windows XP, Windows Server 2003. Для этого пользователь должен обладать достаточными правами доступа. Между более новыми версиями операционной системы Windows задания на печать передаются немного быстрее. Это связано с более лаконичной структурой формата EMF. Но для обычного пользователя это ускорение незаметно.
Совет по использованию системного реестра: записи системного реестра для управления службой LPD
Для управления службой LPD используются следующие параметры системного реестра:
Раздел: HKLM\System\CurrentControlset\Services\LPDSVC\Parameters
Записи: AllowJobRemoval, AllowPrinterResume и MaxConcurrentUsers (по умолчанию установлено значение 64)
Существует несколько способов подключения клиентов Windows к совместно используемому принтеру на сервере Windows. Чаще всего используется мастер добавления принтера. Но проще всего найти совместно используемый принтер в базе данных Active Directory. Это позволяет находить принтеры, указав в качестве критерия расположение и интересующие возможности. На рис. 16.23 показаны критерии выбора принтера.
Можно воспользоваться простыми запросами или создать расширенный запрос, который позволит выполнять поиск практически по всем атрибутам класса объектов Printer. Например, можно искать цветные принтеры, способные печатать двусторонние изображения размером 11x17 дюймов, обладающие возможностью сшивания распечатанных страниц. Для этого или администратор или сценарий INF должен предоставить соответствующую информацию в виде Атрибутов объекта принтера в базе данных Active Directory.
Рис. 16.23. В окне Find Printers (Найти принтеры) отображаются базовые критерии поиска принтера
После того как интересующий принтер найден, щелкните правой кнопкой мыши на пиктограмме принтера и выберите из контекстного меню команду Connect (Подключить). При этом будет установлен драйвер принтера и добавлен локальный принтер.
Сложно сказать, станут ли пользователи применять окно поиска. Если они не смогут или не захотят этого делать, придется предоставлять пользователям подключения к принтерам другим способом. Эта тема рассматривается в следующем разделе.
Автоматизация подключения клиентов к принтерам
Большую часть проблем пользователей при подключении к серверам печати по сети можно решить с помощью регистрационного сценария.
Ниже приведен трехстрочный сценарий на языке Visual Basic, который предназначен для установки соединения с принтером в операционных системах Windows Server 2003, Windows ХР, Windows 2000 и Windows NT:
Set Obj = CreateObject("Wscript.Network")
Printershare = "\\<имя_сервера>\<имя_принтера>”
obj.AddWindowsPrinterConnection(Printershare)
Такой сценарий позволяет автоматизировать установку подключения к сетевому принтеру. Если необходимо автоматизировать подключение и локальных принтеров, можно воспользоваться соответствующими параметрами библиотеки функций Printui. dll. Для этого следует применить утилиту Run 113 2. Н еобходимая команда выглядит следующим образом:
rundll32 printui.dll,PrintUIEntry /ia /c\\s21 /m "HP Deskjet 640c" /h
*b "Intel" /v "Windows Server 2003" /f %windir%\inf\ntprint.inf
Эта команда установит принтер HP DeskJet 640c на компьютере S21 с помощью INF- сценария, который хранится локально на компьютере. Слово PrintUIEntry чувствительно к регистру.
Список параметров PrintUIEntry можно получить после ввода параметра /? в командной строке, например:
rundll32 printui.dll,PrintUIEntry /?
Существует около 50 различных параметров этого вызова функции. В данном примере использованы следующие параметры.1
/1а. Установить принтер с помощью сценария с расширением . inf.
/с. Путь UNC к удаленному компьютеру.
/ш. Имя драйвера принтера (обычно это длинная строка).
/h. Тип драйвера принтера: Alpha, Intel, IA64.
/v. Версия драйвера: Windows NT 4.0, Windows ХР, Windows 2000 или Windows Server 2003.
/f. Имя файла с расширением .inf.
Устранение неисправностей 1 в работе клиентов печати
Если драйверы принтера на сервере повреждены, все новые клиенты печати будут загружать поврежденные драйверы. Если предполагается, что проблема связана именно с повреждением драйверов, попытайтесь удалить драйверы на рабочей станции и установите драйверы локально с компакт-диска. Если после этого принтер работает, но прекращает работать после следующего подключения к серверу, переустановите принтер на сервере. Может потребоваться удаление подключения к принтеру на всех клиентах, удаление старых драйверов и повторное подключение к серверу для загрузки обновленных драйверов.
В операционных системах Windows Server 2003, Windows ХР и Windows 2000 клиент подключается к серверу под управлением Windows с помощью вызовов RPC. Если в работе сети возникают проблемы, соединения RPC могут отказать, что приведет к неудачному завершению обработки задания на печать. После разрыва соединения RPC с клиентом печати для восстановления соединения может потребоваться перезагрузка клиента.
Если проблемы в работе RPC возникают постоянно, может возникнуть соблазн разрешить клиентам отправлять задания на печать непосредственно на сетевые устройства печати (если такие устройства используются в организации). Лучше все-таки устранить проблему в работе сети, поскольку устройство сетевого интерфейса не предназначено для обработки десятков одновременных запросов на печать.
Печать на сервере печати от стороннего производителя
Если сетевым клиентом от стороннего производителя предоставляется поставщик печати, этот поставщик и монитор печати стороннего производителя будут работать вместе для передачи задания на печать соответствующему серверу. Задания на печать, отправленные на серверы под управлением операционных систем, отличных от Windows, всегда полностью обрабатываются локально, что требует от клиента потребления больших вычислительных ресурсов.
Если присутствует несколько поставщиков печати, то дополнительного ускорения начала печати можно добиться с помощью сортировки поставщиков в порядке наиболее вероятного обнаружения в сети. Для этого в окне Network Connections (Сетевые подключения) можно воспользоваться окном Advanced Settings (Дополнительные параметры). На рис. 16.24 показан пример списка поставщиков печати. Воспользуйтесь кнопками с изображениями стрелочек для перемещения поставщиков в списке. Перезагрузка после внесения изменений не требуется.
Печать по сети Интернет
Операционные системы Windows Server 2003, Windows ХР и Windows 2000 поддерживают использование протокола Internet Printing Protocol (IPP), который описывается набором документов RFC и Internet Draft. Дополнительная информация о протоколе IPP доступна на
сайте www.normos.org. Для получения документов по этому вопросу выполните поиск по ключевому слову IPP.
Протокол IPP использует протокол HTTP для соединения с сервером печати. В операционной системе Windows для печати обычно используется протокол RPC поверх протокола SMB. Эта связка работает значительно быстрее, чем IPP, но требует устойчивого сетевого соединения. Протокол IPP работает медленнее, но позволяет отправлять задания на печать на ТСР-порт 80 через брандмауэр.
Microsoft Termnal Services Microsoft Windows Network Web Client NetworkMicrosoft Termnal Services Microsoft Windows Network Web Client NetworkВ ф Print ProvidersВ ф Print Providers■^ LanMen Print Services ^ HTTP Print Services■^ LanMen Print Services ^ HTTP Print Services
Microsoft Termnal Services Microsoft Windows Network Web Client Network
Microsoft Termnal Services Microsoft Windows Network Web Client Network
В ф Print Providers
В ф Print Providers
■^ LanMen Print Services ^ HTTP Print Services
■^ LanMen Print Services ^ HTTP Print Services
Puc. 16.24. В окне Advanced Settings (Дополнительные параметры) в аплете Network Connections (Сетевые подключения) отображается список поставщиков печати
Протокол IPP разрабатывался для замены комбинации LPR/LPD, в которой данные передаются открытым текстом. Поскольку протокол IPP использует в качестве транспортного протокол HTTP, для шифрования данных может использоваться механизм Transport Layer Security (TLS).
Требования протокола IPP
Для использования протокола IPP на сервере печати под управлением операционной системы Windows Server 2003 необходимо установить службу IIS (Internet Information Server). Файлы поддержки принтера входят в состав службы IIS и хранятся в виртуальной папке принятого по умолчанию Web-сайта, которая называется Printers (рис. 16.25).
Страницы ASP в папке Printers содержат код, который запрашивает информацию о принтере и доставляет ее клиенту с помощью динамической Web-страницы. Щелкните на принтере для просмотра текущего списка заданий в очереди, а также другой информации (рис. 16.26).
Поскольку файлы поддержки устанавливаются автоматически, от администратора не требуется сложная последовательность действий для предоставления функциональных возможностей IPP. Процесс оказывается еще более автоматизированным, так как клиенты Windows выбирают для печати наиболее эффективный протокол. Локальные клиенты Windows, которые поддерживают соединения RPC, используют стандартный протокол печати. Клиенты Windows,
которые подключаются через брандмауэр и обнаруживают невозможность использования RPC, пытаются использовать IPP поверх HTTP, если открыт доступ через ТСР-порт 80.
^JPrtCabs^JPrtCabsInternet Information Services Я J| SERVERI (local computer) $ Cj Applcatlon PoolsInternet Information Services Я J| SERVERI (local computer) $ Cj Applcatlon Poolslpp.0014.asp jpp_.0015.asp lpp_0016.asp Ipp.adsl.hc jppj-es.hc ipp.uti.hc pagel.asp prtwebvw.csslpp.0014.asp jpp_.0015.asp lpp_0016.asp Ipp.adsl.hc jppj-es.hc ipp.uti.hc pagel.asp prtwebvw.css: .® Ш images ;;•® Q PrtCabs 'SGiSdhwwtiUpdrite. ® yit$web ' .®£2 aspnet.dent ;, ® ^ Administration ' ® A Mfcrosoft SharePoint Adr ®- ^ Defaufc SMTP Vrtual Server ® ^ Defaufc NNTP Vrtual Server :: .® Ш images ;;•® Q PrtCabs 'SGiSdhwwtiUpdrite. ® yit$web ' .®£2 aspnet.dent ;, ® ^ Administration ' ® A Mfcrosoft SharePoint Adr ®- ^ Defaufc SMTP Vrtual Server ® ^ Defaufc NNTP Vrtual Server :a ^ Defa^ Web 516 : : & #H5Helpa ^ Defa^ Web 516 : : & #H5Helplpp.0001.asp lpp.0002.asp lpp.0003.asp lpp.0004.asp lpp.0005.asp lpp.0006.asp lpp_0007.asp lpp.0008.asp lpp_0009.asp lpp.0010.asp lpp.0011.asp lpp.0012.asp lpp.0013.asplpp.0001.asp lpp.0002.asp lpp.0003.asp lpp.0004.asp lpp.0005.asp lpp.0006.asp lpp_0007.asp lpp.0008.asp lpp_0009.asp lpp.0010.asp lpp.0011.asp lpp.0012.asp lpp.0013.aspU1U1
^JPrtCabs
^JPrtCabs
Internet Information Services Я J| SERVERI (local computer) $ Cj Applcatlon Pools
Internet Information Services Я J| SERVERI (local computer) $ Cj Applcatlon Pools
lpp.0014.asp jpp_.0015.asp lpp_0016.asp Ipp.adsl.hc jppj-es.hc ipp.uti.hc pagel.asp prtwebvw.css
lpp.0014.asp jpp_.0015.asp lpp_0016.asp Ipp.adsl.hc jppj-es.hc ipp.uti.hc pagel.asp prtwebvw.css
: .® Ш images ;
;•® Q PrtCabs '
SGiSdhwwtiUpdrite
. ® yit$web ' .®£2 aspnet.dent ;
, ® ^ Administration ' ® A Mfcrosoft SharePoint Adr ®- ^ Defaufc SMTP Vrtual Server ® ^ Defaufc NNTP Vrtual Server :
: .® Ш images ;
;•® Q PrtCabs '
SGiSdhwwtiUpdrite
. ® yit$web ' .®£2 aspnet.dent ;
, ® ^ Administration ' ® A Mfcrosoft SharePoint Adr ®- ^ Defaufc SMTP Vrtual Server ® ^ Defaufc NNTP Vrtual Server :
a ^ Defa^ Web 516 : : & #H5Help
a ^ Defa^ Web 516 : : & #H5Help
lpp.0001.asp lpp.0002.asp lpp.0003.asp lpp.0004.asp lpp.0005.asp lpp.0006.asp lpp_0007.asp lpp.0008.asp lpp_0009.asp lpp.0010.asp lpp.0011.asp lpp.0012.asp lpp.0013.asp
lpp.0001.asp lpp.0002.asp lpp.0003.asp lpp.0004.asp lpp.0005.asp lpp.0006.asp lpp_0007.asp lpp.0008.asp lpp_0009.asp lpp.0010.asp lpp.0011.asp lpp.0012.asp lpp.0013.asp
U1
U1
Puc. 16.25. Консоль IIS Management, на которой отображается папка Printers на принятом по умолчанию Web-сайте
Рис. 16.26. В папке Printers можно просмотреть задания на печать на доступных принтерах на сервере печатиРис. 16.26. В папке Printers можно просмотреть задания на печать на доступных принтерах на сервере печати
Рис. 16.26. В папке Printers можно просмотреть задания на печать на доступных принтерах на сервере печати
Рис. 16.26. В папке Printers можно просмотреть задания на печать на доступных принтерах на сервере печати
Настройка клиента для печати по сети Интернет
Клиент может подключаться к совместно используемому принтеру по протоколу IPP двумя способами:
с помощью мастера добавления принтера, который требует от пользователя знания точного URL для принтера;
с помощью принятой по умолчанию Web-страницы, которая доступна по адресу http://
<сервер_печати>/printers.
Обычно пользователи предпочитают использовать второй вариант доступа.
Если администратор будет настаивать на использовании мастера добавления принтера, пользователям придется вводить URL принтера в окне Specify a Printer (рис. 16.27).
Рис. 16.27. В окне мастера добавления принтера необходимо задать адрес URL интересующего принтера
Используется следующий синтаксис адреса URL:
http://<имя_сервера>/printers/<имя_общего_принтера>/.printer
Точка перед словом printer в конце адреса имеет большое значение. Без этой точки установка соединения завершится неудачно.
Для пользователя намного удобнее выбрать принтер из графического списка. Если пользователь не аутентифицирован в том же домене, в котором находится сервер печати, система выдаст запрос на ввод регистрационных данных.
Для подключения к определенному принтеру щелкните на гиперссылке, соответствующей имени принтера. Откроется страница, на которой показан список заданий на печать, установленных в очередь.
В группе Printer Actions (Операции с принтером) в левой части страницы щелкните на гиперссылке Connect (Подключиться). Будут загружены драйверы принтера. Загрузка драйверов может занять некоторое время, так как в качестве транспортного используется протокол HTTP.
Свойства принтера IPP
Принтер IPP отображается в окне Printers and Faxes (Принтеры и факсы) на локальном клиенте, как обычный сетевой принтер. Если пользователь выбирает печать на принтере IPP и соединение RPC недоступно, то файл сначала преобразовывается локально. После этого файл передается серверу печати в виде простого текста по протоколу HTTP.
Если просмотреть свойства принтера IPP, можно обратить внимание на следующие характеристики.
Имя принтера отображается в окне Printers and Faxes (Принтеры и факсы) в виде <принтер> on http://<1р-адрес>.
На вкладке Sharing (Доступ) отображается сообщение Sharing is not supported for this type of printer (Для этого типа принтера не поддерживается общий доступ).
Имя локального порта будет иметь следующую структуру:
http://<1р_адрес>/printers/<имя_принтера>/.printer
В окне конфигурации порта указываются имя пользователя и пароль. Имя должно отображаться в виде <домен>\<имя_пользователя>, что обеспечивает правильную интерпретацию имени виртуальной папкой IIS.
В остальном принтер выглядит и ведет себя, как обычный сетевой принтер, но работает немного медленнее. Кроме этого, из-за попытки обновления свойств принтера в окне Printers and Faxes (Принтеры и факсы) при первой инициализации открытие окна занимает больше времени, если в окне должны отображаться принтеры IPP.
Если выделить пиктограмму принтера в окне Printers and Faxes (Принтеры и факсы), то в информационной области в левой части окна под заголовком See Also (Дополнительно) предоставляется возможность подключения к Web-сайту принтера. Это позволяет выбрать другой принтер, подключенный к тому же серверу печати.
Если в пределах обширной локальной сети (например, сети университета) существует несколько серверов печати, можно создать внутрисетевой Web-сайт, на котором будут указаны гиперссылки на различные серверы печати. Предоставив географическую информацию на Web-странице, можно предоставить пользователям возможность выбора ближайшего принтера
Совместный доступ к факсам
В составе операционной системы Windows 2000 предоставляется служба Fax, которая позволяет пользователям отправлять документы по факсимильной связи. В составе операционной системы Windows Server 2003 предоставляется одна из возможностей Small Business Server 2000, которая расширяет функциональные возможности службы Fax и позволяет совместное использование факсимильных устройств.
В малой или средней сети эту возможность можно использовать для отправки документов в виде факсимильных сообщений без распечатки и последующей отправки с помощью специализированного устройства. Эту технологию нельзя воспринимать как полноценную замену факсимильной связи уровня предприятия, но в некоторых случаях программное решение оказывается наиболее подходящим с точки зрения стоимости и удобства.
Совместный доступ к факсам поддерживает стандартные факс-модемы и интеллектуальные факс-адаптеры, например Brooktrout TruFax и TRIM или Intel/Dialogic Gammalink. Цена этих адаптеров находится в пределах от 400 долларов за адаптер с одним портом до 5000 долларов за адаптер на 24 порта PRI (Primary Rate Interface) с возможностями маршрутизации входящих звонков. Служба Fax не поддерживает высокоуровневые возможности, например Direct-Inbound-Dialing (DID) и другие технологии маршрутизации. Кроме этого, служба поддерживает не более 4 портов, поэтому желательно выбирать менее дорогие факс-модемы и факс-адаптеры.
Служба Fax предоставляет факс-модем для совместного доступа в виде принтера специального назначения. Клиенты подключаются к принтеру Fax из окна Add Printers and Faxes (Добавить принтер или факс). Существуют драйверы для операционных систем Windows Server 2003, Windows 2000 и Windows ХР.
Служба Windows Server 2003 Fax обратно совместима с локальными клиентами Windows 2000 и с модулем Fax Sharing в Small Business Server. Но архитектура службы была значительно расширена.
Архитектура службы Fax
На рис. 16.28 показана схема совместного доступа к факсу, которая применяется в операционной системе Windows Server2003. Служба факса состоит из выполняемого файла, Fxssvc.exe,
который предоставляет клиентский программный интерфейс для обработки сообщений, и набора соединений для доставки факсов на факс-модем или принтер.
Для связи с факс-модемами служба Fax использует технологию Telephony API (TAPI). Это значит, что служба должна работать вместе с другими клиентами TAPI, например сетевыми клиентами, телефонными клиентами и клиентами маршрутизации. Для отправки факсов можно использовать тот же модем, что и для подключения к сети, но для промышленного факс-сервера подобное использование модема не рекомендуется. Вместо этого желательно следовать правилу “одна функция — один модем”.
Рис. 16.28. Архитектура совместного использования факса
Кроме этого, служба Fax отправляет полностью преобразованные факс-документы на устройство печати. Для этого используется специальный монитор факс-принтера. Этот монитор связывается с локальным спулером или с сетевым поставщиком печати.
Служба Fax предоставляет простой набор вариантов маршрутизации для входящих факсов. Автоматическая маршрутизация на основе номера Direct-Inbound-Dialing (DID) не поддерживается. Также не поддерживается сканирование заголовка факса для получения имени получателя, как это делает большинство коммерческих служб факсов, но факс может быть отправлен на принтер, в файл и по адресу электронной почты одного пользователя. Этот
пользователь может прочитать факс и передать его содержимое по электронной почте указанному в сообщении получателю.
Факс-адаптеры и сеть
Если приходится работать в безопасной среде, в которой на серверы запрещено устанавливать модемы, так как это создает бреши в системе безопасности сети, может потребоваться установка интеллектуального факс-адаптера. Такие адаптеры принимают входящие соединения только от факс-машин.
Установка службы Fax
В отличие от других сетевых функций, служба Fax по умолчанию не устанавливается. Для установки этой службы можно воспользоваться аплетом Add/Remove Programs (Установка и удаление программ), доступным на Control Panel (Панель управления).
Кроме этого, на сервере необходимо установить факс-модем или факс-адаптер. Для эко-' номии собственного времени воспользуйтесь факс-модемом, который указан в списке совместимых аппаратных средств по адресу www.microsoft.com/hcl. Это не означает, что другие модемы не работают, но цифровая связь по аналоговым каналам считается загадочной и волшебной технологией, а добавление факсимильной связи к этой комбинации делает ее еще более сложной. Лучше всего максимально снизить вероятность отказа.
Если в системе установлен внутренний модем или модем подключен по шине USB, подсистема Plug-and-Play автоматически обнаружит устройство и загрузит необходимые драйверы. Для проверки правильности установки можно воспользоваться консолью Device Manager (Диспетчер устройств), файл Devmgmt.msc. Если установить внешний модем, подключенный к последовательному порту, модем не будет обнаружен автоматически. Для принудительного запуска сканирования шины можно щелкнуть правой кнопкой мыши на пиктограмме корня дерева устройств в окне Device Manager (Диспетчер устройств) и выбрать команду Scan for Hardware Changes (Обновить конфигурацию оборудования). Модем будет обнаружен, и автоматически будут установлены необходимые драйверы. В противном случае придется самостоятельно установить драйверы, совместимые с операционной системой Windows Server 2003 или Windows 2000.
Настройка службы Fax
После установки факс-модема или факс-адаптера и запуска службы Fax можно настроить параметры сервера. Это делается одним из трех способов, которые описаны в следующих разделах.
Запустите консоль Fax с помощью команды Start*Programs*Accessories*Communi- cations*Fax (Пуск*Программы*Стандартные*Связь*Рах). Будет запущен мастер настройки факса (Fax Configuration Wizard), который позволяет выбирать нужные параметры настройки в автоматически открывающихся окнах.
В окне Printers and Faxes (Принтеры и факсы) щелкните на гиперссылке Add A Local Fax Printer. После установки факса откройте окно Properties (Свойства) и задайте необходимые параметры конфигурации.
Запустите консоль Fax Service Manager, Fxsadmin.msc. Для этого выберите Start* Programs*Accessories1*Communications* Fax (Пуск* Программы* Стандартные* Связь* Fax) и воспользуйтесь консолью для настройки службы.
Консоль Fax Service Manager предоставляет больше возможностей, поэтому стоит выбирать именно этот вариант. Но мастер более удобен в использовании. Мастер выдает такую последовательность запросов.
Информация об отправителе. Эта информация используется для заполнения титульных листов факсимильного сообщения.
Параметры конфигурации модема. Эти параметры используются для настройки набора номера на модеме.
Свойства отправки и приема. Эти параметры используются для установки идентификаторов Transmitting Service ID (TSID) и Client Service ID (CSID), которые включаются в состав факсимильного сообщения и отображаются на панели факс-устройства.
Параметры маршрутизации. Эти параметры позволяют выбрать печать, сохранение в файле, перенаправление по адресу электронной почты пользователя или все три операции для входящих факсимильных сообщений.
Параметры хранения. Здесь можно выбрать папки для хранения полученных и отправленных сообщений.
Если после использования мастера возникает необходимость изменить один или несколько параметров, то информация об отправителе и выбранный каталог хранения сообщений могут быть модифицированы на консоли Fax. Все остальные параметры могут быть изменены на консоли Fax Service Manager.
Установка параметров модема
Чтобы задать параметры факс-модема или факс-адаптера, можно воспользоваться окном Properties (Свойства) на консоли Fax Service Manager (рис. 16.29).
Если имя получателя и номер факса должны быть показаны в заголовке исходящих факсов, введите эту информацию в поле Transmitting Station ID (TSID).
По умолчанию модем настраивается только на отправку факсимильных сообщений. Это делается с целью усиления безопасности. Если необходимо принимать факсы, установите соответствующий параметр. Если название вашей компании и номер факса должны отображаться у отправителя при получении вами факса, введите эту информацию в поле Calling Station ID (CSID).
Рис. 16.29. Окно свойств факс-модема, в котором показаны поля TSID, CSID и параметры автоматического ответа
Выберите, после скольких звонков необходимо отвечать на входящий вызов. По умолчанию это количество устанавливается равным 1. Оставьте значение принятым по умолчанию, кроме случаев настройки сервера для малого бизнеса, в котором телефонная линия одновременно используется для передачи факсимильных сообщений и для голосовой связи. В таком случае ответ факс-модема можно задержать на несколько звонков.
Кроме этого, службу Fax можно настроить на отает, если на другом конце линии обнаруживается факс-модем. Эта технология называется Adaptive Answering и поддерживается не всеми модемами. Служба Fax не пытается проверить поддержку этой возможности модемом. Для определения поддержки этой технологии обратитесь к руководству пользователя вашего модема.
Настройка обработки входящих факсимильных сообщений
Если выделить пиктограмму Incoming Methods в окне факс-модема, то будет показано три метода обработки входящих сообщений. Для настройки методов обработки откройте окно Properties (Свойства) и перейдите на интересующую вкладку. Доступны следующие варианты.
Print (Печать). Из списка настроенных на сервере принтеров можно выбрать принтер, на который будут перенаправляться полученные сообщения. На этот принтер будет отправляться каждое полученное сообщение. Выбор нескольких принтеров не поддерживается, как не поддерживается выбор резервного принтера.
Store in a Folder (Хранение в папке). Введите путь к папке, в которой должны храниться все входящие сообщения. Это должен быть том с большим объемом дискового пространства. Иногда скорость накопления входящих факсов просто удивляет.
Route Through E-mail (Перенаправление по адресу электронной почты). Этот вариант требует настройки уведомлений при получении факсов. Дополнительная информация приводится во врезке “Перенаправление факсов по адресу электронной почты”.
После настройки вариантов обработки включите настроенные варианты, щелкнув правой кнопкой мыши на пиктограмме и выбрав команду Enable (Применить) из контекстного меню.
Перенаправление факсов по адресу электронной почты
Служба Fax не поддерживает возможности маршрутизации Direct-Inbound-Dialing (DID), но входящие сообщения можно перенаправлять по адресу электронной почты. Это может быть специальный почтовый ящик, адрес которого может выглядеть, например, как faxadmin@ company.com. Секретарь офиса может просматривать содержимое этого ящика и перенаправлять сообщения соответствующим получателям.
Для этого служба Fax должна быть настроена на отправку сообщений по протоколу SMTP. Затем можно настроить параметры маршрутизации входящих сообщений. Для этого можно воспользоваться консолью Fax Service Manager, как показано ниже.
Щелкните правой кнопкой мыши на пиктограмме Fax (local) на вершине дерева и выберите из контекстного меню команду Properties (Свойства)..
Активизируйте вкладку Уведомления (Receipts), окно которой показано на рис. 16.30.
Установите флажок Enable SMTP E-mail Receipts Delivery (Разрешить доставку SMTP- уведомлений по электронной почте).
Введите адрес электронной почты предполагаемого получателя, а также IP-адрес или имя DNS-сервера электронной почты получателя.
Установите флажок Use This Configuration For The Microsoft Route Through E-Mail Incoming Routing Method (Использовать эту конфигурацию для механизма перенаправления входящих сообщений через электронную почту).'
Щелкните на кнопке ОК, чтобы сохранить изменения и закрыть окно.
Fiom rmri ad<* емFiom rmri ad<* емServe# eddrets.Serve# eddrets.|admjn@compary Jl92J6aO23|admjn@compary Jl92J6aO23OutoON GeneralOutoON GeneralSMTP rmri-P ЕмН» SMTP Mai new» Мн?SMTP rmri-P ЕмН» SMTP Mai new» Мн?Puc. 1630. Вкладка Receipts (Уведомления) окна Fax Properties (Свойства факса)Puc. 1630. Вкладка Receipts (Уведомления) окна Fax Properties (Свойства факса)Рис. 1631. Окно Route through e-mail Properties (Свойства маршрутизации через электронную почту)Рис. 1631. Окно Route through e-mail Properties (Свойства маршрутизации через электронную почту)
Fiom rmri ad<* ем
Fiom rmri ad<* ем
Serve# eddrets.
Serve# eddrets.
|admjn@compary Jl92J6aO23
|admjn@compary Jl92J6aO23
OutoON General
OutoON General
SMTP rmri-
P ЕмН» SMTP Mai new» Мн?
SMTP rmri-
P ЕмН» SMTP Mai new» Мн?
Puc. 1630. Вкладка Receipts (Уведомления) окна Fax Properties (Свойства факса)
Puc. 1630. Вкладка Receipts (Уведомления) окна Fax Properties (Свойства факса)
Рис. 1631. Окно Route through e-mail Properties (Свойства маршрутизации через электронную почту)
Рис. 1631. Окно Route through e-mail Properties (Свойства маршрутизации через электронную почту)
Откройте окно Properties (Свойства) для параметра Route Through E-mail Properties (Свойства маршрутизации через электронную почту) в разделе Devices and Providers^Devices1* <UMa_ycmpoucmea>,=>lncoming Methods (Устройства и поставщикиЦ>УстройстваЦ><#тл/>7_ устройства Ф Методы обработки входящих сообщений), которое показано на рис. 16.31.
Введите тот же адрес электронной почты, который вводился в окне SMTP E-mail Receipts Delivery (Доставка уведомлений по электронной почте).
Щелкните на кнопке ОК, чтобы сохранить изменения и закрыть окно.
Проверьте конфигурацию, отправив факс на факс-сервер и убедившись, что копия факсимильного сообщения отправлена пользователю на указанный адрес электронной почты.
, MetvyoBo*
P ЕмЫв яммоа Ьокм * teempte
Порядок вариантов маршрутизации можно менять. Методы маршрутизации указаны в разделе Incoming Routing^Global Methods (Входящая маршрутизация^Глобальные методы). Щелкните правой кнопкой мыши на пиктограмме и щелкните на кнопке Move Up или Move Down для изменения порядка вариантов. Система будет отправлять факсимильные сообщения с использованием всех настроенных методов маршрутизации. Порядок-сортировки просто определяет очередность использования методов.
Подключение клиента к факс-серверу
Клиенты могут взаимодействовать со службой Fax двумя способами. Самым распространенным способом является использование факс-сервера в качестве сервера печати. Клиент загружает драйвер, предназначенный для взаимодействия со службой Fax на сервере.
Драйверы факс-принтера для операционной системы Windows Server 2003 работают и в операционных системах Windows ХР и Windows 2000. Клиенты загружают эти драйверы автоматически.
Другие методы отправки факсов предполагают запуск приложений, поддерживающих Fax API из состава операционной системы Windows Server 2003. Такое взаимодействие происходит в обход драйвера печати, и клиент связывается непосредственно со службой Fax. Эти приложения должны появиться сразу после выхода операционной системы Windows Server 2003.
Отправка факсимильного сообщения
Для отправки факсимильного сообщения пользователь должен отправить задание на печать для объекта факс-принтера или выбрать Start^Programs^Accessories^Communications1* Fax^Send a Fax (Пуск^Программы^Стандартные^Связь^Факс^Отправить факс). В любом случае система запускает мастер отправки факса (Send Fax Wizard), Fxssend.exe, который выдает запрос на ввод имени получателя и номера факса (рис. 16.32).
Рис. 16.32. Окно Recipient Information (Информация о получателе) мастера отправки факса (Send. Fax Wizard)
Протокол IPP и отправка заданий на печать на факс
Печать на факс-принтер по протоколу HTTP не поддерживается. Если просмотреть список принтеров по адресу http://<cepsep>/Printers, то можно заметить факс-принтер. Но если щелкнуть на гиперссылке этого принтера, окажется, что возможность подключения к принь теру отсутствует.
Отправитель может ввести информацию непосредственно или выбрать контактную информацию из адресной книги (базы данных, которая хранится локально в профиле пользователя в каталоге Application DataXMicrosoft\Address Book). Для добавления записей в адресную книгу пользователь может воспользоваться мастером отправки факса (Send Fax Wizard) или утилитой Windows Address Book (Адресная книга), файл Wab.exe. Для запуска этой утилиты выберите Start^Programs^Accessories^Address Book (Пуск^Прог- раммы1^ Стандартные^ Адресная книга).
Введенная в окне мастера информация о получателе используется для заполнения заголовка факсимильного сообщения. Служба Fax предоставляет несколько стандартных типов заголовков. Заголовки хранятся в профиле All Users в каталоге Application Data\ Microsof t\Windows NT\MSFax\Common Coverages. Эта папка предоставляется для со-
вместного доступа под именем FxsSrvCp$. Это позволяет сетевым клиентам получать доступ к страницам заголовков при печати на факс-сервере.
Страницы заголовков имеют специальный формат, в котором для вывода информации об отправителе и получателе используются специальные привилегии. Дополнительная информация о страницах заголовков приводится в следующем разделе.
В мастере Send Fax Wizard можно настроить немедленную отправку сообщения, отправку в определенное время или во время сниженной стоимости подключения. Расписание сйижен- ной стоимости настраивается на сервере на консоли Fax Service Manager. Щелкните на пиктограмме Fax (local) и выберите из контекстного меню команду Properties (Свойства). Перейдите на вкладку Outbox (Исходящие), которая показана на рис. 16.33. Кроме этого, пользователь может назначать приоритеты исходящим сообщениям. В соответствии с заданным приоритетом сортируются сообщения, поставленные в очередь.
Рис. 16.33. В окне свойств службы Fax на вкладке Outbox (Исходящее) можно задать параметры набора номера и установки приоритета
Отправка сообщений с использованием контактов Exchange
Если используется служба Exchange, можно воспользоваться Global Address List (GAL) для выбора контактов. Для этого необходимо установить в программе Outlook компонент Fax Transport.
Наконец, можно задать параметры уведомления о доставке. Это позволит успокоить пользователей, которые стоят возле факсимильного аппарата и “обязательно хотят убедиться” в отправке сообщения. Можно запросить отправку уведомления в виде всплывающего окна, но такое уведомление имеет смысл только на консоли компьютера. Кроме этого, можно выбрать отправку сообщения электронной почты с добавлением копии факса в виде вложения. Если пользователь отправляет сообщение нескольким получателям, можно настроить отправку единственного уведомления.
Пользователь может просмотреть факсимильное сообщение перед отправкой. Для этого используется Windows Picture and Fax Viewer. Утилита просмотра состоит из динамически под-
ключаемой библиотеки Shimgvw.dll, которая открывается с помощью утилиты Rundll32. При двойном щелчке на файле с расширением, для которого установлена привязка к этой утилите, система запускает следующую команду:
rund!132 shimgvw.dll,ImageView_Fullscreen <путь_к_изображению>
Утилита просмотра позволяет увеличивать, поворачивать, распечатывать и открывать изображения в графическом редакторе для модификации файла. Утилита просмотра позволяет просматривать многостраничные документы. В утилите отсутствуют возможности оптического распознавания текста, которые обеспечивают сохранение содержимого факса в текстовом файле.
Кроме этого, данная утилита предназначена для просмотра, а не для редактирования. Для редактирования можно воспользоваться стандартным редактором изображений Microsoft Paint.
Управление титульными страницами
В составе операционной системы Windows Server 2003 предоставляется редактор Cover Page Editor, Fxscover. exe, который проектировался для создания или изменения титульных страниц, совместимых со службой Fax. Для запуска редактора выберите Starts Programs^ Accessories^Communications^Fax^Fax Cover Page Editor (Пуск1^Программы^Стандарт- ные^Связь^Факс^Титульная страница). Пример титульной страницы, открытой в редакторе, показан на рис. 16.34.
В меню Insert (Вставка) предоставляется возможность вставки полей в титульную страницу. В этих полях можно указать имя отправителя и информацию о факсе. Информация о получателе предоставляется мастером отправки факса или извлекается из адресной книги. Информация об отправителе извлекается из системного реестра рабочей станции отправителя.
Информацию об отправителе можно изменить с помощью консоли Fax, Fxsclnt.exe. Для запуска консоли используйте команду Start^Programs^Accessories^Communications^ Fax (Пуск^Программы^Стандартные^Связь^Рах). После этого используйте команду Tools^ Sender Information (Сервис^ Информация об отправителе) (рис. 16.35).
Го,-Fax Number:Го,-Fax Number:{Recipient Name}{Recipient Fax Number){Recipient Name}{Recipient Fax Number)
Го,-
Fax Number:
Го,-
Fax Number:
{Recipient Name}
{Recipient Fax Number)
{Recipient Name}
{Recipient Fax Number)
From:Fax Number:Business Phone:Home Phone:From:Fax Number:Business Phone:Home Phone:{Sender Name){Sender Fax#}{Sender's Office Telephone #}{Sender's Home Telephone #}{Sender Name){Sender Fax#}{Sender's Office Telephone #}{Sender's Home Telephone #}
From:
Fax Number:
Business Phone:
Home Phone:
From:
Fax Number:
Business Phone:
Home Phone:
{Sender Name)
{Sender Fax#}
{Sender's Office Telephone #}
{Sender's Home Telephone #}
{Sender Name)
{Sender Fax#}
{Sender's Office Telephone #}
{Sender's Home Telephone #}
Puc. 16.34. Титульная страница, открытая в CoverPage Editor
Консоль Fax можно использовать для создания новых титульных страниц, хотя намного проще скопировать существующую страницу и внести необходимые изменения.
Рис. 1635. Консоль Fax, окно Sender Information (Информация об отправителе)
Управление очередями и факс-устройствами
На консоли Fax можно настроить входящие и исходящие очереди сообщений, а также факс-устройства. Интерфейс очереди на консоли Fax предоставляет четыре области, которые выступают в роли окон для содержимого спулера на диске.
Incoming (Входящие). Это сообщения, принятые факс-устройством, но еще не обработанные.
Inbox (Полученные). Это обработанные факсы. По умолчанию файлы, созданные более 90 дней тому назад, автоматически удаляются.
Outgoing (Исходящие). Эти факсы ожидают отправки получателям.
Sent Items (Отправленные). Это копии исходящих факсов. По умолчанию удаляются сообщения, созданные более 1 дня тому назад.
Сообщения в очереди могут просматриваться с помощью Windows Picture и Fax Viewer. Интервалы автоматического удаления можно изменить с помощью консоли Fax Service Manager.
Мониторинг активности факс-сервера
Для наблюдения за активностью факс-сервера можно воспользоваться приложением Fax Monitor, Fxsmntr. ехе. Для запуска этой утилиты на основной консоли Fax необходимо выбрить Tools'^Fax Monitor (Сервис=>Монитор). Будет показан небольшой график, который отображает интенсивность передачи данных между факс-клиентами и факс-сервером.
Вместо просмотра графика на протяжении всего дня можно включить ведение журнала. Служба Fax ведет два журнала.
Журнал активности. В этом журнале записывается информация об отправителе, получателе, времени и имени файла факс-документа. Журнал активности хранится в профиле All Users в каталоге Application DataXMicrosoft\Windows NT\MSFax\ Activity Log. Этот путь можно изменить в окне Fax Service Manager.
Журнал событий. Служба Fax сохраняет в этом журнале предупреждения, ошибки и критически важные события. Журнал можно просматривать с помощью консоли Event Viewer (Просмотр событий).
На этом этапе тему управления и настройки факсимильных служб можно считать законченной. Опять обратимся к печати и рассмотрим управление службами печати.
Управление службами печати
Несмотря на всю сложность и количество протоколов, служба печати в операционной системе Windows Server 2003 предоставляет очень мало настраиваемых компонентов.
Очереди печати. Очереди показаны в окне Printer and Faxes (Принтеры и факсы). Для просмотра списка заданий каждую очередь придется открывать отдельно.
Свойства сервера печати. Свойства сервера доступны в основном меню окна Printer and Faxes (Принтеры и факсы). В этом окне можно управлять портами и драйверами, а также настраивать правила отправки уведомлений и регистрацию событий в журнале.'
Безопасность принтера. Эти параметры позволяют управлять списком пользователей, которые могут печатать на принтере, управлять принтером и управлять заданиями в очереди печати.
Управление очередями печати
В окне Printer and Faxes (Принтеры и факсы) можно проверять состояние документов в очереди и управлять принтером в целом и каждым документом в очереди. Для этого необходимо обладать привилегиями Print Operator (Оператор печати) в домене или привилегиями Power User (Опытный пользователь) на локальном компьютере.
Двойной щелчок на пиктограмме принтера открывает окно, в котором показаны задания, установленные в очередь. Щелкните правой кнопкой мыши на пиктограмме принтера. Будет выдан список возможных действий. Большинство названий говорят сами за себя. Вот несколько интересных пунктов.
Set As Default (Выбрать по умолчанию). Эта команда делает принтер заданным по умолчанию для всех заданий. Большинство приложений использует стандартные вызовы Win32 API и принтер, заданный по умолчанию. Если такой принтер не выбран, вызов функции завершится неудачно.
Use Printer Offline (Использовать принтер автономно). Эта команда позволяет использовать принтер автономно. Задания на печать будут накапливаться в очереди, пока устройство печати недоступно. В противном случае при недоступности устройства печати будут выдаваться сообщения об ошибках.
Pause Printing (Приостановить печать). Все операции по печати останавливаются, но спулер продолжает принимать новые задания.
Щелкните правой кнопкой мыши на документе в очереди печати. Откроется контекстное меню с доступными командами. Пользователи, обладающие стандартными привилегиями печати, могут просматривать список заданий, но остановка и отмена печати разрешена только для заданий, владельцем которых является данный пользователь.
При отмене задания файлы с расширениями . spl и . shd удаляются из каталога спулера. Если приостановить печать с последующим возобновлением, печать продолжится со следующей страницы. Если выбрать перезапуск задания, печать начнется с первой страницы.
Откройте окно Properties (Свойства) для документа. В окне будет показана дополнительная информация о задании на печать (рис. 16.36).
На вкладке General (Общие) отображается информация о задании, включая количество страниц, назначенный тип данных и имя процессора печати. Всегда указывается имя Winprint, хотя современный процессор печати называется Localspl. Если задание было отправлено с компьютера Macintosh, процессор печати будет называться Sfmpsprt. Кроме этого, выводится информация о времени создания задания на печать и владельце задания.
Рис. 1636. Свойства задания на печать
На вкладке Layout (Расположение) можно управлять ориентацией листа. Щелкнув на кнопке Advanced (Дополнительно), можно получить доступ к специальным параметрам устройства. Эти параметры предоставляются мини-драйвером от производителя. В качестве примера принтера с большим набором дополнительных возможностей можно назвать Xerox DocuCen- ter, который поддерживает создание документов в любом формате, включая создание раздельно прошитых книг с отдельными обложками.
На вкладке Paper/Quality (Бумага/Качество) предоставляются параметры для выбора разрешения, настройки соответствия цветов, выбора источника бумаги и т.д.
Настройка параметров сервера печати
Вместо настройки параметров каждого принтера в отдельности можно настроить параметры всего сервера печати. Для этого в окне Printers and Faxes (Принтеры и факсы) воспользуйтесь командой Prints Print Server Properties (Печать^Свойства сервера печати). Для устранения проблем при печати пользовательских заданий можно применить вкладку Advanced (Дополнительно).
Флажок Notify When Remote Documents Are Printed (Уведомлять о печати удаленных документов) позволяет включить всплывающее сообщение на компьютере пользователя при
завершении отправки задания на устройство печати. Это не значит, что задание было полностью напечатано, так как этой информацией обладает только устройство печати.
Можно сбросить флажок Log Spooler Information Events (Вносить в журнал события спулера). Обычно установка этого флажка приводит к внесению в журнал событий слишком большого объема информации. Действительно полезная информация может утонуть в море сообщений об успешном завершении печати.
Флажки Веер On Errors Of Remote Documents (Сигнал при ошибках печати удаленных документов) и Show Informational Notifications for Local Printers (Показывать информационные уведомления для локальных принтеров) редко оказываются полезными, так как для получения данного уведомления о проблемах в печати задания придется находиться возле сервера печати. Но не стоит о них забывать, так как они могут пригодиться во время устранения неисправностей.
Остальные варианты уведомления могут быть отключены во время нормальной работы. Их стоит использовать только во время устранения неисправностей.
Безопасность принтера
Безопасность принтера включает в себя управление принтерами (логическими принтерами, а не физическими устройствами), документами в очереди печати и возможности добавлять документы в очередь. Существует три основных права доступа, которые необходимы для такого управления.
Print (Печать). Право добавлять задание на печать в очередь.
Manage Printers (Управление принтерами). Право создавать и удалять принтеры, приостанавливать и запускать очереди, а также изменять параметры настройки принтеров.
Manage Documents (Управление документами). Право удалять и изменять свойства заданий в очереди, принадлежащих другим пользователям.
Находящиеся в очереди задания на печать подчиняются правам доступа файловой системы NTFS. Владельцем находящихся в каталоге спулера файлов является владелец задания на печать. Право доступа Manage Documents (Управление документами) предоставляет пользователю право управлять собственными файлами в каталоге \Windows\System32\ SpoolXPrinters.
Список контроля доступа для принтера можно просмотреть в окне Printer (Принтер). Для этого в меню окна необходимо выбрать Printers Properties (Принтер^Свойства) и активизировать вкладку Security (Безопасность). Доступны следующие стандартные права доступа.
Группа Administrators (Администраторы) — право Full Control (Полный доступ)
Группа Creator/Owner (Создатель-владелец) — право Manage Documents (Управление документами)
Группа Everyone (Все) — право Print (Печать)
Группа Print Operators (Операторы печати) (группа Power Users (Опытные пользователи) на изолированном компьютере) — право Full Control (Полный доступ)
Группа Server Operators (Операторы сервера) — право Full Control (Полный доступ)
Если необходимо ограничить доступ к принтеру, например, только отдельным сотрудникам предоставляется право печатать на цветном принтере для плакатов IRIS стоимостью 150 тыс. долларов. Соответствующих пользователей и группы можно добавить в список контроля доступа и предоставить им необходимые права.
Базовые права доступа для факсов совпадают со стандартными правами доступа для принтеров. Дополнительные права доступа, доступные после щелчка на кнопке Advanced View (Дополнительные параметры) редактора ACL Editor, позволяют указывать приоритет факсов и просматривать архив факсов.
Политики печати
Групповые политики позволяют удобно управлять печатью в пределах предприятия. Существует около двух десятков политик для управления принтерами и факсами, Которые позволяют определить, кто может печатать, что печатать, кому разрешено создавать и удалять принтеры, а также определяют, что компьютер должен делать с сохраненными заданиями на печать.
Перечислим политики печати, которые могут оказаться полезными.
Custom Support URL in the Printers Foder's Left Pane(Собственный адрес URL в левой панели папки Принтеры). У этой политики очень длинное название, поскольку она предоставляет очень полезную возможность. В левой панели окна Printers and Faxes (Принтеры и факсы) присутствует ссылка, которая называется Get Help With Printing. Обычно эта ссылка указывает на справку по печати на сайте компании Microsoft. С помощью этой групповой политики можно указать ссылку на собственный Web-сайт. Эта возможность оказывается очень полезной для службы поддержки.
Browse a Common Web Site То Find Printers (Обзор общего Web-сайта в поисках принтеров). При включении этой политики и предоставлении адреса URL система добавляет ссылку Browse The Intranet в окне Specify A Printer (Выберите принтер) мастера добавления принтера. Для ссылки используется заданный в политике адрес URL, который обычно указывает на виртуальную папку Printers на сервере печати. Это отличный способ предоставить пользователям доступ к списку принтеров.
Default Active Directory Path When Searching For Printers (Принятый по умолчанию путь Active Directory для поиска принтеров). Эта политика позволяет ограничить поиск в Active Directory из окна мастера добавления принтера определенной организационной единицей или доменом вместо поиска по всей базе данных Active Directory. Но политика не настолько универсальна, поскольку она не позволяет ограничить поиск Search For Printers в окне Search (Найти), доступном из меню Start (Пуск).
Prevent Addition of Printers (Запретить добавление принтеров). Если администратор устал устранять проблемы в работе принтеров, он может установить эту политику и взять создание принтеров полностью под свой контроль. Включение этой политики приводит к удалению окна Add Printers (Добавить принтер) из пользовательского интерфейса. Умные пользователи все еще могут подключить принтер с помощью команды net use или с помощью мастера Add Hardware Wizard (Мастер добавления нового устройства), но пользователи редко обладают таким уровнем знаний. Администратор может добавлять принтеры с помощью сценариев.
Управление свойствами принтеров
В окне Properties (Свойства), доступном из окна Printers and Faxes (Принтеры и факсы), предоставляются параметры конфигурации для следующих возможностей.
Совместный доступ
Управление портами
Безопасность
Параметры устройства печати
Параметры устройства печати предоставляются мини-драйверами принтера и фильтрами, установленными при установке драйверов от производителя. Предоставляются параметры управления лотками, сшивателями, размером страницы и т.д. Список параметров слишком велик, чтобы приводить его на страницах этой книги.
Совместный доступ
На вкладке Sharing (Доступ), кроме обычного совместного доступа к принтеру, предоставляются еще две возможности. Кнопка Additional Drivers (Дополнительные драйверы) позволяет получить доступ к списку флажков для альтернативных клиентов, которые могут загружать драйверы при подключении к совместно используемому принтеру. Некоторые драйверы доступны на установочном компакт-диске Windows Server 2003 в каталоге \ Printers. Остальные необходимо загрузить с Web-сайта производителя.
Если возникла противоположная ситуация, когда сервер печати под управлением Windows NT 4.0 обслуживает клиентов под управлением Windows Server 2003 и Windows ХР, в системе Windows NT 4.0 можно установить обновленные драйверы с помощью утилиты fixprnsv, доступной в папке \Printers на установочном компакт-диске операционной системы Windows Server 2003.
С помощью флажка List in Directory (Публиковать в каталоге) совместно используемый принтер можно опубликовать в Active Directory. Публикация принтера позволяет пользователям быстро находить ресурсы принтеров с помощью окна Search (Поиск).
С публикацией принтера в Active Directory связано несколько сложностей. Эти сложности возникают из-за способности Active Directory удалять опубликованные принтеры, которые не указывают на активные принтеры. Такая ситуация может возникнуть при отключении сервера печати от сети, удалении принтера или разрыве сетевого соединения.
Агент удаления запускается на контроллере домена каждые 8 часов. В это время агент удаления пытается проверить каждый принтер, который был опубликован в Active Directory. Если в течение трех попыток не удалось установить связь с принтером, агент удаляет объект Pr intQueue из базы данных Active Directory.
Сервер печати под управлением Windows 2000 или Windows Server 2003 выполнит повторную публикацию принтеров сразу же после включения в сеть. Если опубликовать принтеры, подключенные к клиенту более старой версии, их придется публиковать повторно после включения сервера.
Для изменения параметров удаления можно воспользоваться рядом групповых политик. Политики хранятся в разделе Computer Configuration^Administrative Templates^Printers (Конфигурация компьютера^ Административные шаблоны1^ Принтеры). Ниже приведен список этих политик.
Directory Pruning Interval (Интервал удаления из каталога). Эта политика определяет частоту проверки состояния принтеров для объекта PrintQueue в базе данных Active Directory. По умолчанию этот интервал устанавливается равным 8 часам.
Directory Pruning Retry (Количество попыток при удалении). Эта политика определяет количество попыток подключения перед тем, как принтер будет признан отключенным. По умолчанию используются 2 попытки.
Directory Pruning Priority (Приоритет удаления из каталога). Эта политика определяет приоритет агента удаления принтеров. По умолчанию агент работает с нормальным приоритетом.
Check Published State (Проверять состояние публикации). Эта политика заставляет сервер печати постоянно публиковать ресурсы принтеров в базе данных Active Directory вместо публикации ресурсов после перезагрузки сервера печати. Эту политику стоит устанавливать только в случае нестабильной работы сети, которая приводит к удалению опубликованных ресурсов. Неисправность должна быть достаточно серьезной, чтобы привести к отключению в течение 24 часов.
Порты
На вкладке Ports (Порты) окна свойств принтера перечислены назначенные принтеру порты, а также другие доступные порты и связанные с ними принтеры. Если необходимо изменить порт, назначенный устройству печати или изменить свойства самого порта, такие изменения можно внести на этой вкладке.
Именно на этой вкладке необходимо менять адрес, заданный для монитора портов Tcpmon, если на сетевом интерфейсе принтера был изменен 1Р-адрес.
Если рабочая группа пользователей создает большой объем бумажных отчетов (почему вспоминается бухгалтерия?), то общую пропускную способность подсистемы печати можно увеличить с помощью установки нескольких устройств печати для одного логического принтера. Такая конфигурация называется пулом принтеров (printer pooling). Это не приведет к ускорению печати конкретных заданий, но позволит избежать накопления заданий в очереди печати.
При использовании пула принтеров убедитесь, что все устройства печати в составе пула поддерживают работу под управлением драйвера, назначенного принтеру. Устройства печати не обязательно должны быть одной модели, но они должны воспринимать одинаковые коды управления принтером. Например, не стоит совмещать принтеры Postscript уровней 2 и 3 в одном пуле, которому назначен драйвер Postscript уровня 3.
Дополнительные параметры
На вкладке Advanced (Дополнительно) в окне свойств принтера предоставляется набор дополнительных параметров. В табл. 16.2 перечислены доступные параметры и примеры их использования.
Таблица 16.2. Дополнительные параметры принтеров
Параметр
Функция
Примеры и замечания
Available From (Доступен с)
Назначение времени, с которого принтер будет отправлять задания на устройство печати. Созданные в остальное время задания помещаются в очередь
Если в организации установлено большое количество цветных принтеров, которые могут использоваться работниками в нерабочее время, можно создать принтер и назначить параметр Available Hours (Часы доступности), чтобы задания печатались ночью
Priority (Приоритет)
Если существует несколько принтеров, которые получают задания с одного устройства печати, спулер будет поочередно отправлять задания из очередей. Если задания из очереди одного принтера должны печататься раньше заданий из другой очереди, установите большее значение приоритета для первой очереди
Принтер большого формата может постоянно использоваться отделом Art и иногда — отделом Technical Documentation. Если дизайнеры жалуются, что им приходится ждать завершения печати заданий, отправленных из отдела технической документации, можно создать отдельный принтер для дизайнеров с большим приоритетом
Driver (Драйвер)
Если для принтера выпущен новый драйвер или заменено устройство печати, связанное с принтером, эта кнопка позволяет установить новый драйвер. Если принтер предоставляется для совместного доступа, подключающиеся пользователи автоматически загрузят новый драйвер
Если заменить драйвер, установочный сценарий может изменить название принтера. В таком случае подключенные клиенты не смогут найти совместно используемый принтер, даже если имя ресурса не изменилось. Перед установкой драйвера существующего принтера скопируйте имя принтера в буфер обмена, чтобы иметь возможность восстановить оригинальное имя
Параметр
Функция
Примеры и замечания
Spool Print Documents ... /Start Printing Immediately (Помещать документы в спу- лер/Немедленно печатать документы)
Этот параметр заставляет спулер принимать входящие задания на печать, "на лету" преобразовывать поток данных и одновременно с этим отправлять задания на устройство печати
Этот параметр позволяет ускорить печать больших документов. Если по какой-то причине печать задания завершится неудачно, спулер получит соответствующее уведомление от мониторе печати; задача будет полностью помещена в очередь спулера и отправлена на устройство печати повторно
Print Directly to Printer (Печатать непосредственн о на принтер)
Этот параметр разрешает спулеру не сохранять задание на локальном жестком диске. Задание преобразовывается "на лету" и сразу отправляется на устройство печати
Если принтер предоставлен для совместного доступа, этот параметр игнорируется
Hold Mismatched Documents (Останавливать несовпадающие документы)
Этот параметр заставляет спулер проверять соответствйе параметров документа и параметров принтера
Если принтер использует растровый драйвер, а в задании на печать используется формат Postscript, этот параметр заставит спулер приостановить печать. Задание не может быть перемещено в другую очередь, поэтому единственной альтернативой является отмена задания и повторная печать на другом принтере
Print Spooled Documents First
(Сначала печатать документы из спулера)
Спулер печатает задания в очереди до входящих заданий. Если два задания попадают в очередь одновременно, спулер отправляет на печать задание большего размера. Этот параметр используется совместно с параметром Start Printing Immediately
В обычных условиях спулер выбирает следующее задание на печать на основе назначенного приоритета. Это значит, что задание с большим приоритетом на 500 страниц, печать которого займет около часа, будет отправлено на печать раньше, чем задание в одну страницу, которое уже находится в очереди. При установке этого параметра первым на печать будет отправлено задание, установленное в очередь первым
Keep Printed Documents (Сохранять напечатанные документы)
Этот параметр заставляет спулер сохранять файл задания после печати документа
Иногда важно, чтобы задание было отпечатано с первого раза. Например, пакеты бухгалтерского учета печатают отчет в процессе сведения счетов в конце месяца и в конце года. В таких случаях очень сложно повторить процедуру и напечатать отчет еще раз. Если слишком долго оставлять этот параметр включенным, свободное дисковое пространство может быстро исчерпаться
Enable Advanced Features (Включить дополнительные возможности)
При отключении этого параметра дополнительные параметры становятся недоступными
Если использование дополнительных параметров из пользовательского интерфейса принтера приводит к проблемам совместимости, этот параметр можно сбросить для отключения некоторых дополнительных параметров. Для решения проблемы драйвер мини-порта должен явно опрашивать значения этого параметра
Страницы-разделители
Если несколько пользователей одновременно отправляют задания на печать на один сетевой принтер, могут возникнуть трудности с разделением заданий в выходном лотке принтера. Страницы-разделители определяют начало каждого задания на печать. Такие страницы хорошо заметны при просмотре стопки отпечатанных листов.
Существует четыре принятых по умолчанию типа страниц разделителей. Файлы страниц хранятся в каталоге \Windows\System32. Рассмотрим эти файлы.
Pscript. sep. Переводит принтер с двусторонней печатью в режим Postscript, но не приводит к печати страницы-разделителя.
Sysprint. sep. Печатает страницу-разделитель на принтере Postscript.
Sysprt j . sep. To же, что и Sysprint. sep, но с поддержкой дополнительных специальных шрифтов для модулей японского языка.
Pci. sep. Переводит принтер с двусторонней печатью в режим PCL, после чего печатает имя пользователя, дату и номер задания на печать.
Ниже приведен пример файла разделителя:
\H1B\L%-12345X@PJL ENTER LANGUAGE=PCL
\H1B\L&11T\O
\M\B\S\N\U
\U\LJob : \I
\U\LDate: \D
\U\LTime: \T
\E
В табл. 16.3 перечислены управляющие коды и их назначение. Если необходимо переключить принтер из режима Postscript в режим PCL без печати страницы-разделителя, воспользуйтесь следующим файлом страницы-разделителя:
\H1B\L%-12345X@PJL ENTER LANGUAGE=PCL\O
Таблица 16>3. Управляющие коды в файлах-разделителях и их функции
Управляющий код
Функция
\N
Выводит имя пользователя, отправившего задание
\1
Выводит номер задания
\D\T
Выводит дату и время
\Lxxxx
Параметр вывода. Задает печать символов (хххх) до появления следующего управляющего кода. Этот код можно использовать для заполнения строки символами, которые сделают страницу-разделитель легко узнаваемой
\Р<путь>
Печатает содержимое указанного файла начиная с пустой строки без дополнительной обработки. Этот параметр может использоваться для печати информационных сообщений
\Нпп
Управляющий код для конкретного принтера, где пп — это код ASCII. Чтобы узнать коды для своего принтера, обратитесь к руководству пользователя
\Wnn
Устанавливает ширину страницы разделителя. По умолчанию используется ширина 80 символов. Максимальная ширина составляет 256 символов. Любой печатаемый символ за пределами этой ширины удаляется
\B\S
Печатает текст в виде символов одинаковой ширины
Управляющий код
Функция
\Е
Выброс страницы. Этот параметр можно использовать для начала новой страницы- разделителя или для завершения файла страницы-разделителя. Если при печати выдается лишняя страница-разделитель, удалите этот код из файла страницы-разделителя
\п
Пропустить п строк (где п — значение от от 0 до 9)
\В\М
Печатает текст в виде символов двойной ширины
\и
Отключает печать символами одинаковой ширины
Печать из DOS
Приложения DOS, работающие в рамках виртуальной машины DOS (NT Virtual DOS Machine — NTVDM), ничего не знают о таких новшествах, как графический интерфейс GDI, модели драйверов WDM (Windows Driver Model) и библиотеки шрифтов. Приложение DOS пытается отправить поток байтов в порт LPT или поток битов в порт СОМ, и больше ничего.
Одной из функций драйвера NTVDM является преобразование вызовов аппаратных функций DOS в эквивалентные вызовы Win32 API. Это удается для приложений DOS, соответствующих определенным правилам. Но многие приложения таким правилам не соответствуют. Самой распространенной проблемой считается попытка приложения DOS отправить поток байтов непосредственно в порт принтера. Такие задания не будут напечатаны.
Некоторые приложения DOS закрывают файл печати, не отправляя байт <ЕОЕ>. В таком случае процессор печати будет считать, что приложение продолжает печататься. Существует несколько признаков, указывающих на наличие такой проблемы.
Задание на печать не запускается до завершения приложения.
Последняя страница задания остается в принтере, требуя принудительного извлечения страницы.
Задание от приложения DOS “смешивается” со страницами других заданий в выходном лотке. Эта ситуация возникает при использовании приложений, которые производят вычисления между отправкой страниц на печать, и вычисления продолжаются достаточно долго, чтобы превысить время ожидания принтера и позволить ему принять следующее задание.
При возникновении таких признаков попытайтесь установить принятый по умолчанию тип данных в FF Appended. Если печать выполняется на сервер NetWare, не пытайтесь использовать команду capture для решения проблемы. Команда capture не поддерживается в операционной системе Windows NT.
Если печать выполняется на нестандартный порт, например сетевое устройство печати или инфракрасный порт принтера, либо приложение DOS пытается выполнить печать на сервере печати через сеть, приложение DOS не сможет обнаружить порт LPT. Для указания приложению LPT-порта можно воспользоваться командой net use. Это относится даже к тому компьютеру, к которому подключено устройство печати.
Предположим, что сервер под управлением операционной системы Windows Server 2003 поддерживает работу принтера для сетевого устройства печати, например HP JetDirect. Для этого устройства не используется порт LPT1 или LPT2; вместо этого используется специальный порт, предназначенный для печати на сетевое устройство. Если на это устройство необходимо печатать из приложений DOS, работающих на этом сервере, принтер необходимо предоставить для совместного доступа и перенаправить порт принтера на совместно используемый принтер. Если предоставление принтера для совместного доступа нежелательно, печать
из приложений DOS окажется невозможной. Для перенаправления порта принтера можно воспользоваться следующей командой:
net use Iptl: \\имя_сервера\совместно_используемый_ресурс_принтера
Имя совместно используемого ресурса может быть длиннее восьми символов. Приложение DOS будет печатать на порт LPT1, как и на компьютере под управлением операционной системы DOS. Можно использовать номер порта LPT от 1 до 9, но большинство приложений DOS не распознает номера больше 3. При указании порта двоеточие вводить необязательно.
Печать в Windows Server 2003 R2
Для управления печатью в новой версии операционной системы Windows Server 2003 R2 появилась новая консоль Print Management (Управление печатью), позволяющая управлять всеми локальными или удаленными принтерами из единой консоли. Вы можете использовать данную оснастку на любом компьютере, работающем под управлением Windows Server 2003 R2, и управлять всеми сетевыми принтерами и серверами печати, работающими под управлением Windows 2000 Server, Windows Server 2003или Windows Server 2003 R2.
Консоль Print Management оперативно отображает такие детали, как статус очереди, название принтера, название драйвера и имя сервера. Вы также можете настроить вид консоли путем использования фильтров оснастки. Например, можно задать отображение только тех принтеров, которые сообщают об определенной ошибке. При возникновении неполадок можно настроить Print Management на отправку уведомления по электронной почте или на выполнение сценария. Фильтрация также позволяет выполнять групповую обработку заданий печати, например одновременную отмену всех заданий. Аналогично можно удалять одновременно несколько принтеров.
Администраторы могут устанавливать принтеры удаленно, используя функцию автоматического обнаружения. Она производит поиск принтеров в локальной подсети и устанавливает их на локальном сервере печати. Администратор может подключиться к серверу филиала, используя Remote Desktop (Удаленный рабочий стол) и без затруднений установить удаленные принтеры.
Если принтер оснащен Web-интерфесом, то на консоли Print Management могут отображаться такие сообщения о неисправностях, как место затора бумаги в принтере и количество тонера в картридже. Некоторые принтеры предоставляют через Web-интерфейс возможность удаленного контроля, что поможет решать проблемы в филиалах.
Устранение неисправностей при печати
При диагностике подсистемы печати начинайте с физического уровня. Включен ли принтер? Подключен ли принтер к компьютеру? Правильно ли соединены контакты последовательного кабеля? Любой администратор знаком с необходимой последовательностью действий. Существуют менее известные факторы, которые влияют на локальную печать.
■ Включение двунаправленной печати. Монитор печати для принтеров PCL и Postscript ожидает получения от принтера информации о состоянии, что требует двунаправленного подключения к принтеру. Более старые параллельные кабели без контактов для двунаправленной передачи данных заставят систему отказаться создавать принтер или приведут к “зависанию” задания на печать в очереди печати. Конфигурация порта принтера доступна в параметрах настройки BIOS. Часто для порта ЕСР/ЕРР установлена конфигурация, не поддерживающая двунаправленную передачу данных.
■ Задание не в той очереди. Если задание оказалось не в той очереди, в которую оно было направлено, перетаскивание задания из очереди в очередь не допускается. Необходимо
отменить задание в одной очереди и направить его на правильный принтер. Это связно с тем, что задание уже было преобразовано с использованием драйвера для первой очереди. Перемещение задания может привести к несовпадению форматирования задания с параметрами заданного принтера. Было бы неплохо, если бы администратор мог перемещать задания между очередями, связанными с одним устройством печати, но в операционной системе эта возможность также не поддерживается.
■ Страницы печатаются частично или печатаются странные символы. Если в отпечатанном задании видны управляющие символы, коды Postscript, отсутствуют графические символы из документа или задание по другим признакам не совпадает с изображением на экране, проблема, скорее всего, связана с неправильным принятым по умолчанию типом данных. Откройте окно свойств принтера, перейдите на вкладку Advanced (Дополнительно), щелкните на кнопке Print Processor (Процессор принтера) и выберите другой принятый по умолчанию тип данных. Если клиенты UNIX постоянно жалуются на повреждение заданий в очереди печати, создайте для них новый принтер, в котором принятый по умолчанию тип данных установлен равным значению TEXT.
Медленная или неравномерная печать. Если локальная печать задания выполняется очень медленно или неравномерно, может потребоваться установка дополнительного объема памяти, более быстрого процессора или и того, и другого. Если пользователь требует быстрой печати, но не желает оплачивать модернизацию аппаратных средств, попытайтесь установить отдельный сервер печати, который освободит рабочую станцию от нагрузки по преобразованию задания.
Неадекватное назначение прав доступа к каталогу спулера. Если настроенный для пользователя принтер работает нормально, а потом вдруг пользователь не может отправить задание на печать, проверьте права доступа NTFS для каталога \Windows\System32\Spool. Этому пользователю может быть запрещен доступ.
Ошибка подсистемы Plug-and-Play. Если драйвер устанавливался автоматически средствами подсистемы Plug-and-Play, проверьте наличие ошибок в окне Device Manager (Диспетчер устройств). Последовательный порт может использовать линию запроса прерывания (IRQ) совместно с другим устройством. Параллельный порт может не поддерживать двустороннюю передачу данных или использовать нестандартный адрес lOBase. Обычно при использовании параллельных портов проблемы с IRQ не возникают, но не стоит забывать о дополнительных устройствах и устройствах безопасности, которые не позволяют порту нормально взаимодействовать с принтером. Если на устаревшем компьютере установлен второй параллельный порт, убедитесь, что в BIOS включено использование IRQ5 для устаревших устройств и эта линия запроса прерывания назначена Device Manager (Диспетчер устройств).
Проверьте правильность выбора драйвера. В операционной системе Windows Server 2003 используются драйверы из операционной системы Windows 2000. Драйверам для режима пользователя отдается предпочтение по сравнению с драйверами для режима ядра. Для получения самой новой версии драйвера обратитесь на Web-сайт производителя.
Управление печатью из командной строки
Компания Microsoft предоставила в составе операционной системы Windows несколько утилит управления печатью на языке сценариев VBScript. Эти сценарии впервые появились в составе Windows 2000 Resource Kit. В этих утилитах для вывода информации и управления принтерами, заданиями на печать и компонентами принтеров (портами, очередями и конфигурациями) используется инструментарий управления Windows (WMI).
Большинство сценариев требует привилегий администратора или, как минимум, привилегий администратора печати на целевом сервере. Кроме этого, большинство утилит требует указания имени принтера в командной строке. Желательно, чтобы эти имена были как можно короче.
Существует шесть сценариев; сценарии соответствуют вкладкам в окне свойств принтера.
PrnPort. Этот сценарий позволяет находить, создавать, настраивать и удалять порты принтеров на указанном сервере. Эта функциональная возможность доступна на вкладке Ports (Порты) в окне свойств принтера. Ниже приведен пример результата выполнения этой утилиты:
C:\>prnport -1 -s sl.company.com Server name sl.company.com Port name IP_10.1.1.81 Host address 192.168.0.81 Protocol RAW Port number 9100 SNMP Disabled
Number of ports enumerated 1
PrnMngr. Этот сценарий позволяет создавать и удалять принтеры, а также может использоваться для выбора определенного принтера как принятого по умолчанию. Эта функциональная возможность предоставляется мастером добавления принтера в окне Printers and Faxes (Принтеры и факсы). Ниже приведен пример результата выполнения этой команды: C:\>prnmngr -1 -s sl.company.com Server name sl.company.com Printer name testprn Share name DeskJet648c Driver name HP DeskJet 640C/642C/648C Port name IP_10.1.1.81 Comment Standard letterhead paper Location Bldg C, Floor 3, Cubicle 33C Print processor WinPrint Data type RAW Parameters Attributes 8776 Priority 1
Default priority 0 Status OK Average pages per minute 0
PrnQctl. Этот сценарий может использоваться для просмотра, останова, запуска заданий в очереди печати и управления ими. Кроме этого, сценарий PrnQctl позволяет печатать тестовую страницу. Эта функциональная возможность предоставляется при двойном щелчке на пиктограмме принтера в окне Printers and Faxes (Принтеры и факсы), после которого открывается окно очереди печати.
PrnCnfg. Этот сценарий позволяет вывести информацию о конфигурации, которая обычно доступна на вкладке Advanced (Дополнительно) в окне свойств принтера. Ниже приведен пример отчета, выдаваемого в результате выполнения этого сценария: C:\>prncnfg -s sl.company.com -р testprn -g Server name sl.company.com Printer name HP DeskJet 640C/642C/648C Share name DeskJet648c Driver name HP DeskJet 640C/642C/648C Port name IP_10.1.1.51 Comment Standard letterhead paper Location Bldg C, Floor 3, Cubicle 33C Separator file Print processor WinPrint
Data type RAW Parameters Priority 1 Default priority 0 Printer always available Attributes local shared published do_complete_first .
Prnjobs. Этот сценарий позволяет вывести список заданий принтера, приостановить определенное задание, а также отменить его или возобновить. Эта функциональная возможность доступна при щелчке правой кнопкой мыши на задании в очереди. Ниже приведен пример отображения результата выполнения этого сценария: C:\>prnjobs —s si -р testprn -1 Job id 14 Printer testprn Document Test Page Data type NT EMF 1.008 Driver name HP DeskJet 640C/642C/648C Description newprn, 14 Elapsed time 00:00:00.
Machine name WSl.company.com Job status
Notify Administrator
Owner Administrator
Pages printed 0
Parameters
Size 75952'
Status UNKNOWN Status mask 0
Time submitted 12/16/2001 11:57:58
Total pages 1
Number of print jobs enumerated 1
PrnDrvr. Этот сценарий позволяет получить информацию о драйверах принтеров, загруженных на конкретном сервере. Это позволяет определить актуальность драйвера. Аналога этой утилиты с графическим пользовательским интерфейсом не существует. Ниже показан пример вывода этой утилиты: C:\>prndrvr —s si -1 Server name si Driver name HP DeskJet 640C/642C/648C,3,Windows NT x86 Version 3 Environment Windows NT x86 Monitor name
Driver path C:\WINDOWS\System32\spool\DRIVERS\W32X86\3\UNIDRV.DLL Data file C:\WINDOWS\System32\spool\DRIVERS\W32X86\3\HPFDJ680.GPD Config file C:\WINDOWS\System32\spool\DRIVERS\W32X86\3\UNIDRVUI.DLL Help file C:\WINDOWS\System32\spool\DRIVERS\W32X86\3\UNIDRV.HLP Dependent files
C:\WINDOWS\System32\spool\DRIVERS\W32X86\3\HPVDJ50.INI
C:\WINDOWS\System32\spool\DRIVERS\W32X86\3\HPVUD50.DLL'
C:\WINDOWS\System32\spool\DRIVERS\W32X86\3\HPVUI50.DLL C:\WINDOWS\System32\spool\DRIVERS\W32X86\3\HPFIMG50.DLL C:\WINDOWS\System32\spool\DRIVERS\W32X86\3\HPV600AL.DLL C:\WINDOWS\System32\spool\DRIVERS\W32X86\3\HPFDJ6xx.GPD C:\WINDOWS\System32\spool\DRIVERS\W32X86\3\HPFDJ69x.GPD C:\WINDOWS\System32\spool\DRIVERS\W32X86\3\HPFDJ200.HLP C:\WINDOWS\System32\spool\DRIVERS\W32X86\3\HPFNAM50.GPD C: \WINDOWS\System32 \spool \DRIVERS\W32X86\3 \UNIRES. DLL C:\WINDOWS\System32\spool\DRIVERS\W32X86\3\STDNAMES.GPD Number of printer drivers enumerated 1
В составе Resource Kit доступна еще одна утилита, которая называется PrintMig. Это стандартный выполняемый файл, который упрощает резервное копирование и восстановление конфигураций принтеров, хранящихся в системном реестре. Эту утилиту можно использовать для быстрого переноса конфигураций принтеров между серверами. Иногда это полезно при отказе основного сервера печати и восстановлении этих функциональных возможностей на другом сервере. Пример окна с установленными в системе элементами подсистемы печати показан на рис. 16.37.
Рис. 16.37. Утилита Printer Migration. В окне показаны элементы, которые могут быть скопированы на другой компьютер
Отслеживание расположения принтера
Каждый объект принтера в базе данных Active Directory имеет атрибут Location. При поиске принтера в базе данных Active Directory пользователь может ограничить круг поиска, указав информацию о расположении принтера.
Границы поиска определяются сайтами, поэтому при наличии только одного сайта эта возможность не действует. Для поиска с учетом расположения принтера можно воспользоваться утилитой Search (Поиск).
При выборе сайта из списка поиска система автоматически добавляет к имени сайта символ “/”. Для поиска с учетом расположения перед именем каждого атрибута расположения необходимо указать имя сайта, символ “/” и более конкретную информацию о расположении, например здание, этаж, комната и т.д.
Службы SharePoint
Для улучшения взаимодействия пользователей, географически удаленных друг от друга, в новой версии операционной системы Windows Server 2003 R2 добавлена технология под названием SharePoint Services. В Windows Server 2003 R2 включены Windows SharePoint Services c Service Pack 2. Теперь вы можете установить Windows SharePoint Services прямо из мастера Configure Your Server (Настройка вашего сервера) или Manage Your Server (Управление вашим сервером). В следующих разделах рассмотрены возможности, которые предоставляются при установке Windows SharePoint Services.
Сайты SharePoint: хранилище файлов и совместная работа
Web-сайты, созданные на основе Microsoft Windows SharePoint Services 2.0, обеспечивают среду, в которой команды пользователей могут общаться, обмениваться документами и совместно работать над проектами. Сайты SharePoint включают следующее.
Различные возможности совместной командной работы: календари, контакты, Интер- нет-ссылки, обсуждения, списки задач, объявления и многое другое.
Библиотеки документов. В библиотеках документов пользователи смогут хранить файлы и получать доступ к ним. Кроме того, предоставляется ряд дополнительных возможностей, например регистрация входящих и исходящих документов, ведение истории версий, использование произвольных метаданных и различных вариантов отображения.
Web Parts обеспечивают доступ к данным, Web-службам, множеству других приложений и содержимому сайтов SharePoint.
Пользователи такого Web-сайта могут участвовать в командной работе, не используя ничего, кроме Web-браузера. Тем не менее, если у пользователя установлены приложения, совместимые с Windows SharePoint Services, например пакет Microsoft Office 2003, он может прозрачно работать с сайтом, редактируя документы в клиентских программах и сохраняя их в библиотеках, перемещая информацию на сайт или создавая на нее ссылки.
Централизованное администрирование SharePoint: Web-интерфейс для управления вашим сервером
С помощью Web-интерфейса под названием SharePoint Central Administration (Централизованное управление SharePoint) вы можете управлять отдельным сервером или целой группой серверов (Web farm), на которой запущены Windows SharePoint Services. Используйте SharePoint Central Administration для расширения виртуального сервера, создавайте сайты или задействуйте режим Self-Service Site Creation (Самостоятельное создание сайтов), чтобы пользователи могли создавать собственные сайты. Предоставляется возможность управления настройками безопасности, списком серверов вашей Web farm и т.д. Также для управления серверами, на которых запущены Windows SharePoint Services, вы при желании можете воспользоваться утилитой Stsadm. ехе, запускающейся из командной строки.
Приложения для Windows SharePoint Services
Приложения для Windows SharePoint Services специально разработаны для определенных процессов или задач и позволяют увеличить производительность труда сотрудников. Предоставляется богатый выбор приложений, предназначенных для улучшения работы кадровых агентств, управления проектами, отслеживания обращений в службу технической поддержки, учета рабочего времени, планирования, создания расписаний и т.д. Вы можете пользоваться этими приложениями сразу же после установки или изменить их с целью удовлетворения специфических требований конкретной организации.
Расширенная поддержка схем использования внешних сетей
Функция преобразования зоны адресов URL (появившаяся в Service Pack 2 для Windows SharePoint Services) упрощает взаимодействие с ргоху-сервером или брандмауэром. Windows SharePoint Services используют абсолютные адреса URL для генерации гиперссылок и сообщений электронной почты. Раньше в ситуациях, когда перед сервером Windows SharePoint Services был установлен обратный ргоху-сервер, это препятствовало поддержке службами SharePoint отдельных расширенных конфигураций с использованием внешних сетей — таких, как прерывание канала SSL, изменение заголовков хостов и трансляция портов. Теперь
появилась возможность настраивать зоны адресов URL — такие, как Интернет, внутренняя и внешняя сеть, — и преобразовывать входящие и исходящие адреса URL для этих зон, чтобы перечисленные конфигурации работали без проблем.
В следующей главё
Глубоко вдохните. Если сравнить развертывание операционной системы Windows Server со сказкой “Волшебник страны Оз”, то именно сейчас мы находимся перед волшебником, думая, что осталось только попросить сердце, ум, дом, храбрость. Вместо этого придется столкнуться с самой сложной частью путешествия. В следующих двух главах рассматриваются шифрованная файловая система и инфраструктура открытого ключа.
После выхода из глубокого темного места настроим операционную среду пользователя, чтобы всем было удобно работать в сети, настроим службы удаленного доступа, чтобы всем было удобно работать дома, и создадим план восстановления после сбоев. Затем можно будет отправиться домой, будь то Канзас или квартира на другом конце города.
1717
17
17
Управление шифрованием файлов
С
реда. 13:30. Обед. Звонок по телефону. На другом конце телефонной линии слышен голос исполнительного директора компании. Он находится в Нью-Йорке и проводит презентацию для потенциальных инвесторов. Он только что вернулся с обеда и обнаружил, что кто-то похитил портативный компьютер из зала для совещаний, где он должен был находиться в “полной безопасности”.
Больше всего исполнительного директора интересует получение файлов, необходимых для проведения презентации. Администратора же больше интересует безопасность данных на жестком диске портативного компьютера. Если преступники смогут прочесть данные, хранящиеся на портативном компьютере, цена компьютера взлетит на новый уровень. Как только риск потери важной информации становится ощутимым, руководящий персонал компании начинает интересоваться шифрованием. (Конечно, администратор уже достаточно давно предлагал использовать шифрование...)
Во избежание таких ситуаций компания Microsoft разработала шифрованную файловую систему (Encrypted File System — EFS), которая впервые была предоставлена в составе операционной системы Windows 2000. В составе операционных систем Windows Server 2003 и Windows 2000 предоставляется улучшенная версия EFS, в которой исправлены некоторые недостатки и добавлены возможности, делающие шифрование более удобным для пользователей и администраторов. Если у вас есть список причин для модернизации портативных компьютеров до Windows ХР, добавьте EFS в первую пятерку.
В этой главе рассматриваются компоненты шифрования файлов и принципы их совместного функционирования. Кроме этого, приводится ряд советов, позволяющих защитить систему от компрометации и обеспечить доступность файлов для авторизованного персонала. В последнем разделе содержится набор пошаговых процедур для развертывания шифрования файлов и управления им.
Новые возможности операционной системы Windows Server 2003
Если при знакомстве с EFS в операционной системе Windows 2000 вы заметили отсутствие критически важных функций, то стоит еще раз обратить внимание на EFS после выхода операционных систем Windows Server 2003 и Windows ХР. Можно выделить следующие изменения. '
Новые и более криптографически стойкие методы шифрования. Теперь предоставляется возможность выбора между шифрованием DESX (использовалось в операционной системе Windows 2000) и 3-DES (Triple-DES) — алгоритмом, соответствующим правительственным стандартам по работе с документами.
Шифрование автономных файлов. Эта возможность является наиболее заметным улучшением в операционных системах Windows Server 2003 и Windows ХР. Пользователь может одновременно использовать автономные файлы и защищать свои файлы с помощью шифрования.
Передача шифрованных файлов по протоколу WebDAV. Перенаправитель WebDAV использует в качестве транспортного протокол HTTP, а не SMB. Шифрованные файлы передаются в зашифрованном виде и не требуют предварительной дешифровки, как в случае с протоколом SMB. Кроме этого, сервер может получать зашифрованные файлы по протоколу WebDAV без компрометации безопасности через делегирование Kerberos.
Более гибкое управление групповыми политиками. Теперь шифрованная файловая система может быть отключена в пределах всего домена с помощью одной групповой политики. В операционной системе Windows 2000 для управления шифрованием требовались удаление и повторный импорт сертификатов Х.509.
Совместный доступ к зашифрованным файлам. Владельцы зашифрованных файлов могут предоставлять доступ другим пользователям. Это расширяет применение EFS до пределов рабочей группы. Доступ может предоставляться только отдельным пользователям, но не группам. Разрешения другим пользователям могут выдавать только те пользователи, которые уже имеют доступ к файлу.
Предупреждения при копировании. Теперь Explorer (Проводник) предупреждает пользователей при копировании или перемещении шифрованных файлов на незащищенный носитель, например на диск Zip, гибкий диск или в раздел FAT. Новые параметры команд : сору и хсору разрешают при необходимости обходить эти меры защиты.;
Визуальные обозначения. Теперь оболочка Explorer (Проводник) отображает имена за- j шифрованных файлов и папок другим цветом. Это похоже на отображение сжатых фай- j лов в операционной системе Windows 2000.1
Улучшенное администрирование из командной строки. Утилита с интерфейсом команд- 1 ной строки cipher получила несколько дополнительных возможностей, включая воз- 1 можность генерации сертификатов восстановления файлов, поиска зашифрованных фай- 1 лов в томе, обновления сертификатов для всех зашифрованных файлов в томе и очистки | неиспользуемого дискового пространства для удаления временных файлов. (Возможность | очистки свободного дискового пространства появилась в Windows 2000 SP3.)|
Улучшения в системе безопасности. Хотя это и нельзя рассматривать как улучшение, в | EFS обработка главного ключа шифрования была изменена. Теперь главный ключ шиф- I рования не меняется при изменении локального пароля пользователя кем-то другим. Это | позволяет исправить серьезный недостаток изолированных портативных компьютеров и 1 рабочих станций. Теперь взломщик не может воспользоваться специальными утилитами 1 для изменения пароля пользователя (или пароля администратора) на изолированном | компьютере для получения доступа к зашифрованным файлам.1
Но не все изменения положительны. В операционной системе Windows 2000 файлы не могут быть зашифрованы без сертификата агёнта восстановления данных (Data Recovery Agent — DRA). Это позволяет избежать ситуации, когда пользователь зашифровал файлы и ушел из компании, не оставив возможности получить доступ к файлам. В операционных системах Windows Server 2003 и Windows ХР существует возможность шифрования файлов без агента восстановления данных. Эта “возможность” потенциально может привести к серьезным последствиям, так как пользователи могут зашифровать свои файлы и потерять секретный ключ, что навсегда блокирует доступ к файлам.
Функциональное описание шифрования файлов
Ничего не поделаешь. Шифрование файлов имеет сложную структуру. Шифрованная файловая система EFS использует технологии, которые только приближаются к периоду зрелости. Развертывание необходимо планировать очень внимательно, чтобы обеспечить безопасность и доступность файлов. Кроме этого, EFS требует некоторых умственных усилий и трудозатрат от пользователей, чего иногда Добиться не удается.
Шифрование файлов
При шифровании файлов используются элементы различных подсистем Windows. Чтобы перечислить всех участников процесса шифрования, рассмотрим последовательность событий при шифровании файла. На рис. 17.1 изображена блок-схема компонентов процесса шифрования.
При установке флага шифрования для файла драйвер шифрованной файловой системы вызывается поставщик шифрования Microsoft (Microsoft Crypto Provider) для получения ключа шифрования файла (File Encryption Key — FEK).
Поставщик шифрования Microsoft использует службу генератора случайных чисел (Random Number Generator) для создания ключа длиной 128 бит, который будет использоваться для создания ключа шифрования файла. (Поставщики шифрования используют 128-раз- рядные службы, кроме случаев работы с клиентами устаревших версий.)
Шифрованная файловая система использует полученный ключ для шифрования файла. Шифруются только данные файла. Также шифруются все именованные потоки данных. Остальные атрибуты, например метки времени, имена файлов и атрибуты, хранятся открытым текстом. Указатель на дескриптор безопасности, определяющий доступ к файлу, также остается неизменным, хотя файловая система налагает дополнительные ограничения на доступ к зашифрованным файлам.
Шифрованная файловая система передает зашифрованный файл файловой системе NTFS, которая сохраняет зашифрованный поток данных, как любой поток данных, который предоставляется приложением. Шифрованная файловая система не является альтернативой файловой системе NTFS. Она ее дополняет.
Шифрованная файловая система еще раз обращается к поставщику шифрования Microsoft. На этот раз файловой системе необходим открытый ключ пользователя. Этот ключ используется для шифрования копии ключа шифрования файла. Копия хранится вместе с файлом в поле дешифровки данных (Data Decryption Field — DDF).
Шифрованная файловая система шифрует еще одну копию ключа шифрования файла с помощью открытого ключа восстановления файлов (File Recovery — FR) учетной записи администратора домена. Результат шифрования сохраняется в поле восстановления данных
(Data Recovery Field — DRF), которое также хранится вместе с файлом. Учетная запись администратора называется агентом восстановления данных (Data Recovery Agent — DRA).
Поставщик шифрования MicrosoftПоставщик шифрования MicrosoftГенератор случайных чиселГенератор случайных чиселКлюч шифрования файлаКлюч шифрования файлаДрайвер EFSДрайвер EFSДрайвер файловой системы NTFSДрайвер файловой системы NTFSСистемный реестрСистемный реестрПоставщик шифрования MicrosoftПоставщик шифрования MicrosoftОткрытый ключ ОРАОткрытый ключ ОРАОткрытый ключ пользователяОткрытый ключ пользователя
Поставщик шифрования Microsoft
Поставщик шифрования Microsoft
Генератор случайных чисел
Генератор случайных чисел
Ключ шифрования файла
Ключ шифрования файла
Драйвер EFS
Драйвер EFS
Драйвер файловой системы NTFS
Драйвер файловой системы NTFS
Системный реестр
Системный реестр
Поставщик шифрования Microsoft
Поставщик шифрования Microsoft
Открытый ключ ОРА
Открытый ключ ОРА
Открытый ключ пользователя
Открытый ключ пользователя
Данные ^ DDF (ключ ^ DRF (ключИ
■ шифрования файла,■шифрования ■ И
И зашифрованный с И файла, эашифро- И И (*ON9o8ds98O Н помощью И ванный с помощью И И NSDOT9094oinИоткрытого ключа Иоткрытого ключаИИ
9d8y87t(*Y("Ипользователя) Д DRA)ИИ
Зашифрованный файлН
Рис. 17.1. Элементы шифрования данных
Шифрованная файловая система передает поля DDE и DRF файловой системе NTFS, которая сохраняет каждое значение в записи файла в специальном атрибуте, который называется $Logged_Utility_Stream.
В тоге получается файл NTFS с атрибутом $Data, заполненным абсолютно нечитаемыми символами. Для дешифровки содержимого файла необходим ключ шифрования файла (РЕК). Этот ключ есть только у пользователя, который зашифровал файл, и у агента восстановления данных (DRA). Как будет показано далее, в операционных системах Windows Server 2003 и Windows ХР есть возможность предоставления доступа к файлам другим пользователям.
Дешифровка файлов
Ниже приведена краткая последовательность действий при дешифровке зашифрованного файла (рис. 17.2).
Пользователь открывает зашифрованный файл.
Файловая система NTFS “видит”, что для файла установлен атрибут шифрования, и предоставляет поток данных драйверу EFS.
Система EFS координирует действия с поставщиком шифрования Microsoft для получения доступа к секретному ключу пользователя. Поставщик шифрования дешифрует секретный ключ пользователя с помощью ключа сеанса, полученного из главного ключа, который управляется программным интерфейсом защиты данных (Data Protection API — DP API).
Система EFS использует секретный ключ для дешифровки ключа шифрования файла, который хранится в поле дешифровки данных (DDF).
После этого система EFS использует ключ шифрования файла для дешифровки данных. Данные предоставляются запросившему приложению.
Рис. 17.2. Схема дешифровки данных
Выглядит сложно? Естественно. Внутри шифрованной файловой системы множество “движущихся частей”. Далее в этой главе рассматриваются взаимодействие компонентов и диагностика ситуаций, в которых они отказываются взаимодействовать.
Шифрование данных
При шифровании файла пользователем драйвер EFS работает совместно с драйвером NTFS в составе подсистемы Windows Executive для шифрования атрибута $Data. На рис. 17.3 показана схема записи MFT до и после шифрования.
Шифрованная файловая система преобразовывает атрибут $Data в последовательность блоков шифрования, которые хранятся в той же области диска, что и оригинальный файл. (Если атрибут $Data является резидентным, он выносится за пределы таблицы MFT и сохраняется надиске.)
Во время транзакции шифрования файла создается копия файла. Чтобы предотвратить копирование, для папки можно установить флаг шифрования с последующим сохранением файлов непосредственно в зашифрованной папке. В таком случае поток данных будет шифроваться еще до сохранения на диске и временные файлы создаваться не будут. Дополнительная информация приводится во врезке “Удаление временных файлов EFS”.
Алгоритмы шифрования данных
На протяжении многих лет единственным алгоритмом шифрования, разрешенным для экспорта за пределы США, был Data Encryption Standard, или DES. Этот алгоритм был разработан в компании IBM еще в 70-е годы XX века. Он просто не соответствует современным возможностям компьютеров. Недорогой компьютер может взломать стандартное шифрование DES за очень короткое время.
Для обхода этого недостатка в EFS используется один из двух обеспечивающих большую безопасность по сравнению с DES механизмов шифрования, разрешенных для экспорта за пределы США и сохраняющих скорость алгоритма DES: DESX и 3DES (Triple-DES).
952 Глава 17
Запись MFT до шифрования файла
Заголовок
$Standard_Information$Fiie_Name (Короткое имя - необязательно)$File Name (Длинное имя)$Data (резидентная)
"Is this a cheese shop?""Finest in the district, squire.""It certainly is uncontaminated bycheese."
Запись MFT после шифрования файла
Заголовок
$Standard_Information
$Fi le_Name (Короткое имя - необязательно)
$File_Name (Длинное имя)
$Logged_Utility_Stream
Содержит поле дешифровки данных
$Logged_Utility_StreamСодержит поле восстановления данных
$Data (нерезидентная)
$Data (нерезидентная)
OasdonasLKSFDO)(*&)EOJ%Ed88yqlnasdf-97823lkkd-09871233kjjdd)&#$(YOND *(&#IH%EUF_(*Y#l%HIDF(P*&#('YDopiy9weyO-we7rD*)F&IOoe25u8
Рис. 17.3. Запись MFT до и после шифрования
DESX
Этот алгоритм шифрования используется в операционной системе Windows 2000. Алгоритм DESX был описан Рональдом Риверстом (Ronald Riverst) из компании RSA Data Security в попытке усилить защиту алгоритма DES от атак перебором по словарю. Если коротко, то DESX является блочным шифратором, использующим три этапа шифрования файла.
Сначала каждый блок шифруется 64-разрядным шифратором с помощью простого алгоритма XOR.
После этого отдельный 56-разрядный шифратор используется для шифрования зашифрованных блоков с помощью стандартного шифрования DES.
Наконец еще один 64-разрядный шифратор используется для последнего шифрования по методу XOR.
Комбинация из трех этапов позволяет получить на выходе файл, более устойчивый к атаке поиска ключа, чем при использовании алгоритма DES. К сожалению, DESX не намного лучше DES, если дело касается защиты от сложного криптографического анализа.
Удаление временных файлов EFS
Если есть основания подозревать, что пользователь создал незашифрованные временные файлы при шифровании отдельных файлов, можно удалить все временные файлы из тома, а также очистить все неиспользуемые кластеры. Для этого можно воспользоваться командой cipher.
Команда имеет следующий синтаксис:
cipher /w:<каталог>
Например, команда cipher /w: \е\ позволяет очистить все свободные кластеры на диске Е. (Путь к каталогу указывать обязательно, так как к каталогу с помощью точки функционального монтирования может быть примонтирована другая файловая система.)
Команда cipher /w позволяет перезаписать содержимое свободных кластеров последовательностью нулей и единиц; после этого записываются случайные числа. На большом диске процесс может занять некоторое время. Пользователь не должен получать доступ к диску, пока не будут записаны все свободные кластеры. Это позволяет убедиться, что пользователь не создаст незащищенные временные файлы. ■
Хотя эта утилита выполняет неплохую работу по очистке диска, команда cipher /w не соответствует требованиям по очистке, описанным в документе DoD 5220.22-М (документ Министерства обороны США). Если требования этого документа должны быть удовлетворены, придется приобрести продукт от стороннего производителя.
3DES
Сообщество криптологов абсолютно прагматически отреагировало на неудачу протокола DES, воспользовавшись той же логикой, которая используется телевизионными продюсерами.
Телевидение. “В прошлом году публика потеряла интерес к сериалу, хотя он был громким и непристойным. В этом году мы сделаем сериал, который будет в три раза более непристойным и в три раза более громким. И интерес публики вернется."
Криптография. “Если однократное шифрование DES оказалось слишком простым для взлома, нужно применить шифрование DES три раза. Этого должно хватить.” (Дополнительная информация о более долговечном решении приводится во врезке “Усовершенствованный стандарт шифрования".)
Иначе говоря, алгоритм 3DES предполагает трехкратное шифрование данных. Каждый раз используется треть большого главного ключа шифрования. В результате получается блок,
который в миллиард раз более безопасен, чем при использовании протокола DES. Но производительность также снижается в три раза. Протокол DES не настолько медленный, как могло бы показаться, и протокол 3DES оказывается быстрее многих альтернатив.
Организация National Institute of Standards and Technology (NIST) принимает решения о политиках и правилах, которыми должны руководствоваться компании при ведении дел с правительственными организациями. Поскольку любая компания хочет вести дела с правительством, многие рекомендации NIST становятся стандартами де-факто.
Стандарты NIST публикуются в виде документов Federal Information Processing Standards (FIPS). Общие требования к безопасности компьютеров приводятся в публикации FIPS-140-2, Security Requirements for Cryptographic Modules. Этот стандарт используется Министерством финансов для определения технологий, которые будут свободно экспортироваться, и технологий, которые требуют специальных процедур экспортирования.
Хотя алгоритм 3DES достаточно устойчив, он поддается некоторым атакам криптоанализа. Для полного соответствия стандарту FIPS-140-2 компания Microsoft заменила алгоритм шифрования в шифрованной файловой системе операционных систем Windows Server 2003 и Windows ХР SP1 на Advanced Encryption Standard (AES). Это может привести к проблемам совместимости с компьютерами под управлением операционных систем Windows 2000 и Windows ХР, в которых используется алгоритм DESX. Перенос зашифрованного файла из операционной системы Windows Server 2003 в операционную систему Windows 2000 с последующим восстановлением данных не поддерживается.
Для обратной совместимости можно настроить групповую политику, которая заставит компьютеры под управлением операционных систем Windows Server 2003 и Windows ХР SP1 использовать алгоритм DESX, а не AES, пока миграция не будет завершена. Для управления шифрованием используется политика System cryptography: Use FIPS compliant algorithms for encryption (Системная криптография: использовать FIPS-совместимые алгоритмы для шифрования). Эта политика хранится в разделе Computer Configurations Windows SettingsSSecurity SettingssSecurity Options (Конфигурация компьютерам Параметры WindowsSnapaMeTpbi безопасности S Параметры безопасности).
Усовершенствованный стандарт шифрования ;
Несмотря на достаточно быструю работу алгоритма 3DES, его возможностей недостаточнф для использования в приложениях шифрования высокого уровня. В 2001 году организация NIST выбрала в качестве стандарта другой алгоритм, который называется Advanced Encryption Standard (AES). .
В стандарте AES используется алгоритм Cipher Block Square, который также называется алгоритмом Rijndael. Этот алгоритм был разработан учеными из Бельгии Джоан Дамен (Joan Оаетеп)'и Винсентом Рименом (Vincent Rijmen). Дополнительная информация об алгоритме Rijndael доступна по адресу www.ddj.com/articles/1997/9710/9710e/9710e.htm?topic=security. Список часто задаваемых вопросов по алгоритму AES доступен по адресу www.nist.gov/ public_affairs/releases/aesq&a.htm.
Защита ключа шифрования файла
Алгоритмы DESX, 3DES и AES являются симметричными. Это значит, что один и тот же ключ используется как для шифрования, так и для дешифровки. Чем длиннее ключ, тем лучше. В результате ослабления экспортных ограничений в 2000 году в поставщике шифрования Microsoft в качестве ключа шифрования используется 128-разрядное случайное число. Это число называется ключом шифрования файла. - -
Естественно, что система безопасности должна хранить ключ шифрования так, как обычно хранится ключ от дома. Никто не оставляет ключ от дома возле входной двери, чтобы лю-
бой мог открыть дверь и войти. К сожалению, ключ шифрования файла должен храниться вместе с файлом из соображений переносимости. Например, если выполнить восстановление шифрованных файлов из резервной копии, должна сохраняться возможность доступа к содержимому файла.
Значит, ключ шифрования файла (FEK) должен храниться вместе с файлом. Но ему необходимо обеспечить адекватную защиту, иначе вся система шифрования будет скомпрометирована. Необходим отдельный механизм шифрования для защиты ключа шифрования файла. Именно в этой ситуации становится ясна роль криптографии с помощью открытого ключа.
Криптография с помощью открытого ключа основана на использовании пары из открытого и секретного ключей. Все, что зашифровано с помощью одного ключа, может быть расшифровано вторым ключом. Только секретный ключ пользователя может использоваться для дешифровки ключа FEK, который необходим для дешифровки файла. Таким образом, секретный ключ пользователя является самым важным компонентом системы EFS.
Секретный ключ хранится в пользовательском профиле. Файл с ключом является скрытым системным файлом. Это не позволяет зашифровать файл средствами EFS.
Система EFS не использует криптографию открытого ключа для шифрования содержимого файла из-за значительного снижения производительности. Методы шифрования с помощью открытого ключа обеспечивают на удивление высокую безопасность, но работают очень медленно и требуют значительных ресурсов центрального процессора. Комбинация быстрого механизма шифрования файлов со средней степенью безопасности с очень безопасным механизмом шифрования на основе открытого ключа считается достаточно стандартным приемом в данной отрасли. Этот прием используется в механизме S/MIME (Secure Multipuprose Internet Mail Extensions) для защиты электронной почты. Механизм IPSec использует такое решение для защиты данных, передаваемых по сети.
Хранение ключа шифрования файла
Для хранения зашифрованного ключа FEK используется структура данных, которая называется полем дешифровки данных (Data Decryption Field — DDF). В DDF содержится копия сертификата открытого ключа пользователя для использования при идентификации. DDF хранится вместе с файлом в специальном атрибуте файловой системы NTFS, который называется $Logged_Utility_Stream.
Кроме этого, EFS предоставляет метод доступа к файлу на случай удаления секретного ключа пользователя. При шифровании файла EFS добавляет еще одну копию ключа шифрования файла, которая зашифрована открытым ключом восстановления файлов, предоставленным учетной записи Administrator (Администратор). Эта учетная запись называется агентом восстановления данных (Data Recovery Agent — DRA). Секретный ключ агента восстановления данных можно использовать для дешифровки копии FEK. Полученный ключ будет использоваться для доступа к файлу.
Система EFS хранит копию FEK в структуре данных, которая называется полем восстановления данных (Data Recovery Field — DRF). Это поле хранится вместе с сертификатом открытого ключа агента DRA. DRF хранится в собственном атрибуте $Logged_Utility_ Stream в записи файла.
Совместный доступ к зашифрованным файлам
В операционных системах Windows Server 2003 и Windows ХР поддерживается совместный доступ к зашифрованным файлам. Для этого еще одна копия ключа FEK шифруется с помощью открытого ключа каких-либо заданных пользователей. Таким образом, пользователи получают возможность дешифровки файлов. Кроме ключа, пользователям необходимы права доступа NTFS, которые позволят открыть файл.
Пользователь, который первым зашифровал файл, может воспользоваться окном Properties (Свойства) и указать других пользователей, которые могут получать доступ к содержимому файла. Щелкните на кнопке Advanced (Дополнительно) для просмотра вариантов шифрования. После этого щелкните на кнопке Details (Другие) для просмотра списка пользователей и агентов DRA, связанных с файлом (рис. 17.4).
При добавлении имени к списку авторизованных пользователей EFS получает сертификат открытого ключа из локального хранилища сертификатов (системный реестр) или из базы данных Active Directory.
Любой пользователь с правами на доступ к зашифрованному файлу может добавлять других пользователей в список авторизации. Объясните пользователям, что предоставлять совместный доступ следует только при абсолютной необходимости и только надежным коллегам.
Утилита efsinfo
В составе Resource Kit предоставляется утилита с интерфейсом командной строки, которая называется efsinfo и позволяет просмотреть имя пользователя, который зашифровал файл, список пользователей, добавленных в список авторизации, и список агентов DRA, назначенных файлу. Ниже показан пример использования утилиты efsinfo на изолированном сервере без локального агента DRA.
E:\>efsinfo /и /г /с test.txt
test.txt: Encrypted
Users who can decrypt:
CX612097-B\Admin (Admin(Admin@localbox))
ч>
ч>
Certificate thumbprint: 839E 9492 B38A C464
Unknown (Bill(Bill@localbox)) Certificate thumbprint: BeBO 795E C707 52F8
No recovery agent is found
CF52 5E8C
3F50
666В
С280
F36B
6ВВЗ
5EF5
1С60
6357
C$60
1164
BHDhxuser
Рис. 17.4. Подробная информация о файле с точки зрения EFS. Показаны пользователи, которым разрешен доступ к зашифрованному файлу, а также назначенный файлу агент восстановления данных
None
None
2/9/2102
2/7/2102
Эта информация может оказаться полезной, если у пользователей есть несколько серти-; фикатов EFS. Можно быстро определить, какой сертификат использовался для шифрования файла. Текущий сертификат пользователя можно определить с помощью команды efsinfo /у. Ниже представлен пример использования этой команды.
E:\>efsinfo /у
Your current EES certificate thumbnail information on the PC named localbox is:
^ 839E 9492 CF52 C280 6BB3 5EF5 1C60 B38A C464 5E8C
Защита секретного ключа
В старом сериале 1970-х годов “Get Smart?” в начале каждой серии Максвелл Смарт (которого играл Дон Адамс) шел через длинный коридор с большим количеством дверей к телефонной будке. В телефонной будке он набирал номер и проваливался в люк в полу. Этот эпизод можно использовать для описания защиты секретного ключа пользователя: ключ за ключом, один за другим. Рассмотрим, как это все работает.
' Секретный ключ хранится в профиле пользователя в каталоге \Application Data\ MicrosofС\СгурСо\К5А\<^1Д_пользователя>. Для защиты секретного ключа поставщик шифрования Microsoft использует ключ сеанса, сгенерированный программным интерфейсом Data Protection (DPAPI).
Интерфейс DPAPI генерирует ключ сеанса с помощью секрета, полученного на основе хешированного пароля пользователя. Подробная информация о генерации этого секрета доступна по адресу www.microsoft.com/serviceproviders/whitepapers/security.asp. Если коротко, то хешированный пароль хешируется еще раз, но на этот раз используется 160-разрядный алгоритм SHA-1. После этого результат пропускается через 4000 итераций алгоритма защиты пароля PBKDF2, который описывается в документе PKCS #5, “PasswordBased Cryptography Standard” (Стандарт криптографии на основе пароля). Дополнительная информация доступна по адресу www. rsalabs. com. В результате на основе хешированного пароля пользователя получается псевдослучайное число. В интерфейсе DPAPI это значение называется главным (Master) ключом.
Главный ключ сам шифруется с помощью специальной функции, которая называется HMAC (Hashed-based Message Authentication Code). Функция HMAC включает секретный ключ в стандартную функцию хеширования. Функция НМАС, используемая для шифрования главного ключа, является хешем главного ключа с хешем пароля пользователя в качестве секретного ключа. Зашифрованный главный ключ хранится в профиле пользователя в катат логе \Application Data\Microsoft\Protect\<STD_пoльзoвaтeля>. Несложно заметить, что надежность всей системы зависит от надежности пароля пользователя. Если злоумышленник знает пароль пользователя, он может получить доступ к зашифрованным файлам. Все просто. Для устранения этого уязвимого места можно использовать аутентификацию по смарт-картам. Дополнительная информация по использованию смарт-карт приводится в главе 20, “Управление удаленным доступом и маршрутизацией”.
При изменении пароля пользователя интерфейс DPAPI создает новый главный ключ, который используемся для генерации нового ключа сеанса. Новый ключ сеанса будет использован для повторного шифрования секретных ключей пользователя при следующей регистрации пользователя. Если администратор сменит пароль пользователя в базе данных Active Directory, интерфейс DPAPI создаст новый главный ключ при первой регистрации пользователя с помощью нового пароля. После этого на основе нового главного ключа будет сгенерирован новый ключ сеанса, с помощью которого будут повторно зашифрованы секретные ключи пользователя. .
Если компьютер входит в домен Windows Server 2003 или Windows 2000, копия главного ключа хранится на локальном компьютере. Эта резервная копия использует открытый ключ из базы данных Active Directory в качестве секретного ключа для алгоритма НМАС, который используется для шифрования главного ключа. Это дает возможность восстановить главный ключ в случае повреждения локальной копии.
Защита секретного ключа на изолированных компьютерах
В доменной среде хешированный пароль пользователя хранится в базе данных Active Directory. Копия хешированного пароля кэшируется локально в системном реестре в разделе Secrets узла Security (часто этот раздел называется LSA Secrets), но эта копия не может быть изменена, пока пользователь находится за пределами сети.
Это не относится к изолированным компьютерам, на которых хешированный пароль пользователя хранится в локальной базе данных SAM. Если злоумышленник получит физический доступ к изолированному компьютеру, он сможет воспользоваться несколькими утилитами для изменения пароля пользователя в базе данных SAM, включая пароль пользователя Administrator (Администратор). Поскольку локальная учетная запись Administrator (Администратор) является агентом восстановления данных для шифрованных файлов на локальном компьютере, регистрация от имени Administrator (Администратор) на локальном компьютере может привести к компрометации зашифрованных файлов пользователя.
По крайней мере, такая ситуация была в операционной системе Windows 2000. В операционных системах Windows Server 2003 и Windows ХР работа интерфейса DPAPI была мо- i дифицирована и это уязвимое место было устранено. Если на изолированном компьютере под - управлением операционных систем Windows Server 2003 и Windows ХР изменить пароль пользователя в обход интерфейса DPAPI, главный ключ пользователя повторно не будет зашифрован. Без доступа к главному ключу шифрованная файловая система не в состоянии ] получать доступ к зашифрованным файлам от имени пользователя. Это позволяет защитить 1 зашифрованные файлы от злоумышленников, получивших физический доступ к компьютеру.' i
В операционных системах Windows Server 2003 и Windows ХР появилась новая возмож- 1 ность, которая называется диск сброса пароля (Password Reset Disk — PRD). Если пользова,- I тель забыл свой пароль, диск сброса пароля позволяет сменить пароль в окне регистрации. I При изменении пароля с помощью диска сброса пароля интерфейс DPAPI не обновляет I главный ключ. Это значит, что пользователь потеряет доступ к зашифрованным файлам. 1 Особенно опасна такая ситуация при использовании операционной системы Windows ХР, в .3 которой не требуется создание агента восстановления данных (DRA).’ I
Но эту проблему можно решить. Если пользователь вспомнил свой старый пароль, он мо- 1 жет зарегистрироваться с помощью нового пароля и заменить его старым. Это заставит ин1- 1 терфейс DPAPI создать новый главный ключ на основе новых регистрационных данный 1 пользователя. Ключ сеанса, созданный на основе главного ключа, позволит дешифровать сек- 1 ретный ключ EFS. При этом пользователь восстановит доступ к зашифрованным файлам. Я
Такая модификация интерфейса DPAPI не защищает от злоумышленника, который, сменив ■ пароль учетной записи Administrator (Администратор), пытается найти подсказки к ориги- ■ нальному паролю пользователя. Например, злоумышленник может воспользоваться програм- Я мой взлома пароля, например LOphtcrack, для извлечения паролей пользователей на основе хе- ■ тированных паролей из базы данных SAM. Бывают ситуации, когда пользователь, защищая ■ файлы на портативном компьютере с помощью шифрования, не соблюдает элементарные пра- ■ вила безопасности и использует простой пароль (или даже пустой пароль) для регистрации, fl
По этой причине пользователи изолированных компьютеров, применяющие шифрование fl файлов, должны всегда использовать длинные, сложные пароли и никогда не должны сохра- fl нять подсказки к паролям, пароли коммутируемого доступа или пароли любого приложения, fl если эти пароли совпадают с паролем входа в систему. Это уязвимое место характерно только для изолированных компьютеров.Я
Хранение ключей EFSЯ
При первом шифровании файла система получает набор ключей шифрованной файловой Я системы, выдаваемых в форме сертификатов (certificates). Сертификаты PKCS обычно вы- Я даются по конкретной причине. В этом случае сертификат выдается для поддержки EFS. На- Я
пример, сертификат EFS не может быть использован для создания цифровых подписей сообщений электронной почты.
Если центр сертификации (Certification Authority — СА) недоступен, сертификат EFS выдается поставщиком шифрования на локальном компьютере. Это так называемые самоподпи- санные (self-signed) сертификаты. Такие сертификаты не формируют цепочку ответственности, которая ведет к центру сертификации. С точки зрения безопасности самоподписанные сертификаты имеют смысл только на локальном компьютере, поскольку другие компьютеры не смогут проверить действительность источника сертификата.
Если центр сертификации установлен, групповая политика сообщит локальным клиентам о существовании центра сертификации, распространяя сертификат открытого ключа центра сертификации. Клиенты используют открытый ключ для шифрования запросов на получение сертификатов, которые отправляются центру сертификации. После получения запроса на получение сертификата центр сертификации дешифрует запрос с помощью своего секретного ключа, проверяет источник запроса и выдает сертификат. Сертификат подписывается секретным ключом центра сертификации, что позволяет клиенту проверить сертификат с помощью открытого ключа центра сертификации. "
После получения сертификата ключи EFS хранятся в локальном профиле пользователя в скрытой папке Application Data (рис. 17.5).
Открытый ключ пользователя для EFS хранится в каталоге System Certificates\My\ Certificates.
Секретный ключ пользователя для EFS хранится в каталоге Crypto\RSA\<SJD_ пользователях
Главный ключ и резервный главный ключ хранятся в каталоге Protect\<SID_ пользователях ■
Очень важно, чтобы после применения системы шифрования файлов при обслуживании рабочих станций профилям пользователей уделялось особое внимание. Если удалить пользовательский профиль, пользователь лишится доступа ко всем зашифрованным файлам на компьютере.
Как будет показано далее, при изучении процесса восстановления данных доменная учетная запись Administrator (Администратор) является принятым по умолчанию агентом восстановления данных (DRA) для всех серверов и рабочих станций в домене. Профиль для этой учетной записи создается на первом контроллере домена. В профиле хранятся секретный и открытый ключи восстановления файлов (File Recovery — FR), которые используются агентом DRA. Если удалить профиль учетной записи Administrator (Администратор) на первом контроллере домена, восстановление зашифрованных файлов окажется невозможным в пределах всего домена.
Секретный ключ восстановления файлов учетной записи Administrator (Администратор) можно и нужно экспортировать в виде сертификата. Этот сертификат может храниться в безопасном месте и должен использоваться только при необходимости. Кроме этого, могут быть назначены другие агенты DRA в дополнение к доменной учетной записи Administrator (Администратор).
Ключи EFS и перемещаемые профили х
Папка Application Data перемещается вместе с пользователем перемещаемого профиля. Это хорошая новость, так как один и тот же секретный ключ будет использоваться для шифрования файлов на разных компьютерах. Это значительно упрощает сбор файлов одного пользователя, если возникнет такая необходимость.
Плохая новость заключается в том, что шифрование файлов в перемещаемом профиле не поддерживается, поскольку в механизме обработки файлов заложена “уловка-22”. Предположим, что в папке Му Documents (Мои документы) в перемещаемом профиле удалось зашифровать файл. По завершении сеанса зашифрованный файл будет скопирован на сервер.
Профиль пользователя
Открытый ключ ОткрытыйОткрытый ключ Открытыйвосстановления ключ EFSвосстановления ключ EFSфайловфайловРис. 17.5. Хранение ключей в пользовательском профилеРис. 17.5. Хранение ключей в пользовательском профиле
Открытый ключ Открытый
Открытый ключ Открытый
восстановления ключ EFS
восстановления ключ EFS
файлов
файлов
Рис. 17.5. Хранение ключей в пользовательском профиле
Рис. 17.5. Хранение ключей в пользовательском профиле
После следующей регистрации система загрузит содержимое перемещаемого профиля и на его основе инициализирует локальную операционную среду. Но в перемещаемом профиле хранится зашифрованный файл, который не может быть открыт без секретного ключа. Однако секретный ключ находится в профиле, который не может быть инициализирован системой до копирования всего содержимого профиля.
Для того чтобы избежать такой ситуации, компания Microsoft не разрешает пользователям шифровать файлы в перемещаемом профиле. Если пользователь зашифровал файл в профиле, то при завершении сеанса система выдает сообщение об ошибке, в котором говорится о невозможности копирования зашифрованного файла на сервер.
Если пользователям перемещаемых профилей совершенно необходимо шифровать файлы в папке Му Documents (Мои документы), можно применить следующий метод. Настройте перенаправление папок и разместите папку Му Documents (Мои документы) на сервере, разрешите использование автономных папок и зашифруйте содержимое кэша автономных папок.
Управление сертификатами
Сертификат представляет собой структуру данных, в которой содержатся ключ, открытый или секретный, а также информация о ключе и данные об источнике выдачи ключа. Если провести аналогию с дорогим бриллиантом, к которому прилагаются свидетельство ювелира и сертификат о происхождении с рельефными подписями, то принципы использования сертификатов будут ясны.
Организация International Telecommunications Union (ITU) выпустила стандарт Х.509, который определяет структуру сертификатов PKCS. Пример сертификата Х.509 показан на рис. 17.6.
Рис. 17.6. Содержимое сертификата открытого ключа Х.509
Существуют и другие типы сертификатов, которые широко применяются на рынке, но не вошли в стандарт ITU. Компания RSA поддерживает список типов сертификатов и документации по их содержимому и структуре. Web-сайт RSA доступен по адресу www. rsasecur i ty. com.
Оснастка Certificates (Сертификаты)
Сертификаты хранятся в разных местах в зависимости от предполагаемого использования и наличия секретных и открытых ключей. Операционная система Windows предоставляет единое “логическое” хранилище сертификатов, которое обеспечивает дополнительный уровень абстракции над физическим расположением сертификатов. Для просмотра содержимого логического хранилища можно воспользоваться оснасткой Certificates (Сертификаты). На рис. 17.7 показан внешний вид оснастки Certificates (Сертификаты). В этой оснастке можно просматривать сведения о собственных сертификатах. При наличии прав администратора также можно просматривать сертификаты, выданные компьютерам или службам, работающим на этом компьютере. Просмотр хранилища сертификатов другого пользователя не поддерживается.
Qphxuserl
2/9/2102
Encrypting fife System
й-аинг^
If on<ule RoutXCerhfudlrs Curt ent Us«?r\PersorMl\Cert»fkdtes]
S 21 Personal
®®£j Trusted Root Certification Authorities
®
®
ffl 21 Enterprise Trust
® l~^ Intermediate Certification Authorities
® 21 Active Directory User Object
Й 2) Trusted Publishers
21 Untrusted Certificates
S CJ Thrd-Party Root Certification Authorities
S 21 Trusted People
® О Other People
£К5К*5*й»?а9^£К5К*5*й»?а9^
£К5К*5*й»?а9^
£К5К*5*й»?а9^
Puc. 17.7. Окно оснастки Certificates (Сертификаты)
He существует консоли, на которой оснастка Certificates (Сертификаты) предоставляется по умолчанию. Для доступа к оснастке Certificates (Сертификаты) придется создать собственную консоль ММС. Последовательность действий по созданию такой консоли приводится в процедуре 17.1.
Процедура 17.1. Просмотр персональных сертификатов
с помощью оснастки Certificates (Сертификаты)
Откройте пустую консоль ММС. Для этого воспользуйтесь командой Starts Run (Пуск^ Выполнить) и введите команду пшю.
В меню консоли выберите Console^Add/Remove Snap-in (Консоль1^Добавить/Удалить оснастку). Откроется окно Add/Remove Snap-in (Добавить/Удалить оснастку).
Щелкните на кнопке Add (Добавить). Откроется окно Add Standalone Snap-in (Добавить изолированную оснастку).
Для загрузки оснастки выполните двойной щелчок на пуйкте Certificates (Сертификаты). Если используемой учетной записи не предоставлены привилегии администратора, можно загрузить только персональные сертификаты. В противном случае предоставляется возможность загрузки сертификатов компьютеров и служб.
После загрузки оснастки сохраните консоль под понятным именем, например Cert .msc. Консоль можно сохранить в каталоге \wiNNT\System32 вместе с остальными файлами консолей, чтобы оснасткой могли пользоваться и другие администраторы. Консоль не указывает на сертификаты конкретного пользователя. В оснастку загружаются сертификаты того пользователя, который запустил консоль.
Разверните дерево до раздела Certificates — Current User^Personal^Certificates (Сертификаты — Текущий пользователь■$ Персональные1^ Сертификаты). Сведения о выданных пользователю сертификатах отображаются в правой панели. В столбце Intended Puproses (Предполагаемое использование) перечислены функции сертификата. Если хоть один раз выполнялось шифрование файла, в списке будет присутствовать как минимум один сертификат EFS. Доменная учетная запись Administrator (Администратор) будет иметь как минимум два сертификата. Один сертификат будет предназначен для EFS, а вторым будет сертификат восстановления файлов (File-Recovery — FR).
Выполните двойной щелчок на сертификате для просмотра его содержимого.
Оснастка Certificates (Сертификаты) позволяет получать новые сертификаты. Для сертификатов EFS это обычно не требуется, так как служба EFS автоматически получает сертификаты при шифровании файлов. Если необходимо назначить дополнительные агенты восстановления данных (DRA), для них придется получать сертификаты восстановления файлов. Для запроса этих сертификатовтакже можно воспользоваться оснасткой Certificates (Сертификаты).
Система EFS выдает только самоподписанные сертификаты восстановления файлов. В домене такой сертификат выдается для доменной учетной записи Administrator (Администратор). Для локального компьютера этот сертификат выдается первому пользователю, который регистрируется на компьютере после завершения установки. Для получения дополнительных сертификатов необходимо обратиться в центр сертификации.
Управление сертификатами
Ключи в профиле пользователя хранятся в формате, не поддерживающем транспортировку. Если необходимо перенести ключи пользователя на другой компьютер, самым простым способом сделать это является настройка перемещаемого профиля пользователя с последующей регистрацией на интересующей рабочей станции. После этого копия профиля пользователя будет помещена на новый компьютер. Внутри копии будут храниться ключи EFS.
Открытые ключи восстановления файлов распространяются в сертификатах Х.509 с помощью групповых политик. Безопасность этих сертификатов не рассматривается как отдельная задача. Но до завершения подготовки к развертыванию EFS стоит удалить сертификат из групповых политик, чтобы отключить шифрование файлов на клиентах под управлением Windows 2000.
Секретные ключи восстановления файлов требуют совсем другого подхода. Совершенно ясно, что копии секретных ключей восстановления файлов не должны передаваться по сети. Одним из первых действий при развертывании EFS должно быть копирование секретного ключа восстановления файлов в сертификат и удаление этого секретного ключа со всех компьютеров.
Оснастка Certificates (Сертификаты) позволяет сохранять ключи внутри сертификатов. Для этих целей операционная система Windows поддерживает несколько форматов сертификатов.
Сертификаты Х.509 (. сег) с использованием Distinguished Encoding Rules (DER)
Сертификаты Х.509 (.сег) с использованием кодирования Base-64
PKCS #7 Cryptographic Message Syntax Standard (.P7B)
PKCS #12 Personal Information Exchange (PFX)
Из четырех типов сертификатов первые три используются для распространения открытых ключей. Только последний тип, сертификат PFX, поддерживает хранение секретного ключа. Формат PFX использует устойчивое к взлому кодирование для хранения ключа без его компрометации. Дополнительная информация о формате PKCS #12 доступна в технической документации, которую можно загрузить по адресу ftp.rsasecurity.com/pub/ pkcs/pkcs-12.
Восстановление зашифрованных файлов
Как было показано в предыдущем разделе, при открытии пользователем зашифрованного файла происходит длинная последовательность событий. EFS должна получить доступ к секретному ключу пользователя, для чего необходимо содействие интерфейса DPAPI, который использует ключ сеанса, созданный на основе главного ключа, который, в свою очередь, защищен ключом, содержащим хешированный пароль пользователя.
Если пользователь покидает компанию, уходит в отпуск, умирает или просто отказывается открывать файл, пароль пользователя можно сбросить в базе данных Active Directory и зарегистрироваться от имени пользователя. Интерфейс DPAPI создаст новый главный ключ на основе хешированного пароля пользователя и с помощью ключа сеанса, полученного на основе главного ключа, выполнит повторное шифрование секретных ключей.
Если модификация учетной записи пользователя нежелательна, можно открыть зашифрованные пользовательские файлы с помощью регистрационных данных агента восстановления данных (DRA). В этом разделе рассматриваются распространение открытого ключа DRA в пределах домена, использование этих сертификатов на клиентах в составе домена, а также использование учетной записи DRA Для чтения зашифрованного файла без участия оригинального владельца.
Групповые политики восстановления зашифрованных файлов
Зашифрованный файл на компьютере в составе домена содержит копию ключа шифрования файла, который зашифрован ключом восстановления файлов, выданным DRA. По умолчанию в качестве агента DRA выступает доменная учетная запись Administrator (Администратор). Можно и нужно настроить другие учетные записи для возможности восстановления данных.
Клиенты EFS получают копию открытого ключа восстановления файлов, выданного DRA, в виде сертификата Х.509, который хранится в групповой политике Encrypting File System. Политика расположена в разделе Computer Configuration^Windows Settings^Security Settings^ Public Key Policies (Конфигурация компьютерам Конфигурация Windows1^ Параметры безопасности^ Политики открытого ключа), как показано на рис. 17.8.
SlAdmlnlstrator Administrator 2/27/2004SlAdmlnlstrator Administrator 2/27/2004Rie RecoveryRie RecoverySecurity Setthgs S 8W Account Poktes ® Я Local Pokies Ф Я Event Log Й Restricted Groups Sl-^ System Services S-Q8 Registry В 08 He System B- Й M* Key PoldesSecurity Setthgs S 8W Account Poktes ® Я Local Pokies Ф Я Event Log Й Restricted Groups Sl-^ System Services S-Q8 Registry В 08 He System B- Й M* Key Poldes
SlAdmlnlstrator Administrator 2/27/2004
SlAdmlnlstrator Administrator 2/27/2004
Rie Recovery
Rie Recovery
Security Setthgs S 8W Account Poktes ® Я Local Pokies Ф Я Event Log Й Restricted Groups Sl-^ System Services S-Q8 Registry В 08 He System B- Й M* Key Poldes
Security Setthgs S 8W Account Poktes ® Я Local Pokies Ф Я Event Log Й Restricted Groups Sl-^ System Services S-Q8 Registry В 08 He System B- Й M* Key Poldes
Lalx-Lalx-d Automatic Certificate Request Setthgs ^ Domair Root Certification Authorities Г"! Г Tn «М
Lalx-
Lalx-
Puc. 17.8. Объект групповой политики Default Domain отображает сертификат учетной записи Administrator (Администратор) в разделе Public Key^Encrypting File System
При загрузке компьютера, входящего в домен, компьютер загружает сертификат агента DRA вместе с групповыми политиками, которые предоставляются регистрационным сервером. Клиент кэширует сертификаты в локальном системном реестре. Благодаря локальному кэшу пользователи портативных компьютеров могут использовать сертификат агента DRA для шифрования файлов даже при отсутствии сетевого соединения. Это обеспечивает возможность восстановления файлов в случае проблем в работе учетной записи.
Изолированные клиенты под управлением Windows Server 2003 и Windows ХР используют в качестве агента DRA локальную учетную запись или вообще не используют DRA. По этой причине очень важно, чтобы каждый настольный или портативный компьютер был включен в домен Active Directory под управлением Windows Server 2003 или Windows 2000. Если попытаться настроить управление шифрованием файлов на большом количестве изолированных серверов и рабочих станций, задача администратора значительно усложнится.
Поскольку групповая политика EFS, в которой содержится сертификат восстановления файлов для DRA, расположена в разделе Computer Configuration (Конфигурация компьютера) объекта групповой политики, клиенты продолжают использовать сертификат при шифровании файлов, даже если пользователь регистрируется с помощью локальной базы данных SAM, а не в домене. Это связано с тем, что компьютер продолжает находиться в составе домена и регистрируется с использованием кэшированных регистрационных данных, в состав которых входят кэшированные групповые политики.
Если портативный компьютер будет похищен, злоумышленник сможет взломать учетные записи в базе данных SAM, но не получит доступа к зашифрованным файлам. Кэшируется только открытый ключ агента DRA. Секретный ключ не кэшируется, а предоставление открытого ключа не представляет угрозы безопасности. Помните, что пользователь не использует локальную учетную запись, которая может быть взломана, а хешированный доменный пароль пользователя кэшируется в разделе LSA Secrets, где его нельзя изменить.
Кэшированные регистрационные данные пользователя шифруются и хранятся в разделе Security системного реестра. На момент написания книги ни на одной из платформ семейства Windows NT не был взломан локальный кэш регистрационных записей. Это не относится к другим разделам системного реестра, например к разделу LSA Secrets, который успешно взламывался в течение последних нескольких лет.
Отключение параметров групповой политики EFS
Новая возможность операционной системы Windows Server 2003 позволяет отключить EFS в пределах домена или организационной единицы одним щелчком мышью. На рис. 17.9 показано окно Properties (Свойства) для политики EFS, которая управляет шифрованием в пределах всего домена.
Сбросив флажок Allow Users То Ecnrypt Files Using Encrypting File System (Разрешить пользователям шифровать файлы), администратор распространяет обновление системного реестра, которое отключает шифрованную файловую систему. Этот флажок меняет следующую запись системного реестра:
I
Раздел:HKLM\Software\Policies\Windows NT\CurrentVersion\EFS '
Запись: EFSConfiguration
Значение: 1 — для отключения, о или удаление — для включения (reg_dword)
Клиенты Windows Server 2003 и Windows ХР пытаются обнаружить эту запись в своих групповых политиках. Если запись отсутствует, клиент шифрует файлы, даже если в групповых политиках отсутствует сертификат восстановления файлов.
Это поведение диаметрально противоположно поведению клиентов Windows 2000. Такое поведение может застать администратора врасплох. Инженеры компании Microsoft должны были настроить клиенты на включение шифрованной файловой системы в случае обнаружения значения 1 записи EFSConfiguration. На данный момент результатом такой логики является шифрование файлов клиентами Windows ХР, даже если из групповой политики восстановления файлов удалены все сертификаты восстановления файлов.
Лучшим выходом из этой ситуации является создание собственной групповой политики в домене Windows 2000, которая будет распространять запись EFSConf iguration среди клиентов Windows Server 2003 и Windows ХР. Клиенты Windows 2000 игнорируют эту запись в системном реестре.
мМ|М
Рис. 17.9. Окно свойств политики Encrypting File System Policies (Политики шифрованной файловой системы), в котором существует возможность отключить шифрование файлов в пределах домена
Открытие файлов от имени DRA
Термин восстановление зашифрованных файлов (encrypted file recovery) может ввести в заблуждение. На самом деле зашифрованный файл не “восстанавливается”. Если зарегистрироваться с помощью учетной записи Administrator (Администратор) или любой другой учетной записи, которой предоставлены права агента DRA, и секретный ключ будет доступен в пользовательском профиле на данном компьютере, то к зашифрованным файлам будет предоставлен доступ. Открытие таких зашифрованных файлов называется в данном случае восстановлением (recovery).
Главной особенностью процесса восстановления является секретный ключ восстановления файлов, принадлежащий агенту DRA. По умолчанию этот ключ хранится в профиле Administrator (Администратор) на первом контроллере домена. Если зарегистрироваться на клиентской рабочей станции с помощью доменной учетной записи Administrator, в доступе к зашифрованным файлам будет отказано, так как на локальном компьютере отсутствует копия секретного ключа администратора.
Для учетной записи Administrator (Администратор) можно включить перемещаемый профиль, но в таком случае копии секретного ключа появятся на всех компьютерах. С тем же успехом можно сделать сто копий ключа от входной двери собственного дома и раздать их незнакомцам. Если необходимо открыть зашифрованный файл пользователя, не меняя пароль пользователя и не перехватывая контроль над учетной записью пользователя, то возможны два варианта решения проблемы.
Секретный ключ агента восстановления данных (DRA) можно скопировать на рабочую станцию пользователя с помощью перемещаемого профиля или с помощью экспорта и последующего импорта ключа в хранилище сертификатов на рабочей станции. После завершения восстановления можно удалить ключ и очистить неиспользованное дисковое пространство.
Более подходящим решением является перемещение зашифрованных файлов на компьютер, где хранится секретный ключ агента DRA. Скопировать файлы по сети не удастся, но их можно скопировать в виде резервной копии средствами утилиты Ntbackup.
Для обеспечения надежности инфраструктуры шифрования секретный клдэч восстановления файлов агента DRA необходимо защитить. Копии секретного ключа восстановления данных не должны храниться на компьютерах. Вместо этого ключ необходимо переместить на сменный носитель, который хранится в надежном месте. После этого ключ должен импортироваться только в случае необходимости при восстановлении файлов.
Шифрование файлов на сервере
Шифрование и дешифровка файлов требуют присутствия ключей EFS на локальном компьютере, на котором находится файл. Это делает шифрование файлов на сервере немного сложнее, чем может показаться с самого начала.
ч -Как было показано несколько раз, при шифровании пользовательского файла на локальном настольном или портативном компьютере EFS совместно с поставщиком шифрования Microsoft создает ключи EFS, которые хранятся в локальном профиле пользователя. Если пользователь пытается зашифровать файл по сети, EFS на сервере пытается найти локальный профиль пользователя на сервере. Система EFS не может получить доступ к ключам на рабочей станции пользователя, так как контексты безопасности предоставляются ей только на сервере EFS.
Это значит, что сервер должен иметь локальный профиль для пользователя, в котором хранятся открытый ключ EFS для шифрования файла и секретный ключ EFS для дешифровки зашифрованного файла. Для создания локального секретного ключа служба Protected Storage (Защищенное хранилище) на сервере должна получить копию хешированного пароля пользователя, которая будет использоваться для шифрования главного ключа, защищающего секретный ключ пользователя. Служба получает необходимую информацию благодаря “подмене" пользователя (как бы работая от его имени).
Обращение от имени пользователя и Kerberos
Чтобы сервер мог действовать от имени пользователя для работы EFS, необходимо получить от имени пользователя билет сеанса доступа Kerberos, который будет предоставлен контроллеру домена при запросе регистрационных данных пользователя. Сервер может получить билет сеанса доступа двумя способами.
Отправить запрос клиенту Kerberos на рабочей станции пользователя (такой запрос выполняется незаметно для пользователя) и получить билет сеанса доступа, который будет предоставлен серверу. Такой билет будет отмечен как перенаправляемый (forwardable). Это означает, что клиент Kerberos получает билет для передачи другому компьютеру.
Запросить у клиента Kerberos билет TGT, с помощью которого будет получен собственный билет сеанса доступа. В таком случае сервер будет вести себя, как пользователь. В билете TGT будет установлен флаг Proxiable (флаг Proxiable указывает, что новый билет, гарантирующий сервис, с другим сетевым адресом может быть получен на основе существующего билета).
Разница между перенаправляемым билетом сеанса доступа Forwardable и билетом TGT Proxiable примерно сопоставима с разницей между одалживанием другу двадцати долларов на завтрак и предоставлением другу своей чековой книжки с правом подписи. Сервер, который получил любой из билетов, может делать с ними все что угодно.
Для предотвращения бесконтрольного предоставления билетов Kerberos Proxiable и Forwardable контроллер домена Windows откажется принимать билеты сеанса доступа или билеты TGT, если предъявляющий их сервер не является доверенным для делегирования (Trusted for Delegation).
Доверенность для делегирования
Перед тем как сервер сможет шифровать файлы для сетевых пользователей, он должен стать доверенным для делегирования. Этот параметр настраивается в свойствах объекта Computer сервера в базе данных Active Directory (рис. 17.10).
В операционной системе Windows Server 2003 поддерживается несколько вариантов делегирования. В качестве самого распространенного случая, позволяющего обеспечить правильную работу EFS, выберите переключатель Trust This Computer For Delegation To Any Service (Kerberos Only) (Доверять этому компьютеру делегирование для любой службы (только Kerberos)). Остальные варианты позволяют включить делегирование для специфичных типов транзакций.
После настройки доверенного для делегирования сервера сервер занимает очень привилегированное положение в сети. Необходимо обеспечить физическую безопасность сервера и защитить его от установки троянских программ.
Кэширование ключей пользователя на доверенном сервере EFS
После настройки доверенного для делегирования сервера Windows Server 2003 и шифрования пользовательских файлов сервер обеспечит ускорение работы EFS благодаря кэшированию секретных ключей в памяти. По умолчанию сервер кэширует до 15 ключей. Это количество можно увеличить до 30. Для этого необходимо изменить соответствующую запись в системном реестре:
Раздел: HKLM\Software\Microsoft\Windows NT\CurrentVersion\EFS
Запись: UserCacheSize
Значение: от 5 до 30 (reg_dword)
Sanni | OewewM* I Mert*»«**« I l*<* "I Minwed» | D*Mntitf6ilii^*««i^etiijltoiili#6ft«hltii*8rierec*telMonSBKrieilWN* - ■ •
- <r *•'.*•,* * *
, ’, ЗКхЗГПйЭ^^
Puc. 17.10. Страница свойств сервера, на которой показаны разные варианты доверенности для делегирования
Файловые транзакции EFS и протокол WebDAV
Традиционно для обмена файлами по сети в операционных системах Windows иЯюльзу- ется командный язык SMB. В операционных системах Windows Server 2003 и Windows ХР предоставляется новый способ динамической работы с файлами на удаленных компьютерах. Это протокол Web-based Distributed Authoring and Versioning (WebDAV). Дополнительную информацию о WebDAV можно найти в спецификации RFC 2518, “HTTP Extensions for Distributed Authoring — WEBDAV”, и на сайте рабочей группы WebDAV по адресу www. ietf.org/html.charters/webdav-charter.html.
В главе 16, “Управление совместно используемыми ресурсами”, рассматривается настройка общего каталога на сервере или рабочей станции. На хосте должна быть запущена служба IIS (Internet Information Services), поскольку совместно используемый каталог на самом деле представляет собой виртуальную папку принятого по умолчанию Web-сайта. Кроме этого, в метабазе IIS должна быть активизирована публикация WebDAV. По умолчанию эта возможность не включена.
Сетевой поставщик в операционной системе Windows Server 2003 (перенаправитель WebDAV) управляет транзакциями обмена файлами для Web-pecypca. WebDAV использует протокол HTTP в качестве транспортного, что позволяет применять этот протокол для доступа к файлам сквозь брандмауэр через стандартный ТСР-порт 80.
Для создания общей Web-папки на сервере должна быть установлена и запущена служба IIS. Параметры безопасности IIS должны разрешать публикацию WebDAV. Это можно сделать на консоли Internet Information Services. Щелкните правой кнопкой мыши на пиктограмме сервера, выберите из контекстного меню команду Security (Безопасность) и пройдите через все окна мастера блокировки безопасности IIS Security Lockdown Wizard. В окне Enable request Handlers установите флажок Enable WebDAV Publishing (рис. 17.11).
Рис. 17.11. Окно Enable Request Handlers мастера блокировки безопасности, в котором доступен флажок Enable WebDAV Publishing
Подключение к общему ресурсу WebDAV не сложнее указания адреса URL Web-pecypca вместо имени UNO. Например, для подключения диска придется указать адрес http: / /ммя_ сервера/web-pecypc вместо \\имя_сервера\ресурс.
При установке подключения WebDAV и открытии файла перенаправитель WebDAV выдает HTTP-команду GET для получения файла в локальный кэш временных файлов Интернет. Пользователь вносит изменения в локальную копию файла. При сохранении изменений файл копируется на ресурс WebDAV с помощью команды HTTP PUT. Это намного проще, чем использование командного языка SMB, и намного медленнее, но это намного удобнее, чем передав файлов по протоколу FTP.
Преимущества WebDAV с точки зрения EFS
Кроме стандартных команд GET и PUT, протокол WebDAV управляет блокировками файлов и поддерживает управление версиями файлов с помощью специального набора свойств, которые сохраняются вместе с данными файла. Клиент WebDAV получает доступ к свойствам с помощью команд GetProp и PostProp. На рис. 17.12 показаны свойства файла, связанные с WebDAV.
Рис. 17.12. Свойства файла в совместно используемом Web-каталоге
Поскольку клиенты WebDAV работают с локальной копией файла, они получают несколько преимуществ при работе с шифрованными файлами в общедоступной среде, например в Интернет.
Передача зашифрованных файлов. При использовании WebDAV клиент выполняет локальное шифрование файла в кэше временных файлов Интернет и передает зашифрованный файл по сети на сервер. При использовании SMB поток данных передается по сети открытым текстом.•
Не требуется установка “доверенности для делегирования”. При использовании WebDAV клиент (а не сервер) берет на себя ответственность за шифрование файла. Это значит, что сервер не нуждается в пользовательских сертификатах PKCS и, таким образом, может не являться доверенным для делегирования. Это избавляет администратора от необходимости дополнительно защищать сервер от программ типа “троянский конь”. Кроме этого, не потребуется хранение десятков и сотен пользовательских профилей в папке Documents and Settings на сервере.
Управление передачей шифрованных файлов по WebDAV
Необходимо соблюдать осторожность, манипулируя зашифрованными файлами на Web- ресурсе, так как не существует внешнего указателя на то, что файл является зашифрованным. Флаг шифрования является частью свойств WebDAV. Этот флаг можно увидеть только при просмотре файла через перенаправитель WebDAV. Если получить доступ к зашифрованному файлу WebDAV с помощью Explorer (Проводник) или через стандартный общий ресурс SMB, будет видно только зашифрованное содержимое файла. То есть, если пользователь зашифрует содержимое файла в ресурсе WebDAV, единственной возможностью открыть файл будет доступ к нему через общий ресурс WebDAV.
Этот аспект WebDAV имеет интересные последствия. Восстановление зашифрованного файла становится очень простой процедурой. Для открытия зашифрованного файла WebDAV достаточно зарегистрироваться на сервере, который хранит секретный ключ восстановления файлов агента DRA, и получить доступ к файлу через ресурс WebDAV. Файл будет открываться, так как сначала он копируется в локальный кэш.
Передача зашифрованного файла с помощью WebDAV имеет и свою негативную сторону. Поскольку содержимое зашифрованного файла WebDAV оказывается совершенно непрозрачным для файловых сканеров, этот протокол позволяет пользователям загружать в систему непроверенные файлы без проверки программ сканирования, установленных на брандмауэре или прокси-сервере. Сканирование на уровне 7 стало популярным способом защиты от вирусов и других типов вредоносного кода.
Поскольку WebDAV использует порт 80, не существует способа блокирования такой передачи данных, кроме установки политики для программы сканирования файлов с целью уведомления администратора о событии передачи зашифрованных файлов через границы брандмауэра. После этого можно связаться с пользователем и определить содержимое копируемого файла. Разумеется, такое решение требует значительных трудозатрат, но с ростом популярности WebDAV некоторые производители антивирусных программ сканирования могут найти способ автоматизации этого процесса.
Особые советы по использованию EFS
В этом разделе приводится информация об ограничениях EFS и особых соображениях при эффективном развертывании EFS.
Перемещение и копирование зашифрованных файлов
Файлы похожи на детей, которые растут в сельских общинах. Они редко остаются в папке, в которой были созданы. При перемещении или копировании файлов пользователь может получить неожиданный результат, особенно если не подозревает, что файлы зашифрованы.
Зашифровавший файл пользователь (или пользователь, которому разрешен доступ к зашифрованному списку) может скопировать содержимое файла в любое место. Это связано с тем, что поток данных дешифруется прй чтении с диска.
Если пользователь попытается скопировать или переместить зашифрованный файл на носитель, не поддерживающий EFS, оболочка Explorer (Проводник) предупредит пользователя о возможном раскрытии содержимого файла. Пользователь может проигнорировать предупреждение и сохранить файл. Если пользователь работает в командной строке, команды
сору и xcopy будут блокировать операции копирования на небезопасные тома. Существует несколько новых параметров, которые позволяют отключить блокировку. Для отключения блокировки необходимо воспользоваться командами сору /сЗихсору /д.
Если пользователь копирует незашифрованный файл в зашифрованную папку, новый файл будет зашифрован. Если пользователь переместит незашифрованный файл в зашифрованную папку (обычно при такой операции данные файла не меняются), система перехватит управление и все равно зашифрует файл, предполагая, что именно такого результата хотел добиться пользователь. Если используется командная строка, это не так. Команда move оставляет файл незашифрованным, даже если он перемещается в зашифрованную папку.
Если пользователь копирует зашифрованный файл на доверенный для делегирования сервер, файл дешифруется на клиенте, передается открытым текстом по сети и шифруется на сервере с помощью открытого ключа из пользовательского профиля на сервере. Если файлы должны передаваться по сети в зашифрованном виде, воспользуйтесь WebDAV или реализуйте IPSec (рассматривается в следующей главе).
Пользователь, которому не удается получить доступ к данным в зашифрованном файле, все еще может переместить файл, если это позволяют права доступа NTFS. Это связано с тем, что операция перемещения файла не подразумевает обращения к данным. Меняется только обратная ссылка на родительский каталог. Возможность доступа к фрагментам файла, не связанных с данными, позволяет удалить файл, переместив его в Корзину или полностью удалив файл из тома. Шифрование не является заменой соответствующим правам доступа файловой системы NTFS.
Если пользователь присоединяет зашифрованный файл к сообщению электронной почты, файл сначала дешифруется, после чего копируется во вложение MIME. Если пользователь не включил технологию S/MIME, содержимое файла может стать доступно другим пользователям.
Файлы, которые не могут быть зашифрованы
Зашифровать можно практически любой файл. Это касается файлов с данными, выполняемых файлов, файлов DLL, временных файлов и файлов с параметрами конфигурации. Но существует несколько исключений.
Сжатые файлы. Зашифрованные файлы не могут быть сжаты, а сжатые файлы не могут быть зашифрованы. Алгоритм шифрования меняет содержимое файла до такой степени, что в файле отсутствуют непрерывные последовательности символов, позволяющие добиться заметного сжатия.
Точки монтирования и точки функционального монтирования. Символические ссылки на другие файловые системы и папки не могут быть зашифрованы. Если необходимо зашифровать файлы и папки за точкой монтирования, можно перейти в каталог точки монтирования и выбрать файлы непосредственно в каталоге. Точка монтирования должна указывать на файловую систему NTFS 3.0 или более позднюю версию файловой системы.
Системные файлы. Шифрованная файловая система откажется шифровать файлы, для которых установлен атрибут System (Системный). Операционной системе может потребоваться информация из этих файлов во время загрузки еще до того, как будет включена EFS. Эту возможность можно использовать для защиты некоторых файлов от шифрования пользователями.
Кроме этого, если на компьютере установить службу индексирования, любой зашифрованный файл будет удален из индекса. Это сделано для предотвращения просмотра содержимого файла через каталог индекса.
Временные файлы, файлы подкачки, файлы спящего режима и файлы спулера
Если приложение сохраняет временные файлы, убедитесь, что они находятся в том же каталоге, что и зашифрованные файлы; или включите шифрование для папки, в которой хранятся временные файлы.
При шифровании папок с временными файлами не забудьте включить шифрование для папки \Local Settings\Temp в пользовательском профиле. Самым простым способом найти эту папку является ввод команды cd / d % t emp% в интерпретаторе командной строки.
Содержимое файлов подкачки и файлов спящего режима не шифруется. Можно включить политики, которые приведут к удалению файла подкачки при завершении сеанса и запретят использование спящего режима. Удаление файла подкачки не защищает его содержимое от просмотра шестнадцатеричным редактором, хотя просматривать страницы по 4 Кбайт в поисках полезной информации — очень трудоемкая задача. В операционной системе Windows ХР можно полностью запретить использование файла подкачки. Это позволяет избавить систему от данного уязвимого места, но на компьютере должен быть установлен достаточный объем оперативной памяти для поддержки запускаемых пользователем приложений.
Если пользователи портативных компьютеров угрожают администратору расправой за отключение спящего режима, договоритесь о его включении при условии, что перед переходом в спящий режим на компьютере будут закрыты все файлы с данными. Но существует большая разница между обещаниями “крест на пузе" и реальным следованием инструкции, поэтому группа аудита должна обратить особое внимание на это уязвимое место.
Если необходимо защитить файлы во время печати, включите шифрование файлов спуле- рав каталоге\Windows\System32\Spool\Printers.
Автономные файлы
Чтобы включить автономные файлы для пользователей портативных компьютеров, необходимо рассмотреть возможность шифрования кэша автономных файлов. При этом полное шифрование кэша не меняет состояния файлов на сервере.
Шифрование автономных файлов включается на вкладке Offline Files (Автономные файлы) в окне Folder Options (Свойства папки), которое показано на рис. 17.13.
Рис. 17.13. Окно Folder Options (Свойства папки), в котором показаны варианты шифрования
Эта возможность недоступна в операционной системе Windows 2000. Если планируется использование служб шифрования файлов от компании Microsoft, рекомендуем как можно быстрее модернизировать портативные компьютеры до Windows ХР.
Антивирусная проверка
Большинство антивирусных программ сканирования работает в контексте безопасности Localsystem или Localservice. В такой конфигурации сканер не может открывать зашифрованные файлы пользователей и способен пропустить вирус.
К сожалению, не существует абсолютного решения этой проблемы. Любое решение, позволяющее антивирусной программе просматривать содержимое файла, обеспечит такой же доступ злоумышленнику. Самым лучшим решением является использование программы сканирования на рабочих станциях и серверах, поддерживающих проверку и анализ выявления вирусов в реальном времени. Для некоторых вирусов этого может оказаться недостаточно, когда выявление вируса произойдет слишком поздно. Желательно ознакомиться с новшествами в антивирусном программном обеспечении от известных производителей.
Шифрование и восстановление системы
В операционной системе Windows ХР предоставляется новая возможность, которая называется System Restore (Восстановление системы). С помощью этой функции регулярно создается “моментальный снимок” системы и параметры сохраняются в файле кэша. Сохраняются список загруженного программного обеспечения, а также параметры драйверов и системы. Если пользователь устанавливает приложение, которое приводит к нарушению стабильности системы, пользователь может вернуть систему в предыдущее состояние, восстановив параметры из сохраненного моментального снимка.
При откате системы до предыдущей конфигурации средствами службы Restore System (Восстановление системы) существует возможность раскрытия содержимого зашифрованных файлов. Служба Restore System (Восстановление системы) хорошо справляется с сохранением флага шифрования, но компания Microsoft предупреждает, что такая возможность существует, поэтому стоит обратить на это внимание.
Служба Restore System? (Восстановление системы) может быть настроена на исключение определенных папок и файлов из списка наблюдения. Службу можно настроить на пропуск зашифрованных папок. В процессе реальной работы нельзя гарантировать, что зашифрованные файлы будут находиться в определенной папке. Если выполнить восстановление системы для пользователя, можно зарегистрироваться от имени пользователя, собрать все зашифрованные файлы в один каталог и создать резервную копию зашифрованных файлов с помощью утилиты Nt backup до запуска восстановления системы. Для поиска зашифрованных файлов воспользуйтесь командой cipher /и /п.
Процедуры EFS
На этом этапе принципы работы EPS рассмотрены в более чем достаточном объеме. Но сначала необходимо выделить время на планирование развертывания EFS. Не стоит допускать существования сотен или тысяч зашифрованных файлов, разбросанных по системе, без четкого плана управления ими.
В следующих разделах рассматриваются создание дополнительных агентов восстановления данных (DRA), развертывание открытых ключей, защита секретных ключей восстановления данных и шифрование файлов и папок. Кроме этого, рассматривается восстановление
зашифрованных файлов при отсутствии пользователя. Также будет описано использование утилиты cipher для выполнения этих задач из командной строки.
Перед развертыванием EFS желательно установить как минимум один сервер центра сертификации (СА) в пределах организации. Это не обязательно должен быть центр сертификации компании Microsoft, но он должен быть в состоянии выдавать сертификаты EFS и сертификаты восстановления файлов. Если установлен центр сертификации от стороннего производителя, обычно проще установить центр сертификации Microsoft в качестве подчиненного корня предприятия (Enterprise Root), что позволит настроить распространение сертификатов Active Directory и получить доступ ко всем функциональным возможностям работы с сертификатами. Инструкции по развертыванию центра сертификации Microsoft приводятся в главе 18, “Управление инфраструктурой открытого ключа”.
Перед развертыванием EFS просмотрите краткий список действий, которые придется выполнить.
Определить администраторов, которые станут агентами восстановления данных (DRA) для их локальных организационных единиц (OU). Таким администраторам необходимо выдать сертификаты восстановления файлов.
Импортировать сертификаты открытых ключей восстановления файлов от созданных агентов DRA в групповую политику EFS. Эта групповая политика должна входить в объект групповой политики, который связан с локальной организационной единицей.
Экспортировать и удалить секретные ключи восстановления файлов агентов DRA. Ключи должны храниться в безопасном месте для применения при восстановлении файлов.
Импортировать сертификат открытого ключа восстановления данных доменной учетной записи Administrator (Администратор). Это позволит использовать EFS на клиентах Windows 2000 и настроит правильное развертывание сертификатов агента DRA для клиентов Windows Server 2003.
Включите групповую политику EFS для клиентов Windows Server 2003 и Windows ХР.
Зашифруйте файлы и папки на портативных и настольных компьютерах.
Настройте групповую политику для шифрования кэша автономных файлов на портативных компьютерах и, возможно, на настольных компьютерах.
Кроме этого, необходимо периодически проверять возможность восстановления файлов от имени локального агента DRA. Инструкции по такой проверке также приводятся в этом разделе.
Отключите шифрование
В операционных системах Windows Server 2003 и Windows ХР предоставляется возможность шифрования файлов и без наличия агента DRA. Это усложняет отключение EFS в смешанной среде. Для отключения EFS на всех компьютерах необходимо выполнить три операции.
Для серверов под управлением Windows Server 2003 и рабочих станций под управлением Windows ХР в домене Windows Server 2003 необходимо установить групповую политику Encrypting File System для отключения EFS.
Для серверов под управлением Windows Server 2003 и рабочих станций под управлением Windows ХР в домене Windows 2000 необходимо воспользоваться собственным административным шаблоном ADM для настройки и распространения групповой политики, отключающей EFS.
Для серверов и рабочих станций под управлением Windows 2000 в домене Windows Server 2003 или Windows 2000 необходимо удалить сертификат открытого ключа агента DRA из политики Encrypting File System (Windows Server2003) илиполитики Encrypting Data Recovery Agent (Windows 2000).
Если используется изолированный сервер под управлением Windows Server 2003 или рабочие станции под управлением Windows ХР, отключите локальное шифрование файлов с помощью политики Encrypting File System в локальных политиках безопасности.
Отключение EFS на клиентах Windows Server 2003
и Windows ХР в домене Windows Server 2003
Для отключения шифрования файлов на клиентах Windows Server 2003 и Windows ХР в домене Windows Server 2003 можно воспользоваться простой групповой политикой. Последовательность действий рассматривается в процедуре 17.2.
Процедура 17.2. Отключение EFS с помощью групповой политики Windows Server 2003
Откройте редактор групповых политик (GPE) для объекта групповой политики (GPO) Default Domain.
Перейдите в раздел Computer Configuration^Windows Settings^Security Settings^Public Key Policies (Конфигурация компьютерам Параметры WindowsM Параметры безопасно- стиМ Политики открытого ключа).
Щелкните правой кнопкой мыши на пиктограмме Encrypting File System и выберите из контекстного меню команду Properties (Свойства).
Сбросьте флажок Allow Users То Encrypt Files Using Encrypting File System (EFS) (Разрешить пользователям шифровать файлы).
Щелкните на кнопке ОК для сохранения политики.
Для распространения этой политики на рабочие станции потребуется 90 минут плюс-минус 30 минут. Для принудительного обновления на клиенте можно воспользоваться командой gpupdate в командной строке. Попытайтесь зашифровать какой-нибудь каталог и убедитесь, что попытка блокируется.
Отключение EFS на клиентах Windows Server 2003
и Windows ХР в домене Windows 2000
Отключение EFS на клиентах Windows Server 2003 и Windows ХР в домене Windows 2000 требует дополнительных действий. В групповые политики Windows 2000 не входит политика EFSConf igure, которая используется для управления EFS в домене Windows Server 2003. Эту политику придется создать самостоятельно с помощью ADM-шаблона.
Воспользуйтесь редактором Notepad (Блокнот) для создания собственного шаблона ADM в каталоге \Windows\INF на контроллере домена, который выступает в роли PDC Emulator. (По умолчанию для изменения групповых политик используется сервер, выполняющий роль PDC Emulator.) Файлу можно присвоить любое имя с расширением . adm, например Ef s. adm.
Пример содержимого такого файла показан ниже. Строки, заключенные в двойные кавычки можно изменять по своему усмотрению, строку SUPPORTED необходимо оставить без изменений.
CLASS MACHINE
CATEGORY "Специальная обработка EFS"
POLICY "Отключение EFS на клиентах Windows Server 2003 и Windows ХР"
#if version >= 4
SUPPORTED "At least Microsoft Windows XP Professional"
#endif
KEYNAME "Software\Policies\MicrosoftWindows NT\CurrentVersion\Efs" EXPLAIN "Эта политика запрещает шифрование файлов на рабочих
'Ъстанциях под управлением Windows ХР, входящих в домен
4>Windows 2000. Включите эту политику для отключения EFS."
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
END POLICY
END CATEGORY
Созданный шаблон загрузите в редактор групповых политик (GPE), щелкнув правой кнопкой мыши на пиктограмме Administrative Templates (Административные шаблоны) и выбрав из контекстного меню команду Add/Remove Templates (Добавить/Удалить шаблоны). После этого выполните двойной щелчок на имени шаблона. Шаблон будет загружен в редактор. Список категорий шаблонов будет отображаться сразу под пиктограммой Administrative Templates (Административные шаблоны), как показано на рис. 17.14.
Политика вступит в силу после включения в течение 90 минут плюс-минус 30 минут. Для принудительного обновления политики введите команду gpupdate в командной строке на клиенте. При попытке создания зашифрованного файла будет выдано сообщение об ошибке Access Denied. Если этого не произошло, воспользуйтесь командой gpupdate /v и проверьте, была ли получена политика. Ниже приведен фрагмент отчета при правильной работе утилиты:
Administrative Templates
GPO: Default Domain Policy
Setting: SoftwareXPolicies\Microsoft\Windows NT\CurrentVersion\EFS State: Enabled
1I onsolc Rnol DHuull r-omain Polii у | sei ver i,company-<omJ Policy Computer Configuration'1 Administrative T—Г"I F"
ЙЙ^ Console RootЙ ^ Default Domain Poky [serveri .company.com] i e« Computer Configuration : ®- ^ Software Settings : a-1^3 windows Settings ; Й-Ш Administrative Templates$ -^ Windows Components^ Console RootЙ ^ Default Domain Poky [serveri .company.com] i e« Computer Configuration : ®- ^ Software Settings : a-1^3 windows Settings ; Й-Ш Administrative Templates$ -^ Windows ComponentsМмЫе XP and-NET ffsМмЫе XP and-NET ffsDisntav PropertiesDisntav PropertiesRequfrements:At least Mfcrosoft Windows >Ф ProfessionalRequfrements:At least Mfcrosoft Windows >Ф ProfessionalDescription;This poky stops № deskops from encrypting fibs in a Windows 2000 domain. Enable the poky to dsabie EFS.Description;This poky stops № deskops from encrypting fibs in a Windows 2000 domain. Enable the poky to dsabie EFS.S^ Network ‘^ Printers SI 4D U** ConfigurationS^ Network ‘^ Printers SI 4D U** ConfigurationExtendedExtendedPuc. 17.14. В редакторе групповых политик отображается административный шаблон, содержащий политику специальной обработки EFSPuc. 17.14. В редакторе групповых политик отображается административный шаблон, содержащий политику специальной обработки EFSn I:
Й
Й
^ Console Root
Й ^ Default Domain Poky [serveri .company.com] i e« Computer Configuration : ®- ^ Software Settings : a-1^3 windows Settings ; Й-Ш Administrative Templates
$ -^ Windows Components
^ Console Root
Й ^ Default Domain Poky [serveri .company.com] i e« Computer Configuration : ®- ^ Software Settings : a-1^3 windows Settings ; Й-Ш Administrative Templates
$ -^ Windows Components
МмЫе XP and-NET ffs
МмЫе XP and-NET ffs
Disntav Properties
Disntav Properties
Requfrements:
At least Mfcrosoft Windows >Ф Professional
Requfrements:
At least Mfcrosoft Windows >Ф Professional
Description;
This poky stops № deskops from encrypting fibs in a Windows 2000 domain. Enable the poky to dsabie EFS.
Description;
This poky stops № deskops from encrypting fibs in a Windows 2000 domain. Enable the poky to dsabie EFS.
S^ Network ‘^ Printers SI 4D U** Configuration
S^ Network ‘^ Printers SI 4D U** Configuration
Extended
Extended
Puc. 17.14. В редакторе групповых политик отображается административный шаблон, содержащий политику специальной обработки EFS
Puc. 17.14. В редакторе групповых политик отображается административный шаблон, содержащий политику специальной обработки EFS
Создайте эту политику до развертывания рабочих станций Windows ХР. Найдите все файлы, которые уже были зашифрованы, и дешифруйте их до начала промышленного развертывания EFS. Для поиска зашифрованных файлов в томе можно воспользоваться командой cipher /и /п. Для запуска этой утилиты необходимо локально зарегистрироваться на рабочей станции или получить контроль над рабочей станцией с помощью службы Remote Desktop (Удаленный рабочий стол).
Отключение EFS на клиентах Windows 2000
в домене Windows Server 2003
Для отключения EFS на клиентах Windows 2000 необходимо из групповой политики удалить сертификат открытого ключа восстановления файлов (FR public key) агента восстановления данных (DRA). Без этого сертификата клиенты не смогут шифровать файлы.
Экспортируйте копию сертификата до его удаления. В этом случае сертификат можно будет повторно импортировать при восстановлении EFS. Даже если планируется немедленное развертывание EFS, желательно экспортировать сертификат и сохранить копию на случай его удаления из групповой политики. Открытый ключ не требует специальной обработки. Главное — сделать достаточно копий, чтобы единственный отказавший гибкий диск не привел к потере файлов. Необходимая последовательность действий приводится в процедуре 17.3.
Процедура 17.3. Экспорт и удаление сертификата открытого ключа восстановления файлов
Откройте консоль Active Directory — Users and Computers (Active Directory — пользователи и компьютеры).
Перейдите в раздел Computer Configuration*Windows Settings*Security Settings*Public Key Policies* Encrypting File System (Конфигурация компьютера1* Параметры Windows* Параметры безопасности* Политики открытого ключа* Шифрованная файловая система).
Щелкните правой кнопкой мыши на пиктограмме Administrator Certificate (Сертификат администратора) в правой панели и выберите из контекстного меню команду All Tasks* Export (Все задачи*Экспорт). Запустится мастер экспорта сертификатов (Certificate Export Wizard).
Щелкните на кнопке Next (Далее). Откроется окно Export Private Key (Экспорт секретного ключа). Выберите переключатель No, Do Not Export The Private Key (Нет, не экспортировать секретный ключ).
Щелкните на кнопке Next (Далее). Откроется окно Export File Format (Формат файла экспорта). Выберите один из типов сертификатов. Все типы сертификатов криптографически эквивалентны.
Щелкните на кнопке Next (Далее). Откроется окно File То Export (Файл для экспорта). Введите или найдите путь и имя файла, в котором будет сохранен сертификат, например AdminPublicFR.сег.
Щелкните на кнопке Finish (Готово). Мастер завершит работу. Убедитесь, что файл сертификата находится в заданной папке.
После копирования файла на другой носитель можно удалить сертификат из групповой политики Encrypting File System. Убедитесь, что удален только сертификат, а не вся политика. Если удалить политику, клиенты Windows 2000 будут шифровать файлы, используя локальный агент DRA.
Настройка дополнительных агентов DRA
Если потерять секретный ключ восстановления данных, выданный учетной записи Administrator (Администратор), например, удалив профиль администратора на первом контроллере домена, восстановление файлов окажется невозможным. Чтобы избежать возникновения такой ситуации, стоит как можно быстрее назначить дополнительные агенты DRA еще до развертывания EFS.
Если организационные единицы определяются по географическому принципу, желательно для каждой из них создавать объекты GPO, в которых содержится политика Encrypting
File System для агента или агентов DRA в этой организационной единице. Другими словами, локальные администраторы должны получать сообщения, когда пользователь не сможет получить доступ к зашифрованным файлам. Например, можно создать объект групповой политики PhxEFS, связать его с организационной единицей Phoenix и загрузить сертификат открытого ключа восстановления файлов в политику Encrypting File System для объекта групповой политики PhxEFS.
Важное замечание: сертификаты агента DRA во вложенных объектах GPO не объединяются. Другими словами, клиент получает сертификат агента DRA в политике Encrypting File Sys tern, ближайшей к объекту компьютера в Active Directory. Все остальные политики игнорируются. Таким образом, если агент DRA назначен в объекте GPO, связанном с организационной единицей, доменная учетная запись Administrator (Администратор) не будет входить в список агентов DRA.
Система EFS автоматически получает только один сертификат восстановления файлов. Этот сертификат соответствует агенту DRA в домене. Для получения дополнительных сертификатов восстановления файлов назначенный на роль агента DRA администратор должен получить сертификат восстановления файлов. Для этого можно воспользоваться консолью Certificates (Сертификаты). Получите сертификат восстановления файлов, как показано в процедуре 17.4.
Процедура 17.4. Получение сертификата восстановления файлов для дополнительных агентов DRA
Зарегистрируйтесь в системе от имени учетной записи администратора, назначенного на роль агента DRA.
Загрузите оснастку Certificates (Сертификаты) на консоль ММС.
В разделе Certificates — Current User (Сертификаты — текущий пользователь) щелкните правой кнопкой мыши на папке Personal (Личные) и выберите из контекстного меню команду Request New Certificate (Запросить новый сертификат). При этом запустится мастер запроса сертификата (Certificate Request Wizard).
Щелкните на кнопке Next (Далее). Откроется окно Certificate Types (Типы сертификатов), которое показано на рис. 17.15. Выберите EPS Recovery Agent из списка типов сертификатов. Будет выдано сообщение об ошибке, если клиент не в состоянии установить связь с центром сертификации.
Щелкните на кнопке Next (Далее). Откроется окно Certificate Friendly Name and Description (Имя и описание сертификата). Введите короткое имя сертификата и его описание. По желанию эти поля можно оставить пустыми.
Щелкните на кнопке Next (Далее). Откроется окно со списком выбранных параметров.
Щелкните на кнопке Finish (Готово) для запроса сертификата. После завершения транзакции с центром сертификации должно появиться сообщение об успешном запросе сертификата.
Разверните дерево Personal^Certificates (Личные^Сертификаты), чтобы просмотреть новый сертификат. В столбце Indended Puprose (Предполагаемое использование) в качестве назначения сертификата указано File Recovery (Восстановление файлов).
Опубликуйте сертификат в Active Directory, перетащив копию в раздел Certificates^Active Directory User Object^Certificates (Сертификаты* Объекты пользователей Active Directory1* Сертификаты).
Описанная выше последовательность действий по запросу сертификата восстановления файлов заставляет центр сертификации выдавать два объекта.
Сертификат Х.509, в котором содержится открытый ключ восстановления файлов
Секретный ключ восстановления файлов, который передается клиенту по безопасному каналу
Рис. 17.15. Мастер запроса сертификата (Certificate
Request Wizard). Окно Certificate Types (Типы сертификатов), в котором выбран тип EPS Recovery Agent (Агент восстановления EFS)
Локальный поставщик шифрования размещает ключи в локальном профиле администратора. Немного ниже будет показано, как экспортировать секретный ключ восстановления данных в виде сертификата. Это позволит удалить локальную копию секретного ключа, а сам ключ сохранить в безопасном месте.
Загрузка новых агентов DRA в групповые политики EFS
Теперь, когда для всех агентов DRA получены сертификаты открытого ключа восстановления файлов, эти сертификаты необходимо добавить в объекты GPO, связанные с организационными единицами. Это позволит клиентам в организационных единицах загружать сертификаты и использовать их для шифрования файлов. Необходимая последовательность действий рассматривается в процедуре 17.5.
Процедура 17.5. Загрузка открытого ключа восстановления файлов в групповые политики EFS
Откройте консоль Active Directory — Users and Computers (Active Directory — пользователи и компьютеры).
Откройте окно Properties (Свойства) для организационной единицы, с которой будет связан новый объект GPO.
Активизируйте вкладку Group Policy (Групповая политика).
Щелкните на кнопке New (Создать) для добавления нового объекта групповой политики. Введите имя объекта, например PhxEFS.
Щелкните на кнопке Edit (Изменить), чтобы запустить редактор групповых политик.
Перейдите в раздел Computer Configuration^Windows Settings^Security Settings1*Public Key Policies (Конфигурация компьютера^Параметры Windows1*Параметры безопасности ■* Политики открытого ключа).
Щелкните правой кнопкой мыши на Encrypting File System и выберите из контекстного меню команду Add Data Recovery Agent (Добавить агент восстановления данных). Запустится мастер добавления агента восстановления (Add Recovery Agent Wizard).
Щелкните на кнопке Next (Далее). Откроется окно Select Recovery Agents (Выберите агентов восстановления).
Щелкните на кнопке Browse Directory (Просмотр каталога). Откроется окно Find Users, Contacts and Groups (Найти пользователей, контакты и группы). В этом окне можно найти агентов DRA, для которых в предыдущем разделе создавались сертификаты восстановления файлов. В поле Recovery Agents (Агенты восстановления) появится характерное имя пользователя.
Щелкните на кнопке Next (Далее). Откроется окно с выбранными параметрами.
Щелкните на кнопке Finish (Готово) для загрузки сертификата в политику.
Для вступления политики в силу на рабочих станциях потребуется 90 минут плюс-минус 30 минут. Для принудительного обновления политики на клиенте в организационной единице можно применить команду gpupdate. Попробуйте зашифровать какой-нибудь файл на рабочей станции под управлением Windows ХР. Список агентов DRA доступен на вкладке Details (Другие) в окне свойств файла. (Кроме этого, можно воспользоваться командой ef sinfo /г из состава Support Tools.) Новый агент DRA будет добавлен в список. При этом из списка будет удалена доменная учетная запись Administrator (Администратор).
Экспорт и удаление секретных ключей восстановления файлов
Без управления доступом к секретным ключам восстановления данных нельзя обеспечить безопасность EFS. Рассмотрим последовательность действий для обеспечения безопасности секретных ключей восстановления файлов.
Экспортируйте секретные ключи восстановления файлов в сертификат.
Сохраните сертификат восстановления файлов на нескольких носителях и положите носители в сейф или в хранилище.
Удалите сертификат восстановления файлов на контроллере домена, где находился сертификат до экспорта.
В процедуре 17.6 рассматривается последовательность действий для выполнения этих операций. Эта последовательность действий должна быть выполнена на компьютере, где агент DRA получил сертификат восстановления файлов.
Процедура 17.6. Экспорт и удаление секретного ключа восстановления файлов
Загрузите оснастку Certificates (Сертификаты) на консоль ММС.
Разверните дерево до раздела Certificates — Current User^Personal^Certificates (Сертификаты — текущий пользователь1*Личные1* Сертификаты). Если пиктограмма отсутствует, значит, вы загрузились не на тот компьютер.
Щелкните правой кнопкой мыши на сертификате File Recovery (Восстановление файлов) и выберите из контекстного меню команду All Tasks1*Export (Все задачи^Экспорт). Запустится мастер экспорта сертификатов (Certificate Export Wizard). Воспользуйтесь столбцом Intended Purposes (Предполагаемое использование) для поиска необходимого сертификата.
Щелкните на кнопке Next (Далее). Откроется окно Export Private Key (Экспорт секретного ключа). Выберите Yes, Export the Private Key (Да, экспортировать секретный ключ).
Щелкните на кнопке Next (Далее). Откроется окно Export File Format (Формат файла экспорта), которое показано на рис. 17.16. Для этой операции доступен только формат PKCS #12. Этот формат позволяет зашифровать секретный ключ для обеспечения дополнительной защиты.
Рис. 17.16. Окно Export File Format (Формат файла экспорта) мастера экспорта сертификатов
Оставьте флажок Enable Strong Protection (Разрешить сильную защиту). Это позволит использовать усовершенствованный алгоритм шифрования, который недоступен в операционной системе Windows NT до установки Service Pack 4.
Щелкните на кнопке Next (Далее). Откроется окно Password (Пароль). Введите пароль и его подтверждение. Требования к сложности пароля не предъявляются, но длинный пароль лучше, чем короткий, и чем меньше буквенных символов, тем лучше.
Щелкните на кнопке Next (Далее). Откроется окно File То Export (Экспортируемый файл). Введите имя, которое будет присвоено экспортируемому сертификату. Имя не имеет криптографического значения. Желательно, чтобы имя указывало на пользователя, которому принадлежит сертификат, например PhxAdminPrivate.
Щелкните на кнопке Next (Далее). Откроется окно с выбранными параметрами.
Щелкните на кнопке Finish (Готово). Мастер запишет файл сертификата и сообщит об успешном завершении экспорта.
Закройте консоль Certificate (Сертификаты).
Сделайте несколько копий экспортируемого сертификата и сохраните сертификат в безопасном месте.
Всегда проверяйте сертификат секретного ключа перед удалением секретного ключа на сервере. Для этого импортируйте ключ из сертификата на другой компьютер (сервер или рабочую станцию) и проверьте возможность открытия зашифрованных файлов на рабочей станции.
После проверки содержимого сертификата удалите секретный ключ восстановления файлов на сервере. Для этого можно воспользоваться оснасткой Certificate (Сертификаты). Это позволит защитить агент DRA от использования злоумышленниками для доступа к зашифрованным файлам.
Настройка шифрования каталогов
на портативных компьютерах
Теперь пришло время разрешить пользователям шифровать файлы. Посоветуйте пользователям включать шифрование каталогов, а не отдельных файлов, с последующим сохранением файлов в зашифрованных каталогах. В таком случае не будут создаваться временные файлы с незашифрованным содержимым.
Если пользователь включает шифрование для каталога, в котором уже хранятся файлы, файлы будут зашифрованы. В таком случае на жестком диске останутся временные файлы, поэтому пользователей необходимо обязать запускать команду cipher /w после включения шифрования с целью удаления содержимого временных файлов.
Если EFS сталкивается с заблокированным файлом, выдается предупреждение с вариантами выбора Retry (Повторить) и Ignore (Игнорировать). Пользователь должен запомнить имя заблокированного файла и зашифровать этот файл позднее, когда блокировка будет снята.
Шифрование каталогов
Чтобы включить шифрование для каталога, выполните последовательность действий, описанную в процедуре 17.7.
Управление сертификатами с помощью утилиты cipher
Пару сертификатов для восстановления файлов (сертификат открытого ключа Х.509 и сертификат секретного ключа PKCS #12) можно получить из командной строки с помощью утилиты cipher.
Для этого можно воспользоваться командой cipher /г:<имя_файла>, где <имя_файла> — это имя, под которым будут сохранены файлы с сертификатами.
После генерации файлов выполните двойной щелчок на файле, чтобы запустить мастер импорта сертификата и импортировать ключ в персональное хранилище сертификатов. Не забудьте добавить сертификаты в персональное хранилище.
Если после установки нового агента DRA необходимо обновить существующие зашифрованные файлы с использованием открытого ключа нового агента DRA, введите команду cipher /и. При этом будут обновлены все зашифрованные файлы в томе, доступные пользователю, который запустил утилиту cipher. Для проверки использования нового агента DRA можно активизировать вкладку Advanced (Дополнительно) в окне свойств файла и щелкнуть на кнопке Details (Другие).
Процедура 17.7. Включение шифрования каталога
Откройте Explorer (Проводник).
Перейдите в каталог, который должен быть зашифрован. Пользователи с перемещаемыми профилями не могут шифровать каталог Му Documents (Мои документы) или любой другой компонент профиля.
Откройте окно свойств каталога. .
Щелкните на кнопке Advanced (Дополнительно). Откроется окно Advanced Attributes (Дополнительные атрибуты).
Установите переключатель Encrypt Contents То Secure Data (Шифровать содержимое для защиты данных). Установка этого флажка одновременно с флажком Compress Contents (Сжимать содержимое) невозможна.
Щелкните на кнопке ОК, чтобы сохранить выбранные параметры и вернуться в окно Properties (Свойства).
Щелкните на кнопке ОК, чтобы применить внесенные изменения и зашифровать содержимое каталога. Откроется окно Confirm Attribute Changes (Подтвердить изменения атрибутов).
Выберите Apply Chages То This Folder, Subfolders and Files (Применить изменения к этой папке, вложенным папкам и файлам). В таком случае будет зашифровано содержимое каталога и всех его подкаталогов.
Покажите пользователям, как определить, зашифрован ли файл, по цвету текста под пиктограммой файла или папки. Если цвет не изменился, в окне Folder Options (Свойства папки) на вкладке View (Вид) включите параметр Show Encrypted or Compressed NTFS Files in Color (Показывать зашифрованные или сжатые файлы NTFS другим цветом). Кроме этого, состояние файла отображается в боковой панели окна.
Предоставление доступа к зашифрованному файлу другим пользователям
Пользователь, зашифровавший файл, может предоставить доступ к этому файлу другим пользователям. Для этого необходимо открыть окно свойств файла и щелкнуть на кнопке Advanced (Дополнительно) в группе атрибутов. После этого необходимо щелкнуть на кнопке Details (Другие), как показано на рис. 17.17.
ааааияжиишбж^ - ^
Uw V*o Can T!«mpw**ew» The Hr
phxu«er1 (phxwal @COMPANV)BABE 5FB9 4F4
Puc. 17.17. Добавление пользователей, которым разрешен доступ к зашифрованному файлу
Выбранный пользователь (или пользователи) должен иметь сертификат открытого ключа EFS в хранилище сертификатов на компьютере или в учетной записи Active Directory. Если пользователь никогда раньше не шифровал файлы, он должен сделать это на входящем в домен компьютере, чтобы получить сертификат EFS. Сертификат автоматически будет скопирован в учетную запись пользователя в базе данных Active Directory. Кроме этого, пользователя можно обучить работе с оснасткой Certificates (Сертификаты), чтобы он мог запросить сертификат EFS у центра сертификации. Первый вариант проще.
Шифрование отдельных файлов
Если пользователи настаивают на шифровании отдельных файлов, их задачу можно упростить, добавив пункт Encrypt/Decrypt (Шифровать/Дешифровать) в контекстное меню. Для этого необходимо добавить в системный реестр новую запись:
Раздел: HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced
Запись: EncryptionContextMenu
Значение: 1 (reg_dword)
Шифрование файлов и каталогов с помощью утилиты cipher
Если для управления зашифрованными каталогами отдается предпочтение утилитам с интерфейсом командной строки, воспользуйтесь утилитой cipher.
Для включения шифрования каталога введите команду cipher /е /s: <имя_каталога>. После этого все новые файлы в каталоге будут шифроваться. Существующие файлы останутся незашифрованными.
Для включения шифрования каталога с шифрованием существующих файлов введите команду cipher /е /а / i /s : <имя_каталога>. Параметр /i заставляет утилиту продолжить 'шифрование, даже если обнаружен заблокированный файл. В результате этой операции генерируются временные файлы с незашифрованным содержимым. После ввода этой команды необходимо ввести команду cipher /w для очистки свободного дискового пространства.
Для отключения шифрования каталога введите команду cipher /d <имя_каталога>. Для дешифровки файлов в каталоге воспользуйтесь командой cipher /d /а /i /s: <имя_папки>\*. *.
Восстановление шифрованных файлов
Если пользователь, зашифровавший файл, недоступен, файл можно открыть с помощью регистрационных данных агента DRA. Для этого на компьютере, на котором сохранен файл, должен существовать секретный ключ агента DRA. Не существует специального механизма восстановления или приложения для восстановления файлов. Последовательность действий выглядит следующим образом.
Импортируйте на компьютер секретный ключ восстановления файлов для агента DRA. Воспользуйтесь для этого сохраненным сертификатом. Компьютер не обязательно должен быть сервером, но он должен работать под управлением Windows Server 2003 или Windows ХР и входить в домен.
Перенесите требующие восстановления файлы на компьютер с секретным ключом восстановления файлов. Для этого можете воспользоваться утилитой Ntbackup.
Откройте и дешифруйте файлы, воспользовавшись регистрационными данными агента DRA.
Удалите секретный ключ агента DRA с компьютера.
Очистите свободное дисковое пространство для удаления остатков секретного ключа.
Единственным пунктом этой последовательности действий, требующим подробных инструкций, является п.1, а именно — импорт сертификата секретного ключа восстановления файлов. Это сертификат PFX, который был сохранен на гибком диске или компакт-диске и помещен в сейф. Последовательность действий рассматривается в процедуре 17.8.
Процедура 17.8. Импорт секретного ключа восстановления файлов из сертификата PFX
Скопируйте файл PFX, содержащий секретный ключ восстановления файлов, на жесткий диск компьютера под управлением Windows Server 2003 или Windows ХР. Этот компьютер можно рассматривать как компьютер восстановления.
Откройте Explorer (Проводник) и перейдите в папку, в которой находится файл PFX.
Выполните двойной щелчок на файле. Запустится мастер импорта сертификатов (Certificate Import Wizard).
Щелкните на кнопке Next (Далее). Откроется окно File То Import (Импортируемый файл). Убедитесь в правильности написания имени.
Щелкните на кнопке Next (Далее). Откроется окно Password (Пароль). Введите пароль, который был назначен для файла PFX при экспорте. Не устанавливайте флажок Mark This Key As Exportable (Пометить ключ как экспортируемый). Теперь копия ключа будет удалена сразу после завершения восстановления.
Щелкните на кнопке Next (Далее). Откроется окно Certificate Store (Общий ресурс сертификата). Выберите переключатель Place All Certificates In Following Store (Добавить все сертификаты в следующее хранилище) и щелкните на кнопке Browse (Обзор).
Выделите папку Personal (Личные) в иерархии логического хранилища сертификатов и щелкните на кнопке ОК, чтобы вернуться в окно мастера.
Щелкните на кнопке Next (Далее). Откроется окно со списком выбранных параметров.
Щелкните на кнопке Finish (Готово). Ключ будет извлечен из сертификата и добавлен в хранилище Personal (Личные). Мастер сообщит об успешном завершении импорта.
После этого можно открыть любой зашифрованный файл и восстановить его содержимое, скопировав его в другой файл, назначив файлу другого пользователя или полностью дешифровав файл.
Перенос зашифрованных файлов на другой компьютер
Если пользователь меняет портативные компьютеры и собирается перенести зашифрованные файлы на другой компьютер, перед администратором встает серьезная проблема Просто скопировать зашифрованные файлы по сети на новый компьютер не удастся. Для этого необходимо выполнить такую последовательность действий.
Создать резервную копию всех зашифрованных файлов на портативном компьютере пользователя (или на сетевом диске).
Настроить перемещаемый профиль пользователя.
Зарегистрировать пользователя на новом компьютере с использованием перемещаемого профиля.■
Скопировать резервную копию на новый компьютер.
Восстановить зашифрованные файлы на диск нового компьютера.
Убедиться, что пользователь может открывать зашифрованные файлы.
Если использовать перемещаемый профиль нежелательно, с помощью оснастки Certificates (Сертификаты) можно экспортировать сертификат пользователя и импортировать его на новый компьютер. Помните, что необходимо регистрироваться с использованием учетной записи пользователя. Убедитесь, что сертификату PFX с секретным ключом назначен надежный пароль и после завершения переноса секретный ключ удален со старого компьютера. Очистите свободное дисковое пространство с помощью команды с ipher /w.
В следующей главе
На этом этапе можно подумать, что EFS является самой сложной подсистемой, которую придется развертывать для пользователей. Но безопасность передачи данных важна настолько же, насколько и безопасность храненйя данных, а это значит, что придется иметь дело с несколькими еще более сложными функциями операционной системы Windows Server 2003. Это касается IP Security (IPSec), Transport Layer Security (TLS) и поддержки приложений, например, электронной почты (S/MIME). Все эти возможности требуют развертывания инфраструктуры открытого ключа. Глубоко вдохните. Ныряем.
1818
18
18
. Управление инфраструктурой открытого ключа
В
спомните детство. Помните игру в салки? Секретную дорогу в школу, по которой можно было оторваться от сверстников? Бабушку, которая угощала свежими карамельками по праздникам? Те, кто возвращаются в места своего детства, часто обнаруживают решетки на окнах, бойцовских собак во дворах и наклейки с эмблемой сигнализации на стеклах автомобилей.
Тоже самое справедливо для Интернета. Когда-то дружественное академическое сообщество превратилось в пугающее место, где всегда царит полночь и разбиты все уличные фонари. В такой среде требуется защита данных от злоумышленников и обеспечение безопасности каналов связи.
За последние десять лет появился набор технологий, который обеспечивает конфиденциальность и защиту. Все вместе эти технологии называются инфраструктурой открытого ключа (Private Key Infrastructure — PKI). В операционной системе Windows Server 2003 предоставляется поддержка наиболее популярных протоколов инфраструктуры открытого ключа. Эти службы используются для обеспечения целого ряда возможностей, например, для шифрованной файловой системы, IP Security (IPSec), Transport Layer Security (TLS), подписывания кода и в смарт-картах.
Развертывание служб инфраструктуры открытого ключа может оказаться исключительно сложным процессом. Частично это связано с природой криптографии, но большая часть сложностей является следствием того, что разные фрагменты технологии проектировались разными производителями и комитетами независимо и часто с диаметрально противоположными взглядами.,
Но не беспокойтесь. Если разобраться в терминологии и выделить основные концепции, фактическая реализация инфраструктуры открытого ключа в операционной системе Windows Server 2003 не потребует дополнительных усилий. Реальная работа заключается в планировании. В небольшой организации с тесным кругом лиц, принимающих решения в области информационных технологий, эта глава поможет спланировать и реализовать инфраструктуру открытого ключа на основе Windows Server 2003.
С другой стороны, если необходимо провести развертывание инфраструктуры открытого ключа в крупной организации с совершенно запутанным механизмом принятия решений, подготовьтесь к паре лет изучения, сравнения продуктов, запросов и предложений, презентаций производителей, стандартов и десятков встреч со скептически настроенными коллегами
и впавшими в замешательство менеджерами. В этой главе будет предоставлено достаточно информации для формирования базы и начала процесса оценки вклада компании Microsoft в данную технологию.
Необходимо ознакомиться со следующими основными элементами инфраструктуры открытого ключа.
Криптографические элементы. Это технологии шифрования и хеширования, которые используются для защиты данных и проверки личности отправителя.
Элементы открытого ключа. Это различные технологии для генерации и использования пар ключей (открытый/секретный). В операционной системе Windows Server 2003 поддерживаются широко распространенные методы. Необходимо ознакомиться с этими методами, чтобы иметь полную уверенность в их правильной реализации.,
Сертификаты. Ядром инфраструктуры открытого ключа являются безопасный обмен сертификатами и их хранение. Придется разобраться в механизмах, которые используются клиентами Windows для запроса, проверки и хранения сертификатов.
Центры сертификации. Любой элемент инфраструктуры открытого ключа способен генерировать пару открытого и секретного ключей. Для того чтобы эта пара могла использоваться для передачи данных, необходимо проверить ее действительность у центра сертификации (Certification Authoriry — СА). В этой главе рассматривается создание иерархии центров сертификации под управлением Windows Server 2003.
Выдача и отзыв сертификатов. После установки центров сертификации необходимо разобраться в механизмах выдачи сертификатов клиентам. Операционная система Windows Server 2003 обеспечивает максимальную прозрачность этого процесса, но иногда требуется вмешательство администратора.
Утилиты с интерфейсом командной строки. Наконец, при помощи утилит, которые запускаются из командной строки, можно ускорить выполнение всех операций. Утилиты предоставляются в составе наборов Support Tools и Resource Kit и позволяют управлять инфраструктурой открытого ключа и исправлять неисправности в работе PKI.
Новые возможности операционной системы Windows Server 2003
В составе операционной системы Windows 2000 компания Microsoft впервые предоставила набор интегрированных криптографических инструментов. В операционной системе Windows Server 2003 эти инструменты были усовершенствованы. Кроме этого, были реализованы изменения и улучшения, появившиеся в промышленных стандартах с момента выхода операционной системы Windows 2000. Можно выделить следующие новые возможности.
Восстановление ключей. Одной из наиболее интересных новых возможностей операционной системы Windows Server 2003 является возможность сохранения и повторной выдачи ключей шифрования, которые были удалены или потеряны пользователем.
Автоматическое включение пользователей. Эта возможность позволяет выдавать сертификаты пользователей сразу же при регистрации пользователя в домене с компьютера под управлением операционной системы Windows ХР или Windows Server 2003. Сертификат пользователя может использоваться EPS, S/MIME и IPSec. Это позволяет значительно снизить сложность развертывания данных приложений. .
Поддержка 3DES и AES. Поставщик шифрования Microsoft в операционной системе Windows Server 2003 поддерживает алгоритмы шифрования 3DES (Triple-DES) и AES
(Advanced Encryption Standard), что делает систему совместимой со стандартом FIPS-140 (правительственный стандарт США шифрования для персональных компьютеров).
Поддержка FIPS 180-2. Операционная система Windows Server 2003 поддерживает расширенные алгоритмы хеширования, указанные в Secure Hash Standard (публикация FIPS 180-2). Копия этого стандарта доступна по адресу csrc.nist.gov/encryption/shs/ dfips-180-2.pdf. Новый алгоритм является улучшением текущего стандарта 160-bit Secure Hashing Algorithm-1 (SHA1). Эти улучшения называются SHA-256, SHA-384 и SHA-512.
Отличия между списками отзыва сертификатов. Для того чтобы не выпускать длинные и неуправляемые списки отзыва сертификатов (Certification Revocation Lists — CRL), в новом документе RFC предоставляется поддержка периодического выпуска базового списка отзыва сертификатов с частыми обновлениями, которые называются отличиями между списками отзыва сертификатов (Delta CRLs). Распространение таких отличий требует намного меньше сетевых и клиентских ресурсов, чем распространение полного списка отзыва сертификатов при каждом изменении.
Управляемые шаблоны сертификатов. Новая версия шаблона в операционной системе Windows Server 2003 поддерживает обновленные расширения сертификатов с возможностью установки любых значений для этих расширений.
Улучшения в обработке смарт-карт. В операционных системах Windows Server 2003 и Windows ХР поддерживается использование смарт-карт для регистрации на сервере с помощью службы Remote Desktop (Удаленный рабочий стол). Утилиты net и runas также поддерживают использование смарт-карт.
Обновления корневого сертификата центра сертификации. При проверке сертификата, выданного внешним центром сертифика(ции, клиент под управлением Windows ХР или Windows Server 2003 автоматически будет использовать сайт Windows Update для проверки копии корневого сертификата центра сертификации. Это упрощает развертывание решений, использующих инфраструктуру открытого ключа от сторонних компаний.
Квалифицированная субординация. Классические реализации PKI сложно расширять между несколькими организациями из-за неограниченной природы перекрестных доверительных отношений. В операционной системе Windows Server 2003 используются совместимые с RFC ограничения на диапазон и типы сертификатов из внешних иерархий, которые могут считаться доверенными.
Разрешение на экспорт устойчивых алгоритмов шифрования
На прЬтяжении многих лет правительство США разрешало экспорт только тех алгоритмов шифрования, в которых использовались ключи размером 40 и 56 бит. 14 января 2000 года ситуация изменилась, так как Commerce Department пересмотрел ограничения на экспорт технологий шифрования с дополнением от 19 октября 2000 года. Копии новых правил и дополнений можно получить на следующих Web-сайтах.
Правила от 14 января: www.bxa.doc.gov/Encryption/pdfs/Cypto.pdf
Дополнение от 19 октября: www.bxa.doc.gov/Encryption/190ct2KFactsheet.html
Список часто задаваемых вопросов по дополнению от 19 октября: www. Ьха. doc. gov/ Encryption/Oct2KQandAs.html
Несмотря на ослабление экспортных ограничений в США, некоторые страны налагают свои импортные ограничения, которые предусматривают значительные штрафы. Проверьте локальное законодательство перед отправкой пользователя в зарубежную командировку с портативным компьютером, на котором используется EFS, S/MIME или PGP.
Задачи инфраструктуры открытого ключа
Службы инфраструктуры открытого ключа (PKI) в операционной системе Windows Server 2003 предоставляют поддержку приложений, использующих шифрование. Правильно спроектированная инфраструктура PKI позволяет решить следующие задачи.
Конфиденциальность. Конфиденциальность транзакций пользователя защищается шифрованием потоков данных и сообщений. ,
Аутентификация. Ни одна из транзакций не может быть по-настоящему безопасной, если участники транзакции неизвестны друг другу. Инфраструктура PKI предоставляет отправителям и получателям механизмы для проверки личности друг друга.
Целостность. Транзакции могут быть помечены таким образом, что любое вмешательство в процесс выполнения транзакции становится очевидным немедленно. Этот механизм позволяет защитить транзакцию от повтора и нарушения порядка сообщений или дейтаграмм.
Невозможность отрицания. Аутентифицировать источник сообщения — это одно, но совсем другое — не дать источнику отказаться от авторства сообщений. Цифровые подписи неразрывно связывают отправителей и их сообщения.
В инфраструктуре PKI для решения этих задач используются стандартные элементы. Для достижения конфиденциальности были разработаны сверхустойчивые алгоритмы шифрования. Сертификаты предоставляют безопасный транспорт для обмена ключами шифрования, которые используются алгоритмами шифрования. Аутентификация и целостность обеспечиваются цифровыми подписями, которые состоят из зашифрованных хешированных паролей. Невозможность отрицания обеспечивается применением цифровых подписей таким образом, что отправитель всегда оставляет свой идентификатор в отправленных сообщениях.
Ниже приведены источники дополнительной информации о компонентах инфраструктуры PKI, которые используются в операционной системе Windows Server 2003.
RSA Labs, www. rsalabs. com
Federal Information Processing Standards (FIPS), www. itl .nist. gov/ f ipspubs
Рабочая группа по инфраструктуре открытого ключа в составе Internet Engineering Task Force (IETF), www.ietf.org/html. charters/pkix-charter. html
Документация по инфраструктуре открытого ключа от компании Microsoft, www. microsof t. com/security
Документы RFC, связанные с инфраструктурой открытого ключа, www. nexor. com
Существует несколько производителей программного обеспечения, которые продают продукты для инфраструктуры открытого ключа. Эти продукты можно использовать как вместо инфраструктуры открытого ключа в операционной системе Windows Server 2003, так и вместе с ней. Ниже перечислены основные производители таких продуктов.
Verisign, www. verisign. сот
Thawte, www. thawte .com ■
Schlumberger, www. Schlumberger. com
Digital Signature Trust, www. dst. com
SecureNet, www. securenet. com.au
Entrust, www. entrust. com
Baltimore Technologies, www .Balt imore. com
Криптографические элементы х в Windows Server 2003
В 9 классе я и мой друг Марк Рофф'(Магк Roff) обменивались секретными записками. В нашем коде использовалось смещение номеров букв на основе книги “Властелин колец” издательства Bantam. В записках указывались номера страниц и эльфийские руны, которые скрывали знание, известное только нам двоим. Мы особым образом складывали записки, поэтому знали, что записки никто не читал.
Не стоит даже упоминать, что наши записки не отняли бы много времени у опытного криптографа. (Если честно, то Марк мог создать более сложную систему, но он сделал ее простой для меня.) Несмотря на недостаток сложности, записки содержали все элементы современной инфраструктуры открытого ключа: алгоритм шифрования, уникальный ключ шифрования, метод секретного обмена ключами и способ проверки целостности процесса.
Методы шифрования
Криптографические службы в операционной системе Windows Server 2003 используют два универсальных метода шифрования.
Блочный. Блочный шифратор делит данные на фрагменты, при необходимости дополняет последний фрагмент и по очереди шифрует каждый фрагмент. Лучшие шифраторы используют результат шифрования предыдущего блока как основу для ключа шифрования следующего блока (шифрование блоков по цепочке). Большинство алгоритмов'шифрования использует блочную шифрацию.
Потоковый. Потоковый шифратор использует последовательность случайных чисел, создаваемую на основе ключа шифрования. Последовательность случайных чисел используется для шифрования потока битов. Поток случайных чисел на самом деле является предопределенной битовой последовательностью, зависящей от ключа шифрования, поэтому при наличии ключа шифрования поток может быть дешифрован. Если приходится шифровать большие объемы данных для передачи, потоковое шифрование работает намного быстрее, чем блочное шифрование.
Принятые по умолчанию поставщики шифрования в операционной системе Windows Server 2003 поддерживают следующие алгоритмы шифрования.
RC2 и RC3. Эти алгоритмы разработал Рональд Ривест (Ronald Rivest), входящий в группу Rivest, Shamir and Adleman, которая организовала компанию RSA Labs в 90-х годах прошлого века. Это алгоритмы блочного шифрования с переменным размером блока и ключа. Эта “переменность” усложняет взлом, если взломщик не знает размерности оригинальных данных при попытке дешифровки данных.
RC4. Алгоритм RC4 также был разработан в RSA и является алгоритмом потоковой шиф- рации с переменным размером ключа для защиты от атак.
DES. Устаревший стандарт Data Encryption Standard (DES) был совместно разработан компанией IBM и правительством США. В стандарте используется алгоритм с блоком размером 64 бит и ключом размером 40 или 56 бит. Главными преимуществами этого алгоритма являются скорость и возможность экспорта. Алгоритм DES был взломан очень давно и не используется ни в одном уважаемом продукте шифрования.
DESX. Модификация DES, созданная Ривестом в RSA. В этой модификации алгоритм DES размещен между двумя битовыми операциями XOR (ИСКЛЮЧАЮЩЕЕ ИЛИ) с различными ключами.
3DES. Алгоритм Triple-DES практически не является модификацией DES. Этот алгоритм подразумевает усиление надежности шифрования за счет трехкратного шифрования с помощью алгоритма DES.
AES. Новый стандарт Advanced Encryption Standard (AES) использует алгоритм Rijndael. Этот алгоритм был разработан Йоаном Даменом (Joan Daemen) и Винсентом Рейме- ном (Vincent Rijmen) в Бельгии. Со временем AES придет на смену DESX и 3DES.
Ключи шифрования .
В целом, чем больше и сложнее ключ шифрования, тем меньше вероятность, что кто-то • сможет расшифровать содержимое зашифрованного сообщения. Конечно, так бывает не все- j гда. Можно использовать исключительно длинный ключ и исключительно простой алгоритм | шифрования. Но что это значит?]
Существуют два типа ключей шифрования.|
Симметричные. При таком алгоритме один и тот же ключ используется как для шифро- I вания, так и для дешифровки данных.;
Асимметричные. При таком алгоритме два ключа математически связаны друг с другом. ] Один из ключей используется для шифрования, а второй — для дешифровки.1
Асимметричные ключи используются в медленно работающих алгоритмах, которые ] обычно не подходят для шифрования больших объемов данных. В алгоритмах для массового 1 шифрования обычно используются симметричные ключи, но в таком случае приходится | обеспечивать секретную пересылку ключа. В большинстве современных систем используется I гибридный метод с краткодействующим симметричным ключом, зашифрованным асиммет- 1 ричным ключом. Защита и проверка асимметричных ключей возлагается на инфраструктуру 1 открытого ключа.■1
Хеш
Шифрование решает только две поставленные задачи, конфиденциальность и целост- I ность. Для аутентификации и невозможности отказа инфраструктура PKI использует другое J средство обработки данных — хеш (hash). Иногда хеш называют дайджестом сообщения 1 (message digest). 1
В отличие от шифрования, при котором исходные данные могут быть восстановлены, при 1 хешировании исходные данные меняются необратимо. ■ |
В самой простой форме алгоритм хеширования принимает входящие данные переменной | длины, а выходные данные имеют фиксированный размер, который очень зависит от входной | информации. Изменение единственного бита во входных данных приводит к десяткам изме- 1 нений в выводе. Чем больше размерность хеша, тем более безопасным считается алгоритм. | Для создания хеша большего размера требуется больше времени, поэтому приходится нахо- I дить баланс между безопасностью и производительностью. 1
яяВ цифровых подписях используется технология хеширования для проверки личности от- 1 правителя-. Например, в методе создания цифровой подписи RSA хешируется сообщение | (или дейтаграмма TCP), а затем хеш шифруется секретным ключом отправителя. Получатель | хеширует сообщение (или дейтаграмму) с помощью того же алгоритма и дешифрует хеш от- 1 правителя с помощью открытого ключа отправителя. Выполняется сравнение полученного и 1 созданного хешей. Если хеши совпадают, личность отправителя считается подтвержденной. |
я
я
В стандарте Digital Signature Security Standard (DSS) используется похожий метод под- | писывания, но пара ключей генерируется с помощью алгоритма Digital Signature Algorithm | (DSA), а не RSA. Алгоритм DSA работает медленнее, но он безопаснее, чем алгоритм хеширо- |
1
вания SHA-1. При его использовании вероятность генерации такого же хеша на основе других исходных данных намного ниже.
Хеширование не является криптографическим процессом, но существует возможность добавления к хешу ключа шифрования, что позволит создать криптографический “винегрет” из разных методов. Этот метод называется Hashed-based Message Authentication Code (HMAC) и определяется в документе RFC 2104, “HMAC: Keyed-Hashing for Message Authentication". Технология HMAC используется для создания цифровых подписей в S/MIME, IPSec и Secure Sockets Layer (SSL). Также эта техника используется для защиты паролей в Kerberos и NT LanMan (NTLM) Challenge-Response.
Теоретически возможно сгенерировать хеш методом проб и ошибок и создать коллизию (collision), т.е. одинаковые хеши для разных исходных данных. Например, в операционной системе Windows хеши используются для защиты паролей. Предположим, что используется пароль £oan$hark. Система хеширует этот пароль с помощью алгоритма RSA MD4 и создает хеш фиксированного размера 128 бит. Хешированный пароль сохраняется в базе данных Active Directory. Программа взлома паролей может попытаться определить пароль (или эквивалентную замену), хешируя комбинации букв и цифр по алгоритму MD4, пока не будет получен результат, совпадающий с хешем в базе данных Active Directory.
В операционной системе Windows Server 2003 поддерживается шесть механизмов хеширования.
MD4 и MDS. (“MD” расшифровывается как “message digest” или “дайджест сообщения”.) Это алгоритмы RSA. Алгоритм MD4 используется для хеширования паролей пользователей в операционных системах Windows NT и Windows 2000. Алгоритм MD5 используется для поддержки внешней аутентификации CHAP (Challenge Handshake Authentication Protocol) для клиентов коммутируемого доступа. Оба алгоритма обрабатывают исходные данные блоками по 512 бит и выдают единственный блок размером 128 бит. Алгоритм MD5 более требователен к вычислительным ресурсам, но обеспечивает большую безопасность.
SHA-1. Алгоритм SHA (Secure Hash Algorithm) был предложен институтом NIST (National Institute of Standards and Technology) в дополнение к стандарту цифровой подписи DSS (Digital Signature Standard). Алгоритм SHA-f основан на MD4. Он обрабатывает исходные данные блоками по 512 бит, но создает выходной блок размером 160 бит, а не 128 бит. Это делает SHA-1 более безопасным, чем MD4 или MD5, при прочих равных условиях. Кроме этого, алгоритм SHA-1 не восприимчив к криптоанализу, что обеспечивается алгоритмом искажения данных. Также этот алгоритм работает быстрее, чем MD4 и MD5.
SHS (Secure Hash Standard). В этот стандарт входят расширения SHA-1 с большим размером дайджеста: SHA-256, SHA-384 и SHA-512. В системном реестре не существует параметра, который позволяет выбирать разные алгоритмы. Алгоритм выбирается из библиотеки разработчиком приложения.
Службы открытого/секретного ключа
Теоретически пользователи могут обмениваться ключами шифрования, копируя ключи на диск и передавая диск в защищенном контейнере. Инфраструктура открытого ключа является электронной курьерской службой, которая работает в крайне небезопасной сети.
Технология открытого ключа начала использоваться в конце 1970-х годов, когда Уитфилд Диффи (Witfield Diffie) и Мартин Хеллман (Martin Hellman) разработали метод открытого обмена секретными ключами. Они разработали криптографический эквивалент передачи кошелька с деньгами продавцу пива через весь стадион с уверенностью, что никто не попытается взять деньги из кошелька по дороге.
Через некоторое время после появления метода обмена ключами Диффи-Хеллмана трио, в которое вошли Рон Ривест (Ron Rivest), Ади Шамир (Adi Shamir) и Лен Эйдельман (Len Adleman) — учредители RSA Labs, на основе идеи математически связанных ключей разработали более универсальную службу на основе пар ключей. Все данные, зашифрованные одним ключом, могут быть расшифрованы только с помощью другого ключа из пары.
RSA определяет один из ключей как открытый (public). Открытый ключ может свободно распространяться. Можно распылять краску на стены зданий, не боясь скомпрометировать систему безопасности. (Здесь, в Финиксе, краска на стенах заменила газеты и стала основным средством общественных коммуникаций.) Секретный ключ требует совершенно другого подхода. Секретный ключ должен надежно защищаться. Элемент инфраструктуры открытого ключа (пользователь) получает открытый ключ другого пользователя и применяет его для шифрования сообщений таким образом, что только первый пользователь, обладающий своим секретным ключом, способен расшифровать сообщение.
В RSA были разработаны безопасные методы для проверки и распространения открытых ключей с помощью сертификатов (certificates). Сертификат содержит открытый ключ и информацию об издателе ключа, владельце ключа и сроке действия ключа.
RSA Labs продолжает оставаться основным разработчиком технологии инфраструктуры открытого ключа (PKI). Дополнительная информация доступна на сайте по адресу www. rsalabs.com.
После создания технологий обмена открытыми/секретными ключами RSA программист Фил Циммерман (Phil Zimmerman) скомбинировал асимметричные ключи с симметричным массовым шифрованием и создал технологию PGP (Pretty Good Privacy). Этот продукт до сих пор широко используется для шифрования электронной почты. Дополнительная информация доступна на сайте PGP по адресу www.pgp.com. (Теперь права на технологию PGP принадлежат компании Network Associates, www. паi . com.)
Компания Network Associates прекратила разработку утилит PGP и заявила о прекраще-, нии поддержки в 2002 году. Фил Циммерман пытается заставить компанию Network Associates 1 сделать код PGP общедоступным. Дополнительная информация о разработках в этой области | представлена на сайте OpenPGP по адресу www. openpgp. com. ]
С тех пор технология открытого ключа развилась в систематическую методику создания, 1 получения, распространения, каталогизации и защиты криптографических элементов. Глав- j ным хранилищем информации об инфраструктуре открытого ключа является PKIX Working | Group, которая поддерживается институтом IETF. Дополнительная информация доступна по I адресу www.ietf.org/html.charters/pkix-charter.html. I
Технологии открытого ключа в операционной системе Windows Server 2003 |
Операционная система Windows Server 2003 поддерживает следующие методы обмена от-1 крытыми ключами. 1 ■ Диффи-Хеллмана | ■ RSA I ■ Digital Signature Standard (DSS) |
Метод Диффи-Хеллмана I
Метод Диффи-Хеллмана (Diffi-Hellman, D-H) является дедушкой технологий открытого 1 ключа. Это способ обмена секретным ключом по открытой сети без передачи самого ключа 1 или зашифрованной формы ключа. В операционной системе Windows Server 2003 метод!
Дифф^-Хеллмана используется для поддержки IP Security (IPSec), Secure Socket Layer (SSL) и Transport Layer Security*(TLS).
В транзакции D-H отправитель и получатель используют очень большие простые числа и примитивные корни этих простых чисел в механизме, который создает секретные ключи. Метод D-H использует особые свойства простых чисел и логарифмов простых чисел в модульной алгебре. Это странный раздел алгебры, в котором числа конгруэнтны, если остатки равны после целого деления на одно число. Общий делитель называется модулем (modulus), отсюда и имя. Например, 17/3 равно 5 с остатком 2, поэтому 17 по модулю 3 равно 2. Так как 23 по модулю 3 также равно 2 (23/3 равно 7 с остатком 2), числа 23 и 17 конгруэнтны ио модулю 3.
В методе D-H два элемента системы безопасности (пользователя) независимо генерируют секретное случайное число, Ах — с одной стороны и Вх — с другой стороны. Каждый элемент пропускает числа через механизм D-H для создания открытых чисел Ра и Рь. Пользователи обмениваются этими числами и пропускают их через вторую часть механизма D-H для создания секретного ключа. Именно в этот момент начинает действовать модульная алгебра. Раздельные расчеты на разных компьютерах приводят к одинаковым результатам.
Конечным результатом этой транзакции является общий секретный ключ, который может использоваться для шифрования сообщений пользователей. Злоумышленййк не может рассчитать секретный ключ D-H без информации об оригинальной последовательности секретных случайных чисел на одном из компьютеров.
RSA
Большая часть этой главы посвящена генерации и использованию ключей RSA, поэтому здесь они не будут рассматриваться подробно. В отличие от метода Диффи-Хеллмана, в котором ключ существует только на протяжении сеанса, RSA генерирует постоянно существующие ключи, которые могут использоваться для шифрования, цифровой подписи и т.д. В операционной системе Windows Server 2003 ключи RSA используются в протоколе Kerberos. В Exchange 2000 ключи RSA используются в технологии S/MIME.
Стандарт цифровой подписи
В 1991 году институт NIST опубликовал стандарт 186, Digital Signature Standard (DSS). В этом стандарте описывался метод генерации пар открытого/секретного ключа, отличавшийся от метода RSA. Новый метод назывался Digital Signature Algorithm (DSA).
Институт NIST опубликовал DSA для решения очевидной проблемы метода RSA, связанной с созданием цифровых подписей. (Только циники будут утверждать, что новый ме!од был предназначен для обхода лицензионных отчислений RSA.)
В методе DS А используются ключи сеанса, основанные на сложности получения дискретных логарифмов, как и в методах Диффи-Хеллмана и RSA. Разница заключается в использовании ключей для проверки и применения цифровой подписи. При использовании RSA сообщения подписываются быстро, а проверка Подписи отнимает заметную часть вычислительных ресурсов процессора. При использовании DSA подписывание отнимает больший объем ресурсов, а проверка оказывается достаточно простой. В операционной системе Windows Server 2003 поддерживаются как метод RSA, так и метод DSA. Выбор метода зависит от разработчика приложения. '
Службы шифрования в операционной системе Windows Server 2003
В операционной системе Windows Server 2003 используется набор библиотек функций и выполняемых файлов для шифрования, например для генерации ключей шифрования и обработки сертификатов. В операционных системах Windows 9х и Windows NT эти библиотеки
называются Crypto API. В операционных системах Windows 2000 и Windows Server 2003 этот набор программных средств называется Data Protection API (DPAPI). Вызовы функций из этих библиотек одинаковы для всех современных платформ Windows, хотя выполняемые файлы могут отличаться. Это позволяет обеспечить обмен зашифрованными и подписанными данными между всеми клиентами Windows.
Каждый дискретный набор криптографических функций поддерживается поставщиком службы шифрования (Cryptographic Service Provider — CSP). Компания Microsoft предоставляет набор поставщиков служб шифрования в составе операционной системы Windows Server 2003 для обеспечения базовых служб шифрования. Сторонние производители предоставляют собственные поставщики служб шифрования для поддержки аппаратных средств или независимых функций шифрования. На рис. 18.1 показан список поставщиков служб шифрования в системном реестре в разделе HKLM\Software\Microsof t\Cryptography\ DefaultsXProvider.
«IflUti«IflUtiCryptography QB AutoEnrolment S-^ CalaisC3 Catalog»£3 CatDBTempFles ' ^ CertiffcateTemplateCache Й CJ DefaultsCryptography QB AutoEnrolment S-^ CalaisC3 Catalog»£3 CatDBTempFles ' ^ CertiffcateTemplateCache Й CJ Defaults■ - Q Gempius GemSAFE Card CSP vl .0□ Infineon SICRYPT Base Smart Card CSP О Mkrosoft Base Cryptographic Provider vl.O Cl Mkrosoft Base DS5 and Dffie-Helman Cryptogaphic Provider О Mkrosoft Base DS5 Cryptographic Provider C3 Mkrosoft DH SChannel Cryptographic Provider Q Hcroscft Enhanced Cryptographic Provider vl .0: Cl Merosoft Enhanced DSS and Dffie-Heiman Crvntoor^iwr Provider - ~ ^ Mkrosoft Enhanced RSA and AES Cryptographic Provider (Prototype) Ш□ Mkrosoft RSA SChamei Cryptographic Provider Cl Mkrosoft Strong jCnotooraohk Piwider•• S3 Schlumberger Cryptographic Servfce Provider ; Й ^ Provider Types*4■ - Q Gempius GemSAFE Card CSP vl .0□ Infineon SICRYPT Base Smart Card CSP О Mkrosoft Base Cryptographic Provider vl.O Cl Mkrosoft Base DS5 and Dffie-Helman Cryptogaphic Provider О Mkrosoft Base DS5 Cryptographic Provider C3 Mkrosoft DH SChannel Cryptographic Provider Q Hcroscft Enhanced Cryptographic Provider vl .0: Cl Merosoft Enhanced DSS and Dffie-Heiman Crvntoor^iwr Provider - ~ ^ Mkrosoft Enhanced RSA and AES Cryptographic Provider (Prototype) Ш□ Mkrosoft RSA SChamei Cryptographic Provider Cl Mkrosoft Strong jCnotooraohk Piwider•• S3 Schlumberger Cryptographic Servfce Provider ; Й ^ Provider Types*4
«IflUti
«IflUti
Cryptography QB AutoEnrolment S-^ Calais
C3 Catalog»
£3 CatDBTempFles ' ^ CertiffcateTemplateCache Й CJ Defaults
Cryptography QB AutoEnrolment S-^ Calais
C3 Catalog»
£3 CatDBTempFles ' ^ CertiffcateTemplateCache Й CJ Defaults
■ - Q Gempius GemSAFE Card CSP vl .0
□ Infineon SICRYPT Base Smart Card CSP О Mkrosoft Base Cryptographic Provider vl.O Cl Mkrosoft Base DS5 and Dffie-Helman Cryptogaphic Provider О Mkrosoft Base DS5 Cryptographic Provider C3 Mkrosoft DH SChannel Cryptographic Provider Q Hcroscft Enhanced Cryptographic Provider vl .0
: Cl Merosoft Enhanced DSS and Dffie-Heiman Crvntoor^iwr Provider - ~ ^ Mkrosoft Enhanced RSA and AES Cryptographic Provider (Prototype) Ш
□ Mkrosoft RSA SChamei Cryptographic Provider Cl Mkrosoft Strong jCnotooraohk Piwider
•• S3 Schlumberger Cryptographic Servfce Provider ; Й ^ Provider Types*4
■ - Q Gempius GemSAFE Card CSP vl .0
□ Infineon SICRYPT Base Smart Card CSP О Mkrosoft Base Cryptographic Provider vl.O Cl Mkrosoft Base DS5 and Dffie-Helman Cryptogaphic Provider О Mkrosoft Base DS5 Cryptographic Provider C3 Mkrosoft DH SChannel Cryptographic Provider Q Hcroscft Enhanced Cryptographic Provider vl .0
: Cl Merosoft Enhanced DSS and Dffie-Heiman Crvntoor^iwr Provider - ~ ^ Mkrosoft Enhanced RSA and AES Cryptographic Provider (Prototype) Ш
□ Mkrosoft RSA SChamei Cryptographic Provider Cl Mkrosoft Strong jCnotooraohk Piwider
•• S3 Schlumberger Cryptographic Servfce Provider ; Й ^ Provider Types*4
Puc. 18.1. Расположение разделов системного реестра, связанных с поставщиками служб шифрования
На самом деле этот список сложнее, чем необходимо. До ослабления экспортных ограничений на технологий шифрования компания Microsoft была вынуждена предоставлять отдельные версии поставщиков для США и для экспорта. Обычно для разделения использовались обозначения Base и Enhanced. В операционной системе Windows Server 2003 все технологии шифрования можно экспортировать, поэтому существует два основных поставщика служб шифрования (CSP) и несколько надстроек от производителя.
RSAenh. Этот поставщик CSP поддерживает криптографические функции, соответствующие стандарту RSA и правительственным стандартам шифрования в США. Эти функции включают в себя возможности генерации ключей, запроса сертификатов, хеширования и шифрования. Кроме этого, данный поставщик поддерживает службы Schannel для безопасного обмена данными с Web-сайтами.
Dssenh. Этот поставщик поддерживает правительственный стандарт Digital Signature Standard, принятый в США, и более распространенные транзакции обмена ключами Diffi- Hellman.
Поставщики смарт-карт. В операционной системе Windows Server 2003 используются универсальные интерфейсы для сбора билетов со смарт-карт и наборы драйверов для уст-
ройств чтения смарт-карт Gemplus, Infineon (бывшее подразделение Siemens Semiconductors) и Schlumberger.
Вместе с Outlook 2000 и Outlook ХР устанавливается еще один поставщик служб шифрования, Exchcsp.dll, который поддерживает S/MIME, соответствующий стандарту FIPS-140. Этот поставщик описан в документе, доступном по адресу csrc.nist .gov/cryptval/140-1/ 140spZ140spll0.pdf.
Хранилище ключей
В операционных системах Windows Server 2003 и Windows ХР пользовательские ключи шифрования хранятся в профиле пользователя. Расположение ключей показано на рис. 18.2.
Секретные ключи пользователя хранятся в каталоге Crypto/RSA. Ключи шифруются ключом сеанса, полученным на основе главного ключа, который генерируется интерфейсом DPAPI.
Главный ключ (Master key) хранится в каталоге Protect\<5Ю_пользователя>. Ключ шифруется с помощью специальной структуры, которая называется HMAC (Hash-based Message Authentication — код аутентификации хеш-сообщения). Структура НМАС представляет собой хеш, объединяющий блок данных с секретным ключом. Структура НМАС для главного ключа состоит из хеша SHA-1 самого главного ключа, использующего хеши- рованный пароль пользователя в качестве секретного ключа. Структура НМАС позволяет шифровать главный ключ с помощью криптографически устойчивого ключа, созданного на основе пароля пользователя.
Открытые ключи пользователей хранятся в каталоге System Certificates\ Certificates. Копии сертификатов открытых ключей хранятся в системном реестре. Если пользователь является членом домена Windows Server 2003 и Windows 2000, копия открытого ключа пользователя может храниться в базе данных Active Directory.
iSss I f, zl lOtiSUM/14 1 ShO 136h(>Z aS42453DH SOUiSss I f, zl lOtiSUM/14 1 ShO 136h(>Z aS42453DH SOUQ Ci^ocumants and SettingsVtcbninlstratorV^ Data№o*>ft\Crypto\RSA\S-l-5-21-10850312i4-1580436667-85424539tjQ Ci^ocumants and SettingsVtcbninlstratorV^ Data№o*>ft\Crypto\RSA\S-l-5-21-10850312i4-1580436667-85424539tj0 £3 Administrator0 ^ Appkation Data0 £3 IdentitiesEI QlMkrosoftS 63 OR Security Corfig0 Q) Credentials0 ^ Crypto0 Q R5A0 £3 Administrator0 ^ Appkation Data0 £3 IdentitiesEI QlMkrosoftS 63 OR Security Corfig0 Q) Credentials0 ^ Crypto0 Q R5A7f23be66224292f81aI9ccf6e098bdIc-87iic42: ^24e4c4e0cl92d713daa3e6f870833050_8711c4;7f23be66224292f81aI9ccf6e098bdIc-87iic42: ^24e4c4e0cl92d713daa3e6f870833050_8711c4;
iSss I f, zl lOtiSUM/14 1 ShO 136h(>Z aS42453DH SOU
iSss I f, zl lOtiSUM/14 1 ShO 136h(>Z aS42453DH SOU
Q Ci^ocumants and SettingsVtcbninlstratorV^ Data№o*>ft\Crypto\RSA\S-l-5-21-10850312i4-1580436667-85424539tj
Q Ci^ocumants and SettingsVtcbninlstratorV^ Data№o*>ft\Crypto\RSA\S-l-5-21-10850312i4-1580436667-85424539tj
0 £3 Administrator
0 ^ Appkation Data
0 £3 Identities
EI QlMkrosoft
S 63 OR Security Corfig
0 Q) Credentials
0 ^ Crypto
0 Q R5A
0 £3 Administrator
0 ^ Appkation Data
0 £3 Identities
EI QlMkrosoft
S 63 OR Security Corfig
0 Q) Credentials
0 ^ Crypto
0 Q R5A
7f23be66224292f81aI9ccf6e098bdIc-87iic42: ^24e4c4e0cl92d713daa3e6f870833050_8711c4;
7f23be66224292f81aI9ccf6e098bdIc-87iic42: ^24e4c4e0cl92d713daa3e6f870833050_8711c4;
В 63 Internet Explorer QjMMC
0 Q| Protect
Q| 5-1-5-21-1005031214-1580436667-854245398-500
0 63 Systemcertificates
0 ^My
Certificates
Q CTLs
О Keys
S £3 Windows 63 Cookies
Puc. 18.2. Расположение ключей в пользовательском профиле
Если удалить профиль пользователя, будут потеряны секретные ключи, связанные с открытыми ключами, которые использовались для шифрования файлов и сообщений электронной почты. При потере секретного ключа пользователь больше не сможет дешифровать файлы и сообщения. Если развернута инфраструктура открытого ключа на основе Windows, проявляйте исключительную осторожность при работе с профилями пользователей.
Сертификаты
В механизмах обмена ключами Диффи-Хеллмана и DSS новый ключ шифрования создается для каждого сеанса. Это имеет смысл в таких приложениях, как IPSec, в которых безо- I пасные сетевые соединения устанавливаются при необходимости. Но что если необходимо i сохранить ключ для последующего использования, например, при использовании цифровых i подписей? Необходим способ безопасной передачи ключа, и, что еще важнее, ключ должен ] быть выдан авторизованным источником и не должен измениться по дороге.j
Структура данных, которая используется для передачи и проверки ключей, называется { сертификатом (certificate). Сертификат выступает в роли сейфа, который защищает ключ, гарантируя личность источника ключа, личность владельца ключа и допустимые области применения ключа. Кроме этого, в сертификате содержится дополнительная информация, которая называется расширениями (extension) и упрощает процесс проверки.;
Сертификат не может быть подделан, так как источник подписывает сертификат цифровой подписью. Подписывается хеш сертификата. Это позволяет клиентам одновременно про- i верять личность источника сертификата и целостность сертификата. Клиент дешифрует хеш j сертификата с помощью открытого ключа источника и сравнивает результат с самостоятельно вычисленным хешем сертификата. Если результаты сравнения совпадают, сертификат i считается действительным.
В операционных системах Windows Server 2003, Windows ХР и Windows 2000 для работы с сертификатами используется технология DPAPI. Выданные клиенту сертификаты сохраняются в системном реестре и Active Directory. Ключи хранятся на диске. Кроме этого, сертификаты могут храниться на смарт-карте. В таком случае исключается ненадежность диско- I вого хранилища сертификатов. Для просмотра выданных клиенту сертификатов можно вое- ] пользоваться оснасткой Certificates (Сертификаты). Для этой оснастки не существует | предварительно созданной консоли, поэтому ее необходимо загрузить на пустую консоль с I помощью команды File^Add/Remove Snap-in (Файл^Добавить/Удалить оснастку) из меню 1 ММС. Общая информация о сертификате показана на рис. 18.3.]
Сертификат содержит следующие элементы (некоторые элементы являются необяза- | тельными)._I
Issued By (Кем выдан). Центр сертификации, выдавший сертификат. По умолчанию ко- > 1 пия сертификата открытого ключа хранится в базе данных центра сертификации. Центр 1 сертификации на основе Windows Server 2003 может также хранить сертификаты секрет- ] ных ключей.]
Issued То (Кому выдан). Элемент системы безопасности, которому был выдан сертификат. 1 В инфраструктуре PKI на основе Windows Server 2003 имена компьютеров могут указы- | ваться как “плоские” имена или полностью определенные доменные имена. Если получа- | телем является пользователь, в качестве имени может использоваться регистрационный 1 идентификатор, основное имя пользователя (UPN) или характерное имя пользователя (DN). 1
Intended Uses (OID) (Предполагаемое применение). Сертификат имеет одно или не- | сколько предполагаемых применений. Выдача сертификата для всех применений невоз- 1 можна. Центр сертификации, выдающий сертификат, определяет предполагаемое приме- 1 нение на основе идентификатора объекта (Object ID — OID). Для записи идентификатора 1
объекта используется точечно-десятичный формат с целью указания иерархии. Например, идентификатор объекта 1.3.6.1.4.1.311.20.2.1 относится к функции Enrol Iment Agent. Идентификатор объекта начинается с ISO в Женеве (1), выдан организации, признанной ISO, в данном случае Министерству обороны США (1.3.6), и управляется организацией Internet Assigned Naming Authority (1.3.6.1).
t ertdicatet ertdicateJJ2S1'JJ2S1', OU * EFS Rte Encryption Certificate : L-EFSCN-= Administrator, OU * EFS Rte Encryption Certificate : L-EFSCN-= AdministratorGeneral Ortak | certficabon Path |General Ortak | certficabon Path |
t ertdicate
t ertdicate
JJ2S1'
JJ2S1'
, OU * EFS Rte Encryption Certificate : L-EFS
CN-= Administrator
, OU * EFS Rte Encryption Certificate : L-EFS
CN-= Administrator
General Ortak | certficabon Path |
General Ortak | certficabon Path |
Puc. 183. Обитая информация о сертификате, доступная в оснастке Certificates (Сертификаты)
Version (Версия). Версия сертификата. Серверы центров сертификации под управлением Windows выдают сертификаты Х.509 Version 3.
Serial Number (Серийный номер). Это серийный номер сертификата, заданный центром сертификации. Номер является уникальным и обеспечивает проверку действительности сертификата.
Signature Algorithm (Алгоритм подписи). Алгоритм хеширования, который используется для создания цифровой подписи сертификата. Обычно это или SHA-1, или MD5 (RSA).
Issuer (Поставщик). Это характерное имя Х.500 выдавшего сертификат сервера, например cn=ca-l,o=company,l=phoenix,s=az,c=us,e=administrator@compa^ny.com.
Valid From (Действителен с). Дата выдачи сертификата.
Valid To (Действителен до). Важное поле, определяющее дату истечения срока действия сертификата. Срок действия сертификата определяет центр сертификации. Чем короче интервал, тем выше уровень безопасности, но от клиентов требуются дополнительные трудозатраты.
Subject (Субъект). Это характерное имя Х.500 владельца сертификата.
Public Key (Открытый ключ). В этой структуре данных хранится открытый ключ.
СА Version (Версия центра сертификации). Это количество возобновлений сертификата авторизации на определенном сервере поставщика.
Subject Key Identifier (Идентификатор ключа субъекта). Это важное поле содержит хеш SHA-1 поля Public Key (Открытый ключ). Это поле используется для идентификации содержимого и защищает открытый ключ от несанкционированного измненения.
Certificate Template (Шаблон сертификата). Это уникальное расширение Microsoft, в котором содержится имя шаблона, на основе которого центр сертификации генерировал сертификат.
Key Usage (Использование ключа). В этом поле содержится идентификатор объекта для предполагаемого применения ключа.
Authority Key Identifier (Идентификатор ключа поставщика). В этом поле содержатся хеш SHA-1 открытого ключа центра сертификации, а также характерное имя центра сертификации.
CRL Distribution Points (CDPs) (Точки распространения списков отозванных сертификатов). Содержит идентификаторы списков отозванных сертификатов. Списки указаны с помощью пути LDAP, URL или имени совместно используемого ресурса.
Authority Information Access (Доступ к информации о поставщике). Сообщает клиенту место расположения сертификата центра сертификации.
Thumbprint (Отпечаток). Хеш сертификата, который используется для положительной идентификации.
Thumbprint Algorithm (Алгоритм отпечатка). Алгоритм, который используется для получения хеша сертификата.
Документация на сертификаты
Содержимое и структура стандартного сертификата инфраструктуры открытого ключа определяется организацией ITU (International Trelecommunications Union) в стандарте Х.509. Последняя версия стандарта, Version 3, была определена в 1995 году.
Организация ITU тесно сотрудничает с IETF (Internet Engineering Task Force) с целью обеспечения соответствия стандартов современным требованиям. Структура и содержимое сертификата с точки зрения IETF описаны в документе RFC 2549, “Internet Х.509 Public Key Infrastructure Certificate and CRL Profile".
Применяемая сегодня технология открытого ключа изначально была разработана компанией RSA. Документация по технологии доступна на сайте www. rsalabs. com. Стандартная структура сертификата содержится в документе PKCS#7 (Р7В), “Cryptographic Message Syntax". Кроме этого, RSA стандартизирует механизмы обработки сертификатов на основе следующих документов.
PKCS#10, Certification Request Syntax. Это не сертификат как таковой, а способ получения сертификата от центра сертификации.
PKCS#11, Cryptographic Token Interface Syntax. Этот стандарт определяет безопасное хранение сертификатов в таких аппаратных средствах, как смарт-карты.
PKCS#12, Personal Information Exchange Syntax. Этот тип сертификата проектировался для безопасного хранения и передачи секретных ключей.
Локальные хранилища сертификатов
Сертификаты и ключи, полученные клиентами инфраструктуры открытого ключа, хранятся в различных местах на локальном клиенте в зависимости от функций сертификатов. Операционная система Windows абстрагирует физическое расположение сертификатов в виде
логических хранилищ, которые доступны в оснастке Certificates (Сертификаты), показанной на рис. 18.4. Предоставляются такие логические хранилища.
Personal (Личные). В этом хранилище содержатся сертификаты, выданные пользователю, компьютеру или любой службе, работающей на компьютере. Для просмотра сертификатов компьютера или служб необходимо зарегистрироваться с помощью учетной записи администратора. Физически эти сертификаты хранятся в системном реестре в каталоге HKLMXSoftware\Microsoft\SystemCertificates.
Trusted Root Certification Authorities (Доверенные корневые центры сертификации). Содержит сертификаты корневых центров сертификации и сертификаты внешних корневых центров сертификации, которые загружаются вместе с операционной системой или загружаются службой Windows Update. Физически сертификаты хранятся в системном реестре и в групповых политиках.
Intermediate Certification Authorities (Промежуточные центры сертификации). Содержит подчиненные центры сертификации (и внешние подчиненные центры), а также списки отозванных сертификатов.
Active Directory User Object (Объект пользователя Active Directory). Содержит сертификаты, которые были скопированы в Active Directory.
Requests (Запросы). Запросы сертификатов, отправленные центру сертификации. Копии запросов PKCS#10 хранятся в системном реестре.
7/9/2009 '7/9/2009 'i QAutoridadcertficadoradeleAsod... Autoridad Certficadora de laAsode... 6/28/2005,i QAutoridadcertficadoradeleAsod... Autoridad Certficadora de laAsode... 6/28/2005,.x ronsoie? - (Console Pool Certihcal es - Current User (third Party Root Certification Authorities'Xertific.x ronsoie? - (Console Pool Certihcal es - Current User (third Party Root Certification Authorities'XertificSAutoridad Certif icadora del Cole*.. ^Baltimore EZ by DST ®Ве1двсот E-Trust Primary CA О CW KT SeoreNet CA Class A ScW KT SeoreNet CA Class В OcW HKT SeoreNet CA Root @C&W KT SetureNet CA 5GC Root О CAI @Certipo$te Classe A Personne Ocertiposte ServeurSAutoridad Certif icadora del Cole*.. ^Baltimore EZ by DST ®Ве1двсот E-Trust Primary CA О CW KT SeoreNet CA Class A ScW KT SeoreNet CA Class В OcW HKT SeoreNet CA Root @C&W KT SetureNet CA 5GC Root О CAI @Certipo$te Classe A Personne Ocertiposte ServeurЛмг&2SIaba.ecom Root caЛмг&2SIaba.ecom Root caAutoridad Certficadora del Coiegio .,. Batanore EZ by DST Belgacom E-Trust Primary CA CW KT SeoreNet CA Class A CW KT SeoreNet CA Class В CW KT SeoreNet CA Root CW KT SeoreNet CA 5GC Root CAI Certiposte Classe A Personne Certiposte ServeurAutoridad Certficadora del Coiegio .,. Batanore EZ by DST Belgacom E-Trust Primary CA CW KT SeoreNet CA Class A CW KT SeoreNet CA Class В CW KT SeoreNet CA Root CW KT SeoreNet CA 5GC Root CAI Certiposte Classe A Personne Certiposte Serveurlautite.ABA.ECOM Root CAlautite.ABA.ECOM Root CAУ Console RootЙ 0 Certificates - Current UserВ У PersonalУ CertificatesВ У Trusted Root Certification AuthoritiesУ CertificatesУ Enterprise Trust@ У Intermedate Certification Authorities У Active Directory User Object У Trusted PittshersВ У Untrusted CertificatesУ Certificates£} У Third-Party Root Certification AuthoritiesУ Console RootЙ 0 Certificates - Current UserВ У PersonalУ CertificatesВ У Trusted Root Certification AuthoritiesУ CertificatesУ Enterprise Trust@ У Intermedate Certification Authorities У Active Directory User Object У Trusted PittshersВ У Untrusted CertificatesУ Certificates£} У Third-Party Root Certification Authorities6/29/200$ 7/3/20091/21/201C 10/16/20C 10/16/20C 10/16/201 10/16/20C 3/11/201$ 6/24/2016 6/24/2016 6/26/2016 6/26/2016 6/26/2016 7Wf7ntRJ6/29/200$ 7/3/20091/21/201C 10/16/20C 10/16/20C 10/16/201 10/16/20C 3/11/201$ 6/24/2016 6/24/2016 6/26/2016 6/26/2016 6/26/2016 7Wf7ntRJSoftware Publishing Certificate (Сертификаты публикации программного обеспечения). Компьютерные клиенты хранят здесь сертификаты Authenticode и другого программного обеспечения для работы с цифровыми подписями. Физически эти сертификаты хранятся в системном реестре.
7/9/2009 '
7/9/2009 '
i QAutoridadcertficadoradeleAsod... Autoridad Certficadora de laAsode... 6/28/2005,
i QAutoridadcertficadoradeleAsod... Autoridad Certficadora de laAsode... 6/28/2005,
.x ronsoie? - (Console Pool Certihcal es - Current User (third Party Root Certification Authorities'Xertific
.x ronsoie? - (Console Pool Certihcal es - Current User (third Party Root Certification Authorities'Xertific
SAutoridad Certif icadora del Cole*.. ^Baltimore EZ by DST ®Ве1двсот E-Trust Primary CA О CW KT SeoreNet CA Class A ScW KT SeoreNet CA Class В OcW HKT SeoreNet CA Root @C&W KT SetureNet CA 5GC Root О CAI @Certipo$te Classe A Personne Ocertiposte Serveur
SAutoridad Certif icadora del Cole*.. ^Baltimore EZ by DST ®Ве1двсот E-Trust Primary CA О CW KT SeoreNet CA Class A ScW KT SeoreNet CA Class В OcW HKT SeoreNet CA Root @C&W KT SetureNet CA 5GC Root О CAI @Certipo$te Classe A Personne Ocertiposte Serveur
Лмг&2
SIaba.ecom Root ca
Лмг&2
SIaba.ecom Root ca
Autoridad Certficadora del Coiegio .,. Batanore EZ by DST Belgacom E-Trust Primary CA CW KT SeoreNet CA Class A CW KT SeoreNet CA Class В CW KT SeoreNet CA Root CW KT SeoreNet CA 5GC Root CAI Certiposte Classe A Personne Certiposte Serveur
Autoridad Certficadora del Coiegio .,. Batanore EZ by DST Belgacom E-Trust Primary CA CW KT SeoreNet CA Class A CW KT SeoreNet CA Class В CW KT SeoreNet CA Root CW KT SeoreNet CA 5GC Root CAI Certiposte Classe A Personne Certiposte Serveur
lautite.
ABA.ECOM Root CA
lautite.
ABA.ECOM Root CA
У Console Root
Й 0 Certificates - Current User
В У Personal
У Certificates
В У Trusted Root Certification Authorities
У Certificates
У Enterprise Trust
@ У Intermedate Certification Authorities У Active Directory User Object У Trusted Pittshers
В У Untrusted Certificates
У Certificates
£} У Third-Party Root Certification Authorities
У Console Root
Й 0 Certificates - Current User
В У Personal
У Certificates
В У Trusted Root Certification Authorities
У Certificates
У Enterprise Trust
@ У Intermedate Certification Authorities У Active Directory User Object У Trusted Pittshers
В У Untrusted Certificates
У Certificates
£} У Third-Party Root Certification Authorities
6/29/200$ 7/3/2009
1/21/201C 10/16/20C 10/16/20C 10/16/201 10/16/20C 3/11/201$ 6/24/2016 6/24/2016 6/26/2016 6/26/2016 6/26/2016 7Wf7ntRJ
6/29/200$ 7/3/2009
1/21/201C 10/16/20C 10/16/20C 10/16/201 10/16/20C 3/11/201$ 6/24/2016 6/24/2016 6/26/2016 6/26/2016 6/26/2016 7Wf7ntRJ
В У Trusted PeopleУ CertificatesВ У Certificate Enrolment RequestsВ У Trusted PeopleУ CertificatesВ У Certificate Enrolment RequestsРис. 18.4. Хранилище сертификатов в оснастке Certificates (Сертификаты)Рис. 18.4. Хранилище сертификатов в оснастке Certificates (Сертификаты)Ai *лгИ** C/erHflrwinra AAi *лгИ** C/erHflrwinra AAiФогИя* Cwt# lr**r*AiФогИя* Cwt# lr**r*■ЧГ■ЧГQcertisign - Autoridade Certiflcador... Certisign - Autoridade Certficadora ... Qcertislgn - Autoridade Certficador... Certisign • Autoridade Certficadora... ^Certisign Autoridade Certficadora .,. Certisign Autoridade Certficadora A...
В У Trusted People
У Certificates
В У Certificate Enrolment Requests
В У Trusted People
У Certificates
В У Certificate Enrolment Requests
Рис. 18.4. Хранилище сертификатов в оснастке Certificates (Сертификаты)
Рис. 18.4. Хранилище сертификатов в оснастке Certificates (Сертификаты)
Ai *лгИ** C/erHflrwinra A
Ai *лгИ** C/erHflrwinra A
AiФогИя* Cwt# lr**r*
AiФогИя* Cwt# lr**r*
■ЧГ
■ЧГ
Центры сертификации
Локальный клиент инфраструктуры PKI генерирует собственные пары ключей откры- тый/секретный. Локальный клиент может отправить открытый ключ другому элементу структуры безопасности, но у внешних клиентов нет никакой причины доверять этому ключу, так как ничто не подтверждает источник сертификата.
Превращение самостоятельно сгенерированных открытых ключей в заслуживающий доверия объект требует вмешательства центра сертификации (Certification Authority — С А). Центр сертификации выступает в роли нотариуса. Он добавляет собственную подпись к открытому ключу клиента, подтверждая действительность сертификата как минимум для тех, кто доверяет этому центру сертификации.
Центр сертификации является исключительно простым способом заняться предпринимательством. Любой администратор сервера под управлением Windows Server 2003 или UNIX/ Linux может установить службы центра сертификации и начать выдавать сертификаты за деньги. Новый центр сертификации не поддерживается другими центрами сертификации, поэтому он подписывает собственный сертификат и становится корневым центром сертификации.
Как и в любом предприятии, для выживания клиенты должны знать о местонахождении центра сертификации и доверять его целостности. Компания Microsoft разделяет центры сертификации по расположению сертификатов центра сертификации.
Центр сертификации масштаба предприятия (Enterprise СА) хранит копию сертификата центра сертификации в базе данных Active Directory, откуда клиенты могут загрузить сертификат и сохранить его в локальном хранилище сертификатов.
Изолированный центр сертификации (Standalone С А) хранит копию сертификата центра сертификации в общей папке, которая доступна по адресу URL. Клиенты должны получить адрес центра сертификации, что позволит отправлять запросы сертификатов и получать сертификаты в определенном месте. (Центр сертификации масштаба предприятия также использует фиксированное хранилище для клиентов, которые не поддерживают поиск в базе данных Active Directory.)
Центр сертификации масштаба предприятия на основе Windows Server 2003 усложняет процесс выдачи сертификата благодаря использованию протокола Kerberos или NTLM для проверки личности конечного получателя. При этом для клиентов инфраструктуры открытого ключа обеспечивается уверенность в безопасном получении цифровой подписи.
Одновременное использование центров сертификации масштаба предприятия и изолированных центров сертификации позволяет создать инфраструктуру открытого ключа (PKI), обеспечивающую безопасность и масштабирование. При планировании развертывания центров сертификации помните, что имя сервера центра сертификации и его характерное имя из базы данных Active Directory включаются в выпускаемые сертификаты Х.509, поэтому центр сертификации не может быть переименован или удален из домена. Кроме этого, служба сертификации не поддерживает работу на кластерах, поэтому ее невозможно запустить на кластере Windows Server 2003 Enterprise Edition или Windows Server 2003 Datacenter Edition как ресурс в режиме защиты целостности кластера. Но при желании службу можно запустить на одном узле кластера.
Хранилище сертификатов центра сертификации
Сертификаты, выдаваемые центром сертификации, хранятся в базе данных Jet, которая называется <имя_сервера>. edb, в каталоге \Windows\System32\CertLog. В этой базе данных хранятся секретные ключи центра сертификации. Защищайте эту базу данных так же тщательно, как базу данных Active Directory. Если база данных центра сертификации потеряется, будет утрачена возможность аудита сертификатов, выданных центром сертификации. Резервное копирование этой базы данных выполняется в составе резервного копирования состояния системы.
Центры сертификации масштаба предприятия также хранят сертификаты в базе данных Active Directory в контейнере Public Key Services, расположенном в контейнере cn=Services, cn=Configuration,dc=<flOMeH>,dc=<KopeHb>.-В этом контейнере хранятся следующие подконтейнеры.
Enrollment Services. В этом контейнере хранятся объекты pkiEnrollmentServi.ee, соответствующие центрам сертификации, настроенным на выдачу сертификатов. В этих объектах хранятся копии сертификатов центра сертификации, характерное имя (DN) сертификата и шаблоны сертификатов, предоставляемые центром сертификации.
Certificate Templates. В этом контейнере хранятся объекты PKlCertif icateTemplates. Атрибуты объектов определяют имя, содержимое, идентификатор объекта и назначение типа сертификата, который создается на основе этого шаблона. Шаблоны сертификатов версии 2 в этом контейнере поддерживаются только в домене Windows Server 2003.
CRL Distribution Points (CDP). В этих контейнерах хранятся объекты CRLDistributionPoint для каждого центра сертификации. В атрибутах этих объектов хранятся базовые сертификаты списков отозванных сертификатов и все сертификаты различий списков, выданные соответствующим центром сертификации. Клиенты загружают эти сертификаты и используют для локальной проверки сертификатов.
Authority Information Access (AIA). В этом контейнере хранятся копии объектов CertificationAuthority, оригиналы которых хранятся в основном контейнере Certification Authority. Клиенты ссылаются на контейнер AIA при попытке получить сертификат в цепи доверия.
Key Recovery Agent (KRA). В этом контейнере хранятся объекты MsPKl- PrivateKeyRecoveryAgent для каждого центра сертификации. Эти объекты имеют атрибут Usercertificate, в котором перечислены секретные ключи, хранящиеся в центре сертификации, настроенном как центр регистрации (Registration Authority).
Object Identification (OID). В этом контейнере хранятся объекты MsPKi-Enterprise-oid, которые определяют имя и идентификатор объекта сертификата, выданного центром сертификации на предприятии. Идентификаторы объектов (OID) уникальны и назначаются типу сертификата центром сертификации.
Шаблоны сертификатов
Центр сертификации масштаба предприятия под управлением Windows Server 2003 использует шаблоны сертификатов (certificate templates) из базы данных Active Directory для генерации сертификатов пользователей, компьютеров и других центров сертификации. Изолированные центры сертификации не используют шаблоны сертификатов.
Шаблоны сертификатов управляются с помощью оснастки Certificate Templates (Шаблоны сертификатов). Проще всего для доступа к этой оснастке воспользоваться консолью Certification Authority (Центр сертификации). Щелкните правой кнопкой мыши на папке Certificate Templates (Шаблоны сертификатов) и выберите из контекстного меню команду Manage (Управление) (рис. 18.5).
Выполните двойной щелчок на шаблоне, чтобы открыть окно Properties (Свойства). В окне приведены назначение сертификатов, созданных на основе этого шаблона, а также расширения, которые будут включены в сертификат (рис. 18.6).
В оснастке показаны два типа шаблонов. Первый тип, отображенный цветом меньшей интенсивности, имеет версию 1. Эти шаблоны содержат фиксированную информацию, недоступную для модификации администратором. В операционной системе Windows 2000 используются шаблоны версии 1, поэтому они предоставляются для сохранения обратной совместимости. Второй тип, отображенный цветом нормальной интенсивности, имеет версию 2. В этих шаблонах содержатся настраиваемые поля, предоставляющие больше возможностей по проектированию и развертыванию инфраструктуры открытого ключа (PKI).
Имея доступ к шаблонам версии 2, центр сертификации Windows Server 2003 предоставляет следующие дополнительные возможности по сравнению с центром сертификации Windows 2000.
"'I Cony* Rr**"'I Cony* Rr**Рис. 18.5. Оснастка Certificate Templates (Шаблоны сертификатов), в которой показаны шаблоны версий 1 и 2, доступные для распространения центром сертификации под управлением Windows Server 2003Рис. 18.5. Оснастка Certificate Templates (Шаблоны сертификатов), в которой показаны шаблоны версий 1 и 2, доступные для распространения центром сертификации под управлением Windows Server 2003| AdministratorWindows 20003.1Notalowed| Authenticated SessionWindows 20002.1Notalowed(Basic EFSWindows 20002.1Notalowed|ca ExchangeWindows .NET Enterprise...106.0Not alowed(CEP EncryptionWidows 20003.1Notalowed(code SigningWindows 20002.1Notalowed(ComputerWindows 20004.1Notalowed(Cross Certification AuthorityWindows .NET Enterprise...105.0Notalowed(Directory Emal RepkationWindows .NET Enterprise ...115.0Alowed(Domain CofitrolerWidows 20003.1Not alowed(Domain Controler AuthenticationWindows .NET Enterprise ...110.0Alowed(EFS Recovery AgentWindows 20005.1Notalowed(Enrolment AgentWidows 20003.1Notalowed(Enrobnent Agent (Computer)Widows 20004.1Notalowed(Exchange Enroknent Agent (Offlhe r.... Windows20003.1Notalowed| AdministratorWindows 20003.1Notalowed| Authenticated SessionWindows 20002.1Notalowed(Basic EFSWindows 20002.1Notalowed|ca ExchangeWindows .NET Enterprise...106.0Not alowed(CEP EncryptionWidows 20003.1Notalowed(code SigningWindows 20002.1Notalowed(ComputerWindows 20004.1Notalowed(Cross Certification AuthorityWindows .NET Enterprise...105.0Notalowed(Directory Emal RepkationWindows .NET Enterprise ...115.0Alowed(Domain CofitrolerWidows 20003.1Not alowed(Domain Controler AuthenticationWindows .NET Enterprise ...110.0Alowed(EFS Recovery AgentWindows 20005.1Notalowed(Enrolment AgentWidows 20003.1Notalowed(Enrobnent Agent (Computer)Widows 20004.1Notalowed(Exchange Enroknent Agent (Offlhe r.... Windows20003.1NotalowedРис. 18.6. В свойствах шаблона сертификатов отображаются включенные расширения
"'I Cony* Rr**
"'I Cony* Rr**
Рис. 18.5. Оснастка Certificate Templates (Шаблоны сертификатов), в которой показаны шаблоны версий 1 и 2, доступные для распространения центром сертификации под управлением Windows Server 2003
Рис. 18.5. Оснастка Certificate Templates (Шаблоны сертификатов), в которой показаны шаблоны версий 1 и 2, доступные для распространения центром сертификации под управлением Windows Server 2003
| Administrator
Windows 2000
3.1
Notalowed
| Authenticated Session
Windows 2000
2.1
Notalowed
(Basic EFS
Windows 2000
2.1
Notalowed
|ca Exchange
Windows .NET Enterprise...
106.0
Not alowed
(CEP Encryption
Widows 2000
3.1
Notalowed
(code Signing
Windows 2000
2.1
Notalowed
(Computer
Windows 2000
4.1
Notalowed
(Cross Certification Authority
Windows .NET Enterprise...
105.0
Notalowed
(Directory Emal Repkation
Windows .NET Enterprise ...
115.0
Alowed
(Domain Cofitroler
Widows 2000
3.1
Not alowed
(Domain Controler Authentication
Windows .NET Enterprise ...
110.0
Alowed
(EFS Recovery Agent
Windows 2000
5.1
Notalowed
(Enrolment Agent
Widows 2000
3.1
Notalowed
(Enrobnent Agent (Computer)
Widows 2000
4.1
Notalowed
(Exchange Enroknent Agent (Offlhe r..
.. Windows2000
3.1
Notalowed
| Administrator
Windows 2000
3.1
Notalowed
| Authenticated Session
Windows 2000
2.1
Notalowed
(Basic EFS
Windows 2000
2.1
Notalowed
|ca Exchange
Windows .NET Enterprise...
106.0
Not alowed
(CEP Encryption
Widows 2000
3.1
Notalowed
(code Signing
Windows 2000
2.1
Notalowed
(Computer
Windows 2000
4.1
Notalowed
(Cross Certification Authority
Windows .NET Enterprise...
105.0
Notalowed
(Directory Emal Repkation
Windows .NET Enterprise ...
115.0
Alowed
(Domain Cofitroler
Widows 2000
3.1
Not alowed
(Domain Controler Authentication
Windows .NET Enterprise ...
110.0
Alowed
(EFS Recovery Agent
Windows 2000
5.1
Notalowed
(Enrolment Agent
Widows 2000
3.1
Notalowed
(Enrobnent Agent (Computer)
Widows 2000
4.1
Notalowed
(Exchange Enroknent Agent (Offlhe r..
.. Windows2000
3.1
Notalowed
Архивация и восстановление ключей. Центр сертификации может сохр>анять копии пар ключей, которые можно восстановить и повторно выдать пользователям, которые потеряли свои ключи. Центр сертификации предоставляет службу, которая называется Registration Authority (Центр регистрации). До выхода Windows Server 2003 единственным продуктом Windows, который предоставлял службы регистрации, была Exchange-служба KMS (Key Management Service). В следующей версии Exchange функции службы KMS будут переданы центру сертификации Windows Server 2003. Если на данный момент используется KMS из состава Exchange 5.5 или Exchange 2000, можно экспортировать секретные ключи центру сертификации Windows Server 2003. Для этого можно воспользоваться утилитой certutil, входящей в состав операционной системы Windows Server 2003.
Автоматическая запись пользователей. В операционной системе Windows 2000 поддерживалась настройка компьютеров на автоматическую запись на получение сертификата Computer. В операционной системе Windows Server 2003 пользователи могут быть настроены на автоматическую запись на получение сертификата User. Шаблон сертификата User поддерживает шифрованную файловую систему, цифровую подпись и аутентификацию клиента для IPSec, SSL и смарт-карт. Автоматическая запись пользователя доступна только при регистрации на рабочей станции Windows ХР или на сервере под управлением Windows Server 2003.
Квалифицированная субординация. Эта возможность позволяет центру сертификации ограничивать тип сертификатов, выдаваемых подчиненными центрами сертификации.
Отличия между списками отозванных сертификатов. В больших инфраструктурах открытого ключа могут использоваться очень длинные списки отозванных сертификатов. Увеличение размера списка приводит к снижению производительности, так как каждый клиент должен свериться со списком отозванных сертификатов при проверке нового сертификата. При использовании отличий между списками отозванных сертификатов (Delta CRLs) клиенту достаточно только загрузить изменения в базовый список отозванных сертификатов. Это позволяет значительно сократить объем данных, передаваемых по сети.
Требования Common Criteria. Стандарт ISO 15408 определяет инструкции по оценке системы безопасности. Институт NIST ссылается на стандарт 15408 как на требования Common Criteria (СС). На момент написания книги текущей версией является 2.1, которую можно загрузить с сайта по адресу csrc .nist.gov/cc/ccv20/ccv21ist.htm#CCV21. Правильно реализованная иерархия центров сертификации Windows Server 2003 соответствует требованиям Common Criteria.
Это великолепные возможности, которые значительно улучшили службы центров сертификации Windows, но есть и плохая новость: они доступны только в Windows Server 2003 Enterprise Edition и Windows Server 2003 Datacenter Edition. В операционной системе Windows Server 2003 Standard Edition поддерживаются только устаревшие шаблоны версии 1. Standard Edition не соответствует стандартам Common Criteria из-за недостатка возможностей управления на основе ролей. Кроме этого, для использования шаблонов версии 2 необходим домен Windows Server 2003, так как для использования этой версии шаблонов требуются компоненты схемы, недоступные в операционной системе Windows 2000.
Отзыв сертификатов
На центр сертификации возлагается еще одна задача, сопоставимая по важности с выдачей сертификатов. При необходимости центр сертификации может отозвать выданные сертификаты. Например, если злоумышленнику удалось скомпрометировать секретный ключ пользователя, можно отозвать сертификат открытого ключа пользователя, чтобы остальные пользователи больше не доверяли этому открытому ключу.
Центр сертификации поддерживает список отозванных сертификатов (Certificate Revocation List — CRL), в котором содержатся серийные номера отозванных сертификатов. Серийный номер представляет собой порядковое целое число, присвоенное сертификату центром сертификации.
Воспользуйтесь консолью Certificate Authority (Центр сертификации) для отзыва сертификата. Щелкните на сертификате правой кнопкой мыши и выберите из контекстного меню команду All Tasks'^ Revoke Certificate (Все задачи1^ Отозвать сертификат). В результате сертификат будет размещен в контейнере Revoked Certificates.
При отзыве сертификатов соблюдайте осторожность. Возможности отменить отзыв не существует. Все цифровые подписи, зашифрованные сообщения и другие результаты шифро-
вания, которые основаны на этом сертификате, оказываются недоступными при отзыве сертификата. Если отозвать сертификат подчиненного центра сертификации, становятся недействительными все сертификаты, выданные этим центром сертификации.
Список отозванных сертификатов
Сертификаты похожи на кредитные карточки.. Банк может отозвать карточку, но ее практически невозможно отобрать. Вместо этого банк добавляет карту в список отозванных карточек. В инфраструктуре отозванных карточек каждый продавец отвечает за проверку карточки с помощью звонка в клиринговый центр и сверки со списком отозванных карточек. В инфраструктуре открытого ключа каждый центр сертификации выпускает список отозванных сертификатов. Каждый элемент системы безопасности отвечает за проверку списка отозванных сертификатов при проверке действительности сертификата.
При создании списка отозванных сертификатов центр сертификации сохраняет копии списка в стратегических местах, где клиенты могут получить доступ к этому списку. Это так называемые точки распространения списка отозванных сертификатов (CRL Distribution Point — СВР). В сертификате центра сертификации указывается расположение точек распространения списков CRL (рис. 18.7). Если клиент не в состоянии найти список CRL по указанному адресу, клиент предполагает, что были отозваны все сертификаты, выданные данным центром сертификации.
Л*!!
бе*и ОМ* |teWea»»e»> |
НейqKey UsageSubject Key Identtfier Certificate Template Name Authority Key IdentifierНейqKey UsageSubject Key Identtfier Certificate Template Name Authority Key IdentifierEnhanced Key Usage Subject Akemabve NameEnhanced Key Usage Subject Akemabve Name1 Vai»Digtal Signature (80)38 4c 62 b9 05 d5 4e 40 68 51...EnrofcnentAgentKeyTD*e6ee9a 17 5f c9 18 4...1 Vai»Digtal Signature (80)38 4c 62 b9 05 d5 4e 40 68 51...EnrofcnentAgentKeyTD*e6ee9a 17 5f c9 18 4...^Authority Information Access [l]Authorlty Info Access; Acc..,^Authority Information Access [l]Authorlty Info Access; Acc..,Certificate Request Agent (1 „,, Other Name:Principal Name—A.,, wjCertificate Request Agent (1 „,, Other Name:Principal Name—A.,, wj
Ней
qKey Usage
Subject Key Identtfier Certificate Template Name Authority Key Identifier
Ней
qKey Usage
Subject Key Identtfier Certificate Template Name Authority Key Identifier
Enhanced Key Usage Subject Akemabve Name
Enhanced Key Usage Subject Akemabve Name
1 Vai»
Digtal Signature (80)
38 4c 62 b9 05 d5 4e 40 68 51...
EnrofcnentAgent
KeyTD*e6ee9a 17 5f c9 18 4...
1 Vai»
Digtal Signature (80)
38 4c 62 b9 05 d5 4e 40 68 51...
EnrofcnentAgent
KeyTD*e6ee9a 17 5f c9 18 4...
^Authority Information Access [l]Authorlty Info Access; Acc..,
^Authority Information Access [l]Authorlty Info Access; Acc..,
Certificate Request Agent (1 „,, Other Name:Principal Name—A.,, wj
Certificate Request Agent (1 „,, Other Name:Principal Name—A.,, wj
5 [1JCRL Distribution Point
Distribution Point Name:
Pul Name:
URL-ldap:///CN-Bigdog, CN-server 1 ,CN-CDP, CN-Public% 20Key%
| 20ServiceslCN*Services>CF^ConfigurationJDC"CompanyJDC>com?
| certifkateRevocationList?base?objectClass-cRLDistrtoutlonPoint
URL-http://serverLcompany.com/CertEnroB/Blgdog,crl
Puc. 18.7. Список CDP в сертификате центра сертификации, выданном центром сертификации под управлением Windows Server 2003
Центр сертификации предприятия под управлением Windows Server 2003 публикует список отозванных сертификатов в базе данных Active Directory в виде объекта CRLDistibution Point в контейнере сп=<имя_сервера>, cn=CDP, cn=Public Key Services, cn=Services, cn=Conf iguration, de=<домен>, дс=<корень>. Изолированный центр сертификации размещает список отозванных сертификатов на диске в каталоге % sys t emroo t %\sys t em3 2 \ certsrv\CertEnroll. Также эта папка является корнем одноименного виртуального Web- каталога.
Для просмотра содержимого списка отозванных сертификатов можно воспользоваться консолью Certification Authority (Центр сертификации). Щелкните правой кнопкой мыши на контейнере Revoked Certificates, выберите Properties (Свойства) и щелкните на кнопке View CRLs (Просмотреть список CRL) (рис. 18.8).
Для предотвращения постоянных запросов к центру сертификации клиенты кэшируют списки отозванных сертификатов на период публикации (publication period). По истечении этого периода клиент опять обращается к точке распространения списков отозванных сертификатов и загружает обновленную версию списка CRL. Если новая версия недоступна, клиент предполагает, что отозваны все сертификаты, выданные этим центром сертификации.
Клиент инфраструктуры открытого ключа необходимо настроить на проверку списка отозванных сертификатов при получении сертификата. Это не требование. Например, Outlook не выполняет автоматическую проверку сертификата, так как клиент может работать в автономном режиме. В таком случае проверка списка отозванных сертификатов должна выполняться вручную. .
Информация о точках распространения списков отозванных сертификатов предоставляется клиентам с помощью расширения сертификата центра сертификации.
Для модификации информации о точке распространения списка можно воспользоваться окном свойств центра сертификации. Активизируйте вкладку Х.509 Extensions (Расширения), как показано на рис. 18.9.
Bigdog Properties
Д1Л1
CrtfAcate Manager* Retention* | Auding | RecoveryAgenl* | Security I General | PoicyM«Me | ЕЛМогМе EAraem | storage | .
|cRL Distribution Port (CDP)^1 1
Spedy Icoabomtranwfciahueeicenebtop eeeririiwleievocalionfer■
(CRU\
C \WINDOXVS\Sy$tem32\CeftS(v\Ce<tEnfol\<CaName><CRLN«neSuffix idap7//CN-<CATruncatedName><CRLNameSLifix>,CN-<ServefShortNai http//<ServerDNSName>/CeftEnrofl/<CaName><CRLNameSuffbo<Delta
Г PiAMCRLtlo the location
Adi |
Г Indude nCPLi OrteueedittofridDeltoCRLtocatiorw
•‘ ViewDetetM. I'
- I
ОК}| Сюм! I
Г Indudeti the CDP extonwnd esued certficatet
Г Pitt* Date CRU to to location
or || Caned
Puc. 18.8. Сертификат центра сертификации отображает список отозванных сертификатов (CRL)
Рис. 18.9. Свойства центра сертификации, Значения точки распространения списка CRL, которые используются центром сертификации
Публикация списка отозванных сертификатов
Центр сертификации публикует список отозванных сертификатов (CRL) для клиентов. При этом копия списка размещается в точках распространения списка CRL (точки CPD), с которых клиент может загрузить этот список. Каждому списку CRL назначается интервал публикации (publication interval). Клиенты хранят в кэше список отозванных сертификатов на протяжении интервала публикации. Это минимизирует количество запросов к центру сертификации.
В операционной системе Windows Server 2003 поддерживается публикация списка отозванных сертификатов вручную. Для этого можно воспользоваться консолью Certification Authority (Центр сертификации). Щелкните правой кнопкой мыши на контейнере Revoked Certificates и выберите из контекстного меню команду All Tasks^Publish (Все задачи1^ Публикация). На рис. 18.10 показан пример окна Publish CRL (Публикация CRL).
Если назначить большой интервал истечения срока действия на центре сертификации, список отозванных сертификатов может стать очень большим. Самые последние документы RFC допускают публикацию отличий между списками CRL (Delta CRLs). В отличиях указываются изменения базового списка отозванных сертификатов. Серверы под управлением Windows Server 2003 Enterprise Edition и Windows Server 2003 Datacenter Edition поддерживают публикацию отличий между списками.
По умолчанию для списков отозванных сертификатов используется интервал публикации продолжительностью одна неделя. Для отличий между списками CRL интервал публикации составляет один день. Для изменения интервалов можно воспользоваться окном Properties (Свойства) для папки Revoked Certificates (рис. 18.11).
Рис. 18.10. В окне Publish CRL (Публикация CRL) можно выбрать публикацию полного списка или отличий между спискамиРис. 18.10. В окне Publish CRL (Публикация CRL) можно выбрать публикацию полного списка или отличий между спискамиРис. 18.11. Свойства папки Revoked Certificates, в которой устанавливаются интервалы публикации для списков отозванных сертификатов и отличий между спискамиРис. 18.11. Свойства папки Revoked Certificates, в которой устанавливаются интервалы публикации для списков отозванных сертификатов и отличий между списками
Рис. 18.10. В окне Publish CRL (Публикация CRL) можно выбрать публикацию полного списка или отличий между списками
Рис. 18.10. В окне Publish CRL (Публикация CRL) можно выбрать публикацию полного списка или отличий между списками
Рис. 18.11. Свойства папки Revoked Certificates, в которой устанавливаются интервалы публикации для списков отозванных сертификатов и отличий между списками
Рис. 18.11. Свойства папки Revoked Certificates, в которой устанавливаются интервалы публикации для списков отозванных сертификатов и отличий между списками
По истечении срока действия списка отозванных сертификатов клиенты откажутся принимать сертификаты, выданные этим центром сертификации, пока не будет опубликован новый список. Время от времени необходимо публиковать базовый список отозванных сертификатов с длительным интервалом публикации. После этого при необходимости нужно выпускать отличия между списками для обеспечения быстрого отзыва сертификата. Например, небольшая организация может публиковать базовый список отозванных сертификатов раз в квартал и отличия — каждую неделю. Большие организации с тысячами и десятками тысяч сертификатов могут выпускать базовый список CRL каждую неделю с публикацией отличий каждый день и публикацией вручную отличий при отзыве сертификата.
Получение списка отозванных сертификатов с помощью службы Windows Update
Компания Microsoft принимает сторонние списки отозванных сертификатов на сайте Windows Update по адресу windowsupdate .microsoft .com. Это позволяет производителям инфраструктуры открытого ключа распространять списки отозванных сертификатов без указания точки распространения списка в сертификате центра сертификации. На рис. 18.12 показан сайт Windows Update, на котором отображен список обновлений для программного обеспечения и драйверов.
3 Ми rosoft Windows I ipdnte Microsoft Internet Explorer3 Ми rosoft Windows I ipdnte Microsoft Internet Explorer1л - *.$,. ^f - / kГtees1л - *.$,. ^f - / kГtees:,com/en/defaL*.asp:,com/en/defaL*.asp1—:1—:H HAT JiW *jH HAT JiW *j
3 Ми rosoft Windows I ipdnte Microsoft Internet Explorer
3 Ми rosoft Windows I ipdnte Microsoft Internet Explorer
1л - *.$,. ^f - / k
Гtees
1л - *.$,. ^f - / k
Гtees
:,com/en/defaL*.asp
:,com/en/defaL*.asp
1—:
1—:
H HAT JiW *j
H HAT JiW *j
MicrosoftMicrosoftWindows Update
Microsoft
Microsoft
Home 1 Windows (Atslog • Office Update I Windows Update Worldwide
See AkoSee AkoWindows Update LdtalogWindows Update LdtalogQ Rid Microsoft Windows updates Q find haitdward driver iodates , Q Go to Download BasketQ Rid Microsoft Windows updates Q find haitdward driver iodates , Q Go to Download BasketOther Options□ View download historyOther Options□ View download history0 Find driver updates for hardware devices0 Find driver updates for hardware devicesa View download historya View download historyChoose from a variety of updates that you can cfctrbute over your network. This site is your one-stop location for Windows updates and enhancements, in adcftion to Mfcrosoft Windows Hardware Quality (WHQL) logo device drivers.
See Ako
See Ako
Windows Update Ldtalog
Windows Update Ldtalog
Q Rid Microsoft Windows updates Q find haitdward driver iodates , Q Go to Download Basket
Q Rid Microsoft Windows updates Q find haitdward driver iodates , Q Go to Download Basket
Other Options
□ View download history
Other Options
□ View download history
0 Find driver updates for hardware devices
0 Find driver updates for hardware devices
a View download history
a View download history
а Find updates for Microsoft Windows operating systems
Tmw&T
Puc. 18.12. Web-сайт Windows Update. Варианты обновления
Если пользователь получает сертификат и сертификат соответствующего центра сертификации не входит в список доверенных корневых центров, система обращается на сайт Windows Update для проверки копии сертификата и копирования списка отозванных сертификатов.
Все пакеты данных, загружаемые с сайта Windows Update, подписаны цифровой подписью компании Microsoft для подтверждения источника. Это защищает клиентов от перенаправления на поддельный сайт Windows Update и загрузки вредоносного кода.
Доверительные отношения между центрами сертификации
При обмене защищенными фрагментами данных (например, подписанными сообщениями электронной почты или зашифрованными дейтаграммами TCP) между двумя элементами инфраструктуры PKI эти элементы должны хранить копии открытых ключей друг друга для дешифровки данных или проверки подписи. Клиенты могут просто обменяться сертификатами открытого ключа, но как они могут быть уверены, что можно доверять чужому сертификату?
Например, представьте автора этой книги при покупке товаров в магазине мужской одежды. Допустим, я предоставляю Клерку подписанный мною документ о том, что я совершаю покупки для президента США, и указывающий каждому читателю документа принять мой чек. Клерк в праве рассмеяться и вызвать охрану.
Элементы PKI не доверяют чужим сертификатам или центрам сертификации по умолчанию. Чтобы сертификат считался надежным, элемент прежде всего должен доверять центру сертификации, выпустившему сертификат. Клиент инфраструктуры открытого ключа доверяет центру сертификации, если в локальном хранилище существует копия сертификата открытого ключа этого центра сертификации. Открытый ключ из этого сертификата используется для проверки цифровой подписи сертификата, предоставляемого конечными элементами системы безопасности.
В операционных системах Windows Server 2003 и Windows ХР не существует стандартного процесса для получения сертификата центра сертификации от доверенного центра сертификации. Компания Microsoft предоставляет в составе операционной системы несколько сертификатов от сторонних производителей PKI. Сертификаты могут быть загружены с сайта службы Windows Update. Для установки сертификатов можно воспользоваться мастером Signature Wizard при загрузке элемента управлении ActiveX или установке другого подписанного цифровой подписью программного обеспечения. В домене Active Directory сертификаты могут быть получены вместе с групповой политикой.
Для просмотра доверенных сертификатов, хранящихся на клиенте, можно воспользоваться оснасткой Certificates (Сертификаты). Логическое хранилище находится в разделе Trusted Root Certification Authorities^Certificates (Доверенные корневые центры сертификации1^ Сертификаты), как показано на рис. 18.13.
i I Console Roota®Certificates - Current Useri I Console Roota®Certificates - Current UserииQj Personal••@3 Certificatesrl Trusted Root Certtfication AuthoritiesLj Certifkate»Enterprise Trust•^ Intermedtote Certification Authorities Pl Active Directory User ObjectQj Personal••@3 Certificatesrl Trusted Root Certtfication AuthoritiesLj Certifkate»Enterprise Trust•^ Intermedtote Certification Authorities Pl Active Directory User ObjectBwidTe -E3 ABA.ECOM Root CABwidTe -E3 ABA.ECOM Root CAЛйЫЙЙ!ABA.ECOM Root CAЛйЫЙЙ!ABA.ECOM Root CA^Autorktod Certifkadora de la Asod... Autoridad Certficadora de la Asocial 5 ^Autoridad Certifkadora del Colegl... Autoridad Certifkadora del Colegio .^Autorktod Certifkadora de la Asod... Autoridad Certficadora de la Asocial 5 ^Autoridad Certifkadora del Colegl... Autoridad Certifkadora del Colegio .[^Baltimore EZ by OST(^Belgacom E-Trust Primary CA[^Baltimore EZ by OST(^Belgacom E-Trust Primary CABaltimore EZ by OST Belgacom E-Trust Primary CABaltimore EZ by OST Belgacom E-Trust Primary CA®- £2 Trusted Pub6sher$ j? Pl Untrusted Certificates®- £2 Trusted Pub6sher$ j? Pl Untrusted CertificatesQc&W НКТ SecureNet СА Class А Sc&W НКТ SecureNet СА Class ВQc&W НКТ SecureNet СА Class А Sc&W НКТ SecureNet СА Class ВC&W НКТ SecureNet СА Class А C&W НКТ SecureNet СА dess ВC&W НКТ SecureNet СА Class А C&W НКТ SecureNet СА dess В
i I Console Root
a®Certificates - Current User
i I Console Root
a®Certificates - Current User
и
и
Qj Personal
••@3 Certificates
rl Trusted Root Certtfication Authorities
Lj Certifkate»
Enterprise Trust
•^ Intermedtote Certification Authorities Pl Active Directory User Object
Qj Personal
••@3 Certificates
rl Trusted Root Certtfication Authorities
Lj Certifkate»
Enterprise Trust
•^ Intermedtote Certification Authorities Pl Active Directory User Object
BwidTe -
E3 ABA.ECOM Root CA
BwidTe -
E3 ABA.ECOM Root CA
ЛйЫЙЙ!
ABA.ECOM Root CA
ЛйЫЙЙ!
ABA.ECOM Root CA
^Autorktod Certifkadora de la Asod... Autoridad Certficadora de la Asocial 5 ^Autoridad Certifkadora del Colegl... Autoridad Certifkadora del Colegio .
^Autorktod Certifkadora de la Asod... Autoridad Certficadora de la Asocial 5 ^Autoridad Certifkadora del Colegl... Autoridad Certifkadora del Colegio .
[^Baltimore EZ by OST
(^Belgacom E-Trust Primary CA
[^Baltimore EZ by OST
(^Belgacom E-Trust Primary CA
Baltimore EZ by OST Belgacom E-Trust Primary CA
Baltimore EZ by OST Belgacom E-Trust Primary CA
®- £2 Trusted Pub6sher$ j? Pl Untrusted Certificates
®- £2 Trusted Pub6sher$ j? Pl Untrusted Certificates
Qc&W НКТ SecureNet СА Class А Sc&W НКТ SecureNet СА Class В
Qc&W НКТ SecureNet СА Class А Sc&W НКТ SecureNet СА Class В
C&W НКТ SecureNet СА Class А C&W НКТ SecureNet СА dess В
C&W НКТ SecureNet СА Class А C&W НКТ SecureNet СА dess В
Puc. 18.13. Доверенные ирнтры сертификации, показанные в оснастке Certificates (Сертификаты)
Особый принцип работы доверенных центров сертификации требует от пользователей особой осторожности при принятии сертификатов. Например, при загрузке элемента управления ActiveX или Java откроется окно Security Warning (Предупреждение безопасности), в котором пользователь уведомляется о цифровой подписи кода. Кроме этого, пользователю предоставляется возможность просмотра сертификата перед установкой элемента управления. Если пользователь выберет Always Trust Content From... (Всегда доверять содержимому от...), сертификат исходного центра сертификации будет добавлен в хранилище доверенных сертификатов.
Цифровая подпись не делает код безопасным для установки. Например, можно вспомнить инцидент в январе 2001 года, когда сторонняя компания от имени инженера компании Microsoft в качестве идентификатора получила у компании Verisign сертификат с именем Microsoft Corporation.
Ошибка быстро быда обнаружена, и сертификаты были добавлены в список отозванных сертификатов (CRL) от компании Verisign, но компания Verisign не включает в свои сертификаты информацию о СВР — координаты точек распространения списков CRL. Без СВР клиенты не могли проверить содержимое списка CRL и не блокировали прием поддельных сертификатов. Компании Microsoft пришлось воспользоваться другими способами распространения списков CRL, в которые были включены идентификаторы поддельных сертификатов.
Срок действия поддельных сертификатов уже истек,, но это только один урок. Цифровая безопасность требует и безопасности при выполнении тех или иных действий. Служба Windows Update предоставляет производителям возможность распространять списки отозванных сертификатов. Эти списки необходимо распространять среди клиентов с помощью Active Directory или благодаря предоставлению клиентам непосредственного доступа к сайту Windows Update.
Иерархия центров сертификации
Установленный корневой центр сертификации может выдавать сертификаты другим серверам сертификации, которые станут подчиненными (subordinate) центрами сертификации. Подчиненные центры сертификации могут выдавать сертификаты другим центрам сертификации, что позволит сформировать иерархию. Еще одним термином для обозначения такой иерархии является цепочка доверия (chain of trust).
Цепочка доверия добавляется в каждый сертификат, выданный любым центром сертификации. Для просмотра этой иерархии можно активизировать вкладку Certification Path (Путь сертификации) в окне свойств сертификата (рис. 18.14).
Для единственной организации с единственной инфраструктурой открытого ключа допустима показанная строгая иерархия. Для поддержки взаимодействия с внешними организациями в иерархию доверия придется включать корневые и подчиненные центры сертификации сторонних организаций, что позволит клиентам проверять действительность внешних сертификатов.
Для этого можно создать перекрестные доверительные отношения (cross-trust). В такой конфигурации центр сертификации из одной иерархии выдает сертификаты центрам сертификации из другой иерархии. В такой ситуации внешний центр сертификации становится подчиненным в собственной цепочке доверия. На рис. 18.15 показан пример иерархии с перекрестными доверительными отношениями.
ЛЯ1
General | Oetefc Certification Poth j
- CerttftatiohpiBth^*'^^'
i Bigdog‘■!
LittleDogi i
Certificate status:
I This certificate is OK.
Puc. 18.14. Оснастка Certificates (Сертификаты), в которой на вкладке Certification Path (Путь сертификации) показаны подчиненные центры сертификации
Subsidiary.com
Инфраструктура открытого ключа (PKI)
Сертификатцентрасертификации
Company.com
Инфраструктура открытого ключа (PKI)
Сертификатцентрасертификации
Корневой центр сертификации
Корневой центр сертификации
Кому выдан: Company_SubCA
Подчиненный центр сертификации
Кому выдан:
S ubs i di a ry_S ubC A
Кому выдан: Company_RootCA
Кем выдан: Company_RootCA
Автономный корень
Кому выдан:
Subsidiary_RootCA
Квм выдан:
Subsidiary_RootCA
Автономный корень
Квм выдан:
Company_SubCA
Кому выдан: Company_SubCA
Кем выдан: Подчиненный
Company_RootCA центр сертификации
Кому выдан:
Subsidiary_SubCA
Кем выдан:
Subsidiary_RootCA
Кем выдан:
Subsidiary_SubCA
Рис. 18.15. Иерархия с перекрестными доверительными отношениями
Создание перекрестных доверительных отношений может превратиться в сложную процедуру. Любой подчиненный центр сертификации в одной организации может создавать перекрестные доверительные отношения с подчиненными центрами сертификации из другой организации, что приводит к формированию сложной структуры доверительных отношений и может привести к созданию циклов в цепочках доверия.
Компании Microsoft и Entrust (компания Microsoft получила инфраструктуру открытого ключа от компании Entrust) однажды попытались упростить процесс установки доверительных отношений благодаря использованию списков перекрестных доверительных отношений (Cross-Trust Lists — CTL). Списки перекрестных доверительных отношений представляют собой подписанный набор хешей сертификатов центров сертификации и являются электронным аналогом закрытого клуба. Фактически список перекрестных доверительных отношений сообщает: “Этому центру сертификации можно доверять. Я его проверил и он знает пароль”. Клиенты, доверяющие центру сертификации, автоматически доверяют списку перекрестных доверительных отношений, выданному этим центром сертификации.
Но перекрестные доверительные отношения и списки таких отношений имеют один общий недостаток. Центру сертификации из другой организации предоставляется слишком много доверия. Элементы системы безопасности в организации будут доверять любому сертификату, выданному любым подчиненным центром сертификации ниже перекрестного доверительного отношения.
Для решения этой проблемы компания Microsoft совместно использует ограничения и расширения использования политик стандарта Х.509 для поддержки возможности, которая называется квалифицированное подчинение (Qualified Subordination — QS). При использовании квалифицированного подчинения администратор может ограничить предназначение сертификатов, получаемых от подчиненных центров сертификации с помощью перекрестных доверительных отношений, а также может ограничить цепочку доверия, чтобы доверие не распространялось на дополнительные подчиненные центры сертификации.
Проектирование доверительных отношений
На рис. 18.16 показана схема типичной иерархии доверия. При проектировании безопасной иерархии центров сертификации первый корневой центр сертификации должен быть изолированным корнем. Отключив корневой центр сертификации от сети, можно защитить инфраструктуру открытого ключа (PKI) от кражи секретного ключа корневого центра сертификации. Автономный корень используется исключительно для выдачи сертификатов подчиненным центрам сертификации.
Автономный корневой центр сертификации не может быть контроллером домена, так как контроллеры домена не могут неограниченное время находиться за пределами сети. Кроме этого, центр сертификации не может быть центром сертификации предприятия, так как у него нет доступа к Active Directory. Но этот сервер должен входить в домен, чтобы он мог проверить серверы, выбранные на роль подчиненных центров сертификации.
При создании изолированного корневого центра сертификации выберите установку вручную и задайте ключ длиной 4096 бит. Генерация такого ключа займет некоторое время, но обеспечит максимальную безопасность сертификатов, выданных корневым центром сертификации. Этот центр сертификации не будет использоваться для постоянного подписывания сертификатов, поэтому длинный ключ не приведет к снижению производительности.
Кроме этого, за пределами корневого центра сертификации необходимо сохранить список отозванных сертификатов (CRL). Не забывайте, что корневой центр сертификации будет отключен от сети, а клиенты нуждаются в точке распространения для проверки содержимого списка CRL. Выберите точку распространения списка CRL и измените путь в свойствах центра сертификации. Это справедливо и для путей AIA, которые указывают на фиксированный ресурс, а не на Active Directory. Разместите сертификаты на доступном ресурсе и установите путь AIA до выдачи сертификатов подчиненным центрам сертификации.
В иерархии непосредственно ниже автономного корня должен находиться центр сертификации масштаба предприятия (Enterprise Subordinate). Подчиненный центр сертификации предприятия сможет публиковать сертификат открытого ключа центра сертификации в Ас-' tive Directory. Для создания такого подчиненного центра необходимо временно включить корневой центр сертификации в сеть или сохранить запрос сертификата PKCS #10 в файле, перенести файл на автономный корень, сгенерировать сертификат центра сертификации и перенести сертификат обратно на подчиненный центр сертификации.
Для подчиненного центра сертификации стоит выбирать ключ длиной не меньше 2048 бит. Несколько материалов, опубликованных начиная с 2002 года, демонстрируют возможность проведения криптоаналитических атак на ключи RSA, которые позволяют сделать ключ длиной 1024 бит уязвимым в течение следующих нескольких лет. Комментарий Брюса Шнейера (Bruce Schneier) доступен по адресу www. counterpane. сот/crypto-gram-02 03 . html#6.
Поскольку изолированный корень не публикует свои сертификаты центра сертификации в Active Directory, то при установке подчиненного центра сертификации сертификаты необходимо запрашивать у изолированного корня с помощью утилит Web Enrollment. По этой причине на изолированном корне должны работать службы IIS и должна предоставляться общая Web-папка с элементами управления ActiveX, обеспечивающими возможность получения сертификатов через Web. Эта Web-папка, которая называется CertSrv, устанавливается по умолчанию при установке Certificate Services (Службы сертификатов).
На этом этапе создана двухуровневая иерархия с автономным корневым центром сертификации и одним или несколькими центрами сертификации на втором уровне. Эти центры сертификации используются для выдачи сертификатов. В крупных организациях центры сертификации должны использоваться исключительно для управления политиками, а для выдачи сертификатов должны быть установлены центры сертификации третьего уровня. Центры сертификации для управления политиками также могут быть отключены от сети, что обеспечивает дополнительную безопасность.
Автономный кореньАвтономный кореньПодчиненный центр сертификации масштаба предприятияПодчиненный центр сертификации масштаба предприятияКому выдан: Сотрапу_Ро1САКому выдан: Сотрапу_Ро1САКому выдан: Company_RootCAКому выдан: Company_RootCAИзолированный корневой центр сертификациИзолированный корневой центр сертификациКопии сертификатов и шаблоновКопии сертификатов и шаблоновКем выдан: Company_RootCAКем выдан: Company_RootCAКонтроллер домена под управлением Windows Server 2003Контроллер домена под управлением Windows Server 2003Кем выдан: Company_PolCAКем выдан: Company_PolCAЦентр сертификации для управления политикамиЦентр сертификации для управления политикамиКому выдан:Company_IssuingCAКому выдан:Company_IssuingCAКем выдан: Company_RootCAКем выдан: Company_RootCA
Автономный корень
Автономный корень
Подчиненный центр сертификации масштаба предприятия
Подчиненный центр сертификации масштаба предприятия
Кому выдан: Сотрапу_Ро1СА
Кому выдан: Сотрапу_Ро1СА
Кому выдан: Company_RootCA
Кому выдан: Company_RootCA
Изолированный корневой центр сертификаци
Изолированный корневой центр сертификаци
Копии сертификатов и шаблонов
Копии сертификатов и шаблонов
Кем выдан: Company_RootCA
Кем выдан: Company_RootCA
Контроллер домена под управлением Windows Server 2003
Контроллер домена под управлением Windows Server 2003
Кем выдан: Company_PolCA
Кем выдан: Company_PolCA
Центр сертификации для управления политиками
Центр сертификации для управления политиками
Кому выдан:
Company_IssuingCA
Кому выдан:
Company_IssuingCA
Кем выдан: Company_RootCA
Кем выдан: Company_RootCA
Центр сертификации, I выдающий сертификаты *1
Подчиненный центрсертификациимасштаба предприятия
Рис. 18.16. Иерархия доверительных отношений центров сертификации
Разрешения, необходимые для установки подчиненного центра сертификации масштаба предприятия
Для установки подчиненного центра сертификации масштаба предприятия в корневом домене леса необходимо быть членом группы Enterprise Admins (Администраторы предприятия) для леса или обладать привилегиями администратора домена в корневом домене леса.
При регистрации от имени учетной записи без административных привилегий в пределах леса будет предоставлена возможность только установки изолированного корня или изолированного подчиненного центра сертификации, даже если создание выполняется с консоли контроллера дочернего домена.
Необходимо регулярно создавать резервные копии каждого центра сертификации, чтобы отказ сервера не приводил к потере центра сертификации. Помните, что имя и принадлежность центра сертификации к домену изменить невозможно.
Установка центра сертификации
После завершения проектирования инфраструктуры открытого ключа (PKI) и выбора расположения центров сертификации пришло время установить службу сертификации на сервере, который будет изолированным корневым центром сертификации. Необходимая последовательность действий рассматривается в процедуре 18.1.
Процедура 18.1. Установка изолированного корневого центра сертификации
В Control Panel (Панель управления) запустите аплет Add/Remove Programs (Установка и удаление программ).
Щелкните на кнопке Add/Remove Windows Components (Установка и удаление компонентов Windows).
Выберите Certification Services. Будет выдано предупреждение о невозможности изменить имя компьютера и принадлежность домену. Щелкните на кнопке Yes (Да).
Щелкните на кнопке Next (Далее). Откроется окно СА Туре (Тип центра сертификации). Выберите переключатель Standalone Root СА (Изолированный корневой центр сертификации), как показано на рис. 18.17.
Щелкните на кнопке Next (Далее). Откроется окно СА Identifying Information (Идентифицирующая информация о центре сертификации), показанное на рис. 18.18.
Щелкните на кнопке Next (Далее). Откроется окно Cryptographic Key (Криптографический ключ). В процессе генерации ключа отображается индикатор выполнения.
После завершения генерации ключа откроется окно Certificate Database Settings (Параметры базы данных сертификатов). Разместите базу данных и файлы журнала на диске, который можно извлечь из компьютера. Их можно хранить и в разделе с операционной системой, если есть возможность отключить от сети диск или весь компьютер.
Щелкните на кнопке Next (Далее). Система временно остановит работу служб IIS и установит службу сертификации. После этого будет инициализирована база данных центра сертификации и будут перезапущены службы I IS.
После установки службы сертификатов можно воспользоваться консолью Certification Authority (Центр сертификации) для управления выдаваемыми сертификатами.
Windows romponents Wi?drdWindows romponents Wi?drd
Windows romponents Wi?drd
Windows romponents Wi?drd
CA Type
Select the type of CA you want to set up.
Windows Components WizardWindows Components WizardСенщг>пе»Ь*»й.jBigdod'ЕМпдй*>ж1м1гв«КсD C-company,D C-comСенщг>пе»Ь*»й.jBigdod'ЕМпдй*>ж1м1гв«КсD C-company,D C-com
Windows Components Wizard
Windows Components Wizard
Сенщг>пе»Ь*»й.
jBigdod'
ЕМпдй*>ж1м1гв«Кс
D C-company,D C-com
Сенщг>пе»Ь*»й.
jBigdod'
ЕМпдй*>ж1м1гв«Кс
D C-company,D C-com
Puc. 18.17. В окне CA Type (Тип центра сертификации) выбрано создание изолированного корневого центра сертификации
CA Identifying Information
Enter information to idertiy this CA
Puc. 18.18. Окно CA Identifying Information (Идентифицирующая информация о центре сертификации)
Проверки действительности
Клиенты проверяют действительность сертификатов, предоставляемых другими элементами инфраструктуры открытого ключа. Проверка действительности состоит из следующих операций.
Проверка формата. Клиент проверяет соответствие форматирования сертификата требованиям стандарта Х.509.
Проверка времени. Клиент проверяет дату истечения срока действия сертификата и сравнивает ее с текущей датой.
Проверка целостности. Каждый сертификат содержит хеш содержимого сертификата, зашифрованный секретным ключом сертификата. В стандарте Х.509 эта структура назы-
вается подписью (signature). Компания Microsoft (и компания Entrust) называет эту структуру отпечатком (thumbprint). Эти термины являются синонимами. Клиент выполняет проверку целостности, дешифруя подпись с помощью открытого ключа центра сертификации, полученного из сертификата доверенного центра сертификации. После этого клиент хеширует сертификат с помощью того же алгоритма, который использовался центром сертификации. Если результаты совпадают, целостность сертификации подтверждается.
Проверка иерархии центров сертификации. Если клиент не доверяет непосредственно центру сертификации, подписавшему сертификат, он проверяет цепочку доверия на каждом центре сертификации в иерархии доверия.
■ Проверка на отзыв. Клиент обращается к Active Directory, Web-сайту или сетевому ресурсу для проверки отзыва сертификата корневого центра сертификации или подчиненного центра сертификации в списке доверия либо для проверки отзыва сертификата самого конечного элемента структуры PKI.
Из этих проверок самой сложной является проверка иерархии. Эта проверка требует от клиента создания цепочки доверия, которая достигает корневого центра сертификации. Самым простым способом создания такой цепочки является использование ссылок на два элемента сертификата, Authority Key Identifier (AKI — идентификатор ключа издателя сертификата) и Subject Key Identifier (SKI — идентификатор ключа владельца сертификата).
В поле AKI содержатся три фрагмента информации об издателе сертификата.
Имя выдавшего сертификат. Это характерное имя Х.500 или основное имя пользователя (UPN) центра сертификации, выдавшего сертификат.
KeylD. Это хеш SHA-1 открытого ключа центра сертификации. Он выступает в роли перекрестной ссылки, которая уникально идентифицирует сертификат среди других сертификатов, выданных этим центром сертификации данному элементу структуры PKI.
Серийный номер сертификата. Это порядковый номер (обычно целое число), присвоенный сертификату центром сертификации.
В поле SKI определяется владелец, которому был выдан сертификат. Обычно в этом расширении хранится только KeylD для открытого ключа сертификата, хотя может храниться и другая идентифицирующая информация.
Authority Information Access (AIA)
При проверке действительности клиенты должны найти копию сертификата для каждого центра сертификации в цепочке доверия, чтобы проверить цифровую подпись. Клиенты Windows сначала проверяют локальное хранилище сертификатов. Если сертификат отсутствует в локальном хранилище, они ссылаются на расширение в сертификате, которое называется Authority Information Access (AIA) (рис. 18.19).
Расширение AIA имеет форму URL-адреса HTTP, сайта FTP, контейнера LDAP или общего ресурса, на котором может быть получен сертификат центра сертификации. Ниже приведен пример такой записи:
[1]Authority Info Access1
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2) Alternative Name:
URL=ldap:///CN=CA-1,CN=AIA,CN=Public%20Key%20Services,
1>CN=Services,CN=Conf iguration,DC=Company,DC=com
DC=net?cACertificate?base/objectclass=certificationAuthority [2]Authority Info Access
Access Method=Certification Authority Issuer(1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://serveri.company.com/CertEnroll/
serveri.company.com_CA-l.crt
По умолчанию центр сертификации предприятия хранит копии сертификата центра сертификации в общей папке CertEnroll и в базе данных Active Directory в контейнере cn=AIA,cn=Public Key Services,cn=Services,cn=Configuration,йс=<имя^цомена>, дс-<корено>. Папка CertEnroll является основой для виртуальной Web-папки, чтобы клиенты могли использовать протокол HTTP для получения копии сертификата.
CertificateCertificateJtui
Certificate
Certificate
General Det* | certf cation Path |
Show: |<AJI> "
*y SMIME CapeMties ^Subject Key Identifier ^^Certificate ТепфюСе Nanie ^Authority Key Identifier ImCRL Distribution Points§g Enhanced Key Usage §5 Subject Aternative Name*y SMIME CapeMties ^Subject Key Identifier ^^Certificate ТепфюСе Nanie ^Authority Key Identifier ImCRL Distribution Points§g Enhanced Key Usage §5 Subject Aternative Name[1JSMIME Capab*y: Object I.,. e7 6e 9a 92 94 dd 97 f5 21 ca .., AdministratorKeyID-59 6a 2e a5 7b 23 be 8,.. [1JCRL Distribution Point: Distr,..Microsoft Trust List Sibling (1.... Other NameiPrincpal Name-A,..[1JSMIME Capab*y: Object I.,. e7 6e 9a 92 94 dd 97 f5 21 ca .., AdministratorKeyID-59 6a 2e a5 7b 23 be 8,.. [1JCRL Distribution Point: Distr,..Microsoft Trust List Sibling (1.... Other NameiPrincpal Name-A,..
*y SMIME CapeMties ^Subject Key Identifier ^^Certificate ТепфюСе Nanie ^Authority Key Identifier ImCRL Distribution Points
§g Enhanced Key Usage §5 Subject Aternative Name
*y SMIME CapeMties ^Subject Key Identifier ^^Certificate ТепфюСе Nanie ^Authority Key Identifier ImCRL Distribution Points
§g Enhanced Key Usage §5 Subject Aternative Name
[1JSMIME Capab*y: Object I.,. e7 6e 9a 92 94 dd 97 f5 21 ca .., Administrator
KeyID-59 6a 2e a5 7b 23 be 8,.. [1JCRL Distribution Point: Distr,..
Microsoft Trust List Sibling (1.... Other NameiPrincpal Name-A,..
[1JSMIME Capab*y: Object I.,. e7 6e 9a 92 94 dd 97 f5 21 ca .., Administrator
KeyID-59 6a 2e a5 7b 23 be 8,.. [1JCRL Distribution Point: Distr,..
Microsoft Trust List Sibling (1.... Other NameiPrincpal Name-A,..
Ж ;i]Authority Info Access*
Access Method—Certfkation Authority Issuer (1.3.6.1.5.5.7,48,2;
Alternative Name:
URL-ldap:///CN-UttleDog,CN-AIA,CN-Pubk%20Key%
§1 205ervkes, CN-Services, CN-Configuration, DC-company, DC-com?
Ж :ACertffkate?base?objectClass-certifkationAuthority—
1 [2]Authority Info Access
Access Method-CertfkationAuthorty Issuer (1,3.6.1.5.5.7.48.2) Alternative Name:
Ede Properties... | Cepytoflk- |
Puc. 18.19. Содержимое расширения AIA дляцентра сертификации масштаба предприятия
После отключения центра сертификации от сети расширение AIA должно содержать адрес URL, указывающий на другой сервер. Для инфраструктур PKI, которые включают пользователей за пределами домена, расширение AIA обычно указывает на Web-сервер в пределах демилитаризованной зоны.
Протокол OCSP
Одной из проблем классической проверки действительности сертификата является необходимость хранения копий сертификатов для всех доверенных центров сертификации и промежуточных центров сертификации вместе со списками отозванных сертификатов и отличиями между списками.
Для упрощения инфраструктуры открытого ключа можно перенести процесс проверки действительности сертификата на сервер. Клиент инфраструктуры открытого ключа (PKI) сможет запросить у сервера проверку сертификата, а сервер вернет подписанный цифровой подписью ответ о действительности или недействительности сертификата.
Такой механизм проверки на сервере является одной из служб протокола OCSP (Online Certificate Status Protocol — протокол оперативного определения статуса сертификата). Этот протокол документирован в документе Internet Draft draft-ietf-pkix-ocspv2-02 .txt, “Online Certificate Status Protocol, version 2”. Протокол OCSP определяет три службы.
Интерактивное состояние отзыва. Эта проверка заменяет поиск в списках отозванных сертификатов запросом к серверу OCSP. Сервер должен хранить копию списка отозванных сертификатов, поэтому этот протокол не отменяет назначения точек распространения в расширениях сертификата. Просто задача проверки передается ограниченному количеству серверов.
Делегированная проверка пути. Одна из более сложных задач клиента инфраструктуры открытого ключа заключается в проверке пути сертификата. В полносвязной инфраструктуре открытого ключа определение всех возможных цепочек для проверки действительности сертификата может занять значительное время. Сервер выполняет эту операцию однажды, сохраняя результат и ускоряя ответы на запросы клиентов.
Делегированное обнаружение пути. Это подмножество делегированной проверки пути. Сервер просто возвращает путь, а проверка действительности выполняется клиентом самостоятельно.
Отсутствие документов RFC указывает на новизну протокола OCSP. В операционной системе Windows Server 2003 поддерживается тестовая версия стандарта.
Подача заявок на сертификаты
Центр сертификации работает в соответствии с принципами бюрократии. Сертификаты не выдаются кому попало. Клиент должен передать запрос на получение сертификата в специальном формате для проверки личности клиента перед внесением открытого ключа клиента в подписанный сертификат. Этот процесс называется подачей заявки (enrollment).
Самым популярным форматом отправки запросов на получение сертификата является PKCS # 10 Certification Request. Дополнительная информация о содержимом запроса приводится в документе RFC 2986, “PKCS #10: Certification Request Syntax Verstion 1.7”. (Соответствующая документация также доступна на сайте RSA по адресу www. rsalabs. com.) Запрос сертификата PKCS #10 содержит следующую информацию.
Открытый ключ клиента. Этот ключ должен быть подписан центром сертификации. Передача этого ключа открытым текстом не является проблемой, так как открытый ключ именно для этого и предназначен.
Характерное имя клиента. Это имя клиента в формате Х.500 или LDAP. Например, характерное имя доверенной сети Verisign выглядит, как OU=VeriSign Trust Network, OU = 1998 VeriSign, Inc. - For authorized use only, OU = Class 1 Public Primary Certification Authority - G2, 0 = VeriSign, Inc., C = US. Примером характерного имени пользователя Active Directory может служить cn=Jane User,ou=Phoenix,dc=Company,dc=com.
Цифровая подпись. Это хеш запроса сертификата, зашифрованный секретным ключом клиента. Сам по себе секретный ключ никогда не передается по сети. Он остается в безопасности — в локальном профиле пользователя.
Метод хеширования. Это алгоритм хеширования, который использовался для создания цифровой подписи. В инфраструктуре открытого ключа от компании Microsoft используются алгоритмы SHA-1 и MD5.
При получении запроса сертификата PKCS #10 центр сертификации использует открытый ключ из запроса для дешифровки цифровой подписи запроса. (Что-то зашифрованное одним ключом из пары может быть расшифровано другим ключом.) Если дешифровка оказывается неудачной, центр сертификации предполагает, что злоумышленник изменил запрос в процессе его передачи. В таком случае запрос отбрасывается.
. Если центру сертификации удается дешифровать цифровую подпись, запрос хешируется с помощью алгоритма, указанного клиентом. Если полученный в результате хеш совпадает с хешем в расшифрованной подписи, личность пользователя считается подтвержденной.
После этого центр сертификации подписывает открытый ключ пользователя и вносит его в сертификат Х.509, который возвращается клиенту. Клиент распространяет копии сертификата среди других элементов инфраструктуры PKI. После этого распространенный ключ будет использоваться при шифрорании передаваемых данных. Другие участники при получении сертификата Х.509 будут проверять его действительность с помощью цифррвой подписи центра сертификации.
Сообщения управления сертификатами поверх CMS (СМС)
Длительное время компания RSA Security обладала правами на технологию PKCS, что заставило рабочую группу PKIX в составе IETF разработать отдельный стандарт инфраструктуры открытого ключа, который называется СМР (Certificate Management Protocol — протокол управления сертификатами). Этот стандарт описывается в двух документах RFC: RFC 2510, “Internet Х.509 Public Key Infrastructure Certificate Management Protocols”, и RFC 2511, “Internet X.509 Certificate Request Message Format”.
Протокол управления сертификатами намного сложнее метода обмена ключами RSA, но он предоставляет больше возможностей и исправляет несколько гипотетических ошибок. Главным преимуществом протокола СМР с точки зрения администратора является поддержка непосредственного доступа в Registration Authority (Центр регистрации), в котором в безопасной форме хранятся копии секретных ключей. В случае, если пользователь потеряет секретный ключ, ключ можно выдать еще раз.
С точки зрения специалиста, протокол СМР лучше RSA из-за природы протоколов инфраструктуры открытого ключа. Протокол СМР использует синтаксис криптографических сообщений (Cryptographic Message Syntax — CMS), описанный в документе RFC 2530, “Cryptographic Message Syntax”.
Рас Хозли (Russ Housley) и Тим Полк (Tim Polk), разработавшие стандарт CMS и протокол управления сертификатами СМР, предложили новый протокол, который называется со- общения управления сертификатами на основе синтаксиса криптографических сообщений (Certificate Management Messages over CMS — CMC) и в котором комбинируются лучшие возможности RSA и протокола СМР с целью создания гибридного решения для инфраструктуры открытого ключа. Они документировали этот протокол и описали основные компоненты инфраструктуры открытого ключа в документе RFC 2797 и замечательной книге, которая называется Planning far PKI.
В операционных системах Windows Server 2003 Enterprise Edition и Windows Server 2003 Datacenter Edition поддерживается подача заявок CMC для клиентов Windows ХР и Windows Server 2003, а также подача заявок PKCS #10 для клиентов Windows 2000 и других клиентов более старых версий. В операционной системе Windows Server 2003 Standard Edition поддерживается только подача заявок по методу PKCS #10.
Функциональное описание подачи заявки
Пользователи и компьютеры под управлением Windows Server 2003 и Windows ХР автоматически записываются на получение сертификата при регистрации в домене, содержащем центр сертификации масштаба предприятия под управлением Windows Server 2003. Пользователи Windows 2000 прозрачным образом записываются на получение сертификата EFS при шифровании файла в домене с центром сертификации масштаба предприятия. Кроме этого,
для подачи заявок на сертификаты клиенты могут использовать оснастку ММС, которая называется Certificates (Сертификаты). Клиенты, не имеющие непосредственного доступа к центру сертификации, могут подать заявку на получение сертификата через Web-страницу. Все эти методы используют элемент управления ActiveX, который называется Xenroll. dll. Ниже приводится подробное описание транзакции.
Автоматическая подача заявки на получение сертификата
Компьютеры и пользователи в домене Windows Server 2003 автоматически получают сертификаты с помощью групповых политик. Настройка выполняется с помощью групповой политики Automatic Certificate Request Settings, которая расположена в разделе Computer Configuration^Windows Settings'* Security Settings1*Public Key Policies (Конфигурация компьютера1* Параметры Windows* Параметры безопасности1* Политики открытого ключа).
Возможность автоматической подачи заявки на получение сертификата контролируется объектом Autoenrollment Settings в корне папки Public Key Policies. На рис. 18.20 показано окно Properties (Свойства) для этой политики.
Рис. 1820. Свойства политики Autoenrollment Settings (Параметры автоматической подачи заявки)
Основным переключателем политики является Enroll Certificates Automatically (Автоматически подавать заявку на получение сертификата). При желании можно указать автоматическое возобновление и отзыв сертификатов. Кроме этого, можно выбрать автоматическое обновление типов шаблонов сертификатов. Автоматическое обновление типа шаблона важно в смешанной среде, так как клиенты Windows 2000 не могут автоматически получать сертификаты, созданные на основе шаблонов версии 2.
Заявка на получение сертификата с помощью оснастки Certificates (Сертификаты)■
Клиенты Windows 2000 могут записываться на получение сертификата версии 1 с помощью оснастки Certificates (Сертификаты).‘Клиенты Windows ХР и Windows Server 2003 мо- ' гут подавать заявки на получение сертификатов версии 2 непосредственно с помощью оснастки Certificates.,
Например, можно воспользоваться оснасткой Certificates для получения сертификата Administrator (Администратор), который позволит выполнять следующие операции:
создавать цифровую подпись для списка доверия сертификатов;
шифровать данные;
шифровать сообщения электронной почты;
создавать цифровую подпись для сообщений.
Для запроса нового сертификата щелкните правой кнопкой мыши на пиктограмме Personal^Certificates (Личные^Сертификаты) в оснастке Certificates (Сертификаты) и выберите из контекстного меню команду Request New Certificate (Запросить новый сертификат). Откроется мастер запроса сертификата (Certificate Request Wizard). Выберите тип сертификата из списка (рис. 18.21).
После получения сертификата его копия будет сохранена локально в пользовательском разделе системного реестра. Еще одна копия будет сохранена в пользовательском объекте в Active Directory.
iLcrtihcate Request Wizard
Certificate Туряt
A csitficate type content (Heat prepeitto tor cortflcateaL
Sebet ecertificate type for your lequuk. toucenactees or* <etfleN»twie»i< you have ponwokra tor ««I that ага «нйЫе №>■ e buatod CA.
Certificate types,
:Basic EF5
■-: EF5 Recovery Agent
Bl Enrollment Agent User
To select a cryptoy aphr service provider «id a CA, select Advanced.
Г" Advanced
сваек | Net* ||
Puc. 18.21. Мастер запроса сертификата (Certificate Request Wizard) отображает список доступных сертификатов
Если при загрузке оснастки Certificates (Сертификаты) сместить фокус на компьютер, а не на пользователя, можно запросить сертификат контроллера домена и сертификат контроллера домена для репликации по электронной почте, которые необходимы для использования протокола SMTP для репликации между сайтами.
Подача заявки через Web
Любой клиент может запросить сертификат у центра сертификации, воспользовавшись Web-браузером. Для этого на центре сертификации должна работать служба IIS и должна быть активизирована возможность запросов через Web. При этом будет установлен набор виртуальных каталогов, которые используются клиентами для загрузки элемента управления ActiveX, Xen^oll, позволяющего подать заявку на получение сертификатов. Процесс записи управляется с помощью классического протокола RSA PKCS #10 или стандартного протокола PKIX СМС.
При подаче заявки через Web используется виртуальный каталог CertSrv, который указывает на каталог Windows\Systems2\CertSrv. В этом каталоге хранятся ASP-страницы и другие файлы поддержки, помогающие получить сертификат и копии сертификатов центра сертификации. Запросы на получение сертификата и выданные сертификаты безопасно хранятся в базе данных центра сертификации.
Еще два виртуальных каталога используются для поддержки подачи заявки на получение сертификата: CertEnroll и CertControl. В каталоге CertEnroll хранится список отозванных сертификатов — подписанный список более недействительных сертификатов, выданных центром сертификации. В каталоге CertControl хранятся элементы управления ActiveX, которые используются для записи клиентов Web.
Сервер центра сертификации масштаба предприятия требует от пользователей предоставления доменных регистрационных данных для подключения к сайту CertSrv. Изолированные серверы поддерживают анонимные запросы, если их специально не настроить на запрет таких запросов.
Параметр Advanced в процессе подачи заявки через Web позволяет отправить существующий сертификат на сертификацию или запросить сертификат для смарт-карты. Для получения сертификата от Web-сервера выполните последовательность действий, описанную в процедуре 18.2.
Процедура 18.2. Отправка заявки на получение сертификата через Web
Подключитесь к центру сертификации с помощью обозревателя Internet Explorer 5.0 или более поздней версии. Воспользуйтесь адресом URL http: //<имя_сервера>/certsrv. Будет выдана приветственная страница, на которой отображаются параметры запроса (рис. 18.22). Имя сервера центра сертификации отображается на зеленом поле в верхней части страницы.
* * *» «НИИ* »йг* * *» «НИИ* »йгО** * О ' А 1Й Jvl^NNWwhttp://server 1/certsrv/О** * О ' А 1Й Jvl^NNWwhttp://server 1/certsrv/Эе.Эе.
* * *» «НИИ* »йг
* * *» «НИИ* »йг
О** * О ' А 1Й Jvl^N
NWwhttp://server 1/certsrv/
О** * О ' А 1Й Jvl^N
NWwhttp://server 1/certsrv/
Эе.
Эе.
HomeHomeMicrosoft С
Home
Home
Welcome
Use this Web site to request a certificate for your Web browser, e-mail client, or other program. By using a certificate, you can verify your identity to people you communicate with over the Web, sign and encrypt messages, and, depending upon the type of certificate you request, perform other security tasks.
You can also use this Web site to download a certificate authority (CA) certificate, certificate chain, or certificate revocation list (CRL), or to view the status of a pending request.
For more information about Certificate Services, see Certificate Services Documentation.
Select a talk:
Request a certificate
View the status of a pending certificate request
Download a CA certificate, certificate chain, or CRL
Puc. 18.22. Страница приветствия при подаче заявки на получение сертификата
Щелкните на ссылке Request A Certificate (Запросить сертификат). На следующей странице будет показан один вариант сертификата, User Certificate (Пользовательский сертификат). Щелчок на кнопке Advanced Certificate Request (Расширенный запрос сертификата), позволяет запросить сертификат для смарт-карты.
Щелкните на ссылке User Certificate (Пользовательский сертификат). Откроется страница User Certificate — Identifying Information (Пользовательский сертификат — Идентифицирующая информация).
Щелкните на кнопке Submit (Отправить). Центр сертификации обработает запрос, и будет отображена страница Certificate Issued (Сертификат выдан).
Щелкните на кнопке Install This Certificate (Установить этот сертификат). После обработки заявки на получение сертификата откроется страница Certificate Installed (Сертификат установлен). Для проверки наличия сертификата можно воспользоваться оснасткой Certificates (Сертификаты).
Архивация и восстановление ключей
' Любой администратор гостиницы согласится, что людям нельзя доверять ключи. Ключи теряются, стираются, попадают под утюг или просто остаются не с той стороны двери с автоматическим замком.
Создание центрального хранилища для замены ключей является сложным решением. Если это хранилище будет скомпрометировано, вся инфраструктура открытого ключа станет бесполезной. На самом деле еще хуже, чем бесполезной, поскольку будет выглядеть надежной, пока злоумышленник будет просматривать зашифрованные файлы и сообщения электронной почты.
Но возможность обеспечения постоянного доступа к данным несмотря на ошибки пользователей делает безопасное хранилище ключей очень привлекательной возможностью. В стандартной инфраструктуре открытого ключа такая возможность называется центр регистрации (Registration Authority — RA). На протяжении многих лет компания Microsoft предоставляла центр регистрации для пользователей Exchange в форме службы управления ключами (Key Management Service — KMS). Эта служба хранила копии ключей пользователей для шифрования электронной почты. При необходимости эти ключи могли выдаваться повторно.
Служба KMS в Exchange 2000 является надстройкой центра сертификации Windows 2000. В операционной системе Windows Server 2003 компания Microsoft предоставляет центр регистрации в составе центра сертификации. В следующей версии Exchange служба KMS будет отсутствовать и будет использоваться Registration Authority из состава операционной системы Windows Server 2003. На самом деле даже существует утилита миграции, которая позволяет перенести базу данных KMS в центр сертификации Windows Server 2003.
Для повторного предоставления центр сертификации (СА) способен хранить только ключи шифрования. Ключи цифровой подписи не могут выдаваться повторно, так как это противоречит правилу невозможности отказа, предоставляемой цифровой подписью. Если хранить секретные ключи цифровых подписей, отправитель, обвиненный в отправке вредоносного сообщения, может утверждать, что это администратор получил доступ к хранилищу ключей и отправил сообщение.
Восстановление ключа требует использования шаблона сертификата уровня предприятия, который называется агентом восстановления ключей (Key Recovery Agent). По этой причине восстановление ключей не поддерживается на изолированных центрах сертификации. Только центр сертификации масштаба предприятия имеет доступ к шаблонам. Кроме этого, по умолчанию только группы Domain Admins (Администраторы домена) и Enterprise Admins (Администраторы предприятия) имеют доступ к шаблону Key Recovery Agent. Это определяется правами доступа в базе данных Active Directory. Для доступа к шаблону можно воспользоваться консолью Active Directory — Users and Computers (Active Directory — пользователи и компьютеры). Для доступа к шаблону воспользуйтесь командой View=> Services Node (Вид^Узлы служб). Объект шаблона расположен в разделе Services^Public Key Services^ Certificate Templates (Службы1^ Службы открытого ключам Шаблоны сертификатов).
Измените разрешения шаблона, чтобы и члены других групп с правами администраторов получили возможность выдавать Сертификаты восстановления ключа (Key Recovery).
По умолчанию восстановление ключей отключено. На самом деле активизация восстановления ключей является достаточно сложным процессом, намного сложнее, чем он мог бы быть. Рассмотрим этапы активизации восстановления ключей.'
Создайте агент восстановления ключей (Key Recovery Agent). Эта учетная запись получает сертификат, позволяющий генерировать и сертифицировать пары открытого/секретного ключа для пользователей. Вспомните, что нормальный процесс сертификации ключа требует, чтобы пользовательская учетная запись сгенерировала пару ключа и запросила сертификацию открытого ключа.
Настройте центр сертификации на архивацию ключей и разрешение восстановления ключей.
Выпустите новый шаблон, который будет использоваться совместно со стандартным шаблоном User для генерации сертификатов архивации.
Создание агента восстановления ключей
Настройка центра сертификации для выпуска сертификатов агента восстановления (Recovery Agent) требует загрузки шаблона агента восётановления ключей (Key Recovery Agent) для кэша шаблона из базы данных Active Directory в кэш шаблонов центра сертификации. С помощью этого шаблона будут выпускаться сертификаты для выбранных учетных записей восстановления ключей. Для создания агента восстановления ключей можно выполнить последовательность действий, описанную в процедуре 18.3.■
Процедура 18.3. Создание агента восстановления ключей
Откройте консоль Certification Authority (Центр сертификации).
Щелкните правой кнопкой мыши на пиктограмме Certificate Templates (Шаблоны сертификатов) и выберите команду New^Certificate Template То Issue (Создать1^ Выдаваемые шаблоны сертификатов). Откроется окно Enable Certificate Templates (Включить шаблоны сертификатов), которое показано на рис. 18.23.
Q0 Exchange Signature Or* QU Exchange User QglPSEC SiPSEC (Offfre request)Q0 Exchange Signature Or* QU Exchange User QglPSEC SiPSEC (Offfre request)SeateEmaiSeccae Emai IP security IKE intermeddle IP security IKE intermeddleSeateEmaiSeccae Emai IP security IKE intermeddle IP security IKE intermeddleQflRouter (0 ffine request) У Smartcard Logon QySmartcardUser @Trust List Signing QjUser Siyiature Or*QflRouter (0 ffine request) У Smartcard Logon QySmartcardUser @Trust List Signing QjUser Siyiature Or*dent Authentication^dent Authentication, Smart Card LogonSeateEmai, dent Authentication, Smart Card LogonMicrosoft Trust List Signing4 *Secure Emai, dent Authentication-* . ’dent Authentication^dent Authentication, Smart Card LogonSeateEmai, dent Authentication, Smart Card LogonMicrosoft Trust List Signing4 *Secure Emai, dent Authentication-* . ’Puc. 1823. Окно Enable Certificate Templates (Включение шаблонов сертификатов), в котором показан шаблон Key Recovery AgentPuc. 1823. Окно Enable Certificate Templates (Включение шаблонов сертификатов), в котором показан шаблон Key Recovery Agent
Q0 Exchange Signature Or* QU Exchange User QglPSEC SiPSEC (Offfre request)
Q0 Exchange Signature Or* QU Exchange User QglPSEC SiPSEC (Offfre request)
SeateEmai
Seccae Emai IP security IKE intermeddle IP security IKE intermeddle
SeateEmai
Seccae Emai IP security IKE intermeddle IP security IKE intermeddle
QflRouter (0 ffine request) У Smartcard Logon QySmartcardUser @Trust List Signing QjUser Siyiature Or*
QflRouter (0 ffine request) У Smartcard Logon QySmartcardUser @Trust List Signing QjUser Siyiature Or*
dent Authentication^
dent Authentication, Smart Card Logon
SeateEmai, dent Authentication, Smart Card Logon
Microsoft Trust List Signing4 *
Secure Emai, dent Authentication-* . ’
dent Authentication^
dent Authentication, Smart Card Logon
SeateEmai, dent Authentication, Smart Card Logon
Microsoft Trust List Signing4 *
Secure Emai, dent Authentication-* . ’
Puc. 1823. Окно Enable Certificate Templates (Включение шаблонов сертификатов), в котором показан шаблон Key Recovery Agent
Puc. 1823. Окно Enable Certificate Templates (Включение шаблонов сертификатов), в котором показан шаблон Key Recovery Agent
Щелкните на кнопке ОК для загрузки шаблона. После этого шаблон будет отображен в правой панели консоли Certification Authority (Центр сертификации).
Зарегистрируйтесь на рабочей станции, которая будет использоваться для восстановления ключей с помощью учетной записи агента восстановления (Key Recovery Agent).
Откройте оснастку Certificates (Сертификаты) и разверните раздел Personal^Certificates (Личные^ Сертификаты).■
Щелкните правой кнопкой мыши на пиктограмме Certificates (Сертификаты) и выберите команду New^Request Personal Certificate (Создать^Запросить новый сертификат) из контекстного меню. Запустится мастер запроса сертификата (Certificate Request Wizard).
Щелкните на кнопке Next (Далее). Откроется окно Certificate Types (Типы сертификатов). Выберите Key Recovery Agent (Агент восстановления ключей).
Щелкните на кнопке Next (Далее). Откроется окно Certificate Friendly Name and Description (Имя и описание сертификата).
Щелкните на кнопке Next (Далее). Откроется окно со списком выбранных параметров.
Щелкните на кнопке Finish (Готово), чтобы завершить транзакцию и работу мастера. Будет выдано сообщение о доставке запроса центру сертификации и выдаче сертификата после одобрения диспетчером сертификатов (Certificate Manager)..
На консоли Certification Authority (Центр сертификации) выделите пиктограмму Pending Request (Запросы в очереди). Запрос на получение сертификата будет показан в правой панели.
Щелкните правой кнопкой мыши на пиктограмме запроса на получение сертификата и выберите из контекстного меню команду All Tasks1^ Issue (Все задачи1^ Выдать). После этого сертификат появится в разделе Issued Certificates (Выданные сертификаты).
Настройка центра сертификации на архивацию сертификатов
Агент восстановления ключей подготовлен. Следующим этапом является настройка центра сертификации на архивацию сертификатов. Необходимая последовательность действий рассматривается в процедуре 18.4.
Процедура 18.4. Настройка центра сертификации на архивацию сертификатов
Рис. 18.24. В окне свойств центра сертификации выбрана вкладка Recovery Agents (Агенты восстановления)
Создание шаблона архивации
Теперь центр сертификации готов к архивации ключей. Следующим этапом является создание шаблона, который будет использоваться для выдачи архивированных ключей, и загрузка этого шаблона в центр сертификации (СА). Выполните последовательность действий, описанную в процедуре 18.5.'
Процедура 18.5. Создание шаблона архивации
На консоли Certification Authority (Центр сертификации) загрузите оснастку Certificate Templates (Шаблоны сертификации). Для этого щелкните правой кнопкой мыши на пиктограмме Certificate Template (Шаблоны сертификатов) и выберите из контекстного меню команду Manage (Управление).
Выберите пиктограмму шаблона User. На этом этапе пиктограмма отображается цветом пониженной интенсивности.
Щелкните правой кнопкой мыши на пиктограмме и выберите из контекстного меню команду Dubplicate Template (Дублировать шаблон). Откроется окно Properties (Свойства) для копии шаблона Recovery Agent (Агент восстановления), которое показано на рис. 18.25.
В поле Template Display Name (Отображаемое имя шаблона) задайте имя шаблона Archive User. Содержимое поляТетр1а1е Name (Имя шаблона) изменится автоматически.
Установите флажок Publish Certificate In Active Directory (Публиковать сертификат в Active Directory).
Активизируйте вкладку Request Handling (Обработка запросов) (рис. 18.26).
Установите флажок Archive Subject's Encryption Private Key (Архивировать секретный ключ субъекта шифрования).
gssmms^^«глаSupeieded Twtietae| EMMfam | Sw* .Benwl |в*аеМИж*д | Stig* Наяд | IweweHaeNw*Те**** we.-, .Имип$<*аМСА« кЫма See 36Hlt«W»a<*wN*»»4* dene* IeWaukjwo* tetagat **a**l*l*llgjgj||llBt|gigil|ill|||i||||||^fT****w.|AichiveUs«: ’Vat***HenawalfawiI 2 [уме3 Г б^адеке"P ^M*«M*« Active DeeptoyГ ^я*»*т*ф|ее«е1< •dupfc*<M*#e***l*e*** - —*-*.—.4Puc. 18.25. Окно свойств для копии шаблонаUser. Вкладка General (Общие)gssmms^^«глаSupeieded Twtietae| EMMfam | Sw* .Benwl |в*аеМИж*д | Stig* Наяд | IweweHaeNw*Те**** we.-, .Имип$<*аМСА« кЫма See 36Hlt«W»a<*wN*»»4* dene* IeWaukjwo* tetagat **a**l*l*llgjgj||llBt|gigil|ill|||i||||||^fT****w.|AichiveUs«: ’Vat***HenawalfawiI 2 [уме3 Г б^адеке"P ^M*«M*« Active DeeptoyГ ^я*»*т*ф|ее«е1< •dupfc*<M*#e***l*e*** - —*-*.—.4Puc. 18.25. Окно свойств для копии шаблонаUser. Вкладка General (Общие)фКЯВтЯЛЪ.^!^ .JjxJЗиИмМТмМм | , Extension ] -. Securi^f | j Genetpl RegwMtwdhg | SiA^ect N«ne j lesuenceRequwseoti }. l^poW ^Encryption'3P AtdweeubjBCt'eenanAonpifvetekay P IrwWeeiw^teiiowSwahwedbyiheBLtiect :*»*« |3S5—3■ 1hgw*aiialwawaiew*ledadcwtti9afhc*r«epfowlei» 04 Ve^PaaeadecM rogue*mayueaniESP|■^Microsoft PH SCheind Cryptogaohic Provid^ ~J«/Microsoft Enhanced Cryptographic Provider v1.0^1 ^[ jMicrosoft Enhanced DSS and Diffie-Helman Cryptographic Provider ■** it ' ^Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype», * iF **>wpnv*e key lobe «portedГ Rggiee war hpul *■<*№•*">Г' •'' ."»< иНКТ, П. r wrnhHInWнее'»»».. >■■« ■ew ■ ww———..—» .фКЯВтЯЛЪ.^!^ .JjxJЗиИмМТмМм | , Extension ] -. Securi^f | j Genetpl RegwMtwdhg | SiA^ect N«ne j lesuenceRequwseoti }. l^poW ^Encryption'3P AtdweeubjBCt'eenanAonpifvetekay P IrwWeeiw^teiiowSwahwedbyiheBLtiect :*»*« |3S5—3■ 1hgw*aiialwawaiew*ledadcwtti9afhc*r«epfowlei» 04 Ve^PaaeadecM rogue*mayueaniESP|■^Microsoft PH SCheind Cryptogaohic Provid^ ~J«/Microsoft Enhanced Cryptographic Provider v1.0^1 ^[ jMicrosoft Enhanced DSS and Diffie-Helman Cryptographic Provider ■** it ' ^Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype», * iF **>wpnv*e key lobe «portedГ Rggiee war hpul *■<*№•*">Г' •'' ."»< иНКТ, П. r wrnhHInWнее'»»».. >■■« ■ew ■ ww———..—» .Puc. 18.26. Окно свойств шаблона User. Вкладка Request Handling (Обработка запросов)Puc. 18.26. Окно свойств шаблона User. Вкладка Request Handling (Обработка запросов)
gssmms^^«гла
Supeieded Twtietae| EMMfam | Sw* .
Benwl |в*аеМИж*д | Stig* Наяд | IweweHaeNw*
Те**** we.-, .
Имип$<*аМСА« кЫма See 36Hlt«W»a<*w
N*»»4* dene* IeWaukjwo* tetagat **a**l*l*llgjgj||llBt|gigil|ill|||i||||||^f
T****w.
|AichiveUs«: ’
Vat***Henawalfawi
I 2 [уме3 Г б^адеке"
P ^M*«M*« Active Deeptoy
Г ^я*»*т*ф|ее«е1< •dupfc*<M*#e***l*e*** - —*-*.—.4
Puc. 18.25. Окно свойств для копии шаблона
User. Вкладка General (Общие)
gssmms^^«гла
Supeieded Twtietae| EMMfam | Sw* .
Benwl |в*аеМИж*д | Stig* Наяд | IweweHaeNw*
Те**** we.-, .
Имип$<*аМСА« кЫма See 36Hlt«W»a<*w
N*»»4* dene* IeWaukjwo* tetagat **a**l*l*llgjgj||llBt|gigil|ill|||i||||||^f
T****w.
|AichiveUs«: ’
Vat***Henawalfawi
I 2 [уме3 Г б^адеке"
P ^M*«M*« Active Deeptoy
Г ^я*»*т*ф|ее«е1< •dupfc*<M*#e***l*e*** - —*-*.—.4
Puc. 18.25. Окно свойств для копии шаблона
User. Вкладка General (Общие)
фКЯВтЯЛЪ.^!^ .JjxJ
ЗиИмМТмМм | , Extension ] -. Securi^f | j Genetpl RegwMtwdhg | SiA^ect N«ne j lesuenceRequwseoti }
. l^poW ^Encryption'3
P AtdweeubjBCt'eenanAonpifvetekay P IrwWeeiw^teiiowSwahwedbyiheBLtiect :
*»*« |3S5—3
■ 1hgw*aiialwawaiew*ledadcwtti9afhc*r«epfowlei» 04 Ve^PaaeadecM rogue*mayueaniESP|
■^Microsoft PH SCheind Cryptogaohic Provid^ ~J
«/Microsoft Enhanced Cryptographic Provider v1.0^1 ^
[ jMicrosoft Enhanced DSS and Diffie-Helman Cryptographic Provider ■** it ' ^Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype», * i
F **>wpnv*e key lobe «ported
Г Rggiee war hpul *■<*№•*">
Г' •'' ."»< иНКТ, П. r wrnhHI
nWнее'»»».. >■■« ■ew ■ ww———..—» .
фКЯВтЯЛЪ.^!^ .JjxJ
ЗиИмМТмМм | , Extension ] -. Securi^f | j Genetpl RegwMtwdhg | SiA^ect N«ne j lesuenceRequwseoti }
. l^poW ^Encryption'3
P AtdweeubjBCt'eenanAonpifvetekay P IrwWeeiw^teiiowSwahwedbyiheBLtiect :
*»*« |3S5—3
■ 1hgw*aiialwawaiew*ledadcwtti9afhc*r«epfowlei» 04 Ve^PaaeadecM rogue*mayueaniESP|
■^Microsoft PH SCheind Cryptogaohic Provid^ ~J
«/Microsoft Enhanced Cryptographic Provider v1.0^1 ^
[ jMicrosoft Enhanced DSS and Diffie-Helman Cryptographic Provider ■** it ' ^Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype», * i
F **>wpnv*e key lobe «ported
Г Rggiee war hpul *■<*№•*">
Г' •'' ."»< иНКТ, П. r wrnhHI
nWнее'»»».. >■■« ■ew ■ ww———..—» .
Puc. 18.26. Окно свойств шаблона User. Вкладка Request Handling (Обработка запросов)
Puc. 18.26. Окно свойств шаблона User. Вкладка Request Handling (Обработка запросов)
Установите флажок Allow Private Key to be Exported (Разрешить экспорт секретного ключа).
Активизируйте вкладку Issuance Requirements (Требования к выдаче).
Сбросьте флажок СА Certificate Manager Approval (Одобрение диспетчера сертификатов центра сертификации). Это позволяет центру сертификации выпускать сертификаты без вмешательства администратора.
Щелкните на кнопке ОК для инициализации нового шаблона. Пиктограмма выводится на консоли Templates (Шаблоны) с нормальной степенью яркости.
Закройте оснастку Templates (Шаблоны)..
На консоли Certification Authority (Центр сертификации) нажмите клавишу <F5> для обновления содержимого.
Щелкните правой кнопкой мыши на пиктограмме Certificate Templates (Шаблоны сертификатов) и выберите из контекстного меню команду New=>Certificate Template То Issue (Создать^ Выдаваемые шаблоны сертификатов). Откроется окно Enable Certificate Templates (Включение шаблонов сертификатов).
Выберите пиктограмму Archive User и щелкните на кнопке ОК. После этого пиктограмма появится в списке доступных сертификатов.
Для отображения различий между стандартными сертификатами и архивированными сертификатами активизируйте столбец Archived Key на консоли. Для этого выделите пиктограмму Issued Certificates (Выданные сертификаты) и воспользуйтесь командой View=> Add/Remove Columns11»Archived Key (Вид^Добавить удалить столбцы1^Archived Key).
На этом этапе с помощью оснастки Certificates (Сертификаты) на рабочей станции пользователя можно запрашивать сертификат Archive .User. Последовательность действий описана в соответствующей процедуре в разделе “Заявка на получение сертификата с помощью оснастки Certificates (Сертификаты)”..
Восстановление архивированного сертификата
Если пользователь потерял секретный ключ шифрования, восстановите ключ на центре сертификации. Для этого выполните последовательность действий, описанную в процедуре 18.6.
Процедура 18.6. Врсстановление потерянного ключа
Откройте консоль Certification Authority (Центр сертификации).
Найдите сертификат для повторно выдаваемого ключа в разделе Issued Certificates (Выданные сертификаты). В столбце Archive Key должно быть указано Yes (Да). Этот индикатор указывает на возможность восстановления сертификата.
Выполните двойной щелчок на пиктограмме сертификата. Откроется окно Properties (Свойства).
Активизируйте вкладку Details (Подробности) и запишите серийный номер сертификата (рис. 18.27) или с помощью комбинации клавиш <Alt+PrintScrn> сделайте копию экрана, которую можно вставить в редактор MS Paint и распечатать. Серийный номер состоит из 20 цифр. Не вводите пробелы.
В командной строке воспользуйтесь утилитой certutil для извлечения ключа в указанный файл: certutil -getkey <серийный_номер> <файл>
Рис. 1827. Окно свойств сертификата. Вкладка Details (Дополнительно), на которой показан серийный номер сертификата
В файле содержится секретный ключ в формате PKCS #7. После этого файл необходимо преобразовать в файл PFX (сохранить под любым именем с расширением .pfx), чтобы его можно было перенести на рабочую станцию пользователя. Для этого можно воспользоваться утилитой certutil. Введите следующую команду: certutil -recoverkey -£ <файл> <файл_р£х>
После запроса на ввод пароля задайте надежный пароль. Этот пароль потребуется при импорте ключа на рабочую станцию пользователя.
Перенесите файл PFX на рабочую станцию пользователя и зарегистрируйтесь от имени пользователя. Выполните двойной щелчок на файле в Explorer (Проводник). Запустится мастер импорта сертификатов.
Воспользуйтесь мастером для добавления ключа в личное хранилище пользователя. Убедитесь в правильности импорта с помощью оснастки Certificates (Сертификаты).
На этом процедуру восстановления можно считать завершенной.
Утилиты с интерфейсом командной строки для управления PKI
Консоль Certification Authority (Центр сертификации) предоставляет наиболее удобный способ управления иерархией доверительных отношений между центрами сертификации. Однако в наборе Resource Kit предоставляется несколько утилит, запускающихся из командной строки, функциональные возможности которых отсутствует на консоли ММ С.
Утилита certutil
Эта утилита позволяет экспортировать и просматривать сертификаты и списки отозванных сертификатов, выданных любым центром сертификации, для которого у вас есть привилегии администратора, а также управлять этими сертификатами и списками. Кроме этого, предоставляется возможность управления базой данных центра сертификации. Воспользуйтесь командой certutil /? для получения списка доступных параметров и их предназначения.
Ниже приведен пример использования этой утилиты:
C:\>certutil -verify serveri.windomain.net_serverl.crt Issuer: .
CN=PolicyCA-l
0=Windomain
L=Phoenix
S=AZ
C=US
E=administrator@windomain.net
Subject:
CN=Serverl
0=Windomain
L=Phoenix '
S=AZ
C=US
E=administrator@windomain.net
Cert Serial Number: 611227e4000000000003
Revocation check passed
Утилита ds store
Эта утилита предоставляет дополнительные возможности управления базой данных центра сертификации по сравнению с утилитой certutil. Одной из неприятных особенностей использования dsstore является чувствительность к регистру некоторых параметров. Например,
рассмотрим результат запроса на отображение сертификата корневого центра сертификации.
(Компоненты имен — DN, CN и DC — должны указываться в верхнем регистре):
C:\>dsstore -display DC=windomain,DC=net
>>>>>>> СА Object # 0 <<<<<<<<
DN: CN=EnterpriseRootCA,CN=Certification Authorities,
S> CN=Public Key Services, CN=Services,CN=Configuration,
4> DC=windomain,DC=net
Cert #0
Issuer :: EnterpriseRootCA
Subject :: EnterpriseRootCA
SHAS HASH: A7180DE4 81036013 07F630F7 B1A3B885 DB1AA67B
Ниже представлен отчет утилиты dsstore, содержащий всю информацию о центре сертификации:
C:\>dsstore -tcainfo
СА Name: EnterpriseRootCA ============================
Machine Name: server4.windomain.net
DS Location: CN=EnterpriseRootCA,CN=Enrollment Services,
S> CN=Public Key Services,CN=Services,CN=Configuration,
*t> DC=windomain,DC=net
:: Support Certificate Templates ::
EFSRecovery
EFS
Doma inCont roIler
Webserver
Machine
User
SubCA
Administrator
ст
#1
: EFS Recovery Agent
ст
#2
: Basic EFS
ст
#3
: Domain Controller
ст
#4
: Web Server
ст
#5
: Computer
ст
#6
: User
ст
#7
: Subordinate Certification Authority
ст
#8
: Administrator
#CTs from enum: 8
Cert DN: CN=EnterpriseRootCA, 0=Windomain, L=Phoenix , S=AZ, C=US, 4> E=administrator@windomain.net
Утилита Certmgr
Эта утилита с графическим интерфейсом из состава Platform SDK обеспечивает другое представление содержимого хранилища сертификатов, отличающееся от содержимого оснастки Certificates (Сертификаты). Запустите утилиту Certmgr на любом компьютере, на котором необходимо просмотреть сертификаты. Пример окна выбора сертификата показан на рис. 18.28.
Утилита signcode
Эта утилита с графическим интерфейсом из состава Platform SDK позволяет добавлять сертификаты подписи к выполняемым файлам и библиотекам DLL. Это отличный способ подписывания собственных приложений, а также подготовки устаревших драйверов без цифровой подписи для получения логотипа Windows 2000.
<None> <None> <None>
12/3/2002 12/3/2002
. 12/3/2003 11/9/2101 12/2/2004 12/4/2003 12/4/2002 12/3/2002
agdog UttieOog Hgdog Adminisbator Administrator Hgdog Hgdog UttieOog
Administrator
QAdminisbator я QAdminisbator : QAdminisbator
QAdminisbdtor '/ QAdminisbator 4 QAdminisbator у QAdi*vsbator
Рис. 18.28. Окно выбора сертификата в утилите Certmgr
<None> <None>
В следующей главе
в пределахв пределахМы практически подошли к завершению развертывания Windows Server 2003
в пределах
в пределах
предприятия. Осталось только настроить операционную среду на рабочих станциях и обеспечить пользователям коммутируемый доступ и доступ через виртуальные частные сети. Эти операции рассматриваются в следующих двух главах. .
1
1
1
19
Управление операционной средой пользователя
Г
лавной особенностью операционной среды в Windows Server 2003 и Windows ХР стало изменение ее внешнего вида и методов работы в ней. Как оборотень в сериале “Секретные материалы”, оболочка Explorer (Проводник) получила возможность изменяться, но при этом сохранила свое место. По умолчанию на рабочем столе нет ни одной пиктограммы, кроме Recycle Bin (Корзина). Меню Start (Пуск) стало больше по размеру, но его содержимое стало более структурированным. Пиктограммы изменились, превратившись из карикатурных изображений Windows 2000 в современные графические изображения. Но самой лучшей особенностью является возможность изменять весь интерфейс быстрее, чем Мадонна меняет стиль своей музыки.
Можно обнаружить, что иногда оболочка раздражает, так как знакомые элементы расположены в новых местах. Если новый интерфейс не способствует повышению производительности, можете включить классический интерфейс, что не приведет к потере функциональности.
Важные изменения внесены на более глубоких уровнях, а не только на блестящем фасаде новой оболочки. Существуют новые методы обработки выполняемых файлов и динамически подключаемых библиотек, новые варианты миграции и обеспечения совместимости приложений, а также целый ряд новых возможностей служб терминалов. Вместо интерфейса в этой главе рассматриваются элементы операционной среды, которые оказывают влияние на администрирование. Можно перечислить следующие темы.
Параллельные сборки
Перемещение настроек пользователей
Совместимость приложений
Перенаправление папок и домашних каталогов
Автономные файлы
Операции с удаленным рабочим столом, включая Remote Assistance (Удаленный помощник)
Классический внешний вид и файлы справочного руководства
Интерактивная справочная утилита, которая называется Help and Support Center (Центр справки и поддержки), часто предполагает, что используется новый интерфейс, поэтому инструкции могут вызвать затруднения при использовании с классическим интерфейсом. При необходимости можно переключиться на новый интерфейс, разобраться в инструкциях справочного руководства и вернуться в классический интерфейс.
Новые возможности Windows Server 2003
С точки зрения управления сервером и рабочей станцией в операционной системе Windows Server 2003 появилось несколько важных возможностей.
Параллельные сборки (Side-by-Side). Чтобы избежать проблем совместимости между разными версиями одной и той же динамически загружаемой библиотеки, компания Microsoft предоставила в составе операционных систем Windows Server 2003 и Windows ХР новую возможность, которая называется параллельная сборка (Side-by-Side assembly). Эта возможность позволяет единственной динамически загружаемой библиотеке предоставлять несколько версий интерфейса. Это похоже на раздвоение личности доктора Джекила и мистера Хайда в области управления приложениями.
Миграция профилей пользователей. В операционной системе Windows 2000 Service Pack 2 предоставлялся инструментарий, который назывался средством перемещения пользовательских настроек (User State Migration Toolkit — USMT). Обновленная версия этого инструментария предоставляется в составе Windows Server 2003 и Windows ХР. В новой версии предоставляется возможность перемещения профиля и параметров приложений между компьютерами, работающими под управлением любой версии Windows на основе Explorer (Проводник). Кроме этого, предоставляется утилита с интерфейсом мастера, которая позволяет перемещать отдельные настройки.
Усовершенствования в протоколе RDP (Remote Desktop Protocol — протокол удаленного рабочего стола). Теперь среда служб терминалов доступна не только на серверах, но и на рабочих станциях. Новая версия протокола RDP поддерживает быстрый и гибкий удаленный доступ. Теперь протокол поддерживает глубину цвета 24 бит, перенаправление устройств, функциональную возможность назначения комбинаций клавиш во время сеанса, а также непосредственный доступ к консоли сервера или рабочей станции.
Быстрое переключение пользователей. Эта возможность является расширением служб терминалов и позволяет нескольким пользователям создавать независимые сеансы на консоли изолированной рабочей станции под управлением операционной системы Windows ХР. Это упрощает управление изолированными компьютерами и небольшими сре- ' дами рабочих групп.
Обработка не отвечающих приложений. Если приложение прекращало отвечать на запросы операционной системы, традиционным методом завершения его работы было использование Task Manager (Диспетчер задач) или утилиты kill из состава Resource Kit. В операционных системах Windows Server 2003 и Windows ХР заголовок окна приложения продолжает отвечать на запросы, даже если само окно прекращает на них реагировать. Это позволяет воспользоваться пунктом меню заголовка Close (Закрыть) и завершить работу приложения.
Привилегии пользователей. Принятые по умолчанию права доступа NTFS в операционной системе Windows Server 2003 значительно ограничивают возможность пользователя получать доступ к файлам в системной папке. Это позволяет сохранить целостность операционной системы.
Параллельные сборки
Оперативная память всегда считалась дорогостоящим компонентом, поэтому компания Microsoft всегда проектировала операционную систему Windows таким образом, чтобы обеспечить работу с минимальным объемом оперативной памяти. (По крайней мере, операционная система пытается делать вид, что занимает оперативную память для чего-то полезного.)
Одним из методов экономии памяти является совместное использование образа динамически загружаемой библиотеки несколькими процессами. Такое использование библиотек может привести к бесконечной головной боли и это знают большинство администраторов. Например, версия динамически загружаемой библиотеки, установленная вместе с одним приложением, может не иметь важной функции, необходимой другому приложению. Если второе приложение запускается после первого, оно подключается к образу динамически загружаемой библиотеки, уже находящемуся в оперативной памяти. При неудачном обращении к отсутствующей функции происходит неприятное событие. Это может быть сообщение приложения Dr. Watson или общая ошибка защиты, или даже критическая ошибка (синий “экран смерти”).
Сегодня память стала не таким дорогим ресурсом, и более важной характеристикой является надежность, поэтому компания Microsoft старается развернуть обработку динамически загружаемых библиотек в обратную сторону, обеспечив поддержку одновременной загрузки нескольких версий библиотеки. Такое решение требует больше оперативной памяти и дискового пространства, но уменьшает количество ошибок, связанных с совместимостью.
Компания Microsoft использует термин сборка (assembly) для описания общих блоков кода, например, динамически загружаемых библиотек. Сборка для запуска нескольких версий называется параллельной сборкой (Side-by-Side, или SxS). Только две динамически загружаемые библиотеки в Windows Server 2003 и Windows ХР являются параллельными сборками.
Shell Common Controls версии 6.0 (Conctl32 . dll)
GDI Plus версии 1.0 (Gdiplus . dll)
Две динамически загружаемые библиотеки не делают революции, но используются многими приложениями и являются потенциальными источниками проблем совместимости в связи с поддержкой тем (theme) в новом интерфейсе. Позволяя предыдущим версиям этих библиотек загружаться в память одновременно с новыми версиями, приложения намного реже будут сталкиваться с проблемами совместимости. В следующих версиях операционной системы Windows следует ожидать увеличения количества параллельных сборок.
Локальные образы
В операционной системе Windows Server 2003 поддерживается и старый метод решения проблем при использовании нескольких версий динамически загружаемых библиотек. В устаревшем методе выполняемый файл приложения отмечался особым образом, в результате чего приложение загружало библиотеки DLL из собственного каталога.
Для включения локальной загрузки необходимо создать пустой файл с таким же именем, как у выполняемого файла, но с расширением . local. Например, для выполняемого файла с именем Zanzibar. ехе необходимо создать локальный файл Zanzibar. local.
При обнаружении расширения . local операционная система загружает запрашиваемые библиотеки из локального каталога, если такие библиотеки существуют. В противном случае приложение связывается с библиотеками в памяти, если такие библиотеки уже загружены.
Файл в формате XML, который называется манифест (manifest), определяет обработку параллельной сборки выполняемым файлом. Файл-манифест находится в том же каталоге,
что и выполняемый файл. Файл имеет то же имя, что и исполняемый файл, и расширение .manifest. Одним из приложений, использующих параллельные сборки, является мастер миграции файлов, Migwi z. ехе. Это приложение использует функции библиотеки Common Controls.
Миграция настроек пользователя
Пользователи тратят много времени и творческой энергии на собственные рабочие станции. Кроме этого, они прилагают значительные усилия, чтобы обойти установленные правила хранения файлов. Как только наступает время миграции рабочих станций пользователей, самой большой проблемой является сохранение данных и параметров одновременно с развертыванием новой операционной системы и новых приложений.
Обычно развертывание осуществляется в три этапа.
Сбор пользовательских данных и их копирование на сервер
Очистка жесткого диска рабочей станции и запись на него образа новой операционной системы■
Перемещение данных пользователя обратно на рабочую станцию
Компания Microsoft предоставляет два инструмента, которые значительно упрощают i миграцию.
Мастер перемещения файлов и параметров (Files and Settings Transfer Wizard —
FSTW). Эта утилита состоит из выполняемого файла Migwi z и набора файлов INF, которые определяют, что и куда будет перемещаться. Мастер предназначен для использования на изолированных компьютерах для отдельных пользователей.
Инструментарий перемещения пользовательских настроек (User State Migration Toolkit - USMT). Эта утилита состоит из двух выполняемых файлов, Scanstate и Loadstate, а также файлов INF, которые используются в мастере перемещения файлов и параметров. Эта утилита предназначена для использования в доменной среде для одновременной миграции нескольких пользователей.
Начнем с рассмотрения сценариев INF, которые используются для исследования приложений во время миграции.
Файлы INF для миграции пользователей
И мастер перемещения файлов и параметров (FSTW), и инструментарий перемещения пользовательских настроек (USMT) используют набор из четырех файлов INF, которые выступают в роли сценариев миграции. Ниже приведен перечень этих файлов, а затем будут подробно рассмотрены функции каждого файла.
Migapp.inf
Miguser.inf
Migsys.inf
Sysfiles.inf
Файл Migapp. inf.
В этом сценарии перечислены приложения, связанные с ними записи системного реестра и файлы поддержки. Для указанных приложений в файле определяются следующие операции.
Выявление присутствия приложения в системном реестре
Определение существующего окружения для приложения
Задание набора инструкций, например копирование файлов на новое место и создание новых записей в системном реестре
В табл. 19.1 перечислены приложения, исследуемые с помощью Migapp. inf. Если необходимо автоматизировать перемещение собственного приложения или приложения от стороннего производителя, в этот файл можно добавить дополнительные записи.
Таблица 19.1. Приложения, исследуемые по умолчанию в файле Migapp. inf
Acrobat Reader 4.0
Acrobat Reader 5.0
Adobe Photoshop Suite 6
Adobe ImageReady 3
MM JukeBox 6
MSN Explorer 10
MS Netmeeting 3
MS MediaPlayer 7
MS Messenger 3.6
MS Money 2001
MS Movie Maker 1
CmdExe
CuteFTP 4
Yahoo Messenger
AIM
ICQ
GameVoice 1
RogerWilco
BattleCom
GoZilla
Microsoft Office
Office XP
Microsoft Office 97
NetscapeCommunicator
PSTPAB
Eudora 5
GetRight 4
Lotus Suitestart 99
Odigo
Prodigy Internet
Quicken 2001
QuickTime Player 5
RealJukebox 2 Basic
RealPlayer 8 Basic
Sonique
WinAmp
WinZip
Microsoft Works 2001
WordPerfect Office 2000
WsFTPLE5
MSN Zone 6;
Quicken2001 HAndB
Ниже приведен фрагмент файла Migapp. inf для приложения Quicken, который позволяет получить представление о выполняемых действиях в сценарии:
[Quicken 2001.Environment]
QuickenDir=Registry, HKLM\Software\Microsoft\WindowsACurrentVersion\
4>. AppPaths\QW.EXE [Path]
[Quicken 2001.Detect]
File, SQuickenDirS\QW.EXE, VERSION("Productversion", "010.*")
[Quicken 2001.Instructions]
copyfilesex=Quicken 2001 CopyfilesEx
forcesrcfile=Quicken 2001 ForceSrcFile
[Quicken 2001 CopyfilesEx]
%QuickenDir%\QDATA.QSD,%QuickenDir%
%QuickenDir%\QW.CFG,%QuickenDir%
%QuickenDir%\QW.RMD,%QuickenDir%
[Quicken 2001 ForceSrcFile]
%QuickenDir%\QW.CFG
%QuickenDir%\QW.RMD'
Файл Miguser. inf
В сценарии Miguser. inf перечислены пользовательские параметры в системном реестре, а также профиль пользователя, который должен быть скопирован на новый компьютер в процессе миграции. В табл. 19.2 перечислены принятые по умолчанию компоненты файла Miguser.inf.
Таблица 19.2. Параметры для пользователя, сканируемые по умолчанию при миграции
Пользовательский параметрКомпонент рабочего стола
Совместно используемые элементы рабочего стола Элементы меню Start (Пуск)
Совместно используемые элементы меню Start (Пуск) Му Documents (Мои документы)
Совместно используемые документыМу pictures (Мои рисунки)
Favorites (Избранное)—
Ниже приведен фрагмент кода операций, которые применяются к пользовательскому профилю:
[Desktop Items.Detect]
Directory,%csidl_desktopdirectory%,EXISTS
[Desktop Items.Instructions]
ForceDestFile=ForceDestDesktop
CopyFilesFiltered=CopyDesktopFiles
[ForceDestDesktop]■
%csidl_desktopdirectory%\desktop.ini
[CopyDesktopFiles]
dir=%csidl_desktopdirectory%\*
Файл Migsys. inf
Этот сценарий определяет перемещение файлов и параметров операционной системы. В табл. 19.3 перечислены системные файлы, которые исследуются в сценарии по умолчанию. При желании можно добавить для анализа и другие файлы.
Таблица 19.3. Системные файлы и параметры, исследуемые с помощью Migsys. inf по умолчанию
Шрифты
Специальные возможности
Мышь и клавиатура
Internet Explorer
Избранное
Телефония
Соединения удаленного доступа
Языки и стандарты
Мультимедиа
Outlook Express
WAB
Экранная заставка
Окончание табл. 19.3
, Шрифты
Специальные возможности
Экран
Свойства папок
Пиктограммы рабочего стола
Оформление
Панель задач Обои
Ниже приведен пример операций, определенный в сценарии для соединений удаленного доступа:
[Ras Connections]
AddReg=Ras.AddReg
[Ras.AddReg]
HKR\RemoteAccess\Profile\*
[Ras Connections.9X]
CopyFilesEx=RasCopy9X
[RasCopy9X]
%windir%\usmt.pbk,%CSIDL_APPDATA%\Microsoft\Network\Connections\
Pbk,Ras Phone.PBK
[Ras Connections.Environment.NT.Windows.NT4]
RasUserFile=Registry, HKR\Software\Microsoft\RAS Phonebook
4> [PersonalPhonebookFile]
[Ras Connections.NT.Windows NT4]
CopyFilesEx=RasCopyNT4
В большинстве случаев этот сценарий не нуждается в модификации. Конкретные параметры обычно указываются в перемещаемых системных файлах.
Файл Sysf lies. inf
В этом сценарии перечислены конфигурационные файлы операционной системы, требующие преобразования или специальной обработки. В каждой операционной системе предоставляются параметры для всех локализованных версий, например французской, итальянской, немецкой, испанской, китайской, японской и тд. Кроме этого, в сценарии присутствуют расширения для различных файлов и их значений, а также каталогов, в которых необходимо искать эти файлы. В табл. 19.4 перечислены операционные системы, которые исследуются во время сканирования.
Таблица 19.4. Операционные системы, исследуемые с помощью файла Sysf lies. inf
Windows 95
Windows 95 OSR2
Windows 95 OSR2.5
Windows 98 Second Edition
Файлы ММС 1.0
Windows 98
Microsoft Netmeeting
Windows ME
Windows NT 4.0
Windows 2000
Использование мастера перемещения файлов и настроек
Мастер перемещения файлов и настроек (FSTW) использует выполняемый файл Migwiz. Этот файл и сценарии поддержки хранятся в каталоге \Windows\System32\USMT. На установочном компакт-диске Windows Server2003 предоставляются копия файла Migwiz и файлов поддержки, что позволяет “собирать" необходимые данные на компьютерах под управлением Windows Эх, Windows ME и WindowsNT 4.0. Этот мастер доступен в меню установочного компакт-диска в разделе Perform Additional Tasks (рис. 19.1).
I Wek onw I о Microsoft Windows XP
Welcome to Microsoft Windows XP
. What do you want to do?
i-> ' Set up Remote Desktop Connection !ЧЙ Set up a home or small office network iHH Transfer files and settings
§| Browse this CD
!->i View the release notes
^ Back
® Exit
Puc. 19.1. Выбор дополнительных функций на установочном компакт-диске Windows Server 2003
Мастер перемещения файлов и настроек выполняет миграцию за два этапа. В ходе первого этапа мастер запускается на существующем компьютере для анализа и сбора информации из системного реестра и файлов. Этот этап может отнять много времени в зависимости от количества файлов на компьютере. Планируйте выполнение этой фазы за период от 30 до 90 минут. В это время пользователь не должен выполнять задачи на компьютере.
Мастер создает огромный файл с расширением . dat, который содержит информацию о миграции. Мастер предоставляет четыре способа переноса файла миграции на новый компьютер.
■ Домашняя сеть. Этот вариант позволяет перенести файлы непосредственно по сети. В этом случае необходимо запустить Home Networking Wizard (Мастер подключения к Интернет в домашней или малой сети) для настройки компьютера. Большинство организаций с существующей сетью не требует такой настройки.
■ Другой. В этом случае файлы сохраняются в каталоге и могут переноситься на другой компьютер любым удобным способом, например с помощью диска Zip или компакт-диска либо копирования по сети. Этот вариант больше всего подходит для организаций с существующей сетью.
■ Гибкий диск или сменный носитель. Пользователи, не подключенные к сети, могут сохранить файлы миграции на гибком диске или диске Zip/Orb. В зависимости от объема пользовательских данных на диске может потребоваться большое количество гибких дисков.
■ Прямое кабельное соединение. Это касается пользователей, которые не используют сеть и не желают носиться с пачкой гибких дисков для переноса файлов. Недостатком этого метода является низкая скорость и необходимость правильного выбора кабеля пользователем компьютера.
В ходе второго этапа мастер запускается на новом компьютере. При появлении сообщения Do You Have a Windows ХР CD? (Доступен ли установочный компакт-диск Windows ХР?) выберите! Don't Need the Wizard Disk (Мне не нужен компакт-диск мастера). В таком случае мастер поймет, что запускается второй этап, и запросит расположение файлов миграции. Сообщите мастеру расположение файлов и подождите завершения работы мастера. На это уйдет некоторое время.
Если мастер столкнется с критической ошибкой, он выдаст страницу HTML, в которой описывается причина проблемы. Файл журнала сохраняется в пользовательском профиле в каталоге Local Settings\Application Data. Папка Local Settings скрыта, поэтому перед ее поиском необходимо включить отображение скрытых файлов.
Инструментарий UMST
Инструментарий перемещения пользовательских наётроек UMST (User State Migration Toolkit) обеспечивает функциональные возможности, подобные возможностям FSTW, но в данном случае поддерживается использование сценария миграции для автоматизации операций. Инструментарий перемещения пользовательских настроек поддерживает работу только с компьютерами, входящими в состав домена. Для изолированных компьютеров необходимо использовать мастер перемещения файлов и настроек (FSTW).
Инструментарий UMST использует те же сценарии INF, что и мастер FSTW. Однако вместо выполняемого файла Migwiz инструментарий UMST использует две утилиты с интерфейсом командной строки.
■ Scanstate. Эта утилита сравнивает содержимое диска и системного реестра с параметрами в сценарии INF. Затем создается сценарий миграции.
■ Loadstate. Эта утилита извлекает содержимое сценария INF, созданного утилитой Scanstate, и применяет полученную информацию на указанном компьютере.
Существует несколько преимуществ Использования инструментария UMST по сравнению с использованием мастера перемещения файлов и настроек. Одним из преимуществ является размер файла миграции. Вместо большого двоичного файла DAT утилита Scanstate создает текстовый сценарий INF и папки, в которых содержатся файлы, копируемые на указанный компьютер. Кроме этого, утилита Scanstate работает намного быстрее, чем мастер FSTW.
Ниже приведен синтаксис для ввода команд утилиты Scanstate. Все параметры утилиты должны вводиться в одной строке:
scanstate <каталог> /с fv.l /l:usmt.log /i:miguser.inf
/i:migapp.inf /i:migsys.inf /i:sysfiles.inf
Рассмотрим назначение параметров утилиты Scanstate.
■ <каталог>. Это каталог, в котором должны сохраняться файлы миграции. Для файлов необходимо от 100 до 150 Мбайт дискового пространства в зависимости от количества файлов на компьютере. Каталог может находиться на сетевом диске.
■ /с. Пропускать ошибки, связанные с длинными именами файлов. Список пропущенных файлов заносится в журнал Longf Не. log.
■ /v. Этот параметр включает вывод подробного отчета утилиты. Существует семь уровней подробности. Для самого подробного вывода следует использовать значение 7. Это значение позволяет получить максимум информации в журнале.
■ /1. Имя файла журнала, в котором будут храниться сообщения об ошибках и другие сообщения. Обычно автор этой книги использует имя Usmt. log.
■ /i. Этот параметр позволяет указать сценарии INF, которые будут использоваться для сбора информации о состоянии. Укажите все четыре сценария INF, если необходимо перенести параметры системы, параметры приложений и пользовательские параметры.
Утилита Scanstate создает достаточно большой файл Migration, inf и иерархию каталогов, в которой хранятся файлы, обнаруженные во время сканирования. Скопируйте эти файлы на целевой компьютер и запустите утилиту Loadstate, воспользовавшись командой следующего формата (все параметры должны быть указаны в одной строке):
loadstate <каталог> /ч-Л /1 :usmtload. log /i:miguser.inf
/1:migapp.inf /i:migsyi.inf /i:sysfiles.inf
В данном случае <каталог> указывает на файлы, сохраненные утилитой Scanstate. Не указывайте полный путь к файл с расширением . inf. Достаточно указать путь к папке на вершине иерархии миграции, которая называется Usmt2i .umc. Например, если полное имя файла Migration, inf выглядит как D:\Usmtfiles\Usmt2i.umc\Migration.inf, параметр < ка талог> будет иметь значение D:\Usmtfiles.
После завершения работы утилиты Loadstate перезагрузите компьютер для инициализации изменений. При появлении сообщений об ошибках проверьте содержимое журнала.
Управление перенаправлением каталогов
В идеальном мире пользователи будут использовать персональные компьютеры только для запуска приложений. Все файлы будут храниться не на локальных дисках IDE, а на сервере, где обеспечиваются резервное копирование, антивирусное сканирование и отказоустойчивость. В таком мире не будет приведенных ниже диалогов.
Пользователь: Вы срочно должны что-то предпринять. Мой компьютер издал громкий глухой звук и теперь при включении выдает сообщение Unable to load command interpreter. System halted.
Администратор: В течение часа к вам подойдет человек и заменит жесткий диск.
Пользователь: А что с ведомостью на зарплату?
Администратор: А что с ведомостью на зарплату?
Пользователь: Сегодня четверг. Мне нужна электронная таблица для составления ведомости.
Администратор: На каком сервере она хранится?
Пользователь: Я не знаю. Кажется, на сервере “Диск С”...
Попытка перенести пользовательские данные на сервер или другую сетевую подсистему хранения превращается в бесконечную борьбу. Пользователи стараются сохранять файлы в удобных местах. Обычно самым удобным местом является каталог, предложенный приложением по умолчанию.
Во многих организациях для хранения пользовательских данных используются домашние каталоги. К сожалению, слишком мало приложений по умолчанию сохраняют файлы в домашних каталогах пользователей. Начиная с операционной системы Windows 2000, компания
Microsoft изменила требования таким образом, что приложения вынуждены предлагать в качестве принятого по умолчанию каталог му Documents (Мои документы). Разработчики приложений должны использовать переменную %userpath%, которая указывает на каталог Му Documents (Мои документы), или вызов функции SHGetFolderPath, который возвращает информацию о расположении всех каталогов профиля.
По умолчанию папка Му Documents (Мои документы) хранится на локальном жестком диске, но ее можно перенаправить на общий ресурс сервера, вручную указав путь UN С в свойствах папки Му Documents (Мои документы) или воспользовавшись групповой политикой Folder Redirection. В однородной среде Windows Server 2003, Windows ХР или Windows 2000 перенаправление каталогов избавляет от использования классических домашних каталогов.
Политики перенаправления каталогов
Групповые политики, которые управляют перенаправлением каталогов, хранятся в разделе User Configuration^Windows Settings^Folder Redirection (Конфигурация пользователям Параметры WindowsM Перенаправление папок). Ниже приведен список папок, поддерживающих перенаправление.
Му Documents (Мои документы). Содержит пользовательские файлы, изображения и звуковые файлы.
■ Application Data. Содержит конфигурационные файлы пользователя, файлы инфраструктуры открытого ключа и специфичные для пользователя данные, используемые приложениями.
Desktop (Рабочий стол). Содержит файлы и ярлыки, отображаемые на рабочем столе пользователя в оболочке Explorer (Проводник).
Start Menu (Главное меню). Содержит файлы и ярлыки, которые отображаются в меню Start (Пуск).
При включении политики перенаправления каталогов файлы прозрачно переносятся на указанный (целевой) сервер. Пользователи могут даже не заметить, что файлы хранятся не на локальном жестком диске. Конечно, если возникнут проблемы в работе сети или откажет сервер, поддерживающий работу перенаправленных каталогов, пользователи это заметят. Кроме этого, пользователи могут заметить снижение скорости открытия и закрытия файлов при доступе к файлам из удаленного офиса через внешнее соединение к серверу, на котором хранятся перенаправленные папки.
Эти и другие проблемы в работе сети можно обойти с помощью распределенной файловой системы (Distributed File System — DFS) для репликации содержимого пользовательских каталогов на серверы, расположенные в стратегических точках сети. Дополнительную информацию о распределенной файловой системе можно получить в главе 16, “Управление совместно используемыми ресурсами”.
Пользователи портативных компьютеров, когда покинут офис и отключатся от сети, заметят, что файлы хранятся не на локальных компьютерах. Дополнительная информация о локальном кэшировании копий файлов приводится в разделе “Управление автономными файлами”.
Управление размещением перенаправленных каталогов
При включении политики перенаправления каталогов в редакторе групповых политик предоставляется два варианта размещения перенаправленных каталогов: Basic (Основной) и Advanced (Дополнительный).
Вариант Basic позволяет указать единое расположение каталогов для всех пользователей, на которых влияет политика перенаправления. Файлы распределяются внутри общего ресурса на основе имен пользователей. Существует четыре способа определения расположения папки:
Create a folder for each user under the root path (Создание папки для каждого пользователя в корневом каталоге);
Redirect the folder to a specified location (Перенаправление папки в указанное место);
Redirect the folder to the user’s home directory (Перенаправление папки в домашний каталог пользователя);
Redirect the folder to the user’s local profile (Перенаправление папки в локальный профиль пользователя).
Кроме этого, можно определить политику копирования существующих файлов из локальных папок пользователя на сервер, тип доступа к файлам на сервере и операции, которые будут выполняться при отключении политики или перемещении пользователя за пределы действия политики. Ниже приводится более подробная информация об этих параметрах.
Создание папки для каждого пользователя
в корневом каталоге
Это новая возможность операционной системы Windows Server 2003. Она является рекомендуемым методом для перенаправления папки Му Documents (Мои документы). При выборе этого варианта указывается путь UNС к общему ресурсу. Система автоматически добавляет к этому пути имя пользователя, после которого добавляется папка Му Documents (Мои документы). В окне свойств отображается пример пути, который будет добавлен.
Перенаправленные папки пользователя создаются на сервере автоматически, когда пользователь впервые регистрируется после включения политики перенаправления каталогов. Применяемые к папке права доступа зависят от параметра Grant The User Exclusive Rights to My Documents (Предоставить пользователю права монопольного доступа к папке Мои документы), который доступен на вкладке Settings (Параметры) в окне свойств политики (рис. 19.2).
Если установить флажок Grant The User Exclusive Rights to My Documents (Предоставить пользователю права монопольного доступа к папке Мои документы), создается папка Му Documents (Мои документы) и пользователь становится владельцем созданной папки. В списке контроля доступа к папке указываются только имя пользователя и имя учетной записи System. Обе учетные записи получают Full Control (Полный доступ) к этому каталогу и всем его подкаталогам и файлам. Воспользуйтесь этим флажком для обеспечения секретности пользовательских данных. (Конечно, любой пользователь с административными привилегиями может стать владельцем этой папки и изменить список контроля доступа. Следует включить аудит такого события.)
Если сбросить флажок Grant The User Exclusive Rights to My Documents (Предоставить пользователю права монопольного доступа к папке Мои документы), будет создана папка <имя_пользователя>' s Documents и пользователь будет назначен владельцем папки. Список контроля доступа к этой папке значительно отличается от списка контроля доступа при установке этого флажка.
Во-первых, учетной записи пользователя предоставляется Full Control (Полный доступ) только к самой папке. Учетной записи Creator Owner (Создатель-владелец) предоставляется Full Control (Полный доступ) к каталогу и всем подкаталогам и файлам. Это обеспечивает пользователю полный контроль, но при попытке смены владельца права доступа будут переданы новому владельцу.
Во-вторых, каталог <имя_пользователя>' s Documents наследует права доступа от родительского каталога в корневом Каталоге общего ресурса. Важно ограничить права доступа NTFS в корневом каталоге. В противном случае пользователи смогут видеть файлы друг друга, что обычно приводит к ряду нервных потрясений.
Рис. 19.2. Вкладка Settings (Параметры) в окне свойств политики перенаправления каталогов
Перенаправление в указанное место
Этот вариант работает так же, как и вариант Basic в операционной системе Windows 2000. Укажите путь UNC к общему каталогу и добавьте переменную среды %username%, после которой следует Му Documents, например:
\\serveri\user_docs\%username%\My Documents
Этот вариант обеспечивает обратную совместимость. Его необходимо применять, когда в сети одновременно работают компьютеры под управлением Windows Server 2003, Windows ХР и Windows 2000.
Это предпочтительный вариант для политик перенаправления каталогов Start Menu (Главное меню) и Desktop (Рабочий стол). Если указать всем Пользователям один и тот же каталог, можно сохранить однородную среду, не налагая всех ограничений обязательного профиля.
Все ярлыки, размещенные в перенаправленном каталоге Start Menu (Главное меню), будут выводиться в пользовательском меню “выше линии”. Они не меняют внешний вид, характер работы или содержимого меню Start (Пуск). Пользовательские права для перенаправленных каталогов ограничены до Read (Чтение) и Execute (Выполнение).
Еще одним применением варианта Specify a Location (Указать расположение) является перенаправление папки Му Documents (Мои документы) на другой локальный диск. Например, в некоторых организациях просто не могут убедить пользователей хранить файлы на сервере. Если отдел обслуживания рабочих станций разбивает локальный диск на “системный” раздел и раздел “данных”, этот вариант можно использовать для перенаправления папки Му Documents (Мои документы) в раздел данных. Этот параметр должен назначаться только тем пользователям, на компьютерах которых присутствуют два раздела. Для этого можно воспользоваться фильтром инструментария управления Windows (WMI), который будет проверять существование фиксированного диска с подходящей буквой логического диска.
Перенаправление на домашний каталог пользователя
Этот параметр также появился в операционной сйстеме Windows Server 2003. Он полезен, если существует классическая инфраструктура домашних каталогов, которую необходимо использовать.
При выборе этого варианта параметр Grant The User Exclusive Rights to My Documents (Предоставить пользователю права монопольного дос'гупа к папке Мои документы) игнорируется и каталоги наследуют права доступа от корня домашнего каталога. В список контроля доступа по умолчанию добавляется группа Administrators (Администраторы).
Этот вариант доступен только клиентам Windows Server 2003 и Windows ХР. В смешанной среде необходимо использовать вариант Specify a Location (Указать расположение) с указанием пути UNC к совместно используемому ресурсу, в котором хранятся домашние каталоги пользователей.
Перенаправление на локальный профиль пользователя
Этот параметр позволяет вернуть перенаправленные каталоги к обычному расположению в локальных профилях пользователей. Оставьте этот параметр включенным в течение достаточного времени, чтобы он распространился на рабочие станции и портативные компьютеры. После этого полностью отключите политику.
Промежуточного шага можно избежать. Для этого необходимо выбрать параметр Redirect the Folder Back to the Local Userprofile when the Policy is Removed (После удаления политики перенаправлять папку обратно в локальный профиль пользователя) при создании политики. Этот параметр обеспечивает автоматическое возвращение пользовательских данных на локальный диск при перемещении объекта пользователя за пределы действия политики (например, при перемещении объекта пользователя за пределы организационной единицы).
Указание целей перенаправления папок в соответствии с группами
Если папки необходимо перенаправлять в зависимости от членства в группах, выберите переключатель Advanced (Дополнительно) в свойствах политики и введите имя группы. После выбора группы предоставляются те же варианты выбора расположения, что и в варианте Basic (Простой) (рис. 19.3).
Specify Group and Location£OfXSpecify Group and Location£OfX
Specify Group and Location£OfX
Specify Group and Location£OfX
■
You can tix>eee the Urgetfokbc location far ai
Seoxity &сц>МагпЬег*ф
' ]C0MPANY\Phx_Sales| j
Brome. |
Target FoWw Location - - -
’ ^Create a folder for each user under the toot path *|■
Root Path ‘|
; |л$егтеН\и!^Jj
Browee... | i
Puc. 193. Дополнительные параметры перенаправления каталогов, среди которых доступно перенаправление для отдельных группPuc. 193. Дополнительные параметры перенаправления каталогов, среди которых доступно перенаправление для отдельных групп' For usaClav. the fakterril be reducted to;
Puc. 193. Дополнительные параметры перенаправления каталогов, среди которых доступно перенаправление для отдельных групп
Puc. 193. Дополнительные параметры перенаправления каталогов, среди которых доступно перенаправление для отдельных групп
SVswveHtueerjWC. SMyDocunente'
(Ж I Owl I
Особенности перенаправления каталогов
При планировании перенаправления каталогов стоит обратить внимание на несколько подводных камней.
Старайтесь не перенаправлять каталог Application Data, если используется шифрованная файловая система. В этом каталоге хранятся ключи шифрованной файловой системы. Если перенаправить каталог на сервер, клиенты на портативных компьютерах не смогут шифровать или дешифровать файлы за пределами сети. Хранение папки Application Data в автономных файлах не поддерживается.
Если на сервере, на котором запущенй служба терминалов в режиме приложений (Application mode), обслуживаются пользователи удаленного рабочего стола, желательно включить политику перенаправления для папки Му Documents (Мои документы). В таком случае пользовательские данные будут храниться за пределами сервера терминалов. Кроме этого, можно воспользоваться перенаправлением папок Desktop (Рабочий стол) и Start Menu (Главное меню) с целью создания однородного внешнего вида и поведения для рабочих столов в пределах сеансов служб терминалов.
Если пользователь нуждается в возможности шифрования файлов в перенаправленной папке Му Documents (Мои документы), с сервером, на котором хранятся каталоги, должны быть установлены доверительные отношения для делегирования. В таком случае сервер получает исключительные привилегии. Дополнительная информация и необходимые предосторожности при шифровании файлов на сервере приводятся в главе 17, “Управление шифрованием файлов’’.
Создание домашних каталогов
и управление ими
Если нет желания использовать политики перенаправления каталогов, но необходимо, чтобы пользователи хранили данные на сервере, можно воспользоваться классическими домашними каталогами. Домашний каталог предоставляет удобный метод хранения, понятный пользователям. Можно сказать “Сохраняйте данные на диске U”, и пользователи поймут, что от них требуется.
Подготовка домашних каталогов для пользователей выполняется в два этапа.
Выбор сервера домашних каталогов и создание общего ресурса для хранения домашних каталогов пользователей.
Настройка учетной записи каждого пользователя Active Directory на использование общего каталога на сервере домашних каталогов.
Информация о домашнем каталоге хранится в двух атрибутах объекта User в базе данных Active Directory: Home-Directory и Home-Drive.
Домашние каталоги могут храниться на любом сервере. Сервер не обязательно должен работать под управлением Windows. Если на клиентах установлено несколько сетевых поставщиков, домашний каталог может быть установлен на компьютере под управлением NetWare, Banyan или UNIX, использующем файловую систему NFS (Network File System).
Если используется сервер под управлением операционной системы Windows, создайте совместно испбльзуемый ресурс для домашних каталогов пользователей в томе NTFS. Это позволит использовать права доступа для файлов и каталогов, чтобы защитить пользовательские данные от других пользователей.
Назначение домашнего каталога с помощью консоли Active Directory — Users and Computers
Домашние каталоги можно создавать двумя способами: воспользоваться графическими утилитами управления на консоли Active Directory — Users and Computers (Active Directory — пользователи и компьютеры) или утилитами с интерфейсом командной строки. Начнем с использования консоли. Назначьте пользователю домашний каталог, как описано в процедуре 19.1.
Процедура 19.1. Назначение домашнего каталога с помощью консоли Active Directory — Users and Computers (Active Directory — пользователи и компьютеры)
Откройте консоль Active Directory — Users and Computers (Active Directory — пользователи и компьютеры). Разверните дерево до объекта пользователя.
Выполните двойной щелчок на объекте пользователя. Откроется окно Properties (Свойства).
Перейдите на вкладку Profile (Профиль), которая показана на рис. 19.4.
Рис. 19.4. Окно свойств для учетной записи пользователя на консоли Active Directory — Users and Computers (Active Directory — пользователи и компьютеры). Вкладка Profile (Профиль)
В группе Home Folder (Домашняя папка) выберите переключатель Connect (Подключить).
Введите букву диска, которая должна использоваться для домашнего каталога, и путь UNC к домашнему каталогу.
Щелкните на кнопке ОК, чтобы сохранить изменения и закрыть окно Properties (Свойства). Система автоматически создаст домашний каталог на указанном общем ресурсе. Список контроля доступа будет автоматически настроен на предоставление полного доступа пользователю и группе Administrators (Администраторы).
Создание домашних каталогов
из командной строки
Если нет желания использовать графический интерфейс для создания домашнего каталога, воспользуйтесь утилитами с интерфейсом командной строки. Большая часть утилит предоставляется в составе операционной системы. Несколько утилит предоставляется в составе Resource Kit. В примере, описанном в процедуре 19.2, создается домашний каталог для администратора службы поддержки, которую зовут Рита Мануэль (Rita Manuel).
Процедура 19.2. Назначение домашнего каталога из командной строки
Откройте приглашение командной строки и введите следующую команду для создания учетной записи пользователя:
net user rmanuel * /add /fullname:"Rita Manuel"
S> /comment:"Help Desk Admin" /domain
Символ (*) заставляет команду net запросить пароль и подтверждение пароля, избавляя от необходимости ввода пароля в командной строке.
Параметр / domain добавляет пользователя в базу данных Active Directory. Без этого параметра запуск данной команды на обычном сервере или рабочей станции, а не на контроллере домена, приведет к созданию учетной записи пользователя в базе данных SAM.
Создайте домашний каталог для пользователя Rita. Эту операцию можно выполнить на сервере или по сети:
MD e:\users\rmanuel
или
MD \\Sl\users\rmanuel
Если для домашних каталогов создаются отдельные ресурсы, создайте на консоли сервера общий ресурс. Для этого можно воспользоваться командой net share: net share rmanuel=c:\users\rmanuel
Для создания общего ресурса по сети воспользуйтесь утилитой из состава Resource Kit, которая называется rmt share. Для использования этой утилиты необходимо зарегистрироваться в домене с помощью учетной записи с административными привилегиями. Утилита rmtshare имеет следующий синтаксис:
rmtshare \\Sl\rmanuel=c:\users\rmanuel
Настройте учетную запись пользователя на использование домашнего каталога. Для этого можно воспользоваться командой net user. По умолчанию для домашнего каталога используется буква Z. Не существует параметров командной строки, позволяющих выбрать другую букву диска. Необходимо ввести следующую команду:
net user rmanuel /homedir:\\Sl\rmanuel
На этом этапе домашний каталог пользователя наследует права доступа от родительского каталога. В унаследованных правах могут присутствовать разрешения для других пользователей или групп. Настройте списки контроля доступа для домашнего каталога так, чтобы только пользователь Rita мог получать доступ. Утилита с интерфейсом командной строки, которая используется для изменения прав доступа NTFS, называется Сас 1s. ехе. Утилитой cads можно воспользоваться как локально, так и по сети. Ниже показана команда, которая предоставляет пользователям Rita и Administrator (Администратор) полный доступ и которая удаляет всех остальных пользователей из списка АСЕ: cacls \\Sl\users\rmanuel /t /д rmanuel:f /д administrator:f
Параметр /t заставляет вносить изменения для каталога, а также подкаталогов и файлов.
Параметр /д предоставляет пользователю указанные права доступа.
Параметр rmanuel: f предоставляет учетной записи Rita полный доступ. То же самое касается и группы Administrators (Администраторы).
При вводе этой команды утилита cads запрашивает подтверждение. Введите Y или Yes для внесения изменений.
Если планируется использовать квоты, назначьте пользователя Rita владельцем домашнего каталога. Ни одна из стандартных утилит Microsoft не позволяет выполнить эту операцию. Рекомендуем использовать утилиту chown из состава Services for UNIX (SFU).
Эти команды позволяют создать сценарий для автоматизации добавления пользователей. Файл сценария должен иметь расширение . cmd. В следующем примере показан простой сценарий, которому в качестве параметров передаются регистрационный идентификатор пользователя, полное имя и комментарий:
md \\Sl\users\%l
net share %l=c:\users\%l (или rmtshare \\Sl\%l=c:\users\%l) net user %1 * /add /domain /homedir:\\Sl\users\%l /fullname:%2 S> /comment:%3
cacls \\Sl\users\%l /t /g %l:f chown \\Sl\users\rmanuel rmanuel
Для создания более сложных сценариев можно воспользоваться языком VBScript, JScript или Perl. Пользователь, запускающий сценарий, должен обладать достаточными административными привилегиями для добавления учетных записей пользователей и модификации списков контроля доступа.
Подключение домашних каталогов для клиентов более старых версий
При назначении пользователю домашнего каталога на современных клиентах Windows диск домашнего каталога подключается автоматически при регистрации пользователя. Это не относится к пользователям на клиентах более старых версий, например Windows 3.1х и Windows Эх. Клиенты более старых версий требуют подключения домашнего каталога в регистрационном сценарии. Ниже приведен синтаксис соответствующей команды:
net use u: \\Sl\users /home
Ограничением классических клиентов Windows является возможность подключения сетевых дисков только к общему ресурсу, а не к каталогу на общем ресурсе.
Например, при подключении диска U к \\Sl\users\dletterman для клиента более старой версии клиент подключает только ресурс users, поэтому диски содержит все домашние каталоги, а не только файлы пользователя dletterman.
Одним из решений является создание общего ресурса для каждого домашнего каталога пользователя. Чтобы скрыть общие ресурсы от просмотра всеми пользователями, к имени можно добавить символ доллара ($). Например, если физический каталог, в котором находятся домашние каталоги, хранится на сервере на диске Е и называется E:\Users\ DLetterman, общий ресурс должен называться Dletterman$ и путь UNC будет выглядеть, как\\Sl\dletterman$.'
Символ $ не полностью скрывает общий ресурс,, поэтому не применяйте его вместо жестких ограничений прав доступа NTFS на домашние каталоги.
Службы терминалов и домашние каталоги
В многопользовательской среде служб терминалов пользовательские параметры сохраняются в домашнем каталоге пользователя. Если пользователь не имеет домашнего каталога, сервер терминалов создаст такой каталог в локальном профиле пользователя. Эта задача выполняется путем набора пакетных файлов, которые запускаются при каждой регистрации пользователя на сервере служб терминалов.
Например, приложения Office 97 сохраняют пользовательские шаблоны в каталоге С: \Program Files\Of f ice97\Templates. В среде сервера терминалов пользователи будут перезаписывать шаблоны друг друга. Набор сценариев в каталоге \Windows\Application Compatibility Scripts перенаправляет совместно используемые папки старых приложений в отдельные домашние каталоги пользователей.
Управление автономными файлами
При использовании перенаправления папок или домашних каталогов пользователи портативных компьютеров будут возмущаться из-за невозможности получить доступ к собственным файлам. Решением этой проблемы являются автономные файлы (offline files). При включении этой возможности пользователь может копировать файлы с сервера на свой портативный компьютер. При подключении пользователя к сети изменения в автономных файлах синхронизируются с копиями на сервере и цивилизация оказывается спасенной в очередной раз.
Дополнительные варианты применения автономных файлов
Названия автономных файлов в документации компании Microsoft меняются в зависимости от точки зрения. С точки зрения сервера эта технология называется кэшированием на стороне клиента (client-side caching). С точки зрения клиента эта технология называется автономными файлами (offline files). Но независимо от названий она применяется не только на портативных компьютерах пользователей.
Локальный доступ к большим файлам. При работе с большими файлами,- хранящимися на сервере, могут возникнуть сложности. Дизайнеры компьютерной графики и операторы приложений CAD обычно копируют большие файлы на локальные жесткие диски и работают с копиями в течение рабочего дня. В конце рабочего дня файлы копируются обратно на сервер. Иногда они забывают скопировать файл на сервер, поэтому задачу синхронизации можно автоматизировать с помощью автономных файлов.
Доступность файлов во время отказов сети. Временные отказы сети практически неизбежны, но пользователи начинают нервничать, если такие отказы длятся достаточно долго. В результате некоторые пользователи предпочитают хранить файлы на локальных дисках. Если пользователи отказываются сохранять файлы на сервере, автономные файлы могут быть тем куском сыра, который заманит пользователей обратно в сеть.
Кэширование приложений. Пользователи часто используют установленные в сети приложения, находясь за пределами локальной сети. Вместо установки приложений на локальных компьютерах можно воспользоваться автономными файлами для хранения кэшированных копий выполняемых файлов.
Некорректное использование автономных файлов
Автономные файлы не являются решением всех проблем мобильных пользователей. Рассмотрим случаи, когда автономные файлы являются неверным решением.
Доступ к файлам осуществляется несколькими пользователями. Представьте, что несколько пользователей пытаются получить доступ к одним и тем же файлам и, отключившись от сети, вносят изменения на своих портативных компьютерах. После подключения к сети начнется синхронизация файлов. Последний запускающий синхронизацию пользователь перезапишет изменения, внесенные всеми остальными пользователями. Пользователи не обрадуются. И администратор тоже.
Файлы баз данных. Не следует кэшировать файлы баз данных. Процесс синхронизации может скопировать файл с данными, но пропустить журнал транзакций или изменение в файле поддержки.
Файлы приложений, работающих по технологии “клиент/сервер”. Не используйте автономные файлы для сохранения локальных копий конфигурационных файлов приложений, работающих по технологии “клиент/сервер", если приложение использует собственные механизмы кэширования.
Файлы PST. Если приложение Microsoft Outlook используется в режиме Corporate Workgroup, пользователи могут хранить автономные папки и архивы в локальном файле PST (личное хранилище). Приложение Outlook самостоятельно обеспечивает синхронизацию между информационным хранилищем Exchange и локальным хранилищем PST. Не добавляйте еще один уровень синхронизации в виде синхронизации автономных файлов. Это приведет к повреждению данных.
Система автоматически фильтрует файлы в соответствии с перечисленными выше критериями. Это относится к файлам со следующими расширениями:
. db (Foxpro)
.pst (Outlook)
.mdb, .mdw, .mde, Idb (Access)
.slm (Visual Sourcesafe)
Если в папке присутствуют файлы с такими расширениями, система откажется настраивать папку для хранения автономных файлов. Если папка настроена на хранение автономных файлов, система откажется копировать в эту папку файлы с указанными расширениями.
Расширения жестко закодированы в службу кэширования на стороне клиента. Эти ограничения можно переопределить с помощью групповой политики Files Not Cached (Некэ- шируемые файлы). Политйка хранится в разделе Computer ConfigurationMAdministrative TemplatesMNetworkMOffline Files (Конфигурация компьютерам Административные шабло- ныМСетьМАвтономные файлы).
Соблюдайте осторожность при включении политики Files Not Cached (Некэшируемые файлы). Политика полностью переопределяет принятые по умолчанию расширения. Если в список необходимо добавить дополнительные расширения, не забудьте все перечисленные выше расширения.
Автономные файлы и удаленный рабочий стол
Автономные файлы отключены на компьютерах, на которых запущена служба Remote Desktop (Удаленный рабочий стол). Это касается серверов под управлением Windows Server 2003, так как в данной операционной системе служба Remote Desktop включена по умолчанию. Если операционная система Windows Server 2003 установлена для тестирования на портативном компьютере или существуют другие причины для включения автономных файлов
на сервере, Remote Desktop можно отключить. Для этого выполните последовательность действий, описанную в процедуре 19.3.
Процедура 19.3. Отключение удаленного рабочего стола
Щелкните правой кнопкой мыши на пиктограмме Му Computer (Мой компьютер) и выберите Properties (Свойства) из контекстного меню. Откроется окно Properties (Свойства).
Откройте вкладку Remote (Удаленное использование).
Сбросьте флажок Allow Users То Connect Remotely То This Computer (Разрешить удаленный доступ к этому компьютеру).
Щелкните на кнопке ОК для сохранения изменений. Текущие сеансы удаленного рабочего стола сохранятся. Для включения автономных файлов придется завершить сеансы или перезагрузить компьютер.
Службу Remote Desktop (Удаленный рабочий стол) можно включить в любой момент, установив флажок Allow Users То Connect То This Computer (Разрешить удаленный доступ к этому компьютеру). Если автономные файлы были включены, то перед включением Remote Desktop их необходимо отключить.
Это же ограничение относится к изолированным рабочим станциям под управлением Windows ХР с включенной службой Fast Switching (Быстрое переключение пользователей). Такая проблема не возникает в корпоративной среде, так как при включении рабочей станции в домен служба Fast Switching отключается. Если на изолированных рабочих станциях под управлением Windows ХР работают пользователи, подключающие общие каталоги на серверах под управлением Windows Server 2003 или Windows 2000 и пользователи нуждаются в автономных файлах, придется отключить службу Fast Switching. Запустите аплет Users Accounts (Учетные записи пользователей) в новом интерфейсе Control Panel (Панель управления) и выберите Change The Way Users Logon On Or Off (Изменение входа пользователей в систему). Сбросьте флажок Fast User Switching (Использовать быстрое переключение пользователей) и сохраните внесенное изменение.
Настройка кэширования на стороне клиента
Кэширование на стороне клиента управляется на сервере с помощью параметров, заданных для совместно используемого ресурса. На вкладке Sharing (Совместный доступ) щелкните на кнопке Caching (Кэширование). Откроется окно Caching Settings (Параметры кэширования), которое показано на рис. 19.5.
17 Alow oechngoltiHn be «hand Ude
]« I Cancel |
Puc. 19.5. В окне Caching Settings (Параметры кэширования.) для совместно используемого каталога отображаются принятые по умолчанию параметры кэширования
Существует три варианта настройки. Варианты отличаются выбором файлов для кэширования и обработкой изменений в файлах на сервере.
Кэширование документов вручную
Вариант кэширования Manual Cashing of Documents (Кэширование документов вручную) является принятым по умолчанию. В этом случае пользователь должен выбрать файлы, которые будут храниться автономно. Это так называемое закрепление (pinning). Название варианта может ввести в заблуждение, так как, кроме файлов с данными, пользователь может кэшировать выполняемые файлы.
Файл или папка закрепляется с помощью пункта Make Available Offline (Сделать доступным автономно) в окне Properties (Свойства) для файла или папки. Для закрепленного файла или папки отображается пиктограмма с небольшой двунаправленной синей стрелкой.
При открытии закрепленного файла пользователем система проверяет копию файла на сервере и пытается обнаружить изменения. Если изменения не вносились, открывается локальная копия. Если изменения вносились на сервере, копия файла загружается с сервера в локальный кэш, после чего и открывается локальная копия.
Пока клиент держит локальную копию открытой, копия на сервере заблокирована. Это предотвращает модификацию копии на сервере другим пользователем.
К сожалению, использование и обнаружение блокировок зависит от приложения. Например, Microsoft Word ведет себя правильно и отказывается открывать заблокированный файл. С другой стороны, Notepad (Блокнот) игнорирует блокировки и открывает любой файл.
Автоматическое кэширование документов
При выборе варианта Automatic Cashing of Documents (Автоматическое кэширование документов) от пользователя не требуется закрепление файла для включения кэширования. Локальные копии кэшируются при открытии любого файла на совместно используемом ресурсе.
Если файл был кэширован автоматически, пиктограмма файла не меняется. Если пользователь планирует работать с некоторыми файлами за пределами сети, их необходимо закрепить вручную.
Как И в случае с вручную закрепленными файлами, при открытии автоматически кэшированного файла сначала проверяется копия на сервере и сравнивается с локальной копией. Кэшированная локально копия используется для чтения, а все изменения вносятся одновременно в локальную копию и в копию на сервере. Копия на сервере остается заблокированной.
При создании нового файла на совместно используемом ресурсе, настроенном на автоматическое кэширование, файл кэшируется локально. Если файл создается на сервере другим пользователем, он будет показан в списке файлов в Explorer (Проводник), но будет кэширован, только если пользователь его бткроет. Обучите пользователей такому заклинанию: “Для использования — потом, открыть — сейчас”.
Автоматическое кэширование программ и документов
Вариант Automatic Cashing of Program and Documents (Автоматическое кэширование программ и документов) отличается от других вариантов автоматического кэширования методом обработки блокировок. Файлы данных блокируются, а выполняемые файлы нет. Это позволяет сократить объем передаваемых по сети данных, хотя отказ от нескольких пакетов SMB не дает заметной экономии. В большинстве случаев стоит избегать этого варианта и применять вариант Use Automatic Caching of Documents (Использование автоматического кэширования документов). Вариант Automatic Cashing of Program and Documents стоит использовать только при использовании устаревшего приложения, которое плохо справляется с поддержкой одновременной работы нескольких пользователей.
Отключение кэширования
Конечно, существует и четвертый вариант: Disabling Cashing (Отключение кэширования). Можно сказать “Нет” автономным файлам и отключить кэширование на сервере. Это необходимо сделать для каждого ресурса, на котором запрещено кэширование. Например, если существует общий ресурс, на котором хранятся гигабайты выполняемых файлов и нет смысла кэшировать эти файлы на локальных компьютерах пользователей, отключите кэширование для этого ресурса.
Кроме этого, можно отключить автономные файлы на клиенте. По умолчанию автономные файлы включены для рабочих станций под управлением Windows ХР и отключены для серверов под управлением Windows Server 2003. Переключатель предоставляется в меню Tools'^ Folder Options (Сервис^ Свойства папки) любой папки (рис. 19.6). Этот параметр также можно настроить с помощью Appearance and Themes1^ Folder Options (Оформление и темы=> Свойства папки) в новом интерфейсе Control Panel (Панель управления).
При выборе варианта Enable Offline Files (Использовать автономные файлы) клиент получает информацию обо всех совместно используемых ресурсах, для которых настроено автоматическое кэширование, поэтому на клиенте должно быть достаточно дискового пространства. По умолчанию кэш автономных файлов может занять до 10% дискового пространства. Пользователи не получают уведомления о переполнении кэша. При переполнении кэша более старые файлы удаляются из кэша.
По умолчанию кэш автономных файлов находится в скрытой папке, которая называется \Windows\CSC.
Если эту папку необходимо хранить за пределами диска С, ее можно переместить на другой диск с помощью утилиты Cachemov, которая предоставляется в составе Resource Kit. Это приложение с графическим интерфейсом, которое предоставляет список фиксированных - дисков, установленных в системе, а также указывает объем доступного дискового пространства. Перемещение кэша на сменный носитель не поддерживается.
Рис. 19.6. В окне Folder Options (Свойства папки) открыта вкладка Offline Fifes (Автономные файлы)
Совет по использованию системного реестра: кэширование на стороне клиента
Ниже представлены записи системного реестра, управляющие кэшированием на стороне клиента:
Раздел: HKLM\Software\Microsoft\Windows\CurrentVersion\NetCache
Записи: DefCacheSize (reg_dword) (содержит размер кэша в шестнадцатеричной форме);
Enabled (reg_dword) (значение 1 — для включения, о — для отключения);
EncryptCache (REG_DWORD) (значение 1 — для шифрования всего кэша, 0 — для отключения шифрования)
Диспетчер синхронизации
Компании Microsoft потребовалось несколько лет для создания прозрачной для пользователя системы синхронизации автономных файлов с файлами на сервере. После нескольких “почти работающих” решений задача синхронизации файлов была возложена на диспетчера синхронизации (Synchronization Manager), Mobsync. exe.
Диспетчер синхронизации не только управляет автономными файлами, но и обрабатывает автономные Web-страницы для Internet Explorer версии 5.0 и,более новых версий. (Synchronization Manager устанавливается при установке Internet Explorer на компьютер под управлением Windows Эх и Windows NT.)
Параметры диспетчера синхронизации в системном реестре
Параметры диспетчера синхронизации находятся в следующем разделе системного реестра:
Раздел: HKLM\Software\Microsoft\Windows\CurrentVersion\SyncMgr
В этом разделе очень мало параметров, которые должен менять администратор. Все необходимые параметры доступны в пользовательском интерфейсе.
Параметры диспетчера синхронизации
Диспетчер синхронизации не работает непрерывно. Он выполняет свои задачи только в заданные моменты времени. По умолчанию это моменты регистрации и завершения сеанса пользователя. Диспетчер можно настроить на синхронизацию в другие моменты. Для этого существует три интерфейса.
Свойства папки
Диспетчер синхронизации
Групповые политики
Параметры в окне Folder Options (Свойства папки) были рассмотрены ранее. Интерфейс диспетчера синхронизации показан на рис. 19.7. Для его запуска выберите Starts Programs^ Accessories1^Synchronize (Пуск^Программы^Стандартные^Синхронизация).
Щелкните на кнопке Setup (Установка), чтобы открыть окно Synchronization Settings (Параметры синхронизации), показанное на рис. 19.8.
В списке When I Am Using This Network Connection (При использовании данного сетевого подключения) отображается только один интерфейс локальной сети, даже если на компьютере установлено несколько сетевых адаптеров. Остальные элементы этого списка соответствуют коммутируемым соединениям. В этом окне можно настроить специальные параметры синхронизации для низкоскоростных соединений. Обычно синхронизация не выполняется по линиям, работающим на скорости ниже 500 Кбит/с.
ЬчиЛли* |0пИ»| Stf*d*d|
Seen ip** 1*» to be Mmdvoneed when you be on or fog < dibice d bum cw be flhieft fa each netwoik oomecbon.
When<anMf9tfwn*wcfkeeMwctM>n:
|иНИНЯИ^В*1
। . *ieteahtoii» Mowing ehookodfawiK
яКИбпеП*
] 1В<Й\A$erver2\users on server2й ^
jOffline Web PagesS
□ ЙМу Current Heme Pages 'j
' taiatriie*WN£«rimt*i^^P When! tog onto H^canputor
( P V^wnlfogdfovocnfMK.
* Г A*«eh*Wfo«idww6»igiheiieme
Puc. 19.8. Параметры синхронизацииPuc. 19.8. Параметры синхронизацииOK | Cancel j
Puc. 19.8. Параметры синхронизации
Puc. 19.8. Параметры синхронизации
Рис. 19.7. Интерфейс диспетчера синхронизации
Повреждение базы данных кэширования на стороне клиента
Хранящиеся на клиенте автономные файлы перечислены в базе данных CSC (Client-Side Caching). Эта база данных может быть повреждена. Симптомами повреждения являются невозможность открыть файл, файлы, доступные только в автономном режиме, и записи в журнале событий, указывающие на повреждение.
Если возникают эти или другие симптомы, можно попытаться удалить файлы из кэша на стороне клиента,, а затем выполнить повторную синхронизацию. Эта возможность доступна в окне Folder Options (Свойства папки) на вкладке Offline Folders (Автономные папки).
Если это не помогло решить проблему, выполните полную повторную синхронизацию в окне Folder Options (Свойства папки) на вкладке Offline Folders (Автономные папки). Для этого нажмите комбинацию клавиш <Ctrl+Shift> и щелкните на кнопке Delete (Удалить). Это приведет к полному уничтожению содержимого локально кэшированных файлов, поэтому убедитесь, что на сервере хранятся актуальные версии файлов, или скопируйте кэшированные файлы. Для завершения процедуры компьютер должен быть перезагружен.
Решение конфликтов
Если копия файла на сервере изменяется, пока пользователь находится за пределами сети, диспетчер синхронизации должен определить последовательность действий при подключении пользователя к сети. Существует три возможных сценария.
Клиентская копия не изменилась. В таком случае серверная копия записывается поверх локальной копии и пользователь не подучает никаких сообщений.
Серверная копия была удалена. В таком случае локальная копия сохраняется, но отображается только пока пользователь находится в автономном режиме. “Фантомная” копия может вводить пользователя в заблуждение. Если файл бодыпе не нужен, пользователя можно обучить удалению файла в автономном режиме. Если файл нужен, создайте копию файла в автономном режиме и удалите оригинал. После этого выполните повторную синхронизацию и скопируйте файл обратно в папку.
ПВ83ПШЗЯЯЯЯЯЯМММШй#в&№'... Я
Н
МЛ* #awe*w*r wee dsxmeM farnr the natwok. the Ыомпд Ha we changed. boh enw aanputw and on Iha netwo*
ФaolM9Ыfon^\■enl•tгMмl(\a*■■>Ma^>v*anenl■'
Т(мци*еН»|Явсе1**
<* Keep bedivenreeL Save the ween en «у cc*e«*r»*i« network at Dheument fadmnttrater vUrtf
№ Keep огф the version on try COTtxW. Rapiece the network veraon
C Keep a* Iha network v««« Replace the waon опту compute
harwork Veteran Mpdtnd on T2W2001 1022yaw |
tjxalVeraon Modtedbjr'tKbnrtator'отVaw I
ту*едп immw1
Г Do *■ total сойки.
| OK j Cancel |
Puc. 19.9. Окно Resolve File Conflicts (Решение конфликтов файлов)
Изменились клиентская и серверная копии. В таком случае для пользователя отображается окно Resolve File Conflicts (Решение конфликтов файлов), показанное на рис. 19.9, в котором диспетчер синхронизации предоставляет пользователю возможность принять решение о дальнейших действиях.
Пользователь может решить возникший конфликт, выбрав сохраняемую копию или выбрав сохранение обеих копий с переименованием локальной версии. Пользователь может просматривать файлы перед принятием решения. Опытные пользователи чаще всего правильно выходят из конфликта. Менее опытный пользователь может ошибиться при указании пути к файлу, который указывается в формате UNC. Не удивляйтесь звонкам в службу поддержки, связанным с вопросами относительно символов косой черты и обратной косой черты.
Автономные файлы и шифрование
Обычно файлы на портативном компьютере стоят дороже, чем сам портативный компьютер. Защита этих файлов с помощью прав доступа NTFS не остановит злоумышленников. Если похититель портативного компьютера не знает, как взломать пароль администратора, то это знает скупщик краденного. Или скупщик знает того, кто обладает достаточными знаниями. Лучшим методом защиты в данном случае является шифрование.
В операционной системе Windows 2000 пользователи не могли шифровать файлы в кэше автономных файлов. Это делало информацию с сервера доступной всем интересующимся. Этот недостаток рассматривался как критически важный, что мешало многим организациям использовать автономные файлы.
В операционных системах Windows Server 2003 и Windows ХР пользователи получили возможность шифровать содержимое кэша автономных файлов. Локальное состояние шифрования полностью независимо от шифрования на сервере. Это делает автономные файлы безопасным средством для переноса файлов на портативные компьютеры.
Для включения шифрования автономных файлов активизируйте вкладку Offline Files (Автономные файлы) в окне Folder Options (Свойства папки). Установите флажок Encrypt Offline Files to Secure Data (Шифровать автономные файлы для защиты данных). Удостоверьтесь, что портативный компьютер входит в домен и регистрация выполняется в домене, а не в локальной базе данных SAM. Это позволяет использовать учетную запись Administrator (Администратор) в качестве агента восстановления данных. Дополнительная информация приводится в главе 17, “Управлениё шифрованием файлов".
Автономные файлы и групповые политики
Вместо настройки параметров автономных файлов на каждом клиенте можно воспользоваться групповыми политиками. Параметры политик хранятся в разделе Computer Configurations Administrative TemplatessNetworksOffline Files (Конфигурация компьютерам Административные шаблоныМСетьМАвтономные файлы). Эти групповые политики управляют следующими аспектами применения автономных файлов.
Включение/отключение автономных папок (на клиентах) и кэширования на стороне клиента (на серверах)
Установка событий синхронизации (регистрация/завершение сеанса/спящий режим)
Отключение элементов конфигурации автономных папок в окне Folder Options (Свойства папки) в Control Panel (Панель управления)
Отключение возможности закрепления файла пользователем
Управление всплывающими сообщениями диспетчера синхронизации (Synchronization Manager)
Шифрование автономных файлов
Изменение предельной скорости для низкоскоростного соединения (по умолчанию граничной является скорость 500 Кбит/с)
Установка принятого по умолчанию размера кэша (в процентах от объема диска)
Выбор расширений файлов, которые нельзя хранить в кэше автономных файлов
При установке групповых политик для автономных файлов помните, что целевая аудитория использует портативные компьютеры, которые могут находиться за пределами сети в момент установки политики. Пользователи коммутируемых соединений получат политики Administrative Templates (Административные шаблоны) и обнаружат изменения политик, но операции по синхронизации не начнутся, пока пользователь не подключится к сети.
Может потребоваться создание группы, которая называется Laptop Users, и предоставление этой групповой политики только данной группе. Это позволяет избежать создания политик автономных файлов, оказывающих влияние на пользователей рабочих станций.
Операции при использовании автономных файлов
Ниже перечислено несколько ключевых моментов, сГ которых необходимо помнить при использовании автономных файлов.
Все серверные ресурсы по умолчанию настроены на кэширование документов вручную (вариант Manual Caching of Documents). Это требует от пользователей закрепления (pinning) всех файлов, которые должны быть доступны автономно.
Если необходимо использовать автоматическое кэширование, выберите вариант Automatic Caching for Documents (Автоматическое кэширование документов), а не Automatic Caching for Documents and Programs (Автоматическое кэширование документов и программ), что позволит обеспечить правильное блокирование файлов.
Файлы, хранящиеся на общем ресурсе и настроенные для автоматического кэширования, не кэшируются локально до их открытия. Проведите обучение пользователей.
При работе с кэшированными файлами данных по сети для чтения всегда используется локальная копия. Запись выполняется одновременно в обе копии.
Если модификация файла выполняется одновременно на сервере и пользователем в автономном режиме, инструкции в окне Resolve File Conflicts (Решение конфликтов файлов) позволят пользователю выбрать необходимые операции.
Управление сервером с помощью удаленного рабочего стола
Полностью отказавшись от персональных компьютеров, можно оставить только хранилище на сервере. Системы на основе “тонких” клиентов стабильно увеличивают свою долю на рынке в течение последних нескольких лет. Это связано с тем, что все больше компаний открывают преимущества работы пользователей непосредственно на сервере в многопользовательской среде.■
Многопользовательское применение операционной системы Windows началось в 1995 году с продукта Citrix WinFrame, представлявшего переработку базового кода Windows NT 3.51. Компания Citrix уже присутствовала на рынке, выпустив программу WinView, представлявшую собой переработанный базовый код OS/2. Главной технологией как в WinView, так и в WinFrame был протокол Citrix Integrated Computing Architecture (ICA), который обеспечивал исключительно эффективный клиент/серверный механизм для передачи информации о сеансе.
После выхода операционной системы Windows NT 4.0 компания Microsoft решила, что многопользовательский код должен входить в базовую поставку операционной системы, а не в дополнения от сторонних производителей. Компании Microsoft и Citrix выработали схему лицензирования, по которой компания Citrix сохранила управление над протоколом ICA, а компания Microsoft получила управление над всеми остальными компонентами. В результате получилась операционная система Windows NT 4.0 Terminal Server Edition, которая содержала код как от компании Microsoft, так и от компании Citrix.
В операционной системе Windows 2000 компания Microsoft встроила функциональные возможности поддержки работы нескольких пользователей в базовую операционную систему вместо создания отдельного продукта более высокого уровня. Это привело к увеличению производительности и стабильности. В операционной системе Windows 2000 службы терминалов могут работать в двух режимах.
Режим удаленного администрирования (Administration). Этот режим позволяет двум администраторам одновременно запускать сеансы на сервере.
Режим приложений (Application). Этот режим позволяет запускать сеансы любому количеству авторизованных пользователей. Каждый сеанс получает отдельные параметры конфигурации, сохраняемые в домашнем каталоге пользователя.
На данный момент компания Microsoft предоставила службы терминалов в составе всех операционных систем в линейке продуктов. Возможности служб терминалов предоставляются как в серверных операционных системах Windows Server 2003, так и в операционных системах для рабочих станций Windows ХР. Кроме этого, компания Microsoft изменила терминологию, связанную со службами терминалов. Возможность установки сеанса служб терминалов теперь называется Remote Desktop (Удаленный рабочий стол). Возможность поддержки нескольких независимых пользовательских сеансов, подобная режиму приложений в Windows 2000, называется службами терминалов (Terminal Services).
В составе операционной системы Windows Server 2003 предоставляется поддержка протокола RDP (Remote Desktop Protocol — протокол удаленного рабочего стола) версии 5.2. Это обновленная версия RDP5.1, предоставляющаяся в составе Windows ХР. Основным отличием является поддержка автоматической повторной установки сеанса. При использовании клиента RDP версии 5.2 сеанс может пропустить несколько тактов без отключения. Это делает подключения по виртуальной частной сети или коммутируемым линиям более устойчивыми.
Протокол RDP
Существует два способа запуска сеанса удаленного рабочего стола в операционной систе ме Windows Server 2003. Один из способов подразумевает использование протокола RDP от Microsoft. Изначально протокол назывался T-Share и являлся переработкой международного стандарта Т.120. Это быстрый протокол, поддерживающий многоканальную связь, но до Win dows Server 2003 и Windows ХР протокол был несколько ограничен и не предоставлял некоторых функций. Для использования протокола RDP необходим клиент под управлением Windows.
Еще одним интерфейсом является протокол ICA от Citrix. Использование ICA требует службы Citrix ICA MetaFrame и отдельного клиента ICA. Клиенты ICA существуют практически для всех платформ, не только для Windows, начиная с Linux и HP-UX и заканчивая Macintosh.
Если необходимо избежать дополнительных сложностей и затрат на приобретение Citrix MetaFrame для поддержки клиентов, работающих под управлением операционных систем, отличных от Windows, то можно воспользоваться другими доступными альтернативами. Можно приобрести клиент Java RDP, который называется HOBLink JWT и поддерживает соединение со службами терминалов Windows 2000 и Windows Server 2003. Дополнительная информация доступна на сайте по адресу www. hobs of t. com. Кроме этого, существует клиент RDP с открытым исходным кодом. Этот клиент доступен на сайте по адресу www.rdesktop.org.
Но не игнорируйте MetaFrame полностью. Компания Citrix активно старалась улучшить MetaFrame 'и протокол ICA в последние годы. Например, если необходимо публиковать отдельные приложения со сложного, центрально-управляемого набора серверов (server farm), потребуется MetaFrame. Обратитесь на сайт компании Citrix по адресу www .citrix.com для получения списка новых возможностей MetaFrame для Windows Server 2003. Этот продукт не бесплатен (и даже очень не бесплатен), но его возможности и производительность могут оказаться весьма полезными.
С другой стороны, MetaFrame может и не потребоваться после ознакомления с новыми возможностями протокола RDP. Версия 5.2 работает не только быстрее и надежнее предыду щих версий, но и поддерживает 24-битовый цвет, полный набор функций перенаправления устройств, совместный доступ к буферу обмена, шифрование с ключом 128 бит и возможность использования комбинаций клавиш для сокращенного вызова команд во время сеанса. Протокол RDP можно использовать и для подключения непосредственно к консоли сервера под управлением Windows Server 2003 или рабочей станции под управлением Windows ХР. В более ранних версиях Windows для этого требовалась установка NetMeeting.
Кроме этого, службы терминалов можно запускать внутри кластера балансировки сетевой нагрузки (Network Load Balancing— NLB). Такая возможность появилась в операционной системе Windows 2000, но в этой версии были проблемы при установке соединений. В операционной системе Windows Server 2003 поддержка кластера NLB была улучшена благодаря добавлению службы каталога сеансов (Session Directory). При подключении пользователя к серверу в кластере NLB сервер уведомляет службу Session Directory. Если пользователь отключается и подключается повторно, устанавливающий соединение сервер обращается к Session Directory и отправляет пользователя обратно к оригинальному серверу.
Удаленный рабочий стол
Клиент удаленного рабочего стола (Mstsc. ехе) устанавливается вместе с каждой версией операционных систем Windows Server 2003 и Windows ХР. Ярлык расположен в классическом меню Start (Пуск) в разделе Programs^ Accessories^Communications^Remote Desktop Connection (Программы^Стандартные^Связь1^Подключение к удаленному рабочему столу).
Новый клиент Mstsc отличается от версии в составе Windows 2000. В новом клиенте Mstsc объединены клиент RDP с диспетчером подключений, что требовало отдельного клиента в операционной системе Windows 2000. Конфигурационные файлы Mstsc имеют текстовый формат и получают расширение . rdp. Можно выполнить двойной щелчок на одном из файлов RDP, чтобы установить сеанс с указанным в файле сервером. Это значительно упрощает распространение ссылок среди клиентов.
Клиент RDP 5.2 запускается на любой 32-разрядной платформе Windows. На установочном компакт-диске Windows Server 2003 предоставляется пакет MSI, который можно использовать для развертывания клиента на компьютерах под управлением Windows NT, Windows Эх и Windows ME любым выбранным способом. Для установки требуется запустить Windows Installer. Установка на клиентах более старых версий требует перезагрузки.
Дополнительные функции клиента
Как вам, вероятно, известно, компания Microsoft предоставила в составе Windows 2000 SP1 “усовершенствованные” клиенты RDP.
Клиент, основанный на консоли ММС (Mstsmmc. msc) и поддерживающий соединения с несколькими серверам в одном окне.
Клиент на основе Web-интерфейса, состоящий из элемента управления ActiveX Msrdp. осх и сценария установки Ms г dp. in f.
Эти клиенты предоставляются и в составе операционной системы Windows Server 2003, но в другой упаковке. Клиент на основе ММС устанавливается по умолчанию На каждом компьютере под управлением Windows Server 2003. Ярлык расположен в меню Starts Programs^ Administrative Tools^Remote Desktop (Пуск=>Программы^Администрирование^Удаленные рабочие столы). Клиент на основе Web-интерфейса является компонентом IIS вместе с виртуальной папкой TSWeb, в которой хранится ASP-страница Connect .asp, позволяющая пользователям вводить регистрационные данные и передающая эти данные любому выбранному серверу.
Кроме этого, клиент RDP 5.1 предоставляет дополнительные функциональные возможности установки соединений с помощью командной строки. Для получения списка параметров можно воспользоваться командой mstsc / ?. Два параметра особенно полезны. Можно указать другой порт (протокол RDP по умолчанию использует ТСР-порт 3389), если приходится подключаться через брандмауэр. Кроме этого, можно подключиться непосредственно к консоли сервера, а не создавать новый сеанс.
Возможности установки соединений клиента RDP
Приложение Remote Desktop Connection (Подключение к удаленному рабочему столу) Mstsc предоставляет параметры для управления клиентами. Для запуска этого приложения воспользуйтесь командой Starts Programs1^ Accessories^Communications^Remote Desktop (Пуск^Программы^Стандартные^Связь^Подключение к удаленному рабочему столу). Примеры окон показаны на рис. 19.10 и 19.11.
Рассмотрим возможности, которыми можно управлять с клиента.
Размер рабочего стола. Рабочий стол сеанса может иметь любой размер, но не больше размера рабочего стола на базовом персональном компьютере. При запуске в полноэкранном режиме в нижней части экрана отображаются элементы управления, которые напоминают пользователю, что на экран выводится сеанс удаленного рабочего стола, а не действительный рабочий стол.
Комбинации клавиш для сокращенного вызова команд. Можно включить использование “горячих” клавиш внутри сеанса удаленного рабочего стола, а не в пределах базового рабочего стола. Это значительно упрощает работу пользователей, которые обнаруживают,
что любимая комбинация клавиш <Ctrl+Alt+Del> и кнопка Windows работают не так, как можно было ожидать.
Глубина цвета. Максимальная поддерживаемая глубина цвета составляет 24 бит, но, установив глубину цвета 16 или 15 бит, можно добиться повышения производительности.
>П>ПРис. 19.10. В окне Remote Desktop Connection (Подключение к удаленному рабочему столу) открыта вкладка Display (Экран)Рис. 19.10. В окне Remote Desktop Connection (Подключение к удаленному рабочему столу) открыта вкладка Display (Экран)Рис. 19.11. В окне Remote Desktop Connection (Подключение к удаленному рабочему столу) открыта вкладка Experience (Дополнительно)Рис. 19.11. В окне Remote Desktop Connection (Подключение к удаленному рабочему столу) открыта вкладка Experience (Дополнительно)
>П
>П
Рис. 19.10. В окне Remote Desktop Connection (Подключение к удаленному рабочему столу) открыта вкладка Display (Экран)
Рис. 19.10. В окне Remote Desktop Connection (Подключение к удаленному рабочему столу) открыта вкладка Display (Экран)
Рис. 19.11. В окне Remote Desktop Connection (Подключение к удаленному рабочему столу) открыта вкладка Experience (Дополнительно)
Рис. 19.11. В окне Remote Desktop Connection (Подключение к удаленному рабочему столу) открыта вкладка Experience (Дополнительно)
Перенаправление локальных устройств. Пользователь может отказаться от перенаправления дисков, принтеров и последовательных портов. Это позволяет защитить локальные файлы. На производительность выбор конфигурации не влияет.
Дополнительно. Пользователь может указать скорость подключения, и клиент автоматически отключит возможности, не подходящие для выбранной скорости.
Перенаправление консоли
Служба Terminal Service, Termservice устанавливается на каждый компьютер под управлением Windows Server 2003. Служба поддерживает как стандартные клиентские сеансы, так и непосредственное подключение к консоли. Второй вариант соответствует возможности удаленного управления.
Для подключения к консоли сервера запустите выполняемый файл Remote Desktop Connection (Подключение к удаленному рабочему столу) из командной строки с параметром /console (команда mstsc /console) и выберите интересующий сервер. При подключении произойдут два события.
Если учетная запись уже зарегистрирована на консоли сервера, сеанс перехватит управление консолью и консоль перейдет в заблокированное состояние.
Если кто-то другой зарегистрирован на консоли и подключающийся пользователь обладает правами администратора, текущий сеанс пользователя консоли будет принудительно завершен и консоль перейдет в заблокированное состояние.
Служба удаленного рабочего стола на сервере предоставляет возможность подключения до двух пользователей одновременно. Пользователи получают общий набор параметров конфигурации (в отличие от разных наборов параметров при использовании истинных служб терминалов). Эта возможность предназначена для администраторов, которые получают доступ к серверу с целью управления. Предоставление доступа пользователям, не обладающим правами администраторов, рассматривается в разделе “Управление правами удалённого доступа’’.
Удаленный рабочий стол и компьютеры PocketPC .
На установочном компакт-диске Windows Server 2003 предоставляется драйвер удаленного рабочего стола для компьютеров PocketPC. Этот драйвер подходит для использования на таких компьютерах, как Compaq iPaq. Пакет ActiveSync не поддерживает установку этого приложения, поэтому скопируйте соответствующий файл САВ на PocketPC и щелкните на файле САВ для его установки. Например, для установки на iPaq подходит файл rpc_SA1100 . cab.
Клиент не поддерживает 128-разрядное шифрование, поэтому установите шифрование данных на сервере службы терминалов в режим Client Compatible. Дополнительная информация доступна по адресу www. с ewindows . net / faqs/ terminal server-citrix. htm .
Если на компьютере PocketPC установлен модем CDPD (Cellular Digital Packet Data), подклю- !чение co скоростью 9600 бит/с обеспечит низкоскоростной, но надежный доступ к удаленному рабочему столу.
Перенаправление устройств
Предыдущие версии служб терминалов и удаленного рабочего стола от компании Microsoft предоставляли ограниченную поддержку перенаправления устройств. С выходом Windows NT 4.0 Terminal Server Edition (TSE) в регистрационные сценарии можно добавлять команды net use для подключения COM-порта к последовательному порту на клиенте. Это позволяет использовать модем или сканер штрих-кодов на клиенте. Начиная с Windows 2000, поддерживается перенаправление принтеров, но для этого драйверы принтера должны быть установлены на сервере.
Комбинация клиентов RDP 5.1 или 5.2 и сервера терминалов Windows Server 2003 обеспечивает поддержку новых возможностей перенаправления устройств.■
Буфер обмена
Диски
Принтеры (с автоматическим перенаправлением принтеров для клиентов Windows Server 2003, Windows ХР и Windows 2000)
Последовательные и параллельные порты (истинное перенаправление, а не использование net use).
Перенаправление звуковых данных
Все возможности перенаправления активизируются по умолчанию при подключении клиента по протоколу RDP 5.1 или 5.2 к серверу терминалов под управлением Windows Server 2003. Это относится и к клиентам предыдущих версий под управлением Windows NT 4.0, Windows 9х и Windows ME. Ниже приводится дополнительная информация о различных вариантах перенаправления.
Перенаправление буфера обмена
Эта возможность позволяет пользователям копировать содержимое буфера обмена между сеансом RDP и локальным рабочим столом, а также между различными сеансами RDP, если используется многосеансовый “тонкий” клиент. В операционной системе Windows 2000 эта
.Ий!»]'.Ий!»]'**3w»i Сега***3w»i Сега*4,87 GB4,87 GB2.68 GB2.68 GB26.0 GB26.0 GB31A-Inch Hoppy Disk Removable Disk CD Drive31A-Inch Hoppy Disk Removable Disk CD DriveSystem Folder System Folder System Folder System Folder System Folder System FolderSystem Folder System Folder System Folder System Folder System Folder System Folder* My Computer* My Computer-^Local Disk (С:)-^Local Disk (С:)Local DiskLocal DiskNetwork DrivesNetwork DrivesOtherOtherDisk from RemoteD... Disk from RemoteD... Disk from Remote D... Disk from RemoteD,.. Disk from RemoteD... Disk from RemoteD...Disk from RemoteD... Disk from RemoteD... Disk from Remote D... Disk from RemoteD,.. Disk from RemoteD... Disk from RemoteD...
.Ий!»]'
.Ий!»]'
**3w»i Сега*
**3w»i Сега*
4,87 GB
4,87 GB
2.68 GB
2.68 GB
26.0 GB
26.0 GB
31A-Inch Hoppy Disk Removable Disk CD Drive
31A-Inch Hoppy Disk Removable Disk CD Drive
System Folder System Folder System Folder System Folder System Folder System Folder
System Folder System Folder System Folder System Folder System Folder System Folder
* My Computer
* My Computer
-^Local Disk (С:)
-^Local Disk (С:)
Local Disk
Local Disk
Network Drives
Network Drives
Other
Other
Disk from RemoteD... Disk from RemoteD... Disk from Remote D... Disk from RemoteD,.. Disk from RemoteD... Disk from RemoteD...
Disk from RemoteD... Disk from RemoteD... Disk from Remote D... Disk from RemoteD,.. Disk from RemoteD... Disk from RemoteD...
возможность доступна в виде дополнительного пакета в составе Resource Kit, который называется Rdcl ip. Но установка этого пакета была связана с определенными сложностями.
Возможность перенаправления буфера обмена оказывается исключительно полезной. Ее можно использовать для получения копий экрана, передачи содержимого документов и даже для работы в командной строке. Главное — соблюдать осторожность и случайно не создавать составные (compound) документы при вставке. Если при установке объекта будет создана связь OLE со вставленным объектом через RDP-соединение, вставленный объект будет доступен только внутри сеанса RDP.
Перенаправление дисков
Для проверки возможности перенаправления дисков подключитесь к серверу терминалов Windows Server 2003 с помощью клиента RDP 5.1. Откройте окно Му Computer (Мой компьютер) и обратите внимание на нижнюю часть окна в разделе Other (Другие места). В названиях клиентских дисков указаны буква диска и имя клиентского компьютера (рис. 19.12).
Не ее VW Fevoite» Те* Help . j, Seerdi FoUerr 1
Ad»«,f7My Computer Name ~~ I Type
Hard Dirk Drive.
Devices with Removable Storage
•#3'ЛНорру(А:) ^NTF5 (D:) ^CD Drive (E:)
Xk on 'proiica.J Network Drive)
X* on SERVERI X* on SERVERI 3Jo on SERVERI XV on SERVERI X» on SERVERI Xе ™1 SERVERI
Puc. 19.12. Окно My Computer (Мой компьютер). Перенаправленные клиентские диски в окне сеанса RDP 5.1
Пользователи могут копировать данные между серверными и клиентскими дисками, если на сервере установлены соответствующие права доступа NTFS. Протокол RDP не настолько эффективен при передаче файлов, как протокол SMB, поэтому не ждите высокой производительности. Файлы можно перемещать с клиентских дисков на сетевые диски в ходе сеанса на сервере. Поток данных сначала отправляется на сервер по протоколу RDP, после чего передается перенаправителю SMB для доставки.по сети. Такое перемещение файлов требует дополнительных затрат времени и ресурсов центрального процессора.
Перенаправление принтеров
Результат перенаправления принтеров можно увидеть в окне Printers and Faxes (Принтеры и факсы) в окне сеанса RDP 5.2. Откройте это окно и на сервере терминалов.
Если подключиться с помощью клиента Windows 2000 или Windows ХР, в сеансе RDP будут отображены принтеры рабочей станции и принтеры, которые локально подключены на сервере терминалов (рис. 19.13). В окне Printers and Faxes (Принтеры и факсы) на сервере терминалов показаны все принтеры активных клиентов, а также локально установленные принтеры.
После завершения сеанса клиента принтеры удаляются из списка на сервере терминалов. После подключения клиента принтеры отображаются повторно. Информация о параметрах принтеров извлекается из кэшированной информации о клиенте.
№ и
^ Printers and Faxes
V^O HP LaserJet 551 (from 5ERVER1) j
In session 1
Xerox DocuPrint 180 EPS PS3
9*)act$
Рис. 19.13. В окне Printers and Faxes (Принтеры и факсы) показаны принтеры, перенаправленные с клиентского компьютера, на котором запущен клиент RDP 5.1
Перенаправленные принтеры используют порт RDP, который динамически создается на сервере и указывает на клиентский компьютер. Для просмотра перенаправления портов СОМ можно воспользоваться утилитой change port в пределах клиентского сеанса. Ниже представлен пример отчета этой утилиты:
C:\>change port
AUX = \DosDevices\COMl
GOMI = \Device\RdpDr\;COM1:2\tsclient\COMl
COM2 = \Device\Seriall
Обратите внимание, что порт COM2 перенаправляется на локальный интерфейс СОМ1 (Seriall), который объединяет порты (СОМ1:2) и отправляет их обратно на сервер терминалов с помощью Terminal Server director, Rdpdr. Параллельные порты перенаправляются с помощью такого же механизма, но не отображаются в списке портов.
Перенаправленные порты выводятся на сервере терминалов с помощью имен, соответствующих клиентскому сеансу, например TS0 04, CLIENT1: LPT1. Порты, соответствующие перенаправленным принтерам, используют имя устройства PRN, например TS011, CLIENT1: PRN1. Пример списка портов показан на рис. 19.14.
Сервер терминалов автоматически настраивает принтеры для клиентов Windows Server 2003, Windows ХР и Windows 2000, получая драйверы от клиентов. Для принтеров назначаются такие права доступа, что доступ могут получить только администраторы или пользователь, создавший сеанс. Пользователи не видят принтеры от других сеансов, а видят только принтеры, созданные вручную на сервере терминалов.
Для клиентов более старых версий принтеры необходимо создавать вручную и перенаправлять на сервер терминалов. Это связано с тем, что сервер терминалов не может получить соответствующий драйвер автоматически. Создайте принтер с помощью мастера добавления принтеров и выберите один из перенаправленных клиентских портов (LPT или СОМ) в качестве целевого. Для просмотра списка портов должен быть установлен пользовательский сеанс.
^ Xerox DoctiPrrnt 180 IPS PS3 PropertiesK^ КЗ
Genette] Shamg PW* | Advanced | Securty] Device SvHngi|
^ Xerox DoctPmll 80 EPS PS3
Print to Iha fcEovmg polfv). Dooumort* «Л pnit to the Ini Im cheokadport
Port 1 Decratkon I PrinterI *1
' □ COM3: Serial Port<1 j
□ COM4: Serial Port1
D FILE: Prim IO Fie: |
■ НЩДНШЕН8ШЯЯШНННИИИВНЯ1
, □ TS003 SERVER1: COM1! i
□ TS0O2 SERVER1: COM2|
J □ TS0O1 SERVER1: LPT13‘ 'j
Add Port...[ Delete Pon | Cori»» Port.. | I
U'Eneblrtfitirachmteiupppit 1151 l]
Г* Enable printer pooliig■i
| OK | Canoe! | Аи»
Рис. 19.14. Список портов на сервере терми-/
налов, в котором показаны перенаправленные пользовательские порты
На клиенте более старой версии принтер должен быть подключен к порту LPT или СОМ. Перенаправление принтера на сервере терминалов для USB-порта не поддерживается, поскольку порт USB не “отображается” до момента использования, как элементарная частица, которая возникает из ниоткуда в окрестностях черной дыры.
Задания на печать полностью визуализируются на сервере терминалов до отправки на клиентский принтер по протоколу RDP. Это позволяет избежать конфликта драйверов. Для принтера должен быть установлен драйвер, совместимый с Windows Server 2003, Windows ХР или Windows 2000. Для дешевых принтеров, которые предназначены для потребительских настольных компьютеров под управлением Windows 9х или Windows ME, такие драйверы могут не существовать. После широкого распространения Windows ХР на рынке рабочих станций эта ситуация должна измениться.
Перенаправление звуковых данных
Многие приложения воспроизводят звуковые сигналы. Без перенаправления звуковых данных звуковые сигналы будут воспроизводиться на сервере, что будет только весе- лить/раздражать администратора в серверной комнате. Перенаправление звуковых данных позволит обрабатывать звук на клиенте.
Никаких проблем кодирования не возникает, поскольку поток декодируется на сервере и упаковывается для доставки клиенту по протоколу RDP. Например, в процессе написания этой книги автор прослушивает песню “Dead Parrot” в исполнении Monty Python (www. montypython.net/fullsketches.php), которая передается в окно Internet Explorer в сеансе удаленного рабочего стола, а из него— на компьютер автора по протоколу RDP. Пользователь может прослушивать музыкальный компакт-диск, смонтированный на сервере терминалов, если администратор достаточно обезумел, чтобы вставить диск в привод.
Для повышения производительности поток данных передается средствами протокола UDP. Если при воспроизведении потока изменится пропускная способность канала, клиент и сервер смогут автоматически “договориться” о новых параметрах потока.
Протокол RDP плохо приспособлен для воспроизведения видеофрагментов. Поддерживается небольшая частота кадров, и многие кадры выпадают из потока. Кроме этого, часто теряется качество аудиопотоков при повышении нагрузки на сервер терминалов. Эту возможность стоит использовать только в случае необходимости.
Для управления перенаправлением звуковых и видеоданных, а также управления другими возможностями перенаправления можно воспользоваться окном Properties (Свойства), чтобы подключить RDP на консоли Terminal Services Configuration (Конфигурация служб терминалов). Все параметры доступны на вкладке Client Settings (Параметры Клиента).
Безопасность сервера терминалов
Безопасность удаленного рабочего стола и сервера терминалов, в основном, связана со следующими вопросами.
■ Что защищает поток данных RDP между клиентом и сервером?
■ Как создать RDP-соединение через брандмауэр?
■ Как предотвратить повреждение файлов на сервере пользователями во время сеансов работы с сервером терминалов?
■ Как управлять удаленным доступом к серверу или рабочей станции?
Начнем с последнего вопроса.
Управление правами удаленного доступа
Многие администраторы Windows 2000 обнаружили, что возможность подключения к серверу терминалов зависит от прав доступа, назначенных подключению RDP-Tcp на консоли Terminal Services Connection (Подключения служб терминалов).
Ниже перечислены разрешения, связанные с соединением RDP-Tcp.
■ Query Information (Запрос информации)
■ Set Information (Установка сведений)
■ Remote Control (Удаленное управление)
■ Logon/Logof f (Вход в систему/Выход из системы)
■ Message (Сообщение)
■ Connect/Disconnect (Подключить/Отключить)
■ Virtual Channels (Виртуальные каналы)
■ В операционной системе Windows Server 2003 предоставляется встроенная группа, которая называется Remote Desktop Users (Пользователи удаленного рабочего стола). Эта группа входит в список контроля доступа для подключения RDP-Tcp. В принятой по умолчанию конфигурации удаленного рабочего стола этой группе предоставлены права User Access (Доступ пользователя) и Guest Access (Гостевой доступ). Это соответствует разрешениям Query (Запрос), Logon (Вход в систему), Message (Сообщение) и Connect (Подключить). При полной установке служб терминалов группа Remote Desktop Users (Пользователи удаленного рабочего сТола) получает разрешение Full Control (Полный доступ) для подключения RDP-Tcp.
В операционной системе Windows Server 2003 предоставляется новый параметр назначе- . ния прав пользователей (User Rights Assignment), который называется Allow Logon Through Terminal Services (Разрешить регистрацию через службы терминалов). Последнее разрешение предоставляется локальной группе пользователей Remote Desktop Users (Пользователи удаленного рабочего стола) после установки Terminal Services. Членство в этой группе позво-
ляет пользователям подключаться с помощью RDP-сеанса, даже если явные разрешения на подключение на консоли не предоставлялись. ।
Кроме этого, существует учетная запись Remote Assistant (Удаленный помощник), которой предоставлено право доступа Full Control (Полный доступ) для подключения RDP-Tcp. Эта учетная запись используется для предоставления доступа пользователям, которые применяют Remote Assistant для работы на сервере или рабочей станции. По умолчанию эта учетная запись отключена. Она используется только для временных подключений. Если удалить эту учетную запись на локальном компьютере, подключение к компьютеру с помощью Remote Assistant окажется невозможным, хотя удаленный рабочий стол будет оставаться доступным.
На рабочих станциях под управлением Windows ХР (а не Windows Server 2003) предоставляется еще один уровень безопасности для удаленного рабочего стола: для установки соединения необходимо, чтобы для учетной записи был задан пароль. По умолчанию для учетных записей с пустым паролем соединение по сети с рабочей станцией под управлением Windows ХР запрещено.
Блокировка конфигурации системы
При установке служб терминалов (Terminal Services) на Windows Server 2003 Enterprise Edition будет выдан запрос на выбор между Full Security (Полная безопасность) и Relaxed Security (Ослабленная безопасность). При выборе варианта Full Security (Полная безопасность) пользователям будет запрещена запись или изменение системных файлов и параметров системного реестра.
Это может привести к проблемам при использовании устаревших приложений, которые требуют доступа к файлам в системном каталоге или записям системного реестра, защищаемым при выборе варианта Full Security (Полная безопасность). Если такие приложения установлены на компьютере, то установку служб терминалов придется выполнить с параметром Relaxed Security (Ослабленная безопасность).
Для переключения между Full Security (Полная безопасность) и Relaxed Security (Ослабленная безопасность) можно воспользоваться параметром консоли Terminal Services Configuration (Настройка служб терминалов). Выделите пиктограмму Server Settings (Параметры сервера). Параметры будут показаны в правой панели (рис. 19.15).
® 1м г [Terminal Service LMihriuriiliun bervfi *»ethno<J
Mt Mtn Wm H* _
^*~Tennhal Services Configuration GsSE^ZZZZZiZZ^^
—1 Conoecttons, |g)D*t= temporary folders on exitYesI
л, Igjju,, temporary folders per sessionYesj
ISQActive DesktopEnableI
^Permission CompatibilityFul Security|
^Restrict each user to one sessionNoj
Puc. 19.15. На консоли Terminal Server Configuration Manager (Диспетчер настройки служб терминалов) отображаются параметры сервера
Параметр Full Security (Полная безопасность) объекта Server Settings (Параметры сервера) не является заменой полной блокировки сервера терминалов. Этот параметр защищает только файлы операционной системы в каталоге \Windows, совместно используемые файлы в ка-
талоге \Program Files и критически важные записи в разделе системного реестра HKLM. Все остальные папки придется просмотреть самостоятельно и определить лучший способ их защиты от скучающего, глупого или злонамеренного пользователя.
По возможности пользователям служб терминалов необходимо запретить доступ в Интернет или как минимум установку приложений, чтобы не позволить устанавливать приложения из сети. Для этого можно воспользоваться следующими групповыми политиками.
Set Path for Roaming TS Prof lies (Установить путь к перемещаемым профилям сервера терминалов). Эта политика запрещает пользователям перемещаемых профилей копировать собственные папки на сервер терминалов, поскольку в папках могут содержаться выполняемые файлы. Укажите совместно используемый ресурс, на котором пользователи будут хранить профиль при работе на сервере терминалов.
Do Not Allow Drive Redirect ion, (Запретить перенаправление дисков). Эта политика запрещает пользователям копировать файлы из персонального компьютера на сервер терминалов. Иногда пользователи хранят выполняемые файлы в домашних каталогах, поэтому данное решение не является идеальным.
Loopback Processing (Обработка по методу обратной петли). Эта политика позволяет применять пользовательские политики из объекта групповой политики, связанного с организационной единицей компьютера, а не организационной единицей пользователя. Это позволяет защитить конфигурацию сервера терминалов от изменения пользовательскими политиками.
Always Prompt Client for Password Upon Connection (Всегда запрашивать пароль при подключении). Эта политика защищает администратора от случайного отключения требования регистрации в объекте RDP-Tcp. Без этого требования пользователи смогут установить собственные регистрационные данные в Remote Desktop Connection. Этот файл может использоваться другими пользователями для получения доступа.
Allow Reconnection From Original Client Only (Разрешить повторное подключение только оригинальному клиенту). Эта политика запрещает пользователям отключаться на одном компьютере и подключаться на другом.
Internet Explorer — Security Zones — Use Only Machine Settings (Internet Explorer — зоны безопасности — использовать только параметры компьютера). Эта политика запрещает пользователям обходить параметры зон безопасности и загружать элементы управления AcitveX, Javabeans, файлы Shockwave и другие запрещенные данные.
Prohibit Access to the Control Panel (Запретить доступ к Панели управления). Эта политика запрещает пользователям изменять и исследовать параметры системы с помощью Control Panel (Панель управления).
Prevent Access to the Command Prompt (Ограничить доступ'к приглашению командной строки). Эта политика запрещает пользователям обходить ограничения Explorer (Проводник).
* Restrict These Programs From Being Launched From Help (Ограничить запуск этих приложений из окна справки). Не забудьте о черных ходах. Службу Help and Support Center (Центр справки и поддержки) можно назвать логовом ярлыков для различных запрещенных приложений.
Remote Control Settings — View Session Without User's Permission (Параметры удаленного управления — просмотр сеанса без разрешения пользователя). Это противоречивая политика, но ничто не делает людей более честными, чем осознание возможности наблюдать без предупреждения. Одна эта политика в комбинации со стремлением управляющего персонала наказывать , нарушителей может быть намного эффективнее, чем любые параметры блокировки.
В этом списке перечислена только небольшая часть инструментов управления работой пользователей на сервере терминалов. Стоит отметить, что активная поддержка со стороны управляющего персонала очень важна для управления общим рабочим местом на сервере терминалов.
Серверы терминалов и брандмауэры
Протокол RDP использует ТСР-порт 3389. Администраторы сети могут блокировать этот порт на брандмауэре. И их не стоит винить. В конце концов, именно их обвинят в потере информации или другом ущербе, если изменение конфигурации приведет к появлению уязвимого места.
Если в брандмауэре открыты только некоторые порты, сервер терминалов и клиентов RDP можно настроить на использование другого, нестандартного порта.
Сначала настройте порт RDP в системном реестре на сервере терминалов. Эта информация указывается в следующей записи системного реестра:
Раздел: HKLM\System\CurrentControlSet\Control\Terminal Server\Wds\Rdpwd\Tds\ TCP
Запись: PortNumber
Значение: 3389 (reg_dword)
Замените значение записи PortNumber номером порта, открытого на брандмауэре. Номер порта необходимо указывать в десятичной форме, а не в шестнадцатеричной.
После этого измените номер порта в следующей записи системного реестра:
I
Раздел: HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations Запись: PortNumber
Значение: 3389 (reg_dword)
Перезагрузите сервер для инициализации нового порта. Для проверки ожидания запросов на новом порту воспользуйтесь командой netstat -а.
Для подключения клиента удаленного рабочего стола к серверу через новый порт запустите клиент с использованием параметра в командной строке, который определяет номер порта: mstsc /v:serveri:6500
Если для подключения пользователей к серверу терминалов через брандмауэр используется элемент управления ActiveX в интерфейсе TSWeb, настройте Web-страницу на перенаправление пользователей с помощью другого порта. Необходимая последовательность действий рассматривается в процедуре 19.4.
Процедура 19.4. Изменение принятого по умолчанию RDP-порта в интерфейсе TSWeb
Найдите файл Connect. asp в каталоге \Windows\Web\TSWeb.
Откройте файл в редакторе Notepad (Блокнот) и найдите строки, начинающиеся с MsTsc, AdvancedSettings2.
Добавьте строку сразу после найденных записей. Строка должна выглядеть следующим образом:
MsTsc.AdvancedSettings2.RDPPort = 3389
Замените значение 3389 номером порта, на котором сервер терминалов ожидает входящих запросов.
Эта процедура не работает для серверов Windows 2000, поскольку элемент управления ActiveX, предоставляемый в составе Windows 2000, не экспортирует методы AdvancedSettings2. Это ограничение можно обойти. Для этого придется скопировать папку Tsweb с сервера под управлением Windows Server 2003 на сервер под управлением Windows 2000 и создать обший
ресурс для этой папки. Если клиент уже загрузил элемент управления ActiveX для Windows 2000, элемент управления придется удалить перед подключением клиента к новому совместно используемому ресурсу.
Шифрование потока данных
Поток данных RDP всегда шифруется. В операционных системах Windows Server 2003, Windows ХР и Windows 2000 SP2 клиенты RDP 5.1 и RDP 5.2 используют 128-разрядное шифрование. Более старые клиенты, не обладающие возможностями надежного шифрования, используют 56-разрядное шифрование в протоколе RDP 5.0 и 40-разрядное шифрование в протоколе RDP 4.0.
Уровень безопасности настраивается на консоли Terminal Services Connection (Подключения служб терминалов). Откройте окно Properties (Свойства) для пиктограммы RDP-Tcp. На вкладке General (Общие) отображается раскрывающийся список Encryption Level (Уровень шифрования). В этом списке предоставлено два варианта.
Client Compatible (Совместимый с клиентом). Этот вариант позволяет клиентам более старых версий запрашивать 56- и 40-разрядное шифрование.
High (Высокий). Этот вариант подразумевает принудительный выбор 128-разрядного шифрования. В таком случае устаревшие клиенты не смогут подключаться к серверу удаленных терминалов.
Поток данных, зашифрованный с помощью 128-разрядного алгоритма RC4, очень устойчив к атакам, но, если необходима более безопасная среда для обмена начальной информацией о сеансе, рассмотрите возможность использования протокола Citrix SecurelCA. Этот протокол использует метод обмена ключами Диффи-Хеллмана и поддерживает 128-разрядный алгоритм RC5.
Управление ресурсами
Пользователи рассматривают подключения сеансов сервера терминалов крайне просто. Из соображений скорости пользователи подключаются и отключаются, а не завершают сеанс с повторной регистрацией. Особенно это касается “тонких” клиентов, загрузка которых занимает десятки секунд.
Если допустить накопление критической массы отключенных сеансов, ресурсы сервера терминалов закончатся. Для управления тайм-аутами сеансов можно воспользоваться консолью Terminal Services Configuration (Настройка служб терминалов). Откройте окно Properties (Свойства) для объекта RDP-Tcp и активизируйте вкладку Sessions (Сеансы), которая показана на рис. 19.16.
Клиент RDP может запросить значения тайм-аутов для завершения отключенного сеанса, ограничения для активных сеансов и ограничения для неактивных сеансов. Обычно эти значения запрашиваются как бесконечные.
Установите флажок Override User Settings (Заменить параметры пользователя) и установите предельный срок, в течение которого пользователи должны восстановить отключенный сеанс. Этого времени должно быть достаточно для повторного подключения в случае разрыва коммутируемого соединения или перебоя питания, но задержка не должна поощрять отключение вместо завершения сеанса. Опыт автора этой книги показывает, что вполне достаточно предельного периода продолжительностью 15 минут.
Убедитесь, что в качестве принятого по умолчанию действия при превышении предельного периода выбран переключатель End Session (Завершить сеанс). Это позволит избежать накопления отключенных сеансов.
Если пользователь завершает более одного сеанса при повторном подключении, пользователю предоставляется список. Для переключения в другой сеанс и правильного его завершения
можно воспользоваться утилитой с интерфейсом командной строки tscon (дополнительная информация об этой утилите приводится далее в этой главе). Кроме этого, можно воспользоваться возможностью удаленного управления и перехватить управление над таким сеансом.
Рис. 19.16. Вкладка Sessions (Сеансы) окнаРис. 19.16. Вкладка Sessions (Сеансы) окнасвойств объекта RDP-Tcpсвойств объекта RDP-Tcp
Рис. 19.16. Вкладка Sessions (Сеансы) окна
Рис. 19.16. Вкладка Sessions (Сеансы) окна
свойств объекта RDP-Tcp
свойств объекта RDP-Tcp
С точки зрения безопасности могут потребоваться включение возможности Allow Reconnection (Разрешать повторное подключение) и установка переключателя From Previous Client (От предыдущего клиента). Этот параметр запрещает пользователям “бродить по этажу”, подключаясь с разных компьютеров. Кроме этого, система защищается от бесполезного увеличения количества лицензий.
Лицензирование
Лицензирование сервера терминалов является сложной темой. В базе знаний компании Microsoft хранится около двух десятков статей, связанных с лицензированием сервера терминалов. И это только основные статьи по данной теме. Наиболее актуальную информацию можно получить при обсуждении условий с поставщиком решений на базе продуктов Microsoft (VAR), имевшим дело с серверами терминалов. Большинство таких поставщиков не понимают сложности лицензирования и в итоге заказчику приходится переплачивать. Ниже приведено краткое описание ситуации.
Для начала, если не планируется использование истинных служб терминалов для общего доступа к приложениям в многопользовательской среде, остановитесь прямо сейчас. Две бесплатные лицензии на удаленный рабочий; стол предоставляются в составе каждой копии Windows Server 2003. В группу Remote Desktop Users (Пользователи удаленного рабочего стола) можно вносить любого пользователя, а не только администратора. Обратите внимание: это ненастоящая многопользовательская среда. Изменения конфигурации, внесенные пользователем с правами администратора, будут оказывать влияние на всех пользователей.
Для соединения с сервером терминалов потребуется лицензия на доступ клиента TS Client Access License (TS CAL). Лицензия TS CAL ничем не отличается от лицензии на Windows ХР,
поэтому использование сеанса сервера терминалов соответствует использованию Windows ХР. Кроме этого, нужна стандартная лицензия на доступ клиента, которая предоставляет возможность сетевого подключения к серверу. .
Если подключаться к серверу терминалов с рабочей станции под управлением Windows ХР, все равно нужна TS CAL. В этом отличие от старых служб терминалов. Кроме этого, нужна стандартная лицензия на доступ клиента. Если планируется установка Citrix MetaFrame, то, кроме клиентских лицензий на сервер MetaFrame и клиент ICA'ot Citrix, нужны лицензии TS CAL и стандартная CAL от компании Microsoft. Общая стоимость лицензий клиентов на рабочее место без оптовой скидки может составить 400 долларов и даже больше. Если существует 100 клиентов сервера терминалов, придется потратить достаточно большую сумму только Для того, чтобы положить в ящик пару сертификатов.
Если сервер терминалов планируется использовать для анонимных некоммерческих подключений по Интернет, можно приобрести лицензию Internet Connector. Цена этой лицензии, позволяющей до 200 одновременных соединений, составляет порядка 10 000 долларов. Цена может возрасти, так как компания Microsoft развивает свою модель ценообразования. Такая лицензия не поддерживает аутентификации пользователей. Среди покупателей такой лицензии встречаются крупные организации, которые используют службы терминалов для предоставления удаленных рабочих столов своему мобильному персоналу.
Серверы лицензирования
В течение 120 дней после установки служб терминалов необходимо установить службу лицензирования служб терминалов (Terminal Services Licensing — TSL) как минимум на одном контроллере домена. Для этого в Control Panel (Панель управления) можно воспользоваться аплетом Add/Remove Programs (Установка и удаление программ). Служба лицензирования должна быть установлена на контроллере домена Active Directory, так как для ее поиска серверы терминалов используют запросы LDAP. При использовании изолированного сервера служба устанавливается на сервер терминалов.
База лицензий использует стандартный механизм Microsoft Jet. Расположение базы данных выбирается во время установки службы лицензирования. По умолчанию база данных сохраняется в каталоге \Windows \System3 2 \LServer и называется TLSLic . edb.
Сервер терминалов обнаруживает службу лицензирования с помощью запроса к базе данных Active Directory. После обнаружения служба лицензирования будет использована для получения лицензий. Служба лицензирования не предоставляет пул лицензий для совместного доступа. В крупном офисе она должна хранить больше лицензий, чем такая же служба в небольшом офисе.
При установке службы лицензирования мастер установки предлагает выбрать между моделями домена/рабочей группы и предприятия.
Если выбрать модель предприятия, служба лицензирования будет выдавать лицензии любому клиенту из любого домена в пределах сайта. Если выбрать модель домена/рабочей группы, служба лицензирования будет выдавать лицензии любому клиенту в пределах домена, не обращая внимания на сайты. _
Если используется лес из нескольких доменов, лучше остановиться на модели предприятия. Но это может усложнить распространение лицензий на удаленные сайты. Серверы терминалов не пытаются искать службу лицензирования в других сайтах, поэтому в пределах каждого сайта с сервером терминалов должна быть установлена служба лицензирования.
Служба лицензирования должна быть активизирована путем подключения к клиринговому центру Microsoft через Интернет или с помощью звонка в службу поддержки для получения номера инициализации. Активация не предоставляет дополнительных клиентских лицензий. При активации просто предоставляется цифровой сертификат, который уникально идентифицирует службу лицензирования в базе данных компании Microsoft. Активация службы лицензирования никак не связана с процессом Windows Product Activation (WPA), кроме использования похожей методологии.
Если устанавливается MetaFrame, придется установить сервер лицензирования для клиентских лицензий ICA. Эти лицензии более гибкие, чем лицензии на доступ к серверу терминалов.
После инициализации службы лицензирования в нее нужно загрузить клиентские лицензии на доступ к серверу терминалов. Эти лицензии предоставляются компанией Microsoft или авторизованным поставщиком решений. Клиентские лицензии предоставляются в форме сертификатов с 25-значным номером. Этот номер необходимо ввести на консоли Licensing Manager (Диспетчер лицензирования), который свяжется с компанией Microsoft по сети Интернет. После проверки действительности клиентских лицензий на доступ сервер Microsoft предоставит код авторизации, который встроен в службу лицензирования. Пакеты лицензий доступны в составе различных программ, которые называются соглашениями (agreements). Если открыть окно Properties (Свойства) для сервера лицензирования и перейти на вкладку Licensing Program (Программа лицензирования), можно будет выбрать одно из соглашений (рис. 19.17).
Изменение имени службы лицензирования, а также перемещение или удаление невозможны. Если это сделать, в жертву будут принесены лицензии, которые хранятся на сервере. При необходимости лицензии можно перенести на другой сервер лицензирования, после чего изменить состояние сервера.
!l.<r ensinq Wizard Properties
Eich ftinMWiwi dmМжиИТмШ Saw tarwIM
вцмМо mantoVw «амгЬоц KOMtad lljwpiKiMMdygur fcanw
Microsoft Open LicenseMicrosoft Open LicenseWhwteUee:WhwteUee:VicltiB PtogrjMK |License Pak (Retail Purchase)
Microsoft Open License
Microsoft Open License
WhwteUee:
WhwteUee:
CancelCancelEnterprise agreement Campus agreement School agreement abon Services agreement ther Volume License agreement --наедет
Cancel
Cancel
Рис. 19.17. Консоль Terminal Server License Manager (Диспетчер лицензирования сервера терминалов). Открыта вкладка Licensing Program (Программа лицензирования) окна Properties (Свойства) для сервера лицензирования
Маркеры лицензий доступа клиентов к серверу терминалов
При подключении к серверу терминалов сервер лицензирования выдает маркер (token) лицензии TS CAL. Этот маркер кэшируется на всех клиентах. Все лицензии TS CAL выдаются на рабочее место. Билет позволяет лицензированному клиенту подключаться к любому серверу терминалов в пределах леса. .
Принцип предоставления лицензий TS С AL на рабочие место может застать администратора врасплох, если администратор к этому не готов. Например, если пользователь сервера терминалов перемещается по двадцати удаленным офисам и подключается с рабочей станции в каждом офисе, на этого пользователя будет потрачено двадцать клиентских лицензий TS CAL.
Проблемы лицензий TS CAL на доступ к серверу терминалов в операционной системе Windows 2000 были исправлены в Service Pack 3. Проблема была связана с устройствами,
которые получали клиентскую лицензию на доступ к серверу терминалов, но никогда не подключались к серверу терминалов. С исправлением вводилась транзакция лицензирования, состоящая из двух этапов.
На первом этапе использовался временный маркер доступа, срок действия которого истекал в диапазоне случайного значения от 52 до 119 дней. Если пользователь регистрировался на сервере терминалов в течение срока действия маркера, билет превращался в нормальный маркер клиентской лицензии TS CAL.
Если пользователь не подключался к серверу терминалов с данного устройства, клиент рабочей станции продолжал получать временные билеты, а срок действия уже полученных билетов истекал и они возвращались в пул билетов. Это позволило защитить лицензии от потери на некорректно работающих устройствах.
Если с этих рабочих станций больше никто и никогда не подключался к серверу терминалов, можно подумать, что потрачены лишние деньги. Но лицензионное соглашение позволяет выполнить однократное перемещение лицензий TS CAL на другое устройство. Кроме этого, лицензию можно переместить в случае отказа устройства. Для этого нужно позвонить в клиринговый центр лицензирования служб терминалов, поддерживаемый компанией Microsoft. Процесс занимает несколько минут.
' Хранилище маркеров клиентских лицензий TS CAL и Windows NT
Клиентский персональный компьютер хранит маркеры лицензий доступа клиентов к серверу терминалов (TS CAL) в системном реестре в разделе HKLM\Software\Microsoft\ MSLicensing\Store\LicenseOOO (или LicenseOOl).
Если указано более одной лицензии, лицензия TS CAL имеет идентификатор продукта 41 00 30 00 32 00 00 00.
Клиент Windows NT может сталкиваться с проблемами при получении нескольких лицензий TS CAL (по одному на каждого пользователя, который регистрируется на сервере терминалов с этой рабочей станции). Это связано с тем, что пользователь не имеет достаточных прав на доступ к разделу MSLicensing. Для предоставления группе Authorized Users (Прошедшие проверку) права Full Access (Полный доступ) для этого раздела можно воспользоваться утилитой Regedt32.
Для удаления маркера с клиентского компьютера можно удалить весь раздел License###. Не забудьте восстановить маркер на сервере лицензирования, обратившись в службу поддержки клирингового центра.
Если на сервере лицензирования заканчиваются лицензии, клиентам без маркеров выдаются временные маркеры на 90 дней. Если в течение 90 дней на сервер лицензирования добавить лицензии доступа клиентов к серверу терминалов, клиенты обменяют временные билеты на постоянные.
Автоматическое лицензирование
Как было сказано в начале этого раздела, приобретать лицензии TS CAL не требуется, если подключение к серверу осуществляется с рабочей станции под управлением Windows ХР. Но сервер лицензирования отслеживает эти подключения в специальном встроенном пуле. Это неограниченный пул, который используется исключительно для административной оценки.
Автоматическое лицензирование может привести к дополнительным сложностям при переходе с Windows 2000 на серверы под управлением Windows Server 2003 и клиенты под управлением Windows ХР. Клиенты более старых версий продолжают использовать полученные маркеры лицензий доступа клиентов к серверу терминалов, но современные клиенты требуют лицензий TS CAL. По умолчанию при исчерпании пула лицензий для Windows 2000 сервер лицензирования будет выдавать клиенту Windows 2000 лицензию для Windows ХР. Это позволяет упростить наполнение сервера лицензирования новыми лицензиями.
Чтобы поддержать отдельные хранилища лицензий и избежать накопления лицензий модернизации, автоматическую модернизацию лицензий можно заблокировать. Соответствующая групповая политика называется Prevent License Upgrade. Эта групповая политика находится в разделе Computer Configuration!* Administrative Templates*Windows Components1* Terminal Services^Licensing (Конфигурация компьютера1* Административные шаблоны1* Компоненты Windows'* Службы терминалов1* Лицензирование).
Если клиенту Windows 9х выдан маркер клиентской лицензии TS CAL и этот клиент модернизирован до Windows ХР, лицензию можно вернуть в пул для предоставления другому клиенту более старой версии. Для такого возврата требуется позвонить в службу поддержки клирингового центра.
Если службы лицензирования работают под управлением ознакомительной версии операционной системы Windows Server 2003, никогда не устанавливайте лицензии на такой сервер. Лицензии будут потеряны при завершении ознакомительного периода. Теоретически их можно восстановить, позвонив в службу поддержки клирингового центра, но лучше заранее избежать этих неприятностей.
Удаленное управление
Консоль Terminal Services Manager (Диспетчер служб терминалов) позволяет реализовать удаленное управление или сеанс затенения (shadowing) пользователя. Это позволяет администратору или персоналу службы поддержки диагностировать проблемы или обучать пользователей.
Определение номера телефона службы поддержки клирингового центра
Если возникла необходимость позвонить в службу поддержки клирингового центра, то для получения номера телефона в вашей стране можно воспользоваться консолью Licensing Manager.
Откройте окно Properties (Свойства) для сервера.
Активизируйте вкладку Connection Method (Метод соединения).
Выберите страну и щелкните на кнопке ОК.
Щелкните правой кнопкой мыши на пиктограмме сервера и выберите Install Licenses (Установить лицензии) из контекстного меню. Запустится мастер лицензирования (Licensing Wizard).
Щелкните на кнопке Next (Далее). Откроется окно Obtain Client License Key Pack (Получить пакет ключей клиентских лицензий). В этом окне содержатся номер телефона и 35-символьная активационная лицензия для сервера терминалов.
В отличие от протокола ICA в Citrix MetaFrame, протокол RDP не поддерживает непосредственное затенение пользователя на консоли сервера терминалов. Необходимо подключиться к серверу терминалов и после этого открыть консоль Terminal Services Manager во время сеанса. Затенение в протоколе RDP использует возможность Т.120, которая обеспечивает групповую отправку данных для выбранных устройств.
На рис. 19.18 показаны окно консоли Terminal Services (Служба терминалов) и перечень активных сеансов пользователей. Чтобы применить затенение пользовательского сеанса, щелкните правой кнопкой мыши на пиктограмме пользователя и выберите из раскрывшегося меню команду Remote Control (Удаленное управление).
Перед тем как будет реализовано затенение сеанса пользователя, по умолчанию требуется получить от этого пользователя разрешение. После предоставления пользователем разрешения текущий сеанс прерывается и администратору предоставляется копия пользовательского сеанса. Поддерживается взаимодействие с сеансом пользователя для демонстрации необходимой последовательности действий или исправления проблемы.
AISlLl^l Z/JSl AJ AJ -BJ* Thb conoKW■^ Favorite servers ® ^ Al Listed ServersAISlLl^l Z/JSl AJ AJ -BJ* Thb conoKW■^ Favorite servers ® ^ Al Listed ServersSanaiI UwI Sew. I IDiSUtaIIdaTimel'9 SERVER2phxadminConsole0 Active9 SERVER2phxuser.RDP-Tcp#43 Active19 SERVER2administratorDisconnected1 Disconnected11SanaiI UwI Sew. I IDiSUtaIIdaTimel'9 SERVER2phxadminConsole0 Active9 SERVER2phxuser.RDP-Tcp#43 Active19 SERVER2administratorDisconnected1 Disconnected11
AISlLl^l Z/JSl AJ AJ -BJ
* Thb conoKW
■^ Favorite servers ® ^ Al Listed Servers
AISlLl^l Z/JSl AJ AJ -BJ
* Thb conoKW
■^ Favorite servers ® ^ Al Listed Servers
Sanai
I Uw
I Sew. I IDiSUtaI
IdaTimel
'9 SERVER2
phxadmin
Console
0 Active
9 SERVER2
phxuser.
RDP-Tcp#4
3 Active
1
9 SERVER2
administrator
Disconnected
1 Disconnected
11
Sanai
I Uw
I Sew. I IDiSUtaI
IdaTimel
'9 SERVER2
phxadmin
Console
0 Active
9 SERVER2
phxuser.
RDP-Tcp#4
3 Active
1
9 SERVER2
administrator
Disconnected
1 Disconnected
11
For Help, press Ft
Puc. 19.18. Список активных сеансов пользователей на консоли Terminal Services Manager (Диспетчер служб терминалов)
После завершения затенения нажмите комбинацию клавиш <Ctrl+*> (на цифровой клавиатуре), чтобы завершить этот сеанс и вернуться в собственный сеанс.
Для подключения к пользовательскому сеансу можно воспользоваться и командой shadow. Дополнительная информация приводится в разделе “Управление службами терминалов с помощью командной строки”.
Если необходимо включить затенение без разрешения пользователя, настройте подключение RDP-Tcp на консоли Terminal Services Configuration (Настройка служб терминалов), как описано в процедуре 19.5.
Процедура 19.5. Настройка затенения без разрешения
Для соединения RDP-Tcp откройте окно Properties (Свойства) и активизируйте вкладку Remote Control (Удаленное управление) (рис. 19.19)..
|RDP lip Рнци-П|RDP lip Рнци-ПID£IID£I
|RDP lip Рнци-П
|RDP lip Рнци-П
ID£I
ID£I
General ILogon Settogs j Sessions | Envronmenl
Remote Cored | Chart Setting* | NetwotkAdaptet | Pemweoni
You can me remote cortid to remote^ control or observe a war*» «mm
<• U« remote control wih date* user settings
1 C Do not alow remote control
IUte remote coi*d with the taiowing settings.
iTarecMretheuMf’ipomMontoctirtrdor dwervethesetaion. ,
isteed the Mowing check bote'
Puc. 19.19. Свойства соединения RDP-Tcp. Вкладка Remote Control (Удаленное управление)
Выберите переключатель Remote Control With The Following Settings (Использовать следующие параметры управления) и сбросьте флажок Require User's Permission (Запрашивать разрешение пользователя).
В группе Level Of Control (Уровень управления) выберите View the Session (Наблюдение за сеансом) или Interact With The Session (Взаимодействие с сеансом).
Управление службами терминалов с помощью командной строки
Существует набор утилит с интерфейсом командной строки, которые можно использовать для управления службами терминалов. Эти утилиты предоставляют разнообразные функциональные возможности. Ниже приведен краткий список наиболее часто используемых утилит.
change
query
reset
msg
tscon
shadow
tskill ■ tsshutdn
Утилита change
Для утилиты change доступны три параметра, с помощью которых запускаются выполняемые файлы для выполнения поставленной задачи.
change user (CHGUSER)
change logon (CHGLOGON)
change port (CHGPORT)
Команда change user
Команда change user позволяет изменить многопользовательский режим системы. Для этой команды можно использовать три параметра.
EXECUTE. Этот режим поддерживает раздельные файлы конфигурации приложений для каждого пользователя и используется по умолчанию. Стандартные серверы удаленного рабочего стола игнорируют этот параметр.
INSTALL. В этом режиме предоставляется возможность установки приложений, которые будут запускаться в многопользовательском режиме. Если не указать этот параметр при установке, система будет рассматривать приложение как однопользовательское и не будет хранить конфигурационную информацию для каждого пользователя отдельно.
QUERY. Запрашивает текущий режим.
В предыдущих версиях Windows и MetaFrame при установке приложений приходилось помнить о необходимости включения режима install. Когда в Control Panel (Панель управления) выбиралась пиктограмма Add/Remove Program (Добавить/удалить приложение) система автоматически переключалась в режим INSTALL, но приходилось вручную отвечать No (Нет) при попытках приложений установиться автоматически. Многие админист-
раторы забывали отключить автоматическую установку и в дальнейшем были вынуждены удалять и повторно устанавливать приложение в нужном режиме.
Сервер под управлением Windows Server 2003 автоматически переключается в режим INSTALL при установке приложения. После завершения установки открывается окно After Installation, в котором предоставляется информация о действиях, необходимых для переключения обратно в режим EXECUTE.
Команда change logon
Параметр logon используется для управления доступом к серверу терминалов по протоколу RDP. С помощью этого параметра можно заблокировать создание новых сеансов при установке приложения или при устранении неисправностей. Для запрета создания новых сеансов необходимо воспользоваться командой change logon /disable. Команда change logon / enable разрешает создание новых сеансов.
Команда change port
Этот параметр позволяет перенаправлять логический порт СОМ за пределами диапазона, поддерживаемого устаревшими приложениями, на порт с меньшим номером. Команда имеет следующий синтаксис: change port portx=porty.
Параметр query
Этот параметр состоит из двух элементов, каждый из которых является отдельным выполняемым файлом.
query process (quappsrv.exe). Этот параметр позволяет вывести список процессов, запущенных пользователем на сервере терминалов. В списке указываются имя сеанса, идентификатор сеанса, имя программы и идентификатор процесса. Эта информация оказывается полезной при диагностике пользовательского процесса.
query session (qprocess.exe). Этот параметр позволяет вывести список всех сеансов на сервере терминалов с указанием пользователя и устройства, а также состояния сеанса. Параметр /counter позволяет подсчитать активные, отключенные и повторно установленные сеансы.
query termserver (qwinsta. ехе). Этот параметр позволяет вывести список всех серверов терминалов в пределах домена. Информация извлекается из базы данных Active Directory или получается в ответ на широковещательные запросы.
query user (quser.exe). Этот параметр позволяет вывести список пользователей, запустивших сеансы на сервере терминалов, с указанием идентификатора сеанса, имени сеанса, периода отсутствия активности и времени регистрации.
query winsta (qwinsta.exe). Этот параметр предоставляет ту же информацию, что и query session.
Команда reset
Эта команда завершает сеанс пользователя и освобождает процесс. Не используйте ее, если пользователь не сохранил данные.
Утилита tscon
Утилита tscon позволяет подключаться к активному или отключенному сеансу сервера терминалов и незаменима для восстановления пользовательских сеансов при отключении и невозможности повторного подключения или прй повторном подключении и получении нового сеанса. Без этой утилиты старые сеансы оставались бы “без присмотра" и отключались
по достижении тайм-аута для отключенных сеансов. Утилита tscon позволяет переключиться в сеанс и выполнить правильное завершение сеанса с сохранением пользовательских данных из запущенных приложений.
Эта команда должна вводиться в пределах сеанса. Она не будет работать на консоли сервера. Необходимо знать идентификатор или имя сеанса, к которому необходимо подключиться. Для получения нужной информации можно воспользоваться командой query session. После получения информации о сеансе можно воспользоваться командой tscon <идентификатор_сеанса>.
При вводе этой команды администратор и пользователь отключаются от текущих сеансов (поддерживается последующее повторное подключение). После этого администратор подключается к пользовательскому сеансу, работающему в контексте безопасности пользователя. Для этого на сервере терминалов необходимо иметь административные привилегии.
Утилита shadow ’
Эта утилита связана с утилитой tscon. Утилиту shadow можно использовать для запуска сеанса удаленного управления для клиента сервера терминалов. Вместо замены сеанса, как это делает утилита tscon, утилита shadow создает второй экземпляр сеанса, который предоставляется администратору и пользователю одновременно. Использование команды tscon эквивалентно выбору Remote Control (Удаленное управление) на консоли Terminal Services Manager (Диспетчер служб терминалов).
Как и в случае утилиты tscon, эта утилита может использоваться только из сеанса на локальном сервере терминалов. Запустите команду query session для определения идентификатора пользовательского сеанса. После этого для удаленного управления пользовательским сеансом можно воспользоваться командой shadow <идентификатор>.
При вводе этой команды администратор отключается от собственного сеанса, а пользователю выдается запрос на разрешение удаленного управления сеансом. Такой затененный сеанс можно использовать для устранения неисправностей. В данном случае управление пользовательским сеансом перехватывается из командной строки, а не из консоли Terminal Services (Служба терминалов).
После завершения управления пользовательским сеансом (для этого необходимо нажать комбинацию клавиш <Ctrl+*> на цифровой клавиатуре) администратор восстанавливает собственный сеанс.
Продукты для "тонких" клиентов
Для максимального использования преимуществ служб терминалов, особенно с точки зрения снижения общей стоимости владения (ТСО), стоит рассмотреть развертывание устройств “тонких” клиентов. Это простые устройства под управлением Windows СЕ, которые подключаются к серверу терминалов по протоколу RDP или ICA. Большинство таких устройств оборудовано локальным последовательным или параллельным портом, а также шиной USB. Некоторые новые устройства оборудованы только шиной USB. Стоит приобретать только самые современные модели, поддерживающие протоколы RDP версий 5.1 и 5.2.
Преимуществами “тонкого” клиента являются гибкость и простота. Не гонитесь за дешевизной. Качественные устройства будут стоить от 400 до 600 долларов в зависимости от производительности, параметров видеосистемы и дополнительных возможностей, например, Web-браузера, локального привода компакт-дисков или даже локального жесткого диска. Некоторые “не-такие-уж-тонкие” клиенты на самом деле являются рабочими станциями под управлением Windows ХР в плотной “упаковке” и даже работают под управлением встроенной версии операционной системы Windows NT 4.0.
Производители “тонких" клиентов обычно закладывают большую разницу между ценой и себестоимостью (намного больше, чем для персональных компьютеров), поэтому боритесь за
скидки до последнего. Особенно при покупке большого количества устройств. Кроме этого, не все устройства оказываются одинаковыми, хотя спецификации могут совпадать.
Настаивайте на высокоскоростном видеоадаптере с большим объемом видеопамяти, сетевом адаптере Ethernet с пропускной способностью 100 Мбит/с, а также достаточном объеме локально^ оперативной памяти для поддержки нескольких сеансов одновременно.
По адресу www .thinclient.com доступен отличный Web-сайт, на котором можно найти руководства по выбору продуктов, информацию о ценах и сравнение различных возможностей устройств.
Удаленный помощник
На рабочих станциях под управлением Windows ХР запускается такая же служба Terminal Service (Termservice), как и на компьютере под управлением операционной системы Windows Server 2003. Но на рабочих станциях не поддерживаются виртуальные сеансы. Поддерживается только единственный консольный сеанс.
Система безопасности не позволяет администратору или простому пользователю просто подключиться к консоли рабочей станции под управлением Windows ХР. Пользователь должен “пригласить" другого пользователя для подключения к консоли с целью устранения неисправностей или обучения. Функция Remote Assistant (Удаленный помощник) напоминает множество других обучающих программ (которые называют “over-the-shoulder”), позволяющих сотрудникам службы поддержки удаленно работать на рабочей станции пользователя.
Функция Remote Assistant (Удаленный помощник) встроена и в операционную систему Windows Server 2003, но при наличии возможности установки двух соединений удаленного рабочего стола целесообразность использования Remote Assistant невысока.
Кроме этого, рабочие станции под управлением Windows ХР поддерживают несколько одновременных сеансов работы пользователей на одной физической консоли. Эта возможность называется быстрым переключением пользователей (Fast User Switching). Она включается только на изолированных рабочих станциях. Для ее включения необходимо специальное окно регистрации (GINA или Graphical Identification and Authentication). Теоретически существует возможность создания собственного окна GINA, но на момент написания книги только компания Microsoft создала окно .GINA, поддерживающее быстрое переключение пользователей. Если установить клиент для сетей NetWare или программу удаленного управления, например PC Anywhere, которая устанавливает собственные версии окна GINA, возможность быстрого переключения пользователей станет недоступной.
Включение удаленного помощника
На рабочих станциях под управлением Windows ХР функция Remote Assistance (Удаленный помощник) включается автоматически. Соответствующий параметр доступен в Control Panel (Панель управления) в аплете Network and Internet Connections (Сеть и подключения к Интернет). Щелкните на ссылке Remote Desktop (Удаленный рабочий стол) в левой панели окна.
Кроме этого, существует возможность активизировать подключения Remote Desktop (Удаленный рабочий стол) к рабочей станции под управлением Windows ХР. При включении этой возможности администратор сможет подключаться к рабочей станции без предварительного приглашения. В таком случае администратор перехватывает управление над консольным сеансом и консоль блокируется. Совместный доступ к консоли поддерживается только при использовании Remote Assistance (Удаленный помощник).
Для запуска Remote Assistance (Удаленный помощник) необходимо “приглашение” пользователя. Это приглашение может принимать одну из трех форм.
Мгновенное сообщение
Сообщение электронной почты
Файл
Приглашение в виде мгновенного сообщения
Несложно предположить, что эта возможность работает только в комбинации с Microsoft Instant Messenger и не поддерживается клиентами обмена мгновенными сообщениями от компаний AOL и Yahoo. Получатель приглашения должен работать под управлением Windows ХР или Windows Server 2003, чтобы были запущены наиболее актуальные версии Instant Messenger, клиента RDP и приложения Remote Assistance (Удаленный помощник).
Щелкните правой кнопкой мыши на списке собеседников и выберите из контекстного меню команду Ask For Remote Assistance (Пригласить удаленный помощник). Получателю будет отправлено приглашение. Получатель примет приглашение и создаст RDP-сеанс.
Перед подключением RDP-сеанса к рабочей станции пользователя пользователь должен щелкнуть на кнопке Yes (Да) при получении запроса “Do you want to let this person view your screen and chat with you” (Разрешить этому пользователю просмотр экрана и обмен сообщениями).
После решения всех формальностей у получателя приглашения открывается окно Remote Assistance (Удаленный помощник), в котором отображается внешний вид рабочего стола пользователя. Поддерживается обмен текстовыми или голосовыми сообщениями (рис. 19.20).
С hat HistoryС hat HistoryWaling for an answer...Waling for an answer...It*». vyuwtadteMjbowtil@h6ifie.mm/ 5r<evn Ум?* CW ^bektoWMow^ Actual Size
С hat History
С hat History
Waling for an answer...
Waling for an answer...
a 1Sto.1*m.wdb.D0C„- Мкадв *?rA
boswel@primenet.com is connected to M .boswel@home. com.
The connection status is
Welcome to Remote Assistance. To explore your options, dick htelp.M.bosweB@home,com is connected to bosweB@prirenet, com. The connection status is Screen View OnlyWelcome to Remote Assistance. To explore your options, dick htelp.M.bosweB@home,com is connected to bosweB@prirenet, com. The connection status is Screen View OnlyScreen View Only
Welcome to Remote Assistance. To explore your options, dick htelp.
M.bosweB@home,com is connected to bosweB@prirenet, com. The connection status is Screen View Only
Welcome to Remote Assistance. To explore your options, dick htelp.
M.bosweB@home,com is connected to bosweB@prirenet, com. The connection status is Screen View Only
Meer—i* entryMeer—i* entryAs insl The the cli<
Meer—i* entry
Meer—i* entry
Puc. 19.20. Окно Remote Assistance (Удаленный помощник)
Приглашенный пользователь может щелкнуть на кнопке Take Control (Принять управление) в меню в верхней части страницы и получить управление над консольным сеансом пользователя.
Для работы этого сеанса необходим доступ к ТСР-порту 3389 на всех промежуточных брандмауэрах. Чаще всего нежелательно, чтобы рабочие станции были доступны из внешнего мира, поэтому, закрыв порт 3389 на внешнем брандмауэре, можно реализовать возможность Remote Assistance (Удаленный помощник) только для внутреннего использования.
Отправка приглашения Remote Assistance (Удаленный помощник) в виде файла или сообщения электронной почты
Приглашение можно отправить по электронной почте. Приглашение будет иметь форму файла MsRclncident, который доставляется в виде вложения в сообщение. Кроме этого, можно сохранить этот файл с доставкой другим способом, если электронная почта недоступна.
Оба варианта доступны только в Help and Support Center (Центр справки и поддержки). Щелкните на ссылке Invite a Friend to Connect to Your Computer (Пригласить друга для подключения к компьютеру). Будет запущен небольшой мастер, выбирая варианты в окнах которого, можно отправить приглашение по электронной почте или сохранить файл приглашения. Интерфейс мастера показан на рис. 19.21.
Remote AssistanceRemote AssistancePick how you want to contact your assistantPick how you want to contact your assistantUse Windows Messenger ..Use Windows Messenger ..□ Ask a friend to helpQ Get help from MicrosoftQ Go to a Windows Web site forum□ Ask a friend to helpQ Get help from MicrosoftQ Go to a Windows Web site foruminvite this personinvite this personor prepare an e-mail invitationor prepare an e-mail invitationM.bosweMPhome.comM.bosweMPhome.com
Remote Assistance
Remote Assistance
Pick how you want to contact your assistant
Pick how you want to contact your assistant
Use Windows Messenger ..
Use Windows Messenger ..
□ Ask a friend to help
Q Get help from Microsoft
Q Go to a Windows Web site forum
□ Ask a friend to help
Q Get help from Microsoft
Q Go to a Windows Web site forum
invite this person
invite this person
or prepare an e-mail invitation
or prepare an e-mail invitation
M.bosweMPhome.com
M.bosweMPhome.com
Д About Support□ My Computer Information□ Advanced System Information□ System Configuration UtttyД About Support□ My Computer Information□ Advanced System Information□ System Configuration UtttyType your friend's name: |desktopadmin<§company.com Щ ContinueType your friend's name: |desktopadmin<§company.com Щ Continue
Д About Support
□ My Computer Information
□ Advanced System Information
□ System Configuration Uttty
Д About Support
□ My Computer Information
□ Advanced System Information
□ System Configuration Uttty
Type your friend's name: |desktopadmin<§company.com Щ Continue
Type your friend's name: |desktopadmin<§company.com Щ Continue
Puc. 19.21. Окно приложения Help and Support Center (Центр справки и поддержки) для запуска Remote Assistance (Удаленный помощник)
Файл MsRclncident является XML-файлом и содержит следующие компоненты:
<?хш1 version="1.О" encodings"Unicode" ?>
<UPLOADINFO TYPE="Escalated">
<UPLOADDATA USERNAME="bboswell"
RCTICKET="65538,1,222.222.222.222:3389 ;
xp-boswell.company.com:3389,
DyujDzxhdao46uOGBJO=,
wVcu/xeOrJp73FloZ7+SFYht2CKrKJbYXElZcD8szM8=,
SolicitedHelp,
LCrBVQ19e6A1723GWZY9xz/DYD4po/4jour9/cJG4b5yZZoT3viow==,
gQ90tB5A6qNglkeSwXNb0omFRC8="
RCTICKETENCRTYPTED="1"
DtStart="999091377"
DtLength="60"
PassStub="UP!9Udt*cemT4h L="t" />
</UPLOADINFO>
Ценные компоненты содержимого шифруются и подписываются. Для использования файла от получателя может потребоваться знание пароля. Отправитель должен передать пароль получателю любым способом.
Расширение MsRcincident связано с приложением Help and Support Center (Центр справки и поддержки). Можно выполнить двойной щелчок на файле и просмотреть его содержимое (рис. 19.22).
омчщм „. ew..омчщм „. ew..Q Ask a friend to helpQ Ask a friend to help□ Get help from Mcrosoft□ Get help from McrosoftQ Go to a Windows Web site forumQ Go to a Windows Web site forumRemote Assistance - Save InvitationRemote Assistance - Save Invitation
омчщм „. ew..
омчщм „. ew..
Q Ask a friend to help
Q Ask a friend to help
□ Get help from Mcrosoft
□ Get help from Mcrosoft
Q Go to a Windows Web site forum
Q Go to a Windows Web site forum
Remote Assistance - Save Invitation
Remote Assistance - Save Invitation
SeeJU* ,"SeeJU* ,"□ About Support, Q My Computer Information□ Advanced System Information□ About Support, Q My Computer Information□ Advanced System InformationFrom (the name you would Hee to appear on the invitation):
SeeJU* ,"
SeeJU* ,"
□ About Support
, Q My Computer Information
□ Advanced System Information
□ About Support
, Q My Computer Information
□ Advanced System Information
To lessen the chance that someone fraudulently gars access to your computer you can Kmit the time in which a recipient can accept a Remote Assistance invitation. Specify the duration that this Invitation wi remain open.
Сапом» >Сапом» >Q System Configiration - Utility
Сапом» >
Сапом» >
Puc. 19.22. Сообщение в отправляемом файле приглашения Remote Assistance, показанное в окне Help and Support Center (Центр справки и поддержки)
Отключение удаленного рабочего стола
Если необходимо защитить сервер, отключив доступ через Remote Desktop (Удаленный рабочий стол), выполните последовательность действий описанную в процедуре 19.6.
Процедура 19.6. Отключение удаленного рабочего стола
в операционной системе Windows Server 2003
Щелкните правой кнопкой мыши на пиктограмме Му Computer (Мой компьютер) и выберите из контекстного меню команду Properties (Свойства).
Активизируйте вкладку Remote (Удаленное использование) (рис. 19.23).
В группе Remote Desktop (Дистанционное управление рабочим столом) сбросьте флажок Allow Users То Connect Remotely То Your Computer (Разрешить удаленный доступ к этому компьютеру).
Щелкните на кнопке ОК, чтобы сохранить внесенные изменения.
Рис. 19.23. Свойства системы. Вкладка Remote (Удаленное использование)
В следующей главе
Мы приближаемся к тому волшебному моменту, когда система будет полностью готова к использованию. В следующей главе рассматриваются вопросы подготовки коммутируемого доступа, доступа через виртуальную частную сеть и установки соединений с Интернетом при помощи технологии NAT (Network Address Translation — трансляция сетевых адресов).
2020
20
20
Управление удаленным доступом и маршрутизацией
У
каждого поколения есть свои любимые игрушки для создания сложных структур.
Сначала были Tinker Toys, которые сменились Erector Sets, после которых появился конструктор LEGO. На смену LEGO приходит K’Nex. Игры, в которые мы играем в детстве, оказывают влияние на структуры, которые мы проектируем во взрослой жизни. Это наблюдение особенно справедливо по отношению к топологиям передачи данных. Сначала — “точка-точка”, после этого — “звезда”, затем — смешанная сеть, а теперь — трехмерные нейронные структуры.
Как системные администраторы, мы живем внутри структуры передачи данных, как будто они сделаны из стекла и бетона. Работая в крупной организации со значительным бюджетом отдела информационных технологий, можно отметить, что компоненты этой структуры обычно приобретаются для реализации определенной функции. Если необходимо маршрутизировать данные, покупается маршрутизатор. Если необходимо предоставить коммутируемый доступ к сети, приобретается точка сетевого доступа. Если необходимо обеспечить безопасность передачи данных в Интернете, приобретаются брандмауэры и создаются виртуальные частные сети.
Но средние и небольшие организации или подразделения организаций с недостаточным финансированием нуждаются в компонентах инфраструктуры, которые не требуют дополнительных капиталовложений и дополнительных специализированных знаний. Именно в этом случае полезен сервер общего назначения.
Службы инфраструктуры IP в операционной системе Windows Server 2003 более чем способны поддерживать среднее количество пользователей в среде предприятия. Точное количество пользователей зависит от предполагаемых задач и ожидаемой производительности. Например, группа из 30 пользователей “тонких” клиентов в главном зале центра обработки входящих звонков может использовать сервер под управлением Windows Server 2003 в качестве маршрутизатора для доступа к основному офису, где находится сервер терминалов. Если внешнее соединение обеспечивает достаточную пропускную способность, будет обеспечен достаточный уровень производительности. Но если от этого же сервера потребуется использование протокола Layer 2 Tunneling Protocol (L2TP) VPN с шифрованием IPSec, то одного
сервера может оказаться недостаточно. Необходимо поэкспериментировать и определить реальные возможности системы в конкретной ситуации.
В этой главе рассматриваются проектирование и развертывание служб маршрутизации и удаленного доступа под управлением операционной системы Windows Server 2003. Сначала приводится функциональное описание служб взаимодействия с внешними сетями, которые предоставляются в различных серверных пакетах и в составе операционной системы Windows ХР. Рассматриваются такие подробности, как методы аутентификации, которые позволяют обеспечить необходимый уровень безопасности системы. После этого рассматривается последовательность действий по предоставлению пользователям перечисленных ниже возможностей.'
Доступ к частной сети посредством коммутируемого соединения. Сервер под управле
нием Windows Server 2003, оборудованный модемом или интерфейсом, ISDN может быть настроен на прием входящих звонков и маршрутизацию передаваемых данных непосредственно в сеть. Клиенты коммутируемого доступа предоставляют регистрационные данные при создании соединения. Эти регистрационные данные проверяются с помощью базы данных Active Directory. Соединения могут быть настроены на обратный звонок (callback) или на управление пропускной способностью.
Подключение к серверам за пределами брандмауэра с помощью коммутируемого доступа. Сервер под управлением Windows Server 2003, настроенный в качестве сервера удаленного доступа, может быть установлен за пределами брандмауэра для обеспечения дополнительной безопасности. Пользователи могут проходить аутентификацию с помощью метода RADIUS (Remote Access Dial-In User Services). Компьютер под управлением Windows Server 2003 внутри защищенной брандмауэром сети и поддерживающий работу службы IAS (Internet Authentication Service — служба аутентификации Интернета) выступает в роли интерфейса RADIUS к базе данных Active Directory.
Подключение к Интернету с помощью виртуальной частной сети (Virtual Private
Network — VPN). Операционная система Windows Server 2003 поддерживает настройку виртуальных сетевых адаптеров, принимающих зашифрованные соединения по протоколу PPTP (Point-to-Point Tunneling Protocol — туннельный протокол “точка-точка”) или L2TP (Layer 2 Tunneling Protocol). Протокол L2TP для шифрования данных использует протокол IPSec, а для работы IPSec требуется инфраструктура открытого ключа (PKI), обеспечивающая распространение сертификатов компьютеров, содержащих ключи шифрования и цифровые подписи.
Аутентификация с помощью смарт-карт. Для достижения дополнительного уровня безопасности любой из конфигураций удаленного доступа можно воспользоваться смарт- картами, на которых хранятся сертифицированные пары ключей, использующиеся для проверки личности пользователя до предоставления соединения с сервером удаленного доступа.
Подключение к Интернету. Операционная система Windows Server 2003 может выступать в роли безопасного маршрутизатора между частной локальной сетью и сетью Интернет. Сервер использует технологию NAT (Network Address Translation — трансляция сетевых адресов), что позволяет обойтись одним легальным IP-адресом. В сервер интегрирован брандмауэр, который предотвращает доступ к портам на внешнем интерфейсе.
Подключение к сети, состоящей из сегментов различных типов. Сети Ethernet часто соединяют с беспроводными сетями 802.11b или сетями HomePNA Phoneline. (PNA расшифровывается как Phoneline Networking Association.) Компьютер под управлением операционной системы Windows Server 2003, оборудованный соответствующими адаптерами, может выступать в роли маршрутизатора или моста между всеми типами сетей.
Новые возможности операционной системы Windows Server 2003
Ниже приведен список новых возможностей маршрутизации и удаленного доступа, которые рассматриваются в этой главе.
Поддержка РРРоЕ. Широкополосный доступ стал предпочтительным способом подключения к Интернет для многих компаний и домашних пользователей. Провайдеры требуют оплаты за объем переданного трафика от каждого пользователя. Протокол РРРоЕ (Point- to-Point Protocol over Ethernet) предоставляет способ подключения нескольких клиентских компьютеров к провайдеру по единственному широкополосному соединению. Операционные системы Windows Server 2003 и Windows ХР обладают встроенной поддержкой соединений по протоколу РРРоЕ.
Интегрированный брандмауэр. Любой компьютер, подключенный к общедоступной сети, нуждается в защите от злоумышленников. Серверы под управлением Windows Server 2003 и рабочие станции под управлением Windows ХР имеют интегрированный брандмауэр, который может быть включен при использовании сервера в качестве шлюза в сеть Интернет.
Мост для смешанной среды передачи данных. Любой современный компьютер под управлением Windows может обеспечивать маршрутизацию между разными сегментами сети, но маршрутизация требует использования раздельных подсетей, что усложняет настройку сети, особенно в среде небольших или домашних офисов. Операционная система Windows Server 2003 Standard, Windows Server 2003 Enterprise или Windows ХР поддерживает функцию моста между разными сегментами сети, что превращает сегменты в единый интерфейс с единственным IP-адресом.
Интегрированная поддержка безопасности беспроводных сетей 802.1х. Точки беспроводного доступа, в большом количестве появившиеся в последние годы, для защиты пользовательских данных используют протокол WEP (Wired Equivalent Privacy). К сожалению, механизм WEP зависит от статических ключей шифрования длиной 40 или 128 бит. Эти ключи легко взламываются с помощью перехвата пакетов в беспроводной сети. В стандарте 802.1х эта проблема решается через разрешение динамических ключей, обмен которыми происходит с помощью TLS (Transport Layer Security). Эта возможность поддерживается с помощью протокола ЕАР (Extensible Authentication Protocol — протокол расширенной аутентификации) или защищенного протокола ЕАР (Protected ЕАР — РЕАР).
Поддержка протокола IPv6. В составе операционной системы Windows Server 2003 предоставляется стек IPv6, хотя пользовательский интерфейс и не был модифицирован для поддержки 128-разрядной адресации. Стек устанавливается в виде нового протокола в окне свойств сетевого подключения. Кроме этого, устанавливаются два виртуальных интерфейса для туннелей Toredo через NAT, описанных в документе draft-ietf-ngtrans- shipworm-05 .txt. Адреса и маршруты IPv6 назначаются с помощью утилиты Netsh. Синтаксис команды — netsh interface ipv6. Новый параметр /ipv6 для утилит ping, tracert и netstat позволит работать с соединениями IPv6, TCPv6 и UDPv6.
Proxy-сервер IAS. Эта возможность позволяет серверу IAS перенаправлять запросы RADIUS на другой сервер IAS или RADIUS. При этом протокол RADIUS может использоваться для коммутируемого доступа, виртуальных частных сетей и беспроводной аутентификации по протоколу 802.1х в пределах федерации лесов.
Многие улучшения в службах маршрутизации и удаленного доступа (Routing and Remote Access Service — RRAS) в операционной системе Windows Server 2003 связаны с модификацией существующих служб, а не с созданием новых. Ниже приведен список основных улучшений, которые рассматриваются в этой главе.
Улучшенная поддержка смарт-карт. Операционная система Windows 2000 поддерживала регистрацию с помощью смарт-карт, но многие инструменты администратора, включая утилиты с интерфейсом командной строки, все еще требовали ввода пароля. В операционной системе Windows Server 2003 смарт-карты поддерживаются с помощью команд runas и net use. Кроме этого, регистрация с помощью смарт-карт поддерживается во время сеансов сервера терминалов, что упрощает удаленное администрирование при использовании смарт-карт.
Упрощенная поддержка нескольких клиентов RADIUS. Это улучшение позволяет указать диапазон адресов для клиентов RADIUS, а не идентифицировать каждый клиент RADIUS по IP-адресу. Эта возможность позволяет быстро настроить большое количество коммутаторов ЕАР (Extensible Authentication Protocol) для аутентификации с помощью одного сервера RADIUS.
Преобразование имен NetBIOS по входящим (dial-in) коммутируемым соединениям.
Как бы нам, специалистам в области информационных, технологий, не хотелось смерти преобразования имен NetBIOS, преобразование имен с помощью широковещательных запросов все еще остается неплохим решением для небольших сетей. Сервер удаленного доступа Windows Server 2003 поддерживает перенаправление широковещательных запросов NetBIOS от клиентов коммутируемого доступа для обеспечения преобразования имен. По умолчанию эта возможность отключена.
Настройка протокола DHCP (Dynamic Host Configuration Protocol) для клиентов коммутируемого доступа под управлением Windows ХР. Исторически так сложилось, что серверы Windows, получающие адреса для клиентов коммутируемого доступа по протоколу DHCP, не могут предавать параметры DHCP клиентам. Эта особенность характерна и для операционной системы Windows Server 2003, но клиенты под управлением Window's ХР способны обойти это ограничение и получают информацию о конфигурации с помощью пакетов DHCPINFORM. Сервер удаленного доступа под управлением Windows Server 2003 маршрутизирует пакеты DHCPINFORM в указанный сетевой сегмент, где пакет передается серверу DHCP.
Карантин удаленного доступа. Службы маршрутизации и удаленного доступа Windows Server 2003 позволяют отказать в коммутируемом доступе или доступе к виртуальной частной сети всем пользователям, которые не соответствуют определенным критериям конфигурации. Эта возможность может использоваться для блокирования доступа клиентам, на которых не установлены антивирусные программы или последняя версия пакета исправлений (patch). В составе Windows Server 2003 Resource Kit предоставляется кли- ент/серверная утилита, которая упрощает настройку карантина удаленного доступа.
Функциональное описание поддержки устройств для глобальных сетей
За пределами локальных сетей для персональных компьютеров, работающих с ограниченным множеством совместимых с Ethernet технологий, раскинулся широкий мир глобальных сетей, основанный на PSTN (Public Switched Telephone Network). В этом мире “плоские" неэкранированные кабели соединяются с разрушенными коррозией коммутационными щитами, которые подключаются к 30-летним агрегаторам сигналов. Агрегаторы связаны с промежуточными соединителями ATM, подключенными к коммутаторам стоимостью несколько миллионов долларов, которые, в свою очередь, подключаются к оптоволоконным сетям, спроектированным и построенным сотнями производителей и обслуживаемым тысячами корпоративных и правительственных организаций, каждая из которых ни разу не взаимодействовала с другими организациями по вопросам сетей, которые находятся в их ведении.
Похоже, что единственным человеком, который вот уже 50 лет даже не подозревает о структуре общественных коммутируемых телефонных сетей, является бабушка автора этой книги, и причиной этому является только то, что ее жалобы в компанию AT&T терялись в той единственной системе, которая имеет даже более сложную структуру, чем общественные коммутируемые телефонные сети: в общественной почтовой службе.
На поиски способов подключения структуры передачи данных между персональными компьютерами к крайне запутанной сети PSTN ушли силы лучших инженеров и ученых- представителей нынешнего поколения. Хорошо понять стоящие перед ними трудности можно при попытке провести простое DSL-соединение в квартиру, чтобы клиент мог работать из дому, не устанавливая модем для коммутируемых линий.
С точки зрения подключения пользователя Windows в одной точке мира к серверу, работающему под управлением Windows Server 2003 в другой точке того же мира, существуют следующие категории соединений.
Сети с коммутацией каналов. Подключение к таким сетям обычно осуществляется с помощью знакомого аналогового соединения, которое предоставляется модемами. Кроме этого, можно воспользоваться коммутируемыми цифровыми соединениями, реализуемыми с помощью ISDN-устройств.
Сети с коммутацией пакетов. Подключение к таким сетям осуществляется с помощью той или иной формы Х.25 PAD (Packet Assembler/Disassembler) и FRADS (Frame Relay Access Devices). Соединения через сети с коммутацией пакетов обычно основаны на PVC (Permanent Virtual Circuit) или гораздо реже встречающемся SVC (Switched Virtual Circuit). Отдельные устройства могут подключаться непосредственно одно к другому с помощью протокола PPP (Point-to-Point Protocol — протокол “точка-точка”) поверх Frame Relay.
Сети с коммутацией ячеек. Эти сети обычно основаны на устройствах ATM (Asynchronous Transfer Mode); Хотя ATM обычно лежит в основе сети, персональные компьютеры могут непосредственно подключаться друг другу через ATM с помощью интерфейсов LANE (LAN Emulation). Для подключения устройств друг к другу в сети с коммутацией ячеек используется протокол PPPoA (Point-to-Point over ATM).
Выделенные сети. Это универсальный термин для интерфейсов, которые постоянно подключены к открытой коммутируемой телефонной сети. Большинство организаций используют каналы Т-1 (DS-1) самостоятельно или совместно, а некоторые организации могут себе позволить каналы DS-3 и более высокоскоростные соединения.
Широкополосный доступ. Это универсальный термин, который описывает использование широкополосных сигналов для подключения клиентского оборудования к специальному интерфейсу в центральном офисе PSTN (на АТС) или в центре поставщика услуг цифровой сети. Широкополосный доступ включает в себя огромное количество типов технологии DSL, а также доступ по цифровому кабелю.
Поддержка глобальных сетей и NDIS
Ежедневная поддержка работы сервера связи практически не требует вмешательства в работу устройства, подключенного к глобальной сети. Но правильная настройка сервера и его ремонт в случае отказа могут быть связаны с рядом проблем, касающихся способа подключения устройств друг к другу внутри подсистемы Windows Executive. На рис. 20.1 показана схема взаимодействия сетевых драйверов, которые поддерживают связь с глобальной сетью.
Интерфейсы глобальной сети в операционной системе Windows представлены в виде стандартных сетевых адаптеров. Это позволяет протоколам верхнего уровня не обращать внимания на способ передачи данных по сети. Службы передачи данных и управления дос-
тупом к среде передачи данных, связанные с этими устройствами, управляются драйверами NDIS (Network Device Interface Specification — спецификация стандартного интерфейса сетевых адаптеров).
Рис. 20.1. Схема взаимодействия драйверов для поддержки работы в глобальной сети
Из-за своих особенностей устройства с коммутацией каналов, например модемы и терминальные адаптеры ISDN, управляются с помощью драйверов Telephony API (TAPI), которые, в свою очередь, связываются с NDIS. Подробная информация об этой связи не требуется для настройки и диагностики проблем, но желательно помнить, что конкретный модем может отлично работать при создании последовательного соединения (управляемого исключительно средствами Telephony API) и полностью отказывать при выполнении сетевых функций.
NDIS взаимодействует с сетевым адаптером с помощью драйверов мини-порта. Универсальный драйвер мини-порта для связи с глобальными сетями называется RAS Async Adapter, Asyncmac . sys. В файле Netrasa. inf в каталоге \Windows\lNF содержится информация по установке этого драйвера и других виртуальных драйверов мини-порта глобальной сети, например, для интерфейса L2TP (Layer 2 Tunneling Protocol), PPTP (Point-to-Point Tunneling Protocol — протокол туннелирования “точка-точка”) и непосредственного параллельного интерфейса (PTI).
NDIS работает совместно с мини-драйвером адаптера для создания кадра, соответствующего спецификации IEEE 802. Например, кадр Ethernet соответствует спецификации IEEE 802.2, а кадр для беспроводной сети Ethernet соответствует спецификации 802.11b. Для интерфейсов глобальной сети NDIS использует промежуточный драйвер, Ndiswan. sys, который создает коммуникационный кадр, соответствующий требованиям соединения по протоколу РРР. Формат кадра определен в документе RFC 1662, “PPP in HDLC-like Framing”.
Записи системного реестра, связанные с модемами
Информация о конфигурации модема хранится в системном реестре в разделе, имя которого соответствует идентификатору класса для модемов: 4D36E96D-E325-11CE-BFC1- 08002ВЕ10318. Записи конфигурации хранятся в следующем разделе системного реестра:
HKLM\System\CurrentControlSet\Control\Class\{4D36E96D-E325-11CE-BFC1- 08002ВЕ10318}
Для каждого модема создается отдельный раздел с последовательным номером, начиная с 0000. На рис. 20.2 показаны записи для стандартного модема.
{4O36E96B-E325-1 1CE-BFC1-08002BE10318} № П {4D36E96C-E325-11CE-BFC1-08002BE10318} В GJ {4036E96D-E325-I1CE-8FCH36002BE103I8} з^И
GJ EnableCalerlD
CJ напад
Сэи*
Q 1NSTAILED_HAG
C3 Meritor GJ Settings ffl C3 {4036E96E-E32S-llCE-BFCl-0e002BE103ie} ® О <SO36E96F-E32S-llCE-BFCl-0e002BE10318} C3 <4D36E970-E32S-HCE-BFCl-0e002BE103ie} СЭ t4D36E971-E325-llCE-BFCl-CB002BE103ie} ffl-Cj W36E97Z-E325-llCE-eFCl-06002bE103ia> О <4036E973-E32S-llCE-BFCl-0e002BE103ie> Q {eD36E974-E325-llCE-BFCl-0aXBBE103ie} CJ <4036E975-E32S-llCE-BFCl-0e002eE103iet Ca <4D36E977-E32S-HCE-BFCl-0e002BE103ie> В Q <4O36E97e-E32S-llCE-BFCl-0eOa2BE103ie>
(Defat*) @8*ttachedTo @CaierIDOutSide gjCalerlDPilvate S^CompattifcyAaos @|ConfigDiatog ®DCB ^ Defat* igjQDevfceType
Uh
Sh
iDriverDateData iDriverDesc
@)DriverVerslon §|EnumPropPages32 S^FriendyName
REG.SZ REG.SZ REG.SZ REG.SZ REG.BINARY REG.SZ REG.BINARY REG.BINARY REG.BINARY REG.SZ REG.BINARY REG.SZ REG.SZ REG.SZ REG.SZ REG.BINARY REG.BINARY REG.SZ
COM!
0
01 00 00 00 modemui.dl 1C 00 00 00 00 c2 01 00 15 20 C ЭсООООООООООООООООООС
01
3-9-2000
DO 40 84 69 5a 89 bf 01
Sportster 56k Data Fax PnP 5.1.2535.0
modemui. dl, ModemfropPagesPi.s Sportster 56k Data Fax Pr₽ <5 06 38 00
ЗсОООООО rrxkrxasrkl .Inf
Modeni99
REG SZ
IltfPath InfSecUon .
@InactivtyScate
Puc. 20.2. Параметры модема, сохраненные в разделе класса Modem в системном реестре
Данные записи попадают в системный реестр из сценария INF, который находится в скрытой папке \windows\lNF. Если в настройке модема возникли проблемы, решаемые путем внесения изменений в системный реестр, внесите соответствующее изменение в файл INF модема на случай, если модем придется устанавливать еще раз.
Протокол РРР
Когда дело доходит до передачи данных, локальная сеть превращается в фондовую биржу. Много криков, условных сигналов, размахивания квитанциями, но в итоге каким-то образом транзакции завершаются. При передаче данных по глобальной сети используется более произвольный и сфокусированный метод. Один компьютер общается с другим компьютером через канал, создаваемый в результате последовательности действий с двух сторон. Протокол создания такого канала называется PPP (Point-to-Point Protocol).
На протокол РРР возложено много задач, для решения которых используются вспомогательные протоколы. Эти протоколы определены в документе RFC 1661, “Point-to-Point Protocol”. Ниже приведен краткий список этапов транзакции РРР, после которого приводится описание протокола, используемого на каждом этапе.
Создание канала соединения. На этом этапе два физических устройства должны создать канал передачи данных, определяющий личности сторон, размер и тип используемого кадра и используемый протокол аутентификации.
Аутентификация. На этом этапе сервер удаленного доступа получает регистрационные данные, предоставленные установившим соединение пользователем, и использует эти данные для определения личности пользователя. Аутентификация входящих сообщений удаленного доступа не зависит от сетевой аутентификации, которая может требоваться после установки подключения РРР.
Установка сетевого уровня. После аутентификации пользователя клиентскому интерфейсу предоставляются IP-адрес и дополнительные конфигурационные параметры, например сжатие и шифрование. Кроме этого, может требоваться разрыв подключения и ожидание обратного звонка (callback) для определения действительного источника звонка.
Создание канала соединения
Транзакция РРР начинается с “переговоров”, которые выполняются с помощью протокола LCP (Link Control Protocol — протокол управления каналом). Этот протокол отвечает за определение параметров канала передачи данных для сетевого соединения. Можно перечислить следующие параметры.
Максимальная принятая восстановленная единица (Maximum Received Reconstructed Unit - MRRU). Это максимальный размер кадра, который может передаваться с помощью данного соединения. Большие сообщения разбиваются на фрагменты и восстанавливаются после приема. Значение MRRU определено в документе RFC 1717, “PPP Multilink Protocol”, и по умолчанию составляет 1614 байт. (Дополнительная информация об ограничениях размера кадра приводится в разделе “Протокол РРРоЕ” далее в этой главе.)
АССМ (Asynchronous Control Character Мар). Первые 32 символа таблицы ASCII выступают в роли управляющих символов для асинхронного последовательного соединения. Потенциально эти символы могут являться частью потока данных, если в потоке данных передаются двоичные файлы. Параметр АССМ позволяет преобразовать управляющие символы в форму отдельных битов в 32-битовой последовательности. Например, символ Ctrl+L (AL) будет представлен битом 12. Если маска установлена равной 0, предполагается, что преобразование не требуется.
Тип аутентификации. Этот параметр определяет метод аутентификации, который используется на следующем этапе соединения. Метод аутентификации зависит от конфигурации клиента и сервера. Доступны пять вариантов: ЕАР (0хС2-27), MS-CHAPvl (0хС2-23-80), MS-CHAPv2 (0хС2-23-81), CHAP (0хС2-23-05), SPAP (0хС0-27) и РАР (0хС0-23).
Магическое число. Магическое число является случайным числом, которое подтверждает источник пакета. Если хост обнаруживает собственное магическое число на пакете, он рассматривает его как признак создания обратной петли. Пакет отбрасывается, и выполняется повторная установка канала.
Сжатие поля протокола. Этот параметр позволяет сжать поле протокола в кадре РРР. Обе стороны должны установить этот параметр перед фактическим использованием. По умолчанию этот параметр включен.
Сжатие поля адреса и управления. Этот параметр позволяет сжать однобайтное поле Address и однобайтное поле управления в заголовке кадра РРР. По умолчанию этот параметр включен.
Аутентификация
Стороны, взаимодействующие по протоколу РРР, договариваются о методе аутентификации в течение этапа работы протокола LCP. Выбранный метод реализуется во время этого этапа. Это самая сложная часть транзакции РРР. Она рассматривается в разделе “Аутентификация по РРР”.■
Установка сетевого уровня
После аутентификации пользователя протокол РРР предоставляет управление протоколу NCP (Network Control Protocol — протокол управления сетью). Этот протокол отвечает за установку сетевого соединения поверх канала данных, установленного протоколом LCP.
Протокол NCP использует несколько дополнительных протоколов. Вот эти протоколы.
Протокол управления обратным звонком (callback)
Протокол управления сжатием
Протокол управления шифрованием
Протокол управления транспортным протоколом
Протокол управления обратным звонком
Протокол СВСР (CallBack Control Protocol — протокол управления обратным звонком) определяет параметры обратного звонка, который настроен для пользователя. В операционной системе Windows Server 2003 пользовательские параметры обратного звонка хранятся в одном из двух мест. Для изолированных серверов удаленного доступа информация хранится в базе данных SAM в учетной записи пользователя. В доменах эта информация хранится в объекте пользователя в базе данных Active Directory (в атрибуте MSRADIUS-Callback- Number). Протокол СВСР предоставляет три параметра для настройки обратного звонка.
No Callback (Без обратного звонка). Если установлен этот параметр, протокол СВСР немедленно возвращает управление протоколу NCP.
Callback Set by Caller (Обратный звонок устанавливается вызывающей стороной). Если установлен этот параметр, протокол СВСР сообщает клиенту коммутируемого доступа, что необходим обратный звонок, и запрашивает номер для обратного звонка. Пользователь вводит номер телефона, и протокол СВСР обрывает соединение. Клиент ожидает входящего звонка от сервера. Введенный пользователем номер записывается в журнале событий. Этот параметр часто используется для поддержки звонков из-за рубежа (по отношению к США), так как исходящий звонок из США намного дешевле, чем входящий звонок из-за рубежа.
Callback Present То (Обратный звонок предоставляется...). Если установлен этот параметр, протокол СВСР сообщает клиенту коммутируемого доступа о наличии определенного номера обратного звонка. Клиент подтверждает номер и завершает звонок, ожидая встречного звонка от сервера. Сервер набирает указанный номер, восстанавливает соединение и передает управление протоколу NCP. Этот параметр используется в том случае, если необходимо убедиться, что соединение устанавливает конкретный пользователь.
Протокол управления сжатием
Протокол ССР (Compression Control Protocol) обеспечивает выбор метода сжатия данных. В операционной системе Windows используется вариант протокола ССР, который называется МРРС (Microsoft Point-to-Point Compression). Протокол МРРС описан в документе RFC 2118. Он позволяет “договориться" с клиентами Windows о дополнительных возможностях, сохраняя поддержку стандартного протокола ССР для клиентов под управлением других операционных систем. Для определения параметров сжатия протокол МРРС использует параметры, установленные сервером и клиентом коммутируемого доступа.
По умолчанию в Windows-протоколе РРР используется программное сжатие. К сожалению, интерфейс TAPI предоставляет возможность включения аппаратного сжатия. Одновременно оба сжатия использовать нельзя. В таком случае ресурсы центрального процессора будут потрачены на сжатие кадров, которые и так будут сжаты модемом. Программное сжатие обычно работает быстрее, поэтому для отключения аппаратного сжатия можно настроить соответствующий параметр в Control Panel (Панель управления) в разделе Phone and Moderns Modem Configuration Properties (Телефон и модема Свойства конфигурации модема).
На клиентах Windows 98 программное сжатие включено всегда. При отключении программного сжатия транзакция подключения РРР завершится неудачно.
Управление шифрованием
Стандартный протокол РРР предполагает, что шифрованием потока данных будет заниматься протокол более высокого уровня. Компания Microsoft добавила выбор шифрования в фазу установки сетевого подключения. Этот параметр устанавливается в окне свойств коммутируемого подключения на вкладке Security (Безопасность) окна свойств модема. На рис. 20.3 показан пример этого окна на клиенте Windows ХР. В операционной системе Windows Эх используется похожее окно Dial-Up Networking (Коммутируемый доступ).
Рис. 20.3. Окно свойств модема для ком--
мутируемого доступа. На вкладке Security (Безопасность) доступен флажок Data
Encryption (Шифрование данных)
" При установке параметров шифрования клиент и сервер шифруют поток данных с помощью протокола шифрования МРРЕ (Microsoft Point-to-Point Encryption), который описан в документе RFC 3078, “Microsoft Point-To-Point Encryption (МРРЕ)", и в документе RFC 3079, “Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)".
В протоколе МРРЕ используются потоковое шифрование по алгоритму RC4 и шифрование с помощью ключа длиной 128 бит. Использование ключа такой длины стало возможным после ослабления экспортных ограничений. Брюс Шнайер (Bruce Schneier) из компании Counterpane Systems (www.counterpane.com) указывает, что несмотря на кажущуюся безопасность ключа длиной 128 бит, он генерируется на основе пароля пользователя, который искусственно ограничен 14 символами и часто содержит намного меньше максимального количества символов, поэтому длинные ключи не делают протокол МРРЕ более устойчивым к атакам, чем ключи размером 56 бит.
Шифрование РРР защищает только поток данных между двумя конечными точками соединения. Если клиент устанавливает соединение РРР к серверу маршрутизации и удаленного доступа (RRAS-серверу), а затем подключает сетевой диск, находящийся на другом сервере, то поток данных между сервером совместно используемого ресурса и RRAS-сервером шифроваться не будет.
Если данные оказываются достаточно ценными, чтобы оправдать шифрование, стоит реализовать виртуальные частные сети с использованием протоколов L2TP и IPSec, а не исполь-
зовать шифрование средствами протокола РРР. Дополнительная информация приводится в разделе “Настройка VPN-соединений”.
Протоколы управления
После выбора протоколов сжатия и шифрования протокол NCP “обращает внимание” на протоколы управления, которые используются для настройки интерфейса на сетевые протоколы, используемые системой. Каждый сетевой транспорт, поддерживаемый операционной системой Windows Server 2003, имеет соответствующий протокол управления. Ниже перечислены эти протоколы.
Протокол IPCP (Internet Protocol Control Protocol — протокол управления протоколом Интернет). Этот протокол определен в документе RFC 1332, “The PPP Internet Protocol Control Protocol (IPCP)”. Протокол IPCP устанавливает такие параметры, как IP-адрес клиента, основной и вторичный серверы DNS, основной и вторичный серверы WINS, а также использование сжатия Van Jacobson для заголовков IP-пакетов.
Протокол IPXCP (IPX Control Protocol — протокол управления IPX). Этот протокол используется для управления протоколом NetWare IPX (Internetwork Packet Exchange) поверх коммутируемого соединения, как описано в документе RFC 1552, “The PPP Internetwork Packet Exchange Control Protocol (IPXCP)”. Протокол IPXCP устанавливает такие параметры, как номер сети IPX, номер узла IPX, протокол сжатия IPX, протокол маршрутизации IPX, а также имя маршрутизатора IPX.
NBFCP (NetBIOS Frame Control Process — протокол управления кадрами NetBIOS). Этот протокол определен в документе RFC 2097, “The PPP NetBIOS Frames Control Protocol (NBFCP)”. Протокол NBFCP определяет такие параметры, как NetBIOS Name Projection, устанавливающий список имен серверов, которые должны быть добавлены в таблицу имен NetBIOS на клиенте, и Peer Information, который указывает, является ли клиент терминалом сети или шлюзом. Кроме этого, существует параметр IEEE MAC Address Required, который заставляет включать МАС-адрес в каждый кадр для обеспечения связи с другой стороной шлюза, и параметр Multicast Filtering, который управляет широковещательными запросами NetBIOS, которые отправляются через шлюз.
После завершения фазы согласования параметров по протоколу IPCP протокол РРР завершает свою работу и соединение считается установленным. Управление передается драйверу NDIS и на интерфейс начинают отправляться данные.
Протокол РРРоЕ
Протокол РРР не ограничивается соединениями между интерфейсами с коммутацией каналов, например между модемами или терминальными адаптерами ISDN. Операционная система Windows поддерживает использование РРР для установки непосредственного соединения между двумя сторонами поверх целого ряда протоколов глобальных сетей.
Одним из все чаще встречающихся примеров этой возможности является использование протокола РРР для аутентификации и подключения пользователей DSL к сети поставщика услуг DSL через существующее постоянное широкополосное соединение. В таком соединении используется вариант протокола РРР, который называется РРР over Ethernet, или РРРоЕ. Этот вариант протокола описан в документе RFC 2516, “A Method for Transmitting РРР Over Ethernet (РРРоЕ)”.
Очевидно, что причиной использования РРРоЕ является безопасность. В ранних реализациях DSL каждый интерфейс DSL получал IP-адрес и был “постоянно включен” в сеть. Сервер (или рабочая станция), оборудованный интерфейсом DSL, мог маршрутизировать пользователей в Интернет с помощью трансляции сетевых адресов (NAT), или пользователь
мог установить недорогой аппаратный шлюз, который выполнял те же задачи. Поставщики услуг DSL рассматривали такую конфигурацию, как угрозу безопасности, поскольку пользователи могли выполнять вредоносные действия под прикрытием анонимности, предоставляемой при NAT-соединении.
Однако реальное предназначение РРРоЕ связано с экономией средств, а не с обеспечением безопасности. Единственным соединением DSL могут пользоваться десятки пользователей, и все они будут платить только за одно соединение DSL. Такая практика широко распространена при использовании выделенных линий Т-1, но модель получения прибыли в сетях Т-1 значительно отличается от технологии DSL, которая значительно дешевле.
Индустрия боролась с такой практикой некоторое время, пока протокол РРРоЕ не начал позволять в интерфейсе DSL управление пользовательскими учетными записями и начисление оплаты для каждого отдельного пользователя. Серверы под управлением Windows Server 2003 и Windows ХР предоставляют встроенную поддержку протокола РРРоЕ, поэтому установка отдельного программного обеспечения для аутентификации не требуется.
Одним из важных ограничений протокола РРРоЕ является сокращение максимального размера кадра, который может передаваться клиентами через сервер с подключением РРРоЕ. Для стандартного кадра Ethernet полезная нагрузка составляет 1500 байт (октетов). Этот размер называется MTU (Maximum Transmission Unit — максимальная единица передачи). Заголовок РРРоЕ занимает 6 октетов (в дополнение к 2 октетам идентификатора протокола РРР). В таком случае значение параметра MTU сокращается до 1492 байт.
При установке соединения клиент TCP/IP “договаривается" с сервером о значении параметра MTU. Обычно это 1500 байт. Если клиент находится за сервером, который обладает соединением РРРоЕ, сервер РРРоЕ отбросит кадр и вернет серверу ICMP-сообщение (Internet Control Management Protocol — протокол управляющих сообщений в сети Интернет), в котором сообщается, что значение параметра MTU установлено равным 1492. Если Web-сервер настроен на игнорирование ICMP-сообщений, а многие серверы настроены именно так, Web- страница вообще не будет загружаться. -
Удобным методом диагностики является отправка тестового эхо-запроса на Web-сервер с использованием параметра -1 для указания полезной нагрузки пакета и параметра - f для предотвращения фрагментации. Синтаксис соответствующей команды будет выглядеть следующим образом:
ping -f -1 1492 <хост> .
Если в результате выполнения команды выдается сообщение Packet needs to be fragmented but DF set (Пакет должен быть фрагментирован, но установлен бит DE), можно сделать вывод, что превышено значение параметра MTU для Web-сервера или одного из промежуточных маршрутизаторов.
Для решения таких проблем можно уменьшить значение параметра MTU на клиентах, которые находятся за сервером, использующим соединение РРРоЕ. Это можно сделать на каждом клиенте или внести изменения на одном клиенте и экспортировать изменение с помощью редактора Regedit в файл, который будет применяться на остальных клиентах с помощью регистрационного сценария. Ниже приведен список необходимых изменений в системном реестре.
Раздел: HKLM\System\GurrentControlSet\Services\Ndiswan\Parameters\Protocols\0
Запись: ProtocolType
Значение: 0x0800 (reg_dword)
Запись: PPPProtocolType
Значение: 0x0021 (reg_dword)
Запись: ProtocolMTU
Значение <Размер_мти> (reg_dword)
Аутентификация по PPP
Протокол PPP требует от пользователя предоставления регистрационных данных, которые будут проверены сервером удаленного доступа. Безопасность внешних соединений исключительно важна, поэтому стоит внимательно рассмотреть особенности каждого метода аутентификации. Эта информация поможет принять решение об используемом протоколе и поможет при устранении неисправностей, если протокол будет настроен неправильно.
Сам по себе протокол РРР не имеет предпочтительного протокола аутентификации. Метод аутентификации выбирается на этапе работы протокола LCP в транзакции установки соединения. Операционная система Windows Server 2003 поддерживает несколько методов аутентификации, которые используются при установке PPP-соединения. Ниже приведено краткое описание каждого метода аутентификации (далее изложен подробный анализ каждого метода).
Протокол PAP (Password Authentication Protocol — протокол аутентификации по паролю). Клиент передает пароль на сервер открытым текстом. На сервере пароль сравнивается с пользовательским паролем в одной из баз данных. Протокол РАР подходит только для некоторых простейших коммутируемых соединений.
Протокол SPAP (Shiva РАР). Это частный вариант протокола РАР, который используется в Shiva LANRover и в других продуктах. На сервер передается обратимо зашифрованный пароль, что лучше, чем при использовании РАР, но все еще недостаточно для ситуации, когда на другой стороне подключения может находиться подложный сервер удаленного доступа.
Протокол CHAP (Challenge Handshake Authentication Protocol — протокол аутентификации с предварительным согласованием вызова). Это стандартный протокол аутентификации, который используется практически всеми провайдерами услуг Интернет. Протокол CHAP не требует передачи пароля по сети. Вместо этого используется метод вызова-ответа, когда пользовательский пароль используется для хеширования ответа серверу, который сравнивает результат с результатом хеширования того же пароля.
Протокол MS-CHAP (Microsoft CHAP). Это версия протокола CHAP, в которой для ответа на вызов используется хешированная версия пользовательского пароля, а не сам пароль. Такой метод используется в операционных системах Windows 3.1х и Windows 95.
Протокол MS-CHAPv2 (Microsoft CHAPv2). Это улучшенная версия MS-CHAP, в которой устранены некоторые слабые места, в том числе благодаря использованию взаимной аутентификации клиента и сервера, большей продолжительности вызова и более безопасным методам смены устаревшего пароля.
Протокол ЕАР (Extensible Authentication Protocol — расширяемый протокол аутентификации). Это не протокол аутентификации как таковой, а просто механизм для использования альтернативного протокола аутентификации. Основным применением протокола ЕАР в Windows является поддержка аутентификации по смарт-картам. Производители могут добавлять собственные методы в протокол ЕАР.
Теперь каждый из протоколов будет рассмотрен более подробно с указанием сильных и слабых сторон каждого решения.
Протокол РАР
Протокол РАР (Password Authentication Protocol — протокол аутентификации по паролю) позволяет выполнить аутентификацию пользователя по регистрационным данным (имя и пароль). Регистрационные данные передаются открытым текстом. На рис. 20.4 показано, как выглядит транзакция аутентификации при перехвате пакетов.
ЕВ Iran*: Base trans properties
83 PPP: Password Authentication Protocol Irene (0xC023)
BPPPPAP: Authenticate Bequest, ID ■ Ox 1'ч
PPPPAP: Code ■ Authenticate Bequest>
i- PPPPAP: ID ■ 1 (0x1) f PPPPAP: Length ■ 27 (OxlB)>
PPPPAP: Peer ID Length ■ 13 (OxD)'.
г PPPPAP: Peer ID ■ conpany_userl1
V PPPPAP: Password Length ■ 8 (0x8)1
Рис.20.4. Перехваченные пакеты транзакции аутентификации по протоколу РАР.
Регистрационные данные передаются открытым текстом■
Сервер удаленного доступа под управлением Windows получает копию пользовательского пароля по безопасному шифрованному каналу от контроллера домена. Эта копия пользовательского пароля используется для проверки запроса на аутентификацию.
В базе данных Active Directory не хранятся незашифрованные версии паролей пользователей. Но можно включить хранение паролей с использованием обратимого ключа. Контроллер домена может дешифровать пароль и отправить результат серверу удаленного доступа для поддержки аутентификации по протоколу РАР. Дополнительная информация приводится во врезке “Обратимые пароли”.
Протокол РАР можно применять только в тех случаях, когда надежный клиент подключается к надежному серверу по надежной телефонной линии. И даже в этом случае возможность просмотра пользовательского пароля с помощью перехвата пакетов оказывается слишком большим соблазном. Лучше отказаться от использования протокола РАР, отключив его на сервере.
Обратимые пароли
Если в сети присутствуют клиенты под управлением других операционных систем, использующие для аутентификации протоколы РАР, SPAP и CHAP, контроллеры домена необходимо настроить на хранение обратимых паролей. Это необходимо, так как сервер удаленного доступа должен иметь доступ к незашифрованным паролям для проверки регистрационных данных, предоставляемых клиентом.
Существует два основных метода активизации обратимых паролей. Один из методов предназначен для отдельных пользователей, а второй — для всего домена (после установки одного из параметров пользователь должен изменить существующий пароль для генерации обратимой формы пароля).
Отдельные пользователи. В свойствах учетной записи пользователя в Active Directory установите флажок Store password using reversible encryption (Хранить пароль, используя обратимое шифрование), как показано на рис. 20.5.
Все пользователи домена. Включите групповую политику store passwords using reversible encryption for all users in the domain (Хранить пароль, используя обратимое шифрование для всех пользователей в домене), как показано на рис. 20.6. Эта политика хранится в разделе Computer Configuration^Windows Settings^Security
Рис. 20.6. В списке Password Pol i су (Политики паролей) включена политика Store passwords using reversible encryption for all users in the domain (Хранить пароль, используя обратимое шифрование для всех пользователей в домене)Рис. 20.6. В списке Password Pol i су (Политики паролей) включена политика Store passwords using reversible encryption for all users in the domain (Хранить пароль, используя обратимое шифрование для всех пользователей в домене)
Рис. 20.6. В списке Password Pol i су (Политики паролей) включена политика Store passwords using reversible encryption for all users in the domain (Хранить пароль, используя обратимое шифрование для всех пользователей в домене)
Рис. 20.6. В списке Password Pol i су (Политики паролей) включена политика Store passwords using reversible encryption for all users in the domain (Хранить пароль, используя обратимое шифрование для всех пользователей в домене)
Settings^Account Policies^Password Policy (Конфигурация компьютера^Параметры Win- dows^napaMerpbi безопасности^Политики учетных записейЦ>Политики паролей).
Рис. 20.5. В свойствах учетной записи пользователя можно установить флажок Store password using reversible encryption (Хранить пароль, используя обратимое шифрование)
Обратимые пароли являются брешью в системе безопасности, поэтому такая возможность должна включаться только при абсолютной необходимости поддерживать клиентов, использующих протоколы CHAP, PAP и SPAP.
Протокол SPAP
Протокол SPAP (Shiva PAP) используется продуктами Shiva LANRover и совместимыми серверами удаленного доступа. Протокол SPAP применяется для поддержки клиентов Shiva, подключающихся к серверу удаленного доступа под управлением Windows, и клиентов Windows, которые подключаются к устройству LANRover.
В отличие от РАР, протокол SPАР-передает пароль в зашифрованной форме, а не открытым текстом. Это незначительное улучшение, так как пароль шифруется с помощью обратимого и простого с точки зрения взлома алгоритма. Кроме этого, вместе с паролем не передается информация, которая защищает пароль от кражи и последующего несанкционированного использования.
Ни в коем случае не включайте протокол SPAP в качестве протокола аутентификации пользователей коммутируемого доступа на сервере маршрутизации и удаленного доступа (RRAS-сервер). Этот протокол должен использоваться на клиентах только для подключения к серверам LANRover.
Протокол CHAP
Стандарт на протокол CHAP (Challenge Handshake Authentication Protocol — протокол аутентификации с предварительным согласованием вызова) определен документом RFC 1994, “PPP Challenge Handshake Authentication Protocol (CHAP)". Серверы удаленного доступа под управлением Windows используют протокол CHAP для поддержки клиентов под управлением других операционных систем. Клиенты Windows используют протокол CHAP при подключении к серверам удаленного доступа под управлением других операционных систем (обычно такие^серверы установлены у провайдеров услуг Интернет).
Преимущество протокола CHAP по сравнению с РАР и SPAP заключается в том, что пароль или его зашифрованная форма никогда не передаются по сети. В процедуре 20.1 описаны основные этапы транзакции аутентификации по протоколу CHAP.
Процедура 20.1. Транзакция аутентификации по протоколу CHAP
Пользователь вводит имя и пароль и устанавливает коммутируемое подключение.
В начале этапа аутентификации транзакции РРР сервер удаленного доступа отправляет клиенту вызов в форме случайного числа и номера сеанса.
Клиент коммутируемого доступа комбинирует полученный вызов, пароль пользователя и номер сеанса и хеширует их с использованием алгоритма RSA MD5, который создает дайджест сообщения длиной 128 бит.
Клиент возвращает серверу хешированный ответ вместе с регистрационным идентификатором пользователя. На рис. 20.7 показаны перехваченные пакеты транзакции “запрос-ответ".
IJIHa e* a* T<* Ofufee window и*
Ох О: ChallengeОх О: Challengegig 2L№1 *1 @e|8Sl *1119181 ^IH gl 2ji
Ох О: Challenge
Ох О: Challenge
Irene I tine I 3rc awe Adi* 1 Ose ШС AMt I hweeoA.j eeaetiaelen
.666710205345414406 205345414406 PPPCHAP Challenge.
Л1—
® PPP: Challenge Handtheke Authentication Protocol Praae (OxC223)
РРРСНАР:
В
> РРРСНАР: РРРСНАР: РРРСНАР:
Response (0x0) - 34 (0x22)
10 41 34 С4 еэ В5 81 63 70 6D DC 81 56 28 С8 II D8 63 6Г 6D 70 61 61...
Length
Рис.20.7. Перехваченные пакеты транзакции CHAP, в которых видны вызов и ответ от клиента
Сервер удаленного доступа устанавливает защищенное соединение с регистрационным сервером (контроллером домена Active Directory или классическим основным/резервным контроллером домена) и получает копию пароля пользователя открытым текстом. (Дополнительная информация приводилась во врезке “Обратимые пароли”.)
Сервер удаленного доступа принимает пароль пользователя и выполняет ту же операцию хеширования, которую использовал клиент. Если результаты хеширования совпадают, сервер отправляет клиенту сообщение Success.
Протокол CHAP периодически выполняет повторную аутентификацию пользователя, ограничивая время присутствия в сети злоумышленника, который выдает себя за легитимного пользователя.
По умолчанию на RRAS-сервере под управлением операционной системы Windows Server 2003 протокол CHAP отключен. Чтобы поддерживать клиентов под управлением других операционных систем, протокол CHAP необходимо включить вручную одновременно с включением обратимых паролей.
Протокол MS-CHAP версий v1 и v2
Клиенты Windows, аутентифицирующиеся на RRAS-сервере под управлением Windows, получают дополнительное преимущество по сравнению с клиентами сторонних производителей, так как и клиент, и сервер хранят одинаковую копию хеша пароля, использующегося для регистрации по сети. Это позволяет двум сторонам на этапе установки соединения по методу “запрос-ответ” использовать хешированный пароль вместо пароля открытым текстом. При такой конфигурации хранение пароля открытым текстом не требуется.
Компания Microsoft называет этот альтернативный протокол аутентификации MS-CHAP. Существует две версии протокола MS-CHAP. Оригинальная версия описана в информационном документе RFC 2488, “Microsoft PPP CHAP Extensions”. В этой версии было обнаружено несколько значительных уязвимых мест, включая использование очень слабого алгоритма хеширования пароля LanMan (LM) Data Encryption Standard (DES) в транзакции “запрос-ответ”, возможность проведения атак “посредника”, процедуру изменения пароля, которая открывает учетные записи для воздействия вредоносного кода, а также реализацию потокового шифрования, которая значительно упрощает извлечение секретного ключа.
Все эти уязвимые места протокола MS-CHAP описаны в статье “Cryptanalysis of Microsoft’s Point-to-Point Tunneling Protocol” Брюса Шнайера (Bruce Schneier) из компании Counterpane Systems и Питера Маджа (Peter Mudge) из группы LOpht Heavy Industries (теперь ©Stake). Копия этой статьи доступна на сайте по адресу www. counterpane. com.
В ответ на эти замечания компания Microsoft заменила протокол MS-CHAP второй версией, MS-CHAPv2. Этот протокол описан в документе RFC 2759, “Microsoft PPP CHAP Extensions, Version 2”. В новой версии предоставлены следующие улучшения.
Хешированные пароли LanMan DES больше не используются на этапе транзакции “запрос-ответ”. Используются только хешированные пароли NT LanMan (NTLM) MD4. MD расшифровывается как Message Digest (дайджест сообщения).
Применяется запрос большего размера (16 байт вместо 8).
Реализована взаимная аутентификация клиента и сервера для защиты от атаки “посредника”.
Применяется новая транзакция изменения пароля, которая не позволяет использовать выявленные уязвимые места.
Внесены изменения в методе генерации ключей RC4, которые используются для потокового шифрования. Новый метод значительно усложняет извлечение ключей.
Шнайер и Мадж вместе с Дэвидом Вагнером (David Wagner) из компании UC Berkeley описали уязвимые места протокола MS-CHAPv2, которые включены в обновленную версию документа, касающегося протокола РРТР. (Обновленная версия статьи также доступна на сайте компании Counterpane.) Пол Лич (Paul Leach) из компании Microsoft оспорил несколько тезисов статьи в сообщении, которое было опубликовано в Bugtraq. (В качестве критериев поиска сообщения можно воспользоваться именем Paul Leach и словом MS-CHAPv2.)
В итоге системным администраторам приходится выбирать технологию, которую придется реализовывать. Если честно, то протокол MS-CHAPv2 является наиболее безопасным протоколом аутентификации на основе пароля из.поддерживаемых операционной системой Windows Server 2003. (Служба RADIUS не является заменой MS-CHAPv2, а просто обеспечивает другое хранилище для регистрационных данных.) Когда безопасность является главным приоритетом (а когда это не так?), стоит рассмотреть использование смарт-карт для аутентификации удаленного доступа. Дополнительная информация приводится в разделе “Применение смарт-карт для удаленного доступа”.
Протокол EAR
Протокол ЕАР (Extensible Authentication Protocol — расширяемый протокол аутентификации) на самом деле не является самостоятельным протоколом. Он предоставляет способ использования альтернативных методов аутентификации, которые не поддерживаются непосредственно протоколом РРР. В составе операционной системы Windows Server 2003 предоставляются два пакета ЕАР.
MD5-CHAP. В этом методе исцользуются те же транзакции, что и в стандартном протоколе CHAP, но этапы инициализируются в пределах протокола ЕАР для целей тестирования.
Сертификат или смарт-карта. В этом методе используется сертификат Х.509, выданный пользователю и хранящийся на смарт-карте для обеспечения аутентификации.
Пакет MD5-CHAP добавлен в состав протокола ЕАР в качестве диагностического инструмента. Если в процессе развертывания аутентификации по смарт-картам возникают проблемы и необходимо убедиться, что проблема не в протоколе ЕАР, можно включить обратимые пароли, изменить пароль тестового пользователя для получения обратимой копии и воспользоваться методом MD5-CHAP для проверки работоспособности механизма ЕАР. Не используйте пакет MD5-CHAP для промышленной аутентификации. -
Использование смарт-карт для аутентификации требует развертывания инфраструктуры открытого ключа (PKI), в которую администратор вносит пользователя смарт-карты и получает для пользователя сертификат Х.509 от центра сертификации. Полученный сертификат хранится в памяти смарт-карты. Пользователь вставляет смарт-карту в устройство считывания при установке коммутируемого соединения. Дополнительная информация о генерации сертификатов и их сохранении на смарт-картах приводится в разделе “Применение смарт-карт для удаленного доступа".
Программное обеспечение клиента коммутируемого доступа должно быть настроено на использование аутентификации по смарт-картам. Для клиентов Windows соответствующие параметры доступны на вкладке Security (Безопасность) в окне свойств коммутируемого соединения (рис. 20.8).
Последовательность действий при выполнении транзакции аутентификации по смарт- картам рассматривается в процедуре 20.2.
Процедура 20.2. Транзакция аутентификации по смарт-карте при использовании протокола ЕАР
При установке коммутируемого соединения локальный поставщик служб криптографии CSP (Crypto Service Provider) запрашивает у пользователя установку смарт-карты в устройство считывания и получает у пользователя номер PIN. Номер PIN не является эле-
ментом транзакции PPP. Он используется поставщиком служб криптографии (CSP) для получения доступа к информации на смарт-карте.
На этапе работы протокола LCP клиент и сервер договариваются о методе аутентификации по протоколу ЕАР.
В начале фазы аутентификации клиент отправляет пакет ЕАР, в котором указывается основное имя пользователя в формате пользователь@домен. корень.
RRAS-сервер создает безопасное соединение с контроллером домена и проверяет существование пользователя, предоставившего основное имя пользователя. Такая проверка основного имени пользователя требует доступа к Active Directory, поэтому изолированные серверы удаленного доступа не под держивают аутентификацию по смарт-картам.
Если основное имя пользователя существует в базе данных Active Directory, сервер удаленного доступа возвращает копию сертификата Х.509 и предоставляет список корневых центров сертификации из локального хранилища доверенных корневых центров.
Клиент проверяет сертификат сервера с помощью стандартных проверок PKCS на доверие и отзыв. После этого список доверенных центров сертификации сравнивается с центром сертификации, который подписал сертификат смарт-карты. Если найдено совпадение, клиент передает копию сертификата серверу.
Сервер и клиент используют открытые ключи друг друга, извлеченные из соответствующих сертификатов Х.509, для проверки цифровой подписи, которая применяется при завершающем обмене данными. Если проверка завершается успешно, транзакция аутентификации считается успешной.
Рис. 20.8. Окно свойств коммутируемого соединения. Вкладка Security (Безопасность), на которой включена аутентификация по смарт-карте
Как и в случае стандартной транзакции PPP CHAP, аутентификация по смарт-карте используется только для создания канала данных. Пользователю придется дополнительно пройти аутентификацию в сети. Для такой аутентификации также можно воспользоваться смарт-картой, а можно вернуться к использованию пароля. Лучшим вариантом является I
использование смарт-карты и для аутентификации в сети. Для этого можно воспользоваться параметром Logon Using Dial-Up Connection (С использованием удаленного доступа) в окне Winlogon.
Если смарт-карты используются для регистрации в сети, пользователи не будут знать собственных паролей. Если потребуется регистрация на собственном компьютере без использования коммутируемого соединения, смарт-карта может использоваться и для локальной регистрации. Система будет кэшировать регистрационные даннь!е из смарт-карты, как и в случае использования регистрационных данных на основе пароля. (Пара “открытый/секретный ключ”, а также PIN, не кэшируются. Кэшируется только основное имя пользователя и структура данных, в которой хранится идентификатор безопасности пользователя.)
Если будет принято решение использовать смарт-карты и для аутентификации в локальной сети, определенную помощь в администрировании среды смарт-карт окажут новые возможности операционных систем Windows Server 2003 и Windows ХР.
Для аутентификации по смарт-картам можно воспользоваться утилитой runas. Синтаксис соответствующей команды выглядит как runas /и: user@domain.root /smartcard. Это не относится к окну RunAs. В этом окне необходимо указывать регистрационные данные на основе пароля.
Для аутентификации по смарт-картам можно воспользоваться утилитой net use. Синтаксис соответствующей команды выглядит как net use * \\сервер\ресурс /smartcard. Это не относится к окну Map Network Drive (Подключить сетевой диск). В этом окне необходимо указывать регистрационные данные на основе пароля.
Использование смарт-карт поддерживается для аутентификации в сеансе Terminal Server (Сервер терминалов). Это упрощает управление с помощью Remote Desktop (Удаленный рабочий стол)..
Ограничения смарт-карт
Несмотря на дополнительные функциональные возможности смарт-карт, предоставленные в операционных системах Windows Server 2003 и Windows ХР, в наборе этих возможностей существует ряд пробелов. Например, на смарт-карте нельзя хранить регистрационные данные пользователя для шифрованной файловой системы (EF5). Эта возможность позволила бы отказаться от хранения секретного ключа пользователя в локальном профиле.
Кроме этого, система будет настаивать на хранении пароля для пользователя смарт-карты, даже если пользователю этот пароль никогда не потребуется. Для минимизации опасности использования паролей можно воспользоваться групповыми политиками, чтобы задать минимальную длину и сложность пароля с установкой паролей администратором. Проще всего это сделать с помощью команды net user, хотя можно воспользоваться и функциями Active Directory Services Interface (ADSI). Для изменения пароля необходимо зарегистрироваться с правами администратора и ввести команду net user <имя_пользователя> <пароль> в приглашении командной строки.
Если ограничить минимальную длину пароля 14 символами с обязательной комбинацией букв верхнего и нижнего регистров, цифр и специальных символов, то можно быть уверенным, что атака простым перебором паролей завершится неудачно.
Можно установить групповую политику для блокирования всех попыток регистрации, кроме регистрации по смарт-картам, но из этой политики придется исключить некоторых администраторов, чтобы получить доступ к домену в случае проблем в работе инфраструктуры открытого ключа (PKI).
Аутентификация с помощью RADIUS
Если используется сервер удаленного доступа, не входящий в домен, но пользователей необходимо аутентифицировать на основе доменных регистрационных данных, можно воспользоваться тем же методом аутентификации, который используется большинством провайдеров услуг Интернета — технологией RADIUS (Remote Authentication Dial-In User Services — службы удаленной аутентификации пользователей коммутируемого доступа/
Метод аутентификации RADIUS разработан компанией Livingston Systems и теперь является открытым стандартом, описанным в документах RFC 2138, “Remote Authentication Dial-In User Service (RADIUS)”, и RFC 2548, “Microsoft Vendor-specific RADIUS Attributes”. Компания Nortel описала такие же расширения в документе RFC 2882, “Network Access Servers Requirements: Extended RADIUS Practices”.
RADIUS одновременно является механизмом аутентификации и методом реализации политик с учетом личности пользователя, платформы, метода подключения и других атрибутов. Провайдеры услуг Интернета используют политики RADIUS для реализации хитростей, подобных следующей: “Это пользователь X. Он звонит из района с кодом 623 на сервер сетевого доступа в Альбукерке. Предоставить пользователюX IP-адрес 24.3.28.201 и выполнить маршрутизацию через маршрутизатор с наименьшим приоритетом”.
Служба IAS
В операционной системе Windows технология RADIUS реализована с помощью службы IAS (Internet Authentication Service — служба аутентификации Интернета). Основным преимуществом использования службы IAS по сравнению со службами RADIUS от сторонних производителей является возможность получения регистрационных данных пользователей непосредственно из базы данных Active Directory. Это позволяет избавиться от дублирующих баз данных и дублированных паролей, которые придется синхронизировать. Кроме этого, сервер IAS можно установить в любом удобном месте, где доступен контроллер домена. Службу IAS можно запустить даже непосредственно на контроллере домена с целью получения максимальной производительности.
На рис. 20.9 показана простая конфигурация RADIUS на основе операционной системы Windows Server 2003. Клиенты коммутируемого доступа устанавливают соединение с сервером удаленного доступа, который настроен на использование RADIUS в качестве механизма аутентификации. Сервер IAS настроен на получение запросов на аутентификацию, которые отправляются сервером удаленного доступа. Регистрационные данные пользователей запрашиваются у контроллера домена под управлением Windows Server 2003 или Windows 2000 по защищенному каналу.
Сервер IAS может обрабатывать запросы RADIUS от любого устройства RADIUS (соответствующего требованиям документов RFC), а не только от серверов маршрутизации и удаленного доступа под управлением Windows Server 2003. Это относится к большинству концентраторов удаленного доступа, серверам терминалов и пограничных маршрутизаторов, продаваемых основными производителями. Для обеспечения отказоустойчивости может использоваться сразу несколько серверов IAS. Дополнительная информация об установке сервера IAS и настройке сервера удаленного доступа Windows Server 2003 на использование IAS для аутентификации по технологии RADIUS приводится в разделе “Настройка службы IAS".
Настройка профилей удаленного доступа
Если служба IAS не используется, политики RADIUS, заданные для определенных пользователей коммутируемого доступа, настраиваются с помощью консоли RRAS (Маршрутизация и удаленный доступ), доступной через пиктограмму Remote Access Policies (Политики удаленного доступа).
клиента PPP
SMB-соединение с файловым сервером или сервером печати маршрутизируется через RRAS-сервер
или сервер печати
Основная граница брандмауэра
Рис. 20.9. Схема реализации технологии RADIUS на основе сервера удаленного доступа под управлением Windows Server 2003 и сервера IAS под управлением операционной системы Windows Server 2003
Каждая политика RADIUS связана с профилем. Терминология оказывается несколько запутанной, поскольку два термина используются в нескольких разных контекстах. Рассматривайте политику RADIUS, как определение, кто получит конкретный параметр, а профиль определяет, какой параметр будет назначен.
Например, принятая по умолчанию политика RADIUS определяет допустимое время регистрации с понедельника по воскресенье с полуночи до полуночи. Эта политика применяется ко всем пользователям, осуществляющим коммутируемый доступ на сервер. Профиль этой политики описывает параметры аутентификации и IP-адреса, которые будут применяться для пользователей, подключающимся по коммутируемым соединениям, которые подпадают под действие этой политики. В данном случае под действие политики подпадают все пользователи.
Параметры аутентификации в профиле RADIUS копируют значения, заданные в свойствах RRAS-сервера, но автоматическая синхронизация не обеспечивается. Помните об этом, так как можно потратить несколько часов на устранение ошибки, рассматривая параметры RRAS-сервера, когда проблема на самом деле связана с сервером RADIUS.
Параметры профиля на вкладке Encryption (Шифрование) определяют шифрование данных между клиентом коммутируемого доступа и сервером удаленного доступа (рис. 20.10).
Доступны четыре варианта шифрования.
Basic (Простое) использует потоковое шифрование МРРЕ RC4 с длиной ключа 40 бит или блочное шифрование DES, в зависимости от типа соединения.
Stronger (Надежное) использует потоковое шифрование МРРЕ RC4 с длиной ключа 56 бит или блочное шифрование DES.
Strongest (Максимально надежное) использует потоковое шифрование МРРЕ RC4 с длиной ключа 128 бит или блочное шифрование DES.
Выбор варианта No Encryption (Без шифрования) без выбора остальных параметров отключает все формы шифрования. Установка флажка No Encryption (Без шифрования) одновременно с выбором другого варианта позволяет клиенту договориться о подходящем методе шифрования с сервером.
Рис. 20.10. Профиль RADIUS, связанный с политикой удаленного доступа
На оставшихся вкладках определяются политики, которые управляют конфигурацией клиентов коммутируемого доступа, имеющих доступ к системе, и уточняют ее. Многие параметры повторяют параметры, настраиваемые на клиентах Windows и в свойствах RRAS-cep- вера. Это связано с тем, что сервер IAS может использоваться любым сервером RADIUS, а не только RRAS-серверами на основе Windows Server 2003.
Аутентификация коммутируемого доступа и аутентификация в домене
При установке соединения с сервером удаленного доступа выполняются две транзакции аутентификации. Одна процедура аутентификации выполняется во время транзакции РРР, а вторая — при подключении пользователя к общему ресурсу на сервере в пределах домена уже после установки соединения РРР. Механизм получения регистрационных данных в удаленном домене зависит от операционной системы пользователя.
Когда пользователи компьютеров под управлением операционных систем Windows Эх не подключены к сети, они обычно пропускают окно регистрации в домене для быстрого получения доступа к рабочему столу. После этого для установки подключения к серверу удаленного доступа используется окно Dial-Up Networking (Коммутируемый доступ). После установки соединения отображается окно регистрации в домене, где пользователи вводят регистрационные данные для аутентификации. Если пользователь откажется пройти аутентификацию на этом этапе, разрешения на доступ к сети не предоставляются. Так как пользователь прошел аутентификацию в домене, при каждом подключении к серверу через коммутируемое подключение сервер в состоянии аутентифицировать пользоваться с помощью механизма классической сквозной аутентификации.
Пользователи компьютеров под управлением Windows NT имеют два альтернативных метода аутентификации. Первый вариант заключается в установке PPP-соединения до регистрации на рабочей станции. Для этого в окне GINA, которое используется службой Winlogon, содержится параметр Log On Using Dial-Up Connection (Загружаться с использованием
удаленного доступа). Если пользователь установит этот флажок, система установит РРР- соединение с сервером удаленного доступа и служба Winlogon перехватит управление для регистрации в домене, как будто пользователь регистрируется в локальной сети. Современные клиенты Windows для этой транзакции используют протокол Kerberos. В операционных системах Windows NT 4.0 после Service Pack 3 используется протокол NTLMv2.
С другой стороны, пользователь может зарегистрироваться на локальном компьютере с использованием кэшированных регистрационных данных, после чего установить РРР-соеди- нение с сервером удаленного доступа. В таком случае пользователь не сразу получает доступ к домену. При первой попытке обращения к серверу в составе домена пользователь получает запрос на ввод доменных регистрационных данных. Если сервер работает под управлением операционной системы Windows Server 2003 или Windows 2000, служба локального администратора безопасности (LSA) на клиенте перехватит инициативу и получит билет TGT Kerberos для пользовательского домена, после чего получит билет сеанса доступа Kerberos для каждого сервера, к которому обращается пользователь. (Такой механизм будет работать только в том случае, если пользователь сможет обнаружить DNS-сервер через коммутируемое соединение.)
Клиент кэширует билет TGT и билет сеанса доступа из того же домена, в который входит пользователь. Билеты сеанса доступа для серверов в удаленном домене не кэшируются, если пользовательский домен и домен сервера удаленного доступа не работают в режиме Native. Для просмотра содержимого кэша билетов можно воспользоваться утилитами Kerbtray и Klist из состава Resource Kit. С этого момента пользователь аутентифицирован в домене и больше не получает запросов на ввод регистрационных данных.
Если входящий в домен сервер, к ресурсам которого обращается пользователь, работает под управлением Windows NT 4.0, пользователь получает запрос на ввод регистрационных данных и сервер выполняет классическую сквозную аутентификацию NTLM для проверки личности пользователя. Пользователь не получает билеты Kerberos и получает новый запрос на ввод регистрационных данных при обращении к другому серверу.
Это важно помнить при устранении неисправностей. Клиенты под управлением операционных систем Windows ХР и Windows 2000 принимают участие в транзакции Kerberos в домене Active Directory, даже если пользователь не прошел регистрацию в домене. Это минимизирует трудозатраты пользователя и ускоряет доступ к серверам, особенно если это происходит в глобальной сети, где классическая сквозная аутентификация работает исключительно медленно.
Единственной разницей между этой ситуацией и регистрацией в домене с самого начала с помощью флажка Log On Using Dial-Up Connection (Загружаться с использованием удаленного доступа) является применение групповых политик.
При регистрации пользователя в домене из окна Winlogon, загружаются групповые политики. Набор групповых политик, получаемых клиентом, зависит от значения параметра Slow Link (Низкоскоростная линия) в групповой политике. По умолчанию значение этого параметра равняется 500 Кбит/с. Административные шаблоны и параметры безопасности загружаются независимо от скорости соединения.
Аутентификация в нескольких доменах
Если используется лес, состоящий из нескольких доменов, пользователи любого домена должны иметь возможность подключаться к серверу удаленного доступа в любом другом домене. Это относится к доступу через непосредственное коммутируемое подключение и к доступу через виртуальную частную сеть (VPN). В конце концов, если пользователь из Брюсселя работает сверхурочно в Токио, зачем звонить в Европу, если отличный сервер удаленного доступа есть в Японии? '
Когда пользователь из одного домена устанавливает PPP-соединение с сервером коммутируемого доступа в другом домене, сервер коммутируемого доступа должен получить реги-
страционные данные подьзователя от контроллера домена пользователя. Это связано с тем, что только контроллеры домена пользователя хранят полную копию контекста именования. В глобальном каталоге (Global Catalog — GC) хранится недостаточный объем информации для аутентификации пользователя по протоколу РРР.
Это и является проблемой. Служба маршрутизации и удаленного доступа RRAS работает под управлением учетной записи Local System. При подключении к базе данных Active Directory используется билет Kerberos, который получен локальным компьютером. Учетная запись компьютера из одного домена не имеет привилегий на чтение информации о пользователях из базы данных Active Directory в другом домене. Похожие проблемы возникают, когда пользователь, устанавливающий соединение по коммутируемой линии, принадлежит домену в одном лесу федерации, a RRAS- или IAS-сервер является членом домена в другом лесу.
Для RRAS-серверов в пределах одного леса эта проблема решается благодаря добавлению RRAS-сервера в группу RAS and IAS Servers в каждом домене леса. Эта группа получает следующие права доступа к объектам класса User в локальном домене.
Logon Information (Регистрационная информация)
Group Membership (Членство в группах)
Account Restrictions (Ограничения учетных записей)
Remote Access Information (Информация удаленного доступа)
Набор этих разрешений позволяет серверам из группы RAS and IAS Servers получать информацию о пользователе из базы данных Active Directory, необходимую для завершения транзакции аутентификации по протоколу РРР.
Совет по использованию системного реестра:
постоянные коммутируемые соединения
Обычно при завершении сеанса пользователя любое коммутируемое соединение автоматически разрывается. Для сохранения коммутируемых соединений в перерыве между сеансами пользователя можно внести в системный реестр следующее изменение:
Раздел: HKLM\Software\Microsoft\Windows Windows Server 2003\CurrentVersion\ Winlogon
Запись: KeepRASConnections
Значение: reg_SZ (это не опечатка; для хранения этого значения используется тип string)
Значение: 1
Кроме этого, группе RAS and IAS Servers предоставлены права Read/Write (Чтение/ Запись) для объекта RAS and IAS Servers Access Check в контейнере cn=System, dc=<AOMeH>, дс=<корень>. Этот объект используется в качестве “пробного камня”. Если сервер не в состоянии прочитать содержимое этого объекта, сервер понимает, что не имеет доступа к остальной части контекста именования и немедленно возвращает клиенту сообщение об ошибке.
При первом запуске службы удаленного доступа мастер автоматически добавит сервер в группу RAS and IAS Servers в локальном домене. В других доменах сервер придется добавлять в эту группу вручную. Если этого не сделать, пользователи будут получать сообщение об ошибке при попытке установить PPP-соединение. В сообщении будет указываться, что сервер аутентификации не ответил в пределах периода ожидания. Это то же самое сообщение об ошибке, которое выдается, если неправильно настроен уровень IPSec протокола L2TP. В таком случае не идите по длинному пути устранения ошибки, так как на самом деле эта проблема решается очень просто.
Серверы маршрутизации и удаленного доступа (RRAS-серверы) в различных лесах могут использовать новую возможность службы IAS. Эта возможность позволяет IAS-серверу передавать запросы на аутентификацию IAS-серверу в другом лесу.
Стандартная транзакция аутентификации по протоколу РРР
Входите домен АВходите домен АРРР-соединениес аутентификацией по протоколу MS-CHAPv2РРР-соединениес аутентификацией по протоколу MS-CHAPv2домена Windows Server 2003домена Windows Server 2003Контроллер домена Windows Server 2003Контроллер домена Windows Server 2003Межсферная аутентификация KerberosМежсферная аутентификация KerberosКлассическая сквозная аутентификация NTLMКлассическая сквозная аутентификация NTLMПеред исследованием различных методов аутентификации, применяемых в протоколе РРР, стоит подробно рассмотреть относительно простой пример транзакции. На рис. 20.11 показана схема коммутируемого доступа между клиентом Windows ХР и сервером удаленного доступа Windows Server 2003. Сервер входит в один домен, а пользователь — в другой. В процедуре 20.3 описана последовательность событий, которые происходят при использовании модема для подключения непосредственно к серверу.
Входите домен А
Входите домен А
РРР-соединениес аутентификацией по протоколу MS-CHAPv2
РРР-соединениес аутентификацией по протоколу MS-CHAPv2
домена Windows Server 2003
домена Windows Server 2003
Контроллер домена Windows Server 2003
Контроллер домена Windows Server 2003
Межсферная аутентификация Kerberos
Межсферная аутентификация Kerberos
Классическая сквозная аутентификация NTLM
Классическая сквозная аутентификация NTLM
Пользователь, устанавливающий соединение по коммутируемой пинии (входит в домен Б)
Рис. 20.11. Схема коммутируемого доступа между клиентом Windows ХР и RRAS-сервером под управлением Windows Server 2003, находящимися в лесу из нескольких доменов
Процедура 20.3. Подробное описание стандартной аутентификации по протоколу РРР
После установки физического соединения между модемами начинается транзакция РРР. Сначала используется протокол LCP и выполняется согласование параметров соединения. Кроме прочих согласуемых параметров, на этом этапе по умолчанию выбирается протокол аутентификации MS-CHAPv2. Если подходящий метод аутентификации не может быть согласован, протокол LCP завершает работу и пользователь получает сообщение Unable to connect (Не удалось установить соединение).
После завершения работы протокола LCP начинается транзакция протокола РРР CHAP (начинается согласование параметров соединения). При использовании протокола MS-CHAPv2 сервер отправляет клиенту случайное число длиной 16 байт, которое выступает в роли вызова.
Клиент генерирует ответ на вызов в виде хеша MD4, созданного на основе трех составляющих: вызова сервера, 16-байтового случайного числа, сгенерированного на клиенте, и пароля пользователя, хешированного по алгоритму MD4. ,
Клиент отправляет серверу удаленного доступа ответ на вызов с именем пользователя и именем домена.
Сервер создает безопасный канал связи (зашифрованный канал RPC) с регистрационным сервером, в качестве которого в данном примере выступает контроллер домена Windows Server 2003. (Другой вариант подключения и аутентификации в зависимости от версии домена рассматривается в разделе “Ограничения аутентификации в доменах Windows NT 4.0 и доменах, работающих в режиме Mixed”.)
Сервер удаленного доступа использует безопасный канал для подключения к контроллеру домена и проверки существования имени пользователя в указанном домене. Если имя существует, сервер удаленного доступа запрашивает копию хеша MD4 пароля пользователя, список параметров безопасности пользователя и флаг, разрешающий пользователю коммутируемый доступ.
В этом примере контроллер домена не в состоянии ответить на запрос, так как пользователь принадлежит другому домену. Контроллер домена связывается с контроллером домена пользователя и получает билет TGT Kerberos от имени сервера удаленного доступа. Билет TGT возвращается серверу удаленного доступа.
Сервер удаленного доступа использует билет TGT для установки безопасного соединения с контроллером домена в домене пользователя. Это соединение используется для получения регистрационных данных пользователя и разрешений на коммутируемый доступ. Для этого придется обратиться к учетной записи пользователя в базе данных Active Directory. Именно поэтому сервер удаленного доступа должен входить в группу RAS and IAS Servers.
Получив хешированный пароль пользователя, сервер удаленного доступа проверяет полученный от пользователя ответ, хешируя те же составляющие, что и клиент. Если результаты совпадают, личность пользователя считается подтвержденной. Сервер маршрутизации и удаленного доступа возвращает клиенту сообщение Success.
На этом этап PPP CHAP транзакции установки соединения по протоколу РРР завершен. Клиент и сервер переходят к протоколу СВСР, а затем разрывают соединение при использовании метода обратного звонка.
Клиент и сервер переходят к использованию протоколов IPCP (Internet Protocol Control Protocol — протокол управления протоколом Интернета) и ССР (Configuration Control Protocol — протокол управления конфигурацией) одновременно. Именно на этом этапе внешний интерфейс получает IP-адрес и договаривается о параметрах шифрования, выбранных клиентом и сервером.
На этом транзакцию РРР можно считать завершенной. Данные от клиента маршрутизируются через RRAS-сервер в основную сеть, где клиент проходит аутентификацию при установке флажка Logon Using Dial-Up Connection (Загружаться с использованием коммутируемого доступа).'■
Сравнение методов аутентификации для
различных клиентов коммутируемого доступа
В этом разделе рассматриваются аутентификация по протоколу РРР и доменная аутентификация, которые используются различными клиентами. Это помогает разделить проблемы, которые возникают при подключении, на категории, связанные с протоколом РРР и с доменной аутентификацией.
В примерах этого раздела используется сетевая конфигурация, показанная на рис. 20.12. На этой схеме сервер удаленного доступа работает под управлением Windows Server 2003. В пределах леса существует два домена. Сервер удаленного доступа является членом родительского домена, хотя смена принадлежности сервера не повлияла бы на результаты. С точки зрения разрешений на коммутируемый доступ корневой домен леса не имеет никаких особенных настроек.
PPP-соединениеPPP-соединениеServer 2003Server 2003Контроллер домена Windows Server 2003Контроллер домена Windows Server 2003Файловый сервер и сервер печати под управлением Windows Server 2003 (входит в домен Б)Файловый сервер и сервер печати под управлением Windows Server 2003 (входит в домен Б)Межсферная аутентификация KerberosМежсферная аутентификация KerberosКлассическая сквозная аутентификация NTLMКлассическая сквозная аутентификация NTLMВходитвдомен АВходитвдомен А
PPP-соединение
PPP-соединение
Server 2003
Server 2003
Контроллер домена Windows Server 2003
Контроллер домена Windows Server 2003
Файловый сервер и сервер печати под управлением Windows Server 2003 (входит в домен Б)
Файловый сервер и сервер печати под управлением Windows Server 2003 (входит в домен Б)
Межсферная аутентификация Kerberos
Межсферная аутентификация Kerberos
Классическая сквозная аутентификация NTLM
Классическая сквозная аутентификация NTLM
Входитвдомен А
Входитвдомен А
Файловый сервери сервер печатипод управлениемWindows Server2003 (входит вдомен А)
Рис. 20.12. Схема, на которой показаны методы аутентификации в различных ситуациях коммутируемого доступа
Лес и два домена в пределах леса переведены на полные функциональные возможности Windows Server 2003, хотя результаты не отличались бы, если бы лес работал на функциональном уровне Windows 2000 Native. Функциональный уровень Mixed оказывал бы влияние на результат, если на контроллерах домена включить режим NT4 Emulation. Дополнительная информация приводится в главе 9, “Развертывание доменов Windows Server 2003”.
Сценарий 1. Пользователь коммутируемого доступа на изолированной рабочей станции под управлением Windows ХР или Windows 2000 Professional
Клиент устанавливает PPP-соединение и проходит аутентификацию по протоколу MS- CHAPv2 с максимальным принятым по умолчанию уровнем безопасности. Для успеха такой аутентификации пользователь должен иметь регистрационные данные в одном из доменов леса. Клиент должен указать имя домена. Это относится даже к рабочим станциям под управлением Windows ХР Home Edition, несмотря на то что эта операционная система не поддерживает вхождение в домен. На этом этапе выполняется аутентификация пользователя, а не рабочей станции.
Если пользователь является членом домена, отличного от домена сервера удаленного доступа, сервер должен входить в группу RAS and IAS Servers в пользовательском домене. Это позволит серверу получить доступ к регистрационным данным пользователя.
После установки PPP-соединения и при подключении к совместно используемому ресурсу на одном из серверов домена сервер выдает запрос на ввод регистрационных данных. Не забывайте, что пользовательская рабочая станция не является членом домена (изолированная рабочая станция) и не может принимать участие в транзакции Kerberos. Запрашиваемый (целевой) сервер использует сквозную аутентификацию NTLM, взаимодействуя со своим регистрационным сервером (logon server) для проверки аутентификации пользователя, который использует метод “запрос-ответ”.
В результате пользователь может получать доступ к ресурсам любого домена в пределах леса. Это справедливо даже для доменов, работающих в режиме Mixed. Пользователь получат запрос на ввод регистрационных данных при каждом подключении к серверу.
Сценарий 2. Пользователь коммутируемого доступа на рабочей станции под управлением отличной от Windows операционной системы
Для начального PPP-соединения применяется аутентификация по протоколу CHAP, если компьютер не настроен на использование пакета, обеспечивающего поддержку протокола MS-CHAPv2. Аутентификация по протоколу CHAP требует хранения в базе данных Active Directory обратимых паролей, поэтому необходимо внести соответствующие изменения в групповые политики.
После установки PPP-соединения последующие транзакции ничем не отличаются от транзакций для клиентов Windows. Например, если клиентский компьютер работает под управлением операционной системы Linux и использует актуальную версию пакер Samba, клиент будет предоставлять регистрационные данные по протоколу NTLMv2 при каждом обращении к серверу в пределах домена, а сервер будет проверять эти регистрационные данные с помощью классической сквозной аутентификации.
Сценарий 3. Пользователь коммутируемого доступа на рабочей станции под управлением Windows 9х
Клиент устанавливает PPP-соединение и выполняет аутентификацию по протоколу MS- CHAPv2. (Только оригинальная версия операционной системы Windows 95 использует протокол MS-CHAPvl.) Пользователь получает запрос на регистрацию в домене после установки соединения по коммутируемому каналу. В этой транзакции используется классический протокол LanMan Challenge-Response (пароль хешируется по алгоритму DES).
При подключении пользователя к совместно используемому ресурсу на сервере в пределах домена, сервер проводит аутентификацию пользователя с помощью сквозной аутентификации LanMan на собственном регистрационном сервере. Пользователь не получает запрос на ввод регистрационных данных, так как регистрация в домене уже завершена. Пользователь получает доступ к ресурсам в любом домене, если промежуточные домены работают в режиме Native или более высоком режиме.
На эту транзакцию оказывает влияние групповая политика Do Not Store LAN Manager Hash Value On Next Password Change (He сохранять значение хеша LaN Manager при следующем изменении пароля). Включение этой политики предотвращает хранение исключительно уязвимых паролей LanMan DES в базе данных Active Directory. Это позволяет защитить систему от проникновения хакеров через ненадежные пароли с помощью таких программ, как LOphtcrack.
Включение этой политики не дает клиентам Windows 9х регистрироваться в домене Active Directory, если на клиентах не установлено исправление Dsclient, доступное на установочном компакт-диске Windows Server 2003 или Windows 2000 Server. При установке этого
исправления клиент модернизируется для использования аутентификации по протоколу NTLMv2. Дополнительную информацию можно получить в главе 11, “Безопасность доступа по сети и протокол Kerberos”.
Если включить эту групповую политику и попытаться установить соединение по коммутируемому каналу с клиентом Windows 9х без установленного исправления Dsclient, то будет получен следующий результат: установка PPP-соединения завершится успешно, но последующая регистрация в домене окажется неудачной. Если отказ при регистрации в домене вполне ожидаем, так как в базе данных Active Directory отсутствуют хешированные пароли LanMan, то успех при установке PPP-соединения должен удивить. По этому результату можно понять процедуру получения регистрационных данных RRAS-Сервером от регистрационного сервера.
Причина успеха при установке начального PPP-соединения заключается в том, что в RRAS используется сквозная аутентификация NTLM для того, чтобы получить регистрационные данные пользователя для транзакции аутентификации по протоколу MS-CHAP. Использование NTLM приводит к тому, что хешированный пароль пользователя Windows NT возвращается независимо от платформы, на которой работает пользователь, подключающийся по линии коммутируемого доступа. Дополнительная информация приводится во врезке “NTLM и RRAS”.
При установке PPP-соединения с классического клиента Windows 95 по протоколу MS- CH APvl может показаться, что PPP-соединение завершилось неудачно на фазе аутентификации, но на самом деле отказ происходит на этапе использования протокола IPCP, когда клиент пытается договориться о шифровании, а на сервере отсутствует пароль LanMan. Протокол MS-CHAPv2 использует хешированный пароль Windows NT, поэтому выбор алгоритма шифрования завершается успешно.
Конечным результатом для клиентов Windows 9х является возможность установки коммутируемых соединений с любым сервером удаленного доступа и получение доступа к любым ресурсам любого домена в пределах леса. Если пароли LanMan отключены в групповой политике, на клиенте должно быть установлено исправление Dsclient.
NTLM и RRAS
Существует групповая политика, которая называется Network Security: LAN Manager Authentication и может использоваться для управления методами аутентификации, предлагаемыми и принимаемыми в домене. С помощью этой политики меняется содержимое раздела системного реестра HKLM\System\CurrentControlSet\Control\LSA\LMConipatibilityLevel. Существует шесть возможных значений.
Send lm and NTLM responses (Отправлять ответы LM и NTLM)
Send LM and NTLM responses - Use NLTMv2 session security if negotiated (Отправлять ответы LM и NTLM — использовать безопасность сеанса NTLMv2, если об этом договорились стороны)
Send NTLM response only (Отправлять только ответы NTLM)
Send NTLMv2 response only (Отправлять только ответы NTLMv2)
Send NTLMv2 response only \ refuse LM (Отправлять только ответы NTLMv2 / отказывать для LM)
Send NTLMv2 response only \ refuse LM and NTLM (Отправлять только ответы NTLMv2 / отказывать для LM и NTLM)
Самым безопасным является последний вариант, так как он защищает контроллер домена от ответов на все запросы, кроме NTLMv2. В таком случае через соединение не будут отправляться ненадежно хешированные вызовы и ответы.
Если выбрать самый безопасный вариант, PPP-соединение не будет устанавливаться с серверами удаленного доступа в пределах всего домена. Это связано с тем, что для получения регистрационных данных пользователя серверы удаленного доступа используют протокол NTLM, а не NTLMv2.
При установке групповой политики, блокирующей аутентификацию по протоколу NTLM, у серверов удаленного доступа не остается механизма получения регистрационных данных пользователя и попытка установить PPP-соединение завершается неудачно. В таком случае пользователи коммутируемого доступа несколько раз получают запрос на ввод правильного пароля, после чего соединение разрывается. Это относится к клиентам Windows 9х, Windows 2000 и Windows ХР.
Если принято решение применить политику Network Security: LAN Manager Authentication, выберите уровень для отказа на запросы LM, но не выбирайте отказ на запросы NTLM.
Ограничения аутентификации в доменах Windows NT 4.0 и доменах, работающих в режиме Mixed
Присутствие в сети классических резервных контроллеров домена Windows NT приводит к невозможности предоставления полного спектра функциональных возможностей при аутентификации удаленного доступа в операционных системах Windows Server 2003 и Windows 2000. Пока существует вероятность, что сервер удаленного доступа попытается проверить пользователя коммутируемого доступа с помощью сквозной аутентификации на классическом резервном контроллере домена (ВВС), не могут быть реализованы следующие возможности.
Управление соединением с помощью политик удаленного доступа
Проверка идентификатора вызова
Предоставление статических IP-адресов и статических маршрутов
Рис. 20.13. Окно свойств пользователя. Вкладка Dial-in (Коммутируемый доступ)
Эти возможности доступны в окне свойств учетной записи пользователя на консоли Active Directory — Users and Computers (Active Directory — пользователи и компьютеры) на вкладке Dial-in (Коммутируемый доступ) (рис. 20.13). Параметры остаются неактивными, пока домен
не будет переключен в режим Native. На этом этапе все классические резервные контроллеры домена должны быть отключены от сети.
Переключение домена в режим Native может застать службу поддержки врасплох, так как для пользователей изменятся принятые по умолчанию права коммутируемого доступа. В режиме Mixed новым пользователям коммутируемый доступ по умолчанию запрещен. В режиме Native права доступа управляются политикой удаленного доступа, которая по умолчанию устанавливается равной значению Grant Access (Предоставить доступ).
Серверы удаленного доступа под управлением Windows NT 4.0 и домены Active Directory
Существует еще один аспект, который необходимо рассмотреть до развертывания серверов удаленного доступа (Remote Access Server — RAS) под управлением Windows Server 2003. Этот аспект связан с использованием RAS-серверов Windows NT 4.0, которые все еще могут использоваться в сети. Если не обеспечить особые условия для таких серверов, они не смогут выполнять аутентификацию пользователей в домене Active Directory. Причины этого кроются в основах сетевой подсистемы Windows в LanMan Server.
Как было показано, протокол MS-CHAPv2 требует, чтобы сервер удаленного доступа получал хешированный пароль пользователя Windows NT для завершения транзакции аутентификации. Сервер удаленного доступа Windows NT 4.0 подключается к контроллеру домена для получения регистрационных данных пользователя, но контроллер домена отвечает: “Не так быстро, друг. Сначала покажи регистрационные данные Kerberos, и только после этого я предоставлю доступ к базе данных Active Directory".
На самом деле Windows NT 4.0 ничего не подозревает об Active Directory и продолжает отправлять проверенные временем запросы на подключение, пока не откажется от попыток и не выдаст пользователю сообщение Access Denied (Доступ запрещен).
Нулевой сеанс
Сначала достаточно сложно понять, как пользователь на сервере Windows NT 4.0 может получать доступ к Active Directory. Проблема заключается в контексте безопасности службы сервера удаленного доступа, которая работает от имени учетной записи Local System. На компьютере под управлением Windows учетная запись Local System не имеет идентификатора безопасности, а значит, не может устанавливать нормальные соединения с контроллером домена.
В домене Windows NT 4.0 отсутствие контекста безопасности не рассматривалось, как проблема, поскольку сервер удаленного доступа мог устанавливать нулевые сеансы (null session) и подключаться к контроллеру домена. Нулевой сеанс является специальным типом соединения, при котором клиент не предоставляет регистрационных данных и получает ограниченные права доступа на сервере. Сервер удаленного доступа под управлением Windows NT 4.0 использует соединения нулевого сеанса для работы от имени пользователя (impersonation) в степени, необходимой для поиска регистрационных данных пользователя и разрешений на коммутируемый доступ в базах данных SAM и LSA.
Контроллеры доменов Windows Server 2003 и Windows 2000 не поддерживают подключения нулевых сеансов для обращения к базе данных Active Directory. Это позволяет защититься от некоторых атак, которым подвергались (и продолжают подвергаться) классические операционные системы Windows NT. Сервер удаленного доступа, поддерживающий использование Kerberos, может обращаться к базе данных Active Directory при помощи регистрационных
данных Kerberos, полученных учетной записью компьютера. Служба удаленного доступа на сервере Windows NT 4.0 не способна использовать этот механизм, поскольку учетная запись компьютера не в состоянии получить регистрационные данные Kerberos.
Это значит, что у нас появилась проблема. Элементом решения является группа с длинным, но подходящим именем Pre-Windows 2000 Compatible Access. Этой группе предоставляется доступ к следующим атрибутам объекта User в базе данных Active Directory.
Remote Access Information (Информация удаленного доступа)
General Information (Общая информация)
Logon Information (Регистрационная информация)
Group Membership (Членство в группах)
Account Restrictions (Ограничения учетной записи)
Кроме этого, группа получает следующие права доступа для объектов Group.
Read All Properties (Читать все свойства)
List Contents (Просматриватьсодержимое)
Read Permissions (Читать разрешения)
Результат? Эти разрешения предоставляют членам группы Pre-Windows 2000 Compatible Access возможность получать регистрационные данные пользователя, ограничения учетных записей и информацию о членстве в группах. Вся эта информация необходима для обеспечения аутентификации по протоколу MS-CHAPv2.
Анонимный доступ
Теперь начинается самое неприятное. Так как серверы удаленного доступа под управлением Windows NT 4.0 не имеют учетной записи Kerberos, нельзя просто добавить объекты компьютеров в группу Pre-Windows 2000 Compatible Access и ожидать, что аутентификация коммутируемого доступа будет работать. Необходимо создать возможность установки нулевого сеанса, добавив группу Anonymous Logon в группу Pre-Windows 2000 Compatible Access.
В операционной системе Windows 2000 для этой же цели требовалось добавление группы Everyone (Все), а не группы Anonymous Logon. Это связано с изменениями в механизме обработки нулевого сеанса, которые появились с выходом операционной системы Windows Server 2003. В устаревших версиях Windows, включая Windows 2000, для нулевого сеанса по умолчанию предоставлялось членство в группе Everyone (Все). Для этого широкоизвестный идентификатор безопасности группы Everyone (Все) добавлялся в маркер доступа, который автоматически генерировался для соединения нулевого сеанса.
В операционной системе Windows Server 2003 нулевой сеанс не добавляется в группу Everyone (Все). Это “сбивает с толку” программы сканирования портов нулевого сеанса, которые распространяются в сети Интернет и предназначены для взлома сетей Windows. Группа Anonymous Logon получила в операционной системе Windows Server 2003 новый относительный идентификатор (RID), который уникален для домена. Идентификатор безопасности группы Everyone (Все) оставался одинаковым для всех доменов.
Во время работы утилиты Dcpromo и повышения сервера под управлением Windows Server 2003 до контроллера домена предоставляется возможность включения совместимости с операционной системой Windows 2000. При этом группа Anonymous Logon добавляется в группу Pre-Windows 2000 Compatible Access. Группа Everyone (Все) также добавляется в эту группу для сохранения обратной совместимости с операционной системой Windows 2000.
Кроме этого, для чтения отдельных атрибутов в объектах пользователей и групп вместо чтения всего объекта, как это было в операционной системе Windows NT 4.0, на сервер уда-
ленного доступа под управлением Windows NT 4.0 должен быть установлен пакет обновлений SP4 или более новой версии. При установке этого пакета вносятся изменения в функцию г logon и в другие функции, что позволяет компьютеру под управлением Windows NT читать содержимое отдельных атрибутов. ,
Анонимный доступ и безопасность Active Directory
Предоставление нулевому сеансу возможности чтения из базы данных Active Directory создает уязвимое место в системе безопасности, которого стоит избегать, несмотря на ограниченное число атрибутов, управляемых группой Pre-Windows 2000 Compatible Access. По этой причине стоит модернизировать серверы удаленного доступа под управлением Windows NT 4.0 до Windows Server 2003 или Windows 2000 еще до модернизации до домена Active Directory. 4
Если принято решение сохранить совместимость с Windows 2000 для серверов удаленного доступа Windows NT 4.0, то при последующей модернизации уязвимое место можно устранить, исключив группы Anonymous Logon и Everyone (Все) из группы Pre-Windows 2000 Compatible Access.
ВАЖНО! После внесения этого изменения необходимо перезагрузить каждый контроллер домена, чтобы группа Anonymous Logon потеряла возможность чтения из базы данных Active Directory.
Применение смарт-карт для удаленного доступа
Пароли в той или иной форме использовались для аутентификации с помощью компьютера на протяжении полувека. Но скоро наступит тот день, когда аутентификация с помощью пароля станет историей, как запуск двигателя автомобиля вручную или телевизор без дистанционного управления. Да, пароли никогда не исчезнут полностью, но они фундаментально не безопасны, а это делает пароли исключительно опасными в свете изменений компьютерного климата.
Самой очевидной заменой паролям являются биометрические показатели. Проблема регистрации по биометрическим показателям заключается в выборе характеристик для идентификации пользователя и быстрый и безошибочный анализ характеристик с помощью недорогой технологии. Эти требования отодвигают широкое применение биометрической регистрации на несколько лет.
Существует компромисс между биометрическими характеристиками, которые уникально идентифицируют личность, и паролями, которые идентифицируют пользователя, знающего секретную последовательность. Этим компромиссом являются смарт-карты (smart cards). На смарт-карте хранится пара ключей инфраструктуры открытого ключа (PKI), которая выдается пользователю вместе с небольшим процессором, который может предоставлять эти ключи при запросе соответствующим образом запрограммированного драйвера. Вместе с номером PIN, который является еще одной формой пароля, смарт-карта связывает уникальный объект, маркеры инфраструктуры открытого ключа на смарт-карте, с пользователем, который знает секретную последовательность — PIN для смарт-карты.
Номер PIN используется исключительно поставщиком услуг криптографии (Crypto Service Provider) для предоставления доступа к маркерам (token) на смарт-карте. Номер PIN не используется при регистрации. При регистрации пользователя в домене сертификат открытого ключа отправляется контроллеру домена в составе транзакции Kerberos.
Можно подумать, что организация не требует того уровня безопасности, который обеспечивается смарт-картами, и что такой уровень безопасности не требуется на локальных рабочих станциях. Но в любом случае стоит рассмотреть использование смарт-карт для аутенти-
фикации удаленного доступа. Удаленный доступ открывает сеть для различных атак. Использование смарт-карт для аутентификации внешних запросов на регистрацию может обеспечить более надежную защиту от злоумышленников, которые пытаются обнаружить уязвимый пароль для доступа в сеть.
Форматы смарт-карт
Смарт-карты оборудованы достаточным объемом памяти для хранения маркеров различного назначения, например для регистрации, безопасной электронной почты (S/MIME), безопасного Web-доступа и т.д. Многие организации добавляют на поверхность смарт-карты фотографию, что делает смарт-карту не только виртуальным, но и физическим пропуском.
Смарт-карты имеют различную форму. Большинство из них выглядит, как кредитные карты с позолоченными контактными площадками для подключения к внешнему устройству считывания. (Более сложные карты используют магнитные поля для хранения информации, а значит, не нуждаются во внешних контактах.) Устройство чтения подключается к компьютеру через USB-порт или последовательный порт. Для управления устройством считывания используется поставщик услуг криптографии (Crypto Service Provider).
Еще одной популярной формой смарт-карты является небольшая микросхема, помещающаяся на связке для ключей и устанавливающаяся непосредственно в порт USB. Преимуществом такой формы смарт-карт является отказ от необходимости в отдельном устройстве считывания. Недостатком является стоимость микросхемы, которая оказывается в 3 или 4 раза выше стоимости обычной смарт-карты.
Карты SecurlD
Смарт-карты SecurlD от компании RSA не хранят маркеры PKI. Вместо этого используется номер PIN, состоящий из двух частей. Одна из частей известна пользователю, а вторая генерируется и отображается картой. Динамическая часть номера PIN (аутентификатор) меняется каждые 60 секунд и синхронизируется с главным сервером в сети. При регистрации пользователя клиент вводит статическую часть номера PIN, динамическую часть номера и регистрационное имя.
Если необходимо избежать ввода номера PIN пользователем, можно обратить внимание на устройство Sony FIU-710, известное также как “puppy" (“щенок”). В этом устройстве используется комбинация сканера отпечатков пальцев и устройства чтения смарт-карт. Отпечаток пальца используется вместо номера PIN. Сканер отпечатков пальцев защищен от распространенных атак, например, покрытых сульфатом меди желатиновых копий отпечатков.
Выбор смарт-карт
С первого взгляда установка инфраструктуры для смарт-карт выглядит сложной, но на самом деле процедура оказывается достаточно простой. Сложнее всего выбрать производителя. Существует не один десяток производителей. Поиск можно начинать с сайта Hot List по адресу www. andreae.com/hotlist. htm.
Поддержка драйверов
Двумя очевидными кандидатами являются устройства Gemplus и Schlumberger, так как драйверы этих устройств предоставляются в составе операционной системы. (Infineon, ранее — Siemens, также предоставляет поставщика служб криптографии (CSP) в основной поставке, но обычно их микросхемы используются в решениях других производителей, которые могут использовать других поставщиков служб криптографии.)
Даже два производителя со встроенной поддержкой используют элементы, которые придется распространять. Например, драйверы устройства считывания USB от компании Schlumberger предоставляются в составе Windows ХР, но сценарий с расширением . inf не предоставляется, поэтому сценарий придется скопировать в каталог \Windows \ INF на каждой рабочей станции и только после этого подключать устройство считывания к порту USB. Устройство считывания Gemplus требует полной процедуры установки последних версий драйверов.
Ниже перечислены другие производители, которые поддерживают решения на основе смарт-карт для операционных систем Windows Server 2003 и Windows ХР.
Aladdin Knowledge Systems — eToken (www. aks. com)
Rainbow Software — iKey (www. rainbow. com)
Dallas Semiconductor — iButton (www. ibutton. com)
Spyrus — Rosetta USB (www. spyrus. com)
Интеграция c Active Directory
Интеграция c Active Directory очень важна для предотвращения поддержки дубликатов баз данных с учетными записями пользователей. Некоторые производители смарт-карт поддерживают отдельные базы данных, которые могут быть связаны (а могут и не быть связаны) с базой данных Active Directory. Это относится к SecurlD от компании RSA и ActivCard. Решение без полной интеграции в Active Directory не является недопустимым, что усложняет ситуацию.
Интеграция с Kerberos
Предпочтительнее использовать смарт-карты, которые применяют существующие механизмы аутентификации Windows Kerberos, а не собственные механизмы проверки действительности сертификатов. В таком случае сертификаты на смарт-картах применяются совместно с проверенными методами их передачи вместо использования собственного метода, имеющего еще неизвестные уязвимые места.
Рассмотрим, как работает интеграция с Kerberos. При использовании интегрированных с Kerberos смарт-карт в качестве аутентификатора обычно применяется метка времени. Для этого аутентификатора, который обычно шифруется с помощью хешированного пароля пользователя, теперь используется цифровая подпись на основе секретного ключа пользователя, взятого со смарт-карты. Копия сертификата открытого ключа включается в запрос билета TGT, который отправляется на контроллер домена. Контроллер домена проверяет действительность сертификата открытого ключа и использует ключ для проверки цифровой подписи аутентификатора. Если проверка завершается успешно, оставшаяся часть транзакции проходит так же, как и при использовании пароля.
Утилиты управления маркерами
Напоследок во время оценки решений внимательно изучите утилиты, которые предоставляются вместе со смарт-картами для установки номера PIN и форматирования памяти смарт- карты. Удостоверьтесь, что производитель обеспечивает поддержку утилит для операционных систем Windows Server 2003 и Windows ХР. Часто оказывается, что утилиты работают только под управлением Windows 2000, так как производитель не модернизировал утилиты для использования новых поставщиков служб криптографии (CSP) из состава операционных систем Windows Server 2003 и Windows ХР.
Методы применения
Последним этапом при оценке решений является сравнение простоты их применения. Устройства считывания смарт-карт с интерфейсом USB являются идеальным решением, если
рабочие станции оборудованы портами USB. Можно использовать устройства считывания с подключением к последовательному порту (для более старых компьютеров), хотя эти устройства работают медленнее и являются более сложными в установке, особенно если к последовательным портам компьютеров подключены модемы, сканеры и другие периферийные устройства.
Подготовка инфраструктуры открытого ключа для смарт-карт
Выбирая производителя решений для <?март-карт, стоит начать развертывание инфраструктуры открытого ключа (PKI) и подготбвйться к выпуску сертификатов для пользователей смарт-карт. Необходимо установить как минимум один центр сертификации, способный выпускать сертификаты Smart Card User и Smart Card Logon. В идеальном случае необходимо несколько центров сертификации для обеспечения отказоустойчивости и безопасности. Подробная информация о развертывании инфраструктуры открытого ключа (PKI) Windows Server 2003 приводится в главе 18, “Управление инфраструктурой открытого ключа". Если принято решение о развертывании инфраструктуры PKI от стороннего производителя, обязательно протестируйте механизмы создания списков пользователей и сертификации пар ключей, генерируемых смарт-картами. Одни производители предоставляют простые решения, другие — нет.
При развертывании инфраструктуры открытого ключа помните о необходимости выделить рабочие станции для инициализации смарт-карт и персонал для записи маркеров на карты. Безопасность применения смарт-карт будет зависеть от безопасности процесса управления смарт-картами. Если помощник администратора, Салли, звонит вам по телефону и просит передать смарт-карту для ее начальника, контроль над процессом можно считать недостаточным.
Кроме этого, помните о потенциальной возможности последующего отзыва сертификата смарт-карты пользователя с отключением регистрационной учетной записи. Очень важно проверить надежность распространения списка отозванных сертификатов (Certificate Revocation List — CRL) в данной реализации PKI перед началом применения смарт-карт.
Кроме этого, потребуется получение сертификатов компьютеров (Computer) для всех серверов удаленного доступа, которые под держивают регистрацию с помощью смарт-карт. Сертификат используется для цифровой подписи ответов на аутентификацию, чтобы клиент мог проверить личность сервера..'
После выбора производителя, установки аппаратных средств для считывания, создания инфраструктуры открытого ключа и применения безопасных процессов создания списков пользователей можно начинать применение смарт-карт. Ниже перечислены основные этапы процесса.
Настройте станции для записи пользователей
Подготовьте шаблоны сертификатов в центре сертификации и в базе данных Active Directory ■ Выберите агенты подачи заявок (enrollment agent), которые будут выдавать смарт-карты
Подготовьте карты с помощью предоставленной производителем утилиты
Выдайте сертификаты для смарт-карт в .ответ на заявку пользователя и протестируйте результат
Настройте серверы удаленного доступа на поддержку аутентификации по смарт-картам и подайте заявки на получение сертификатов Computer для серверов
Протестируйте аутентификацию по смарт-картам на клиентах различных типов
Настройка смарт-карт
Начните с выбора определенной рабочей станции в качестве станции подачи заявок смарт-карт (enrollment station). Это должна быть безопасная рабочая станция с устройством считывания смарт-карт, установленным вместе с утилитой настройки смарт-карт от производителя. Утилита необходима, чтобы задавать пользовательские и административные номера PIN на смарт-карте и разблокировать карту, если пользователь превысит максимальное количество попыток ввода номера PIN (обычно предоставляется три попытки).
Станция подачи заявок смарт-карт должна работать под управлением операционной системы Windows ХР или Windows 2000 в зависимости от производителя. Если используется инфраструктура открытого ключа Windows Server 2003, для связи с центром сертификации через Web потребуется установка браузера Internet Explorer 5 или более поздней версии.
Подготовка шаблонов сертификатов
Шаблоны, использующиеся для регистрации по смарт-картам, не устанавливаются по умолчанию вместе с центром сертификации под управлением Windows Server 2003. Точно так же устанавливаются шаблоны для сертификатов Enrollment, которые потребуются администраторам, ответственным за добавление пользователей. Эти шаблоны необходимо установить вручную с помощью консоли Certification Authority (Центр сертификации), как описано в процедуре 20.4. На рис. 20.14 показан список принятых по умолчанию шаблонов на консоли Certification Authority (Центр сертификации).
?——г»--т-гт '"x77 "."p^T^I
Не* 'SIlPSECDirectory Erne! ReflationDomain Cortroler AuthenticationEFS Recovery AgentBasic EPSDoman CortrolerWeb ServerComputerUserSubordhate Certification Authority lyAdrrmktratorНе* 'SIlPSECDirectory Erne! ReflationDomain Cortroler AuthenticationEFS Recovery AgentBasic EPSDoman CortrolerWeb ServerComputerUserSubordhate Certification Authority lyAdrrmktratori'Wewww" ’ f ' -~
Не* '
SIlPSEC
Directory Erne! Reflation
Domain Cortroler Authentication
EFS Recovery Agent
Basic EPS
Doman Cortroler
Web Server
Computer
User
Subordhate Certification Authority lyAdrrmktrator
Не* '
SIlPSEC
Directory Erne! Reflation
Domain Cortroler Authentication
EFS Recovery Agent
Basic EPS
Doman Cortroler
Web Server
Computer
User
Subordhate Certification Authority lyAdrrmktrator
IP security IKE Intermdate Directory Service Emal Repkation'
Gent Authentication, Server Authenticatio...t
Fie Recovery;
Encrypting Fie System:
Gent Authentication, Server Authentication;
Server Authentication'
Gent Authentication, Server Authentication-
Encrypting Fie System, Secure Emal, Gen...-
<A1>
Mcrosoft Trust List Signing, Encrypting Fie...;
Puc. 20.14. На консоли Certification Authority (Центр сертификации) отображается принятый по умолчанию список шаблонов сертификатов
Процедура 20.4. Включение шаблона пользователя смарт-карты
uHMI . -(^Exchange Signature Or* Sjj Exchange User (yiPSEC iyiPSEC (Offline request) iy Key Recovery Aoent Я Router (Offline request) У Smartcard LogonuHMI . -(^Exchange Signature Or* Sjj Exchange User (yiPSEC iyiPSEC (Offline request) iy Key Recovery Aoent Я Router (Offline request) У Smartcard Logon@Tfust List Siywig (jj User Signakie Or*@Tfust List Siywig (jj User Signakie Or*ZZZZ3 iZZZZ3 iу^^УШ^Yji^j^j^^^^ijjjmtUi ChlWeiflM* Aulwtl*
uHMI . -
(^Exchange Signature Or* Sjj Exchange User (yiPSEC iyiPSEC (Offline request) iy Key Recovery Aoent Я Router (Offline request) У Smartcard Logon
uHMI . -
(^Exchange Signature Or* Sjj Exchange User (yiPSEC iyiPSEC (Offline request) iy Key Recovery Aoent Я Router (Offline request) У Smartcard Logon
@Tfust List Siywig (jj User Signakie Or*
@Tfust List Siywig (jj User Signakie Or*
ZZZZ3 i
ZZZZ3 i
Secure Emai
Secure Emai
IP security IKE intermediate
IP security IKE intermediate
Key Recovery AgentCliert Authentication
Cfient Authentication, Smart Card Logon
Microsoft Trust List Siywig Secure Email, Cfient Authentication
Рис.20.15. Окно Enable Certificate Templates (Включение шаблонов сертификатов), в котором показан список еще не включенных шаблонов
Проделайте такую же процедуру для шаблона Enrollment Agent (Агент подачи заявок).
Убедитесь в наличии шаблонов в главном окне консоли.
Закройте консоль.
На этом этапе шаблоны сертификатов готовы к использованию при подаче заявок. Копии шаблонов хранятся в базе данных Active Directory, где они доступны для всех центров сертификации предприятия. (Изолированные центры сертификации не используют шаблоны.)
Следующим этапом является выдача сертификатов Enrollment Agent (Агент подачи заявок) тем администраторам, которые будут работать на станциях подачи заявок смарт-карт.
Выдача сертификатов агентов подачи заявок
Центр сертификации под управлением Windows Server 2003 не будет выдавать сертификаты Smart Card User (Сертификат пользователя со смарт-картой) или Smart Card Logon (Сертификат входа со смарт-картой), если запрашивающий администратор не имеет сертификата Enrollment Agent (Агент подачи заявок), который будет использоваться для создания цифровой подписи запроса. Выданный администратору сертификат агента подачи заявок должен физически присутствовать на станции подачи заявок смарт-карт.
Самым простым способом получения сертификата агента подачи заявок является запрос этого сертификата с помощью оснастки Certificates (Сертификаты) при регистрации на консоли станции подачи заявок смарт-карт. С другой стороны, можно получить сертификат на рабочей станции администратора и скопировать сертификат на станцию подачи заявок смарт- карт (enrollment station).
Для обеспечения безопасности центр сертификации не будет выдавать сертификаты Enrollment Agent (Агент подачи заявок) без разрешений на доступ к соответствующему шаблону в базе данных Active Directory. По умолчанию доступ к этому шаблону получают только группы Domain Admins (Администраторы домена) и Enterprise Admins (Администраторы предприятия). Для того чтобы не предоставлять администраторам подачи заявок для пользователей смарт-карт таких широких полномочий, создайте новую группу Enrollment Agents (Агенты регистрации) и добавьте ее в список контроля доступа для сертификата Enrollment Agents (Агенты подачи заявок), указав права Read (Чтение) и Enroll (Подача заявки). Последовательность действий рассматривается в процедуре 20.5.
Процедура 20.5. Предоставление сертификатов Enrollment Agent (Агент подачи заявок) для администраторов.
Зарегистрируйтесь на консоли станции записи от имени учетной записи, входящей в группу Domain Admins (Администраторы домена) или группу Enterprise Admins (Администраторы предприятия).■
Воспользуйтесь консолью Active Directory — Users and Computers (Active Directory — пользователи и компьютеры) для создания новой группы, которая называется Enrollment Agents (группу можно назвать любым именем).
Сделайте одного из администраторов, ответственных за выдачу смарт-карт, членом этой группы.
Откройте консоль Active Directory — Sites and Services (Active Directory — сайты и службы).
Воспользуйтесь командой View^Show Services Node (Вид^Показать узел' служб) для отображения содержимого контейнера Services. (Если этот пункт отсутствует в меню View (Вид), выделите самую верхнюющиктограмму дерева и попробуйте еще раз.)
Разверните дерево до раздела Services1^ Public Key Services^Certificate Templates (Службы ^Службы открытого ключам Шаблоны сертификатов) и найдите пиктограмму Enrollment Agent (Агент подачи заявок) на правой панели (рис. 20.16).
*5*-.*5*-.,-1941,-1941
*5*-.
*5*-.
,-1941
,-1941
: * <ЬТи L^S’OlS.".
S-JO Services ® 8$ MsmqServicesS-JO Services ® 8$ MsmqServices[EFSRecovery[EFSRecovery1т>*"Certificate Tem.,.1т>*"Certificate Tem.,.J.0M8W».J.0M8W».(3S(3SCl NetServices□ Pubfc Key Services® □ AIAffi OCDPCl NetServices□ Pubfc Key Services® □ AIAffi OCDPВ-РЭ Certification Authorities В Pj Enrolment Services ® 13 KRA ® □ ОЮВ-РЭ Certification Authorities В Pj Enrolment Services ® 13 KRA ® □ ОЮГ'Э WndowsNTГ'Э WndowsNT|EnrolmentAgentOffine |ExchangeU$er |ExchangeUserSignature jlPSECIntermediateOfflne llPSEOntermediateOnlhe |KeyRecovery Agent | Machine |MachineEnrolmentAgent joffineRouter I Smart car dLogon I Smartcarduser|EnrolmentAgentOffine |ExchangeU$er |ExchangeUserSignature jlPSECIntermediateOfflne llPSEOntermediateOnlhe |KeyRecovery Agent | Machine |MachineEnrolmentAgent joffineRouter I Smart car dLogon I SmartcarduserCertificate Tem.,. Certificate Tem.,. Certificate Tem.,. Certificate Tem.,. Certificate Tem.,, Certificate Jem.,. Certificate Tem... Certificate Tem.,, Certificate Tem... Certificate Tem.,. Certtficate Tem.,. rxHUficNie TiemCertificate Tem.,. Certificate Tem.,. Certificate Tem.,. Certificate Tem.,. Certificate Tem.,, Certificate Jem.,. Certificate Tem... Certificate Tem.,, Certificate Tem... Certificate Tem.,. Certtficate Tem.,. rxHUficNie Tiem
S-JO Services ® 8$ MsmqServices
S-JO Services ® 8$ MsmqServices
[EFSRecovery
[EFSRecovery
1т>*"
Certificate Tem.,.
1т>*"
Certificate Tem.,.
J.0M8W».
J.0M8W».
(3
S
(3
S
Cl NetServices
□ Pubfc Key Services
® □ AIA
ffi OCDP
Cl NetServices
□ Pubfc Key Services
® □ AIA
ffi OCDP
В-РЭ Certification Authorities В Pj Enrolment Services ® 13 KRA ® □ ОЮ
В-РЭ Certification Authorities В Pj Enrolment Services ® 13 KRA ® □ ОЮ
Г'Э WndowsNT
Г'Э WndowsNT
|EnrolmentAgentOffine |ExchangeU$er |ExchangeUserSignature jlPSECIntermediateOfflne llPSEOntermediateOnlhe |KeyRecovery Agent | Machine |MachineEnrolmentAgent joffineRouter I Smart car dLogon I Smartcarduser
|EnrolmentAgentOffine |ExchangeU$er |ExchangeUserSignature jlPSECIntermediateOfflne llPSEOntermediateOnlhe |KeyRecovery Agent | Machine |MachineEnrolmentAgent joffineRouter I Smart car dLogon I Smartcarduser
Certificate Tem.,. Certificate Tem.,. Certificate Tem.,. Certificate Tem.,. Certificate Tem.,, Certificate Jem.,. Certificate Tem... Certificate Tem.,, Certificate Tem... Certificate Tem.,. Certtficate Tem.,. rxHUficNie Tiem
Certificate Tem.,. Certificate Tem.,. Certificate Tem.,. Certificate Tem.,. Certificate Tem.,, Certificate Jem.,. Certificate Tem... Certificate Tem.,, Certificate Tem... Certificate Tem.,. Certtficate Tem.,. rxHUficNie Tiem
Puc. 20.16. На консоли Active Directory — Sites and Services (Active Directory — сайты и службы) показан контейнер Certificate Templates (Шаблоны сертификатов), содержащий сертификат Enrol Imen t Agen t (Агент подачи заявок)
Откройте окно Properties (Свойства) шаблона Enrollment Agent (Агент подачи заявок) и активизируйте вкладку Security (Безопасность).
Добавьте группу Enrollment Agents в список контроля доступа и предоставьте группе права Read (Чтение) и Enroll (Подача заявок).
Закройте консоль.
Откройте пустую консоль. Для этого введите команду ММС в окне Run (Выполнить).
Воспользуйтесь командой File^Add/Remove Snap-in (Файл^Добавить/Удалить оснастку).
Щелкните на кнопке Add (Добавить). Откроется окно Add Standalone Snap-In (Добавить изолированную оснастку).
Выберите Certificates (Сертификаты) из списка и щелкните на кнопке ОК. Откроется окно оснастки Certificates (Сертификаты).
Выберите Му User Account (Моя учетная запись) и щелкните на кнопке Finish (Готово).
Щелкните на кнопке Close (Закрыть), чтобы закрыть окно Add Standalone Snap-In (Добавить изолированную оснастку).
Щелкните на кнопке ОК, чтобы закрыть окно Add/Remote Snap-in (Добавить/Удалить оснастку). В основном окне будет показано дерево Certificates (Сертификаты) для текущего пользователя.
Разверните дерево до раздела Personal^Certificates (Личные1^ Сертификаты).
Щелкните правой кнопкой мыши на пиктограмме Certificates (Сертификаты) и выберите из контекстного меню команду All Tasks^Request New Certificate (Все задачи1^ Запросить новый сертификат). Запустится мастер запроса сертификата. Если мастер не запустится, значит, у пользователя недостаточно привилегий для выбора любого сертификата (маловероятно) или рабочая станция не входит в домен либо не в состоянии связаться с контроллером домена для получения списка шаблонов сертификатов.
Щелкните на кнопке Next (Далее). Откроется окно Certificate Types (Типы сертификатов), которое показано на рис. 20.17.
OatWceteTrfw A«r№c*6tyr*cort*«{xwtpropwtlKlcreert6t*»r.'
S«l»6t a cWfc*» tree for va* ««*■*, Wuia»iw»«r*o«itfc«l»lweelh*. you hero йпчиипо for and th* я» waMb tie» a 1м#Ы CA
CwUtaeetnwt.
Athyntstralor Basic EFS i‘.
- Smartcard User, ,
User
To <ei*t a ayototravNc oonta раМгеИ а СЦ, oa№ Mvanrad. :|1||||5|$|||||||||||||||||^
'<8o* ( Me*> | ' gahd* ,
Puc. 20.17. В окне Certificate Types (Типы сертификатов) отображается список шаблонов сертификатов, для которых у пользователя есть разрешение Enroll (Подать заявку)
Выделите Enrollment Agent (Агент подачи заявок) и щелкните на кнопке Next (Далее). Откроется окно Certificate Friendly Name and Description (Имя и описание сертификата). Оставьте поля пустыми.
Щелкните на кнопке Next (Далее). Откроется окно с итоговой сводкой. Щелкните на кнопке Finish (Готово) для сохранения изменений и получения сертификата. Будет выдано сообщение об успешной выдаче сертификата.
Теперь администратор с сертификатом Enrollment Agent (Агент подачи заявок) может создавать смарт-карты для пользователей на станции подачи заявок смарт-карт.
Запись пользователей смарт-карт
Процесс подачи заявки (enrollment) состоит из получения сертификата для открытого ключа, сгенерированного в качестве элемента пары “открытый/секретный ключ” механизмом смарт-карты. Для этого используется Web-интерфейс, а не оснастка Certificates (Сертификаты), так как Web-интерфейс предоставляет доступ к элементу управления ActiveX, поддерживающему безопасное копирование сертификата в память смарт-карты.
Для выполнения этой процедуры необходима совместимая с устройством считывания смарт- карта. Новый номер PIN карте можно назначить немедленно (для этого используется предоставленная производителем утилита) или в процессе подачи заявки. Для всех производителей, кроме Gemplus и Schlumberger, на станции подачи заявок смарт-карт и на всех рабочих станциях придется установить поставщик служб криптографии (CSP) от производителя. Может потребоваться установка дополнительных компонентов на станции записи и в базе данных Active Directory.
Сертификаты смарт-карт можно выдавать только пользователям в пределах того же леса, в котором расположен центр сертификации. Это позволяет контроллерам домена в пределах леса проверять сертификат во время регистрации. При выполнении всех предварительных условий можно начинать. Чтобы подать заявку для пользователя, выполните последовательность действий, описанную в процедуре 20.6.
Процедура 20.6. Подача заявки пользователя смарт-карты
На станции подачи заявок смарт-карт запустите Web-браузер и введите полностью квалифицированное имя центра сертификации с указанием /certs rv в конце адреса, например serveri. company. com/certsrv. Откроется страница Welcome, показанная на рис. 20.18.
Welcome
Use this Web site to request a certificate for your Web browser, e-mail client, or other program. By using a certificate, you can verify your identity to people you communicate with over the Web, sign and encrypt messages, and, depending upon the type of certificate you request, perform other security tasks.
You can also use this Web site to download a certificate authority (CA) certificate, certificate chain, or certificate revocation list (CRL), or to view the status of a pending request.
For more information about Certificate Services, see Certificate Services Documentation.'
Select a talk:
Request a certificate
View the status of a pending certificate request
Download a CA certificate, certificate chain, or CRL
"Г"1 TSHw" ' ^
Puc. 20.18. Страница Welcome на сайте центра сертификации, работающего под управлением Windows Server 2003
Щелкните на ссылке Request a certificate (Запросить сертификат). Откроется страница Request a Certificate (Запросить сертификат).
Щелкните на ссылке Advanced Certificate Request (Расширенный запрос сертификата). Откроется страница Advanced Certificate Request (Расширенный запрос сертификата), которая показана на рис. 20.19.
Advanced Certificate Request
The policy of the CA determines the types Of certificates you can request. Click one of the following options to:
Create and submit a request to this CA.
Submit a certificate request by using a base-M-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file
Request a certificate for a smart card on behalf of another user by using the smart card certificate enrollment station.
Note: You must have an enrollment agent certificate to submit a request on behalf of another
user.
Puc. 20.19. Службы сертификации. Страница Advanced Certificate Request (Расширенныйзапрос сертификата)
Щелкните на пункте, который начинается с Request a certificate for a smart card... (Запросить сертификат для смарт-карты...). Откроется страница Smart Card Certificate Enrollment Station (Станция подачи заявок для сертификатов смарт-карт), которая показана на рис. 20.20.
Если поле возле метки Administrator Signing Certificate (Подписавший сертификат администратор) не содержит данных, сертификат Enrollment Agent (Агент подачи заявки) не был получен или не был скопирован на локальный компьютер.
Щелкните на ссылке Certificate Templates (Шаблоны сертификатов) и выберите Smartcard User (Пользователь со смарт-картой). В этот тип сертификатов входит вариант Smart Card Logon (Вход со смарт-картой), поэтому для регистрации не требуется выпуск отдельного сертификата.
Если в поле Certificate Authority (Центр сертификации) не указан центр сертификации, значит, соответствующий шаблон не был включен на консоли Certification Authority (Центр сертификации).
Щелкните на ссылке Cryptographic Service Provider (Поставщик служб криптографии) и выберите имя производителя смарт-карт.
Если имя производителя не указано в списке, следовательно, на станции подачи заявок смарт-карт не установлен поставщик служб криптографии от производителя.
Smart Card Certificate Enrollment StationSmart Card Certificate Enrollment Station
Smart Card Certificate Enrollment Station
Smart Card Certificate Enrollment Station
Enrollment Options:I
Certificate Template: (Smartcard UserMj
Authority: i-
Cryptographic
Service Provider. AdministratorI
Signing Certificate:J
Peer To Enroll: (eagent@i:ompany.comSNectUser, j j
Status:'
An unexpected error occurred. Error The user smart card you inserted does not | match the selected cryptographic service provider (CSP) Please insert a different «i smart card or selectthe appropriate CSP.
RUrrl NewUeer | *j
Puc. 20.20. Certificate Services (Службы сертификатов). Страница Smart Card Certificate Enrollment Station (Станция подачи заявок для сертификатов смарт-карт)
Щелкните на кнопке Select User (Выбрать пользователя) и найдите имя пользователя в окне поиска Active Directory. Пользователь должен иметь доменные регистрационные данные. Для тестирования лучше записать себя, чтобы немедленно проверить результат.
Вставьте смарт-карту в устройство чтения и щелкните на кнопке Enroll (Подать заявку).
Если все сделано правильно, поставщик служб криптографии получит управление и выведет окно для ввода номера PIN, заданного для смарт-карты. На рис. 20.21 показан пример для поставщика служб криптографии от компании Schlumberger.
Рис. 2021. Окно Confirm Smart Card PIN (Подтвердите номер PIN смарт-карты)
Принятый по умолчанию номер PIN для карты Schlumberger — 00000000 (8 нулей). Принятый по умолчанию номер PIN для карты Gemplus — 1234. Никогда не оставляйте принятый по умолчанию номер PIN.
После сохранения сертификата на карте на странице Enrollment Station (Станция подачи заявок смарт-карт) будет показано сообщение об обновлении состояния. Щелкните на
ссылке View Certificates (Показать сертификаты), чтобы убедиться, что сертификат выдан выбранному пользователю (рис. 20.22). Это очень важно. Нельзя допустить случайной подачи заявки для одного пользователя и выдачи смарт-карты другому пользователю.
Рис. 20.22. Содержимое сертификата для выданной смарт-карты пользователя
На этом процесс подачи заявки завершается. После этого необходимо проверить способность смарт-карты предоставлять доступ.
Тестирование сертификата
Любой компьютер под управлением Windows Server 2003 или Windows ХР будет принимать запросы на регистрацию по смарт-картам, если установлено соответствующее устройство считывания. После обнаружения устройства считывания операционной системой в окне Winlogon выводится пиктограмма устройства и пользователю предлагается ввести пароль или вставить смарт-карту.
При установке смарт-карты в устройство считывания выдается запрос на ввод номера PIN. Введите номер PIN, который был задан в процессе подачи заявки. Единственной причиной неудачной регистрации является отсутствие пользователя в базе данных Active Directory или недоступность контроллера домена и сервера глобального каталога. (Как и при стандартной регистрации, глобальный каталог используется для получения информации о членстве пользователя в универсальных группах и для разбиения основного имени пользователя на компоненты “имя/домен”.)
Кроме этого, стоит провести как минимум один тест обработки отзыва сертификатов. Для этого воспользуйтесь консолью Certification Authority (Центр сертификации) и отзовите смарт-карту, выданную тестовому пользователю. Опубликуйте отличие между списками отозванных сертификатов и убедитесь, что пользователь не может зарегистрироваться с помощью смарт-карты. Пользователь должен получить сообщение о том, что смарт-карта была отозвана. Дополнительная информация о публикации списков отозванных сертификатов приводится в главе 18, “Управление инфраструктурой открытого ключа”.
Теперь, когда инфраструктура смарт-карт создана, можно начинать настройку сервера удаленного доступа на использование аутентификации по смарт-картам.
Настройка службы RRAS на использование ■ смарт-карт
Любой сервер удаленного доступа под управлением Windows Server 2003 или Windows 2000 поддерживает регистрацию с использованием смарт-карт. Для этого нужно настроить службу маршрутизации и удаленного доступа (Routing and Remote Access Service — RRAS) на использование протокола ЕАР и выбрать регистрацию по смарт-карте в качестве метода протокола ЕАР.,
Необходимость настройки политик удаленного доступа в режиме Native немного усложняет процесс. Не забывайте это делать, так как в противном случае RRAS-сервер откажет в подключении, даже если кажется, что все сделано правильно. В процедуре 20.7 рассматривается последовательность действий по подготовке сервера к регистрации по смарт-картам.
Процедура 20.7. Подготовка сервера удаленного доступа к регистрации по смарт-картам
Откройте консоль RRAS.
Откройте для сервера окно Properties (Свойства).
Активизируйте вкладку Security (Безопасность).
Выберите Windows Authentication (Аутентификация Windows) и щелкните на кнопке Authentication Methods (Методы аутентификации).
Выберите Extensible Authentication Protocol (ЕАР) и щелкните на кнопке ЕАР Methods (Методы ЕАР).
Выполните двойной щелчок в списке на пункте Smart Card or Other Certificate (Смарт- карта или другой сертификат) и щелкните на кнопке ОК.
Сбросьте остальные флажки и щелкните на кнопке ОК, чтобы вернуться в окно Properties (Свойства).
Щелкните на кнопке ОК, чтобы сохранить изменения, закрыть окно и вернуться на консоль RRAS.
Перейдите по дереву к разделу Remote Access Policies (Политики удаленного доступа). Можно создать новую политику для регистрации по смарт-картам или модифицировать существующую политику. В данном случае будет модифицирована существующая политика.
Выполните двойной щелчок на пиктограмме Allow Access If Dial-In Permission Is Enabled (Разрешить доступ, если разрешен коммутируемый доступ). Откроется окно Properties (Свойства).
И. Щелкните на кнопке Edit Profile (Изменить профиль).
Активизируйте вкладку Authentication (Аутентификация), которая показана на рис. 20.23.
Щелкните на кнопке ЕАР Methods (Методы ЕАР). Откроется окно Select ЕАР Providers (Выбор поставщиков ЕАР).
Щелкните на кнопке Add (Добавить). Откроется окно Add ЕАР (Добавление ЕАР).
Выберите переключатель Smart Card or Other Certificate (Смарт-карта или другой сертификат) и щелкните на кнопке ОК, чтобы вернуться в окно Select ЕАР Providers (Выбор поставщиков ЕАР).
Щелкните на кнопке Edit (Изменить). Откроется окно Smart Card or other Certificate Properties (Свойства смарт-карты или другого сертификата).
В поле Certificate Issued То (Сертификат выдан) выберите сертификат компьютера, выданный серверу (рис. 20.24).
Рис. 2023. Окно Edit Dial-In Profile (Изменение профиля коммутируемого доступа). Вкладка Authentication (Аутентификация). Сняты флажки для всех параметров, кроме ЕАРРис. 2023. Окно Edit Dial-In Profile (Изменение профиля коммутируемого доступа). Вкладка Authentication (Аутентификация). Сняты флажки для всех параметров, кроме ЕАРРис. 2024. Окно Smart Card or other Certificate Properties (Свойства смарт-карты или другого сертификата). Выбор сертификата компьютера, выданного RRAS-cepeepyРис. 2024. Окно Smart Card or other Certificate Properties (Свойства смарт-карты или другого сертификата). Выбор сертификата компьютера, выданного RRAS-cepeepy
Рис. 2023. Окно Edit Dial-In Profile (Изменение профиля коммутируемого доступа). Вкладка Authentication (Аутентификация). Сняты флажки для всех параметров, кроме ЕАР
Рис. 2023. Окно Edit Dial-In Profile (Изменение профиля коммутируемого доступа). Вкладка Authentication (Аутентификация). Сняты флажки для всех параметров, кроме ЕАР
Рис. 2024. Окно Smart Card or other Certificate Properties (Свойства смарт-карты или другого сертификата). Выбор сертификата компьютера, выданного RRAS-cepeepy
Рис. 2024. Окно Smart Card or other Certificate Properties (Свойства смарт-карты или другого сертификата). Выбор сертификата компьютера, выданного RRAS-cepeepy
Щелкните на кнопке ОК и еще раз щелкните на кнопке ОК, чтобы закрыть все окна и вернуться на главную консоль RRAS.
Теперь сервер удаленного доступа готов для аутентификации с помощью смарт-карт. Проверьте правильность аутентификации.
Тестирование удаленной регистрации с помощью смарт-карты
Настройте клиент, подключающийся по линии коммутируемого доступа, на использование аутентификации с помощью смарт-карты. Точная процедура зависит от платформы. На рис. 20.25 показаны параметры конфигурации для клиента Windows ХР.
После настройки клиента на регистрацию по смарт-карте выполните двойной щелчок на пиктограмме коммутируемого подключения и вставьте смарт-карту в устройство считывания. (Кроме этого, можно дождаться запроса на установку смарт-карты.) В открывшемся окне будет предоставлено поле для ввода номера PIN. После ввода номера PIN система установит коммутируемое подключение.
Если поставщик служб криптографии (CSP) отказывается читать содержимое смарт- карты из-за ввода неправильного номера PIN, воспользуйтесь представленной производителем утилитой для сброса номера PIN. В транзакции аутентификации на удаленном сервере номер PIN не используется.
Рис. 2025. Свойства коммутируемого подключения в операционной системе Windows ХР. Параметры смарт-карты на вкладке Security (Безопасность)
Если система принимает номер PIN и читает содержимое смарт-карты, но выдается сообщение Access Denied — Unknown User or Password, (Доступ запрещен — Неправильное имя пользователя или пароль), убедитесь, что смарт-карту можно использовать для регистрации в домене с консоли компьютера, уже подключенного к сети. Если в таком случае смарт- карта работает, проблема может заключаться в неспособности сервера удаленного доступа распознать основное имя пользователя. Сервер должен иметь доступ к контроллеру домена и глобальному каталогу.
По завершении успешного теста можно начинать промышленное развертывание. Для этого необходимы только время и соответствующий бюджет.
Установка и настройка модемов
Подсистема Plug-and-Play значительно упрощает установку модемов. В идеальном случае можно установить новый модем, вставив его в разъем PCI, загрузив компьютер и получив сообщение в области уведомлений о работе подсистемы Plug-and-Play. На портативных компьютерах установка модемов PC Card поддерживается во время работы компьютера. Диспетчер Plug-and-Play обнаружит модем и установит драйверы. Установка модемов USB является настолько же простой.
Установить модемы старых моделей немного сложнее. Диспетчер РпР использует драйвер Serenum.sys для создания списка устройств, подключающихся через последовательный порт. Этот драйвер находит все устаревшие модемы и модемы Plug-and-Play, подключенные к портам RS232 и к шине PCI. В модели драйверов Windows драйвер Serenum рассматривается одновременно как драйвер шины, так как он отображает список компонентов шины, и как драйвер фильтрации, поскольку он создает виртуальное устройство, соответствующее модему. Подробная информация о модели драйверов Windows приводится в главе 3, “Добавление аппаратных средств".
При обнаружении модема драйвером Serenum драйвер вызывает установщик класса модема для поиска подходящего драйвера. Установщик класса запрашивает у модема название производителя и номер модели, после чего выполняет поиск соответствующего файла . inf в каталоге \Windows \ INF. В составе операционной системы Windows Server 2003 предоставляется Около 350 сценариев . inf, предназначенных для модемов. В каждом сценарии содержатся инструкции по настройке нескольких модемов, поэтому модемы без драйверов крайне редки. Вместе с каждым сценарием .inf предоставляется файл .pnf, который является предварительно откомпилированной версией сценария INF, которая быстрее считывается установщиком класса РпР.
Если установщик класса не в состоянии найти файл .inf для модема, но модем отвечает на стандартные команды из набора Hayes, установщик использует универсальный сценарий . inf, который называется Mdmgen. inf и обеспечивает базовые функциональные возможности. Некоторые возможности модема могут оказаться недоступными рри использовании стандартных параметров. Кроме этого, модем может отказаться нормально работать из-за неправильного форматирования строки инициализации.
Если используется внешний модем РпР и перезагрузка компьютера для его установки нежелательна, откройте консоль Device Manager (Диспетчер устройств) (файл Devmgmt .msc), щелкните правой кнопкой мыши на пиктограмме компьютера в вершине дерева и выберите из контекстного меню команду Scan For Hardware Changes (Обновить конфигурацию оборудования). Световые индикаторы модема должны моргнуть, и модем появится в списке устройств.
Если модем не поддерживает технологию Plug-and-Play, его придется устанавливать вручную. В Control Panel (Панель управления) воспользуйтесь аплетом Phone and Modem Options (Телефон и модем) и запустите мастер установки оборудования. При “зависании” установки помните, что установка выполняется средствами Rundll32 совместно с установщиком класса модема, Mdminst. dll. Завершите процесс в Task Manager (Диспетчер задач) и повторите установку.
Тестирование и диагностика модемных подключений
Если модем неправильно работает после установки, проверьте свойства устройств в окне Device Manager (Диспетчер устройств) и убедитесь, что не возник конфликт устройств и установлен правильный драйвер. Один из способов запуска консоли Device Manager (Диспетчер устройств) заключается в том, чтобы щелкнуть правой кнопкой мыши на пиктограмме Му Computer (Мой компьютер) и выбрать из контекстного меню команду Properties (Свойства). После этого перейдите на вкладку Hardware (Оборудование) и щелкните на кнопке Device Manager (Диспетчер устройств).
На рис. 20.26 показан пример дерева устройств, в котором проблемный модем обозначен пиктограммой с изображением знака вопроса. Такая пиктограмма появляется при конфликте устройств или при невозможности найти драйвер устройства.
Обычно, если система не в состоянии обнаружить сценарий .inf для драйвера модема, автоматически запускается мастер обнаружения нового оборудования (Found New Hardware Wizard), который помогает найти и установить драйвер производителя. Если производитель не предоставляет драйверы для конкретной модели модема, попытайтесь воспользоваться драйвером похожего модема, предоставляющего сопоставимый набор возможностей и скорость. Кроме этого, можно воспользоваться драйвером стандартного модема сопоставимой скорости (рис. 20.27).
Если установлен правильный драйвер, на консоли Device Manager (Диспетчер устройств) в окне модема выберите вкладку Resources (Ресурсы). Для модемов Plug-and-Play все параметры ресурсов неактивны. Если можно выбрать конкретный параметр ресурса, система распознала модем как устаревший. Если модем на самом деле является устройством Plug-and-Play, может потребоваться переключение перемычки или изменение программной конфигурации.
ф <й Disk drives $ Ш Display adapters ф Д DVD/CD-ROM drives
$ "^4 floppy dbk controiers $-5 АоРРУ d* *tves a ^ IDE ATA/ATAPI controiers E^» Keyboards
E& ^ Mke and other pointing devices 6-8 Morttors
Рис.2026. Консоль Device Manager (Диспетчер устройств). В дереве устройств отображается неправильно работающей модем
Рис. 20.27. Мастер обнаружения нового оборудования. Окно Install New Modem (Установка нового модема). Выбор стандартного модема для производителя (модели), который не поддерживается средствами РпР
После этого обратите внимание на содержимое поля Conflicts (Конфликты). В этом поле сообщается о неспособности системы распределить линии запроса прерываний таким образом, чтобы модем работал, не вступая в конфликт с другими устройствами. Внешние модемы редко становятся причиной конфликтов при распределении ресурсов, но внутренние модемы иногда конфликтуют с другими устройствами, подключающимися через последовательный порт.
Ниже приведен список других действий, которые стоит предпринять, если модем был установлен правильно, но отказывается работать.
Сохраните несколько часов рабочего времени и проверьте содержимое списка совместимого оборудования по адресу www.microsoft.com/hcl. Если модем не указан в этом списке, проверьте существование обновленных драйверов для Windows Server 2003, Windows ХР или Windows 2000 от производителя. Если таких драйверов не существует, рассмотрите возможность приобретения нового модема. Жизнь коротка, а модемы стоят не так дорого.
Проверьте параметры BIOS и убедитесь, что последовательный порт включен.
' Если внутренний модем подключается к шине ISA, удостоверьтесь, что разъем ISA настроен на распознавание устройств Plug-and-Play. Некоторые внутренние модемы обладают двойной “личностью”: одна — для шины ISA, другая — для подсистемы РпР.
Иногда ошибки в работе можно исправить с помощью модификации строки инициализации модема. Обратитесь к базе знаний производителя и внесите рекомендованные изменения в строку инициализации. Активизируйте вкладку Advanced (Дополнительно) и добавьте соответствующие изменения в поле Extra Initialization Commands (Дополнительные команды инициализации). Введенные здесь параметры переопределяют соответствующие команды из сценария . inf.
При использовании внешнего модема убедитесь во включении соответствующего последовательного порта. Кроме этого, убедитесь, что последовательной порт использует стандартные адреса портов ввода-вывода и линию запроса прерываний. Старые портативные
компьютеры известны своей нестандартной конфигурацией. В табл. 20.1 показаны стандартные параметры последовательных портов.
Таблица 20.1. Стандартные значения адресов портов ввода-вывода и линий запроса прерывания
Последовательный порт
Адрес порта ввода-вывода
Линия запроса прерывания
СОМ1
3F8
4
COM2
2F8
3
COM3
ЗЕ8
4
COM4
2Е8
3
Для проверки работоспособности последовательного порта, к которому подключается внешний модем, можно открыть приглашение командной строки и ввести команду atdt > com# :. При этом на модеме должны моргнуть индикаторы. Если этого не произошло, кабель может иметь другую схему контактов. Правильная схема описывается в табл. 20.2.
Таблица 20.2. Назначение контактов последовательного кабеля
для подключения модема
Соединительный 25-контактный кабель с прямой схемой расположения выводов
Штекер (male)
Разъем (female)
Назначение
1
1
Заземление на корпус
2
2
Передача данных
3
3
Прием данных
4
4
Запрос на отправку
5
5
Разрешение на отправку
6
6
Набор данных готов
7
7
Сигнальная земля
8
8
Обнаружение несущей
20
20
Терминал данных готов
Соединительный кабель с переходом 25-контактного штекера на 9-контактный разъем
Штекер (male)
Разъем (female)
Назначение
8
1
Обнаружение несущей
3
2
Прием данных
2
3
Передача данных
20
4
Терминал данных готов
7
5
Сигнальная земля
6
6
Набор данных готов
4
7
Запрос на отправку
5
8
Разрешение на отправку
22
9
Индикатор звонка (не обязателен)
Если используется модем PC Card, убедитесь, что для модема не требуются устаревшие драйверы адаптера И сокетов. Эти драйверы не предоставляются в составе операционной системы Windows Server 2003. Обеспечивается правильная работа только тех адаптеров PC Card, которые соответствуют спецификациям АРМ и ACPI.
Обратитесь к базе данных Microsoft Knowledge Base. Возможно, в ней содержится информация о решении проблем, связанных с данной моделью модема.
Программные модемы используют для своей работы долю производительности центрального процессора компьютера. Эти модемы могут оказаться сложными в настройке и требовать особого внимания из-за потребляемых ими ресурсов. Программные модемы никогда не должны использоваться на серверах удаленного доступа.
Некоторые модемы предоставляются в составе многофункционального адаптера, например комбинированного адаптера PC Card, предоставляющего функциональные возможности сетевого адаптера и модема или модема и адаптера MIDI одновременно. Сам по себе адаптер может быть совместим со спецификацией Plug-and-Play, но на портативном компьютере может использоваться версия интерфейса АРМ, ACPI или PnP BIOS, не способная распознать компонент модема. В таком случае придется настраивать ресурсы вручную.
Если ни одно из решений не позволило подключить модем, обратитесь к разделу “Устранение неисправностей с помощью журналов модема”, в котором приводятся дополнительные рекомендации по устранению неисправностей.
Даже если модем работает, работа администратора не завершена. При использовании несовместимого модема могут возникнуть другие проблемы, неочевидно связанные одна с другой. Если система работает с ошибками после установки модема, предполагайте худшее. Драйвер NDIS рассматривает устройство, подключающееся через последовательный порт, как соединение по сети и в этом случае часто проявляются недостатки проектирования.
Кроме этого, модем может работать совершенно нормально при стандартных подключениях терминалом, но отказывать при использовании для удаленного доступа. Это особенно справедливо, когда причиной проблемы является плохое состояние линии. Следует приобретать модемы с подсистемой исправления ошибок наилучшего качества. У оператора телефонной связи можно запросить проверку состояния телефонной линии. Линия должна поддерживать подключение на скорости до 56 Кбит/с. Обратитесь и к локальной службе поддержки телефонных сетей. Возможно, проблема заключается в неправильной коммутации проводов внутри здания.
Рекомендуемая конфигурация лаборатории для тестирования коммутируемого доступа
Иногда могут возникать проблемы, связанные с конфигурацией сервера, а не с конфигурацией модема. В таком случае стоит создать небольшую тестовую лабораторию, в которой будут настраиваться серверы удаленного доступа. Потребуется выбрать способ подключения модемов друг к другу. Их нельзя просто соединить один с другим обычным телефонным кабелем. Модемы нуждаются в специальных сигналах от телефонного коммутатора.
Можно приобрести специальное устройство, которое позволяет соединить два телефона или модема, но это достаточно дорогие устройства со специфическими функциональными возможностями. Может оказаться, что модемы не работают с приобретенной моделью устройства.
Более гибким решением является обращение к поставщикам услуг телефонной связи и запрос у них старых офисных АТС (Public Branch Exchange). Часто за пару сотен долларов можно найти бывшее в употреблении, но вполне работающее устройство. Еще пара сотен уйдет на приобретение программирующего телефона. Такое устройство позволяет выполнять полноценное тестирование тех же модемов, которые будут использоваться при эксплуатации решения.
Если необходимо только проверить передачу данных через последовательный порт, два компьютера под управлением Windows можно подключить непосредственно друг к другу с помощью последовательного кабеля. Не ошибитесь и не пытайтесь воспользоваться кабелем LapLink. Нуль-модемные кабели становятся все большей редкостью, так как устройства USB приходят на смену устройствам, подключающимся через последовательный порт. В табл. 20.3-20.5 показано назначение контактов для нуль-модемных последовательных кабелей.
Таблица 20.3. Назначение контактов для нуль-модемного кабеля на 9 контактов
Сигнал
Удаленный контакт
Локальный контакт
Передача данных (TD)
3
2
Прием данных (RD)_
2
3
Запрос на отправку (RTS)
7
8
Разрешение на отправку
8
7
Набор данных готов и Обнаружение несущей (DSR и CD)
6,1
4
Сигнальная земля
5
5
Терминал данных готов (DTR)
4
6, 1
Таблица 20.4. Назначение контактов для нуль-модемного кабеля на 25 контактов
Сигнал
Удаленный контакт
Локальный контакт
Передача данных (TD)
2
3
Прием данных (RD)
3
2
Запрос на отправку (RTS)
4
5
Разрешение на отправку
5
4
Набор данных готов и Обнаружение несущей (DSR и CD)
6,8 '
20
Сигнальная земля
7
7
Терминал данных готов (DTR)
20
6, 8
Таблица 20.5. Назначение контактов для нуль-модемного кабеля
с переходом с 25 на 9 контактов
Сигнал
25 контактов
9 контактов
Передача данных (TD)
2
2
Прием данных (RD)
3
3
Запрос на отправку (RTS)
4
9
Разрешение на отправку
5
7
Набор данных готов и Обнаружение несущей (DSR и CD)
6,8
4
Сигнальная земля
7
5
Терминал данных готов (DTR)
20
6, 1
Взяв нуль-модемный кабель и подключив два компьютера через последовательные порты, выполните последовательность действий, описанную в процедуре 20.8, и установите соединение по коммутируемому каналу связи.
Процедура 20.8. Установка непосредственного подключения между компьютерами через последовательный кабель
В Control Panel (Панель управления) откройте аплет Phone and Modem Options (Телефон и модем).
Активизируйте вкладку Modem (Модемы).
Щелкните на кнопке Add (Добавить). Запустится мастер добавления оборудования и откроется окно New Modem (Новый модем).
Выберите Don't Detect Му Modem (Не определять тип модема) и щелкните на кнопке Next (Далее).
После небольшой задержки система выдаст список модемов.
В разделе Manufacturer (Производитель) выберите Standard Modem Types (Стандартные модемы), а в разделе Models (Модель) выберите Communication Cable Between Two Computers (Нуль-модемный кабель между двумя компьютерами).
Щелкните на кнопке Next (Далее). Откроется окно Install New Modem (Установка нового модема), в котором будет предложено выбрать порт.
Выберите COM-порт и щелкните на кнопке Next (Далее).
Откроется окно со сводкой выбранных параметров. Щелкните на кнопке Finish (Готово), чтобы завершить работу мастера.
На этом этапе кабельное соединение можно использовать для установки коммутируемого подключения, как будто это настоящий модем. Для установки подключения воспользуйтесь мастером нового подключения в окне Network Connections (Сетевые подключения).
Мониторинг коммутируемых сеансов путем отслеживания протоколов
Удаленный доступ предоставляет расширенные возможности мониторинга, которые позволяют следить за всеми или некоторыми протоколами, которые используются для связи в глобальных сетях. Журнал настраивается вручную с помощью внесения изменений в раздел системного реестра HKLM\Sо f twaге\М i с го sо f t\Тгас ing.
В этом разделе приводится длинный список отслеживаемых протоколов. Отслеживание можно включить для любого количества протоколов. Каждый протокол поддерживает два варианта мониторинга: Log Tracing (Запись в журнал) и Console Tracing (Отображение на консоль), но работает только вариант Log Tracing. Вариант Console Tracing больше не поддерживается.
Журналы сохраняются в каталоге \Windows\Tracing в файле, имя которого соответствует названию записи в системном реестре. Ниже приведены список отслеживаемых протоколов и расшифровка соответствующих аббревиатур.
ВАР. Bandwidth Allocation Protocol (Протокол выделения полосы пропускания).
CONFMSP. Поставщик медиаслужб NetMeeting.
CONFTST. Поставщик служб TAPI NetMeeting.
EAPOL. Протокол EAP-over-LAN — 802.11b.
H323MSP. Поставщик медиаслужб протокола Интернет-конференций Н.323.
IASHLPR. Internet Authentication Services Helper.
LASRAD. Интерфейс IAS Radius.
IASRECST. IAS Record Storage.
IASSAM. Интерфейс IAS Security Account Manager.
IGMPv2. Internet Group Membership Protocol version 2 (Протокол управления группами Интернета).,
IPBOOTTP. IP Bootstrap Transfer Protocol, также используется для DHCP.
IPRIP2. IP Routing Information Protocol, release 2.
IPRouterManager. Компонент IP из мультипротокольного маршрутизатора RAS.
IPXAutonet. Обнаружение фреймов IPX.
IPX Traffic Filter Logging. Журнал фильтра данных IPX.
IPXCP. Протокол управления PPP для IPX.
IPXRIP. IPX Routing Information Protocol.
IPXRouterManager. Компонент IPX мультипротокольного маршрутизатора RAS.
IPXSAP. IPX Service Advertising Protocol.
IPXWAN. Управляющий компонент IPX Wide Area Network.
KMDDSP. Служба отображения режима ядра, один из основных поставщиков служб TAPI (вторым является NDPTSP).
NAPMMC. Оснастка IAS.
NDPTSP. NDIS Proxy TAPI Service Provider, один из двух основных поставщиков служб TAPI (вторым является KMDDSP).
NTAUTH. Аутентификация пользователя NT LanMan Challenge-Response.
OSPF. Open Shortest Path First.
OSPFMIB. Информация OSPF Management Information Block, которая используется для SNMP (Simple Network Management Protocol).
PPP. Point-to-Point Protocol (Протокол “точка-точка”).
RASADHLP. RAS Automatic Dialer helper.
RASAPI32. 32-разрядная библиотека RAS API.,
RASAUTO. RAS Automatic Dialer service trace (Диспетчер автоподключений удаленного доступа).
RASBACP. Bandwidth Allocation Control Protocol (Протокол управления распределением полосы пропускания).
RASCHAP. RAS Challenge Handshake Authentication Protocol (Протокол аутентификации RAS).
RASCPL. Журнал аплета RAS Control Panel; отсутствует в операционной системе Windows Server 2003.
RASDLG. Журнал RAS helper DLL.
RASEAP. Протокол ЕАР (Extensible Authentication Protocol) для RAS.
RASIPCP. Internet Protocol Control Protocol.
RASMAN. Служба RAS Management, Rasadmin. exe.
RASMON. Служба RAS Monitor.;
RASNBFCP. NetBIOS Frame Control Protocol.
RASPAP. Служба аутентификации Ras Password Authentication Protocol.
RASPHONE. Служба RAS Phonebook.
RASSCRIPT. Служба сценариев RAS.
RASSPAP. RAS Shiva Password Authentication Protocol.
RASTAPI. Драйвер RAS Telephony API.
RASTLS. RAS Transport Layer Security; используется для мониторинга смарт-карт, RADIUS и MD5-CHAP.
RASTLSUI. Пользовательский интерфейс RAS TLS.
RASUSER. Основной модуль графического интерфейса RAS.
RCAMSP. Поставщик служб потокового видео.
Router. Отслеживает активность службы мультипротокольного маршрутизатора.
RTM. Response Time Monitor; используется SNA.
TermMgr. Диспетчер терминальных служб.
Различные драйверы TAPI. TAPI3 и TAPI2 являются клиентскими интерфейсами к главному модулю TAPISRV.
WaveMsp. Поставщик цифрового звука.
Для просмотра содержимого журнала можно выполнить двойной щелчок на файле журнала, что приведет к запуску редактора Notepad (Блокнот). Обновления файла заблокированы не будут, но для просмотра изменений придется закрыть редактор Notepad (Блокнот) и открыть его повторно. Кроме этого, данные записываются в файл нерегулярно и нечасто, что позволяет повысить производительность. Это значит, что отображаемый размер файла может оказаться меньше фактического размера журнала. Если обновить содержимое окна Explorer (Проводник), размер файла будет обновлен.
Устранение неисправностей с помощью журнала модема
При проблемах в работе модема поиск источника проблемы может оказаться сложным процессом, поскольку выяснить фактическую причину проблемы очень сложно. Часто автора этой книги посещала мысль, что лучшими техниками систем коммуникаций могут стать ветеринары, так как у них хорошо получается диагностировать пациентов, не способных разговаривать.
В операционной системе Windows Server 2003 предоставляется два источника информации о модемах: журнал обнаружения модема, ModemDet. txt, и журнал модема, ModemLog_ <имя_модема>. txt.
Журнал ModemDet. txt
В журнале ModemDet.txt записывается результат опроса (команды АТ) модема установщиком класса при установке модема в системе. Этот журнал записывается только во время обнаружения нового устройства подсистемой Plug-and-Play. Рассмотрим пример журнала для внешнего модема, не поддерживающего технологию РпР:
A modem was found on COM1:
ATI0<cr> = <crxlf>3362
ATI0<cr> = <crxlf>3362
ATIl<cr> = <crxlf>221C
ATIl<cr> = <crxlf>
ATI2<cr> = <crxlf>0K
ATI2<cr> = <crxlf>0K
ATI3<cr> = <crxlf>Sportster 33600/Fax V2.31
ATI3<cr> = <crxlf>Sportster33600/Fax
ATI4<cr> = <crxlf>USRobotics Sportster 33600 Fax Settings...
ATI4<cr> = <crxlf>USRoboticsSportster33600FaxSettings
ATI5<cr> = <crxlf>USRobotics Sportster 33600 Fax NVRAM Settings...
ATI5<cr> = <crxlf>USRoboticsSportster33600FaxNVRAMSettings
ATl6<cr> = <crxlf>USRobotics Sportster 33600 Fax Link Diagnostics...
ATI6<cr> = <crxlf>USRoboticsSportster33600FaxLinkDiagnostics
ATI7<cr> = <crxlf>Configuration Profile...
ATI7<cr> = <crxlf>Conf igurationProf ile
ATl8<cr> = <crxlf>0K
ATI8<cr> = <crxlf>0K
ATl9<cr> = <crxlf>(1.0USR0003\\Modem\PNPC107\Sportster 33.6 FAS EXT)FF
ATI9<cr> = <crxlf>(USR\\Modem\PNPC\Sportster33.6FAXEXT)
ATI10<cr> = <crxlf>ERROR
ATI10<cr> = <crxlf>ERROR
AT%V<cr> = <crxlf>ERROR
AT%V<cr> = <crxlf>ERROR
Modem ID = UNIMODEM7ABE8C8F..
A modem was not found on COM2.
Ответы на запросы установщика классов сообщают, какой сценарий . inf искать. При обнаружении подходящего файла номер Unimodem ID назначается устройству. Это позволяет идентифицировать модем в системном реестре. В приведенном выше листинге в качестве идентификатора задана строка UNIMODEM7ABE8C8F.
Файлы ModemLog
На вкладке Diagnostics (Диагностика) в окне свойств модема присутствует флажок Record A Log File (Записывать файл журнала). Этот параметр включает запись отправленных на модем команд в файл журнала. Файл сохраняется в каталоге \Windows. Имя файла начинается с ModemLog_, после чего указывается имя модема, записанное в системном реестре.
Журнал оказывается достаточно большим. В нем записываются все предварительные тесты, которым подвергается модем, результаты тестирования, сообщения, отправленные на удаленный модем, имена и версии использованных драйверов и т.д. Эта информация очень полезна для получения представления о работе модема. Не оставляйте журнал включенным на длительное время, поскольку его размер увеличивается очень быстро.
Настройка сервера удаленного доступа
Рассмотрев все предварительные требования и теоретическую информацию, можно приступать к подготовке сервера к обслуживанию удаленного доступа. Служба маршрутизации и удаленного доступа (Routing and Remote Access Service — RRAS) устанавливается по умолчанию, но остается отключенной.
Служба RRAS управляется с помощью консоли Routing and Remote Access Service, хранящейся в файле Rrasmgmt .msc. С помощью одной консоли администратор может управлять всеми серверами маршрутизации и удаленного доступа. Консоль RRAS не поддерживает управление подключениями рабочих станций. На консоли RRAS поддерживается управление RRAS-серверами под управлением Windows NT 4.0, но в таком случае оказываются недоступными некоторые возможности маршрутизации. В таком случае лучше всего скопировать на свою рабочую станцию классическую утилиту управления сервером удаленного доступа Windows NT4.0 — Rasadmin. ехе. При добавлении устаревшего сервера на консоль RRAS и щелчке на соответствующей пиктограмме консоль автоматически запустит Rasadmin.
Начальная настройка службы RRAS
На рис. 20.28 показана относительно простая схема удаленного доступа. Сервер удаленного доступа размещен за пределами сети, защищенной брандмауэром, в демилитаризованной
зоне, что позволяет повысить уровень безопасности. Сервер маршрутизирует коммутируемые подключения клиентов в основную сеть через интерфейс демилитаризованной зоны, который является доверенным, но предоставляет большую степень контроля, чем простой коммутируемый доступ на сервер за брандмауэром. Поскольку изолированный RRAS-сервер может аутентифицировать пользователей только с помощью собственной базы данных SAM, он был настроен на использование технологии RADIUS и работает в паре с IAS-сервером внутри сети, защищенной брандмауэром.
ДемилитаризованнаяДемилитаризованнаяОсновная граница брандмауэраОсновная граница брандмауэраФайловый сервер и сервер печатиФайловый сервер и сервер печати
Демилитаризованная
Демилитаризованная
Основная граница брандмауэра
Основная граница брандмауэра
Файловый сервер и сервер печати
Файловый сервер и сервер печати
Рис. 20.28. Простая схема коммутируемого доступа, позволяющая пользователю в домене подключаться непосредственно к RRAS-cepeepy с последующей маршрутизацией в основную сеть после аутентификации с помощью RADIUS
Рассмотрим основные этапы создания такой конфигурации.
Установите модем или систему удаленного доступа (Modem bank), или адаптер Т-1, или адаптер ISDN BRI или PRI на сервере удаленного доступа. Потребуются драйверы, предназначенные для операционной системы Windows Server 2003, Windows ХР или Windows 2000.
Настройте службу маршрутизации и удаленного доступа (RRAS-службу).
Настройте удаленный доступ на прием коммутируемых подключений и использование технологии RADIUS для аутентификации.
Настройте IAS-сервер для принятия запросов на аутентификацию от сервера удаленного доступа.
Если домен работает в режиме Windows 2000 Mixed, настройте отдельные учетные записи пользователей в базе данных Active Directory на удаленный доступ. Если домен работает в режиме Native, для настройки разрешений коммутируемого доступа воспользуйтесь политиками удаленного доступа.*
Добавьте сервер удаленного доступа в группу RAS and IAS Servers в других доменах леса.
Нет необходимости специально настраивать клиенты коммутируемого доступа. Клиенты
Windows используют принятый по умолчанию метод аутентификации (MS-CHAPv2).
Как и при большинстве операций настройки в Windows Server 2003, для настройки службы RRAS используется мастер. Доступные в мастере параметры настройки сложнее, чем может показаться на первый взгляд. Воспользуемся мастером для инициализации службы и рассмотрим некоторые параметры более подробно. Выполните последовательность действий, описанную в процедуре 20.9.
Процедура 20.9. Инициализация службы RRAS для поддержки удаленного доступа
Откройте консоль Routing and Remote Access Service. Для этого воспользуйтесь командой Starts Programs^ Administrative Tools^ Routing and Remote Access Service (Пуск1^ Программы1^ Администрированием RRAS).
Щелкните правой кнопкой мыши на пиктограмме локального сервера и выберите из контекстного меню команду Configure and Enable Routing and Remote Access (Настроить и включить маршрутизацию и удаленный доступ). При этом запустится мастер настройки сервера маршрутизации и удаленного доступа. Сначала открывается окно Configurations (Конфигурации), которое показано рис. 20.29.
Рис. 2029. Мастер настройки сервера маршрутизации и удаленного доступа. Окно Configurations (Конфигурации), в котором показаны параметры настройки
Выберите переключатель Remote Access (Удаленный доступ) и щелкните на кнопке Next (Далее). Откроется окно Remote Access (Удаленный доступ).
Можно выбрать Dial-Up (Коммутируемый) или VPN, или оба варианта. На данном этапе выберите Dial-Up (Коммутируемый).
Щелкните на кнопке Next (Далее). Откроется окно Network Selection (Выбор сети), которое показано на рис. 20.30. В этом окне выбирается интерфейс, который сервер будет использовать для назначения параметров IP. На сервере с несколькими сетевыми адаптерами выберите интерфейс, который подключен к основной сети.
Routing and Remote Access Server Setup Wizard
Network Selection
You can assign remote dents to the network that you want them to use.
Ramofa dlnti rmetbeaMignwi io one network far addeewe. dkhtp accees, and
Ndwuk falttfaceo*
*5377777 -. Рэд^ 1,1- ipAdate
Local Aim Corrections Realtek RTL8139Fami.. 1821686157 (DHCP)
Puc. 20.30. Мастер настройки сервера маршрутизации и удаленного доступа. В окне Network Selection (Выбор сети) показан список доступных интерфейсов
Щелкните на кнопке Next (Далее). Откроется окно IP Address Assignment (Назначение IP-адреса). Можно выбрать использование DHCP или использование статического диапазона адресов. Дополнительная информация о выборе в данном окне в зависимости от инфраструктуры IP приводится в разделе “Настройка параметров IP для коммутируемого доступа’’.
Щелкните на кнопке Next (Далее). Откроется окно Managing Multiple Remote Access Servers (Управление несколькими серверами удаленного доступа). В этом окне можно выбрать использование технологии RADIUS для аутентификации. При выборе этого варианта мастер позволяет указать сервер RADIUS и общий секрет. Дополнительная информация приводится в разделе “Настройка сервера IAS”.
Щелкните на кнопке Next (Далее). Откроется окно со сводкой выбранных параметров. Щелкните на кнопке Finish (Готово), чтобы запустить службу.
Если домен работает в режиме Mixed, удостоверьтесь, что учетные записи в базе данных Active Directory получили разрешения на коммутируемый доступ. Если домен работает в режиме Native, воспользуйтесь консолью RRAS и в разделе Remote Access Policies (Политики удаленного доступа) для политики Allow Access If Dial-in Permission Enabled (Разрешить доступ, если разрешен коммутируемый доступ) установите значение Grant Access (Предоставить доступ). В результате авторизованные пользователи получат доступ.
Проверка коммутируемых подключений
с помощью журнала удаленного доступа
Сервер готов принимать запросы на соединение от пользователей. Проверьте работоспособность сервера, установив соединение с клиентской рабочей станции с помощью регистрационных данных учетной записи Active Directory. Если возникают проблемы, связанные с удаленным доступом. ^ не с модемным соединением, может потребоваться включение журнала на консоли RRAS.
Первый вариант журнала включается для сервера в окне свойств RRAS-сервера (рис. 20.31).
Рис. 20.31. Окно Properties (Свойства) RRAS- сервера. Вкладка Logging (Журнал)
При выборе этого переключателя информация о работе сервера записывается в журнал событий. Второй вариант журнала доступен при использовании пиктограммы Remote Access Logging (Журнал удаленного доступа) на консоли управления RRAS. Этот вариант журнала позволяет отслеживать активность на каждом коммутируемом интерфейсе. Это очень ценный инструмент анализа, но для интерпретации результатов его работы потребуется терпение.
Журнал представляет собой файл со значениями, разделенными запятыми. Каждая строка соответствует записи. Первая строка является заголовком, в котором содержится информация о пользователе, подключающемся по линии коммутируемого доступа, который получил доступ к серверу:
- IP address testuser - logon name 02/15/2002/ - access date 22:24:5 - access time RAS - access method DC-01 - target domain controller
В следующих полях указываются пары чисел. Первое число является идентификатором атрибута, а второе число — значением атрибута. Ниже приведен краткий пример для пользователя, которому было отказано в доступе:
4121,0x00453D36343920523D3020563D33 - CHAP error
4127,4 - authentication type
4130,SUSIDIARY\testuser - Fully qualified user name
4136,3 - packet type (accept-reject)
4142,48 - refection reason (incomplete accounting-request packet received.)
Дополнительная информация об атрибутах и ограничениях, указанных в записях журнала, доступна в интерактивном справочном руководстве в разделе “Interpreting IAS-Formatted Log Files”. В этом разделе доступны полный список и описание типов атрибутов. Кроме этого, обратите внимание на Документ RFC 2138, “Remote Authentication Dial In User Service (RADIUS)”, а также на документ RFC 2548, “Microsoft Vendor-specific RADIUS Attributes”, в котором описываются расширения, реализованные компанией Microsoft.
Атрибуты производителя, связанные с каждым интерфейсом, хранятся в базе данных Active Directory в объекте, который называется Identity-Dictionary. Этот объект хранится в контейнереcn=RRAS,cn=Services,cn=Configuration,ас=<домен>,ас=<корень>. Содержимое этого атрибута доступно в редакторе ADSI Editor, который предоставляется в составе пакета Support Tools.
Настройка параметров IP
для коммутируемого доступа
С точки зрения драйвера NDIS сетевой интерфейс, представленный модемом или терминальным адаптером ISDN, ничем не отличается от адаптера Ethernet. Для описания этого интерфейса будут использованы термины адаптер РРР (PPP adapter) и виртуальный интерфейс глобальной сети (virtual WAN interface). На самом деле драйвер NDIS рассматривает как виртуальные адаптеры все сетевые интерфейсы, а не только соединения удаленного доступа. Одной из задач драйвера NDIS является маскирование физических аппаратных средств за виртуальным покровом логики доступа.
Если запустить команду ipconfig /all на любом компьютере из показанных на схеме, адаптер РРР будет показан вместе с остальными сетевыми адаптерами. Рассмотрим пример выполнения этой команды:
Windows IP Configuration
Host Name:prol
Primary Dns Suffix:
Node Type .. : Mixed
IP Routing Enabled:No
WINS Proxy Enabled:No
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
Description :AMDPCNETFamilyPCI
S>Ethernet Adapter
Physical Address:00-0C-29-65-E9-8B
DHCP Enabled:No
IP Address .: 192.168.0.3
Subnet Mask :255.255.255.0
Default Gateway :192.168.0.254
DNS Servers :192.168.0.15
PPP adapter Company VPN:
WAN (PPP/SLIP) Interface 00-13-25-00-00-00No192.168.10.23 255.255.255.255 192.168.10.23 192.168.10.100WAN (PPP/SLIP) Interface 00-13-25-00-00-00No192.168.10.23 255.255.255.255 192.168.10.23 192.168.10.100Connection-specific DNS Suffix . : Description :
WAN (PPP/SLIP) Interface 00-13-25-00-00-00
No
192.168.10.23 255.255.255.255 192.168.10.23 192.168.10.100
WAN (PPP/SLIP) Interface 00-13-25-00-00-00
No
192.168.10.23 255.255.255.255 192.168.10.23 192.168.10.100
Physical Address:
DHCP Enabled:
IP Address:
Subnet Mask:
Default Gateway :
DNS Servers:
Адрес принятого по умолчанию шлюза для адаптера РРР совпадает с IP-адресом, назначенным интерфейсу RRAS-сервером. Это старая хитрость, которую можно сформулировать так: “Если необходим путь выхода из этого компьютера, обращайся ко мне”. Подтвердить это предположение можно с помощью команды route print. В этом примере информация о коммутируемом соединении выделена полужирным шрифтом:
Interface List
0x1 MSTCP Loopback interface
0x2 ... 00 Ос 29 65 е9 8b AMDPCNET Family PCI Ethernet Adapter
0x20006 ... 00 13 25 00 00 00 .. WAN (PPP/SLIP) Interface
Active Routes:
Network DestinationNetmask
Gateway
Interface Metric
0.0.0.0
0.0.0.0
192.168.0.1
192.168.0.253
21
0.0.0.0
0.0.0.0
192.168.10.23
192.168.10.23
1
127.0.0.0
255.0.0.0
127.0.0.1
127.0.0.1
1
192.168.0.0
255.255.255.0
192.168.0.253
192.168.0.253
20
192.168.0.2
255.255.255.255
127.0.0.1
127.0.0.1
20
192.168.0.255
255.255.255.255
192.168.0.253
192.168.0.253
20
192.168.10.3
255.255.255.255
127.0.0.1
127.0.0.1
50
192.168.10.255
255.255.255.255
192.168.10.23
192.168.10.23
50
224.0.0.0
224.0.0.0
192.168.0.253
192.168.0.253
20
224.0.0.0
224.0.0.0
192.168.10.23
192.168.10.23
1
255.255.255.255
255.255.255.255
192.168.0.253
192.168.0.2
1
Default Gateway:
192.168.10.23
Persistent Routes:
None v ■
В приведенном листинге для принятого по умолчанию шлюза указан адрес 192.168.10.23. Результатом этого маневра является маршрутизация нелокального IP-трафика от клиента на RRAS-сервер, а с RRAS-сервера выполняется маршрутизация в сеть. Единственный виртуальный адаптер глобальной сети на RRAS-сервере используется для обработки всего входящего трафика. Для обозначения этого интерфейса в окне Network Connections (Сетевые подключения) используется пиктограмма Incoming Connections (Входящие подключения).
Назначенные адаптерам РРР параметры IP предоставляются RRAS-сервером всегда, кроме тех случаев, когда система настроена на использование адресов, назначенных статически на клиентах удаленного доступа. Параметры IP для RRAS-сервера находятся на вкладке IP в окне свойств сервера на консоли RRAS (рис. 20.32).
Рис. 20.32. В окне свойств для RRAS-cepeepa на вкладке IP можно настроить параметры маршрутизации, назначения адресов и параметров преобразования имен
Назначение клиенту IP-адреса
В окне IP Address Assignment (Назначение IP-адресов) предоставляется два варианта назначения адресов клиентам, подключающимся по коммутируемым соединениям и интерфейсу РРР на RRAS-сервере.
Один из переключателей включает статический диапазон IP-адресов. Этот переключатель используется при отсутствии сервера DHCP или нецелесообразности его использования для клиентов, подключающихся по коммутируемым соединениям. При указании диапазона адресов необходимо выбрать подсеть, отличную от подсети основного интерфейса RRAS-сервера. Сервер будет маршрутизировать трафик между двумя подсетями. Дополнительная информация приводится во врезке “Протоколы маршрутизации”.
Еще одним вариантом является использование протокола DHCP. При выборе этого переключателя RRAS-сервер обнаруживает сервер DHCP для собственной подсети и получает у него IP-адреса для коммутируемых интерфейсов. Ключевое слово — “интерфейсы”, а не “клиенты". RRAS-сервер не ожидает подключения клиента для получения в аренду IP-адреса. Адреса получаются немедленно.
В операционной системе Windows NT 4.0 такая конфигурация приводила к появлению проблем при использовании стойки из 20 или 30 модемов либо к настройке нескольких десятков интерфейсов Point-to-Point Tunneling Protocol (PPTP). RRAS-сервер получал адреса для всех интерфейсов плюс один адрес для себя. Это может привести к истощению пула адресов на сервере DHCP.
Начиная с операционной системы Windows 2000, RRAS-сервер был модифицирован для получения только 10 адресов одновременно. Если установлено 10 модемов и 30 интерфейсов VPN, но обычно одновременно работают не более 18 пользователей, из пула адресов DHCP будет получено только 20 адресов.
Настройка преобразования имен
Клиенту, подключающемуся по коммутируемому соединению, необходимо преобразование имен в IP-адреса, как и любому другому компьютеру в сети. Но предоставление информации о DNS- и WINS-серверах для такого клиента немного сложнее, чем может показаться на первый взгляд.
Клиенты РРР получают параметры конфигурации на этапе IPCP транзакции подключения. Сервер удаленного доступа определяет Источник получения этих значений в зависимости от параметров адресации IP, рассмотренных в предыдущем разделе.
Статическая IP-адресация
Если сервер удаленного доступа настроен на использование статического диапазона адресов, параметры DNS и WINS извлекаются из настроек сетевого адаптера.
Если сетевой адаптер настроен на использование протокола DHCP, клиенту предоставляются динамические параметры сетевого интерфейса.
Если сетевой адаптер использует протокол DHCP и также имеет статические настройки DNS и WINS, статическая конфигурация получает больший приоритет и только статические параметры предоставляются клиентам коммутируемого доступа.
Протоколы маршрутизации
Если используется сервер удаленного доступа, выделяющий клиентам коммутируемого доступа отдельную подсеть IP и подключенный к различным серверам через отдельные сегменты локальной сети, поддержка таблиц маршрутизации может оказаться нетривиальной задачей. Кроме этого, могут использоваться стандартные маршрутизаторы, которым тоже нужно знать о подсетях.
В такой ситуации на консоли RRAS можно включить использование протокола Routing Information Protocol (RIP). В протоколе RIP для поддержки актуального состояния остальных маршрутизаторов используются широковещательные запросы. Если существующие маршрутизаторы используют протокол OSPF (Open Shortest Path First), на RRAS-сервере можно включить протокол маршрутизации OSPF. Подробно обсудите эту конфигурацию с сетевыми инженерами, чтобы не создать замкнутый маршрут или не распространить неподходящую информацию OSPF. Никто не хочет, чтобы через RRAS-сервер маршрутизировались 5000 сетевых клиентов, и все это только из-за неправильно указанной метрики маршрута.
Если сервер удаленного доступа оборудован более чем одним сетевым адаптером, можно выбрать адаптер, который будет использоваться для получения параметров IP. Соответствующий переключатель расположен на вкладке IP в окне свойств RRAS-сервера.
Если оставить выбранное по умолчанию значение Allow RAS to Select Adapter (Позволить серверу удаленного доступа выбирать адаптер), сервер выберет первый адаптер, указанный в разделе Routing Interfaces (Маршрутизируемые интерфейсы) на основной консоли RRAS. Обычно это первый интерфейс, установленный на сервере. Если адаптер недоступен, используется второй адаптер из списка.
/P-адресация на основе DHCP '
Если сервер удаленного доступа настроен на использование DHCP для выдачи адресов клиентам коммутируемого доступа, ситуация усложняется.
Как было показано в предыдущем разделе, IP-адреса, назначенные клиентам, подключающимся по коммутируемым линиям, арендуются у DHCP-сервера и кэшируются локально сервером удаленного доступа. Но на этапе IPCP клиентам коммутируемого доступа предоставляются параметры, Полученные из сетевого интерфейса, а не от DHCP-сервера. На этапе использования IPCP просто недостаточно времени, чтобы сделать паузу и получить актуальные параметры от DHCP-сервера.
Однако, включив протокол DHCP на сетевом интерфейсе сервера удаленного доступа, можно предоставлять клиентам коммутируемого доступа конфигурацию DHCP. Параметры DNS и WINS, полученные от DHCP-сервера, предоставляются клиентам коммутируемого доступа. Если статически назначить сетевому интерфейсу другие адреса DNS и WINS, они будут иметь больший приоритет.
DHCPINFORM
Многие специалисты информационных технологий предпочитают назначать серверам статические IP-адреса. Если статические адреса DNS и WINS, указанные в параметрах сетевого адаптера, подходят клиентам коммутируемого доступа, проблема не возникает. Но если эти параметры не подходят, клиенты под управлением современных версий Windows могут перехватить управление и получить другие параметры от сервера DHCP.
Этот прием основан на относительно новой возможности сервера DHCP, которая называется DHCPINFORM. Одной из функций DHCPINFORM является предоставление клиентам, не использующим протокол DHCP, конфигурационной информации, указанной сервером DHCP.
Клиенты под управлением Windows Server 2003, Windows ХР и Windows 2000 используют эту возможность с помощью широковещательной рассылки пакета DHCPINFORM после завершения транзакции РРР. Служба агента ретрансляции на сервере удаленного доступа передает пакет DHCPINFORM DHtP-серверу, который отвечает пакетом с параметрами конфигурации. Клиент назначает полученные параметры собственному коммутируемому интерфейсу (в дополнение к параметрам, назначенным на этапе IPCP).
Для наблюдения за этой транзакцией не требуется перехват пакетов. Отключите интерфейс Ethernet на клиенте удаленного доступа и в приглашении командной строки введите команду ipconfig /all. В результате выполнения команды ничего выдано не будет. После
этого установите коммутируемое соединение с сервером удаленного доступа. После установки физического соединения начинайте периодически вводить команду ipconfig /all. Сначала будут выданы параметры конфигурации, соответствующие параметрам конфигурации сетевого интерфейса на сервере удаленного доступа. Через несколько секунд содержимое вывода изменится, отражая параметры, полученные от DHCP-сервера.
В результате будут получены как минимум две записи для DNS и WINS. Это признак успешного завершения процесса DHCPINFORM. Ниже представлен пример отчета о выполнении команды ipconfig /all. Полужирным шрифтом выделены параметры, полученные с помощью функции DHCPINFORM. Вторичные записи получены от сетевого интерфейса:
C:\>ipconfig /all
Windows IP Configuration
Host Name:xp-prol
Primary Dns Suffix :subsidiary.com
Node Type:Unknown
IP Routing Enabled:No
WINS Proxy Enabled..,:Yes
Dns Suffix Search List :subsidiary.com
PPP adapter server!:
: WAN (PPP/SLIP) Interface: 00-53-45-00-00-00: No: 192.168.10.19: 255.255.255.255: 192.168.10.19: 192.168.10.200192.168.0.100: 192.168.10.200: 192.168.0.100: WAN (PPP/SLIP) Interface: 00-53-45-00-00-00: No: 192.168.10.19: 255.255.255.255: 192.168.10.19: 192.168.10.200192.168.0.100: 192.168.10.200: 192.168.0.100Connection-specific DNS Suffix Description Physical Address DHCP Enabled
: WAN (PPP/SLIP) Interface
: 00-53-45-00-00-00
: No
: 192.168.10.19
: 255.255.255.255
: 192.168.10.19
: 192.168.10.200
192.168.0.100
: 192.168.10.200
: 192.168.0.100
: WAN (PPP/SLIP) Interface
: 00-53-45-00-00-00
: No
: 192.168.10.19
: 255.255.255.255
: 192.168.10.19
: 192.168.10.200
192.168.0.100
: 192.168.10.200
: 192.168.0.100
IP Address
Subnet Mask
Default Gateway
DNS Servers
Primary WINS Server
Secondary WINS Server
Несложно заметить, что для клиента полученные с помощью DHCPINFORM параметры становятся основными. Это позволяет клиенту использовать параметры DNS и WINS, соответствующие подсети IP.
Не забудьте включить службу ретранслятора DHCP на консоли RRAS. Для этого придется указать интерфейс, на который должны поступать широковещательные запросы DHCPINFORM. Кроме этого, придется указать IP-адрес как минимум одного DHCP-сервера.
Если клиенты работают под управлением операционных систем Windows NT 4.0 и Windows Эх, придется применить другое решение, так как эти клиенты не поддерживают использование DHCPINFORM. Самым простым методом является статическая настройка параметров DNS и WINS в свойствах коммутируемого подключения. Именно эти параметры будут действительными, даже если клиент получит адрес от сервера удаленного доступа.
Преобразование "плоских" имен
Переключатель Enable Broadcast Name Resolution (Разрешить преобразование широковещательных имен) на вкладке IP окна свойств сервера удаленного доступа является новой возможностью операционной системы Windows Server 2003. По умолчанию эта возможность отключена. Эта функция предназначена для упрощения преобразования имен в небольших сетях, где не установлены службы DNS и WINS.
Примером такой конфигурации является небольшая производственная фирма, в которой имена компьютеров назначались несовершеннолетним сыном владельца при установке локальной сети. При попытке клиента коммутируемого доступа на портативном компьютере Blink_182 подключиться к серверу DMX через сетевой диск портативный компьютер нуждается в методе преобразования имени в 1Р-адрес.
В локальной сети для этого используются широковещательные запросы. Включение широковещательных запросов через коммутируемое подключение также обеспечивает преобразование имен.
В больших сетях преобразование имен с помощью широковещательных запросов нежелательно, но для пары десятков узлов в единственной подсети этот механизм себя оправдывает, поэтому его не стоит избегать только из-за опасений увеличить объем передаваемых по сети данных. Но если в такой сети планируется установка Windows Server 2003, можно установить службы DNS и WINS и избежать использования широковещательных запросов.
Настройка дополнительных параметров IP
Флажок Enable IP Routing (Включить маршрутизацию IP) на вкладке IP в окне свойств сервера удаленного доступа установлен по умолчанию. Этот флажок управляет доступом к основной сети. Это хороший метод блокирования сетевого доступа, когда необходимо изменить параметры, не отключая сервера. При изменении этого параметра не нужно останавливать и перезапускать службу. Изменение вступает в силу немедленно.
Флажок Allow IP-Based Remote Access and Demand-Dial Connections (Разрешить удаленный доступ no IP и подключения с дозвоном по требованию) выступает в роли выключателя удаленного доступа. Этот флажок полезен при устранении неисправностей во время работы службы RRAS с одновременным блокированием доступа к данной службе. К сожалению, пользователи будут получать сообщение об ошибке Cannot connect to remote network (Невозможно подключиться к удаленной сети), а не что-то вроде Remote network temporarily unavailable (Удаленная сеть временно недоступна).
Управление маршрутизацией и удаленным доступом из командной строки
В составе операционной системы Windows Server 2003 предоставляется универсальный текстовый инструмент для управления сетевыми параметрами, включая параметры маршрутизации и удаленного доступа. Этот инструмент называется Network Shell или Netsh.
Утилита Netsh предоставляет текстовый интерфейс с широкими возможностями. Если просто запустить утилиту на одном из серверов, некоторые из параметров могут оказаться недоступными. Такие параметры становятся доступными только после запуска соответствующей службы.
Для перехода в определенный контекст пространства имен необходимо ввести имя контекста в приглашении утилиты. Например, введите ras для перехода в контекст netsh ras>.
Можно переходить из одного контекста в другой без "путешествия” по промежуточным контекстам. Например, в контексте netsh ras> можно ввести команду interface для перехода непосредственно в контекст netsh interfaces Для перехода в родительский контекст можно ввести две точки (. .), как при перемещении по дереву каталогов. Введите bye, exit или quit для выхода из командного интерпретатора.
Для просмотра команд, доступных на каждом уровне пространства имен, введите ? в приглашении утилиты. Некоторые команды имеют дополнительные параметры. Для просмотра списков параметров введите команду и вопросительный знак. Например, команда show ? позволяет просмотреть параметры в текущем контексте: netsh ras>show ?
show tracing - Показывает, активизирован ли режим расширенной трассировки для компонентов.
show user- Выводит свойства пользователя для RAS.
show authmode - Выводит режим проверки подлинности.
show authtype - Отображает типы проверки подлинности, разрешенные
в настоящий момент.
show link- Выводит список свойств связи, согласуемых РРР
show multilink - Выводит список типов многоканальной связи согласуемых РРР
show registeredserver - Выводит информацию о том, зарегистрирован ли
.
компьютер как RAS-сервер в Active Directory указанного домена
show domainaccess
- Отображает, активизированы ли в Active Directory
данного домена RAS-серверы под управлением
Windows NT4 или Windows Server 2003
show activeusers
- Ожидать объявлений RAS-сервера
show client
- Отображает RAS-клиенты, подключенные к этому
компьютеру
show alias
- Вывод списка всех определенных псевдонимов.
show mode
- Отображение текущего режима.
При вводе правильных команд результат выполнения команды выводится на консоли: ras>show registeredserver domain=company.com The following RAS server is registered:
RAS Server: DC-01
Domain:company.com
Для изменения параметра замените слово show словом set. Утилита Network Shell поддерживает два режима работы: интерактивный и неинтерактивный. Для переключения между режимами в приглашении можно ввести команды online и offline. В интерактивном режиме все внесенные изменения вступают в силу немедленно. В неинтерактивном режиме изменения сохраняются, но не реализуются. Для реализации изменений необходимо дополнительно ввести команду commit. Для отмены изменений можно ввести команду abort.
Одной из наиболее полезных возможностей утилиты Network Shell является возможность сброса текущей конфигурации в сценарий, который можно будет воспроизвести для восстановления оригинальной конфигурации. Для просмотра текущей конфигурации можно воспользоваться командой dump. Команду dump можно ввести в приглашении командной строки. В таком случае результат будет выведен на экран. Для сохранения вывода в файл необходимо ввести команду dump в качестве параметра командной строки и перенаправить вывод команды в файл.
Если необходимо ограничить действие команды dump определенным контекстом, добавьте название контекста в командную строку. Ниже приведен пример использования этой команды:
C:\>netsh ras ip dump > netshrasip.scr
,
IP-конфигурация RAS
pushd ras ip'
set negotiation mode = allow set access mode = all set addrreq mode = deny
set pool addr = 10.1.2.0 mask = 255.255.255.240 set addrassign method = auto
popd
Конец IP-конфигурации RAS.
Для внесения параметров, сохраненных в файле сценария, введите команду net sh -f <имя_ файла>, например:
c:\>netsh -f netshrasip.scr
С помощью утилиты netsh можно управлять и другими серверами. Для этого сценарий можно выполнить в удаленном командном интерпретаторе или запустить с помощью Windows Scheduler (Планировщик заданий).
Управление подключениями удаленного доступа с помощью групповых политик
Существует несколько групповых политик для управления подключениями удаленного доступа на клиентских рабочих станциях. Эти политики доступны в редакторе групповых политик в разделе Administrative Templates^Network^Network Connections (Административные шаблоны1^ СетьФ Сетевые подключения). В этом разделе доступен небольшой список политик для компьютеров и более длинный список для пользователей.
■ Компьютерные политики позволяют отключить на рабочих станциях следующие службы.
Internet Connection Sharing (ICS)
Internet Connection Firewall (ICF)
Сетевой мост
Аутентификация беспроводных подключений на основе сертификатов
Из этого списка стоит отключить службу ICS как можно раньше при развертывании рабочих станций под управлением Windows 2000 и Windows ХР. Это защитит сеть от создания “потайного хода” пользователем с локальными правами администратора.
Пользовательские политики запрещают пользователям менять или даже просматривать содержимое настроек удаленного доступа. Эти политики могут пригодиться, если необходимо избежать постоянных звонков в службу поддержки от пользователей, которые думают, что обладают достаточной квалификацией для изменения параметров коммутируемого подключения. Поскольку групповые политики продолжают действовать даже при отключении компьютера от сети, можно ослабить ограничения политик для тех пользователей, которым может потребоваться изменение номера телефона во время командировки.
Установка коммутируемого соединения из командной строки.'
Для установки коммутируемого соединения не нужен графический интерфейс. Выполняемый файл, Rasdial. ехе, который используется для установки соединения, может вызываться из командной строки или файла пакетной обработки.
С помощью Rasdial рабочую станцию без пользователя можно настроить на установку коммутируемого соединения по расписанию, настроенному в Task Scheduler (Планировщик заданий). Кроме этого, можно настроить копирование файлов, доставку электронной почты и другие периодические задачи. Для этого создайте файл пакетной обработки и укажите в этом файле имя записи телефонной книги для утилиты Rasdial. Имя записи совпадает с именем пиктограммы подключения в окне Networking and Dial-up Connections. Например, если существует подключение Home Office, команда будет выглядеть следующим образом: rasdial "home office".
Пока система устанавливает соединение, на консоли выводится та же информация о состоянии, что и при установке соединения из графического интерфейса. Для разрыва соединения воспользуйтесь следующей командой: rasdial /disconnect
К сожалению, утилиту Rasdial нельзя использовать вместе со смарт-картами. В таком случае придется использовать пароли. Если пароли не кэшируются при установке коммутируемого подключения или же необходимо воспользоваться не теми регистрационными данными, которые указаны в телефонной книге,1 то нужную информацию можно предоставить в командной строке. Ниже приведен пример этой команды (параметры не чувствительны к регистру):
rasdial "home office" имя_пользователя */DOMAIN:домен
/PHONE:номер_телефона /CALLBACK:номер_обратного_звонка /PREFIXSUFFIX
Символ “звездочка" (*) заставляет утилиту Rasdial выдавать запрос на ввод пароля. Пароль можно ввести и в командной строке. Параметр /prefixsuffix сообщает утилите Rasdial о необходимости использовать параметры TAPI для интерфейса модема.
Кроме этого, с помощью команды rasphone можно модифицировать телефонную книгу из командной строки. При запуске этой утилиты также открывается графический интерфейс, но, по крайней мере, это быстрее, чем пробираться через меню к пиктограмме подключения. Если ввести команду rasphone -а, сразу запускается мастер новых подключений (Network Connection Wizard).
Настройка маршрутизатора с дозвоном по запросу
Широкополосные подключения становятся доступны практически во всех городах, но технология DSL ограничена длиной кабеля, а цифровой кабель только сейчас начинает предлагаться компаниям в качестве решения для перёдачи данных. Другие варианты постоянного подключения, например разделение пропускной способности линии Т-1 для нескольких пользователей, оказываются слишком дорогими, даже в районах с достаточно низкими тарифами.
Часто единственным доступным решением для удаленного или домашнего офиса является использование коммутируемого соединения с помощью модема или адаптера ISDN. Концептуально разницы между коммутируемым соединением и выделенной линией не существует. Единственной практической разницей является различие в скорости и задержке до установки подключения. В случае ISDN для установки подключения достаточно пары сотен миллисекунд. В случае модемов эта задержка составляет порядка 15-20 секунд.
Сервер маршрутизации и удаленного доступа (RRAS-сервер) под управлением операционной системы Windows Server 2003 может быть настроен на установку коммутируемого подключения, которое работает в качестве решения вида “точка-точка”. Используя несколько модемов, можно достичь большей пропускной способности, чем при использовании ISDN или недорогих выделенных линий. Функция установки подключения по запросу встроена в большинство маршрутизаторов ISDN, но можно дешево купить терминальный адаптер ISDN, который, однако, не обеспечивает использование канала “В” или установку подключения по запросу. В таком случае эти задачи возлагаются на RRAS-сервер. В этом разделе рассматриваются инициализация служб маршрутизации на RRAS-сервере, а также настройка установки подключения по запросу с помощью общедоступного IP-адреса или технологии NAT (Network Address Translation — трансляция сетевых адресов) и брандмауэра.
Инициализация служб маршрутизации
Для использования установки подключения по запросу необходимо включить возможности удаленного доступа (Remote Access) и маршрутизации (Routing) на RRAS-сервере. Включение маршрутизации на существующем сервере удаленного доступа требует перезапуска службы, поэтому эти задачи должны выполняться после завершения рабочего дня. При этом существующие параметры удаленного доступа сохранятся. Необходимая последовательность действий приводится в процедуре 20.10.
Процедура 20.10. Начальная конфигурация служб маршрутизации и удаленного доступа
Откройте консоль Routing and Remote Access.
Выделите пиктограмму Remote Access Clients (Клиенты удаленного доступа) и убедитесь, что к серверу не подключен ни один пользователь.
Щелкните правой кнопкой мыши на имени локального сервера и выберите из контекстного меню команду Disable Routing And Remote Access (Отключить маршрутизацию и удаленный доступ). Будет выдано предупреждение о необходимости повторной настройки службы при последующем запуске. Щелкните на кнопке Yes (Да) для отключения службы.
После остановки службы (а это может отнять некоторое время) пиктограмма сервера изменится на изображение красной стрелки, направленной вниз. После этого выполните повторную инициализацию службы, воспользовавшись инструкциями процедуры 20.9, но добавив следующие этапы.
В окне Routing and Remote Access (Маршрутизация и удаленный доступ) выберите Enable Server as a Router (Использовать сервер, как маршрутизатор) и выберите переключатель Local and Remote Routing (LAN and WAN) (Локальная и удаленная маршрутизация).
В окне Dial-in or Demand Dial Interfaces (Коммутируемые интерфейсы или интерфейсы с дозвоном по требованию) выберите переключатель Enable АП Devices For Both Routing and Remote Access (Разрешить использование устройств для маршрутизации и удаленного доступа).
Оставшиеся действия совпадают. При перезапуске службы RRAS на консоли RRAS появится дополнительная пиктограмма, которая называется Routing Interfaces (Интерфейсы маршрутизации).
После включения маршрутизации сервер можно настроить на дозвон по требованию в удаленный офис, дозвон по требованию в сеть Интернет или дозвон по требованию в Интернет с трансляцией сетевых адресов. В следующих двух разделах рассматривается настройка маршрутизатора с дозвоном в Интернет по требованию и трансляцией сетевых адресов. Маршрутизация с дозвоном по требованию между различными офисами здесь не рассматривается, так как такая конфигурация становится все более редкой и организации переходят к использованию Интернета в качестве промежуточного транспорта.
Настройка маршрутизатора с дозвоном в Интернет по требованию
Если необходимо сохранить общедоступные адреса сети, то для подключения к Интернету должен быть использован маршрутизируемый интерфейс. Если это коммутируемое подключение, то необходимо настроить RRAS-сервер на автоматическую установку подключения при попытке клиента обратиться к узлу в Интернете. Ниже приведены предварительные требования к настройке подключения к Интернету с автоматическим дозвоном.
Компьютер под управлением операционной системы Windows Server 2003, оборудованный модемом или адаптером ISDN. Если установлено несколько модемов или несущих каналов, их можно использовать совместно с целью повышения пропускной способности интерфейса.
На сервере должна быть включена маршрутизация. Дополнительная информация приводилась в разделе “Инициализация служб маршрутизации”.
Назначьте интерфейсу локальной сети на сервере маршрутизации статический IP-адрес и не указывайте адрес шлюза по умолчанию. Настройте клиенты в сети на использование сервера маршрутизации в качестве принятого по умолчанию шлюза.
Провайдер услуг Интернета должен предоставить учетную запись РРР. При этом необходимо получить разрешение на подключение к Интернету с помощью маршрутизатора. Обычно это подразумевает подписание соглашения о фильтрации недопустимого трафика. Это касается NETBEUI, IPX и других транспортных протоколов, отличных от IP. Кроме этого, необходимо блокировать широковещательные пакеты, хотя это автоматически делается на пограничных маршрутизаторах провайдера услуг Интернета.
Провайдер услуг Интернета должен добавить клиентскую сеть в таблицы маршрутизации на собственных маршрутизаторах. Обычно стоимость этой услуги включается в стоимость аренды диапазона IP-адресов. Если предоставить собственные адреса, плата может быть увеличена. Обычно провайдеры услуг Интернета требуют за эту услугу достаточно высокую плату, так как без их маршрутизатора клиент не сможет подключиться к Интернету. В стоимость маршрутизации обычно входит и оплата таких служб, как DNS и электронная почта. Предлагаемый пакет можно принять, а можно от него отказаться.
Сеть должна использовать IP-подсеть с достаточным количеством общедоступных 1Р-ад- ресов для поддержки всех подключенных устройств, включая те устройства, которые никогда не будут подключаться к Интернету. Получение этих адресов может обойтись достаточно дорого.
Установка интерфейса с дозвоном по запросу
После выполнения всех предварительных условий можно приступать к настройке интерфейса с дозвоном по запросу, настройке маршрутизации в Интернете и настройке автоматической установки подключения. Начните с установки интерфейса, как описано в процедуре 20.11.
Процедура 20.11. Установка интерфейса с дозвоном по запросу
Откройте консоль Routing and Remote Access.
На дозвон по запросу должно быть настроено каждое устройство связи. Щелкните правой кнопкой мыши на пиктограмме Ports (Порты) и выберите из контекстного меню команду Properties (Свойства). Откроется окно Port Properties (Свойства порта).-
Выполните двойной щелчок на пиктограмме устройства, которое будет использоваться в качестве интерфейса с автоматическим дозвоном. Откроется окно Configure Device (Настройка устройства). .
Выберите Demand-Dial Routing Connections (Подключения с дозвоном по требованию) и щелкните на кнопке ОК.
Повторите операцию для каждого устройства, которое будет использоваться для маршрутизации с дозвоном по запросу, и закройте окно Port Properties (Свойства порта).
В окне консоли RRAS щелкните правой кнопкой мыши на пиктограмме Routing Interfaces (Интерфейсы маршрутизации) и выберите из контекстного меню команду New Demand-
Dial Interface (Новый интерфейс с дозвоном по требованию). Запустится мастер интерфейсов с дозвоном по требованию (Demand Dial Interface Wizard).
Щелкните на кнопке Next (Далее). Откроется окно Interface Name (Имя интерфейса). Введите имя, описывающее назначение маршрутизатора, например ISP_rtr.
Щелкните на кнопке Next (Далее). Откроется окно Connection Туре (Тип соединения). Если не используется виртуальная частная сеть (VPN), выберите Connect Using a Modem, ISDN Adapter (Подключаться с помощью модема или ISDN-адаптера). Если выбрать вариант VPN, мастер предоставит дополнительное окно для выбора VPN Туре (Тип VPN), в котором по умолчанию выбран вариант Automatic (Автоматический), и ввода IP-адреса или именй VPN-сервера.
Щелкните на кнопке Next (Далее). Если используется несколько устройств коммутируемого доступа, появится список Select A Device (Выберите устройство). Выберите устройство, которое будет связано с интерфейсом с дозвоном по требованию. Если необходимо использовать комбинацию из нескольких устройств, ее можно будет настроить после создания интерфейса.
Если устройство отсутствует в списке, но доступно в списке Port (Порт), удостоверьтесь, что оно настроено на дозвон по требованию.
Щелкните на кнопке Next (Далее). Откроется окно Phone Number (Номер телефона). Введите номер телефона модема (или линии ISDN), подключенного к удаленному компьютеру. Вариант Alternate (Другой) позволяет добавить дополнительные номера, которые будут использоваться в случае, если первый номер будет занят.
Щелкните на кнопке Next (Далее). Откроется окно Protocols and Security (Протоколы и безопасность). Оставьте выбранным параметр Route IP Packets On This Interface (Маршрутизировать IP-пакеты на этот интерфейс). Если для подключения к провайдеру услуг Интернет необходимо использовать сценарий регистрации, выберите переключатель Use Scripting (Использовать сценарий). Мастер предоставит окно Router Scripting (Сценарии маршрутизатора), в котором можно будет выбрать используемый сценарий.
Щелкните на кнопке Next (Далее). Откроется окно Dial Out Credentials (Регистрационные данные для дозвона). Введите имя и пароль для учетной записи, от имени которой будет устанавливаться коммутируемое подключение. Так как это подключение к Интернету, домен не потребуется (кроме случаев, когда поставщик услуг Интернета использует для аутентификации средства операционных систем Windows NT или Windows Server 2003).
Щелкните на кнопке Next (Далее). Откроется последнее окно мастера. Щелкните на кнопке Finish (Готово), чтобы добавить интерфейс и вернуться на консоль Routing and Remote Access.
Настройка маршрутизатора с дозвоном по требованию
Теперь, когда интерфейс установлен, он должен быть настроен на подключение к серверу доступа провайдера услуг Интернета (последовательность действий приводится в процедуре 20.12).
Процедура 20.12. Настройка маршрутизатора с дозвоном по требованию
Выделите пиктограмму Routing Interfaces (Интерфейсы маршрутизации). Новый интерфейс с дозвоном по умолчанию будет отображен в правой панели. Интерфейс будет иметь состояние Enabled (Включено).
Щелкните правой кнопкой мыши на пиктограмме дозвона по требованию и выберите из контекстного меню команду Properties (Свойства). На вкладке General (Общие) в группе Connect Using (Подключиться с помощью) можно выбрать дополнительные модемы или адаптеры ISDN, что благодаря объединению нескольких соединений позволит увеличить
пропускную способность канала (провайдер услуг Интернета должен поддерживать эту возможность).
Перейдите на вкладку Options (Параметры). Переключатель Connection Туре (Тип подключения) позволяет задать период времени, за который интерфейс может оставаться неактивным. Можно выбрать переключатель Persistent Connection (Постоянное подключение), но часто такая конфигурация вступает в конфликт с правилами использования услуги (если не было подписано соглашение о круглосуточном подключении).
По умолчанию для параметра Redial Attempts (Попытки повтора) установлено значение 0. Установленное значение зависит от количества необходимых дозвонов во время повышенной загрузки линий у провайдера услуг Интернет.
Перейдите на вкладку Networking (Сеть) и откройте окно Properties (Свойства) для протокола Internet Protocol.
У провайдера услуг Интернет необходимо получить фиксированный IP-адрес для внешнего интерфейса. Этот адрес будет помещен в таблицы маршрутизации и будет использоваться для доступа к сети организации. Некоторые провайдеры услуг Интернета назначают фиксированный адрес автоматически в зависимости от идентификатора регистрации (logon ID). В таком случае можно оставить выбранным переключатель Obtain Address Automatically (Получить адрес автоматически).
Щелкните на кнопке ОК, чтобы сохранить изменения и вернуться на консоль RRAS.
Проверьте подключение, щелкнув правой кнопкой мыши на интерфейсе и выбрав из контекстного меню команду Connect (Подключиться). После установки подключения и изменения его состояния на Connected (Подключено) отправьте тестовый эхо-запрос на несколько узлов в Интернете с использованием адреса или имени, что позволит убедиться в правильной работе подключения и службы преобразования имен. Если подключение не работает, воспользуйтесь стандартным коммутируемым подключением. Если стандартное коммутируемое подключение работает, проверьте используемые имя и пароль. Для этого щелкните правой кнопкой мыши на пиктограмме интерфейса с дозвоном по требованию в группе Routing Interfaces (Маршрутизируемые интерфейсы) и выберите из контекстного меню команду Credentials (Регистрационные данные).
Настройка автоматической установки подключения
После установки подключения к провайдеру услуг Интернета в таблицу маршрутизации необходимо добавить запись, которая обеспечит маршрутизацию трафика от клиентов в локальной сети на интерфейс Интернета. В таблице маршрутизации невозможцо указать все адреса в Интернете, поэтому альтернативным решением является настройка шлюза, который будет маршрутизировать весь нелокальный трафик на интерфейс с дозвоном по требованию.
Принятый по умолчанию шлюз определяется единственной записью в таблице маршрутизации. В такой записи адрес сети и маска подсети состоят из одних нулей. Для клиентов, подключающихся по коммутируемым линиям, принятые по умолчанию шлюзы настраиваются автоматически, но для интерфейсов с дозвоном по требованию этот маршрут необходимо добавить вручную.■
Принятый по умолчанию маршрут на локальную сеть был уже удален в процессе подготовки к настройке интерфейса с дозвоном по умолчанию. На этом этапе перед настройкой принятого по умолчанию шлюза необходимо убедиться в отсутствии еще одного такого же шлюза. Введите команду route print в приглашении командной строки. Не должно быть ни одной записи 0.0.0.0. Это значит, что для маршрутизатора не настроен ни один шлюз, принятый по умолчанию. Рассмотрим пример таблицы маршрутизации перед добавлением записи для шлюза:
C:\>route print
Interface List i
0x1 MSTCP Loopback interface
0xe000004 ...00 53 45 00 00 00 WAN (PPP/SLIP) Interface
0x11000002 ...00 cO 4f 53 6a f2 3Com 3C918
Active Routes:
Network Destinatior
iNetmask
Gateway
Interface Metric
10.1.0.0
255.255.0.0
10.1.1.1
10.1.1.1
1
10.1.1.1
255.255.255.255
127.0.0.1
127.0.0.1
1
10.255.255.255
255.255.255.255
10.1.1.1
10.1.1.1
1
127.0.0.0
255.0.0.0
127.0.0.1
127.0.0.1
1
127.0.0.1
255.255.255.255
127.0.0.1
127.0.0.1
■1
206.132.49.94
255.255.255.255
127.0.0.1
127.0.0.1
1
206.132.49.255
255.255.255.255
206.132.49.94
206.132.49.94
1
224.0.0.0
240.0.0.0
10.1.1.1
10.1.1.1
1
224.0.0.0
240.0.0.0
206.132.49.94
206.132.49.94
1
255.255.255.255
255.255.255.255
10.1.1.1
10.1.1.1
1
255.255.255.255
255.255.255.255
206.132.49.94
206.132.49.94
1
Persistent Routes:
None
Адреса с октетом узла 255 соответствуют широковещательным адресам для подсетей. Адрес 255.255.255.255 является общим широковещательным адресом (broadcast). Адреса 224.0.0.0 соответствуют подсетям многоадресной отправки (multicast). В процедуре 20.13 описано, как настроить интерфейс на автоматическую установку подключения.
Процедура 20.13. Настройка автоматической установки подключения
На консоли RRAS разверните раздел Local Server (Локальный сервер) и найдите пиктограмму IP Routing (IP-маршрутизация).
Щелкните правой кнопкой мыши на Static Routes (Статические маршруты) и выберите из контекстного меню команду Create A New Static Route (Создать новый статический маршрут). Откроется окно Static Route (Статический маршрут), пример которого показан на рис. 20.33.
В поле Interface (Интерфейс) выберите созданный интерфейс с дозвоном по умолчанию.
В полях Destination (Назначение) и Network Mask (Маска подсети) введите одни нули. Это позволит назначить интерфейс в качестве маршрута, принятого по умолчанию. В таком
127.0.0.0127.0.0.1 192.168.0.0192 168 0.0192.1660.1 192.168.0.157 192.168.0.255 192.168.0.255224.0.0.0224.0.0.0 255.255.255.255 255.255.255.255127.0.0.0127.0.0.1 192.168.0.0192 168 0.0192.1660.1 192.168.0.157 192.168.0.255 192.168.0.255224.0.0.0224.0.0.0 255.255.255.255 255.255.255.255255.0.0.0255.255.255.255255.255.255.0255.255.255.0255.255.255.255255.255.255.255255.255.255.255 255.255.255255 240.0.0.0 240.0.0.0255.255.255.255255.255.255.255255.0.0.0255.255.255.255255.255.255.0255.255.255.0255.255.255.255255.255.255.255255.255.255.255 255.255.255255 240.0.0.0 240.0.0.0255.255.255.255255.255.255.255127.0.0.1 127.0.0.1 192.168.0.157 192.168.0.1 127.0.0.1 127.0.0.1х 192.168.0.157 192.168.0.1 192168.0.157 192168.0.1 192.168.0.157 192.166.0.1127.0.0.1 127.0.0.1 192.168.0.157 192.168.0.1 127.0.0.1 127.0.0.1х 192.168.0.157 192.168.0.1 192168.0.157 192168.0.1 192.168.0.157 192.166.0.1Loopback Loopback Local Atea С... Local Area C. .. Loopback Loopback Local Area C... Local Area C... Local Area C... Local Area C... Local Area C... Local Area C...Loopback Loopback Local Atea С... Local Area C. .. Loopback Loopback Local Area C... Local Area C... Local Area C... Local Area C... Local Area C... Local Area C...1Local1Local3JLocal20Local20Local30Local30Local20Local30Local20Local1Local1Local1Local1Local3JLocal20Local20Local30Local30Local20Local30Local20Local1Local1Local
127.0.0.0
127.0.0.1 192.168.0.0
192 168 0.0
192.1660.1 192.168.0.157 192.168.0.255 192.168.0.255
224.0.0.0
224.0.0.0 255.255.255.255 255.255.255.255
127.0.0.0
127.0.0.1 192.168.0.0
192 168 0.0
192.1660.1 192.168.0.157 192.168.0.255 192.168.0.255
224.0.0.0
224.0.0.0 255.255.255.255 255.255.255.255
255.0.0.0
255.255.255.255
255.255.255.0
255.255.255.0
255.255.255.255
255.255.255.255
255.255.255.255 255.255.255255 240.0.0.0 240.0.0.0
255.255.255.255
255.255.255.255
255.0.0.0
255.255.255.255
255.255.255.0
255.255.255.0
255.255.255.255
255.255.255.255
255.255.255.255 255.255.255255 240.0.0.0 240.0.0.0
255.255.255.255
255.255.255.255
127.0.0.1 127.0.0.1 192.168.0.157 192.168.0.1 127.0.0.1 127.0.0.1
х 192.168.0.157 192.168.0.1 192168.0.157 192168.0.1 192.168.0.157 192.166.0.1
127.0.0.1 127.0.0.1 192.168.0.157 192.168.0.1 127.0.0.1 127.0.0.1
х 192.168.0.157 192.168.0.1 192168.0.157 192168.0.1 192.168.0.157 192.166.0.1
Loopback Loopback Local Atea С... Local Area C. .. Loopback Loopback Local Area C... Local Area C... Local Area C... Local Area C... Local Area C... Local Area C...
Loopback Loopback Local Atea С... Local Area C. .. Loopback Loopback Local Area C... Local Area C... Local Area C... Local Area C... Local Area C... Local Area C...
1Local
1Local
3JLocal
20Local
20Local
30Local
30Local
20Local
30Local
20Local
1Local
1Local
1Local
1Local
3JLocal
20Local
20Local
30Local
30Local
20Local
30Local
20Local
1Local
1Local
Puc. 20.33. Окно Static Route (Статический маршрут), в котором показан маршрут шлюза, принятого по умолчанию
случае поле Gateway (Шлюз) окажется неактивным, поскольку интерфейсы с дозвоном по умолчанию не используют шлюзы.
Оставьте в поле Metric (Метрика) значение 1.
Убедитесь, что установлен флажок Use This Route То Initiate Demand-dial Connections (Использовать этот маршрут для дозвона по требованию). Это заставит службу маршрутизации и удаленного доступа устанавливать подключение при появлении трафика, который предназначен для узлов за пределами локальной сети.
Щелкните на кнопке ОК, чтобы сохранить изменения и вернуться на консоль RRAS. В правой панели появится новый статический маршрут.
После этого необходимо проверить подключение. На клиенте, который настроен на использование маршрутизатора с дозвоном по требованию в качестве шлюза, отправьте тестовый эхо-пакет на внешний интерфейс сервера. После успешного получения ответа на запрос включите постоянную отправку тестовых эхо-пакетов на адрес узла в Интернете. Для этого можно воспользоваться командой ping -t 192.80.3.105. Подождите, пока будет установлено подключение к провайдеру услуг Интернета.
После установки подключения должны прийти ответы на тестовые эхо-пакеты. Если запрос завершится неудачно, воспользуйтесь утилитой tracert или pathping для обнаружения узла, на котором отказывает подключение. Если ответ на тестовый эхо-пакет возвращается от маршрутизатора с дозвоном по требованию, но не возвращается из Интернета, проверьте правильность настройки таблицы маршрутизации на маршрутизаторе провайдера услуг Интернета. Не разрывайте соединение во время диагностики.
Если не был выбран переключатель Persistent Connection (Постоянное подключение), рано или поздно будет превышен период, на время которого соединение может оставаться неактивным, и соединение будет автоматически разорвано. При модемном соединении пользователей необходимо предупредить о паузе в несколько секунд, которая возникает во время согласования параметров соединения между модемами. Если используется подключение ISDN, возникает противоположная проблема. Не стоит оставлять подключение ISDN включенным постоянно. С этим согласится любой, кто получил счет в 2000 долларов в первый же месяц после установки линии ISDN. Следите за активностью маршрутизатора с дозвоном по требованию, пока не станет ясно, что сюрпризы исключены.
Одно замечание: при такой конфигурации маршрутизатора с дозвоном по требованию сеть не защищена от атаки из Интернета. При изучении технологии NAT в следующем разделе будет учитываться возможность включения брандмауэра Internet Connection Firewall (ICE), который предоставляется в составе операционной системы Windows Server 2003. Эта конфигурация более предпочтительна, чем маршрутизатор с дозвоном по требованию, рассмотренный в этом разделе. Если использование технологии NAT нежелательно, брандмауэр можно установить перед маршрутизатором с дозвоном по требованию.
Настройка шлюза в Интернет с использованием технологии NAT
На рис. 20.34 показана схема типичной сети малого офиса. В этом примере единственный сервер под управлением Windows Server 2003 поддерживает работу всех сетевых служб, включая обеспечение шлюза в Интернете.
Изучая эту схему, можно удивиться, почему создатель сети не установил в качестве шлюза специальное решение SOHO для небольших офисов. Одной из причин является стоимость. Дополнительное оборудование совсем не бесплатное, а многие небольшие офисы исключительно чувствительны к стоимости решения. Более важной причиной является богатство возможностей, предоставляемых операционной системой Windows Server 2003. В возможно-
Общий доступ к Интернету и брандмауэрОбщий доступ к Интернету и брандмауэрСервер терминаловСервер терминаловЧастная IP-сеть192.168.0.0/24Частная IP-сеть192.168.0.0/24Сервер электронной почтыСервер электронной почтыКлиенты из Интернета получают доступ к внутренним узлам через брандмауэр ICF с помощью туннеля NATКлиенты из Интернета получают доступ к внутренним узлам через брандмауэр ICF с помощью туннеля NATРис. 20.34. Типичная сеть малого офиса с использованием сервера Windows Server 2003 в качестве шлюзаРис. 20.34. Типичная сеть малого офиса с использованием сервера Windows Server 2003 в качестве шлюзаFTP-серверFTP-серверWeb-сервер (HTTP)Web-сервер (HTTP)
Общий доступ к Интернету и брандмауэр
Общий доступ к Интернету и брандмауэр
Сервер терминалов
Сервер терминалов
Частная IP-сеть
192.168.0.0/24
Частная IP-сеть
192.168.0.0/24
Сервер электронной почты
Сервер электронной почты
Клиенты из Интернета получают доступ к внутренним узлам через брандмауэр ICF с помощью туннеля NAT
Клиенты из Интернета получают доступ к внутренним узлам через брандмауэр ICF с помощью туннеля NAT
Рис. 20.34. Типичная сеть малого офиса с использованием сервера Windows Server 2003 в качестве шлюза
Рис. 20.34. Типичная сеть малого офиса с использованием сервера Windows Server 2003 в качестве шлюза
FTP-сервер
FTP-сервер
Web-сервер (HTTP)
Web-сервер (HTTP)
сти операционной системы входят брандмауэр, гибкое перенаправление портов, возможность использования нескольких общедоступных IP-адресов и практически неограниченное количество поддерживаемых клиентов.
Общедоступный IP-адрес 24.24.24.3/25 RRAS-сервер под управлением Windows Server 2003
Использование единственного сервера для сетевых служб, файловых служб и служб печати нельзя назвать самым отказоустойчивым решением, но владельцы небольших компаний привыкли рассматривать решения с точки зрения минимизации стоимости, а не с точки зрения возможного восстановления. В таких компаниях обычно критически важные серверы установлены в тех же помещениях, где ведется основная деятельность, а погрузочно-разгрузочные работы проводятся на стоянке, которая используется для парковки личных автомобилей. Большинство владельцев малого бизнеса сравнивают стоимость и риск и приходят к решению использовать единственный сервер. Для смягчения последствий отказа сервера можно выделить одну или две рабочие станции под управлением Windows ХР для использования в качестве шлюзов. Рабочая станция под управлением Windows ХР неплохо справляется с этой задачей, а для перенастройки необходимо несколько секунд и второй сетевой адаптер.
Настройка операционной системы Windows Server 2003 в качестве шлюза в Интернет требует установки дополнительного сетевого интерфейса, который будет подключаться к Интернету (это может быть сетевой кабель, подключенный к кабельному модему или адаптеру
DSL, а также коммутируемое подключение с дозвоном по запросу), и настройки следующих компонентов службы маршрутизации и удаленного доступа (RRAS). "
Служба маршрутизации
Служба трансляции сетевых адресов (служба NAT)
Служба брандмауэра
Если внешний интерфейс подключается к поставщику DSL, требующему отдельных подключений, настройка шлюза требует настройки протокола PPPoE (Point-to-Point Protocol over Ethernet) в операционной системе Windows Server 2003. Дополнительная информация приводилась в разделе “Протокол РРРоЕ” этой главы.
Функциональное описание трансляции сетевых адресов
Если показанный на рис. 20.34 сервер настроить в качестве стандартного маршрутизатора, каждый клиент в локальной сети должен будет получить общедоступный IP-адрес. При этом возникают две проблемы. Одна проблема связана с безопасностью. Клиенты будут открыты для всей сети Интернет, из которой могут атаковать злоумышленники.
Вторая проблема связана с архитектурой. Количество свободных IP-адресов стремительно сокращается. Протокол IPv6 должен помочь в решении этой проблемы, а также проблемы безопасности, но на развертывание протокола и устройств IPv6 уйдет несколько лет.
На данный момент технология трансляции сетевых адресов (NAT) решает обе проблемы с помощью хитрости, которая понравится любому подростку. Эта технология позволяет преобразовать один IP-адрес в другой IP-адрес, разрешая клиентам выглядеть по-разному в общедоступной и частной сетях. Трансляция сетевых адресов описана в документах RFC 1597, “Address Allocation for Private Internets”, и RFC 1631, “Network Address Translation (NAT)”.
Преобразование адресов
Для использования технологии NAT необходимо выделить IP-адреса из одного из зарезервированных диапазонов, выделенных для использования в частных сетях. Маршрутизаторы Интернета настроены на блокирование любых сообщений из этих диапазонов.
Сети класса А: 10.0.0.0-10.255.255.255
Сети класса В: 172.16.0.0-172.31.255.255
Сети класса С: 192.168.0.0-192.168.255.255
Производительность широкополосного доступа
Для получения самой актуальной информации о методах повышения производительности широкополосных подключений можно обратиться на сайт www. speedguide. net.
При планировании реализации технологии NAT администратор может выбрать любой диапазон частных адресов. Самым гибким является диапазон сетей класса А, поскольку она поддерживает максимальное количество подсетей и хостов, но при использовании небольшой сети диапазон сетей класса “С” проще в управлении.
Рассмотрим, как работает трансляция сетевых адресов. Предположим, что клиент находится на стороне частной подсети от устройства, поддерживающего трансляцию сетевых адресов. Пусть клиент устанавливает соединение с Web-сервером, который находится с общедоступной стороны от устройства. Клиент отправляет HTTP-трафик на Web-сервер на стандартный ТСР-порт 80. При этом клиент назначает свободный порт, на который он будет
ожидать ответа сервера. Порт отправителя указывается в дейтаграмме, которая отправляется на Web-сервер. Этого достаточно, чтобы Web-сервер знал, кому отвечать на запрос.
При попадании HTTP-пакета на устройство трансляции сетевых адресов NAT-устройство изменяет IP-заголовок, подставляя собственный общедоступный IP-адрес вместо адреса клиента. После этого пакет отправляется по указанному клиентом адресу.
Web-сервер отвечает по указанному в пакете IP-адресу, что приводит к возврату ответа на открытый интерфейс NAT-устройства. Служба NAT подставляет в пакет IP-адрес клиента и отправляет пакет в частную сеть,,где пакет маршрутизируется на интерфейс клиента.
Преобразование портов
При истинной трансляции сетевых адресов настраивается однозначное соответствие между общедоступными и част*ными адресами. Это защищает личность клиента, но не минимизирует использование общедоступных IP-адресов. Это задача другого механизма, который называется трансляция портов (Port Address Translation — РАТ). Служба NAT в операционной системе Windows Server 2003 позволяет реализовать как трансляцию сетевых адресов, так и трансляцию портов.
Чем же трансляция сетевых адресов отличается от трансляции портов? При отправке запроса с клиента в частной сети на узел, который находится с общедоступной стороны от NAT- устройства, это устройство не только подставляет собственный IP-адрес, но и вместо указанного клиентом номера TCP-порта указывает случайный номер собственного порта. Оригинальный IP-адрес и номер порта сохраняются в специальной таблице.
При ответе Web-сервера HTTP-пакет возвращается на внешний интерфейс NAT-устройства на указанный этим устройством номер порта. Устройство трансляции сетевых адресов подставляет в пакет информацию о клиенте и отправляет пакет в частную сеть.
Таким образом, разница между трансляцией сетевых адресов (NAT) и трансляцией портов (Port Address Translation — РАТ) заключается в использовании общедоступного адреса. При использовании истинной NAT потребуется получение общедоступного адреса для каждого клиента в пределах частной сети. При использовании трансляции портов несколько клиентов могут использовать один общедоступный 1Р-адрес.
В службе RRAS Windows Server 2003, как и в большинстве NAT-устройств используется комбинация трансляции сетевых адресов и трансляции портов. Для просмотра таблицы преобразования портов и адресов в операционной системе Windows Server 2003 можно открыть консоль RRAS, щелкнуть правой кнопкой мыши на NAT-интерфейсе и выбрать из контекстного меню пункт Show Mappings (Показать таблицу преобразования).
Если общедоступный интерфейс RRAS-сервера имеет более одного IP-адреса, служба NAT перенаправляет IP-адреса частных клиентов на каждый IP-адрес общедоступного интерфейса, пока не закончатся общедоступные адреса. После этого для оставшихся клиентов используется трансляция портов. Иногда этот механизм называется NAT oyerloading. С точки зрения производительности нет никакой разницы между использованием трансляции сетевых адресов и трансляции портов.
Редакторы NAT
Кроме простой трансляции IP-адресов в заголовках пакетов, для трансляции сетевых адресов может потребоваться “разбор" TCP- или UDP-пакетов для обнаружения IP-адреса, указанного приложением.
Например, при отправке тестового эхо-пакета на удаленный узел в ICMP-пакете указываются IP-адреса отправителя и получателя. Это касается и FTP-команды port, а также других приложений. Кроме этого, существуют ситуации, когда за пределами полезной нагрузки пакета TCP или UDP используется маршрутизация от источника (source addressing). Так бывает при использовании протокола PPTP (Point-to-Point Tunneling Protocol), в котором протокол GRE обеспечивает передачу IP-пакетов внутри дейтаграмм TCP и UDP, а номер порта
указывается внутри пакета. (Встроенные IP-адреса при использовании протокола L2TP поверх IPSec шифруются, что делает их недоступными для технологии NAT.) В механизме трансляции сетевых адресов Windows Server 2003 используется информация, которая хранится в специальных конфигурационных файлах. Эти файлы называются NAT Editor и определяют расположение информации об IP-адресе в пакете приложения. Каждое приложение нуждается в собственном файле NAT Editor. В операционной системе Windows Server 2003 предоставляются файлы NAT Editor для протоколов FTP, ICMP и PPTP. Файлы NAT Editor для протоколов SNMP, LDAP, Microsoft COM и RPC в составе операционной системы не предоставляются.
Входящие подключения при использовании NAT
Когда подключение к общедоступному хосту инициируется клиентом из частной сети, служба NAT будет пропускать входящий трафик из глобальной сети. Если запрос на установку соединения поступает из общедоступной сети, механизм NAT будет блокировать передачу данных.
Могут возникать ситуации, когда клиентам в общедоступной сети необходимо подключаться к серверу в частной сети. В операционной системе Linux такая конфигурация называется перенаправлением портов (port forwarding). ■
Маршрутизация входящего трафика внутрь частной сети посредством технологии NAT похожа на попытку провести гостя на ужин Государственного департамента США. Прием только по приглашениям. Трансляция для входящего трафика осуществляется только по принципу “порт-порт”. Например, если в частной сети установлен Web-сервер, который должен быть доступен в общедоступной сети, маршрутизатор можно настроить на прием входящих соединений, направленных на порт 80 с последующей их маршрутизацией на выбранный Web-сервер. Если пользователь в общедоступной сети введет в браузере IP-адрес сервера NAT, то браузер будет получать страницы, хранящиеся на сервере внутри частной сети.
■вЖИ!№ля
H*Mh*fiew*f | Mtaafat 6«И*«ИР* |кмр ]
SdKt Ша «нее» onjaxa new* to Niidhyiu want to w*de accw lartotoneiuieiL Tl»wl<»aetoeie«iflwlnjeurbaeel«owat
□ Internet Mail Access Protocol Version 3 (IMAP3)
' □ Internet Mail Access Protocol Version 4 (IMAP4)
Internet Mail Server (SMTP)'
IP Security (IKE)
Post-Office Protocol Version 3 (POP3)1
О Remote Desktop
Secure Web Server (HTTPS)—
' ehet ServerI
VPN Gateway (L2TP/IPSec • runnrig on this server)*|
Ш—-I AT
Puc. 2035. Окно свойств общедоступного интерфейса NA Т. Показаны службы, которые можно настроить на преобразование общедоступных адресов в частные адреса
Служба RRAS поддерживает два метода настройки перенаправления портов с помощью NAT. Самым простым способом является установка соответствия между портом общедоступного интерфейса и сервером и портом в частной сети. Для этого необходимо открыть вкладку Services and Ports (Службы и порты) в окне свойств общедоступного интерфейса (рис. 20.35).
Если необходимо опубликовать Web-сервер из частной сети на открытом интерфейсе, установите флажок Web Server (Web-сервер). Откроется окно Edit Service (Редактировать службу), в котором можно указать частный адрес и номер порта.
Однозначное соответствие между внешними портами и внутренними серверами отлично работает, пока в частной сети для каждой службы существует только один Сервер. Но что делать, если необходимо опубликовать три Web-сервера, расположенных в частной сети? Можно воспользоваться другим номером порта на открытом интерфейсе, но это приведет к использованию нестандартных портов и усложнению подключения для клиента.
Более подходящим решением является получение диапазона адресов от провайдера услуг Интернет с последующей настройкой общедоступного NAT-интерфейса на использование этого диапазона для входящих запросов. После этого на общедоступном интерфейсе можно указать IP-адрес и номер порта, которые будут соответствовать каждому серверу и службе в частной сети.
Для назначения адресов внешнему интерфейсу можно воспользоваться вкладкой Address Pool (Пул адресов) в окне свойств общедоступного интерфейса.
Управление ICMP-сообщениями
Протокол ICMP используется для взаимодействия между клиентами и хостами и обеспечивает выполнение целого ряда задач. К сожалению, злоумышленники часто используют этот протокол для нарушения работы серверов или организации атак типа "отказ в обслуживании". В операционной системе Windows Server 2003 предоставляется возможность выбора типов ICMP-сообщений, на которые должен отвечать общедоступный интерфейс. В окне свойств общедоступного интерфейса доступна вкладка ICMP, на которой перечислены сообщения и соответствующие функции (рис. 20.36).
;| nt al Area Connection 3 Properties' £
М*ТДееЯ#«ы|/И^Р«»| SwefreiSA* CMP | ,
fa rtaRMtaHntte Hemet to which tatm^^ч
Alow the fak**S
0 Incoming timestamp request
0 Incoming mask request
0 Incoming router request
□ Outgoing destination unreachable
0 Outgoing source quench
□ Outgoing perameter problem
я 0 Outgoing time exceeded
□ Redirect
Puc. 20.36. Окно свойств общедоступного интерфейса. На вкладке ICMP отображается список ICMP-сообщений, на которые будет выдаваться ответ при установленном соответственно флажке
Если не удается получить у провайдера непрерывный диапазон IP-адресов, адреса можно вводить по одному в виде отдельных диапазонов адресов, состоящих из одного адреса. Для создания новых соответствий портов не требуется перезапуск службы RRAS.
Список действий для развертывания NAT
Рассмотрим основные моменты, касающиеся NAT. О них стоит помнить перед установкой и настройкой этой службы.
Трансляция сетевых адресов требует использования отдельной сети IP-адресов для локальной сети. Для этого может использоваться частное пространство IP-адресов (предпочтительный вариант) или уникальных общедоступных адресов, предоставленных организации.
Механизм трансляции сетевых адресов поддерживает создание временного соответствия между портами TCP/UDP и частными IP-адресами. Если завершить работу сервера, это соответствие будет утеряно и клиентам придется повторно устанавливать подключение к удаленным узлам.
Механизм трансляции сетевых адресов поддерживает использование нескольких общедоступных IP-адресов для перенаправления портов на внутренние ресурсы сети. Эта возможность оказывается полезной, если внутри сети существует несколько серверов, поддерживающих работу одной и той же службы.
Если используется приложение, вставляющее IP-адреса внутрь TCP- или UDP-пакета или добавляющее информацию об IP-адресе в пакет другого протокола, для правильной трансляции адресов придется настроить NAT Editor. В противном случае это приложение будет некорректно работать при использовании трансляции сетевых адресов.
Необходимо настроить сетевые клиенты на использование маршрутизатора с трансляцией сетевых адресов в качестве шлюза в Интернет. Проще всего это сделать с помощью DHCP, но можно и вручную настроить параметры протокола IP на клиентских компьютерах.
Совместный доступ в Интернет
Создание шлюза в Интернет с использованием трансляции сетевых адресов на основе службы RRAS требует нетривиальных способностей от системного администратора. При этом необходимо знать, как использовать службу RRAS на маршрутизаторе, как настроить NAT и интерфейсы, как настроить клиенты для использования сервера в качестве шлюза, а также как обрабатывать запросы DNS от клиентов из частной сети.
Для небольшого офиса с единственным сервером под управлением Windows Server 2003 существует простой способ настройки шлюза. Необходимо установить два флажка и перезагрузить клиенты. Такое удобство предоставляется в виде возможности общего доступа к Интернету (Internet Connection Sharing — ICS). Функция ICS доступна на рабочих станциях Windows ХР, серверах и рабочих станциях Windows 2000 и на рабочих станциях под управлением Windows ME или Windows 98 Second Edition.
Функция ICS включается в окне Network Connections (Сетевые подключения) с помощью переключателя на вкладке Advanced (Дополнительно) в окне свойств внешнего интерфейса (рис. 20.37).
Функция ICS реализована в виде нескольких служб, которые автоматизируют создание шлюза в Интернет. Рассмотрим, что происходит при включении ICS на внешнем интерфейсе. ■ IP-адрес интерфейса частной сети автоматически меняется на 192.168.0'. 1. Этот адрес невозможно изменить, обойти или переопределить. (В операционной системе Windows 98 или Windows ME для этой цели можно изменить параметры системного реестра, но в операционных системах Windows Server 2003 и Windows ХР такая модификация недоступна.) Если сеть уже настроена на использование другого диапазона частных адресов, придется ее перенастроить.
После этого коммутируемый внешний интерфейс настраивается в качестве маршрутизатора с дозвоном по требованию.
Запускается небольшая служба DHCP, которая раздает адреса из диапазона 192.168.0.0/24. Эта служба управляется библиотекой Ipnathplt. dll и не является полноценной реализацией сервера DHCP.
Устанавливается небольшая служба прокси DNS, которая также управляется из Ipnathplt. dll. Этот прокси-сервер передает запросы DHS на DNS-сервер, указанный в параметрах внешнего интерфейса. Обычно адрес этого DNS-сервера предоставляется провайдером услуг Интернета по протоколу DHCP.
Рис. 20.37. Окно свойств внешнего интерфейса на сервере с несколькими сетевыми адаптерами. На вкладке Advanced (Дополнительно) показаны флажки для включения совместного доступа к Интернету (ICS) и брандмауэра (ICF)
Брандмауэр подключения к Интернету
Хотя трансляция сетевых адресов является ключевым компонентом брандмауэра, сам по себе механизм трансляции сетевых адресов не является брандмауэром. Другими словами, механизм трансляции не принимает активного участия в блокировании трафика, нацеленного на порты внешнего интерфейса RRAS-сервера. В ответ на появление встроенного брандмауэра в ядре Linux компания Microsoft добавила в операционные системы Windows Server 2003 и Windows ХР новую функцию, которая называется брандмауэр подключения к Интернету (Internet Connection Firewall — ICF).
По сравнению с более сложными (и дорогими) решениями для создания брандмауэров, например, Microsoft Internet Security and Acceleration (ISA) Server или Checkpoint Firewall, функция ICF оказывается достаточно слабой. Эта функция не обладает методами управления в пределах предприятия и расширенными возможностями ведения журналов, которые можно ожидать от решения для брандмауэра масштаба предприятия, но для своей ниши (брандмауэр для ICS) эта функция вполне подходит.
ICS и DHCP
Можно заметить, что неконтролируемое использование доступа по ICS в локальной сети может привести к появлению нескольких DHCP-серверов, выдающих адреса из диапазона 192.168. Чтобы избежать такой ситуации, ICS-сервер использует пакет DHCPINFORM для обнаружения других серверов DHCP в пределах сети. Если в сети присутствуют другие серверы DHCP, ICS-сервер отключается и вносит соответствующую запись в журнал событий.
Кроме этого, функция DHCP в составе ICS-сервера не отвечает на запросы выделения адресов от службы RRAS. Это защищает клиентов коммутируемого доступа от получения адресов от ICS-сервера.
На момент написания книги в брандмауэре ICF не было выявлено тактических или стратегических уязвимых мест. Служба предоставляет только часть тех возможностей, которые можно ожидать от мощного брандмауэра, но ее достаточно для блокирования доступа к компьютеру со стороны Интернета. При использовании ICF выполняется противодействие процедурам сканирования портов с помощью стандартных инструментов, применяемых для таких задач. Например, интерфейс оказался закрытым при сканировании с помощью Legion, LanGuard или страницы ShieldsUp на сервере Gibson Research по адресу www. grc . сот.
Функцию ICF можно включить двумя способами. Если используется трансляция сетевых адресов, эта возможность доступна для частного интерфейса на консоли RRAS. Если используется ICS, эта возможность доступна на той же вкладке, на которой включается использование ICS.
Настройка NAT на консоли RRAS
Настройка трансляции сетевых адресов на шлюзе для доступа в Интернет значительно проще настройки стандартного маршрутизируемого подключения, так как в этом случае не требуется помощь провайдера услуг Интернета. Ниже представлен краткий перечень подготовительных операций.
Если используется DNS-сервер, являющийся авторитетным (SOA) для общедоступного пространства имен DNS, то этот DNS-сервер необходимо перенести в общедоступную сеть или отобразить порт 53 для перенаправления запросов на DNS-сервер. Если перенести сервер DNS в частное адресное пространство и не отобразить оригинальный адрес на открытом интерфейсе, придется связаться с провайдером услуг Интернета или оператором домена верхнего уровня для изменения адреса сервера преобразования имен. Это относится ко всем серверам, которые переносятся в частную сеть, например к серверу электронной почты (этот сервер использует записи MX в базе данных DNS).
На шлюзе должно быть установлено как минимум два сетевых интерфейса: один — для частной сети, а второй — для общедоступной сети. Общедоступный интерфейс может быть коммутируемым (модем или ISDN) или выделенным.
Не используйте контроллер домена в качестве маршрутизатора с трансляцией сетевых адресов. В этом случае могут возникать ошибки, особенно в работе служб DNS и LDAP.
Служба RRAS должна быть настроена на обеспечение маршрутизации.
Коммутируемый интерфейс должен быть настроен на дозвон по требованию. Для этого откройте консоль RRAS и в окне Port Properties (Свойства порта) выполните двойной щелчок на устройстве. Откроется окно Configure Device (Настройка устройства). Установите флажок Demand-dial Routing Connections (Маршрутизируемые подключения с дозвоном по требованию).
Политики некоторых провайдеров услуг Интернета запрещают подключение к их сети маршрутизаторов с функцией трансляции сетевых адресов. Убедитесь, что нарушение политики не приведет к прекращению предоставления услуг.
При выполнении всех предварительных условий можно приступать к настройке шлюза.
Настройка трансляции сетевых адресов и ICF
Сначала убедитесь, что подключение к Интернету на сервере шлюза полностью работоспособно. После этого выберите интерфейсы для трансляции сетевых адресов и настройте их, как описано в процедуре 20.14.
Процедура 20.14. Настройка трансляции сетевых адресов и ICF
Откройте консоль, Routing and Remote Access.
Разверните дерево до раздела IP Routing (Маршрутизация IP). Найдите пиктограмму Network Address Translation (Трансляция сетевых адресов).
Щелкните правой кнопкой мыши на пиктограмме Network Address Translation (Трансляция сетевых адресов) и выберите из контекстного меню команду New Interface (Создать интерфейс). Откроется окно New Interface For Network Address Translation (Создать интерфейс для трансляции сетевых адресов).
Выполните двойной щелчок на общедоступном интерфейсе. Откроется окно Properties (Свойства).
Выберите переключатель Public Interface (Общедоступный интерфейс) и установите флажок Translate TCP/UDP Headers (Транслировать заголовки TCP/UDP-пакетов) и флажок Enable Firewall On This Interface (Запустить брандмауэр на этом интерфейсе). Щелкните на кнопке ОК, чтобы сохранить внесенные изменения.
Выполните двойной щелчок на интерфейсе частной сети. Откроется окно Properties (Свойства). Выберите переключатель Private Interface (Интерфейс частной сети) и щелкните на кнопке ОК.
Рис. 20.38. Свойства трансляции сетевых адресов. Вкладка Address Assignment (Назначение адреса), на которой показаны параметры настройки DHCP Allocator
Если используется протокол DHCP, измените его параметры для предоставления клиентам IP-адреса сервера NAT. Если сервер DHCP не используется, но будет использоваться в связи с включением трансляции сетевых адресов, настройку DHCP можно упростить, включив DHCP Allocator в свойствах трансляции сетевых адресов. Кроме этого, здесь можно указать параметры прокси-сервера для запросов DHCP.
Откройте окно свойств службы NAT и перейдите на вкладку Address Assignment (Назначение адреса), окно которой показано на рис. 20.38.
Самым простым вариантом являетсй установка флажка Automatically Assign (Назначать автоматически) и принятие указанного по умолчанию адреса 192.168.0.0/24. Служба ICS выдает адреса в этом же диапазоне.
Перейдите на вкладку Name Resolution (Преобразование имен) и установите флажок Resolve IP Addresses for Clients Requesting DNS (Преобразовывать IP-адреса для клиентов DNS). После этого запросы DNS будут отправляться на DNS-сервер, настроенный для внешнего интерфейса. Убедитесь в доступности DNS-сервера до внесения этого.изменения.
Включение ICS и ICF
После настройки надежного подключения к Интернету на общедоступном интерфейсе включите службу ICS, выполнив последовательность действий, которая приведена в процедуре 20.15.
Процедура 20.15. Включение ICS и ICF
Убедитесь, что никто из пользователей не открыл файлы или не подключился к серверу. Это необходимо, поскольку следующие операции приведут к изменению частного IP- адреса на внутреннем интерфейсе сервера. Для проверки установленных соединений воспользуйтесь консолью Computer Management (Управление компьютером), Compmgmt. msc.
Откройте окно Network Connections (Сетевые подключения).
Откройте окно Properties (Свойства) для общедоступного интерфейса.
Откройте вкладку Advanced (Дополнительно).
В группе Internet Connection Firewall (Брандмауэр Windows) выберите переключатель Protect Му Computer (Защитить мой компьютер).
В группе Internet Connection Sharing (Совместный доступ к Интернету) выберите Allow Other Network Users to Connect (Позволять подключения другим пользователям).
Щелкните на кнопке ОК для сохранения изменений. Система выдаст предупреждение об изменении IP-адреса на!92.168.0.1ио возможном отключении от локальной сети. Щелкните на кнопке Yes (Да) и продолжайте установку ICS. Отключение связи с сетью является временным, пока клиенты не получат новые сетевые адреса с помощью службы DHCP.
На обновление потребуется несколько секунд. Воспользуйтесь командой ipconfig для проверки I P-адреса на сетевом интерфейсе. Должен быть указан адрес 192.168.0.1.
На каждом клиенте DHCP необходимо ввести команды ipconfig /release и ipconf ig / renew (на клиентах Windows Эх можно воспользоваться командой winipcfg). Это заставит клиентов DHCP получить новые адреса в подсети 192.168. Воспользуйтесь командой ping и убедитесь, что клиент имеет доступ к шлюзу. Откройте окно Network Connections (Сетевые подключения) на рабочей станции под управлением Windows ХР и убедитесь в наличии пиктограммы Internet Gateway (Шлюз Интернета).
Если для подключения к Интернету используется линия ISDN, первое время проследите за динамикой использования подключения. Возможности ICS должны обеспечивать разрыв соединения после периода неактивности, но никогда нельзя быть уверенным в пользователях, которые получили подключение к Интернету. Если соединение не разрывается, воспользуйтесь утилитой Network Monitor на сервере для просмотра передаваемых по сети данных.
Настройка сетевого моста
Если установить беспроводный сетевой адаптер на портативный компьютер или сегмент Phoneline в офисе, эти устройства придется подключать к основной сети. Пример такого подключения показан на рис. 20.39.
интерфейсами, выступающий в роли сетевого мостаинтерфейсами, выступающий в роли сетевого мостаПодключение VPN к главному офисуПодключение VPN к главному офисуСервер сМодем DSLилинесколькимикабельный модемСервер сМодем DSLилинесколькимикабельный модемсетевой адаптер PC Cardсетевой адаптер PC Card
интерфейсами, выступающий в роли сетевого моста
интерфейсами, выступающий в роли сетевого моста
Подключение VPN к главному офису
Подключение VPN к главному офису
Сервер сМодем DSLили
несколькимикабельный модем
Сервер сМодем DSLили
несколькимикабельный модем
сетевой адаптер PC Card
сетевой адаптер PC Card
Рис. 2039. Офис с несколькими физическими сетями, связанными с помощью моста в виде сервера под ■управлением Windows Server2003
Операционные системы Windows Server 2003 Standard Edition и Windows XP предоставляют возможность настройки маршрутизации или создания моста для этих сегментов. Проблема при настройке маршрутизации в сети малого офиса заключается в необходимости создания нескольких IP-подсетей. Это может усложнить простую конфигурацию. Если необходимо сохранить простоту решения, можно воспользоваться мостом.
В составе операционных систем Windows Server 2003 Standard Edition и Windows XP предоставляется служба Network Bridge, которая может использоваться вместо маршрутизации для связи различных сегментов сети. (Эта функция недоступна в Windows Server 2003 Enterprise Edition и Windows Server 2003 Datacenter Edition.) В операционной системе Windows сетевой мост рассматривается как отдельное устройство с собственным интерфейсом и IP-адресом. Это позволяет упростить конфигурацию при использовании сервера с несколькими сетевыми адаптерами.
Windows ХР и маршрутизация
Рабочая станция под управлением Windows ХР может использоваться в качестве маршрутизатора (перенаправление IP), но в пользовательском интерфейсе соответствующие элементы управления недоступны. Для включения этой возможности нужно внести изменения в системный реестр:
Раздел: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
Запись: IPEnableRouter
Значение: 1 (reg_dword)
Обзор функции моста
Как известно, мост позволяет соединить интерфейсы на канальном уровне в сетевой модели OSI. На этом уровне имеет смысл только назначенный сетевому интерфейсу физический МАС- адрес. Чтобы выбрать точку назначения кадров, мост использует алгоритм связующего дерева.
Такое дерево является большой таблицей поиска. Служба моста создает связующее дерево, просматривая МАС-адреса каждого кадра, который приходит на каждый из интерфейсов моста. Служба как бы создает небольшую памятку, которую можно условно представить в следующем виде: “Устройство 00-b3-a9-37-ef-la прислало кадр на адаптер телефонной линии”. Если через некоторое время на другой сегмент моста придет кадр, предназначенный для этого МАС-адреса, мост отправит кадр на соответствующий интерфейс.
Недостатком моста по сравнению с маршрутизацией является ограниченная масштабируемость. Поиск МАС-адресов не является самым разумным методом управления передачей пакетов в сети. Таблица связующего дерева не лучшим образом справляется с обработкой сегментов, в которых присутствует большое количество хостов. Необходимо избегать создания замкнутых маршрутов в дереве, которые возникают в результате случайного подключения сегментов в двух разных местах. Кроме этого, мосты не блокируют кадры широковещательной и многоадресной рассылки.
Но для небольших офисов, в которых немногие пользователи имеют устройства, использующие альтернативную среду передачи, мост неплохо справляется с соединением различных сегментов сети.
Настройка сетевого моста
Сетевой мост настраивается в окне Network Connections (Сетевые подключения). Процесс действительно состоит только из одного этого этапа. На сервере должны быть установлены как минимум два сетевых адаптера.
Нажмите и удерживайте клавишу <Ctrl>. После этого выберите интерфейсы, которые будут составлять сетевой мост. Щелкните правой кнопкой мыши на любом из выделенных интерфейсов и выберите из контекстного меню команду Bridge Connections (Подключение через мост). Спустя некоторое время появится новая пиктограмма моста (рис. 20.40).
После создания моста составляющие его сетевые адаптеры скрываются за виртуальным интерфейсом. Такие утилиты, как ipconfig, больше не показывают отдельные адаптеры и показывают только интерфейс моста. К этому нужно привыкнуть. После установки моста о нем можно забыть и вспомнить только при проведении обслуживания сервера.
Если в офисе существует несколько сегментов локальной сети, старайтесь избегать создания мостов в нескольких местах (для этого необходимо внимательно проектировать топологию сети). Если появится замкнутый маршрут, связующее дерево будет разрушено и-связь между сегментами разорвется.
Настройка VPN-соединений
В книге “Подарок с Земли" Ларри Найвена (Larry Niven) описан персонаж с необычным талантом. Каждый раз, когда этот персонаж нервничал, окружающие смотрели в другую сторону. Они этого не замечали и всегда отворачивались, когда персонаж начинал нервничать или пугался. Фактически он мог становиться невидимым. Нивен назвал этот феномен “Транс Плато”, поскольку события романа проходили на плато на высоте нескольких миль над поверхностью планеты.
Этот пример приведен по двум причинам. Во-первых, работать в отделе информационных технологий — все равно что работать на высоком-высоком плато, любое падение с которого может затянуться надолго. Во-вторых, в жестоком мире Интернета очень желательно, чтобы данные
обладали эффектом “Транс Плато”, чтобы оставаться невидимыми для всех злоумышленников, которые пытаются получить доступ к чужим секретам. Частично такой эффект обеспечивается благодаря технологии виртуальных частных сетей (Virtual Private Network — VPN).
Рис. 20.40. В окне Network Connections (Сетевые подключения) отображается пиктограмма Network Bridge .(Сетевой мост)
При использовании VPN две стороны соединения обмениваются данными по общедоступной сети, но данные и “личности" конечных точек подключения шифруются таким образом, что их невозможно прочитать, перехватывая передаваемые по сети пакеты. Зашифрованные пакеты создаются на каждой стороне и дешифруются с помощью ключей, известных только конечным точкам.
Процесс шифрования/дешифровки данных одной парой элементов (на одном уровне) и помещение (инкапсуляция) этих данных в пакеты другого набора элементов, а также таких пакетов называется туннелированием (tunneling). В операционной системе Windows Server 2003 поддерживается два метода создания туннелей: Point-to-Point Tunneling Protocol (PPTP) и Layer 2 Tunneling Protocol (L2TP). Выбор конкретного метода и его настройка для достижения необходимого уровня безопасности требуют определенных знаний о принципах работы этих методов.
Протокол РРТР.
Протокол РРТР инкапсулирует зашифрованные сообщения в стандартные кадры РРР с помощью специального протокола, который называется Generic Routing Encapsulation, или GRE.
Протокол РРТР использует два потока данных: управляющего канала (control channel), который передается через ТСР-порт 1723 и используется для создания и разрыва соединений
VPN, и канала данных (tunnel channel), который устанавливается по протоколу IP 47 и используется для передачи зашифрованных данных внутри пакетов GRE.
Транзакция РРТР
Соединение по протоколу РРТР имитирует транзакции коммутируемого соединения по протоколу РРР, за исключением того, что клиент уже установил соединение по сети с RRAS- сервером. Клиент отправляет запрос на подключение РРТР RRAS-серверу с помощью протокола MS-CHAPv2. Для обеспечения большей безопасности можно воспользоваться смарт- картами и включить использование протокола ЕАР.
После установки PPTP-соединения все данные, передаваемые между клиентом и RRAS- сервером, шифруются и помещаются в пакеты GRE. При этом значительно увеличивается доля служебной информации в передаваемых данных. Например, при использовании простой команды type для просмотра содержимого небольшого 10-байтового файла поверх РРТР- соединения генерируется около дюжины кадров с пакетами GRE. Это связано с тем, что шифруются и управляющие данные протоколов SMB и TCP.
Конечная точка подключения РРТР на RRAS-сервере не требует специальной настройки. При включении удаленного доступа на сервере по умолчанию создаются пять внешних интерфейсов РРТР. Это количество можно увеличить, если требуется больше одновременных подключений. Параметры доступны на консоли RRAS при вызове команды Properties (Свойства) для пиктограммы Ports (Порты). Выделите протокол РРТР и щелкните на кнопке Configure (Настройка). Откроется окно настройки протокола. Параметр Maximum Ports (Максимальное число портов) определяет максимальное количество одновременных подключений.
Недостатки протокола РРТР
Данные в протоколе РРТР шифруются с использованием того же протокола МРРЕ (Microsoft Point-to-Point Encryption), который используется при шифровании протокола РРР. В данном случае используется алгоритм потокового шифрования RC4 с обновлением ключа шифрования каждые 256 кадров.
Как было показано в разделе “Аутентификация по РРР”, оригинальный протокол МРРЕ обладал рядом недостатков. В операционной системе Windows Server 2003 (и в других современных службах удаленного доступа под управлением операционной системы Windows) используется протокол PPTPv2, который был значительно улучшен, но остается объектом критики.
Как показывает практика, схожесть между стандартами РРТР и РРР оказывается самым большим недостатком. Это связано с тем, что фаза аутентификации происходит за пределами шифрованного туннеля, поэтому существует вероятность, что злоумышленник создаст метод перехвата транзакции до запуска механизма шифрования. Это одна из причин использования смарт- карт в том случае, если для создания виртуальной частной сети используется протокол РРТР.
Протокол L2TP избавился от недостатков протокола РРТР за счет встраивания фазы аутентификации в шифрованную транзакцию и подписывания всех передаваемых данных цифровой подписью. Если протокол РРТР можно сравнить с обычной курьерской службой, то протокол L2TP соответствует бронированным инкассаторским автомобилям.
Но протокол РРТР не настолько уязвим, чтобы от него отказываться, и одним из его преимуществ является простота. Для создания виртуальной частной сети на основе протокола РРТР необходимы два узла под управлением Windows (или Linux, если установить пакет РоРТоР), способных связаться друг с другом по сети. Операционная система Windows 98 поддерживает создание виртуальной частной сети РРТР с рабочей станцией под управлением Windows ХР, хотя обратная конфигурация немного сложнее в настройке. Протокол L2TP такие конфигурации не поддерживает. Этот протокол поддерживается только современными платформами Windows и требует развертывания инфраструктуры открытого ключа (PKI) из- за использования сертификатов.
Протокол L2TP
По названию несложно догадаться, что протокол L2TP работает на втором уровне стека протоколов OSI, в то время как протокол РРТР работает на уровне приложений. Протокол L2TP работает совместно с протоколом IPSec для шифрования и цифрового подписывания трафика между клиентом и RRAS-сервером.
Протокол L2TP упаковывает целый пакет в полезную нагрузку другого пакета. Теоретически протокол L2TP можно использовать для упаковки трафика в поток анонимных дейтаграмм UDP. Комбинация протоколов IPSec и L2TP позволяет создать систему “точка-точка”, которая удовлетворяет базовым требованиям безопасности: защищенности, аутентификации, целостности и невозможности отказа от выполненных операций.
Протокол IPSec шифрует целый пакет и подписывает его для предотвращения атаки посредника и атаки с подменой адресов. Использующийся для создания шифрованных пакетов протокол называется ESP (Encapsulating Security Payload — инкапсулированные защищенные данные). Этот протокол поддерживает несколько алгоритмов шифрования, включая DES, 3DES и AES. По умолчанию в операционных системах Windows Server 2003 и Windows ХР используется алгоритм шифрования 3DES, хотя после широкого распространения нового стандарта может начаться использование алгоритма AES.
Протокол L2TP принимает пакеты ESP и помещает их в анонимные пакеты UDP. Это и есть туннелирование. Создание туннеля начинается с обмена сертификатами Х.509 между конечными точками еще до того, как по сети будет передаваться имя клиента. Это позволяет защитить этап аутентификации, на котором используются протоколы MS-CHAPv2, RADIUS и ЕАР совместно со смарт-картами.
На рис. 20.41 показано содержимое пакета и выделены различные составляющие кадра L2TP. Дескриптор SPI (Security Parameter Index — индекс защищенного соединения) является числом, которое уникально связывает зашифрованное содержимое с заголовком, хранящимся открытым текстом. Это позволяет защитить систему от подмены адреса.
«11М«11МСинтаксический анализатор (parser) IP-заголовка определяет пакет как Encap Security Payload (ESP) for IPv6. Это связано с тем, что изначально протокол IPSec разрабатывался для протокола IPv6. Протокол ESP поддерживает и пакеты IPv4.
«11М
«11М
ISP: Sequence KUnber ■ в <0хв)
ISP: Reels of Irene: Hueber of data bytes regaining ■ 68 (0x0044)
00000000 00000010 00000020 00000030 00000040 ooboooso 0000006000000000 00000010 00000020 00000030 00000040 ooboooso 00000060Puc. 20.41. Содержимое пакета L2TP, в который включена полезная нагрузка ESPPuc. 20.41. Содержимое пакета L2TP, в который включена полезная нагрузка ESP
00000000 00000010 00000020 00000030 00000040 ooboooso 00000060
00000000 00000010 00000020 00000030 00000040 ooboooso 00000060
Puc. 20.41. Содержимое пакета L2TP, в который включена полезная нагрузка ESP
Puc. 20.41. Содержимое пакета L2TP, в который включена полезная нагрузка ESP
Порядковый номер ESP является важным компонентом, так как протокол L2TP не использует протокол TCP и не может гарантировать доставку пакетов в правильном порядке. Протокол IPSec должен самостоятельно отслеживать порядковые номера и запрашивать повторную отправку в случае потери пакетов.
Применение сертификатов компьютеров
Самым сложным моментом использования протокола IPSec является распространение сертификатов среди компьютеров, являющихся конечными точками операций обмена данными. Проще всего использовать инфраструктуру открытого ключа Windows Server 2003 и групповые политики.
Существует политика Automatic Certificate Request (Автоматический запрос сертификата), которая определяет, какие сертификаты будут предоставляться компьютеру. Настроив эту политику на запрос сертификатов Computer, можно заставить компьютеры автоматически подавать заявку на получение сертификатов без вмешательства администратора. Эта политика хранится в разделе Computer Configuration^Windows Settings^Security Settings^Public Key Policies (Конфигурация компьютера^Параметры Windows^riapaMerpy безопасности^Поли- тики открытого ключа).
Групповые политики поддерживают автоматическое распространение сертификатов только для клиентов Windows Server 2003, Windows ХР и Windows 2000. Только на этих платформах поддерживается использование протокола L2TP.
Транзакция по протоколу L2TP и протокол IPSec
В транзакции обмена данными по протоколу L2TP используется протокол, который называется ISAKMP (Internet Security Association and Key Management Protocol — протокол управления ключами для защиты соединений в сети Интернет). Этот протокол напоминает встречу двух нейрохирургов. Они удостоверяют личности друг друга, договариваются о процедуре встречи и начинают общаться на непонятном жаргоне. На рис. 20.42 показано содержимое перехваченного кадра, в котором передается пакет ISAKMP.
Стоит обратить внимание, что в этом пакете от клиента L2TP RRAS-серверу передается начальная транзакция подключения. С этого пакета начинается согласование параметров взаимно допустимого контекста безопасности (Security Association — SA). Соединение SA по протоколу IPSec определяет правила, в соответствии с которыми два компьютера на каждой стороне соединения SA могут обмениваться информацией. Параметры соединения SA определяются в политике IPSec. Файл политики L2TP SA доступен по умолчанию на всех компьютерах под управлением Windows Server 2003, Windows ХР и Windows 2000.
После выбора SA два компьютера на каждой стороне соединения выполняют взаимную аутентификацию, обмениваясь ключами. Протокол ISAKMP поддерживает обмен сертификатами Х.509 или создание динамических ключей сеансов с помощью метода Диффи- Хеллмана. В протоколе L2TP для операционной системы Windows поддерживается только обмен сертификатами.
Согласование параметров контекста безопасности SA и обмен сертификатами являются единственными фрагментами информации, которые передаются открытым текстом. После подтверждения сертификатов друг друга все передаваемые сообщения передаются в зашифрованном виде. Это значит, что оставшаяся часть этапа аутентификации выполняется внутри защищенного туннеля.
Протокол IPSec работает через UDP-порт 1701 и использует только один канал для данных и управления. Это позволяет избежать использования отдельного канала для управления, как это происходит в протоколе РРТР.
РММ
ТЕМ
•sc ЖАС Шг
Dst MAC AMs
1 Protocol
1 DesGrivtoio»
9
8
10.582300
XEROX 000000
9A1220001100
DNS
OxlC:Std Qry Resp
for serve*^
9
10.786953
9А1220001100
XEROX 000000
ISAKHP
Major Version: 1
Minor Vers
10
10.788959
XEROX 000000
9A1220001100
ISAKMP
Major Version: 1
Minor Vers?
11
11.098948
9А1220001100
XEROX 000000
ISAKMP
Major Version: 1
Minor Vers
и
xnox ooeeao Mizioeou*
иже»
■ajar eartlae: 1
Minor Vers
13
11.800185
9A1220001100
XEROX 000000
ISAKMP
Major Version: 1
Minor Vers
14
11.861380
9A1220001100
XEROX 000000
IP
Protocol ■ UDP -
User Datagr '
9
J
Мн rotoil Network Monitor - [Capture: 19 (Detail)]
jEPHbf В* Оейу Tools Opaare wtxbw и*-IffJ xl
^|1Й~Л^Ш ^ №д|д1" *1 tl ?M *№l ofjl;'" *
.8 Frane: Base frane properties
,@ ETHERNET: EType = Internet IP (IPv4)
S IP: Protocol ■ UDP - User Datagree; Packet ID ■ 11008; Total IP Length ■ 282; Option Й UDP: Src Port: isakep (SOO); Dst Port: isakep (SOO); Length ■ 262 (0x106)
■ ISAKMP: Initiator cookie - 7E ЕЭ 18 88 CO 24 F0 80 ISAKMP: Responder cookie ■ 18 8E 88 B9 SD SO C3 SD ■ ■ ISAKMP: Next payload ■ Key Exchange ISAKMP: Major version ■ 1 (0x1) ISAKMP: Minor version - 0 (0x0) ISAKMP: Exchange type • Identity Protection № ISAKMP: Flags suenary ■ 0 (0x0)-
- ISAKMP: Message ID = 0 (0x0) ISAKHP: Length - 254 (OxFE) ® ISAKHP: Payload type ■ Key Exchange Si' ISAKHP: Payload type ■ Nonce 8 ISAKHP: Payload type ■ Certificate Request ISAKHP: Next payload ■ None ISAKHP: Reserved - 0 (0x0) ISAKHP: Payload length - 70 (0x46) ISAKHP: Certificate type - X.509 Certificate - Signature
L ISAKMP: Certificate authority • 30 3F 31 13 30 11 06 0A 09 92 26 89 93 F2 2C 6< 21I
Suwwry «R» ISAKMP №detF#; ИРЭ0 Off:« (: л
Puc. 20.42. Содержимое кадра, в котором передается пакет ISAKMP
Недостатки протокола L2TP
Протокол L2TP является более безопасным из двух протоколов туннелирования, доступных в операционной системе Windows Server 2003, но с этим протоколом связано несколько проблем при его применении.
Во-первых, каждый компьютер в составе транзакции L2TP должен иметь доступ к инфраструктуре открытого ключа (PKI) и к центру сертификации (СА). Это не обязательно должны быть решения от компании Microsoft, но при использовании инфраструктуры открытого ключа от стороннего разработчика придется обеспечить применение сертификатов без возможности автоматической подачи заявок на их получение.
Во-вторых, протокол L2TP использует значительную долю ресурсов центрального процессора, еще большую, чем протокол РРТР. Это связано с шифрованием по алгоритму 3DES, которое применяется в протоколе IPSec и оказывается более сложным, чем шифрование МРРЕ, применяемое в протоколе РРТР. Кроме этого, система должна проверять цифровую подпись каждого пакета. Для повышения производительности IPSec можно установить сетевой адаптер с аппаратным сопроцессором IPSec. Такие сетевые адаптеры предлагаются большинством производителей.
И последнее, возможно, самое важное. Протокол IPSec не взаимодействует “дружественно" с брандмауэрами, поскольку протокол ESP не предоставляет информации о портах, которую можно использовать при трансляции сетевых адресов. Существуют методы туннелирования протокола IPSec через брандмауэры с трансляцией сетевых адресов, но сложность такого решения может очень быстро выйти из-под контроля. Обратитесь к документации производи-
МаршрутизаторМаршрутизаторКонтроллер домена Windows Server 2003Контроллер домена Windows Server 2003Основная граница брандмауэраОсновная граница брандмауэраСтандартная аутентификация по протоколу РРРСтандартная аутентификация по протоколу РРРif Файловый сервер и сервер печатиif Файловый сервер и сервер печатиАутентификацияKerberosАутентификацияKerberosТуннель L2TP до R RAS-сервераТуннель L2TP до R RAS-сервера
Маршрутизатор
Маршрутизатор
Контроллер домена Windows Server 2003
Контроллер домена Windows Server 2003
Основная граница брандмауэра
Основная граница брандмауэра
Стандартная аутентификация по протоколу РРР
Стандартная аутентификация по протоколу РРР
if Файловый сервер и сервер печати
if Файловый сервер и сервер печати
АутентификацияKerberos
АутентификацияKerberos
Туннель L2TP до R RAS-сервера
Туннель L2TP до R RAS-сервера
теля брандмауэра и держите под рукой номер службы технической поддержки при попытке реализации такого решения. В операционной системе Windows Server 2003 предоставляется поддержка последних документов RFC, которые описывают реализацию туннелей IPSec через брандмауэры; но эта технология все еще находится на этапе развития и для получения приемлемого результата потребуется длительная настройка.
Чтобы избежать проблем взаимодействия с брандмауэрами, в качестве конечной точки туннеля IPSec можно использовать RRAS-сервер, который расположен в демилитаризованной зоне. На рис. 20.43 показан пример такой конфигурации. Это позволяет использовать брандмауэр для анализа незашифрованных данных, передаваемых в пределах основной сети. При таком решении вирусы не смогут проникнуть в сеть, “спрятавшись” в зашифрованных пакетах.
Брандмауэр разрешаетпередачу данных черезТСР-порт 1732
\ Демилита-
RRAS-сервер под управлением \ ризованная Windows Server 2003 используется в \ зона качестве конечной точки туннеля, созданного на основе L2TP
Провайдер услуг Д, Интернет Маршрутизатор
Клиентскийкомпьютер становитсяузлом в частной сети спомощью туннеля
Рис. 20.43. Виртуальная частная сеть на основе протокола L2TP. Туннель заканчивается на RRAS-cepeepe, расположенном в демилитаризованной зоне
Настройка подключения виртуальной частной сети
Виртуальные адаптеры РРТР и L2TP создаются автоматически при активизации удаленного доступа на RRAS-сервере. Дополнительная настройка для приема PPTP-соединений не требуется. Для использования протокола L2TP RRAS-сервер и клиент должны иметь сертификаты компьютера. Если автоматическое получение таких сертификатов нежелательно, получите сертификат компьютера, как описано в процедуре 20.16 (в данном случае предполагается, что доступен центр сертификации под управлением Windows Server 2003 или Windows 2000).
Процедура 20.16. Получение сертификатов компьютеров вручную
Зарегистрируйтесь на компьютере от имени учетной записи с привилегиями администратора.
Откройте пустую консоль ММС.
Загрузите оснастку Certificates (Сертификаты) с помощью команды File^Add/Remove Snap-in (Файл^Добавить/Удалить оснастку). Выберите Computer Account (Учетная запись компьютера), а не Му User Account (Моя учетная запись).
Разверните дерево Certificates1^ Personal (Сертификаты^ Личные).
Щелкните правой кнопкой мыши на пиктограмме Personal (Личные) и выберите из контекстного меню команду Request New Certificate (Запросить новый сертификат). Запустится мастер запроса сертификата (Certificate Request Wizard).
Щелкните на кнопке Next (Далее). Откроется окно Certificate Types (Типы сертификатов). Выберите Computer (Компьютер).
Щелкните на кнопке Next (Далее). Откроется окно Certificate Friendly Name and Description (Дружественное имя сертификата и описание). Оставьте это поле пустым.
Щелкните на кнопке Next (Далее). Откроется окно со сводкой выбранных параметров. Щелкните на кнопке Finish (Готово), чтобы получить сертификат.
После получения сертификатов компьютера на RRAS-сервере и на клиенте можно приступать к настройке клиента на подключение к виртуальной частной сети. Конкретная процедура настройки может зависеть от платформы. Главное, чтобы существовало соединение с RRAS-сервером. Кроме этого, IP-адрес RRAS-сервера должен быть указан в параметрах клиента.
Служба Internet Authentication
Services (IAS).
Служба IAS (Internet Authentication Services — службы аутентификации в Интернете) в операционной системе Windows Server 2003 полностью совместима с такой же службой в операционной системе Windows 2000, поэтому различные компоненты могут работать совместно в процессе модернизации системы.
Если используется реализация RADIUS от стороннего производителя, необходимо проверить номера UDP-портов, которые используются RRAS-серверами и серверами RADIUS. Текущий стандарт RADIUS использует UDP-порт 1812 для аутентификации и UDP-порт 1813 для учета. Более старые реализации RADIUS использовали порт 1645 для аутентификации и 1646 для учета. Существующие серверы RADIUS и серверы удаленного доступа могут использовать прежние номера портов. Если конфликт портов не влияет на работу текущей реализации системы, службу IAS можно перенастроить на использование прежних портов.
Сервер, соответствующий минимальным требованиям операционной системы Windows Server 2003 к производительности центральног^процессора и объему оперативной памяти, может обслуживать десятки тысяч пользователей. Обычно служба IAS должна устанавливаться на контроллер домена. Это позволяет избежать любых задержек при передаче данных по сети при обмене данными между службой IAS и базой данных Active Directory. Но это необязательное требование. Служба IAS может обрабатывать большое количество запросов аутентификации за секунду, даже если ее установить на изолированном сервере. Совместно с IAS-сервером в пределах того же сайта должен быть доступен сервер глобального каталога.
Установка службы IAS
При выборе сервера для установки службы IAS в Control Panel (Панель управления) выберите аплет Add/Remove Programs (Установка и удаление программ). Перезагрузка не требуется. После запуска службы можно настроить журнал и политики удаленного доступа, а также зарегистрировать сервер в базе данных Active Directory, чтобы сервер мог выполнять транзакции аутентификации. Кроме этого, службу необходимо настроить на обработку запросов RADIUS от RRAS-сервера.
Настройка журнала для службы IAS
и политик удаленного доступа
На рис. 20.44 показана принятая по умолчанию конфигурация консоли управления службой IAS, las .msc. Эта консоль доступна через меню Starts Administrative Tools (Пуск1^ Администрирование).
1 ♦1 ♦*• Network t otmections
1 ♦
1 ♦
* ect Haw Favorites To* Advanced H*
^• ■ j - T z'Sw* • . ***• ■* ,
*»mif<Network Corrections
Dial-upDial-up
Dial-up
Dial-up
Internet Gateway
Network BridgeNetwork BridgeLocal Area Connection 2 on XP2EnabledLocal Area Connection 2 on XP2Enabled^ДС Bridge Miniport^ДС Bridge MiniportLocal Area ConnectionEnabled, BridgedLocal Area ConnectionEnabled, BridgedNet^k Bridge (Network Bridge^Net^k Bridge (Network Bridge^Wretess Network ConnectionWretess Network Connection2'RjPJOC2'RjPJOCWizardWizardNew Connection WizardNew Connection Wizard6 objects6 objects
Network Bridge
Network Bridge
Local Area Connection 2 on XP2
Enabled
Local Area Connection 2 on XP2
Enabled
^ДС Bridge Miniport
^ДС Bridge Miniport
Local Area Connection
Enabled, Bridged
Local Area Connection
Enabled, Bridged
Net^k Bridge (Network Bridge^
Net^k Bridge (Network Bridge^
Wretess Network Connection
Wretess Network Connection
2'RjPJOC
2'RjPJOC
Wizard
Wizard
New Connection Wizard
New Connection Wizard
6 objects
6 objects
Puc. 20.44. Консоль управления службой IAS
Папка RADIUS Clients используется для настройки взаимодействия между IAS-сервером и RRAS-серверами. Эта тема рассматривается в следующем разделе.
В папке Remote Access Logging хранится интерфейс настройки функции учета RADIUS. Этот интерфейс имеет форму пиктограммы Local File (Локальный файл). Файл журнала, управляемый функцией учета, хранится в каталоге \Windows\System32\Logfiles. Параметры настройки журнала доступны в окне Properties (Свойства).
Обычно имеет смысл включать все возможности журнала. Это позволяет заметить несанкционированное использование коммутируемого соединения или нарушение в системе безопасности. Файл журнала службы IAS может достаточно быстро увеличиваться в размерах, поэтому на вкладке Local File (Локальный файл) предоставляется возможность изменения расположения файла и периодического создания новых журналов, например, ежедневно, еженедельно или ежемесячно в зависимости от количества пользователей и размера журнала.
При попытке настроить политики удаленного доступа администратор может быть удивлен количеством возможностей по настройке RADIUS. Стандарт разрабатывался для провайдеров услуг Интернета, обслуживающих миллионы пользователей и использующих большое количество политик.
- В обычных условиях потребуется политика, предоставляющая пользователям коммутируемый доступ. Эта политика создается по умолчанию и находится в папке Remote Access Policies. .
По умолчанию для этой политики установлено значение Deny Remote Access Permission. Измените значение на Grant для обеспечения содания коммутируемых соединений. Перед вступлением этой политики в силу учетную запись пользователя в базе данных Active Directory необходимо настроить на использование политик удаленного доступа. Эта возможность доступна только в режиме Native.
Регистрация службы IAS в базе данных
Active Directory
Сервер IAS не может использовать базу данных Active Directory для аутентификации пользователей, пока служба IAS не будет зарегистрирована в базе данных Active Directory. Регистрация предусматривает добавление учетной записи компьютера, на котором запущен сервер IAS, в группу RAS and IAS Servers.
Учетную запись можно добавить в группу вручную, но удобнее воспользоваться возможностью регистрации сервера на консоли IAS. Эта возможность добавляет сервер в группу RAS and IAS Servers только в локальном домене. Если IAS-серверы установлены в нескольких доменах или требуется перекрестная аутентификация пользователей, необходимо вручную добавить IAS-серверы в группу RAS and IAS Servers в каждом домене. Последовательность действий для регистрации IAS-сервера в Active Directory приводится в процедуре 20.17.
Процедура 20.17. Регистрация IAS-сервера в базе данных Active Directory
Щелкните правой кнопкой мыши на пиктограмме Internet Authentication Service (Служба аутентификации Интернета) и выберите из контекстного меню команду Register Service In Active Directory (Зарегистрировать службу в Active Directory).
Будет отображено уведомление о необходимости авторизации компьютеров, поддерживающих работу службы IAS, что позволит им читать свойства коммутируемого доступа пользователей. От администратора требуется подтверждение авторизации. Щелкните на кнопке ОК для подтверждения.
Будет выдано сообщение о регистрации сервера. Кроме этого, будет выдано напоминание о необходимости регистрации сервера в группе RAS and IAS Servers во всех доверенных доменах, что позволит выполнять аутентификацию пользователей из этих доменов.
На этом этапе IAS-сервер готов к аутентификации пользователей. Настройте RRAS-сервер на использование сервера IAS.
Настройка серверов IAS и RRAS на поддержку аутентификации по технологии RADIUS
Перед тем как принимать запросы на аутентификацию по RADIUS от RRAS-сервера, между серверами IAS и RRAS должно быть установлено доверительное отношение. Как и классическое доверительное отношение Windows NT, в этом случае используется известный обоим компьютерам секретный пароль. Это позволяет IAS-серверу удостоверять “личность” RRAS-сервера для защиты от атак посредника. Для настройки RRAS-сервера в качестве клиента IAS-сервера выполните последовательность операций, описанную в процедуре 20.18.
Процедура 20.18. Настройка RRAS-сервера в качестве клиента IAS-сервера
Ншш*м«№«1вам*мм«нм11кммямм141яаьмммм«м**штшамммммям1намммш1мм*мммчмам|м*^ммаиммамммам>шмм«нмим*м1м*аа1амаммммнамм>
На консоли IAS щелкните правой кнопкой мыши на пиктограмме Clients (Клиенты) и выберите из контекстного меню команду Add Client (Добавить клиент). Откроется окно Add Client (Добавление клиента).
Введите имя RRAS-сервера в поле Friendly Name (Дружественное имя). Это имя используется только для удобства пользователя. Единственным доступным протоколом является RADIUS.
Щелкните на кнопке Next (Далее). Откроется окно Client Information (Сведения о клиенте). В поле Client Address (Адрес клиента) введите полностью определенное доменное имя или IP-адрес RRAS-сервера.
В поле Client-Vendor (Клиент-поставщик) выберите Microsoft. Это позволит IAS-серверу использовать контроллер домена Windows для обработки входящих запросов на аутентификацию по протоколу RADIUS.
В поле Shared Secret (Общий секрет) введите пароль, который будет известен только серверам IAS и RRAS. Этот пароль не меняется динамически, поэтому необходимо использовать длинный и сложный пароль, чтобы защитить сеть от создания подложного RRAS-сервера с тем же IP-адресом.
Щелкните на кнопке Next (Далее), чтобы сохранить изменения.
После этого RRAS-сервер необходимо настроить на использование протокола RADIUS и IAS-сервера. Последовательность действий рассматривается в процедуре 20.19.
Процедура 20.19; Настройка RRAS-сервера на использование аутентификации по технологии RADIUS
На консоли Routing and Remote Access откройте окно Properties (Свойства) для пиктограммы сервера.
Активизируйте вкладку Security (Безопасность).
В полях Authentication Provider (Поставщик аутентификации) и Accounting Provider (Поставщик учета) выберите RADIUS.
Возле поля Authentication Provider (Поставщик аутентификации) щелкните на кнопке Configure (Настройка). Откроется окно RADIUS Authentication (Аутентификация по RADIUS). В этом окне перечислены серверы RADIUS, которые будут использоваться RRAS-сервером.
Щелкните на кнопке Add (Добавить). Откроется окно Add RADIUS Server (Добавить сервер RADIUS).
В поле Server Name (Имя сервера) введите полностью определенное доменное имя или IP-адрес IAS-сервера.
Возле поля Secret (Секрет) щелкните на кнопке Change (Изменить). Откроется окно Change Secret (Изменить секрет).
Введите пароль, который вводился при настройке клиента на IAS-сервере, и щелкните на кнопке ОК.
Щелкните на кнопке ОК, чтобы добавить IAS-сервер в список серверов RADIUS. В столбце Initial Score будет показан принятый по умолчанию счет 30. RRAS-сервер будет менять этот счет в зависимости от скорости получения ответов от сервера RADIUS. Установка этого значения вручную требуется достаточно редко.
Выполните ту же последовательность действий для поля Accounting Provider (Поставщик учета).
Остановите и перезапустите RRAS-службу для инициализации новых поставщиков.
На этом этапе RRAS-сервер готов к принятию запросов от клиентов. Для проверки конфигурации можно установить коммутируемое соединение с помощью доменной учетной записи.
RRAS-сервер выполняет аутентификацию пользователей с помощью доменных регистрационных данных, предоставляемых IAS-сервером.
В следующей главе
Теперь, когда настроены удаленный доступ и подключение к Интернету, развертывание операционной системы Windows Server 2003 можно считать завершенным. Можно посидеть на крыльце и любоваться результатами своего труда, как это делают фермеры. Без сомнений, это был большой объем работы.
Но нельзя слишком расслабляться. Даже в моменты отдыха растут сорняки и прилетают вредители, а синоптики предупреждают о засухе. Необходимо подготовиться к возможной катастрофе. Именно эта тема рассматривается в следующей главе.
21
Восстановление после отказов системы
В
последней главе нашей саги о развертывании операционной системы Windows Server 2003 в пределах предприятия пришло время рассмотреть неизбежность катастрофы. На протяжении всей книги рассматривались методы решения больших и малых проблем, которые возникают при реализации возможностей и функций Windows Server 2003, но в этой главе рассматривается решение серьезных проблем, которые могут привести к отказу системы (серьезному отказу). Здесь будет показано, как выяснить природу отказа и защитить систему от таких отказов в дальнейшем.
В этой главе рассматриваются следующие темы.
Резервное копирование и восстановление системы и файлов данных
Использование безопасного режима для восстановления стабильной работы
Восстановление после критических ошибок
Выделенное управление серверами
Использование безопасного режима
Восстановление работоспособности с помощью последней удачной конфигурации
Использование Recovery Console (Консоль восстановления)
Новые возможности операционной системы Windows Server 2003
Автор этой книги родом из Нью-Мехико, где принято давать прозвища своим друзьям. Если бы операционная система Windows Server 2003 была из Нью-Мехико, она бы получила прозвище “Восставший из мертвых”. Это связано с количеством новых возможностей, предназначенных для поддержки постоянного доступа к данным. Ниже перечислены эти новые возможности.
Аварийное восстановление системы (Automated System Recovery — ASR). Эта возможность упрощает восстановление раздела операционной системы.
Прощай, диск аварийного восстановления. В операционной системе Windows Server 2003 не поддерживается использование диска аварийного росстановления. Единственными инструментами восстановления остаются Recovery Console (Консоль восстановления) и аварийное восстановление системы (ASR).
Службы аварийного управления (Emergency Management Services — EMS). Если к серверу невозможно получить доступ по сети, службы аварийного управления обеспечивают подключение к серверу через последовательный порт.
Интерактивный анализ отказов (Online Crash Analysis). Утилиты отладки, работающие в режиме ядра, в операционной системе Windows Server 2003 могут запускаться на том же компьютере, что и операционная система, за которой ведется наблюдение. Это позволяет запускать на консоли различные инструменты отладки.
Теневое копирование тома (Volume Shadow). Заблокированные файлы приводят к проблемам при работе программ резервного копирования. Пользователи нервничают, когда узнают, что восстановить файл невозможно, так как он был заблокирован в момент резервного копирования (в это время пользователь работал из дома). Служба теневого копирования тома создает моментальную копию (snapshot) заблокированных файлов, а программа резервного копирования пользуется копией, а не самим файлом.
Восстановление системы (System Restore). Эта возможность доступна только в операционной системе Windows ХР. Она используется для создания моментальных копий конфигурации системы, которые можно восстанавливать для отката системы в предыдущее состояние.
Интерактивное отслеживание событий (Online event tracking). Если приложение отказывает или другим способом приводит к ошибке в работе операционной системы, система собирает информацию об ошибке и отправляет эту информацию компании Microsoft, где она собирается и анализируется с целью выявления общих тенденций.
Служба отслеживания завершения работы (Shutdown Event Tracking). Эта “возможность", если ее можно так назвать, требует от пользователя ввода причины при каждом завершении работы системы. Введенная причина добавляется в журнал событий. Если система аварийно завершает работу, причину придется указать после перезагрузки системы.
Работа утилиты Ntbackup
Как и во всех операционных системах Windows начиная с Windows NT 3.51, в составе операционной системы Windows Server 2003 предоставляется утилита резервного копирования Ntbackup, которая является версией коммерческой программы Backup Exec от компании Veritas (www. veritas. com) с ограниченными функциональными возможностями. Резервные копии, созданные с помощью более ранних версий утилиты Ntbackup, могут быть восстановлены в операционной системе Windows Server 2003, так как во всех версиях используется один и тот же формат Microsoft Таре Format (MTF). ,
В составе утилиты не предоставляется система управления лентами. Управление лентами осуществляется службой Removable Storage Management (RSM). Служба RSM может обрабатывать как отдельные ленточные приводы, так и роботизированные библиотеки. Кроме этого, служба отвечает за работу с носителями CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, Zip, Jaz, Orb и магнитооптическими носителями.
В отличие от других инструментов администрирования в операционной системе Windows Server 2003, для управления утилитой Ntbackup используется отдельный выполняемый файл, а не консоль ММС. Это позволяет сохранить интерфейс командной строки для планирования резервного копирования в фоновом режиме.■
Запустите утилиту Ntbackup, воспользовавшись командой Starts Programs^ Accessories^ Backup (Пуск^Программы^Стандартные1^Архивация данных). При первом запуске программы используется режим Wizard (Мастер). Автор этой книги является поклонником Гарри Поттера, но, когда дело доходит до восстановления данных, лучше обходиться без помощи волшебников. Во всех примерах этой главы используется Advanced View (Расширенный режим). Мастер необходим только для планирования резервного копирования.
В расширенном режиме утилиты Ntbackup используется знакомый интерфейс на основе вкладок. Пример окна Ntbackup, на котором выбрана вкладка Backup (Резервное копирование) показан на рис. 21.1.
* Влкнр Utility [Unlilk-d]* Влкнр Utility [Unlilk-d]ЗУ Desktop-j I "i j My Computer4 Qs, ЗИ Floppy (AJ№ □<» Local Disk (C )* QJ PRESERVERS (D)* □£ c$ on 'server? Г»)DX ch21 on *pro1 ^captures' (Z)Q^j My Documents- Lj^ My Network PlacesЗУ Desktop-j I "i j My Computer4 Qs, ЗИ Floppy (AJ№ □<» Local Disk (C )* QJ PRESERVERS (D)* □£ c$ on 'server? Г»)DX ch21 on *pro1 ^captures' (Z)Q^j My Documents- Lj^ My Network PlacesЛГк*ЙЕЕ«ЯеtiT|4mmDDSfle6k*e«*<«N»iwiw |NewЛГк*ЙЕЕ«ЯеtiT|4mmDDSfle6k*e«*<«N»iwiw |New1 ! M^Boot Ffes Q ^Certificate Server Cl ^ COM* Class Regwtration Database QdtRogKtry □ ^SYSVOL1 ! M^Boot Ffes Q ^Certificate Server Cl ^ COM* Class Regwtration Database QdtRogKtry □ ^SYSVOL
* Влкнр Utility [Unlilk-d]
* Влкнр Utility [Unlilk-d]
ЗУ Desktop
-j I "i j My Computer
4 Qs, ЗИ Floppy (AJ
№ □<» Local Disk (C )
* QJ PRESERVERS (D)
* □£ c$ on 'server? Г»)
DX ch21 on *pro1 ^captures' (Z)
Q^j My Documents
- Lj^ My Network Places
ЗУ Desktop
-j I "i j My Computer
4 Qs, ЗИ Floppy (AJ
№ □<» Local Disk (C )
* QJ PRESERVERS (D)
* □£ c$ on 'server? Г»)
DX ch21 on *pro1 ^captures' (Z)
Q^j My Documents
- Lj^ My Network Places
ЛГк*ЙЕЕ«Яе
tiT|4mmDDS
fle6k*e«*<«N»iwiw |New
ЛГк*ЙЕЕ«Яе
tiT|4mmDDS
fle6k*e«*<«N»iwiw |New
1 ! M^Boot Ffes Q ^Certificate Server Cl ^ COM* Class Regwtration Database QdtRogKtry □ ^SYSVOL
1 ! M^Boot Ffes Q ^Certificate Server Cl ^ COM* Class Regwtration Database QdtRogKtry □ ^SYSVOL
Puc. 21.1. Окно Ntbackup, в котором выбрана вкладка Backup (Резервное копирование)
В дереве каталогов в левой панели окна Ntbackup используется стандартное пространство имен Explorer (Проводник), корнем которого является Desktop (Рабочий стол). Ниже корня расположены Му Computer (Мой компьютер), Му Documents (Мои документы) и Му Network Places (Мое сетевое окружение). Для резервного копирования можно выбрать весь диск или отдельные файлы и папки на этом диске. Выбор объекта обозначается синей отметкой. Если выбрать отдельный файл, папки на более высоких уровнях получат серую отметку, что указывает на включение структуры каталогов в резервную копию.
Для резервного копирования сетевых файлов можно воспользоваться подключенным сетевым диском или выбрать ресурс из списка ресурсов сервера в разделе дерева Му Network Places (Мое сетевое окружение). Утилита Ntbackup не использует агенты на удаленных компьютерах, поэтому сложные транзакции блокирования баз данных или сжатия данных не поддерживаются.
Для конкретного задания резервного копирования можно указать Backup Destination (Местоположение резервной копии) в виде локального ленточного привода или файла на локальном или сетевом диске. Резервную копию можно записать на сменный жесткий диск, например диск Zip или Jaz, а также на диск DVD-RAM. Это не может быть диск CD-RW, если в системе не установлен механизм пакетной записи от стороннего производителя. Если используется резервное копирование на основе файлов, целевой файл может быть томом NTFS или FAT/FAT32.
Резервное копирование по сети с использованием агентов
Резервное копирование по сети с помощью утилиты Ntbackup ограничено файлами, до которых можно добраться с помощью перенаправителя сетевых клиентов. Для доступа к заблокированным файлам утилита Ntbackup работает вместе с учетной записью Local System. Заблокированные системные файлы не могут быть скопированы с помощью перенаправителя сетевых клиентов. Для этого необходимо, чтобы на сервере был запущен агент.
Агент резервного копирования создает связь "клиент/сервер" между копируемым сервером и сервером, который создает резервную копию. Агент работает в контексте безопасности пользователя с привилегиями Backup Operator. Этот пользователь может получать доступ к заблокированным системным файлам. Агент отправляет копии файлов на сервер резервного копирования, где файлы помещаются на магнитную ленту. Обычно перед отправкой файлов по сети агенты выполняют шифрование файлов.
Типы резервного копирования
При модификации файла файловая система устанавливает флаг архива в атрибутах файла. На основе этого флага программа резервного копирования может определить список файлов, которые необходимо скопировать. Утилита Ntbackup поддерживает пять различных типов резервного копирования. Различия между методами заключаются в способе обработки флага архива.
Для просмотра вариантов резервного копирования запустите утилиту Ntbackup в расширенном режиме и выберите команду Tools^Options (Сервиса Параметры) из главного меню. В окне Options (Параметры) автоматически открывается вкладка Backup Туре (Тип архива). Пример этого окна показан на рис. 21.2. Рассмотрим доступные варианты резервного копирования.
Normal (Обычное). В этом случае выполняется резервное копирование выбранных файлов. Установленный флаг архива сбрасывается.
Сору (Копирование). В этом случае выполняется резервное копирование выбранных файлов, но флаг архива не сбрасывается.
Рис. 212. Окно Options (Параметры) системы резервного копирования. Открыта вкладка Backup Туре (Тип архива)
Differential (Дифференцированное). В этом случае выполняется резервное копирование только тех файлов, для которых установлен флаг архива. Флаг архива не сбрасывается.
Incremental (Добавочное). В этом случае выполняется резервное копирование только тех файлов, для которых установлен архивный флаг архива. Флаг архива сбрасывается.
Daily (Ежедневное). При выборе этого варианта резервного копирования флаг архива не используется. В этом случае выполняется резервное копирование файлов, метка времени модификации которых совпадает с датой резервного копирования.
Вариант Сору (Копирование), в основном, исйользуется для перемещения файлов на другой компьютер и не предназначен для регулярного резервного копирования. Ниже приводится подробная информация о других методах резервного копирования. Кроме этого, приводятся критерии выбора метода в каждом конкретном случае.
Обычная архивация
Запуск варианта Normal (Обычное) резервного копирования каждую ночь может значительно упростить восстановление. Все необходимые для восстановления системы файлы сохраняются в актуальном состоянии на единственной ленте (или наборе лент). Нормальное резервное копирование отнимает достаточно много времени, поэтому приходится соблюдать баланс между пользой резервных копий и длительностью промежутка между операциями резервного копирования.
Дифференцированное резервное копирование
Поскольку при дифференцированном резервном копировании копируются только файлы с установленным флагом архива, время ночной архивации значительно сокращается. Но в дальнейшем дифференцированное резервное копирование будет отнимать все больше и больше времени, так как при создании копии не сбрасывается флаг архива. Например, если файл File_A изменился в понедельник, этот файл будет включен в каждую ночную резервную копию на протяжении недели.
Восстановление дифференцированных резервных копий выполняется в два этапа. Сначала восстанавливается обычная резервная копия, после которой восстанавливается последняя дифференцированная резервная копия.
Дифференцированные резервные копии упрощают выполнение запросов на восстановление отдельных файлов, так как для восстановления файла необходимы только две ленты — последняя обычная резервная копия и последняя дифференцированная резервная копия.
Удостоверьтесь, что ротация лент предусмотрена таким образом, что ленты обычной и связанных с ней дифференцированных резервных копий хранятся вместе. Было бы обидно восстановить обычную резервную копию за одну неделю и дифференцированную копию за другую неделю.
Добавочная архивация
Добавочная архивация позволяет сократить длительность резервного копирования. Сокращение процедуры достигается за счет сброса флага архива. Таким образом, в каждую добавочную копию вносятся файлы, которые изменились с момента создания последней добавочной или обычной резервной копии.
Неприятной особенностью добавочных резервных копий является усложнение процедуры восстановления. Для восстановления тома необходимо восстановить последнюю обычную резервную копию, после чего по порядку восстановить все добавочные резервные копии. Если при восстановлении откажет одна из лент, в результате могут возникнуть проблемы с целостностью данных.
Кроме этого, использование добавочных резервных копий усложняет восстановление отдельных файлов, так как приходится искать файл на нескольких лентах. Если пользователь не помнит, когда файл был потерян, администратору придется просматривать большое количество лент в поисках необходимого файла.
Ежедневная архивация
И дифференцированная, и добавочные резервные копии используют флаг архива. Если использованы утилиты, которые меняют флаг архива, в ночной резервной копии могут отсутствовать некоторые файлы. При ежедневном резервном копировании эта проблема решается благодаря использованию метки времени файлов, а не флага архива.
С ежедневными резервными копиями связаны те же проблемы, что и с добавочными резервными копиями. Необходимо сохранять порядок копий при хранении и восстановлении. Перед восстановлением ежедневных копий необходимо восстановить последнюю обычную резервную копию.
Журналы резервного копирования
Утилита Ntbackup ведет журнал каждой процедуры резервного копирования и восстановления. Для доступа к журналу из меню утилиты Ntbackup можно выбрать Tools^Report (Сер- вис=> Отчет). Журнал является критическим элементом стратегии резервного копирования. Без журнала администратор может не подозревать о проблемах, ставящих под угрозу целостность данных. Например, если резервное копирование данных выполняется по сети, проблема в работе сетевого соединения может помешать копированию некоторых файлов. Без регулярной проверки содержимого журнала администратор не сможет определить, что в процедуре резервного копирования возникла проблема.
Журналы резервного копирования сохраняются в локальном профиле пользователя, который запустил утилиту резервного копирования. Журнал сохраняется в каталоге \Documents and Settings\<logonID>\Local Settings\Application Data\Microsoft\Windows NT\NTBackup\Data. Это фиксированный путь. He существует ни одного параметра системного реестра, который позволяет изменить каталог, в котором сохраняется журнал резервного копирования. При каждом резервном копировании создается новый журнал. Журналы нумеруются последовательно и с автоматической перенумерацией по достижении 10, поэтому самый старый журнал перезаписывается.
В окне Options (Параметры), доступном из меню Tools'^Options (Сервис1^Параметры), можно выбрать тип сохраняемого журнала (рис. 21.3). В утилите Ntbackup предоставляются два варианта протоколирования событий.
Рис. 213. В окне Options (Параметры) можно выбрать вариант ведения журнала
Вариант Detailed (Подробный) позволяет включить в журнал имя и путь к каждому файлу, внесенному в резервную копию.
Вариант Summary (Краткая сводка) позволяет занести в журнал сведения о количестве файлов в резервной копии и количестве пропущенных файлов.
Краткий вариант ведения журнала хорошо подходит для стандартных ежедневных резервных копий, так как снижается опасность пропустить сообщение об ошибке в длинном подробном журнале. В процессе устранения неисправностей при выполнении резервного копирования, связанных с потерей файлов, можно включить переключатель Detailed (Подробный) и просмотреть подробный журнал на предмет причин потери файлов.
Исключение файлов
В окне выбора параметров для резервного копирования Options (Параметры) доступна вкладка Exclude Files (Исключение файлов), которая показана на рис. 21.4.
Рис. 21.4. На вкладке Exclude Files (Исключение файлов) отображается перечень исключаемых файлов. С помощью кнопки Add new (Добавить) можно задать исключение новых файлов
В разделе Files excludes for all users (Файлы, исключенные для всех пользователей) перечислены расширения файлов и отдельные файлы, которые специально исключены из процесса резервного копирования.
По умолчанию в список исключенных файлов входят файл подкачки, временные файлы, кэш автономных файлов на стороне клиента, содержимое папок отладки, база данных службы репликации файлов, любые папки кэшей службы репликации файлов в томах с реплицируемыми файлами (например, \Windows\Sysvol), файлы регистрации Windows, журнал Distributed Transaction Coordinator и локальная база данных криптографических сертификатов.
Добавление исключаемых файлов
В список исключаемых файлов можно добавлять новые типы файлов и даже отдельные папки. Это можно сделать для всех заданий резервного копирования или для заданий текущего пользователя. Для добавления нового исключаемого типа файлов выполните последовательность действий, описанную в процедуре 21.1.
Процедура 21.1. Добавление типов файлов в список исключаемых файлов
Щелкните на кнопке Add new (Добавить) в верхнем разделе, где перечислены файлы, исключаемые для всех пользователей, или в нижнем разделе, где перечислены файлы, исключаемые для работающего в данный момент пользователя. Откроется окно Add Excluded Files (Добавить исключаемые файлы).
Выберите тип файлов, которые необходимо исключить из процесса резервного копирования. Воспользуйтесь полем Applies То Path (Применить для файлов в...) для ограничения области применения правила исключения только определенной папкой.
Щелкните на кнопке ОК, чтобы сохранить внесенные изменения и вернуться в окно Options (Параметры).
Щелкните на кнопке ОК, чтобы сохранить внесенные изменения и закрыть окно.
Регистрация типов файлов для исключения
Если при резервном копировании тома по сети на компьютере-источнике процесса резервного копирования необходимо исключить файл, который не внесен в список исключений на локальном компьютере, то расширение файла необходимо зарегистрировать локально на том компьютере, на котором запускается утилита Ntbackup. Самый простой способ рассматривается в процедуре 21.2.
Процедура 21.2. Регистрация типов файлов для исключения при резервном копировании
Откройте сетевой диск в Explorer (Проводник).
Щелкните правой кнопкой мыши на одном из исключаемых типов файлов и выберите из контекстного меню команду Open With (Открыть с помощью).
Выполните двойной щелчок на выполняемом файле, с которым необходимо связать тип файлов. Окно будет закрыто, а приложение будет добавлено в окно Open With (Открыть с помощью).’
Установите переключатель Always Use This Program to Open These Files (Всегда использовать эту программу для открытия файлов этого типа).
Щелкните на кнопке ОК, чтобы сохранить изменения и добавить соответствие типа файла с приложением в системный реестр..
Теперь, когда тип файла зарегистрирован, такие файлы можно исключить из процесса ре-, зервного копирования, воспользовавшись последовательностью действий из процедуры 21.1.
Общие параметры резервного копирования
В меню утилиты Ntbackup выберите команду Tools'^Options (Сервис1^ Параметры) и перейдите на вкладку General (Общие), как показано на рис. 21.5. Большинство параметров не нуждается в объяснениях и для них следует оставить значения, заданные по умолчанию.
Флажок Compute selection information before backup and restore (Оценивать информацию о выборе файлов перед выполнением операций архивации или восстановления) откла-
дывает начало операции резервного копирования и восстановления на время подсчета общего количества файлов и общего объема файлов в байтах. Расчет этих значений отнимает некоторое время, иногда достаточно большое. Если не требуется проверка доступного пространства до создания резервной копии или восстановления, этот флажок можно сбросить.
Options
Gwed jfle**| ЕЫск*Ти»| B*da»U>g| Е*Ш»НЬ»|
Р СдариЬееЫ^Ноембап fade* back» wdfoetore operation* ''.
Р Uw1ge«6lee№t»<iwle*>ipwi'vMiihe«*»e oM^ttnA
Р Va*dda*debedu«>ae|*l«a
Р Вас* tw the cantor* d mounted *w
Р Show dertve«age when I vtart the ВаскцзШМу and Removabte Storage ienot Mvwtg
P yw*»aww»l*iwtliWII*B*ki<>Uies«ndlh|«e .
P Show dwtmeteage whan newtn*ia<r needed.■ .
P Atwapr afcwureotrecoyrabte made without prorcphri»
| OK | Catod | Ад»
Рис. 21.5. Вкладка General (Общие) в окне Options (Параметры) утилиты Ntbackup
Флажок Use the catalogs on the media to seed up building restore catalogs on disk (Использовать каталоги носителей для ускорения построения каталогов восстановления на диске) рекомендуется устанавливать всегда. С точки зрения процесса резервного копирования каталог (catalog) представляет собой индекс файлов, которые сохранены в резервной копии. Кроме этого, в каталоге указывается расположение файлов. Утилита Ntbackup (и другие программы резервного копирования) использует каталог для определения размещения файлов и папок при восстановлении. Обычно при запуске утилиты Ntbackup копия каталога сохраняется на локальном диске в профиле пользователя, который запустил задание резервного копирования. Например, если задание запустил локальный администратор, каталог сохраняется в папке XDocuments and SettingsXAdministratorXLocal SettingsXApplication DataX MicrosoftXWindows NTXNTBackupXCatalog. Каталогам присваиваются шестнадцатеричные порядковые номера с расширением . vOl. В файле индекса с расширением . sm определяются члены каталога.
Сохранив копию каталога на ленте, администратор может значительно ускорить восстановление в том случае, если на сервере восстановления отсутствует локальная копия каталога. Без копии каталога на ленте утилита Ntbackup будет вынуждена сканировать всю ленту для создания каталога перед восстановлением. Создание каталога может занять несколько часов, которые могут показаться вечностью, если восстанавливаются критически важные данные.
Флажок Verify data after the backup completes (Проверять данные после завершения архивации) позволяет добавить дополнительную страховку к резервной копии. После создания резервной копии читается каждая запись на ленте для проверки ее целостности. Эта проверка не затрагивает файловую систему.
Флажок Back up the contents of mounted drives (Архивировать содержимое подключенных дисков) устанавливается по умолчанию. Смонтированный диск (на самом деле — смонтированный том) состоит из точки функционального монтирования NTFS, которая перенаправляет процесс в удаленную файловую систему, например в другой том, папку или на
компакт-диск. Если смонтированный таким образом том имеет отдельную букву диска и включен в процедуру резервного копирования с использованием этой буквы диска, в результате будут получены две идентичные резервные копии. Резервное копирование через точку монтирования не приводит к снижению производительности. Если смонтирован компакт-диск, который необходимо исключить из резервного копирования, сбросьте этот флажок.
Флажок Always allow use of recognizable media without prompting (Разрешить всегда использовать распознанный носитель без предупреждения) установлен по умолчанию, если администратор никогда не открывал консоль диспетчера съемных носителей (Removable Storage Manager — RSM). Если ленточный привод является единственным сменным носителем, который управляется администратором на сервере, этот флажок можно оставить установленным. Это позволит программе Ntbackup связываться непосредственно с диспетчером RSM для получения лент и управления ими без вмешательства администратора. Без установки этого флажка при каждой установке новой ленты в привод от администратора потребуется подготовка ленты к включению в пул резервного копирования.
Заблокированные файлы и служба теневого копирования тома
Приложение Ntbackup работает в контексте безопасности учетной записи Local System, поэтому приложение может получать доступ к файлам системного реестра и файлам базы данных Active Directory или других баз данных, которые поддерживают работу системы, например DHCP, WINS и т.д. Но даже привилегии системной учетной записи не позволяют обойти блокировку файла пользовательским процессом.
Такие приложения, как Word и Access, блокируют собственные файлы, что нарушает работу любой программы резервного копирования. Заблокированные файлы являются причиной все более распространяющейся проблемы, так как пользователи часто работают дома, подключившись через коммутируемое соединение или виртуальную частную сеть. Пользователя может огорчить отсутствие возможности восстановить критически важный файл, из-за того что ему приходилось работать каждую ночь на протяжение недели, когда выполнялось резервное копирование. Рассмотрим фрагмент журнала Ntbackup, в котором демонстрируется подобная проблема:
Backup Status
Operation: Backup
Active backup destination: 4mm DOS
Media name: "TestBackup"
Backup of "C: "
Backup set #1 on media #1
Backup description: "Test"
Media name: "TestMedia"j
Backup Type: Normal
Backup started: on 2/15/2002 at 3:35 AM.
Warning: Unable to open "C:\Test\LiveDocument.doc" - skipped
Reason: The process cannot access the file because it is being used by another process.
Для решения этой проблемы в операционной системе Windows Server 2003 используется служба теневого копирования тома (Volume Shadow — VS). Служба теневого копирования создает моментальную копию заблокированного файла и позволяет утилите Ntbackup создать резервную копию этой моментальной копии, а не оригинального файла. Ниже приведен еще один фрагмент журнала, созданного при включейии теневого копирования:
Backup (via shadow copy) of "C: "
Backup set #1 on media #1
Backup description: "Test"
Media name: "TestMedia"
Backup Type: Normal
Backup started: on 2/25/2002 at 3:39 AM
Backup completed on 2/25/2002 at 3:39 AM
Directories: 2
Files: 21
Bytes: 4,437
Time: 4 seconds
Служба теневого копирования тома, Vssvc. ехе, создает моментальные копии файлов в разделах NTFS и для хранения временных файлов также использует разделы NTFS, поэтому в томе должно быть достаточно свободного места для хранения наибольшего заблокированного файла.
Если в системе отсутствуют тома NTFS или в существующих томах недостаточно свободного дискового пространства, утилита Ntbackup возвращается к использованию стандартного метода обработки заблокированных файлов. При стандартном методе Ntbackup в течение 30 секунд пытается повторно прочитать файл, после чего в случае неудачи файл исключается из резервной копии.
Утилиту Ntbackup можно настроить на отказ от использования теневых копий. Это позволяет отказаться от резервного копирования больших файлов баз данных. Соответствующие параметры доступны в списке дополнительных параметров резервного копирования (рис. 21.6).
^Advanced Backup Options
Г Be* i«d«*<M ЯП Remote Storage Г Vetostdeteetarbeckup
P Я ро«Ы». сотрем the hookup dote to wrvetpece. Г йп.^»Ч:с^ - ' r^- ■
Г Oedbie volume thadow copy В»*шТиж'
, Detorpten-
! Backtuttetectedltet.endmefkieoohfleotbeckatiup
Puc. 21.6. Дополнительные параметры резерв- дj ;
ного копирования. Возможность включения те- ■' . ■ г1" ^—ч ^ । ;
невого копирования тома■" "" 1■
Восстановление системы на рабочих станциях Windows ХР .
Возможность восстановления системы (System Restore) доступна только в операционной системе Windows ХР. Эта служба создает периодические моментальные копии конфигурации системы, которые можно использовать для отката до предыдущего состояния. Моментальные копии создаются ежедневно, а также при каждой установке нового приложения или изменении конфигурации операционной системы. Моментальные копии конфигурации системы называются точками восстановления (restore points).
Для создания моментальной копии или отката конфигурации вручную к предыдущей точке восстановления можно воспользоваться возможностью System Restore (Восстановле-
00ние системы) в составе Help and Support Center (Центр справки и поддержки). Пункт доступа к возможности восстановления системы доступен на домашней странице Help and Support Center (Центр справки и поддержки). Щелкните на ссылке, чтобы открыть страницу, позволяющую создать точку восстановления или откатить конфигурацию до созданной ранее точки восстановления. Если выбрать откат конфигурации, будет предоставлено окно с изображением календаря, на котором можно выбрать один из дней создания точек восстановления и просмотреть точки восстановления, которые были созданы в выбранный день. На рис. 21.7 показаны точки восстановления, созданные до установки пакета Microsoft Office ХР.
0
0
Select a Restore Point
The Mowing calendar dsplays in bold al of the dates that have restore points avalable. The 1st dsplays the restore ports that are avalable for the selected date.
Possfcte types of restore ports are: system checkpoints (scheduled restore ports created by your computer), manual restore ports (restore ports created by you), and instalation restore ports (automatic restore ports created when certain proyams are instaled).Possfcte types of restore ports are: system checkpoints (scheduled restore ports created by your computer), manual restore ports (restore ports created by you), and instalation restore ports (automatic restore ports created when certain proyams are instaled).
Possfcte types of restore ports are: system checkpoints (scheduled restore ports created by your computer), manual restore ports (restore ports created by you), and instalation restore ports (automatic restore ports created when certain proyams are instaled).
Possfcte types of restore ports are: system checkpoints (scheduled restore ports created by your computer), manual restore ports (restore ports created by you), and instalation restore ports (automatic restore ports created when certain proyams are instaled).
<8*J №*> I йп* |
Рис.21.7. Страница восстановления системы, на которой показан календарь точек восстановления с подробной информацией о существующих точках восстановления
Если выбрать откат до более ранней точки восстановления, восстановятся только измененные системные выполняемые файлы. Файлы данных не восстанавливаются. Это значит, что пользователи не потеряют данные в результате восстановления системы, но они могут потерять критические ссылки внутри приложений. Чем дальше назад во времени откатывается конфигурация системы, тем больше вероятность нарушения согласованности системы.
Откаты не влияют на зашифрованные файлы. Нельзя дешифровать файл, просто откатив систему до момента, когда файл не был зашифрован.
Вопросы безопасности
При добавлении учетной записи в группу Backup Operators (Операторы архива) или при предоставлении разрешений SeBackupPermission и SeRestorePermission другим способом, учетная запись пользователя получает право создавать резервную копию любого файла на компьютере, независимо от значения дескриптора безопасности или шифрования. Операторы архива могут снимать ограничения безопасности с файлов во время восстановле-
ния. Другими словами, сложно себе представить большую брешь в системе безопасности, чем бесконтрольное предоставление привилегий оператора архива.
Эта проблема характерна и для приложений резервного копирования от сторонних производителей, в которых используются клиентские агенты резервного копирования. Эти агенты работают в контексте безопасности учетной записи с разрешениями группы Backup Operators (Операторы архива). Эти привилегии позволяют использовать учетные записи агентов восстановления для других целей. Очень .часто практически каждый администратор регистрируется от имени учетной записи с привилегиями резервного копирования.
Если необходимо запускать ночные операции резервного копирования без использования учетной записи Administrator (Администратор), можно создать специальную учетную запись, которая будет входить в группу Backup Operators (Операторы архива) и запускать резервное копирование с помощью Task Scheduler (Планировщик заданий) (рис. 21.8). Task Scheduler (Планировщик заданий) доступен из Control Panel (Панель управления).
Та* ]шшМ>| Satt«»l
ЙОТ . 1s по Лтсоп М normal /| JoblO1 Л$ /р 4mm DDS /от
с^р ’ |c\WIND0WSVqirtina2——
*"•¥ jcOMRANYMjeckupadmH Setp**nj; | .
f7 СнйМ4ЫийЙНШ1иИ^в9*4М*1Н * •-
| ' 'OK I Canal I
Puc. 21.8. Свойства задания в Task Scheduler (Планировщик заданий). В поле Run as (Запустить от имени) вводятся альтернативные регистрационные данные для запуска команды
Физический доступ к лентам с резервными копиями также имеет значение. Во многих компаниях пользователи без соответствующей авторизации не могут подходить к работающим серверам ближе чем на 50 метров, но резервные копии передаются обычными курьерами и обрабатываются работающими по контракту сотрудниками. Для обеспечения безопасности удаленного хранилища лент с резервными копиями необходимо воспользоваться услугами известных и лицензированных компаний.
Наконец, не забывайте о возможности потери данных в результате хищения. Это особенно важно для малого бизнеса в больших офисных районах с малоэтажной застройкой. Бросок камня в окно — и компьютер уже в руках злоумышленника. Серверы выглядят впечатляюще, поэтому похитители могут потратить дополнительно несколько минут специально на то, чтобы украсть сервер. Не приумножайте потери, оставляя резервные копии в легкодоступном месте.
Резервное копирование файлов состояния системы
В операционных системах Windows Server 2003 и Windows 2000 компания Microsoft собрала большое количество файлов под общим названием состояние системы (System State). Для сохранения целостности данных и работоспособности операционной системы эти файлы должны копироваться и восстанавливаться, как единое целое. В состав файлов состояния системы входит следующее.
База данных Active Directory, ntds.dit, и связанные с базой данных журнал и файлы контрольной точки в каталоге \ Windows\NTDS
Разделы системного реестра из каталога \Windows\System32\Conf ig
База данных регистрации классов СОМ+
Файлы, защищенные службой защиты файлов Windows (это большинство файлов в каталоге \Windows и большинство файлов от компании Microsoft в каталоге \Program Fi les)
Системные файлы из корневого каталога загрузочного диска: Ntdetect.com, Ntldr, Boot.ini,Bootsect.dos, Ntbootdd.sys
Файлы базы данных Help and Support Center (Центр справки и поддержки), если центр сертификации установлен
Содержимое каталога \Windows\Sysvol, в котором хранятся групповые политики и сценарии
Метабаза IIS (если службы IIS установлены)
База данных кластеров (если установлена служба Cluster)
Утилита Ntbackup не позволяет выполнять резервное копирование состояния системы с другого компьютера по сети. И не совершите ошибку, решив, что копирование папки Admin$ является аналогом резервного копирования состояния системы. Многие файлы блокируются при запуске утилиты Ntbackup по сети. Чтобы выполнять централизованное резервное копирование, придется приобрести коммерческий продукт для резервного копирования.
Резервное копирование в файл
Одной из более приятных возможностей утилиты Ntbackup является сохранение резервных копий в файл, а не на ленту. Это делает возможным быстрое резервное копирование локально на рабочих станциях с последующим переносом копий на сменный носитель или на сетевой диск. Резервное копирование на основе файлов также является важным компонентом управления шифрованными файлами. Для перемещения зашифрованных файлов с одного компьютера на другой их необходимо скопировать в файл резервной копии, после чего файл резервной копии перемещается на другой компьютер и восстанавливается на новом месте.
Резервное копирование в файл имеет собственные недостатки. Пользователи рабочих станций с локальными привилегиями Backup Operators (Операторы архива) могут использовать утилиту Ntbackup для резервного копирования всего жесткого диска в файл на сервере. Рассмотрите возможность установки групповой политики, которая ограничивает доступ к утилите Ntbackup.
Аварийное восстановление системы
Восстановление отказавшего системного раздела всегда считалось утомительной задачей. Обычно необходимо отформатировать раздел, переустановить операционную систему,
смонтировать ленту с резервной копией, создать каталог ленты и запустить полное восстановление с ленты.
Как подсказывает название возможности, аварийное восстановление системы (Automated System Recovery — ASR) значительно упрощает этот процесс. В результате резервного копирования для аварийного восстановления системы создается стандартная резервная копия раздела операционной системы, после чего каталог и информация о конфигурации сохраняются на гибком диске. Чтобы восстановить раздел операционной системы с помощью автоматического восстановления системы, достаточно загрузить компьютер с помощью установочного компакт-диска Windows Server 2003 с установленной в ленточном приводе лентой с резервной копией, нажать клавишу <F2> и выбрать возможность аварийного восстановления системы. После этого процесс будет выполняться автоматически. Функция аварийного восстановления системы устанавливает операционную систему с компакт-диска, после чего монтирует ленту и запускает восстановление системы. Не забудьте извлечь гибкий диск из привода после завершения первой текстовой фазы восстановления. Через час можно вернуться к серверу и убедиться в его работоспособности.
Для создания резервной копии для аварийного восстановления системы воспользуйтесь мастером аварийного восстановления системы из состава утилиты Ntbackup. Единственной возможностью является интерактивное резервное копирование. Нельзя запланировать резервное копирование для автоматического восстановления системы с помощью Task Scheduler (Планировщик заданий). Мастер состоит из одного окна, в котором у администратора запрашивается устройство для записи резервной копии и метка носителя (или файл резервной копии и имя этого файла). Единственной операцией со стороны администратора является предоставление пустого отформатированного гибкого диска, на котором сохраняются файлы Setup Information Files (SIF).
Йри аварийном восстановлении системы сохраняется оригинальное разбиение диска на разделы, поэтому данные на других томах этого диска не затрагиваются. Если загрузочный диск зеркалируется, придется "разбить зеркало” до запуска аварийного восстановления системы.
Одной из проблем при использовании аварийного восстановления системы является загрузка драйверов устройств от сторонних производителей, необходимых на начальном этапе загрузки. Обычно это драйверы устройств массового хранения, для загрузки которых необходимо нажать клавишу <F6> во время интерактивной процедуры установки. Для автоматической загрузки дополнительных драйверов необходимо изменить файл As г. sif, который используется в качестве сценария автоматического восстановления системы. В файл сценария необходимо добавить раздел [ InstallFiles ], формат которого выглядит следующим образом:
[InstallFiles]
[Installfile-Key]=[System-Key],[Source-Media-Label], [Source-Device], [Source-File-Path], [Destination-File-Path], [Vendor-Name], [Flags]
Ниже приведено описание компонентов раздела [InstallFiles]. Двойные кавычки в некоторых примерах являются частью записи в файле As г. s i f.
[Installfile-Key]=[System-Key]. Параметр Installfile-Key представляет собой уникальный порядковый номер, назначенный каждой записи. System-Key является индексом в разделе [System], который определяет дисковый раздел, в который устанавливается операционная система. Например, первая запись в разделе [InstallFiles] со ссылкой на первую запись в разделе [System] будет выглядеть как 1=1.
[Source-Media-Label]. Это метка, которая назначается гибкому диску, содержащему дополнительные файлы. Например, если необходимо загрузить драйвер адаптера SCSI с гибкого диска, назначьте гибкому диску метку SCSIFiles. После этого добавьте запись • SCSIFiles ” в файл Asr. sif. Во время автоматического восстановления системы будет выдан запрос на предоставление диска с указанной меткой.
[Source-Device]. Эта запись определяет путь к устройству с носителем, на котором хранится файл. Путь указывается в объектном пространстве имен, например, " \Device\FloppyO11 или "\Device\CdRomO".
[Source-File-Path]. Это путь и имя устанавливаемого файла. Чтобы установить более одного файла, необходимо создать несколько записей в разделе [ InstallFiles ]. Не начинайте строку пути с обратной косой черты. Например, " Scsidrvr. sys" описывает путь к файлу в корневом каталоге гибкого диска.
[Destination-File-Path]. В этот каталог копируется файл. Не начинайте значение параметра с обратной косой черты, например " % sys t emroot %\Syst em3 2\Dr iver s\Sc s i drvr.sys".
[Vendor-Name]. Это название производителя драйвера. Эта запись используется только для удобства администратора, поэтому может иметь любое значение, например "Дополнительный драйвер SCSI".
[Flags]. Это флаги, которые заставляют процедуру автоматического восстановления системы запрашивать гибкий диск. Допустимые значения показаны ниже, например "0x00000001"..
Ниже приведен перечень флагов, которые могут использоваться в разделе [InstallFiles].
0x00000001. Всегда запрашивать предоставление гибкого диска. Это позволяет процедуре установки запросить предоставление гибкого диска сразу после фазы копирования файлов в процессе установки.
0x00000006. Запрашивать необходимые файлы. То же, что и0х00000001, но процедура автоматической установки не будет продолжать работу без необходимого файла.
0x00000010. Перезаписывать существующие файлы.
0x00000020. Запрашивать разрешение на перезапись файлов.
Ниже показан пример параметров, которые определяют запрос дополнительного драйвера
SCSI у пользователя:■
[InstallFiles]\
=1, "SCSIFiles", "\DeVice\FloppyO", "Scsidrvr.sys" , "%systemroot%\System32\Drivers\Scsidrvr.sys", "Adaptec", 0x00000001
Сменные носители
Всеми функциями резервного копирования можно управлять с помощью утилиты Ntbackup, но управление лентами обеспечивается службой RSM (Removable Storage Management — управление сменными носителями).
Служба RSM управляется с помощью оснастки ММС, которая называется Removable Storage (Сменные носители). Соответствующая оснастка предоставляется в составе консоли Computer Management (Управление компьютером), как показано на рис. 21.9. Для выполнения большинства функций, например монтирования и размонтирования носителей, а также выделения носителей для определенной службы, можно воспользоваться утилитой Rsm.exe из командной строки. Синтаксис утилиты Rsm описывается в Help and Support Center (Центр справки и поддержки).
Восстановление потерянного гибкого диска аварийного восстановления системы
На созданном мастером ASR гибком диске находятся два файла SIF— Asr.sif и Asrpnp.sif. Кроме этого, на гибком диске находится копия файла Setup. log. Копии этих файлов хранятся и на ленте. Эти файлы можно с ленты скопировать на отформатированный гибкий диск. Файлы хранятся в папке \Windows\Repair.
JttBLL—-LltaxtasteS^Mediacreate...Off-line MediaIdfe^Mediacreate...Off-lineMedaIdfe^Mediacreate...Off-line MedaIdfeSeparating Sy...HPC1537ASC5ISe... idfeJttBLL—-LltaxtasteS^Mediacreate...Off-line MediaIdfe^Mediacreate...Off-lineMedaIdfe^Mediacreate...Off-line MedaIdfeSeparating Sy...HPC1537ASC5ISe... idfe^ Me Actiwi View Wndo* M*...^ Me Actiwi View Wndo* M*...• * e-® -r # Q 6: Ф1Л « ^ ^ ^ < . J^'^vice Manager -- ^ StorageEV^ Removable Storage• * e-® -r # Q 6: Ф1Л « ^ ^ ^ < . J^'^vice Manager -- ^ StorageEV^ Removable Storage. S ^ Media Pools
JttBLL—-Lltaxtaste
S^Mediacreate...Off-line MediaIdfe
^Mediacreate...Off-lineMedaIdfe
^Mediacreate...Off-line MedaIdfe
Separating Sy...HPC1537ASC5ISe... idfe
JttBLL—-Lltaxtaste
S^Mediacreate...Off-line MediaIdfe
^Mediacreate...Off-lineMedaIdfe
^Mediacreate...Off-line MedaIdfe
Separating Sy...HPC1537ASC5ISe... idfe
^ Me Actiwi View Wndo* M*...
^ Me Actiwi View Wndo* M*...
• * e-® -r # Q 6: Ф1Л « ^ ^ ^ < . J^'^vice Manager -- ^ Storage
EV^ Removable Storage
• * e-® -r # Q 6: Ф1Л « ^ ^ ^ < . J^'^vice Manager -- ^ Storage
EV^ Removable Storage
:• A-^ Free
;0 & Libraries: Ж Work Queue ' у Operator Requests • • Disk Defragmenter;0 & Libraries: Ж Work Queue ' у Operator Requests • • Disk Defragmenter2^ . _»№$i<»ULjdZEaasSsafeZZAlocatedAlocated?Alocatedl;Alocated;2^ . _»№$i<»ULjdZEaasSsafeZZAlocatedAlocated?Alocatedl;Alocated;p 4mm DOSУ CD-ROMImport® Unrecognized0 О Backup
;0 & Libraries
: Ж Work Queue ' у Operator Requests • • Disk Defragmenter
;0 & Libraries
: Ж Work Queue ' у Operator Requests • • Disk Defragmenter
2^ . _»№$i
<»ULjd
ZEaasSsafeZZ
Alocated
Alocated?
Alocatedl;
Alocated;
2^ . _»№$i
<»ULjd
ZEaasSsafeZZ
Alocated
Alocated?
Alocatedl;
Alocated;
Puc. 21.9. Консоль Computer Management ("Управление компьютером) и оснастка Removable Storage (Сменные носители)
Служба RSM управляет работой всех сменных носителей в системе, начиная с ленточных приводов с единственной лентой и приводов компакт-дисков и заканчивая дисководами на 100 компакт-дисков и роботизированными библиотеками. Служба RSM распределяет носители в один из четырех пулов носителей. Ниже описаны эти пулы.
Свободный (Free). В этот пул входят носители, которые отмечены как свободные и доступны для распределения.
Импортированный (Import). В этот пул входят носители, которые отформатированы с использованием формата Microsoft Таре Format (MFT) и имеют распознаваемую метку ленты, но еще не распределены (allocated) для конкретного устройства. Это касается лент с резервными копиями, созданными в классической операционной системе Windows NT.
Нераспознанный (Unrecognized). В этот пул входят неотформатированные ленточные носители или носители, имеющие неизвестный формат.
Оснастка Removable Storage (Сменные носители) позволяет выбирать пользователей, которые смогут получать доступ к определенному устройству и носителям. Для этого используются стандартные списки контроля доступа, доступные на вкладке Security (Безопасность) в окне свойств устройства. Пример окна свойств устройства для ленточного привода показан на рис. 21.10.
Существует три набора разрешений, которые могут применяться к объекту Removable Storage (Сменные носители).
Use. Позволяет пользователю монтировать и размонтировать носитель в устройстве.
Modify. Позволяет пользователю создавать и удалять пулы носителей и выделять и освобождать носитель в этих пулах..
Control. Позволяет пользователю отправлять команды библиотеке для управления физическими операциями.
Имена лент и утилита Ntbackup
Служба Removable Storage (Сменные носители) предоставляет интерфейс для работы с лентами для утилиты Ntbackup и других продуктов резервного копирования. Это хорошо,
так как приложения резервного копирования освобождаются от необходимости предоставлять функции управления лентами, но эта возможность может оказаться и недостатком, поскольку программа резервного копирования лишается реального управления лентами. Все операции управления лентами осуществляются через службу Removable Storage (Сменные носители).
Рис. 21.10. Свойства безопасности для ленточных устройств в оснастке Removable Storage (Сменные носители)
Одним из источников раздражения, связанного с взаимодействием утилиты Ntbackup и службы Removable Storage (Сменные носители), является механизм обработки имен лент. Утилита Ntbackup не имеет доступа к информации о том, смонтирована ли одна лента или применяются ленты в большой многоленточной либо роботизированной библиотеке магнитных лент. Поскольку для библиотек требуются специальные функции управления, утилита Ntbackup вынуждена предполагать существование роботизированной библиотеки. Это значит, что каждая лента должна иметь определенное имя, которое используется при запросе ленты из библиотеки. При перезаписи ленты применяется имя, которое может использоваться в случае восстановления с ленты.
В результате может появиться нечто подобное замкнутому циклу при настройке ротации лент с резервными копиями. Утилита Ntbackup пытается обнаружить ленту с определенным именем и записывает имя ленты в процессе перезаписи. Если использовать принятую по умолчанию метку носителя Media Created On <дата>, то настройка резервного копирования для поиска этой даты каждый день или каждую неделю окажется нетривиальной задачей.
Неуправляемое резервное копирование
Обычно при запуске утилиты Ntbackup как части задания, выполняемого по расписанию, необходимо указывать имя запрашиваемой ленты. Это требование предотвращает случайную перезапись ленты в библиотеке. Если лента устанавливается в единственный привод, имена лент играют незначительную роль. В последнем случае задание на резервное копирование должно выполняться при установке любой ленты в привод.
Существует недокументированный параметр командной строки для утилиты Ntbackup, который называется /шп (Unmanaged) и заставляет утилиту Ntbackup игнорировать имя ленты и просто использовать ленту, смонтированную в приводе. Параметр /шп можно добавить в описание задания в Task Scheduler (Планировщик заданий).
При использовании параметра /шп необходимо добавить параметр /р, с помощью которого выбирается пул ленточных носителей, например "4mm DAT". Имена пулов носителей можно получить на кднсоли RSM.
Это решение недопустимо при использовании роботизированной библиотеки магнитных лент. Нежелательно, чтобы библиотека выбирала и перезаписывала случайную ленту. При использовании автоматизированной библиотеки всегда необходимо указывать конкретные имена лент при настройке заданий на резервное копирование.
При настройке лент для ротации необходимо создавать отдельное задание для каждого дня недели и указывать метки лент, соответствующие заданию. Например, для еженедельной ротации лент можно настроить задание на понедельник, которое будет записывать данные на ленту с меткой Monday. Задание будет искать ленту с меткой Monday. Если при запуске задания Monday в приводе будет находиться лента с меткой Friday, резервное копирование завершится неудачно.
Для использования при такой конфигурации пустой ленты, на ленту необходимо записать подходящую метку. Компания Microsoft должна предоставлять для этого специальную утилиту, но эта утилита не предоставляется. Необходимо выполнить резервное копирование вручную, в процессе которого и будет записана метка. Дополнительная информация об отказе от конкретных меток лент приводилась во врезке “Неуправляемое резервное копирование’’.
Утилиты резервного копирования от сторонних производителей
На поле резервного копирования в операционных системах Windows играет множество игроков. В табл. 21.1 перечислены названия и продукты основных производителей в этой области. Набор возможностей этих продуктов меняется постоянно, поэтому за самой актуальной информацией стоит обратиться на Web-сайт соответствующей компании.
Таблица 21.1. Утилиты резервного копирования от сторонних производителей
Программа
Компания
Web-адрес
ArcServe
Computer Associates
www.cai.com
Backup Exec
Veritas
www.veritas.com
Networker
Legato
www.legato.com
ADSM
IBM
www.pc.ibm.com
Novastor
Novastor
www.novastor.com
Ultrabac
BEI Corporation
www.ultrabac.com
Операции резервного копирования и восстановления
В этом разделе приводятся пошаговые инструкции по интерактивному резервному копированию, планированию резервного копирования и восстановлению файлов с резервных копий.
Интерактивное резервное копирование
Резервное копирование можно выполнять интерактивно в окне утилиты Ntbackup. Кроме этого, можно воспользоваться Task Scheduler (Планировщик заданий), чтобы задать запуск резервного копирования по расписанию. В отличие от операционной системы Windows NT, в операционной системе Windows Server 2003 утилиту Ntbackup можно использовать как в интерактивном, так и в пакетном режимах. Для примера в этом разделе будет использовано предположение, что доступна пустая лента. Если на ленте уже хранится резервная копия, несколько раз будет выдан запрос на подтверждение перезаписи ленты и ее содержимого, а также запрос об импорте ленты в пул свободных носителей (Free) службы RSM.
В процедуре 21.3 приводится последовательность действий по настройке и запуску интерактивного резервного копирования в режиме Advanced утилиты Ntbackup.
Процедура 21.3. Выполнение интерактивного резервного копирования
Запустите утилиту Ntbackup с помощью команды Start^Programs^Accessories^System Tools^Backup (Пуск^Программы^Стандартные^Служебные^Архивация данных). Переключитесь в режим Advanced из окна мастера.
Перейдите на вкладку Backup (Резервное копирование), которая показана на рис. 21.11. Выберите диски и папки, которые должны быть включены в резервную копию. Пункт Му Network Places (Мое сетевое окружение) можно использовать для выбора совместно используемых каталогов, хранящихся на других серверах.
. *Ш1*1. *Ш1*1В меню Ntbackup выберите Tools^Options (Сервис=>Параметры). Откроется окно Options (Параметры). Перейдите на вкладку Backup Туре (Тип архива). Выберите Default Backup Туре (Обычный).
. *Ш1*1
. *Ш1*1
W*e* B*fcwjflM=**<Mei«e»M»*lS<i*d*r*d
ОЙ Desktop :E? © J My Computer■’ ® D41* ^ Fkfpy (A:)a Q^ NTFS (D:)" 33 Q<m» Local D«k(C:): @ Q-м» Datal (F:)' S 0^» Data2(G:J иИ^рлзн-1 ffl QJ, NB3EFRE_EN (E IS QSS °h21 on'pto1\ca System State?® QО My Documents® 0*9 МУ Network PlacesОЙ Desktop :E? © J My Computer■’ ® D41* ^ Fkfpy (A:)a Q^ NTFS (D:)" 33 Q<m» Local D«k(C:): @ Q-м» Datal (F:)' S 0^» Data2(G:J иИ^рлзн-1 ffl QJ, NB3EFRE_EN (E IS QSS °h21 on'pto1\ca System State?® QО My Documents® 0*9 МУ Network PlacesИ ^ SIS Common Store Fie Folder Q О System Volume Inf... Fie FolderИ ^ SIS Common Store Fie Folder Q О System Volume Inf... Fie FolderТ*Т*12/5/2001 10:38 PM12/6/2001 6:22AM12/5/2001 10:03 PM12/5/2001 10:38 PM12/6/2001 6:22AM12/5/2001 10:03 PM
ОЙ Desktop :
E? © J My Computer■
’ ® D41* ^ Fkfpy (A:)
a Q^ NTFS (D:)
" 33 Q<m» Local D«k(C:)
: @ Q-м» Datal (F:)
' S 0^» Data2(G:J иИ^рлзн-1 ffl QJ, NB3EFRE_EN (E IS QSS °h21 on'pto1\ca System State?
® QО My Documents
® 0*9 МУ Network Places
ОЙ Desktop :
E? © J My Computer■
’ ® D41* ^ Fkfpy (A:)
a Q^ NTFS (D:)
" 33 Q<m» Local D«k(C:)
: @ Q-м» Datal (F:)
' S 0^» Data2(G:J иИ^рлзн-1 ffl QJ, NB3EFRE_EN (E IS QSS °h21 on'pto1\ca System State?
® QО My Documents
® 0*9 МУ Network Places
И ^ SIS Common Store Fie Folder Q О System Volume Inf... Fie Folder
И ^ SIS Common Store Fie Folder Q О System Volume Inf... Fie Folder
Т*
Т*
12/5/2001 10:38 PM
12/6/2001 6:22AM
12/5/2001 10:03 PM
12/5/2001 10:38 PM
12/6/2001 6:22AM
12/5/2001 10:03 PM
l^-^l
ВбскертеАвгМаып* _
|\\backups^^
Puc. 21.11. Окно выбора файлов и каталогов для резервного копирования
Активизируйте вкладку Backup Log (Журнал резервного копирования). В группе Information (Информация) выберите переключатель Detailed (Подробная) или Summary (Краткая сводка). По умолчанию выбран переключатель Summary (Краткая сводка).
Щелкните на кнопке ОК, чтобы сохранить заданные параметры и вернуться в основное окно Backup (Резервное копирование).
В поле Backup destination (Местоназначение архива) выберите ленточный привод.
В поле Backup media or file name (Носитель архива или имя файла) выберите пункт New (Создать). Это заставит утилиту Ntbackup извлечь пустую ленту из пула Free носителей службы RSM.
Щелкните на кнопке Start Backup (Начать). Откроется окно Backup Job Information (Сведения о задании резервного копирования), которое показано на рис. 21.12. Поле If The Media Is Overwritten... (Если носитель уже содержит архивы...) имеет важное значение. В поле указывается имя, которое записывается на ленту при перезаписи.
Щелкните на кнопке Advanced (Дополнительно). Откроется окно Advanced Backup Options (Дополнительные параметры резервного копирования), показанное на рис. 21.13.
Г* 6e*tpd*nhMkltRwe*$iewe.
Р у*6г4р^Ы*р.... ,
Рис. 21.12. В окне Backup Job Information (Сведения о задании резервного копирования) показаны принятые по умолчанию значение в поле Backup Description (Описание) и метка носителяРис. 21.12. В окне Backup Job Information (Сведения о задании резервного копирования) показаны принятые по умолчанию значение в поле Backup Description (Описание) и метка носителяу' *
Рис. 21.12. В окне Backup Job Information (Сведения о задании резервного копирования) показаны принятые по умолчанию значение в поле Backup Description (Описание) и метка носителя
Рис. 21.12. В окне Backup Job Information (Сведения о задании резервного копирования) показаны принятые по умолчанию значение в поле Backup Description (Описание) и метка носителя
***№и
| NormalJ
Oetaveei ->
* ti*4yNi#i»<*s>W«*l^^eiHijeyil|*'' -|
R^ • c«*J
Puc. 21.13. Окно Advanced Backup Options (Дополнительные параметры резервного копирования), в котором показаны принятые по умолчанию параметры резервного копирования
Установите флажки Verify data after backup (Проверка данных после архивации) и If possible, compress the backup data to save space (Если возможно, сжимать архивируемые данные). После этого щелкните на кнопке ОК, чтобы сохранить заданные параметры и вернуться в окно Backup Job Information (Сведения о задании резервного копирования).
Щелкните на кнопке Start Backup (Запустить). Если в пуле Free доступен носитель, но он был подготовлен без использования метки носителя Free, служба RSM выдаст информационное сообщение и запрос на подтверждение перезаписи ленты.
После начала резервного копирования откроется окно Backup Progress (Процесс резервного копирования) и начнется запись файлов на ленту. Если отменить задание, утилита Ntbackup выдаст запрос на завершение резервного копирования текущего файла. Можно отказаться и завершить резервное копирование немедленно.
После завершения резервного копирования в окне Backup Progress (Процесс резервного копирования) будет выдана информация о состоянии резервной копии. Щелкните на кнопке Report (Отчет), чтобы запустить редактор Notepad (Блокнот) и просмотреть жур-
нал резервного копирования. Ниже представлен пример журнала при резервном копировании единственного файла:
Backup Status
Operation: Backup
Active backup destination: 4mm DDS
Media name: "New"
Backup of "C: "
Backup set #1 on media #1
Backup description: "Monday"
Backup Type: Normal
Backup started: on 2/27/2002 at 10:22 AM
Folder C:\
Backup completed on 2/27/2002 at 10:46 AM
Directories: 38
Files 239'
Bytes: 1,208,708
Time: 45 seconds
После завершения резервного копирования можно закрыть окно Backup Progress (Процесс резервного копирования). Не забудьте пометить ленту и спрятать ее в безопасном месте.
Планирование резервного копирования
После проверки (с помощью интерактивного задания) работоспособности системы резервного копирования можно составлять расписание для ежедневного резервного копирования. Не забудьте скоординировать резервное копирование с антивирусным сканированием. Для настройки и планирования задания можно воспользоваться утилитой Ntbackup, как описано в процедуре 21.4.
Процедура 21.4. Настройка и планирование резервного копирования
Replace Existing Backups (Заменить существующие архивы). В качестве дополнительной меры безопасности можно установить флажок Allow The Owner... (Задать владельца...).
Щелкните на кнопке Next (Далее). Откроется окно Backup Label (Метка архива). В поле Media Label (Метка носителя) введите имя, которое будет записано на ленту. В поле Backup Label (Метка архива) введите имя, которое будет отображаться в каталоге.
Щелкните на кнопке Next (Далее). Откроется окно When То Back Up (Когда архивировать). Выберите переключатель Later (Позже) и введите имя задания. После этого щелкните на кнопке Set Schedule (Установить расписание). Откроется окно Schedule Job (Запланировать задание).
Воспользуйтесь переключателем Schedule Task (Расписание задания), чтобы задать периодичность резервного копирования, например Daily (Ежедневно) или Weekly (Еженедельно). После этого введите значение в поле Start Time (Начать в).
Щелкните на кнопке ОК, чтобы вернуться в основное окно мастера, и щелкните на кнопке Next (Далее). Откроется окно Set Account Information. Введите регистрационные данные учетной записи, предназначенной для выполнения резервного копирования.
Щелкните на кнопке ОК, чтобы сохранить заданные параметры. Откроется окно со сводкой выбранных параметров. Щелкните на кнопке Finish (Готово) для сохранения изменений в качестве запланированного задания. В календаре появится пиктограмма задания для каждого запланированного запуска.
После этого от администратора требуется установка подходящих лент в привод в зависимости от параметров настройки задания. В следующем разделе рассматривается выполнение этой же задачи с помощью мастера резервного копирования (Backup Wizard).
Структура задания резервного копирования
При наступлении момента запланированного задания Task Scheduler (Планировщик заданий) запускает утилиту Ntbackup как фоновый процесс. При запуске утилите предоставляются па- раметры командной строки, зависящие от параметров, которые были заданы в окнах мастера резервного копирования. Ниже показан пример строки запуска задания на печать:
C:\Windows\System32\ntbackup.exe backup "@С:\Documents and Settings 4>\Administrator\Local Settings\Applicbtion Data\Microsoft\ 4>Windows NT\NTBackup\data\Modnay.bks" /n “Monday" /d "Monday" /v:yes 4> /r:no /rs:no /hc:on /m normal / j :"Monday Backup" /p "4mm DOS"
Это длинная командная строка, так как путь к файлу резервной копии спрятан глубоко в пользовательском профиле администратора. Ниже дано описание использованных параметров.
о /п. Имя ленты, которая должна использоваться этим заданием. Лента с таким именем должна быть смонтирована в приводе. В противном случае выполнение задания будет прервано.
о /d. Имя ленты, которое будет записано при перезаписи. Это имя должно совпадать с именем в параметре /п, чтобы ленту можно было использовать в следующий раз.
о /V. Включает проверку данных после записи.
о /г. Устанавливает ограничение на доступ. Только члены группы Administrators (Администраторы) могут получать доступ к ленте.
о /rs. Включает резервное копирование на удаленное хранилище.
/he. Включает аппаратное сжатие.
/пл. Устанавливает тип резервной копии.
/j. Определяет имя задания.
/р. Указывает устройство резервного копирования.
I
Если используется единственное устройство для записи на ленты и нет желания постоянно указывать имена лент, воспользуйтесь параметром /иш. Дополнительную информацию об остальных параметрах командной строки можно получить с помощью команды ntbackup /?.
Восстановление файлов.
Даже самая лучшая в мире система ротации резервных копий не поможет, если файлы с ленты нельзя считать на жесткий диск. В этом разделе рассматривается восстановление отдельных файлов, так как с этой процедурой связано большинство запросов восстановления. Полное восстановление данных в томе работает по тому же принципу — просто выполняется копирование большего количества файлов. Полное восстановление тома операционной системы рассматривалось в разделе “Аварийное восстановление системы" этой главы.
При настройке задания на восстановление будет предоставлено три возможных варианта записи восстанавливаемых файлов.
■ Original Location (Исходное размещение). Если выбран этот переключатель, утилита восстанавливает файлы в том же каталоге, в котором они находились в момент создания резервной копии. Этот вариант оказывается наиболее полезным при восстановлении целого тома. В обычных условиях не требуется восстановление отдельных пользовательских файлов в оригинальный каталог, так как пользователь мог внести изменения в файл, который находится на диске, и не согласиться с перезаписью этих изменений.
■ Alternate Location (Альтернативное размещение). Выбор этого переключателя позволяет ввести путь или щелкнуть на кнопке Browse (Обзор). Воспользуйтесь этим переключателем для поиска папки, в которой будут храниться восстанавливаемые файлы. В указанную папку записывается оригинальная структура каталогов. Этот вариант оказывается наиболее подходящим для восстановления целого поддерева каталогов, а не отдельных файлов.
■ Single Folder (В одну папку). Выбор этого переключателя также позволяет ввести путь или воспользоваться кнопкой Browse (Обзор). Найдите папку, в которой будут храниться восстановленные файлы. При выборе этого переключателя оригинальная структура каталогов не сохраняется. Этот вариант является наиболее подходящим для восстановления отдельных файлов. Если выбрать восстановление целого каталога при выборе пункта Single Folder, все файлы будут восстановлены в выбранный каталог.
В процессе настройки будут выданы запросы на установку параметров безопасности для восстановленных файлов. Доступны следующие варианты.
Restore Security (Восстановить безопасность). Этот переключатель позволяет применить к восстанавливаемым файлам оригинальные права доступа. Этот переключатель выбран по умолчанию и лучше всего подходит для большинства операций восстановления файлов. Если возникает ситуация, при которой оригинальные дескрипторы безопасности становятся недействительными (восстановление данных после переустановки операционной системы), или необходимо удалить старые дескрипторы безопасности и заменить их принятыми по умолчанию дескрипторами безопасности папки восстановления, сбросьте этот флажок.
Restore ।Removable Storage Database (Восстановить базу данных сменных носителей). Воспользуйтесь этим переключателем для восстановления параметров носителя в базе данных Removable Storage одновременно с восстановлением данных.
Restore Junction Points, Not The Folders And File Data They Reference (Восстановить точки монтирования, а не папки и данные файлов, на которые они ссылаются). Этот переключатель позволяет восстановить один том, не затрагивая файлы в другой файловой системе через точку монтирования. Если нет уверенности, хранятся ли в
определенном томе точки монтирования, установите этот флажок. При необходимости смонтированный том можно будет восстановить отдельно.
When Restoring Replicated Data Sets [el ] (При восстановлении реплицируемых наборов данных). Этот параметр используется при восстановлении файлов в том, который реплицируется средствами службы репликации файлов. Этот параметр доступен только при восстановлении файлов состояния системы. При установке этого флажка метки времени и даты реплицированных файлов устанавливаются равными актуальным значениям, что приводит к распространению файлов на другие серверы, хранящие копию этого тома.
Завершив подготовку к восстановлению файлов, выполните последовательность действий, описанную в процедуре 21.5.
Процедура 21.5. Восстановление файла вручную с помощью утилиты Ntbackup
Вставьте в привод ленту, на которой записаны интересующие файлы. Служба Removable Storage Management предоставит ленту утилите Ntbackup в течение минуты.
Запустите утилиту Ntbackup.
Откройте вкладку Restore and Manage Media (Восстановление носителя и управление им) и выберите пиктограмму ленточного устройства (рис. 21.14).
Рис. 21.14. В окне утилиты Ntbackup открыта вкладка Restore and Manage Media (Восстановление носителя и управление им)
В правой панели найдите запись каталога, содержащую строку Media Location (Расположение носителя), которая означает, что это устройство смонтировано. Для остальных записей каталога будет указано состояние Offline (Отключено).
Выберите восстанавливаемые файлы или папки.
В поле Restore Files То (Восстановить файлы в) выберите один из трех вариантов восстановлений.
Щелкните на кнопке Start Restore (Восстановить). В окне Confirm Restore (Подтвердить восстановление) щелкните на кнопке Advanced (Дополнительно). Откроется окно Advanced Restore Options (Дополнительные параметры восстановления), которое показано на рис. 21.15.
Выберите соответствующие параметры безопасности, точек соединения и точек монтирования. Щелкните на кнопке ОК, чтобы вернуться в окно Confirm Restate (Подтвердить восстановление).
Рис. 21.15. Окно Advanced Restore Options (Дополнительные параметры восстановления), в котором показаны принятые по умолчанию параметры восстановления
Щелкните на кнопке ОК для запуска восстановления. В окне Restore Progress (Процесс восстановления) будет отображаться информация о текущем состоянии процесса восстановления.
После завершения восстановления закройте окно Restore Progress (Процесс восстановления).
Проверьте содержимое отчета, чтобы убедиться в отсутствии проблем в процессе восстановления. После этого скопируйте пользовательские файлы в соответствующий каталог.
Каталогизация ленты .
При записи файла резервной копии на ленту вместе с файлом на ленту записывается фрагмент каталога для этого задания. Если на ленте записан файл резервной копии, но на жестком диске отсутствует каталей-, его можно восстановить с ленты, после чего восстановить файлы с использованием восстановленного каталога (процедура 21.6).
Процедура 21.6. Каталогизация ленты
Вставьте ленту в ленточный, привод и подождите около минуты, пока служба RSM смонтирует ленту и прочитает метку.
Запустите утилиту Ntbackup и перейдите на вкладку Restore and Manage Media (Восстановление носителя и управление им).
В правой панели найдите запись каталога, в которой строка Media Location (Расположение носителя) указывает на смонтированное устройство. Остальные записи будут иметь состояние Offline.
Щелкните правой кнопкой мыши на носителе в правой панели и выберите из контекстного меню команду Catalog (Каталог).
После завершения каталогизации ленты структура ленты будет добавлена в записи каталога в дереве устройства ленточного привода в левой панели.
После этого с ленты можно восстанавливать интересующие файлы.
Восстановление после критических ошибок
В составе операционной системы Windows Server 2003 используются два варианта выполняемых файлов.
Службы режима ядра, которые работают в привилегированном пространстве памяти внутри подсистемы Windows Executive
Пользовательские приложения, которые работают в непривилегированной памяти
Пользовательские приложения практически не могут повлиять на стабильность работы системы. Да, пользовательское приложение может отнять значительную долю ресурсов компьютера или увеличить время реакции системы на действия пользователя, но добиться полной недоступности системных служб из пользовательского приложения невозможно.
С другой стороны, службы режима ядра имеют все возможности для повреждения операционной системы. Вместо того чтобы рисковать значительным повреждением данных на диске и в памяти, при нарушении в работе службы режима ядра система останавливается и выдает информацию о причинах аварийного завершения работы. Критическая ошибка в режиме ядра обычно называется синим экраном смерти (Blue Screen Of Death). Название связано с цветом фона информационного экрана. Синий экран создается подпрограммой ядра, которая называется KeBugCheckEx.
Интерактивное отслеживание событий
Если сервер аварийно завершает работу в результате критической ошибки или приложение “зависает” и должно быть завершено принудительно из Task Manager (Диспетчер задач) либо средствами программы DrWatson, система создает набор файлов XML, в которых содержится список имен процессов, запущенных на компьютере в момент аварийного завершения работы. Кроме этого, в файл записывается информация о содержимом памяти и содержимом регистров центрального процессора, подобно информации, которая выдается на синем экране.
Эти файлы XML отправляются компании Microsoft, где информация добавляется в хранилище с данными об отказах. Эта информация позволяет определить причины отказа и возможные решения. Например, если сотни сообщений об ошибках в работе конкретного драйвера стекаются в компанию Microsoft, компания может связаться с производителем устройства и определить причину нестабильной работы.
Иногда нежелательно, чтобы эта информация становилась доступна компании Microsoft. В разделе Computer ConfigurationsMAdministrative TemplatesMSystemMError Reporting (Конфигурация компьютерам Административные шаблоныМ Системам Отчеты об ошибках) предоставляется набор групповых политик, которые управляют параметрами отправки интерактивных отчетов. Отчеты можно полностью заблокировать, разрешить отправку отчетов лишь для некоторых приложений или разрешить только отчеты о незапланированных завершениях работы системы.
Коды критических ошибок
В верхней строке синего экрана критической ошибки указывается код ошибки, который идентифицирует источник сообщения об ошибке, информацию об ошибке в зависимости от кода, а также причину ошибки. Информация может выглядеть следующим образом:
*** STOP: 0x0000001В (0x00000005, 0x8041E9FB, 0x00000000, 0x00000030) KMODE_EXCEPTION_NOT_HANDLED
*** Address 8041E9FB base at 80400000, DateStamp 377509d0 S> - ntoskrnl.exe
Коды критических ошибок являются лучшим методом поиска причины отказа. Кроме кода, иногда на синем экране отображается информация о дампе стека, идентифицирующая список процессов, присутствовавших в памяти в момент отказа, а также действия, которые выполнялись этими процессами. Ниже приведена краткая расшифровка информации с экрана критической ошибки.
Первая запись после слова STOP является шестнадцатеричным идентификатором кода критической ошибки. Этот идентификатор соответствует имени во второй строке. Если во второй строке имя не указано, исключение было настолько серьезным, что система не смогла обратиться к таблице и сгенерировать имя.
В следующих четырех записях указываются параметры вызова функции KeBugCheckEx при возникновении критической ошибки. Значение и источники этих параметров зависят от типа ошибки.
В строке ниже кода ошибки указывается базовый адрес образа, который привел к появлению ошибки, шестнадцатеричное представление метки даты образа, а также имя образа. В этом случае исключение было вызвано драйвером ядра, Ntoskrnl. ехе.
Имя конкретного выполняемого файла, указанное на экране критической ошибки, не обязательно означает, что этот файл являлся причиной отказа. Имя в верхней части синего окна может оказаться подставным и скрывать за собой реального виновника проблемы.
Лучшим источником информации о кодах критических ошибок является Microsoft Knowledge Base. Начните поиск со статьи Q103059, в которой перечислены коды критических ошибок и их названия. После этого обратитесь к статье Q192463, в которой описываются методы сбора информации без полноценной отладки ядра. Полный перечень кодов критических ошибок доступен в Windows DDK, доступном на сайте msdn.microsoft. com. Список кодов хранится в файле bug с odes. h.
Интерактивные отчеты об ошибках
Для устранения основных источников “зависаний” системы и во избежание появления экранов стоп-ошибок при создании операционной системы Windows Server 2003 была добавлена служба Error Reporting, Ersvc, которая занимается сбором информации о ядре из информации критических ошибок и информации о приложениях из отчетов программы Dr.Watson. Эта информация отправляется компании Microsoft, где выполняется ее систематизация и анализ. Дополнительная информация об этой возможности приводится в главе 3, “Добавление аппаратных средств”.
Распространенные критические ошибки
Среди более чем 200 кодов критических ошибок режима ядра действительно распространены только несколько ошибок.
Kmode_Bxception_Not_Handled (OxOOOOOOlE). Появление этой ошибки указывает, что в ядре произошло исключение, для которого не существует обработчика. В большинстве случаев в окне ошибки будет указано название некорректно работающего драйвера. Имя драйвера будет указано в третьей строке.
lrql_Not_Les8_Or_Equal (ОхОООООООА). Когда поток выдает запросы на программное прерывание, делается это на определенном уровне запроса прерывания (IRQL). Существует 32 уровня запроса прерывания. Чем больше номер, тем больше приоритет. Ошибка 0А
возникает в случае, если драйвер на определенном уровне IRQL пытается получить доступ к памяти, принадлежащей процессу с большим уровнем запроса прерывания.
Oiiexpected_Kernel_MOde_Trap (0x0000007F). Обычно этот код связан с аппаратной проблемой. Список наиболее вероятных причин приводится в статье Knowledge Base Q137539.
Ntfs_File_System (0x00000024). Обычно эта ошибка возникает в результате работы вируса или агрессивной программы антивирусного сканирования. Кроме этого, причиной может стать попытка утилит файловой системы получить доступ к файловой системе в обход программного интерфейса. Также эта ошибка может быть вызвана повреждением файловой системы.
Page_Fault_ln_Nonpaged_Area (0x00000050). Эта ошибка часто вызывается антивирусными программами. Кроме этого, она часто связана с многими проблемами в работе стека протоколов TCP/IP. Некоторые атаки отказа в обслуживании также приводят к появлению ошибки 0x50, поэтому если такая ошибка возникает на компьютерах в демилитаризованной зоне, стоит включить аудит и установить программу перехвата пакетов для определения источника проблемы.
lnacceseible_Boot_Device (0x0000007В). Если эта ошибка возникает в процессе загрузки системы, которая до этого уже работала некоторое время, ошибка указывает на отказавший диск, контроллер или вирус в загрузочном секторе. Если ошибка возникает при установке операционной системы, проблема может быть связана с трансляцией секторов диска или некорректным поведением драйвера дискового адаптера. Кроме этого, такая ошибка может возникать при перезагрузке компьютера после отказа основного диска в составе зеркала.
Дампы памяти
Существует несколько операций, которые позволяют определить причину возникновения критической ошибки и попытаться предотвратить появление еще одного отказа.
Если критическая ошибка возникает после установки нового аппаратного компонента, модернизации драйвера или установки нового приложения, первым действием должна быть перезагрузка компьютера и выбор варианта загрузки Last Known Good Configuration. Дополнительная информация приводится в разделе “Восстановление работоспособности с помощью последней удачной конфигурации”.
Если это не помогает решить проблему, перейдите на консоль восстановления (Recovery) и удалите или переименуйте некорректно работающий драйвер.
Если к серверу невозможно получить физический доступ, его можно настроить на доступ по управляющему каналу ООВ (Out-Of-Band) для просмотра кодов ошибок и перезагрузки компьютера. Дополнительная информация приводится в разделе “Использование служб аварийного управления”.
Если после всех попыток не удается восстановить нормальную работоспособность сервера, можно записать содержимое памяти на момент появления критической ошибки и отправить содержимое дампа в службу поддержки компании Microsoft. Служба поддержки выставит счет в пару сотен долларов за обращение, но при сравнении этой стоимости с вероятными потерями в результате отказов сервера затраты оказываются оправданными.
Настройка дампов памяти
По умолчанию при возникновении критической ошибки содержимое оперативной памяти записывается в файл подкачки. После перезагрузки файл подкачки копируется в файл, который называется Memory. dmp и располагается в каталоге \Windows.
Для удачной записи полного дампа памяти файл подкачки должен иметь размер не меньше объема оперативной памяти плюс 1 Мбайт для записи информации заголовков. Файл подкачки должен находиться в корневом каталоге загрузочного диска. (Компания Mictosoft называет этот диск системным разделом.) Это связано с тем, что подпрограмма обработки критической ошибки не в состоянии смонтировать файловую систему и ограничена использованием вызовов INT13. На других устройствах могут существовать другие файлы подкачки, но они не используются для записи дампа памяти.
Если на сервере установлена оперативная память объемом во много гигабайтов, ни один администратор не захочет выделять гигабайты дискового пространства на системном разделе только для хранения файла подкачки. Кроме этого, многогигабайтный файл подкачки не всегда содержит полезную информацию, особенно если поврежденный драйвер не оставляет узнаваемого следа. У администратора есть два способа избежать создания большого дампа памяти.
• ■ Малый дамп памяти. В такие дампы записывается фрагмент оперативной памяти, который принадлежит операционной системе. Размер этого фрагмента редко превышает 1 Гбайт и не может быть больше 2 Гбайт (по крайней мере, на компьютерах архитектуры IA32). Системы IA64 могут создавать малый дамп большего размера. Необходимое дисковое пространство для создания малого дампа памяти можно узнать в окне Task Manager (Диспетчер задач).
■ Дамп памяти ядра. Этот дамп содержит только пространство стеков. Эта информация может оказаться полезной, только если некорректно работающий драйвер оставляет легко узнаваемый след. В противном случае в таком дампе отсутствует достаточный объем информации для полной диагностики.
JtLtiJtLtiПараметры дампа памяти устанавливаются в окне свойств системы. Щелкните правой кнопкой на пиктограмме Му Computer (Мой компьютер) и выберите из контекстного меню команду Properties (Свойства). На вкладке Advanced (Дополнительно) доступна кнопка Startup and Recovery (Загрузка и восстановление), щелчок на которой открывает доступ к параметрам дампа памяти (рис. 21.16).
JtLti
JtLti
Startup and Recovery
. System startup
Octet* operatise system ,
i |"HcrM0ft Windows .NET Enterprise Server"/fastdetect
P Time to dkpfey fat of operaitlB systems.j 30 ^j seconds
Г tire to dfaphy recovery options *ah needed: p?~3 v-
ToedtthostertietVtxrafhmerully.dkkEdt. Е» I
System fedee - -- -
| P W''*-'s,c**:m^sy$temKg.C. . ...< -
17 Send an edmsislralh® elect
Г Automate* fcatert
WrtBdehu^lrrfpHMtion - --
। kemd'nwnory dump*
j j ] %5ystemRoot%\MEMORY.DMP
P Overwrite any existing fite
Puc. 21.16. В окне Startup and Recovery (Загрузка и восстановление) показаны принятые по умолчанию параметры для обработки критических ошибок системы
В этом окне стоит обратить внимание на несколько параметров восстановления.
Send an administrative alert (Отправить административное оповещение). В данном случае используется служба Alerter, если она работает после отказа системы. Служба отправляет широковещательное сетевое сообщение членам локальной для домена группы Administrators (Администраторы) и уведомляет их о возникновении критической ошибки. Если используется консоль перехвата сообщений об ошибках (например, HP Openview), на сервере стоит установить агент SNMP, который будет перехватывать сообщение об отказе.
Write debugging information (Записать сообщение в системный журнал). Позволяет задать имя файла, в который будет записано содержимое памяти после перезагрузки системы. Дамп остается в файле подкачки, пока система не выполнит успешную перезагрузку.
Write Kernel Information Only (Записать только информацию ядра). Позволяет сохранить дисковое пространство при наличии на сервере большого объема оперативной памяти. Для получения информации о размере файла подкачки можно открыть Task Manager (Диспетчер задач), активизировать вкладку Performance (Быстродействие) и увидеть общий объем памяти в разделе Kernel Memory (Память ядра).
Automatically Reboot (Выполнить автоматическую перезагрузку). Этот параметр позволяет перезагрузить систему после завершения создания дампа памяти. Установка этого параметра может привести к непрерывной последовательности перезагрузок, если критическая ошибка не исчезает после перезагрузки. По этой причине желательно следить за серверами с помощью той или иной программы SNMP, которая будет уведомлять администраторов об отказах серверов.
Просмотр содержимого дампов памяти
В реальных условиях при регулярных отказах сервера и невозможности определить причину проблемы желательно потратить некоторую сумму и обратиться в службу поддержки компании Microsoft. Служба поддержки может потребовать файл дампа памяти. Перед записью огромного файла на компакт-диск и отправкой компакт-диска ночным курьером в службу поддержки желательно убедиться, что в файле дампа действительно содержится полезная информация. На установочном компакт-диске операционной системы Windows Server 2003 предоставляется утилита, которая называется dumpchk и позволяет проверить целостность содержимого файла.
Чтобы самостоятельно просмотреть содержимое файла дампа, потребуется соответствующий инструмент. Самым простым и гибким инструментом анализа дампа является утилита Windows Debugger, windbg. Эта утилита предоставляется на компакт-диске операционной системы Windows Server 2003, доступном через сеть TechNet или на сайте MSDN.
Кроме этого, на компакт-диске Windows Server 2003 предоставляется достаточно большой файл символов (symbol file), который тоже должен быть установлен для отладки. Символы из этого файла помогают отладчику интерпретировать содержимое файла дампа. Существует две версии файлов символов, одна из которых предназначена для обычной версии продукта, а другая — для отладочной версии. Отладочные символы имеет смысл использовать только в том случае, если на сервере установлена операционная система Windows Server 2003 из состава библиотеки MSDN.
При установке отладчик Windbg пытается найти символы в каталоге \Windows\Symbols. Если символы устанавливались в другой каталог, отладчик необходимо настроить на использование файла символов по другому пути. Для этого выберите View^Options^Symbols (Вид1^ Параметры1^ Символы).
Отладчик Windbg имеет большое количество параметров, которые позволяют использовать его для разных целей. Обсуждение этих параметров выходит за пределы тематики этой книги. Но для анализа файла дампа используется достаточно простая возможность отладчика. Просто
C - Windows Debugger:5.00.2184.1 - KernelDump <1 j- CommandC - Windows Debugger:5.00.2184.1 - KernelDump <1 j- Commandукажите программе расположение файла дампа. Для этого выберите File^Open Crash Dump (Файл^Открыть дамп памяти) и укажите файл \Windows\Memory. dmp (рис. 21.17).
C - Windows Debugger:5.00.2184.1 - KernelDump <1 j- Command
C - Windows Debugger:5.00.2184.1 - KernelDump <1 j- Command
0 Hi Mt View Debug Whdow Help-Ifll xt
Si и| дЙ£| jiliMjiI ЩЦЯ si si ОЙМЮЙ
Module Load: HRXDAV.SYS (symbol loading deferred) Module Load: SRV.SYS (symbol loading deferred) Module Load: PARVDM.SYS (symbol loading deferred) Module Load: ASPI32.SYS (symbol loading deferred) Module Load: HTTP.SYS (symbol loading deferred) Module Load: SPUD.SYS (symbol loading deferred) Module Load: TDTCP.SYS (symbol loading deferred) Module Load: RDPUD.SYS (symbol loading deferred) Module Load: FASTFaT.SYS (symbol loading deferred) Module Load: SYSAUDIO.SYS (symbol loading deferred) Module Load: UDMAUD.SYS (symbol loading deferred) Could not get address of KIProcessorBlock Finished re-loading kernel modules Kernel Debugger connection established for C:\WINDOWS\MEMORY.DMP Kernel Version 3S9O Free loaded 8 ffffftff604d200D Bugcheck 000000e2 : OOOOODOO 00000000 00000000 00000000
Stopped at an unexpected exception: code-90000003 addr-ffffffffBD4ffeeb Hard coded breakpoint hit
> I
Рис.21.17. Окно утилиты Windbg, в котором показан результат загрузки файла дампа памяти
Для генерации файла дампа в этом примере использовалась отладочная возможность Windows. Для включения этой возможности внесите в системный реестр следующее изменение для параметра, управляющего драйвером клавиатуры:
I
Раздел: HKLM\System\CurrentControlSet\Services\i8042prt\Parameters
Запись: CrashOnCtrlscroll
Значение: 1 (reg_dword)
После установки этого параметра и перезагрузки можно аварийно завершить работу системы, нажав клавишу <Ctrl>, расположенную справа, и дважды нажав клавишу <Scroll Lock>.
Если в файле дампа достаточно информации для определения источника проблемы, отладчик явно укажет на источник.
После перезагрузки служба сообщения об ошибках попытается отправить информацию об ошибке компании Microsoft. В окне уведомления предоставляется достаточный объем информации для принятия решения об отправке отчета. После щелчка на гиперссылке предоставляется полное содержимое отправляемого отчета (рис. 21.18 ).
Использование служб аварийного
управления
Часто возникает необходимость получить доступ к серверу за пределами нормального сетевого соединения. Например, сетевой интерфейс на сервере не работает или по какой-то причине соединение между администратором и сервером разорвалось, или сервер отказывается реагировать на запросы и необходимо выяснить, в чем причина отказа.
iMtcrosofl Windows
EffortigMhj»•-.- .
№6*-dl BCPI OOOOOOOD BCF2'00000002 80*3 00000000
ВФ4 F8BB92M OSVet 5.1.3890 SP LO Product 274.2
Ths «w report MdudK riamdion r«g«feg the condition tfMfaadtWnd^ occurred, the opeteking system ysmort and coffputer hardware in use, and Iha internet Protocol pF] adcfret# of jwu compute.
We do not ntentionetreoied your name, »d*ws.eiMi address a any other fam of persona^ identfiabto rformation. However. tm error report яму certain customer-specAc Иотеооп r the collected date fie*. Whfe this rfocmabcri fipuidflotenb*be used Io determnayota rderrty. 4 preuni, it wl not he med.
Thedeteihrt weeofcctwior*beuMdto6rAepR*tem NmoreHofmartanea^eiahte.wewitef you when you report th» prabtent Thk error report *■ be ear* wig a tactee connection to a database w*h Smiled access and wi not be used fa maikafing purposes
To view technicai Hotmation about Bit wer яро*, defrlwp_
To see ou data cofecbon pofcy on the «rob, fjtok.hefe.I Qq*|
Рис.21.18. Окно отчета об ошибке после аварийного завершения работы системы
Операционная система Windows Server 2003 обеспечивает метод доступа к серверу с помощью соединения через последовательный порт. Эта возможность называется службами аварийного управления (Emergency Management Services — EMS). Название возможности может ввести в заблуждение, так как это не служба, а базовая функциональная возможность, включаемая с помощью параметра в файле Boot. ini. Этот параметр позволяет перенаправить вывод на последовательный порт и ожидать ответов на этот же порт.
Самым простым способом настройки перенаправления порта является использование утилиты bootcfg. Запустите утилиту в командной строке на сервере, который должен поддерживать работу служб аварийного управления. Синтаксис команды для модификации первой записи ARC в файле Boot. ini для перенаправления вывода на порт СОМ1 со скоростью 115200 бит/с выглядит следующим образом:
bootcfg /ems on /port coral /baud 115200 /id 1
Ниже показано содержимое файла Boot. ini после изменения. Модифицированные строки выделены полужирным шрифтом: [boot loader] timeout=0
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS redirect=COM1
redirectbaudrate=115200
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP S> Professional" /fastdetect /redirect
При загрузке сервера с такой конфигурацией включаются службы аварийного управления и вывод можно получать на последовательном порту. Для установки соединения с сервером через последовательный порт необходим нуль-модемный кабель — кабель с 9-штырьковыми разъемами (DB-9) на каждом конце. Не используйте кабель передачи данных LapLink. Он не подходит для этой задачи.
Кроме этого, на клиенте на другом конце последовательного кабеля должен быть запущен эмулятор терминала. Удобный эмулятор терминала предоставляется во всех 32-разрядных версиях операционной системы Windows. Это Hyperterminal, который доступен в разделе Accessories1^ Communications (Стандартные1^ Связь). Настройте эмулятор Hyperterminal на использование последовательнбго порта, а не модема, и настройте свойства последовательного порта, указав значения параметров Data Bits (Биты данных) и Stop Bits (Стоповые биты) 8 и 1 соответственно при скорости подключения 115 200 бит/с и аппаратном управлении потоком (рис. 21.19).
Рис. 21.19. Свойства последовательного порта для работы утилиты Hyperterm
Если необходимо настроить дополнительное соединение с несколькими серверами в серверной комнате, обратите внимание на концентраторы последовательных портов, предлагаемые такими производителями, как Muxmaster и Cyclades. Такие концентраторы предоставляют сетевые и модемные соединения с последовательными портам, а также обеспечивают безопасность при регистрации, чего нельзя сказать о стандартных службах аварийного управления. Никогда не подключайте модем к последовательному порту реального сервера. Любой подросток, использующий программу демона для прозвона сетей, может устроить массу неприятностей такому серверу и его администратору.
Специальная административная консоль.
При подключении к последовательному порту сервера, поддерживающего работу служб аварийного управления, администратору предоставляется доступ к специальной административной консоли (Special Administrative Console — SAC). На этой консоли предоставляется набор функций, который показан на рис. 21.20.
Большая часть функций специальной административной консоли не требует дополнительных объяснений. Например, функция t имитирует утилиту Hist из состава пакета Resource Kit, выдавая список запущенных выполняемых файлов и соответствующих идентификаторов процессов. Эта информация может использоваться для поиска идентификатора “зависшего” процесса с последующим использованием функции к для завершения процесса. Функция restart оказывается полезной для перезагрузки “зависшего” сервера.
Если по какой-то причине специальная административная консоль недоступна, система переходит к использованию резервной специальной административной консоли, которая называется !SAC. На этой консоли доступно только четыре функции.
Restart. Немедленная перезагрузка компьютера.
D. Вывод содержимого журнала событий.
ID. Вывод идентификационной информации сервера..
Q. Переключение последовательного порта в нормальный режим работы.
^iGU^Sl^iGU^SldDump the current kernel log.fToggle full tlist info to Just processes, or visa-versa.helpDisplay this list,iList all IP network numbers and their IP addresses.i <8> <ip> <subnet> <gateway> Set IP addr., subnet and gateway.iddisplay the computer identification information.k <pid)Mill the given process.1 <pid>Lower the priority of a process to the lowest possible,m <pid> <MB-allow> Limit the memory usage of a process to <MB-allow>.PToggle paging the display.r <pid>Raise the priority of a process by one.sDisplaythe current timeand date<24hourclockused).s mm/dd/yyyy hh:mm Set thecurrent time anddate <24hourclockused).।tTlist.?Displaythis list.restartRestartthe system immediately.shutdownShutdown the system immediately.crashdumpCrash the system. You must havepreviouslyenabled crash dump functionality to get a dump.SAC)!SAC)SAC)!SAC)dDump the current kernel log.fToggle full tlist info to Just processes, or visa-versa.helpDisplay this list,iList all IP network numbers and their IP addresses.i <8> <ip> <subnet> <gateway> Set IP addr., subnet and gateway.iddisplay the computer identification information.k <pid)Mill the given process.1 <pid>Lower the priority of a process to the lowest possible,m <pid> <MB-allow> Limit the memory usage of a process to <MB-allow>.PToggle paging the display.r <pid>Raise the priority of a process by one.sDisplaythe current timeand date<24hourclockused).s mm/dd/yyyy hh:mm Set thecurrent time anddate <24hourclockused).।tTlist.?Displaythis list.restartRestartthe system immediately.shutdownShutdown the system immediately.crashdumpCrash the system. You must havepreviouslyenabled crash dump functionality to get a dump.SAC)!SAC)SAC)!SAC)Connected Ml» 'Auto'detM 1152008*1Connected Ml» 'Auto'detM 1152008*133
^iGU^Sl
^iGU^Sl
dDump the current kernel log.
fToggle full tlist info to Just processes, or visa-versa.
helpDisplay this list,
iList all IP network numbers and their IP addresses.
i <8> <ip> <subnet> <gateway> Set IP addr., subnet and gateway.
iddisplay the computer identification information.
k <pid)Mill the given process.
1 <pid>Lower the priority of a process to the lowest possible,
m <pid> <MB-allow> Limit the memory usage of a process to <MB-allow>.
PToggle paging the display.
r <pid>Raise the priority of a process by one.
sDisplaythe current timeand date<24hourclockused).
s mm/dd/yyyy hh:mm Set thecurrent time anddate <24hourclockused).।
tTlist.
?Displaythis list.
restartRestartthe system immediately.
shutdownShutdown the system immediately.
crashdumpCrash the system. You must havepreviously
enabled crash dump functionality to get a dump.
SAC)!
SAC)
SAC)!
SAC)
dDump the current kernel log.
fToggle full tlist info to Just processes, or visa-versa.
helpDisplay this list,
iList all IP network numbers and their IP addresses.
i <8> <ip> <subnet> <gateway> Set IP addr., subnet and gateway.
iddisplay the computer identification information.
k <pid)Mill the given process.
1 <pid>Lower the priority of a process to the lowest possible,
m <pid> <MB-allow> Limit the memory usage of a process to <MB-allow>.
PToggle paging the display.
r <pid>Raise the priority of a process by one.
sDisplaythe current timeand date<24hourclockused).
s mm/dd/yyyy hh:mm Set thecurrent time anddate <24hourclockused).।
tTlist.
?Displaythis list.
restartRestartthe system immediately.
shutdownShutdown the system immediately.
crashdumpCrash the system. You must havepreviously
enabled crash dump functionality to get a dump.
SAC)!
SAC)
SAC)!
SAC)
Connected Ml» 'Auto'detM 1152008*1
Connected Ml» 'Auto'detM 1152008*1
3
3
Hyperi erminal
fib Ш View CM Trwrfer Help
Puc. 21.20. Специальная административная консоль служб аварийного управления
Службы аварийного управления и критические ошибки
Если система аварийно завершает работу в результате критической ошибки режима ядра, службы аварийного управления перенаправляют содержимое экрана критической ошибки на последовательный порт (рис. 21.21).
Если сервер не настроен на автоматическую перезагрузку после создания дампа памяти, окно критической ошибки исчезнет через несколько минут и будет заменено специальной административной консолью после перезагрузки.
Рис. 21.21. Подключение к службам аварийного управления. Описание критической ошибки показано на консоли HypertermРис. 21.21. Подключение к службам аварийного управления. Описание критической ошибки показано на консоли Hyperterm
Рис. 21.21. Подключение к службам аварийного управления. Описание критической ошибки показано на консоли Hyperterm
Рис. 21.21. Подключение к службам аварийного управления. Описание критической ошибки показано на консоли Hyperterm
Если настроить эмулятор терминала на захват всей входящей информации, можно будет просмотреть содержимое буфера и ознакомиться с описанием критической ошибки, которое позволяет определить направление поиска после перезагрузки.
Использование безопасного режима
Когда драйвер начинает вести себя некорректно, система аварийно завершает работу или работает с ошибками. В таком случае можно загрузить систему с помощью минимального количества драйверов. Такой режим работы операционной системы называется безопасным режимом (Safe Mode). Существует несколько вариантов безопасного режима. Для доступа к безопасному режиму в меню загрузчика необходимо нажать клавишу <F8>.
Safe Mode (Безопасный режим). В этом режиме загружается минимальный набор драйверов периферийных устройств, драйвер видеоадаптера VGA с поддержкой 16 цветов, драйверы интерфейсов накопителей SCSI и IDE, драйвер интерфейса гибкого диска и несколько системных служб. Безопасный режим не поддерживает работу сетевых служб. При выборе этого варианта переменная среды SAFEBOOT_OPTION устанавливается равной значению MINIMAL.
Safe Mode with Networking (Безопасный режим с поддержкой сети). Этот вариант поддерживает загрузку того же набора драйверов, что и в безопасном режиме, но, кроме этого, загружаются драйверы сети. Этот режим полезен для восстановления файлов по сети или для запуска агента резервного копирования от стороннего производителя для восстановления с ленты по сети. В этом режиме переменная среды SAFEBOOT_OPTION устанавливается равной значению NETWORK.
Safe Mode with Command Promt (Безопасный режим с поддержкой командной строки). Этот режим совпадает с обычным безопасным режимом, но в данном случае не загружается оболочка Explorer (Проводник). Предоставляется только приглашение командной строки. Этот режим можно использовать в том случае, если повреждение оболочки Explorer (Проводник) или содержимого системного реестра заставляет компьютер выдавать экран критической ошибки при переходе в графический режим. Избегайте запуска приложения с графическим интерфейсом, так как автоматически запустится Explorer (Проводник), что может привести к аварийному завершению работы системы. В этом режиме переменная SAFEBOOT_OPTION устанавливается равной значению MINIMAL.
Enable Boot Logging (Включить протоколирование загрузки). Этот пункт не связан с безопасным режимом. Он позволяет включить запись журнала загрузки драйверов ядра. Журнал записывается в файл Ntbtlog.txt в каталоге \Windows. Система загружает нормальный набор драйверов и служб.
Особые соображения при регистрации в режиме восстановления службы каталогов
При загрузке в режиме восстановления службы каталогов база данных Active Directory не запускается. Это значит, что поставщик безопасности Kerberos недоступен. Поставщик безопасности MSV1_0 является единственным источником аутентификационной информации для локальной регистрации, а для проверки регистрационных данных поставщик MSV1_0 использует локальную базу данных SAM.
При повышении сервера до контроллера домена старая версия базы данных SAM удаляется и создается новая база данных SAM, в которую записывается новая учетная запись Administrator (Администратор). Мастер повышения запрашивает пароль для новой учетной записи Administrator (Администратор). Рекомендую записать этот пароль и хранить записку в безопасном месте. Одним из решений является помещение записки внутрь закрытого корпуса сервера.
Enable VGA Mode (Включить режим VGA). Этот пункт не связан с безопасным режимом. При выборе этого пункта установленный драйвер видеоадаптера заменяется драйвером адаптера VGA, который поддерживает 16 цветов. Эта возможность полезна для устранения проблем в работе видеоподсистемы, хотя этот вариант может вызвать проблемы, поскольку приходится вручную устанавливать правильные драйверы после выбора этого варианта. Если название правильного драйвера неизвестно, можно попытаться найти драйвер на установочном компакт-диске устройства или загрузить актуальную версию драйвера с сайта производителя.
Last Known Good Configuration (Загрузка последней удачной конфигурации). При выборе этого варианта узел системного реестра System возвращается в последнее стабильное состояние.'
Debugging Mode (Режим отладки). Этот вариант включает механизм отладки режима ядра. Дополнительная информация о механизме отладки режима ядра предоставляется в Microsoft Knowledge Base.
Directory Service Restore Mode (Восстановление службы каталогов). Это специальная версия безопасного режима, которая доступна только на контроллере домена и используется для исправления проблем в работе базы данных Active Directory и восстановления файлов состояния системы. В этом режиме переменная среды SAFEBOOT_OPTION устанавливается равной значению DSREPAIR.
В безопасном режиме можно обратить внимание на номер версии и слово “free”. Это значит, что используется версия операционной системы, в которой отсутствуют отладочные символы. Версия checked содержит системные файлы с отладочными символами, которые используются для отладки режима ядра. Отладочная версия работает медленнее и использует больше оперативной памяти.
В безопасном режиме можно заменить проблемный драйвер, отключить службу или установить новый драйвер для решения возникшей проблемы. В этом режиме можно воспользоваться утилитами восстановления баз данных Jet для восстановления любой служебной базы данных. Если есть подозрение, что проблема является очень серьезной, запланируйте запуск утилиты chknt f s для полного сканирования диска в процессе загрузки.
Восстановление работоспособности с помощью последней удачной конфигурации
С описанной ниже ситуацией наверняка сталкивался каждый системный администратор. В привод устанавливается компакт-диск с драйвером для новой “железки” и бах — система “зависает” и выдает синий экран критической ошибки. Через несколько минут компьютер перезагружается и... опять аварийно завершает работу.
Не нужно быть гением, чтобы догадаться, что установленный драйвер что-то меняет в параметрах системы и приводит к “несварению желудка” у компьютера. Теперь главной проблемой является восстановление работоспособности системы.
Очевидным первым шагом является отключение загрузки некорректного драйвера. Драйверы загружаются на основе записей в системном реестре в разделе верхнего уровня в узле System. Этот раздел называется набором управления (control set). Если есть возможность воспользоваться старым набором управления, в котором отсутствует запись для нового драйвера, работоспособность компьютера восстановится. Именно в этом заключается смысл пункта Last Known Good Configuration (Загрузка последней удачной конфигурации) в меню безопасного режима.
Структура набора управления
Запустите редактор системного реестра и разверните дерево до раздела HKLM\System. Разверните раздел Currentcontrolset. В этом разделе хранятся четыре раздела, содержащие параметры управления службами и драйверами.
Control. В этом разделе содержатся параметры ядра операционной системы, которые используются в процессе загрузки. Это программные классы, классы устройств, последовательность загрузки драйверов устройств, а также параметры безопасности. Кроме этого, в разделе Control содержатся параметры Configuration Manager (Диспетчер конфигурации), которые обеспечивают доступ к системному реестру. Это приводит к ситуации “Уловка-22”. Configuration Manager использует параметры из раздела Control для чтения журналов отслеживания транзакций. Если в журнале отслеживания транзакций указано обновление раздела Cont г о 1, система не сможет загрузиться. По этой причине система хранит полную резервную копию раздела System в файле, который называется System .alt.
Enum. В этом разделе хранятся результаты инвентаризации устройств подсистемы Plug- and-Play. При открытии консоли Device Manager (Диспетчер устройств) и просмотре списка устройств и соответствующих параметров администратор просматривает графическое представление содержимого этого раздела.
Hardware Profiles. В этом разделе хранятся специальные параметры для состояний Docked (Подключенный) и Undocked (Отключенный). Подсистема Plug-and-Play позволяет в большинстве случаев обходиться без аппаратных профилей, но при определении профилей конкретные параметры конфигурации сохраняются в этом разделе. Если существует несколько аппаратных профилей, загрузчик Nt Idr предоставляет меню, в котором можно выбрать соответствующий аппаратный профиль.
Services. В этом разделе хранятся параметры всех служб и драйверов.
Несложно заметить, что существует три раздела набора управления: CurrentControlSet, ControlSetl и ControlSet2. Выделите раздел Select, который находится за пределами наборов управления. В этом разделе присутствуют следующие записи.
Current. Эта запись указывает на набор управления, который использовался при загрузке компьютера. Эта запись указывает на ControlSetl.
Default. Эта запись указывает на набор управления, который будет использоваться во время следующего нормального процесса загрузки. Эта запись указывает на ControlSetl.
Failed. Если эта запись имеет значение, набор управления признан отказавшим и запись Default получает новое значение. Обычно эта запись имеет значение 0, т.е. ни один набор управления не признан отказавшим.
LastKnownGood. Эта запись указывает на набор управления, который позволил успешно загрузить операционную систему. Эта запись указывает на ControlSet2.
Восстановление последней работоспособной конфигурации
В процедуре 21.7 с учетом приведенной выше информации описана последовательность событий при загрузке системы и выборе пользователем пункта Last Known Good Configuration (Загрузка последней удачной конфигурации).
Процедура 21.7. Загрузка последней работоспособной конфигурации
Компьютер выполняет последовательность проверок POST и загружает образ загрузочного сектора. После этого запускается загрузчик операционной системы Windows NT, Nt Idr.
Одной из задач загрузчика NtIdr является проверка раздела системного реестра HKLMX SystemXSelect и выбор набора управления Default. Номер набора управления передается драйверу ядра Windows NT, Ntoskrnl.
Если пользователь прерывает стандартную процедуру загрузки, нажав клавишу <F8> в меню загрузчика, загрузчик Nt Idr выводит меню Advanced Options Menu (Дополнительные варианты). Одним из вариантов является Last Known Good Configuration (Загрузка последней удачной конфигурации).
Выберите пункт Last Known Good Configuration (Загрузка последней удачной конфигурации) и нажмите клавишу <Enter>. Система вернется в меню загрузчика и выдаст в нижней части экрана красное сообщение Last Known Good Configuration (Загрузка последней удачной конфигурации). На этом этапе в разделе Select выполняются две операции. Оригинальный набор управления, на который указывает запись Default, ControlSetl, отмечается как Failed. Кроме этого, запись Default перенаправляется на ControlSet2, который указан в записи LastKnownGood.
В стандартном пункте меню загрузки выберите Microsoft Windows Server 2003 и нажмите клавишу <Enter>. Загрузчик Nt Idr начнет загружать драйверы и отобразит меню выбора аппаратных профилей/восстановления конфигурации (Hardware Profile/Configuration Configuration Menu).
Меню восстановления является комбинацией меню выбора аппаратного профиля и меню выбора набора управления. Это окно было унаследовано от классической операционной системы Windows NT. В этом окне не стоит предпринимать каких-либо действий.
Нажмите клавишу <Enter> для продолжения загрузки или подождите до автоматического продолжения загрузки. Загрузится подсистема Windows Executive, система переключится в графический режим и запустит инициализацию системы на основе содержимого набора управления, на который указывает запись Default. На данный момент запись Default должна указывать на набор управления ControlSet2. Другими словами, ControlSet2 становится текущим (Current) набором управления.
Если система успешно загружается, запускает все службы и загружает все драйверы, а пользователи могут нормально регистрироваться на консоли, запись ReportBootOK в разделе системного реестра HKLM\Software\MicrosoftXWindows NTXCurrentVersion устанавливается равной значению 1.
Значение 1 записи ReportBootOK указывает, что текущий набор управления позволил успешно загрузить компьютер. Содержимое текущего набора управления (ControlSet2) копируется в новый набор управления (ControlSetl), который становится набором управления LastKnownGood.
После этой процедуры назначение наборов управления в разделе Select будет выглядеть следующим образом.
Current — ControlSet2
Default — ControlSet2
Failed — ControlSetl
LastKnownGood—ControlSetl
Несложно заметить, что смена наборов управления позволяет решить проблему, если проблема вызвана неправильным значением записи в разделе набора управления. Если проблема вызвана ошибкой в другом разделе системного реестра, например в разделе Software, система останется в нестабильном состоянии.
Консоль восстановления
На консоли восстановления используется миниатюрная версия операционной системы Windows Server 2003, которая предоставляется на установочном компакт-диске и позволяет получать доступ к файлам в системном разделе. В этой операционной среде можно запускать небольшой набор диагностических утилит, отключать драйверы и службы, заменять файлы драйверов, а также выполнять другие “хирургические” операции для восстановления отказавшей операционной системы. Консоль восстановления загружается одним из двух способов:
-с помощью установочного компакт-диска Windows Server 2003 и пункта Repair (Восстановление);.
путем установки файлов консоли на жесткий диск, что позволяет выбрать пункт Recovery Console (Консоль восстановления) из меню загрузчика
Возможность загрузки консоли восстановления с гибкого диска не предоставляется, так как операционная система Windows Server 2003 не поддерживает установку с гибкого диска. Установим файлы Recovery Console (Консоль восстановления) на локальный жесткий диск и ознакомимся с ее возможностями.
Установка загрузочной версии Recovery Console (Консоль восстановления)
В процедуре 21.8 приводится последовательность действий по копированию загрузочных файдов с установочного компакт-диска Windows Server 2003 на загрузочный диск сервера и по настройке пункта меню, который позволит загрузить Recovery Console (Консоль восстановления). Для этого потребуется установочный компакт-диск операционной системы Windows Server 2003.
Динамические тома и Recovery Console (Консоль восстановления)
Поскольку консоль восстановления не поддерживает работу полноценной версии диспетчера логических дисков, определение содержимого программно-связанных томов невозможно. Дополнительная информация приводится в статье Q227364 в базе данных Microsoft Knowledge Base.'
Процедура 21.8. Установка Recovery Console (Консоль восстановления)
Вставьте в привод установочный компакт-диск операционной системы Windows Server 2003.
Откройте приглашение командной строки и перейдите в каталог \ 13 8 6 на компакт-диске.
Запустите команду winnt32 /cmdcons. После длительной паузы откроется окно программы установки и выдаст предупреждение об установке Recovery Console (Консоль восстановления).
Щелкните на кнопке Yes (Да) для согласия с предупреждением и установки консоли.
После установки файлов консоли восстановления будет выдано сообщение об успешном завершении установки.
При установке Recovery Console (Консоль восстановления) на диск вносятся следующие изменения.
В корневом каталоге создается скрытый каталог \ cmdcons. В этом каталоге содержатся те же файлы, которые расположены в загрузочной среде установочного компакт-диска Windows Server 2003. На самом деле при загрузке с помощью файлов \cmdcons выполняется загрузка с установочного компакт-диска Windows Server 2003.
Копия загрузочного сектора раздела системного тома Windows Server 2003 копируется в каталог \ cmdcons, в файл Bootsect. dat.
Альтернативный загрузчик Cml dr размещается в загрузочном разделе.
Модифицируется файл Boot. ini, в который включается пункт загрузки на консоль восстановления.
Использование файла Bootsect.dat для загрузки альтернативной операционной системы является стандартной хитростью Windows. Этот же метод используется для загрузки операционной системы Windows 9х с помощью вторичного загрузчика операционной системы Windows Server 2003. Файл Boot. ini модифицируется следующим образом (изменения показаны полужирным шрифтом): [boot loader] timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\Windows [operating systems]
multi(0)disk(0)rdisk(0)partition(1)\Windows="Windows Server 2003
S> Standard Edition" /fastdetect
C:\CMDCONS\BOOTSECT.DAT="Windows Server 2003 Recovery Console" 4> /cmdcons
При выборе пункта Recovery Console (Консоль восстановления) из меню загрузчика Ntldr переключает компьютер обратно в реальный (Real) режим и загружает содержимое файла Bootsect в память по адресу 0x700b, как это делает стандартный вызов INT13. После этого загрузчик Ntldr йередает управление выполняемому коду в образе загрузчика. Выполняемый код указывает на альтернативный вторичный загрузчик, который называется Cml dr. Этот загрузчик предоставляет альтернативный командный интерпретатор, который обладает достаточной гибкостью для проверки файлов, копирования драйверов и диагностики некоторых ошибок.
При загрузке с установочного компакт-диска Windows Server 2003 или использовании параметра cmdcons на жестком диске последовательность загрузки Recovery Console (Консоль восстановления) остается той же самой. На экране Welcome to Setup выберите R, чтобы загрузить Recovery Console (Консоль восстановления), как показано на рис. 21.22. Обратите внимание, что возможность аварийного восстановления больше не предоставляется. Прощай, диск аварийного восстановления!
Recovery Console (Консоль восстановления) пытается обнаружить установленные операционные системы Windows Server 2003, Windows 2000 или Windows NT и предлагает выбрать одну из операционных систем. Выбирайте внимательно, так как в инструкции сказано нажать <Enter>, но сначала необходимо выбрать номер раздела. Если этого не сделать, консоль восстановления завершит работу, и процедуру загрузки придется повторить.
После этого Recovery Console (Консоль восстановления) запрашивает регистрационные данные. Единственным вариантом является регистрация от имени локальной учетной записи Administrator (Администратор). Если это контроллер домена, необходимо указать пароль, который вводился при повышении компьютера до контроллера домена.
Если пароль администратора неизвестен, можно воспользоваться одной из коммерческих утилит модификации базы данных SAM.
ERD Commander 2000 с сайта www. win ternals. com (стоимостью 350 долларов)
NT Access с сайта www. sunbelt-software . com (стоимостью 70 долларов)
Windows XP/2000/NT Key с сайта www. lostpassword. com (стоимостью 195 долларов)
Кроме этого, если доступна любая утилита, способная монтировать файловую систему NTFS, или вы хотите установить Windows Server 2003 в отдельный раздел, то можно удалить или переименовать подраздел SAM из раздела \Windows\System32\Config. Система создаст
базу данных SAM с пустым паролем для учетной записи Administrator (Администратор). Не делайте этого, если в базе данных SAM созданы уникальные учетные записи.
Рис. 21.22. Экран приветствия и регистрации консоли восстановления
Для выхода из консоли восстановления и перезагрузки компьютера введите команду exit в приглашении консоли. Нажатие комбинации клавиш ,<Ctrl+Alt+Del> не даст необходимого результата.
Возможности консоли восстановления
После загрузки консоли восстановления можно ввести команду help и получить список доступных команд (рис. 21.23).
Большинство команд имеет стандартные функции, знакомые по операционной системе DOS. Однако некоторые команды являются специфичными для Recovery Console (Консоль восстановления). Ниже приведен перечень команд со специальной функциональностью.
Attrib. Меняет атрибуты файла, но не выводит значения атрибутов. Для просмотра атрибутов предназначена команда Dir.
Batch. Запускает содержимое текстового файла в качестве пакетного файла, например batch scriptl.txt. В файле могут использоваться только команды консоли восстановления.
Enable/Disable. Пара команд, которые позволяют управлять записями служб в системном реестре. Вызывающую проблемы службу можно отключить и перезагрузить компьютер для проверки эффективности отключения.
Diskpart. Запускает диспетчер разделов, напоминающий текстовую фазу установки. Эту утилиту можно использовать для создания раздела и создания файловой системы с помощью команды format.
Fixboot. Заменяет загрузочный сектор раздела. Предоставляет удобный способ удаления вирусов из загрузочных разделов.
^ ЛГ I Standard Server [Ctrl-Ait -M ] - VMware Workstation^ ЛГ I Standard Server [Ctrl-Ait -M ] - VMware Workstationjb12I1$Ijb12I1$IPuc. 21.23. Список доступных команд для консоли восстановленияPuc. 21.23. Список доступных команд для консоли восстановления
^ ЛГ I Standard Server [Ctrl-Ait -M ] - VMware Workstation
^ ЛГ I Standard Server [Ctrl-Ait -M ] - VMware Workstation
jb12I1$I
jb12I1$I
Puc. 21.23. Список доступных команд для консоли восстановления
Puc. 21.23. Список доступных команд для консоли восстановления
Fixmbr. Записывает новую главную загрузочную запись, сохраняя таблицу разделов. Напоминает команду fdisk /mbr и обладает таким же потенциалом сделать компьютер неспособным к загрузке, если используется нестандартная запись MBR.
Lietsvc. Команда выдает список служб, которые зарегистрированы в системном реестре. Кроме этого, выдается состояние каждой службы. Эта команда может использоваться вместе с командами Enable/Disable. Команда Listsvc позволяет определить короткое имя службы.
Logon. Запускается та же процедура регистрации, которая используется при первой загрузке консоли восстановления. Эта команда позволяет зарегистрироваться для другого экземпляра Windows, установленного на компьютере.
Мар. Команда позволяет просмотреть список связей в каталоге \Device пространства имен объектов. Эти связи соответствуют разделам дисков.
Systemroot. Эта команда позволяет перейти в корень системы. Для операционной системы Windows Server 2003 это каталог \Windows.
Exit. Несложно догадаться, что эта команда позволяет выйти из консоли и перезагрузить компьютер.
Ограничения консоли восстановления
Принятая по умолчанию конфигурация консоли восстановления обладает рядом ограничений.
Ограничения каталогов. Допускается просмотр файлов только в корневом каталоге, каталоге \Windows и каталоге \cmdcons, если такой каталог существует. Попытка войти в другие каталоги приводит к появлению сообщения Access Denied. Это ограничение предназначено для защиты пользовательских данных.
Ограничения на копирование файлов. Копирование файлов поддерживается только в направлении к жесткому диску, но не наоборот. Это защищает файлы от хищения.
Ограничения на использование универсальных символов в именах файлов. Для предотвращения одновременного повреждения большого количества файлов консоль восстановления не поддерживает использование универсальных символов в командах удаления. Например, команда del *. htm не поддерживается.
Ограничение доступа. Для регистрации на консоли восстановления необходимо ввести пароль учетной записи Administrator (Администратор).
Для снятия ограничений можно воспользоваться групповыми политиками или непосредственно модифицировать системный реестр. Соответствующие групповые политики расположены в каталоге Computer Configurations Windows SettingssSecurity Settingss Local Policiess Security Options (Конфигурация KOMnbiOTepaS Параметры WindowsS Параметры безопасности^ Локальные политики^Параметры безопасности). Ниже приведены эти политики.
Allow Automatic Administrative Logon (Разрешить автоматическую регистрацию администратора). Эта политика определяет автоматическую регистрацию на основе пароля учетной записи Administrator (Администратор).
Allow Floppy Copy and Access to All Drives and All Folders (Разрешить копирование на гибкий диск и доступ ко всем дискам и папкам). Эта политика снимает ограничение на копирование файлов с жесткого диска и позволяет перемещаться по всем дискам.
Copy prompts (Предупреждение при копировании). Для сохранения целостности файлов команда Сору выдает предупреждение при перезаписи файлов.
Нельзя сказать, что автор этой книги рекомендует включать эти политики. Просто эти возможности доступны. После включения второй политики в качестве дополнительного уровня защиты необходимо воспользоваться командой Set и установить переменные среды на консоли восстановления для получения расширенных функциональных возможностей. Ниже перечислены эти переменные среды (не забудьте добавить символы пробела по обеим сторонам от символа “=").
AllowWildCards = true
AllowAllPaths = true
AllowRemovableMedia = true
NoCopyPrompt'= true
Загрузка консоли восстановления из служб удаленной установки
Сервер служб удаленной установки (RIS-сервер) можно настроить на распространение образов консоли восстановления. Это упрощает использование консоли восстановления на компьютерах без приводов компакт-дисков.
На сервере уже должен находиться “плоский" образ удаленной установки. Дополнительная информация об установке этого образа приводится в главе 2, “Модернизация и автоматизированная установка”. На сервере служб удаленной установки необходимо создать файл SIF со следующим содержимым (назовите файл cmdcons . si f ):
[data]
floppyless = "1"
msdosinitiated = "1"
OriSrc = "\\%SERVERNAME%\RemInst\%INSTALLPATH%"
OriTyp = "4"
LocalSourceOnCD = 1
[SetupData]
OsLoadOptions = "/noguiboot /fastdetect"
SetupSourceDevice = "\Device\LanmanRedirector\%SERVERNAME%\RemInst\ %INSTALLPATH%"
[UserData]
FullName = "%USERFULLNAME%"
OrgName = "%ORGNAME%"
ComputerName = %MACHINENAME%
[Remoteinstall]
Repartition = no
[OSChooser]
Description = "Windows Server 2003 Recovery Console"
Help = "Loads a Windows Server 2003 Recovery Console.".
LaunchFile = "%INSTALLPATH%\%MACHINETYPE%\templates\startrom.com" ImageType=Flat
Version=0.0
Самая важная строка выделена полужирным шрифтом: Repartition = по. Если не добавить эту строку, службы удаленной установки выполнят форматирование диска. Эту ошибку будет сложно объяснить управляющему персоналу.
Разместите этот файл SIF в следующей папке на сервере служб удаленной установки: \RemoteInstall\Setup\English\ImagesWindows\i386\templates. Проверьте файл, загрузив клиент РХЕ и убедившись в загрузке файлов и запуске консоли восстановления. После этого консоль восстановления можно использовать так же, как при загрузке с установочного компакт-диска Windows Server 2003 или загрузке из папки \cmdcons.
Что дальше
Мы сделали это! Это было длинное путешествие, но мы добрались до завершения развертывания Windows Server 2003. Теперь можно откинуться в кресле и поговорить с коллегами. Если проблемы не исчезают и операционная система Windows Server 2003 кажется слишком сложной, вспомните слова Орсона Уэллса:
Тридцать лет гражданской войны, террора, убийств и грабежа в Италии при правлении Борджиа подарили миру Микеланджело, Леонардо да Винчи и Ренессанс. Швейцария пятьсот лет жила в братской любви, мире и демократии. И что она подарила миру? Часы с кукушкой...
Не забывайте о том, что нужно не только работать, но и отдыхать.
Предметный указатель
4
4GB Tuning, 34
4GT, 160
А
АССМ (Asynchronous Control Character
Map), 1096
ACE (Access Control Entry), 566
ACL (Access Control List), 336; 557
ACL Editor, 570; 576; 713
ACPI (Advanced Configuration and Power
Interface), 48; 54; 174
Active Directory
восстановление, 537
дерево, 329
доверительные отношения, 332
домен, 323
идентификация объектов, 348
контексты именования, 323
лес, 330
пространство имен, 322
репликация, 370
схема, 345
топология, 370
ActiveSync, 1066
ADAM (Active Directory Application Mode), 299", 367
ADES (Active Directory Federation Services), 368
ADMT (Active Directory Migration Tool), 335;
506,
ADSI (Active Directory Services Interface), 312
AES (Advanced Encryption Standard), 954; 994
AIA (Authority Information Access), 1019
AKI (Authority Key Identifier), 1019
ANSI (American National Standards Institute), 307
APIC (Advanced Programmable Interrupt Controller), 167
APIPA (Automatic Private IP Addressing), 75;
188
АРМ (Advanced Power Management), 54; 174
ARC (Advanced RISC Computing), 89
ASHA, 351
ASP (Application Service Provider), 700
ASQ (Attribute Scoped Query), 299
ASR (Automated System Recovery), 1203
AWE (Address Windowing Extensions), 161
В
Baseline Security Analyzer, 179
BINL (Boot Information Negotiation Layer), 131
BITS (Background Intelligent Transfer Service), 858
Bridgehead, 379
B-tree, 820
Builtin, 555
Bus-mastering, 49
c
CA (Certification Authority), 1004
CAL (Client Access License), 60
CBCP (CallBack Control Protocol), 1097 ccNUMA (cache-coherent Non-Uniform
Memory Allocation), 153
CCP (Compression Control Protocol), 1097 ccTLD, 243
CDP (CRL Distribution Point), 1002; 1008
CDPD (Cellular Digital Packet Data), 1066 CHAP (Challenge Handshake Authentication
Protocol), 1101; 1104
CHS (Cylinder/Head/Sector), 93
CIFS (Common Internet File System), 205
CIM (Common Information Model), 683
CIM Studio, 684
CIMOM (Common Information Model Object
Manager), 684
Citrix MetaFrame, 62
CIW (Client Installation Wizard), 132
ClassID, 659'
CLFS (Common Log File System), 839'
CLT (Cross-Trust Lists), 1014
CMC (Certificate Management Messages over
CMS), 1022
CMP (Certificate Management Protocol), 1022
CMS (Cryptographic Message Syntax), 1022 CN (Common Name), 5/6
Common Criteria (CC), 1007
CRL (Certificate Revocation List), 1007
CSC (Client-Side Caching), 1059
CSE (Client-Side Extension), 652; 658
CSRSS (Client/Server Runtime Sybsystem), 164
D
DACL (Discretionary Access Control List), 565
DAP (Directory Access Protocol), 308
DBCS (Double-Byte Character Set), 589
DDF (Data Decryption Field), 949; 955
DDK (Driver Development Kit), 177
Deleted Objects, 391
Delta CRLs, 1007; 1010
DEN (Directory Enabled Networking), 328
DES (Data Encryption Standard), 993
Dfs (Distributed File System), 881
Dfs Namespace, 900
DFSR (Distributed File System Replication), 900
DHCP (Dynamic Host Configuration
Protocol), 1092
DHCP Allocator, 1174
DHCPINFORM, 1092; 1153; 1172
DIB (Directory Information Base), 308
Digest, 556
DISP (Directory Information Shadowing
Protocol), 309
DIT (Directory Information Tree), 308
DMA (Direct Memory Access), 169
DMD (Directory Management Domain), 309
DMO (Directory Management Organization), 309
DN (Distinguished Name), 349
DNP (Domain Name Pointer), 254
DNS (Domain Name System), 239
DNSSec, 265
Domain Master Browser, 456
Domain Naming Master, 458
DOP (Directory Operational Binding
Management Protocol), 309
DPAPI (Data Protection API), 950; 998
DRA (Data Recovery Agent), 950; 955
DRA (Directory Replication Agent), 371
DRF (Data Recovery Field), 950; 955
Driver Rollback, 152
DSA (Digital Signature Algorithm), 997
DSA (Directory Service Agent), 308
DSP (Directory System Protocol), 309
DSS (Digital Signature Security), 994
Dssenh, 998
DU A (Directory User Agent), 308
Dual View, 189
E
EAP (Extensible Authentication Protocol), 1101; 1106
EFI (Extensible Firmware Interface), 44; 779
EFI Boot Manager, 46
EFS (Encrypted File System), 947
El Torito, 44
EMF (Enhanced Metafile), 904
EMS (Emergency Management Services), 148;
1221
Error Reporting, 1216
ERSvc (Error Reporting Service), 164
ESE (Extensible Storage Engine),311
ESP (EFI System Partition), 45; 779
ESP (Encapsulating Security Payload), 1179
EULA (End User License Agreement), 70
Executive, 162
F
FACP (Fixed ACPI Description Table), 175
FAT (File Allocation Table), 790; 793
FAT32,43
FEK (File Encryption Key), 949
Fibre Channel, 41
File Server Management, 844
FIPS (Federal Information Processing
Standards), 954
FQDN (Fully Qualified Domain Name), 242
FR (File Recovery), 949; 959
FRADS (Frame Relay Access Devices), 1093 FRS (File Replication Service),336; 433; 888 FSMO (Flexible Single Master Operations), 453
FSRM (File Server Resource Manager),844 FSTW (Files and Settings Transfer Wizard), 1038
FT, 42
G
GC (Global Catalog), 330
GDI (Graphic Device Interface), 904
Gemplus, 1123
GINA (Graphical Identification and , Authentication), 67; 556
GPC (Group Policy Container), 448; 652; 665
GPD (Generic Printer Description), 906
GPE (Group Policy Editor), 449; 652; 677■
GPMC (Group Policy Management Console), 710
GPO (Group Policy Object), 449", 651
GPT (Group Policy Template), 449; 652; 663
GPT (GUID Partition Table), 44; 742; 778 GRE (Generic Routing Encapsulation), 1177
Group Account Migration Wizard, 513 gTLD (generic Top Level Domain), 243 GUID (Globally Unique Identifier), 350
H
Hardware Update Wizard, 190
HCL, 38
HMAC (Hashed-based Message Authentication
Code), 957; 995■
Hotfix, 109
Hyperterminal, 1221
Hyperthreading, 34
I
IAS (Internet Authentication Service), 1109;
1183
ICANN (Internet Corporation for Assigned Names and Numbers), 242
ICE (Internet Connection Firewall), 1171
ICS (Internet Connection Sharing), 1170 \D^/NV^41
IEC (International Electromechanical
Commission), 307
IETF (Internet Engineering Task Force), 307
IFS (Installable File System), 785
IMAPI, 44
Infineon, 1123
Infrastructure Master, 457
Interix, 163; 569
IPC (Interprocess Connection), 861
IPCP (Internet Protocol Control Protocol), 1099
IPMI (Intelligent Platform Management Interface), 189
IPP (Internet Print Protocol),910
IPX (Internetwork Packet Exchange), 1099
IPXCP (IPX Control Protocol), 1099
IP-адрес, 200
IRP (I/O request packets), 177
IRQ, 167'
IRQ Steering, 51
IRQL, 167
ISAKMP (Internet Security Association and
Key Management Protocol), 1180
ISAM (Indexed Sequential Access Method), 312
180,306
ISTG (Inter-Site Topology Generator), 380
Itanium, 155
ITU-T, 306
J
Joliet, 44•
К
KCC (Knowledge Consistency Checker), 375
KeBugCheckEx, 1215
Kerberos, 332; 599'
Key Recovery Agent, 1027
KeylD, 1019
KMS (Key Management Service), 1006; 1026
KVM (Keyboard/Video/Mouse), 148
L
L2,39.
L2TP (Layer Two Tunneling Protocol), 1179
LanMan Workstation, 862
LANRover, 1103'
LBA (Logical Block Addressing), 794
LCN (Logical Cluster Number), 814
LCP (Link Control Protocol), 1096
LDAP (Lightweight Directory Access
Protocol), 311
LDAP Browser, 361
LDIF (LDAP Data Interchange Format), 364; 502
LDM (Logical Disk Manager), 42; 52; 742; 744
LDP, 36/
LES (Log File Service), 837
LMRepl,347
LPR (Line Printer Protocol), 910
LSA (Local Security Authority), 303; 553
LSASS (Local Security Authority Subsystem), 554■
LTS (Link Tracking Service), 828
м
М АС-адрес, 200'
Mailslot, 862
MBR (Master Boot Record), 47; 84; 751
McKinley, 155•
MD5-CHAP, 1106
MetaFrame, 1063
MFT (Master File Table), 800'
Microsoft Client, 865
Microsoft Services for NFS, 901
MMC3.0,112
MountMgr, 55
MPPC (Microsoft Point-to-Point Compression), 1097
MPPE (Microsoft Point-to-Point Encryption), 1098; 1178’
MPR (Multiple Provider Router), 864
MRRU (Maximum Received Reconstructed
Unit), 1096
MS-CHAP (Microsoft CHAP), 1101
MSR (Microsoft Reserved Partition), 45; 781
MSV1_O,555.
MTBF, MTU (Maximum Transmission Unit), 1100
MUP (Multiple UNC Provider), 864
N
NAT (Network Adderess Translation), 1166
NAT Editor, 1168
NBFCP (NetBIOS Frame Control Process), 1099
NC (Naming Context), 320
NCB (Network Control Block), 203; 862
NCP (Network Control Protocol), 1096
NDIS (Network Device Interface
Specification), 1094
NDIS (Network Driver Interface Specification), 187; 199; 861
Negotiate, 556
NetBIOS, 862
NFS (Network File System), 901
NLB (Network Load Balancing), 1063
NLS (National Language Support), 58
NTFS, 42
NTVDM (NT Virtual DOS Machine), 155
NWCWorkstation, 862
О
OCSP (Online Certificate Status Protocol), 1020
OID (Object Identifier), 351
OLAP, 36
OOB (Out-of-Band), 148
OSC (OS Chooser), 132
OSCML (OS Chooser Markup Language), 137
OSI (Open System Interconnection), 198
OU (Organiztional Unit), 440
OWF (One-Way Function), 587
P
PAC (Privilege Access Certificate), 435; 609;
712
PAD (Packet Assembler/Disassembler), 1093
PAE (Physical Address Extensions), 92; 162
PAP (Password Authentication Protocol), 1101
PAS (Partial Attribute Set), 331
Password Synchronization, 552
PAT (Port Address Translation), 1167
PCD (Characterization Data), 906
PCI, 168
PDC Emulator, 454
PDO (Physical Device Object), 177
Performance Monitor, 194
PFX (Personal Information Exchange), 963
PIN, 1122
PIO (Programmed I/O), 169
PKI (Private Key Infrastructure), 989
PKT (Partition Knowledge Table), 882; 887
Plug and Play Manager, 170
PnP (Plug-and-Play), 170; 1136
PocketPC, 1066
Poledit, 696; 875-
PoPToP, 1178
POSIX, 163; 569
POST (Power On Self Test), 84
Power Manager, 171
PPD (Postscript Printer Description), 906
PPP (Point-to-Point Protocol), 1093; 1095
PPPoA (Point-to-Point over ATM), 1093
PPPoE (Point-to-Point Protocol over ■
Ethernet), 1091; 1099
PPTP (Point-to-Point Tunneling Protocol), 1090
PRD (Password Reset Disk), 596; 958
PSTN (Public Switched Telephone Network), 1092
PVC (Permanent Virtual Circuit), 1093
PXE (Preboot Execution Environment), 46; 130
Q
Qualified Subordination — QS, 1014
R
RA (Registration Authority), 1026
RADIUS (Remote Authentication Dial-In User
Services), 1109; 1183
RAID (Redundant Array of Independent
Disks), 43; 744
RAS (Remote Access Server), 1120
RBFG (Remote Boot Floppy Generator), 130; 141
RDC (Remote Differential Compression), 900
Rdclip, 1067
RDN (Relative Distinguished Name), 318
RDP (Remote Desktop Protocol), 1062
Recovery Agent, 1027
Recovery Console, 44; 1228
Registry reflector, 157
Remote Access, 1159
Remote Assistant, 1084
Remote Desktop, 1062
Remote Installation Preparation Wizard, 140
Remote Installation Wizard, Risetup, 143
Reparse point, 136
RFC (Request for Comments), 307
RID (Relative ID), 350; 456
RID Master, 350; 456
RIS (Remote Installation Services), 129
Root hints, 247
RootDSE, 321
RPC (Remove Procedure Call), 374
RRAS (Routing and Remote Access Service),
1134; 1145
RS A, 996
RSAenh, 998
RSDIR (Remote Storage File Analysis), 136
RSDT (Root System Description Table), 175
RSL (Registry Size Limit), 300
RSM (Removable Storage Management), 742;
1190; 1204
RSM (Removable Storage Manager), 186
RSoP (Resultant Set of Policies), 447; 671
RTT (Round-Trip Time), 248
s
S.M.A.R.T., 184
SA (Security Association), 1180
SAC (Special Administrative Console), 1222
SACL (Security Access Control List), 565
Safe Mode, 1224
SAM (Security Account Manager), 300; 554
SAS (Secure Attention Sequence), 67; 556
SASL (Simple Authentication and Security
Layer), 556
Schannel, 556
Schema Master, 458
Schema Operations Master, 357
Schlumberger, 1123
SCSI, 41
SecurlD, 1123
Server Configuration Wizard, 53; 76 ,
SFC (System File Checker), 842
SFM (Services for Macintosh), 817
SHA (Secure Hash Algorithm), 995
SharePoint Services, 943
Shiva, 1103
SHS (Secure Hash Standard), 995
SID (Security Identifier), 350
SID History, 507
Side-by-Side assembly, 1036
SIF (Setup Information File), 137
SIS (Single Instance Storage), 135
SIS Groveler, 135
SKI (Subject Key Identifier), 1019
SKU (Stock Keeping Units), 60
SLS (Secondary Logon Service), 736
SMBus, 174
SMfS, 773
SMTP (Simple Mail Transport Protocol), 375
SPAP (Shiva PAP), 1101; 1103
SPI (Security Parameter Index), 1179
SPN (Service Primary Name), 632
SRM (Security Reference Monitor), 557; 712
SSO (Single Sign-On), 368
SSP (Security Support Provider), 555
SSPI (Security Support Provider Interface), 555
Storage Management for SANs, 773
Subnet Master Browser, 456
SUS (Software Update Service), 152; 181
SVC (Switched Virtual Circuit), 1093
SxS (Side-by-Side), 701; 1037
System Restore, 1199
System State, 534; 1202
т
TAPI (Telephony API), 1094
TCP (Transport Control Protocol), 200
TDI (Transport Driver Interface), 861
Terminal Services, 1062■
TGT (Ticket-Granting Ticket), 604
TLD (Top-Level Domain), 242.
TS CAL, 1075'
TSL (Terminal Services Licensing), 1076
TSWeb, 1073
Twclient, 877
u
UDF (Universal Disk Format), 856
UDP (User Datagram Protocol),200
UMST (User State Migration Toolkit), 1043
UPN (User Principal Name), 351
UPS (Uninterruptible Power Supply),48
User Account Control, 611
USMT (User State Migration Toolkit), 1036;
1038
USN (Update Sequence Number), 839
UTD Vector, 388
UUID (Universally Unique Identifier), 350
V
VCN (Virtual Cluster Number), 815
VDM (Virtual DOS Machine), 903
VDS (Virtual Disk Service), 878
VMM (Virtual Memory Manager), 154
VMWare, 52
VP A (Volume Purchase Agreement), 80
VPN (Virtual Private Network), 1177
VS (Volume Shadow), 1198
w
WBEM (Web-Based Enterprise Management), 683
WDM (Windows Driver Model), 176
Web Enrollment, 1015
Web farm, 36
WebDAV (Web-based Distributed Authoringand Versioning), 818•
Web-сервер, 77
WEP (Wired Equivalent Privacy), 1091
WFP (Windows File Protection), 840
WHQL (Windows Hardware Quality Lab), 38
Win32K, 163
Windows Debugger, 1219
Windows Driver Protection, 165
Windows Executive, 162
Windows Update, 152; 179
' Winlogon, 67; 556
Winsock (Windows Sockets), 862
WMI (Windows Management Instrumentation), 683; 738
Wnet, 861’
WOW (Windowsl6-on-Windows32), 155
WOW64 (Windows32-on-Windows64), 156; 903
WPA (Windows Product Activation), 79
WQL (WMI Query Language), 684
WS-Federation, 368
WS-Management, 190
WTS (Windows Time Service), 66
X
X.500,308 XOR, 746■
A
Авторизация, 558 Агент восстановления данных (DRA), 550; 955 восстановления ключей, 1026 создание, 1027 гровелера, 135■’
миграции паролей, 512 пользователя каталога, 308 репликации каталога, 371 службы каталога, 308; 318
Адаптер РРР, 1150
Адрес
IP, 1152
для многоадресной отправки, 1163 широковещательный, 1163
Адресное пространство, 154
Активация, 79", 80 автоматическая, 126
Алгоритм PBKDF2,957.
сжатия■
RDC, 900 хеширования, 587
MD4,995
MDS, 995
SYLA.995
SHA-1,995
шифрования
3DES, 953; 994
AES, 954; 994
DES, 951; 993
DESX, 953; 993
RC2,993
RC4,993
Rijndael, 954
Аплет
Phone and Modem Options, 1142
Stored User Names and Passwords, 594
Архивация
добавочная, 1193
ежедневная, 1194
обычная, 1193
Архитектура
EFI, 45
IA64,52
управление памятью, 155
Атака
отказ в обслуживании, 608
посредника, 608
Атрибут, 348
$Data, 950; 951
$Logged_Utility_Stream, 950
AltSecurityldentities, 633
CH, 316
DbcsPwd, 589
DC, 316
DN, 317; 349
FSMORoleOwner, 453
GPLink, 668
GPOptions, 668
InterSiteTopology Generator, 381
LmPwdHistory, 589
Member, 457; 726
MemberOf, 457; 726
NtPwdHistory, 589
ObjectGUID, 365
RIDAllocationPool, 456
SAMAccountName, 351
SIDHistory, 507
UnicodePwd, 589
обязательный, 348
связанный, 457
создание, 351
файла, 796
частичный набор (PAS), 55/
Аудит, 558
безопасности, 639
доступа к объектам, 643
управления миграцией учетных записей, 512
Аутентификатор, 607; 1124
предварительный, 608
Аутентификация, 558
в нескольких доменах, 1112
взаимная, 609
коммутируемого доступа, 1111
междоменная, 593; 619
односторонняя, 600
по РРР, 1101
по смарт-картам, 1106
с помощью RADIUS, 1109
сквозная, 303; 600
Б
База данных
SSecure, 808
Active Directory, 323; 345
восстановление, 547
размер, 45/
Builtin, 555
CSC, 1059
Kerberos, 627
LDM, 746
ESA, 555
LSA Secret, 303
SAM, 300; 470; 555
Secedit.sdb, 555; 580; 689
Security Editor, 693
механизм управления, 311
службы каталогов, 312
центра сертификации, 1004
Безопасность, 115
Библиотека
Davclnt.dll, 862
GINA, 67; 556
Gptext.dll, 659
Ipnathplt.dll, 1171
Ntdll.dll, 58
Ntlanman.dll, 862
Nwwks.dll, 862
PrintUI.dll, 915
Rdpnp.dll, 862
Seclogon.dll, 736
Shimgvw.dll, 928
SID History, 507
wow64.dll, 156
wow64cpu.dll, 157
wow64exts.dll, 157
wow64win.dll, 157
Ws_32.dll, 862
магнитных лент, 1207
Билет, 602; 603
Kerberos, 618
TGT, 604
межсферный, 607; 620
перенаправляемый, 622; 967
пользователя, 624
прокси, 622
сеанса доступа, 604
службы, 623
Брандмауэр подключения к Интернету (ICF), 1171
В
Ввод-вывод, 177
низкоуровневый, 178
обработка, 166
программируемый, 169
Вектор обновления, 388
Взлом паролей, 588
Видеоадаптер
DualView, 189
Возможность, 355
Восстановление1
авторитетное, 538
базы данных Active Directory, 547 данных
на отказоустойчивых дисках, 770
жесткое, 547
зашифрованных файлов, 966
каталога Sysvol, 542
мягкое, 547
после критических ошибок, 1215
секретного ключа, 1031
системы, 974; 1203
файлов, 1212
файловой системы, 833
шифрованных файлов, 985
Время сходимости, 373
Выборы обозревателя, 878
Г
Генератор межсайтовой топологии, 380
Группа
Anonymous Logon, 1121
Authenticated Users, 66
Backup Operators, 1200
Creator/Owner, 562
Domain Admins, 867
Enterprise Admins, 1017
Everyone, 478; 562; 598; 871; 1121
Group Policy Creator Owners, 688
Incoming Forest Trust Builders, 334
Local, 562
Local Service, 563
Local System, 563
Network Service, 563
Pre-Windows 2000 Compatible Access, 1121
Primary, 562
PW2CA, 478
RAS and IAS Servers, 1113
Remote Desktop Users, 149
Schema Admins, 357
Server Operators, 724
вложенная, 435
встроенная, 724
Remote Desktop Users, 1070
глобальная, 435; 726
дисков, 748
локальная для домена, 435; 725
локальная для компьютера, 724
распространения, 436
тип, 723
универсальная, 435; 726
д
Дайджест сообщения, 588; 994
Дамп
памяти, 82; 1217
малый, 1218
просмотр содержимого, 1219
ядра, 1218
стека, 83
Дата, 65
Делегирование, 273; 620; 718
некорректное, 274
управления политиками, 687
Демон
kadmin, 628
krbSkdc, 628
Дерево, 329
Дескриптор SPI, 1179
Дескриптор безопасности, 553; 557; 565; 712;
808
объектов Active Directory, 571
просмотр, 713
службы, 570
файла и каталога NTFS, 571
Дефрагментация, 821
системного раздела, 107
тома, 850
Дешифровка файла, 950
Диск
GPT, 44; 47; 744; 779
разбиение, 47
MBR, 744
базовый, 109
преобразование, 751
буквенное обозначение, 55
динамический, 109; 744; 749
для загрузки по сети, 128
загрузочный
РХЕ, 130'
создание, 754
клонирование, 116
кэширование аппаратное, 49
сброса пароля (PRD), 595; 958
Дисковый массив, 42
Диспетчер
DHCP, 132
Plug-and-Play, 163; 170
PnP, 1136
ввода-вывода, 163; 861
виртуальной памяти, 154; 163
загрузки EFI, 46
задач, 159
конфигурации, 163
лицензий, 60; 62
логических дисков (LDM), 52; 742; 744
обслуживания, 69
объектов, 163
объектов CIM, 684
пользователей, 469
пользователей домена, 302
процессов, 163
сеансов, 87
серверов, 303'
синхронизации, 1058
таблиц, 311"
управления питанием, 163; 171
управления службами, 861
установки, 103; 120
устройств, 98; 171; 1137
устройств Plug-and-Play, 108
учетных записей безопасности, 554
Добавление
жесткого диска IDE, 182
приводов сменных носителей, 186
процессора, 182
Доверенность для делегирования, 968
Доверительное отношение
в Active Directory, 332
внешнее, 333
между деревом и корневым доменом, 333;
334
между лесами, 334
между родительским и дочерним
доменами, 333; 334
между сферами, 333; 633
прямое, 333; 620
транзитивное, 332.
Доверительные отношения, 303
Домен, 65; 323; 430
DNS, 241
верхнего уровня, 242
корневой, 242
переименование, 517
режим
Windows 2000 Mixed, 341
Windows 2000 Native, 341
управления каталогом, 309
Домен-контейнер, 483
Доступ
анонимный, 1121
удаленный, 1095
по смарт-картам, 1122
Драйвер
Atapi.sys, 57
Atdisk.sys, 57
Cdfs.sys, 58
Class2.sys, 57
Classpnp.sys, 57
Disk.sys, 57
Dmbootsys, 57
Dmio.sys, 57
Dmload.sys, 57
Fastfat.sys, 58; 793
Floppy .sys, 57
Ftdisk.sys,58
Hidusb^sys, 58
I2Omgmt.sys, 57
I2Omp.sys, 57
I8042prt.sys, 57
Isapnp.sys, 57
Kbdclass.sys, 57
Kbdus.dll, 57
Ksecdd.sys, 58
Mountmgr.sys, 58
Mrxdav.sys, 867 mrxsmb.sys, 201; 866
NDIS, 187; 199
Ndiswan.sys, 1094
netbt.sys, 203
Ntfs.sys, 58
Nwrdr.sys, 866
Openhci.sys, 58
Partmgr.sys, 58
Rdpdr.sys, 867
Scsiport.sys, 58
Serenum.sys, 58; 1136
Serial.sys, 58
setupdd.sys, 58
Smss.exe, 58
srv.sys, 201; 867
tcpip.sys, 200
Uhcd.sys, 58
Usbd.sys, 58
Usbhub.sys, 58
Vga.sys, 58
Videoprt.sys, 58 безопасности ядра, 58 видеоадаптера VGA, 58 защита, 152 интерфейса USB, 58 клавиатуры, 57 класса, 178 мини-порта, 1094 мини-порта SCSI, 86 обновление, 190 откат, 152; 191 плоттера (Msplot.dll), 905 подсистемы диспетчера сеансов, 58 принтера, 904
Postscrip (Pscript.dll), 905
универсальный (Unidrv.dll), 905
устройства, 164 фильтрующий, 178
функций, 178
шины, 177
шины SCSI, 58
ядра
ntkrnlpa.exe, 162
ntoskrnl.exe, 162
Ж
Журнал
Appmgmtlog, 704
Secevent.evt, 640
аудита, 640
безопасности, 81; 640
диагностики службы Windows Installer, 704
загрузки драйверов ядра, 1224
изменений, 838
модема, 1144
обнаружения модема, 1144
приложений, 81
производительности, 195
резервного копирования, 1194
системный, 81
службы каталогов, 81
службы репликации файлов, 81
удаленного доступа, 1149
3
Загрузка, 84
вторичная, 85
задержка, 85
из файла, 69
начальная, 84
Загрузчик
ia64ldr.efi, 84
Ntldr, 51; 53; 85
Setupldr, 57
Setupldr.bin, 54
вторичный, 85
для архитектуры IA64, 779
Закрепление, 1056
Запись
А, 245
Host, 339
MBR, 47; 84
SOA, 255
SRV, 241; 337; 426
^N\^,262;284
WINS-R, 262; 284
каталога, 819
метаданных, 800
ресурсов, 245
связующая, 260
файла, 810
Запись контроля доступа, 566
Запрос, 555
ASQ, 299
DNS, 257
DPN, 254
LDAP, 299
билета сеанса доступа, 617
в пределах атрибута, 299
доступа, 617
записей SRV, 339
итеративный, 246
обратного преобразования, 252
рекурсивный, 246
Затенение, 326
пользовательского сеанса, 1080
Защита процессов, 162
Знание, 375; 620
Зона, 241
Зона DNS
динамическая, 280
заглушка, 240; 259
интеграция в Active Directory, 257
обратного преобразования, 253; 270
прямого преобразования, 252; 269
репликация, 255
И
Идентификатор
SCSI, 89
SCSI ID, 771
безопасности, 336; 456; 560
группы, 559
нулевого сеанса, 562
ограничивающий, 559
пользователя, 559
предопределенный, 561
регистрационный, 559
безопасности (SID), 350
глобально уникальный (GUID), 349
инсталляции, 79
класса, 350; 659
ключа владельца сертификата (SKI), 1019
ключа издателя сертификата (AKI), 1019
объекта (OID), 351
относительный, 350", 456
предопределенный, 563
подтверждения, 79", 111
регистрационный, 304
сети, 271
службы, 202
Имя
FQDN, 242
NetBIOS, 202
группы LDM, 748
доменное, 3 Уб
компьютера, 64
контроллера домена, 64
корневого домена, 429
неоднозначное, 356
нетипизированное, 318
относительное характерное, 318
отображение, 633
плоское, 202; 351
преобразование, 1154
пользователя
полное доменное, 351
сохранение, 594,
регистрационное, 351
сервера, 63
службы
основное (SPN), 632
типизированное, 318
характерное, 317; 349", 392
Инвентаризация, 170
устройств РпР, 67
Инициатива DEN, 328
Инструментарий
UMST, 1043
USMT, 1038
Интерфейс
ACPI, 48; 54; 174
M3SV312
АТА, 41
Citrix MetaFrame, 62
DP API, 957
"OV> К,308
EFI, 44; 779
GDI, 904
Hpmon, 911
IMAPI, 44
Serial ATA, 41
SSPI, 555
TSWeb, 1073
с дозвоном по запросу, 1160
транспортных драйверов (TDI), 861
Инфраструктура открытого ключа (PKI), 989
К
Кадр
Ethernet, 1094
максимальный размер, 1096
Канал DMA, 169
Карта кластеров, 795
FAT32, 798Каталог, 790; 796\$win_nt$.-bt, 110\$win_nt$.-ls, 110\Application Data\Microsoft\DrWatson, 164 \cmdcons, 1228Crypto/RSA, 999\Documents and Settings, 104 \I386\Update, 128Netlogon, 707\RemoteInstall\Admin, 130 \RemoteInstall\OSChooser\I386,135 SIS Common Store, 135System Certificates\Certificates, 999System Volume Information, 877 ^о\,336;542;652 \Windows, 59,90 \Windows\CSC, 1057 \Windows\Inf, 115; 171; 690; 695 \Windows\NTOS, 353 \Windows\Prefetch, 787 \Windows\Security\Database, 555; 580 \Windows\Security\Templates, 690 \Windows\Symbols, 1219 \Windows\System32\CertSrv, 1024 \Windows\System32\Config, 80 \Windows\System32\DllCache, 841 \Windows\System32\DNS, 244 \Windows\System32\Drivers, 171 \Windows\System32\GroupPolicy, 681 \Windows\System32\Spool\Drives, 868 \Windows\System32\Spool\Printers, 907 \Windows\System32\USMT, 1042 \Windows\Sysvol, 449 \Windows\Sysvol\Sysvol, 868 \Windows\Sysvol\Sysvol\Scripts, 868 \Windows\SysWOW64,156; 157 \Windows\Tracing, 1142\WINNT, 59\Winnt\Profiles, 104 \WINNT\System32\Drivers\Etc, 468 глобальный (GC), 330 домашний, 1049 перенаправление, 1045 системный, 90 суперскрытый, 135 фрагментация, 821Квалифицированное подчинение (QS), 1014 Квота, 843КлассAttributeSchema, 348FAT32, 798Каталог, 790; 796\$win_nt$.-bt, 110\$win_nt$.-ls, 110\Application Data\Microsoft\DrWatson, 164 \cmdcons, 1228Crypto/RSA, 999\Documents and Settings, 104 \I386\Update, 128Netlogon, 707\RemoteInstall\Admin, 130 \RemoteInstall\OSChooser\I386,135 SIS Common Store, 135System Certificates\Certificates, 999System Volume Information, 877 ^о\,336;542;652 \Windows, 59,90 \Windows\CSC, 1057 \Windows\Inf, 115; 171; 690; 695 \Windows\NTOS, 353 \Windows\Prefetch, 787 \Windows\Security\Database, 555; 580 \Windows\Security\Templates, 690 \Windows\Symbols, 1219 \Windows\System32\CertSrv, 1024 \Windows\System32\Config, 80 \Windows\System32\DllCache, 841 \Windows\System32\DNS, 244 \Windows\System32\Drivers, 171 \Windows\System32\GroupPolicy, 681 \Windows\System32\Spool\Drives, 868 \Windows\System32\Spool\Printers, 907 \Windows\System32\USMT, 1042 \Windows\Sysvol, 449 \Windows\Sysvol\Sysvol, 868 \Windows\Sysvol\Sysvol\Scripts, 868 \Windows\SysWOW64,156; 157 \Windows\Tracing, 1142\WINNT, 59\Winnt\Profiles, 104 \WINNT\System32\Drivers\Etc, 468 глобальный (GC), 330 домашний, 1049 перенаправление, 1045 системный, 90 суперскрытый, 135 фрагментация, 821Квалифицированное подчинение (QS), 1014 Квота, 843КлассAttributeSchema, 348
FAT32, 798
Каталог, 790; 796
\$win_nt$.-bt, 110
\$win_nt$.-ls, 110
\Application Data\Microsoft\DrWatson, 164 \cmdcons, 1228
Crypto/RSA, 999
\Documents and Settings, 104 \I386\Update, 128
Netlogon, 707
\RemoteInstall\Admin, 130 \RemoteInstall\OSChooser\I386,135 SIS Common Store, 135
System Certificates\Certificates, 999
System Volume Information, 877 ^о\,336;542;652 \Windows, 59,90 \Windows\CSC, 1057 \Windows\Inf, 115; 171; 690; 695 \Windows\NTOS, 353 \Windows\Prefetch, 787 \Windows\Security\Database, 555; 580 \Windows\Security\Templates, 690 \Windows\Symbols, 1219 \Windows\System32\CertSrv, 1024 \Windows\System32\Config, 80 \Windows\System32\DllCache, 841 \Windows\System32\DNS, 244 \Windows\System32\Drivers, 171 \Windows\System32\GroupPolicy, 681 \Windows\System32\Spool\Drives, 868 \Windows\System32\Spool\Printers, 907 \Windows\System32\USMT, 1042 \Windows\Sysvol, 449 \Windows\Sysvol\Sysvol, 868 \Windows\Sysvol\Sysvol\Scripts, 868 \Windows\SysWOW64,156; 157 \Windows\Tracing, 1142
\WINNT, 59
\Winnt\Profiles, 104 \WINNT\System32\Drivers\Etc, 468 глобальный (GC), 330 домашний, 1049 перенаправление, 1045 системный, 90 суперскрытый, 135 фрагментация, 821
Квалифицированное подчинение (QS), 1014 Квота, 843
Класс
AttributeSchema, 348
FAT32, 798
Каталог, 790; 796
\$win_nt$.-bt, 110
\$win_nt$.-ls, 110
\Application Data\Microsoft\DrWatson, 164 \cmdcons, 1228
Crypto/RSA, 999
\Documents and Settings, 104 \I386\Update, 128
Netlogon, 707
\RemoteInstall\Admin, 130 \RemoteInstall\OSChooser\I386,135 SIS Common Store, 135
System Certificates\Certificates, 999
System Volume Information, 877 ^о\,336;542;652 \Windows, 59,90 \Windows\CSC, 1057 \Windows\Inf, 115; 171; 690; 695 \Windows\NTOS, 353 \Windows\Prefetch, 787 \Windows\Security\Database, 555; 580 \Windows\Security\Templates, 690 \Windows\Symbols, 1219 \Windows\System32\CertSrv, 1024 \Windows\System32\Config, 80 \Windows\System32\DllCache, 841 \Windows\System32\DNS, 244 \Windows\System32\Drivers, 171 \Windows\System32\GroupPolicy, 681 \Windows\System32\Spool\Drives, 868 \Windows\System32\Spool\Printers, 907 \Windows\System32\USMT, 1042 \Windows\Sysvol, 449 \Windows\Sysvol\Sysvol, 868 \Windows\Sysvol\Sysvol\Scripts, 868 \Windows\SysWOW64,156; 157 \Windows\Tracing, 1142
\WINNT, 59
\Winnt\Profiles, 104 \WINNT\System32\Drivers\Etc, 468 глобальный (GC), 330 домашний, 1049 перенаправление, 1045 системный, 90 суперскрытый, 135 фрагментация, 821
Квалифицированное подчинение (QS), 1014 Квота, 843
Класс
AttributeSchema, 348
ClassSchema, 348
inetOrgPerson, 347
абстрактный, 314
вспомогательный, 314
наследование, 313
объектов, 345
службы каталогов, 3/2
создание, 351
структурный, 314
экземпляр, 346
Кластер; 790
NLB, 35; 1063
виртуальный номер (VCN), 815
логический номер (LCN), 814
Клиент, 857
РХЕ, 131
Клонирование дисков, 116
Ключ
RSA, 997
архивация, 1006
восстановление, 1026
восстановления файлов, 949; 959
открытый, 980
секретный, 963; 981
главный, 957; 999
открытый, 996
пользователя, 955
сеанса, 607; 957
секретный, 981
шифрования
асимметричный, 994
симметричный, 994
шифрования файла (РЕК), 949,954 Код критической ошибки, 1215 Коллизия, 995
Кольцо репликации, 376
Команда
7,69
bootcfg, 69
capture, 910
cipher, 953
dir, 69,89
Is, 69; 288
Iserver, 288
map, 68
netsh, 189
root, 288
server, 287
start, 167
winmsd, 95; 172
winnt32,107
Командный интерпретатор
cmd.exe, 92
EFI, 46; 68
Компьютер
добавление в домен, 65
Конвейер, 861
Консоль
Active Directory — Domains and Trusts, 354;
439, 472; 500
Active Directory — Sites and Services, 354;
405
Active Directory — Users and Computers, 277; 298; 354; 472; 491
ADSI Edit, 358
Computer Management, 301; 873; 1174
Device Manager, 1137
Dfs, 896
Disk Defragmenter, 821; 851
Disk Management, 757; 848
DNS, 275
Event Viewer, 640; 930
Fax, 928
Fax Service Manager, 922
File Server Management, 844
IIS Management, 917
Internet Authentication Service, 1184
Local Policy Editor, 681
Local Security Settings, 689
Performance Monitor, 194
Print Management, 939
Recovery Console, 1228
Routing and Remote Access Service, 1109,
1145
SAC, 1222
Schema, 355
Security Configuration and Analysis, 691
Terminal Services Configuration, 1071
Terminal Services Manager, 1079
WINS, 203
восстановления, 44; 1228
управления групповыми политиками
(GPMC), 710
Контейнер
Deleted Objects, 390
DisplaySpecifiers, 326
Extended Rights, 327
Lost and Found, 327
Partitions, 327; 458
Physical Locations, 328
Services, 328
Sites, 328
групповой политики (GPC), 448
Контекст безопасности, 1180
Контекст именования, 320
Active Directory, 323
Application, 370; 381
Configuration, 326; 382; 666
Domain, 666
DomainDNSZones, 325
ForestDNSZones, 325
Schema, 324; 355; 458; 540
приложений, 324
Контроллер домена
Active Directory, 336
RID Master, 350
Schema Operations Master, 357
выход из строя, 521
оптимизирующее соединение, 377
основной, 65; 302
переименование, 517
понижение, 516
связующий сервер, 379
скачок нагрузки, 343
хозяин операции, 453
Конфликт при репликации, 390
Копирование зашифрованного файла, 971
Корень
доменный, 883
изолированный, 883
леса, 66
распределенной файловой системы, 882
удаление, 899
Кэш
преобразования имен сайта, 339
регистрационных данных, 593
Кэширование
дисков, 49
ключей пользователя, 968
Кэш-память
второго уровня, 39
третьего уровня, 40
Л
Лес, 330
Лицензирование, 60
автоматическое, 1078
сервера терминалов, 1075
Лицензия
Internet Connector, 1076
TS CAL, 1075
на пользователя, 61
на сервер, 60
на устройство, 61
сервера терминалов, 61
Локализация, 326
м
Мандат, 66
Манифест, 1037
Маркер
доступа, 553; 557 просмотр, 558
лицензии TS CAL, 1077
Маршрутизатор
поставщиков (MPR), 864
с дозвоном в Интернет по требованию, 1159 Маршрутизация, 1159
Маска доступа, 566; 722
Массив
Ftdisks, 108
RAID, 43
RAIDS, 745
дисков FT, 108
Мастер
аварийного восстановления системы, 1203 активации продуктов Windows, 53; 79 блокировки безопасности, 969 восстановления пароля, 596 делегирования управления, 718 добавления агента восстановления, 981 запроса сертификата, 979 импорта сертификатов, 986 интерфейсов с дозвоном по требованию, 1161
компонентов Windows, 142; 269
миграции компьютеров, 509
миграции учетных записей групп, 513 настройки репликации, 898 настройки сервера, 53; 76 настройки сервера маршрутизации и удаленного доступа, 1147
настройки факса, 922
обнаружения нового оборудования, 1137
обновления оборудования, 190
отправки факса, 926
перемещения файлов и параметров
(FSTW), 1038
подготовки удаленной установки, 140 расширения тома, 763 результирующего набора политик, 674 сброса пароля, 596
создания доверительного отношения, 637
создания новой зоны, 269
создания разделов, 759
создания тома, 762
удаленной установки Risetup, 143
установки клиентов, 132; 149
экспорта сертификатов, 978; 981
Метаданные
свойства, 372; 384
просмотр, 384
удаление, 523
Метка времени, 796; 807
Kerberos, 66
файлов, 65
Метод Диффи-Хеллмана, 996
Механизм отложенной записи, 837
Миграция
доменов, 505
настроек пользователя, 1038
паролей, 511
учетных записей
групп, 510
компьютеров, 509
пользователей и групп, 513
Мини-драйвер, 178
Модель OSI, 198
Модем
PC Card, 1140
конфигурация, 1094
настройка, 923
установка, 1136
Модернизация
до версии Windows Server 2003 R2,112
домена Windows NT 4.0,481
подготовка, 465
доменов ресурсов, 498
доменов учетных записей, 499
дочерних доменов, 504
корневых доменов Windows 2000,503
леса Windows 2000,500
основного контроллера домена, 494
резервных контроллеров домена, 496
схемы, 502
Монитор
порта, 910
языка, 910
Монитор ссылок безопасности (SRM), 163;
557; 712
Мост, 1175
настройка, 1176
связей сайтов, 399
н
Windows 2000
модернизация, 105
Набор политик, 447
Набор управления, 1225
Наследование
записей контроля доступа, 716
иерархия, 669
классов, 313
разрешений, 576
блокирование, 577
Номер
версии, 655
редакции, 655
Windows NT 4.0
модернизация, 104
Windows Server 2003,32
Datacenter Edition, 36
Enterprise Edition, 35
Standard Edition, 34
Web Edition, 36
автоматизированная установка, 115
активация, 79
загрузка, 84
лицензия, 60
сравнение версий, 33
О
установка, 48; 70
Windows Server 2003 R2,33
Обозреватель
главный
домена, 879
подсети, 878
потенциальный, 879
резервный, 878
Обработчик прерываний, 166
Образ
riprep, 139
RIS, 139
startrom.com, 131-
sysprep, 118
диска, 116
загрузочный, 135
локальный, 1037
разрешения, 146
Объект
Connection, 370; 411-
CrossRef, 458
Default-First-Site-Name, 400
Domain, 432 ■
Group, 436
Identity-Dictionary, 1150
RootDSE, 321
Site Link, 407
Subnet, 401
групповой политики (GPO), 449", 651
группы, 726
идентификация, 348
управляемый, 683
устаревший, 416
фантомный, 528; 735
физического устройства, 177
функционального устройства, 178
Операционная система
Организационная единица, 440
Оснастка
ADSIEdit, 36/
Certificates, 961; 1000; 1023
Device Manager, 171
DES Management, 901
DHCP Manager, 132
Event Viewer, 80
File Server Resource Manager, 844
Performance Logs and Alerts, 195
Removable Storage, 1205
Replication Management, 901
Schema, 355
Security Configuration and Analysis, 691
Storage Management for SANs, 773
System Information, 172
System Monitor, 195
Отметка на удаление, 391
Отношение доверия в Active Directory, 332
Отображение имен, 633
Отпечаток, 1019
Очередь печати, 930
управление, 930
Ошибка 0x0000007b, 95
п
Пакет, 554■
Act20,114
ActiveSync, 1066
deploy.cab, 117
DHCPINFORM, 1092; 1153
Interix, 569
IRP, 177■'
Kerberos, 554
MD5-CHAP, 1106
MSI, 702
создание, 702
MSV1_O,555
Negotiate, 556
NTLM, 556
PoPToP, 1178
Rdclip, 1067
Schannel, 556
Twclientmsi, 877
VMWare, 52
аутентификации, 554
развертывания программного обеспечения
(AAS), 701
системы безопасности, 555
установки Microsoft (MSI), 701
Память
NVRAM, 46
оперативная, 40
пользовательская, 154
управление, 155
ядра, 154; 195
Папка, 790; 796
Параметр RTT, 248
Пароль, 587
LanMan, 588
NTLM, 588
администратора, 64
восстановления Active Directory, 538
обратимый, 591; 1102
сброс, 595
сохранение, 594
учетной записи администратора, 122
уязвимые места, 588
Переменная языка OSCML, 138
Переменная среды
%systemroot%, 90
SAFEBOOT_OPTION, 1224
Перенаправитель, 861; 866
NetWare, 866
RDP, 867
WebDAV, 867; 948; 969
Windows, 866
Перенаправление
WINS, 284
буфера обмена, 1066
дисков, 1067
запросов DNS, 257
запросов WINS, 262
звуковых данных, 1069
каталогов, 1045
консоли, 1065
по условию, 258
портов, 1168
принтеров, 1067
устройств, 1066
Перенос зоны, 255
инкрементный, 240
на основе уведомлений, 240
частичный, 256
Период публикации, 1009
Печать, 902
в Windows Server 2003 R2,939
двунаправленная, 939
из DOS, 938
на локальном устройстве печати, 912
на сервере печати Windows, 914
на сервере печати от стороннего
производителя, 916
на сетевое устройство печати, 913
на хосте UNIX, 914
по сети Интернет, 918
Подача заявки, 1021
Подключение
автоматическое, 1162
к домену, 123
по запросу, 1158
Подпись, 1019
цифровая, 992
Подсистема
Executive, 162
12О,57
LDM, 42
РпР, 67; 1136
RIS, 129
SIS, 135
WDM, 177
Windows, 164
WOW, 155
WOW64,859
диспетчера сеансов, 58
хранения, 744
настройка, 49
Поиск
авторитетный, 245
ссылок, 828
Поле
восстановления данных (DRF), 950; 955
дешифровки данных (DDF), 949; 955
Политика, 425
Always Install With Elevated Privileges, 702
1723,11773263,3313389,1064; 1085389,331 '464,606749,628.80,96988,605; 628UDP123,3951701,11801812,11831813,11833268,331389,331,3394011,131464,339, 606; 62853,251749,628'88,339, 605; 628Поставщик, 861LPR, 910MUP, 864; 893NetWare, 862Web Client, 862Windows, 862Winsock, 862 аутентификации, 67 печати, 863; 908LanMan, 863Macintosh, 863NetWare, 863Интернет, 863локальный, 909сетевой, 910служб шифрования (CSP), 998смарт-карт, 998удаленного рабочего стола, 862шифрования Microsoft, 949Поток данныхименованный, 817Потребитель события, 738Правилодля содержимого, 348 синтаксическое, 346; 348 структурное, 346; 347схемы, 347Предпочтение, 695; 699просмотр, 699создание, 7001723,11773263,3313389,1064; 1085389,331 '464,606749,628.80,96988,605; 628UDP123,3951701,11801812,11831813,11833268,331389,331,3394011,131464,339, 606; 62853,251749,628'88,339, 605; 628Поставщик, 861LPR, 910MUP, 864; 893NetWare, 862Web Client, 862Windows, 862Winsock, 862 аутентификации, 67 печати, 863; 908LanMan, 863Macintosh, 863NetWare, 863Интернет, 863локальный, 909сетевой, 910служб шифрования (CSP), 998смарт-карт, 998удаленного рабочего стола, 862шифрования Microsoft, 949Поток данныхименованный, 817Потребитель события, 738Правилодля содержимого, 348 синтаксическое, 346; 348 структурное, 346; 347схемы, 347Предпочтение, 695; 699просмотр, 699создание, 700
1723,1177
3263,331
3389,1064; 1085
389,331 '
464,606
749,628.
80,969
88,605; 628
UDP
123,395
1701,1180
1812,1183
1813,1183
3268,331
389,331,339
4011,131
464,339, 606; 628
53,251
749,628
'88,339, 605; 628
Поставщик, 861
LPR, 910
MUP, 864; 893
NetWare, 862
Web Client, 862
Windows, 862
Winsock, 862 аутентификации, 67 печати, 863; 908
LanMan, 863
Macintosh, 863
NetWare, 863
Интернет, 863
локальный, 909
сетевой, 910
служб шифрования (CSP), 998
смарт-карт, 998
удаленного рабочего стола, 862
шифрования Microsoft, 949
Поток данных
именованный, 817
Потребитель события, 738
Правило
для содержимого, 348 синтаксическое, 346; 348 структурное, 346; 347
схемы, 347
Предпочтение, 695; 699
просмотр, 699
создание, 700
1723,1177
3263,331
3389,1064; 1085
389,331 '
464,606
749,628.
80,969
88,605; 628
UDP
123,395
1701,1180
1812,1183
1813,1183
3268,331
389,331,339
4011,131
464,339, 606; 628
53,251
749,628
'88,339, 605; 628
Поставщик, 861
LPR, 910
MUP, 864; 893
NetWare, 862
Web Client, 862
Windows, 862
Winsock, 862 аутентификации, 67 печати, 863; 908
LanMan, 863
Macintosh, 863
NetWare, 863
Интернет, 863
локальный, 909
сетевой, 910
служб шифрования (CSP), 998
смарт-карт, 998
удаленного рабочего стола, 862
шифрования Microsoft, 949
Поток данных
именованный, 817
Потребитель события, 738
Правило
для содержимого, 348 синтаксическое, 346; 348 структурное, 346; 347
схемы, 347
Предпочтение, 695; 699
просмотр, 699
создание, 700
Audit Account Management, 512
Automatic Certificate Request, 1180
Code Signing For Device Drivers, 905
Default Domain Controllers, 590
Disallow Installation of Printers Using
Kernel-Mode Drivers, 905
Encrypting File System Policies, 965
Maximum Password Age, 590
административных шаблонов, 693
безопасности, 584; 688
просмотр, 689
блокирование, 669
переопределение, 670
блокирования анонимной инвентаризации
ресурсов и имен учетных записей, 598
блокирования учетных записей, 590
групповая, 446; 650
Add Computer to a Domain, 66
Automatic Certificate Request Settings, 1023
Default Domain, 623
Encrypting File System, 975
Group Policy Domain Controller Selection, 680
Remote Installation, 147.
User Group Policy Loopback Processing
Mode, 677
восстановления зашифрованных файлов, 964
компоненты, 651
контейнер (GPC), 448; 652; 665
объект (GPO), 449; 651
перенаправления каталогов, 1045
редактор (GPE), 449, 652; 677
типы, 688
управления печатью, 933
шаблон (GPT), 449, 652; 663
для смены пароля, 590
защиты паролей, 589
иерархия,667
обновление, 689
обработка, 660
перенаправления каталогов, 706
распространения программного
обеспечения, 700
системная, 649
сценариев, 707
управляемая, 699
Порт, 911
TCP
135,409
П реобразование
адресов, 1166
имен DNS, 248
имен NetBIOS, 248
портов, 1167
Прерывание
аппаратное, 167
Привилегия, 558
системная, 579
просмотр, 581
Привод
IDE/ATA, 41
SCSI, 41
Провайдер, 683
поддержки безопасности NTLM, 554
Программа
Application Compatibility, 114
Backup Exec, 1190
cdrwin, 44; 854
CIM Studio, 684
DirectCD, 855
Dmadmin, 757
DNSLint, 240
Drive Fitness Test, 742
Drive Image Pro, 116
DrWatson, 164
Easy CD Creator, 854
ERD Commander, 43; 540; 595; 1229
Event Log Monitor, 393
EZ CD Creator, 44
FAZAM, 671
InstallShield Professional, 702
Internet Explorer, 552
lOphtcrack, 590
LanGuard, 598
LogCaster, 393
MetaFrame, 106; 1063
Nero CD Burner, 44; 854
Norton Ghost, 116
NT Access, 1229
OnTrack, 98
PCIScope, 167
PowerChute, 48
Quota and File Sentinel, 844
Quota Server, 843
Registry Defragmentation, 109
SpeedDisk, 823
StorageCentral SRM, 843
System Commander, 95
Tokenmaster, 558
True Image, 116
UPS support, 48
Windows Product Activation, 57
Windows XP/2000/NT Key, 1229
Wininstall 2000,702
Wise Installer, 702
антивирусная, 974
взлома паролей, 589
Просмотр, 878
Пространство имен, 316; 882
Active Directory, 322; 425
LDAP, 316
объектов, 831
Протокол
AFP, 591
APPN,912
АКАР, 591
СВСР, 1097
ССР, 1097
CHAP, 1101; 1104
CIFS, 205
СМС, 1022
СМР, 1022
^>№,308
DHCP, 130; 1092; 1152; 1153
H\SV,309
DLC, 858
DOP, 309
V1SP, 309
EAP, 1101; 1106
ESP, 1179
GRE, 1177
ICA, 1063
ICMP, 1169
IP, 200
IPCP, 1099
IPP, 912; 916
IPSec, 1179
IPv6,201
IPX, 1099
IPXCP, 1099
ISAKMP, 1180
Kerberos, 343; 555; 599
делегирование, 620
kpasswd, 628
L2TP, 1179
LCP, 1096
LDAP, 311
LPR, 914
MPPC, 1097
MPPE, 1098; 1178
MS-CHAP, 1101; 1105
MS-CHAPv2,478; 1101; 1105
NBFCP, 1099
NCP, 1096
NETBEUI, 203
NTLMv2,589, 600
OCSP, 1020
PAP, 1101
PPP, 1093; 1095
PPPoA, 1093
PPPoE, 1091; 1099, 1166
PPTP, 1090; 1177
RDP, 862; 867; 1036; 1062
RIP, 1153
KPC,374
SASL, 556
SecurelCA, 1074
SMB, 203; 205; 912
SMTP, 375; 433
SPAP, 1101; 1103
TCP, 201’
Telnet, 626
TFTP, 132
UDP, 201
WebDAV, 948; 969
WEP, 1091
WS-Management, 190
Профиль удаленного доступа, 1109
Процедура POST, 84
Процесс VMM, 154'
Процессор
Itanium, 155
Itanium 2,40
McKinley, 155
Xeon, 39'
добавление, 182
Публикация
интервал, 1009
период, 1009
Пул
выгружаемый, 158
невыгружаемый, 158
носителей, 1205
принтеров, 935
Путь ARC, 89, 91
OEM, 45; 780
аппаратный, 55
данных Microsoft, 45
загрузочный, 59; 755
основной, 758
программный, 55
расширенный, 758
системный, 59; 755
EFI, 45
форматирование, 72
создание, 71
Разрешение, 558
кумулятивное, 573
наследование, 576
Разрешения для образов, 146
Распознаватель, 247
DNS, 242
Расширение на стороне клиента (CSE), 652;
657’
Appmgmt, 704
Регистрация, 80
анонимная, 598•
Редактор групповых политик (ОРЕ), 449
Реестр, 157
Режим безопасный, 1224
Резервное копирование, 106; 1192
в файл, 1202
дифференцированное, 1193
интерактивное, 1208
каталога, 534
неуправляемое, 1206
файлов состояния системы, 1202
Результирующий набор политик, 671
Репликация'
Active Directory, 303; 370
атрибутов ссылок, 298
вектор обновления, 388
внутрисайтовая, 372
интервал, 407
кольцо, 376
конфликт, 390
межсайтовая, 372; 407
принудительная, 408
свойств, 372
срочная, 373
Р
сценариев, 707
топология, 375
Рабочая группа, 65.
Раздел, 789
ESP, 45■
MSR, 45; 781
транзакция, 384 файлов, 336 частота, 373
Ресурс
административный, 867
общий, 867
Netlogon, 336
отказоустойчивый, 336
Ретранслятор запросов DHCP/BOOTP, 132
Роль
Domain Naming Master, 458
Infrastructure Master, 457; 528
PDC Emulator, 454
RID Master, 350; 456
Schema Master, 458
Schema Operations Master, 357
назначение, 531
передача, 527
настройка, 144
RRAS, 1158
Samba, 592
без локальной консоли, 148
глобального каталога, 331
список, 490
коммутируемого доступа, 1112 лицензий, 63
лицензирования, 1076
печати, 903
настройка, 931
преобразования имен, 244
кэширующий, 244
проверяющий, 602; 604
развертывания, 701
распространения ключей, 602
С
связующий, 379 выбор, 404
Сайт, 338; 372
архитектура, 396 объекты, 382
- создание, 400
Сборка, 1037
параллельная, 1036; 1037 Сборка мусора, 263; 391 Связь, 882
реплицированная, 883
Сеанс
нулевой, 478; 598; 1120
удаленного рабочего стола, 1063
Сектор, 790
динамическая замена, 804
загрузочный, 85; 790
Сервер, 857
DHCP, 1153
DNS, 244; 492
авторитетный, 245 вторичный, 276 выход из строя, 520 кэширующий, 278 переадресующий, 257 подчиненный, 258 установка, 268
DSA, 308
IAS, 1109; 1185
LANRover, 1104
H)KV,339
LTS, 830
NTP, 396
RADIUS, 1186
RIS, 132
замена, 532
терминалов, 1070
удаленного доступа (RAS), 1120
Сертификат, 961; 992; 996; 1000
Computer, 1180
Enrollment, 1126
Enrollment Agent, 1127
VVX.963
VKCS,958
Smartcard Logon, 1126
Smartcard User, 1126
X.509,961; 1106
восстановления файлов, 979
импорт, 983
отзыв, 1007
открытого ключа восстановления файлов, 978
подача заявки на получение, 1021 привилегий доступа (РАС), 435; 609, 712 проверка целостности, 1018 расширение, 1000 самоподписанный, 959 серийный номер, 1019
шаблон, 1005
экспорт, 981
Сетевой адаптер
настройка, 50
скрытый, 188
установка, 187
Сеть
выделенная, 1093
с коммутацией каналов, 1093
с коммутацией пакетов, 1093
с коммутацией ячеек, 1093
Сжатие файлов, 823; 846
Синхронизация, 66; 1058
Система с двойной загрузкой, 51 .
Система безопасности LSA, 553
Системный реестр, 152
очистка, 108
предельный размер, 300
Сканер системных файлов (SFC), 842
Служба
ACL Editor, 576
Active Directory, 297
Alerter, 1219
BINL, 131; 658
BITS, 858
Browser, 863
Citrix ICA MetaFrame, 1063
Dfsclient, 336
DFSR, 900
DHCP, 290
установка, 291
DHCP Client, 262
DNS, 239, 426
зона-заглушка, 240
отключение, 281
DRA, 371
Dynamic DNS, 280
EMS, 148
Error Reporting, 1216
• ERSvc, 164; 1216
Fast Switching, 1055
Fax, 920
. FRS, 336; 375; 433; 888
FTP, 626
IAS, 1109, 1183
ICS, 1157
IMAP, 627
kdc, 628
KMS, 1006; 1026
LanMan Server, 863
LDM, 52
LFS, 837
License Manager, 62
Lmrepl, 479; 707
Logical Disk Server, 757
LSA, 553; 591
компоненты, 554
LSASS, 436; 557
LTS, 828
Microsoft Metadirectory Services, 35
Microsoft RPC Runtime, 409
Mount Manager, 55
Netlogon, 554
Network Bridge, 1175
Network Monitor, 250
Niks, 337
Protected Storage, 554; 967
PXE, 130
Registration Authority, 1006
Remote Desktop, 1055; 1062
Restore System, 974
RIS, 129
RPC Endpoint Mapper, 409
RPC Locator, 409
RRAS, 1113; 1134; 1145
RSM, 186; 742; 1190; 1204
Server, 867
Session Directory, 1063
SharePoint, 943
SIS Groveler, 135
SLS, 736
SUS, 152; 181
System Restore, 1199
TSL, 1076
User Manager, 469
Userenv, 674
VDS, 878
VS, 1198
W32Time, 66
WFP, 840
Windows Installer, 701
Windows Time, 394
Windows Update, 179
Winlogon, 67; 616
WTS, 394
аварийного управления (EMS), 1221
защиты файлов Windows (WFP), 840
каталогов, 297; 305
атрибуты, 312
классы, 312
наследование классов, 313
схема, 345
отслеживания ссылок (LTS), 827
регистрации ошибок, 164
репликации файлов (FRS), 336; 449
спулера, 907
теневого копирования тома, 876; 1198
терминалов, 1062
файла журнала (LFS), 837
Смарт-карта, 1106; 1122
SecurlD, 1123
форматы, 1123
Совместимость
аппаратных средств, 38
приложений, 114
Создание
загрузочного диска РХЕ, 141
мостов связей сайтов, 405
образов, 140
подсетей IP, 401
раздела, 184
сайта, 400
связей сайтов, 402
Сокет, 200, 862
Состояние системы, 1202
Спецификация
АРМ, 174
NDIS, 187; 861
Список
OSC, 132
контроля доступа (ACL), 336; 557
отозванных сертификатов (CRL), 1007
перекрестных доверительных отношений
(CLT), 1014
просмотра, 878
совместимых аппаратных средств, 38
управляемый, 894
Спулер, 907
Среда выполнения
дозагрузочная, 46
Средство проверки согласованности знаний, 375
Ссылка, 882
источник, 828
клиент, 828
обратная, 457
прямая, 457
символическая, 831
циклическая, 835
Стандарт
802.1х, 1091
АРМ, 54
ASMA,351
DNSSec, 265
DSS, 994
El Torito, 53
ISO 9660,44
TA20J063
X.500,308
X.509,961
Стек, 859
Страница памяти, 154
Страница-разделитель, 937
Сфера, 603
Схема, 345
модернизация, 502
правила, 347
расширение для R2,352
Сценарий
Mdmgen.inf, 1137
Migapp.inf, 1039
Migsys.inf, 1040
Miguser.inf, 1040
RIS, 137
SIF, 137
Sysfiles.inf, 1041
winntsif, 111
автоматизированной установки, 119; 124
утилиты riprep, 141
т
Таблица
GPT, 742
MET, 800
векторов обновления, 388
знаний о разделах (РКТ), 887
маршрутизации IRQ, 167
разделов, 90, 751
разделов (РКТ), 882
разделов GUID, 44
Технология
ccNUMA, 153
DMA, 169
Hyperthreading, 34
\9>№Л,312
NAT, 1166
РАЕ, 162
PnP, 48
S.M.A.R.T., 184
Тип данных, 908
Том, 744
RAID 5, 745; 759
замена диска, 771
создание, 766
SFM, 817
дублированный, 745
зеркалированный, 745; 759
замена диска, 774
создание, 764
простой, 759
с чередованием, 744; 759
создание, 764
создание, 762
составной, 744; 759
создание, 763
теневое копирование, 876
удаление, 767
Топология, 370
внутрисайтовая, 376
межсайтовая, 378
репликации, 375
Точка
восстановления, 1199
контрольная, 837
распространения списка отозванных
сертификатов (СРВ), 1008
функционального монтирования, 136; 788;
831
Транзакция
X.500,309
атомарная, 384
аутентификации
по протоколу CHAP, 1104
по протоколу РРР, 1114
по смарт-карте, 1106
по протоколу РРТР, 1178
репликации, 384
Трансляция
портов (РАТ), 1167
сетевых адресов (NAT), 1166
Туннелирование, 1177
ADMT, 335; 464; 513 adprep, 502; 901
apcompat, 114
apmstat, 174
attrib, 192 auditpol, 643 autochk, 87; 803; 834
Baseline Security Analyzer, 179
Boot Manager Maintenance, 86 bootcfg, 86; 91; 1221
Cachemov, 105 7 cacls, 571; 1051
Certmgr, 1033
certutil, 1006; 1031; 1032
change, 1068; 1081
chkdsk, 800; 834
chown, 569; 1052 cipher, 983 cmdkey, 593
compact, 847
convert, 108; 756; 826
cvsde, 366
dcdiag, 363
dcpromo, 336; 484; 517
defrag, 852
dfscmd, 896; 900
dfsutil, 887; 899
Disk Cleanup, 850
Disk Probe, 94
У
Diskeeper, 823
Diskpart, 754; 758; 761; 769; 782
Управление памятью, 155 в архитектуре IA32,154
Уровень
данных, 199
представления данных, 201
прикладной, 201
сеансовый, 201
сетевой, 200
Установка
DNS-сервера, 268
автоматизированная, 115
диска SCSI, 183
компонентов, 127
на сервер без локальной консоли
средствами RIS, 149
по сценарию, 119
сетевого адаптера, 187
устройств, 179
Утилита addiag, 705
Diskpart.efi, 184 dmdiag, 747 dnscmd, 248; 278; 290 DNSLint, 240 dsacls, 571; 721 dsadd, 363 dsastat, 534 dsget, 363 dsmod, 363 dsmove, 363 dsquery, 363 dsrm, 363 dsstore, 1032 dumpchk, 1219 Dumpel, 413 dwwin, 164 efsinfo, 956
ERD Commander, 64 esent, 353 esentutil, 545
Event Viewer, 80
Fax Monitor, 929
fdisk, 98
Fdisk.efi, 185
Format.efi, 185
fsutil, 136; 786; 812; 848; 849
Ftdisk, 744
ftonline, 43; 743
gpotool, 656; 674
gpresult, 582; 673 gpupdate, 643; 650; 654
grovctrl, 136
hfhetchk, 179
ipconfig, 248
ipv6,201
kadmin, 631; 638
kdb5_util, 627
kdestroy, 629
kerbtray, 344; 618
kinit, 628
klist, 618; 636
krb5,636
LDAP Browser, 361
Idifde, 365
tip, 492
License Manager, 60
linkd, 848; 849
Loadstate, 1043
lsadump2,630
mountvol, 45; 780
msinfo32,172
ncadmin, 129
net, 395; 907
netdiag, 188
netdom, 64; 592
Netsh, 1155
Network Shell, 1156
nltest, 592
nslookup, 287
Ntbackup, 535; 536; 1190; 1213
Ntdetect, 86; 194
ntdetect.chk, 194
ntdsutil, 417; 503; 523; 529; 545
Nvrboot.efi, 46; 185
oformat, 826
oidgen, 351
Pagedefrag, 823
Printer Migration, 943
PrintMig, 943
pwdump3e, 589
qchain, 182
Rasadmin, 1145
Rasdial, 1157
RBFG, 130; 141
Regclean, 109
rendom, 517
repadmin, 380-, 384; 408; 413
Replication Monitor, 492
Replmon, 413; 416; 490; 656
riprep, 139
risetup, 147
rmtshare, 875; 1051
Rpings, 409
Rpings32,409
RSDIR, 136
Rsm, 1204
runas, 1108
Runll32,9/5
Scanstate, 1043
schupgr, 503
Search, 879
Secedit, 689; 692
setspn, 632
Setup Manager, 103; 120
setupmgr, 120
sfc, 842
shadow, 1083
showacls, 571
showprivs, 583
Signcode, 1033
Sonar, 891
Stsadm, 944
subinacl, 569; 570", 5 71
sysocmgr, 127
sysprep, 117
System Information, 95; 172
systeminfo, 96; 340
tscon, 1075; 1082
Upromote, 470
whoami, 396; 581
win32tm, 395
Windbg, 1219
Windows Debugger, 1219
winmsd, 95
winnt32,110
winobj, 831
xcacls, 571
Участник системы безопасности, 350; 602;
603; 712
Учетная запись
Administrator, 959
Anonymous Logon, 598
krbtgt, 604
Dsa.msc, 354
LocalService, 735
Dssec.dat, 720
LocalSystem, 735; 1120
Dssite.msc, 354
Remote Assistant, 1071
dsup.inf, 115
службы, 735
dsuptinf, 115
Dumpfsmos.cmd, 453
Ф
edb.chk, 353
edb.log,353
>айл, 790
eventvwr.exe, 80
$LogFile, 837
eventvwr.msc, 80
.kSstash, 627
Exchcsp.dll, 999
Adminpak.msi, 476
Fastfat.sys, 793
adsieditmsc, 358
fde.dll, 706
Asr.sif, 1203; 1204
Fdeploy.ini, 665; 706
Asrpnp.sif, 1204
fpswa.efi, 46; 779
Asyncmac.sys, 1094
Fxsadmin.msc, 922
biosinfo.inf, 175
Fxsclnt.exe, 928
boot.ini, 85; 88; 92; 765; 774; 1221
Fxscover.exe, 928
В oot0004,47
Fxsmntr.exe, 929
Bootsectdat, 1229
Fxssend.exe, 926
Bootsect.dos, 51; 85
Fxssvc.exe, 920
bootvid.dll, 87
Gp.chm, 700
cache.dns, 247
Gpeditmsc, 580; 681
chooseou.osc, 138
Gpt.ini, 656; 663
Clnmgr.exe, 850
GptTempl.inf, 665
cmdlines.txt, 127
GptTmpl.inf, 689
Common.adm, 696
grovctrl.ex_, 136
Compmgmt.msc, 1174
hdlscoml.com, 149
Conf.adm, 695
hdlscom2.com, 149
config.pol, 336; 479; 650; 696
YLosts,244;467
Connect.asp, 1073
Ia641dr.efi,46; 779
Cpl.cfg, 62
las.msc, 1184
Credentials, 593
Inetcorp.adm, 696
Davclnt.dll, 862
Inetpp.dll, 910
Dcpromo.log, 488
Inetres.adm, 695; 699
Dcpromoui.log, 488
Inetset.adm, 696
dcup.inf, 115
install.osc, 138
dcup5.inf, 115
io.sys, 85
defirst.inf, 115
Ipnathplt.dll, 1171
defltdc.inf, 115
Kadm5.acl, 627
defltsv.inf, 115
Kadm5.keytab, 627
deploy.cab, 120
krb5.keytab, 630
deploy.chm, 125
Krb5kdc.conf, 628
devmgmt.msc, 167; 171; 1137
ldp.exe, 361
Dfrg.msc, 821
LlsmapJls, 62
Dfrgfat.exe, 821
Llsuser.lls, 62
Dfrgntfe.exe, 821
Lmhosts, 467
DfsguLmsc, 896
Localspldll, 908
Diskmgmtmsc, 757
Mdmgen.inf, 1137
dnsadddp.exe, 239
Mdminstdll, 1137
Domain.msc, 354
Memory .dmp, 1217
Migapp.inf, 1038
riprep.sif, 141
migrate.inf, 109
rkb5.conf, 629
Migration.inf, 1044
root hints, 247
Migsys.inf, 1040
Rrasmgmt.msc, 1145
Miguser.inf, 1040
schema.ini, 354
Mobsync.exe, 1058
schupgr.exe, 365
ModemDet.txt, 1144
Script.ini, 708
Mrxdav.sys, 867
Seceditexe, 693
mrxsmb.sys, 201; 866
Secevent.evt, 640
msgina.dll, 67
Seclogon.dll, 736
msinfo32.exe, 95
Serenum.sys, 1136
msoobe.exe, 79
Services.exe, 861
MsRcIncident, 1086
setupact.log, 94
Msrdp.inf, 1064
setuperr.log, 95
Msrdp.ocx, 1064
Setupldr.bin, 53; 58
Mstsc.exe, 1063
setuplog.txt, 94; 97
Mstsmmc.msc, 1064
Setupreg.hiv, 58
Ndis.sys, 199, 861
smss.exe, 87
Ndiswan.sys, 1094
Spoolsv.exe, 907
netbt.sys, 203
Srv.sys, 867
netlogon.dnb, 263
srvwiz.dll, 76
netlogon.dns, 427
ssms.exe, 58
Netrasa.inf, 1094
startrom.com, 131; 135; 149
ntbootdd.sys, 86; 93
startrom.nl2,135
Ntbtlog.txt, 95; 1224
Sysfiles.inf, 1041
Ntconfig.pol, 336; 479; 650; 696
Sysprint.sep, 937
ntdetect.chk, 194
Sysprtj.sep, 937
ntds.dit, 323; 331; 353
System.adm, 695
Ntlanman.dll, 862
System.alt, 1226
ntoskrnl.exe, 86
temp.edb, 353
ntvdrn.exe, 155
TLSLic.edb, 1076
Nwprovau.dll, 910
Txtsetup.inf, 55
Nwrdr.sys, 866
Txtsetup.sif, 53; 97; 107; 175
Nwwks.dll, 862
Ufat.dll, 834
pagefile.sys, 82; 87
unattend.txt, 123
Pcl.sep, 937
Untfs.dll, 834
principal.db, 627
Vgaoem.fon, 58
Pscript.sep, 937
Vssvc.exe, 1199
qprocess.exe, 1082
^Na!b.exe,926
quappsrv.exe, 1082
win32k.sys, 164
quser.exe, 1082
Win32spl.dll, 5У0
qwinsta.exe, 1082
winbom.inf, 118
Rasadmin.exe, 1145
Windows.amd, 696
Rasdial.exe, 1157
Winlogon.log, 689
Rdpdr.sys, 867
Winnt.adm, 696
Rdpnp.dll, 862
winnt.sif, 110
Registry.pol, 652; 664; 665; 694; 697
Winspooldrv, 907
repair.txt, 548
Wmplayer.adm, 695
resl.log, 353
wow64.dll, 156
riprep.inf, 140
wow64cpu.dll, 157
riprepJog, 140
wow64exts.dll, 157
wow64win.dll, 157
.sys, 861
wowexe.exe, 155
.vbs, 708
Ws_32.dll, 862
сжатие, 823
Xenroll.dll, 1023
сжатый, 972
автономный, 973; 1053
символов, 1219
восстановление, 1212
спулера, 907; 973
временный, 973
теневой, 907
дешифровка, 950
шаблона групповой политики, 652; 689
заблокированный, 1198
шифрование, 949
закрепленный, 1056
Файл зоны, 241
зашифрованный, 971
Файловая система, 785
защита, 840
FAT, 793
командный, 708
FAT32.43; 794
непрерывный, 795
ISO9660/Joliet, 854
образа, 135
NT, 785
пакетной обработки, 708
NTFS, 42; 799
пакетный, 124
атрибуты, 806
подкачки, 973
версии, 42; 786
подкачки страниц, 82; 87
записи, 800
полностью скрытый, 89
RSS, 785
разреженный, 136; 825
UDF, 856
с расширением
UDFl.5,44
.aas, 664; 703
перенаправление, 157
.adm, 976
распределенная (Dfc), 881
.adm, 695
корень, 883
•bkf, 538
связи, 884
.cmd, 1052
шифрованная, 947
.dns, 244; 264
Факс, 922
.dom, 689
Федерация, 298
.efi, 70; 779
лесов, 334
.gpd, 906
Формат
.ia64,171
EMF, 904
.inf, 689
GPT, 779
.Idf, 365
LDIF.364
.Ink, 829
Форматирование системного раздела, 72
.local, 1037
Фрагментация, 796
.manifest, 1038
каталогов, 821
.msc, 354
Функциональный уровень, 464; 471
.osc, 133 .ped, 906
.pes, 512 .pf, 787
смена, 491
Функция KeBugCheckEx, 1216
.pfx, 1031
X
.pnf, 1137
.pol, 697
.ppd, 906
Хеш, 587; 994
Хозяин
.pwl, 588 .pws, 596 .rdp, 1064
именования доменов, 458 инфраструктуры, 457 операции, 453
.shd, 907; 911
относительных идентификаторов, 456
.sm, 1197
схемы, 458
.spl, 907; 911
Хранилище единственных копий, 135
ц
Центр
распространения ключей (KDC), 604
регистрации (RA), 1006; 1026
сертификации
изолированный (Standalone СА), 1004
корневой, 1004
масштаба предприятия (Enterprise С А), 1004
подчиненный, 1013
сертификации (С А), 1003
установка, 1017
Цепочка доверия, 1013
Цепочка кластеров, 795
ш
Шаблон
ADM, 695
создание, 700
Inetres.adm, 699
безопасности, 690
распространение, 692
специальный, 690
групповой политики (GPT), 449
сертификата, 1005
Шина, 177
PCI, 168
Шифрование
каталогов, 983
метод
блочный, 993
потоковый, 993
отключение, 975
потока данных, 1074
файла, 949
автономного, 973
на портативных компьютерах, 983
на сервере, 967
Шлюз, 1164
э
Экземпляр, 315; 346
Эмулятор WOW64,156; 904
Эмулятор терминала, 1221
Эффект острова, 520
Я
Ядро, 86
ntoskrnl, 87
Standard PC, 54
инициализация, 87
Язык
OSCML, 137
VBScript, 708
Ярлык, 829
2. Перейдите на вкладку Network Identification (Сетевая идентификация).
3. Щелкните на кнопке Properties (Свойства). Откроется окно Identification Changes (Смена идентификации).
4. Щелкните на кнопке More (Дополнительно).
5. В открывшемся окне DNS Suffix and NetBIOS Computer Name (DNS-суффикс и имя NetBIOS) введите имя домена DNS. Установите флажок Change Primary DNS Suffix when Domain Membership Changes (Изменять суффикс первичного DNS-сервера при смене домена). Это обеспечит совпадение домена DNS и домена Active Directory.
6. Щелкните на кнопке ОК для сохранения внесенных изменений.
1. Активизируйте групповую политику Network Access: Let Everyone Permissions Apply To Anonymous Users (Доступ по сети: применять права доступа Everyone к анонимным пользователям) в политике Default Domain Controller в конечном домене. Эта политика хранится в контейнере Computer ConfigurationMWindows Settings^ Security SettingsMLocal PoliciesMSecurity Options (Конфигурация компьютерам Конфигурация WindowsMnapaMeTpbi безопасностиМ Локальные политикиМПараметры безопасности).
3. Создайте ключ миграции паролей и сохраните его на гибком диске, использовав утилиту командной строки ADMT и команду admt key <имя_исходного_домена> <Диск> <пароль>. Если нежелательно вводить пароль открытым текстом на экране, введите вместо пароля символ “*”, и будет выдан запрос на ввод пароля. Файл ключа будет иметь расширение . pes.
4. Перенесите гибкий диск с паролем на контроллер исходного домена вместе с установочным компакт-диском Windows Server 2003, на котором установлена утилита миграции паролей.
5. На исходном контроллере домена вставьте гибкий диск в привод и запустите утилиту миграции паролей с установочного компакт-диска Windows Server 2003. Утилита хранится в каталоге \Valueadd\Msft\Mgmt\Admt\Pwmig.
2. Щелкните правой кнопкой мыши на объекте Security Log (Журнал безопасности) и выберите из контекстного меню команду Properties (Свойства). Откроется окно Properties (Свойства).
3. Измените значение в поле Maximum Log Size (Максимальный размер журнала). Задайте достаточно большой размер журнала, чтобы обеспечить хранение информации о событиях за несколько дней.
4. В группе Event Log Wrapping (По достижении максимального размера журнала) выберите вариант действий при переполнении журнала. Выберите переключатель Do Not Over- write Events (He затирать события). Можно установить системную политику, которая за-
2. Активизируйте вкладку Recovery Agents (Агенты восстановления) в окне Properties (Свойства), как показано на рис. 18.24.
3. Выберите переключатель Archive The Key (Архивировать ключ).
4. В поле Key Recovery Agents (Агенты восстановления ключей) щелкните на кнопке Add (Добавить). Откроется окно Key Recovery Agent Selection (Выбор агента восстановления ключа). В окне будет присутствовать учетная запись, которой был выдан сертификат Key Recovery Agent.
5. Щелкните на кнопке ОК для загрузки агента в список. Возле пиктограммы агента отображается красный символ X, а состояние указывается, как Not Loaded (Не загружен).
6. Щелкните на кнопке ОК, чтобы запустить процедуру восстановления ключей. Будет выдан запрос на останов и перезапуск службы центра сертификации. Сделайте это.
7. После перезапуска службы убедитесь, что состояние агента изменилось на Va 1 id (Активен).
2. Выберите из списка Smartcard User (Пользователи со смарт-картой) и щелкните на кнопке ОК
3. Проделайте такую же процедуру для шаблона Smartcard Logon (Вход со смарт-картой), если планируется развертывание только возможностей, связанных с регистрацией по смарт-карте.,
2. Выполните двойной щелчок на той дате, когда необходимо выполнить резервное копирование. При этом запустится Мастер резервного копирования (Backup Wizard). (В этом случае для настройки задания необходимо использование мастера.)
3. Щелкните на кнопке Next (Далее). Откроется окно Items to Back Up (Элементы для резервного копирования). Выберите диски, которые будут включены в задание резервного копирования. Не забудьте в качестве одного из параметров выбрать System State (Состояние системы).
4. Щелкните на кнопке Next (Далее). Откроется окно Backup Type, Destination, and Name (Тип, расположение и имя архива). Выберите ленточный привод и имя ленты, которая будет использоваться этим заданием.
5. Щелкните на кнопке Next (Далее). Откроется окно Type of Backup (Тип архива). Выберите обычную резервную копию. Эту процедуру можно использовать для создания дифференцированной или добавочной резервной копии в дополнение к обычной резервной копии.
6. Щелкните на кнопке Next (Далее). Откроется окно How to Back Up (Способ резервного копирования). Установите флажок Verify Data After Backup (Проверять данные после архивации) и флажок Use Hardware Compression (Использовать аппаратное сжатие).
7. Щелкните на кнопке Next (Далее). Откроется окно Backup Options (Параметры резервного копирования). Для обычных резервных копий по умолчанию выбран переключатель