- •Тема 1. ЦЕЛИ И ЗАДАЧИ СЕТЕВОГО АДМИНИСТРИРОВАНИЯ
- •Контрольные вопросы
- •Тема 2. ВВЕДЕНИЕ В WINDOWS SERVER
- •2.1. Семейства Microsoft Windows 2000 Server и Windows Server 2003-2008
- •2.2. Характеристики Windows 2000 и Windows Server 2003-2008
- •2.3. Контроллеры домена и рядовые серверы
- •2.3.1. Роли серверов
- •2.4. Архитектура операционной системы
- •2.4.1.1. Внешние подсистемы (подсистемы среды)
- •2.4.1.2. Интегральные (внутренние) подсистемы
- •2.4.2.1. Исполнительная система Windows Server
- •2.4.2.2. Драйверы устройств
- •2.4.2.3. Микроядро
- •2.4.2.4. Аппаратно-зависимый уровень
- •Контрольные вопросы
- •Тема 3. СЛУЖБА КАТАЛОГОВ WINDOWS SERVER
- •3.1. Знакомство со службой каталогов
- •3.2. Рабочие группы и домены
- •3.3. Служба каталогов Active Directory
- •3.3.2.1. Логическая структура
- •3.3.2.2. Физическая структура
- •Контрольные вопросы
- •4.2. Установка и начальная настройка системы
- •4.2.2. Выбор носителя дистрибутива системы
- •4.2.3. Процесс установки системы Windows Server 2003
- •Контрольные вопросы
- •Тема 5. ФАЙЛОВЫЕ СИСТЕМЫ MS WINDOWS SERVER
- •5.1. Обслуживание жестких дисков
- •5.1.1.1. Типы дисков, разделов и томов
- •5.1.1.2. Файловые системы
- •5.1.2. Основные задачи обслуживания дисков
- •5.1.2.1. Работа с простыми томами
- •5.1.2.2. Работа с составными томами
- •5.1.2.3. Работа с чередующимися томами
- •5.1.2.4. Добавление нового диска
- •5.1.2.5. Изменение типа диска
- •5.2. Файловая система FAT
- •5.2.1. Файловая система FAT16
- •5.2.2. Файловая система FAT32
- •5.2.2.1. Структура разделов FAT32
- •5.3. Файловая система NTFS
- •5.3.1. Введение в NTFS
- •5.3.2. Структура NTFS
- •5.3.2.1. Структура тома NTFS
- •5.4. Безопасность файловых систем
- •5.5. Дополнительные файловые системы
- •5.5.1. Распределенная файловая система
- •5.5.1.1. Общие сведения о DFS
- •5.5.1.2. Преимущества DFS
- •5.5.1.3. Ограничения, накладываемые DFS
- •5.5.1.4. Типы корней DFS
- •5.5.1.5. Конфигурирование томов DFS
- •5.5.2. Служба репликации файлов
- •5.5.2.1. Репликация посредством FRS
- •5.5.2.2. Уникальные порядковые номера
- •Контрольные вопросы
- •Тема 6. СЛУЖБА КАТАЛОГОВ ACTIVE DIRECTORY
- •6.1. Обзор Active Directory
- •6.1.1. Введение в Active Directory
- •6.1.1.1. Концепция Active Directory
- •DC=ru/DC=bupk/CN=Users/CN=Ivan Petrov
- •Значение
- •Представляет
- •6.1.2.1. Модель данных
- •6.1.2.2. Схема
- •6.1.2.3. Модель безопасности
- •6.1.2.4. Модель администрирования
- •6.1.2.5. Доступ к Active Directory
- •6.1.2.6. Архитектура службы каталогов
- •6.2. Планирование внедрения Active Directory
- •6.2.1. Планирование пространства имен
- •6.2.1.1. Внутреннее и внешнее пространства имен
- •Преимущества
- •Недостатки
- •Сценарий 2. Внутреннее и внешнее пространства имен различаются
- •Преимущества
- •Недостатки
- •6.2.1.2. Выбор архитектуры пространства имен
- •6.2.2.1. Создание структуры ОП
- •6.2.2.2. Рекомендации по разработке структуры ОП
- •6.2.2.3. Структура иерархии ОП
- •6.2.3. Планирование сайта
- •6.2.3.1. Оптимизация регистрационного трафика
- •6.2.3.2. Оптимизация репликации каталога
- •6.3. Внедрение Active Directory
- •6.4.1. Создание первого контроллера нового домена
- •6.4.2.1. База данных Active Directory
- •6.4.2.2. Общий системный том
- •6.4.3.1. Смешанный режим
- •6.4.3.2. Основной режим
- •6.5. Администрирование Active Directory
- •6.5.1. Создание подразделений и объектов в них
- •6.5.1.1. Создание организационных подразделений (ОП)
- •6.5.1.2. Добавление объектов в ОП
- •6.5.2. Управление объектами Active Directory
- •6.5.2.1. Поиск объектов
- •6.5.2.3. Перемещение объектов
- •6.5.3. Управление доступом к объектам Active Directory
- •6.5.3.1. Управление разрешениями Active Directory
- •6.5.3.2. Наследование разрешений
- •6.5.3.3. Делегирование полномочий по управлению объектами
- •Контрольные вопросы
- •Тема 7. АДМИНИСТРИРОВАНИЕ MS WINDOWS SERVER
- •7.1. Использование Microsoft Management Console (MMC)
- •7.1.1.1. Консоли ММС
- •7.1.2.1. Изолированная оснастка
- •7.1.2.2. Расширение оснастки
- •7.1.3.1. Авторский режим
- •7.1.3.2. Пользовательский режим
- •7.2. Администрирование учетных записей пользователей
- •7.2.2. Планирование новых учетных записей пользователей
- •7.2.2.1. Правила именования
- •7.2.2.2. Требования к паролю
- •7.2.2.3. Параметры учетных записей
- •7.2.4.1. Диалоговое окно свойств
- •7.2.5.1. Профиль пользователя
- •7.2.5.2. Изменение учетных записей пользователей
- •7.2.5.3. Создание домашней папки
- •7.3. Администрирование учетных записей групп
- •7.3.2.1. Типы групп
- •7.3.2.2. Область действия группы
- •7.3.2.3. Участники групп
- •7.3.2.4. Вложенность групп
- •7.3.2.5. Стратегии групп
- •7.3.3. Внедрение групп
- •7.3.3.1. Администрирование групп
- •7.3.4. Внедрение локальных групп
- •7.3.4.1. Создание локальных групп
- •Описание
- •7.3.5. Встроенные группы
- •7.3.5.1. Встроенные глобальные группы
- •7.3.5.2. Встроенная локальная группа домена
- •7.3.5.3. Встроенные локальные группы
- •7.3.5.4. Встроенные системные группы
- •7.4. Администрирование групповой политики
- •7.4.1. Введение в групповые политики
- •7.4.2. Преимущества групповой политики
- •7.4.2.1. Типы групповых политик
- •7.4.2.2. Структура групповой политики
- •7.4.2.3. Применение групповой политики
- •Контрольные вопросы
- •Тема 8. СИСТЕМА БЕЗОПАСНОСТИ WINDOWS
- •8.1. Инфраструктура открытого ключа
- •8.1.2.1. Шифрование с применением открытых ключей
- •8.1.2.2. Секретные ключи
- •8.1.3.1. Иерархия ЦС
- •8.1.4.1. Архитектура служб сертификации
- •8.1.4.2. Обработка запроса сертификата
- •8.1.4.3. Сертификаты ЦС
- •8.1.4.4. Установка служб сертификации
- •8.1.4.5. Администрирование служб сертификации
- •8.2. Технологии открытого ключа
- •8.2.1. Защищенные каналы
- •8.2.2. Смарт-карты
- •8.2.2.1. Вход в систему с помощью смарт-карты
- •8.2.3. Технология Authenticode
- •8.2.4. Шифрованная файловая система
- •8.2.4.1. Защита данных
- •8.2.4.2. Восстановление данных
- •8.2.4.4. Отказоустойчивость
- •8.2.4.5. Шифрование в EFS
- •8.2.4.6. Расшифровка в EFS
- •8.2.4.7. Восстановление EFS
- •8.2.4.8. Утилита командной строки cipher (шифр)
- •8.2.5.1. Политики IPSec
- •8.2.5.2. Компоненты IPSec
- •8.2.5.3. Пример связи по IPSec
- •8.3. Протокол Kerberos в Windows Server
- •8.3.1. Обзор протокола Kerberos
- •8.3.1.1. Термины протокола Kerberos
- •8.3.1.2. Возможности протокола Kerberos
- •8.3.1.3. Процесс аутентификации с помощью Kerberos
- •8.3.1.4. Делегирование в Kerberos
- •8.3.2.1. Локальный интерактивный вход в систему
- •8.3.2.2. Интерактивный вход в домен
- •8.3.2.3. Поддержка открытого ключа в Kerberos
- •8.4. Средства конфигурации системы безопасности
- •8.4.1.1. Настройка системы безопасности
- •8.4.1.2. Анализ безопасности
- •8.4.3. Оснастка Group Policy (Групповая политика)
- •8.5. Аудит в Microsoft Windows
- •8.5.1. Обзор аудита в Windows
- •8.5.1.1. Использование политики аудита
- •8.5.3.1. Настройка аудита
- •8.5.3.2. Настройка политики аудита
- •8.5.3.3. Аудит доступа к файлам и папкам
- •8.5.3.4. Аудит доступа к объектам Active Directory
- •8.5.3.5. Аудит доступа к принтерам
- •8.5.4.1. Журналы в Windows
- •8.5.4.2. Управление журналами аудита
- •8.5.4.3. Архивация журналов
- •Контрольные вопросы
- •Тема 9. СЕТЕВЫЕ СЛУЖБЫ И ПРОТОКОЛЫ
- •9.1. Основы функционирования протокола TCP/IP
- •9.1.3.1. Разбиение сетей на подсети с помощью маски подсети
- •9.2. Сетевые протоколы
- •9.2.1. Протокол ATM
- •9.2.1.1. LAN Emulation
- •9.2.1.2. IP поверх ATM
- •9.2.1.3. ATM поверх xDSL
- •9.3. Сетевые службы
- •9.3.1. Служба DNS
- •9.3.1.1. Служба DNS: пространство имен, домены
- •9.3.1.2. Служба DNS: домены и зоны
- •9.3.1.3. Зоны прямого и обратного просмотра
- •9.3.1.4. Алгоритмы работы итеративных и рекурсивных запросов DNS
- •9.3.2.1. Введение в DHCP
- •9.3.2.2. Аренда DHCP
- •9.3.3. Служба WINS
- •9.3.3.1. Процесс преобразования имен службой WINS
- •9.3.3.2. Регистрация имени
- •Контрольные вопросы
- •Тема 10. СЛУЖБА РЕЗЕРВНОГО КОПИРОВАНИЯ
- •10.1. Базовые понятия службы резервного копирования
- •10.1.1. Типы резервного копирования
- •10.2. Разработка и реализация стратегии резервного копирования
- •10.2.1. Понятие плана архивации
- •10.2.2. Выбор архивных устройств и носителей
- •10.2.3. Типовые решения архивации
- •10.2.4. Пример создания задания на выполнения архивации данных
- •10.2.5. Пример восстановления данных из резервной копии
- •10.2.6. Теневые копии
- •10.2.7. Использование теневых копий
- •10.3. Архивирование и восстановление состояния системы
- •10.3.1. Архивирование и восстановление состояния системы
- •10.3.2. Автоматическое аварийное восстановление системы
- •10.3.2.2. Восстановление системы с помощью ASR-копии
- •Контрольные вопросы
134
Недостатки
Регистрационные имена отличаются от имен электронной почты. Например, если кто-нибудь входит под именем username@bupk.ru, то адрес его электронной почты будет username@universitet.ru, что неудобно.
В DNS Интернета придется зарегистрировать больше имен.
6.2.1.2. Выбор архитектуры пространства имен
Выбрав модель взаимодействия внутреннего и внешнего пространств имен, надо учесть и другие факторы, например, объем трафика репликации и потенциальные изменения структуры предприятия.
Архитектура пространства имен должна отражать структуру предприятия и одновременно обеспечивать степень административной детализации, необходимую для эффективного управления корпоративной и глобальной сетью посредством Active Directory .
Соблюсти эти условия позволяет наличие трех уровней доменов:
•корневой домен;
•домен первого уровня;
•домен второго уровня.
Корневой домен
Это первый домен пространства имен, например
universitet.ru. Корневой домен (root domain) в Active Directory
определяет пространство имен компании. Все внутренние домены являются частью этого домена, создавая непрерывное связное пространство имен в виде дерева доменов. Кроме того, серверы, содержащие корень пространства, скрыты за брандмауэром и, следовательно, не будут видимы из Интернета.
Домены первого уровня
Этот уровень модели отвечает за создание доменных имен, которые не изменяются даже при внутренней реорганизации предприятия.
135
Доверительные отношения между корневым доменом и всеми доменами первого уровня делают ресурсы доступными для всех ветвей дерева доменов. Следовательно, пользователь одного домена первого уровня может получить доступ к ресурсу в другом домене этого уровня.
Доменные имена этого уровня должны состоять минимум из трех букв, чтобы не противоречить стандарту ISO 3166.
Домены второго уровня
В идеале должны содержать только коды стран и ответвления от доменов первого уровня. Преимущество этого подхода: ниже доменов второго уровня можно создавать дочерние домены.
6.2.2.Планирование организационных подразделений (ОП)
ОП должны отражать подробности структуры организации. Создание ОП позволяет делегировать полномочия по администрированию небольших групп пользователей, групп и ресурсов. Вы вправе предоставить полный административный контроль (регистрация пользователей, изменение паролей, управление политикой ведения учетных записей и т. п.) или ограниченный (например, только обслуживание очереди печати).
ОП устраняют необходимость предоставлять пользователям административный доступ на уровне домена для выполнения таких задач как, например, создание учетных записей и установка паролей. Теперь можно предоставить пользователям административные полномочия на уровне ОП и тем самым освободить от этого администраторов доменов.
ОП добавляет новый уровень защиты путем ограничения видимости общедоступных ресурсов (благодаря ACL) — пользователь видит лишь объекты, к которым имеет доступ.
ОП наследует политику безопасности от родительского домена и ОП.
6.2.2.1. Создание структуры ОП
Целесообразно начинать с разработки структуры ОП для первого домена в пространстве имен. Используйте этот домен и структуру ОП как модель для добавляемых в будущем доменов.
136
Кроме того, созданная структура должна допускать возможные реорганизации с минимальным перемещением объектов.
6.2.2.2. Рекомендации по разработке структуры ОП
Создавайте ОП для делегирования административных полномочий.
Структура ОП должна быть логичной и осмысленной — это поможет администраторам ОП наиболее эффективно выполнять свои задачи.
Создавайте ОП для внедрения политики безопасности. Создавайте ОП, чтобы ограничить видимость опублико-
ванных ресурсов для определенных пользователей.
Структуры ОП должны быть относительно статичными. Кроме того, ОП придают гибкость пространству имен, помогая приспособиться к изменяющимся потребностям предприятия.
Не размещайте в ОП слишком много дочерних объектов. Приступив к разработке структуры ОП, старайтесь строго
придерживаться выбранных правил именования ОП и объектов: имена должны быть иерархичны, статичны и готовы к применению в любом домене предприятия.
Не размещайте в ОП слишком много дочерних объектов — это замедлит поиск и выполнение навигационных запросов.
Один из способов создания структуры ОП первого домена – присвоить имя организационным подразделениям верхнего уровня, которые станут заголовками, определяющим более подробные ОП и отнесенные к ним объекты. Альтернативный способ — начать с определения естественной иерархии объектов. Создав иерархические группы объектов, эти группы можно будет положить в основу организационных подразделений верхнего уровня.
Если в сети несколько доменов, структура ОП должна быть применима к каждому из них.
6.2.2.3. Структура иерархии ОП
Очень важно определить иерархию ОП. Структура доменов многих предприятий отражает характер их деятельности.
137
Объектно-ориентированная модель деления на ОП
Active Directory разрешает создавать ОП на основе таких объектов, как пользователи, компьютеры, приложения, группы, принтеры, политика безопасности и другие. Правильно разработанная объектно-ориентированная модель ОП заметно облегчает жизнь администраторам подразделений. Обычно это наилучший вариант организации ОП — он обеспечивает минимальное число будущих изменений.
Географическая модель деления на ОП
Можно формировать подразделения, отражающие задачи бизнеса по географическим областям. Скорее всего, такая структура будет стабильна во времени. Если предвидятся серьезные изменения в организационной структуре предприятия, нужно выбрать другой принцип разграничения ОП.
Модель деления на ОП по выполняемым задачам
ОП можно создавать на основе различных задач, выполняемых сотрудниками организации, например маркетинг, автоматизация и т.п. Эти задачи, вероятно, останутся даже в случае изменений состава и характеристик выполняющих их отделов.
Модель деления на ОП по отделам
Еще один способ — создать подразделения, отражающие текущую структуру предприятия. Однако структура предприятия нестабильна, так как при реорганизации будет меняться состав отделов или варьироваться возложенные на них задачи.
Модель деления на ОП по проектам
Деятельность некоторых предприятий подчинена выполнению конкретных проектов, например, в области разработки программ, авиапромышленности и т.п. Можно отразить это и в структуре ОП, однако так делать не рекомендуется, поскольку проекты тоже нестабильны.
6.2.3. Планирование сайта
Успешное внедрение сети Windows Server на базе Active Directory во многом зависит от физической структуры, которая разграничивается сайтами.
Зачастую сайт имеет те же границы, что и ЛВС или ГВС
сеть.
138
Механизм репликации Active Directory позволяет поразному выполнять репликацию в ЛВС и медленной глобальной сети. Сетевой трафик внутри сайта обычно активнее трафика между сайтами. Настройка сайтов отражается на работе Windows Server в двух ключевых моментах:
1. Вход в сеть. При входе пользователя в сеть Active Directory совместимые клиенты пытаются найти контроллер домена на сайте компьютера пользователя, чтобы обслужить запрос регистрации в системе и последующие запросы сетевой информации.
2. Репликация каталога. Расписание и маршрут репликации каталога домена могут быть сконфигурированы для внутри и межсайтовой репликации по отдельности. Обычно система настраивается так, чтобы межсайтовая репликация осуществлялась реже, чем внутрисайтовая.
В Active Directory сайты не являются частью пространства имен. Структура сайта содержится в отдельной части каталога. Сайты содержат лишь объекты компьютеров и подключений, нужные для конфигурирования межсайтовой репликации.
Правильно спланированные сайты не перегружают сетевые каналы связи трафиком репликации, информация в Active Directory актуальна, и пользователи всегда обращаются к ближайшим ресурсам.
Группируя подсети в сайты, надо учитывать скорость связи между подсетями. Следует объединять только те подсети, которые располагают быстрыми, недорогими и надежными сетевыми соединениями. Под быстрыми здесь понимаются сетевые соединения со свободной пропускной способностью не менее 512 кб/с, которая может быть выделена для трафика репликации. Более емкие соединения разумно рассматривать только для отдельного сайта. Конфигурировать сайты необходимо так, чтобы репликация выполнялась в периоды минимальной нагрузки на сеть.
Структуры домена и сайта хранятся в Active Directory раздельно.