Модель по месту положения. Основные имена пользователей

Данная статья посвящена основам операционной системы . Здесь мы рассмотрим:

  • Отличие от предыдущих версий;
  • Редакции данной ОС;
  • Установка Windows Server 2003;
  • Роли сервера;
  • Основы Active Directory;
  • Функции командной строки;
  • Настройка удаленного рабочего стола;
  • Настройка DHCP сервера.

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

  • Active Directory - расширяемая и масштабируемая служба каталогов, в которой используется пространство имен, основанное на стандартной Интернет-службе именования доменов (Domain Name System, DNS );
  • InteiUMirror - среда конфигурирования, поддерживающие зеркальное отображение пользовательских данных и параметров среды, а также центральное администрирование установки и обслуживания программного обеспечения;
  • Terminal Services - службы терминалов, обеспечивающие удаленный вход в систему и управление другими системами Windows Server 2003;
  • Windows Script Host - сервер сценариев Windows для автоматизации таких распространенных задач администрирования, как создание учетных записей пользователей и отчетов по журналам событий.

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

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

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

Помимо обширного списка новых возможностей, Windows Server 2003 интересна еще и потому, что предлагается в 32-разрядном, 64-разрядном и встроенном (embedded ) вариантах. Тем не менее, наиболее важные отличия касаются четырех редакций ОС, которые перечислены ниже в порядке функциональности и, соответственно, цены:

  • Windows Server 2003 Web Edition;
  • Windows Server 2003 Standard Edition;
  • Windows Server 2003 Enterprise Edition;
  • Windows Server 2003 Datacenter Edition.

Редакция Web Edition

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

Windows Server 2003 Web Edition поддерживает 2 Гб ОЗУ и двухпроцессорную симметричную обработку (symmetric multiprocessor, SMP ). Эта редакция поддерживает неограниченное количество анонимных Web-соединений, но только 10 входящих соединений блока серверных сообщений (server message block, SMB ), и этого более чем достаточно для публикации содержимого. Такой сервер не может выступать в роли интернет-шлюза, DHCP- или факс-сервера. Несмотря на возможность удаленного управления сервером с помощью ПО Remote Desktop, он не может играть роль сервера терминалов в традиционном понимании: он может принадлежать домену, но не может быть его контроллером.

Редакция Standard Edition

Данная редакция - надежный, многофункциональный сервер, предоставляющий службы каталогов, файлов, печати, приложений, мультимедийные и Web-службы для небольших и средних предприятий. Обширный (по сравнению с Windows 2000 ) набор функций дополнен рядом компонентов: MSDE (Microsoft SQL Server Database Engine ) - версией сервера SQL Server, поддерживающего пять параллельных соединений к БД размером до 2 Гб; бесплатной преднастроенной службой РОРЗ (Post Office Protocol v3 ), которая совместно со службой SMTP (Simple Mail Transfer Protocol ) позволяет узлу играть роль небольшого автономного почтового сервера; полезным инструментом NLB (Network Load Balancing ), который присутствовал только в Windows 2000 Advanced Server.

Редакция Standard Edition поддерживает до 4 Гб ОЗУ и четырехпроцессорную SMP-обработку.

Редакция Enterprise Edition

Windows Server 2003 Enterprise Edition нацелена стать мощной серверной платформой для средних и крупных предприятий. К ее корпоративным функциям относятся поддержка восьми процессоров, 32 Гб ОЗУ, восьмиузловая кластеризация включая кластеризацию на основе сетей хранения данных (Storage Area Network, SAN ) и территориально распределенную кластеризацию, плюс совместимость с 64-разрядными компьютерами на базе Intel Itanium, что позволяет поддерживать уже 64 Гб ОЗУ и восьмипроцессорную SMP-обработку.
Ниже перечислены другие отличия Enterprise Edition от Standard Edition:

  • Поддержка служб MMS (Microsoft Metadirectory Services ), позволяющих объединять каталоги, БД и файлы со службой каталогов Active Directory;
  • «Горячее » добавление памяти (Hot Add Memory ) - вы можете добавлять память в поддерживаемые аппаратные системы без выключения или перезагрузки;
  • Диспетчер системных ресурсов Windows (Windows System Resource Manager, WSRM ), поддерживающий распределение ресурсов процессора и памяти между отдельными приложениями.

Редакция Datacenter Edition

Редакция Datacenter Edition доступна только в качестве OEM-версии, предлагаемой в комплекте с серверами класса high-end, и поддерживает практически неограниченную масштабируемость: для 32-разрядных платформ - 32-процессорная SMP-обработка и 64 Гб ОЗУ, для 64-разрядных - 64-процессорная SMP-обработка и 512 Гб ОЗУ. Существует также версия, поддерживающая 128-процессорную SMP-обработку на базе двух 64-процессорных секций.

64-разрядные редакции

По сравнению с 32-разрядными, 64-разрядные редакции Windows Server 2003, работающие на компьютерах Intel Itanium, эффективнее используют скорость процессора и быстрее выполняют операции с плавающей точкой. Улучшения в коде и обработке существенно ускорили вычислительные операции. Возросшая скорость доступа к огромному адресному пространству памяти позволяет улучшить работу сложных, требовательных к ресурсам приложений, например приложений для работы с большими БД, научно-исследовательских приложений и подверженных высоким нагрузкам Web-серверов.

Однако некоторые функции в 64-разрядных редакциях недоступны. Например, 64-разрядные редакции не поддерживают 16-разрядные Windows-приложения, приложения реального режима, приложения POSIX и службы печати для клиентов Apple Macintosh.

Установка и настройка Windows Server 2003

При установке Windows Server2003 система конфигурируется согласно ее роли в сети. Серверы обычно становятся частью рабочей группы или домена.

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

  • Установка с загрузочного компакт-диска. Windows Server 2003 продолжает традицию установки с компакт-диска. Однако есть и нововведение: установка с дискет больше не поддерживается;
  • Улучшенный графический пользовательский интерфейс во время установки. Во время установки Windows Server 2003 использует графический пользовательский интерфейс (GUI ), похожий на интерфейс Windows XP. Он более точно описывает текущее состояние установки и время, оставшееся до ее завершения;
  • Активация продукта. Розничная и пробная версии Windows Server 2003 требуют активации. Такие массовые программы лицензирования, как Open License, Select License или Enterprise Agreement не требуют активации.

После установки и активации Windows можно настроить сервер, используя хорошо продуманную страницу Управление данным сервером (Manage Your Server ), которая автоматически открывается при входе в систему. Эта страница упрощает установку некоторых служб, инструментов и конфигураций в зависимости от роли сервера. Щелкните кнопку Добавить или удалить роль (Add Or Remove A Role ), появится окно Мастера настройки сервера (Configure Your Server Wizard ).
Если установить переключатель Типовая настройка для первого сервера (Typical Configuration For A First Server ), мастер сделает сервер контроллером нового домена, установит службы Active Directory и при необходимости службы DNS (Domain Name Service ), DHCP (Dynamic Host Configuration Protocol ) и RRAS (Routing And Remote Access ).

Если установить переключатель Особая конфигурация (Custom Configuration ), мастер может настроить следующие роли.

  • Файловый сервер (File Server ). Обеспечивает централизованный доступ к файлам и каталогам для пользователей, отделов и организации в целом. Выбор этого варианта позволяет управлять пользовательским дисковым пространством путем включения и настройки средств управления дисковыми квотами и ускорить поиск в файловой системе за счет активизации Службы индексирования (Indexing Service ).
  • Сервер печати (Print Server ). Обеспечивает централизованное управление печатающими устройствами, предоставляя клиентским компьютерам доступ к общим принтерам и их драйверам. Если выбрать этот вариант, запустится Мастер установки принтеров (Add Printer ), позволяющий установить принтеры и соответствующие драйверы. Кроме того, мастер устанавливает службы IIS 6.0 (Internet Information Services ), настраивает протокол печати IPP (Internet Printing Protocol ) и Web-средства управления принтерами;
  • Application Server IIS, ASP.NET (Сервер приложений IIS, ASP.NET ). Предоставляет компоненты инфраструктуры, которые требуются для поддержки размещения Web-приложений. Эта роль устанавливает и настраивает IIS 6.0, ASP.NET и СОМ+;
  • Mail Server РОРЗ, SMTP (почтовый сервер РОРЗ, SMTP ). Устанавливает РОРЗ и SMTP, чтобы сервер мог выступать в роли почтового сервера для клиентов РОРЗ;
  • Сервер терминалов (Terminal Server ). Позволяет множеству пользователей с помощью клиентского ПО Службы терминалов (Terminal Services ) или Дистанционное управление рабочим столом (Remote Desktop ) подключаться к приложениям и ресурсам сервера, например принтерам или дисковому пространству, как если бы эти ресурсы были установлены на их компьютерах. В отличие от Windows 2000, Windows Server 2003 предоставляет Дистанционное управление рабочим столом автоматически. Роли сервера терминалов требуются, только когда нужно размещать приложения для пользователей на сервере терминалов;
  • Сервер удаленного доступа или VPN-сервер (Remote Access/VPN Server ). Обеспечивает маршрутизацию по нескольким протоколам и службы удаленного доступа для коммутируемых, локальных (LAN) и глобальных (WAN) вычислительных сетей. Виртуальная частная сеть (virtual private network, VPN ) обеспечивает безопасное соединение пользователя с удаленными узлами через стандартные Интернет-соединения;
  • Контроллер домена Active Directory (Domain Controller Active Directory ). Предоставляет службы каталогов клиентам сети. Этот вариант позволяет создать контроллер нового или существующего домена и установить DNS. Если выбрать эту роль, запускается Мастер установки Active Directory (Active Directory Installation Wizard );
  • DNS Server (DNS-сервер ). Обеспечивает разрешение имен узлов: DNS-имена преобразуются в IP-адреса (прямой поиск ) и обратно (обратный поиск ). Если выбрать этот вариант, устанавливается служба DNS и запускается Мастер настройки DNS- сервера (Configure A DNS Server Wizard );
  • DHCP-сервер (DHCP Server ). Предоставляет службы автоматического выделения IP-адресов клиентам, настроенным на динамическое получение IP-адресов. Если вы¬брать этот вариант, устанавливаются службы DHCP и запускается Мастер создания области (New Scope Wizard ), позволяющий определить один или несколько диапазонов IP-адресов в сети;
  • Сервер потоков мультимедиа (Streaming Media Server ). Предоставляет службы WMS (Windows Media Services ), которые позволяют серверу передавать потоки мультимедийных данных через Интернет. Содержимое может храниться и предоставляться по запросу или в реальном времени. Если выбрать этот вариант, устанавливается сервер WMS;
  • WINS-сервер (WINS Server ). Обеспечивает разрешение имен компьютеров путем преобразования имен NetBIOS в IP-адреса. Устанавливать службу WINS (Windows Internet Name Service ) не требуется, если вы не поддерживаете старые ОС, например Windows 95 или NT. Такие ОС, как Windows 2000 и XP не требуют WINS, хотя старым приложениям, работающим на этих платформах, может понадобиться разрешать имена NetBIOS. Если выбрать этот вариант, устанавливается сервер WINS.

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

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

Windows Server 2003 не различает основные и резервные контроллеры домена, так как поддерживает модель репликации с несколькими хозяевами. В этой модели любой контроллер домена может обрабатывать изменения каталога и затем автоматически реплицирует их на другие контроллеры домема. В модели репликации с одним хозяином в Windows NT все происходит не так: основной контроллер домена хранит главную копию каталога, а резервные - ее копии. Кроме того, Windows NT распространяет только БД диспетчера учетных записей безопасности (security access manager, SAM ), a Windows Server 2003 - весь каталог информации, называемый хранилищем данных (datastore ). В нем есть наборы объектов, представляющие учетные записи пользователей, групп и компьютеров, а также общие ресурсы, например серверы, файлы и принтеры.

Домены, в которых применяются службы Active Directory, называют доменами Active Directory, чтобы отличать их от доменов Windows NT. Хотя Active Directory работает только с одним контроллером домена, в домене можно и нужно создать дополнительные контроллеры. Если ОДИН контроллер выходит из строя, для выполнения аутентификации и других важных задач можно задействовать другие.

В домене Active Directory любой рядовой сервер разрешается повысить до уровня контроллера домена без переустановки ОС, как того требовала Windows NT. Для превращения рядового сервера в контроллер следует лишь установить на него компонент Active Directory. Возможно и обратное действие: понижение контроллера домена до рядового сервера, если он не является последним контроллером домена в сети. Вот как повысить или понизить уровень сервера посредством мастера установки Active Directory.

Функции командной строки

В Windows Server 2003 масса утилит командной строки. Многие из них используют протокол TCP/IP, поэтому его следует предварительно установить.
Как администратору, Вам следует знать следующие утилиты командной строки.

  • ARP - отображает и управляет программно-аппаратной привязкой адресов, используемой Windows Server 2003 для отправки данных по сети TCP/IP;
  • FTP - запускает встроенный FTP-клиент;
  • HOSTNAME - отображает имя локального компьютера;
  • IPCONFIG - отображает свойства TCP/IP для сетевых адаптеров, установленных в системе. Также используется для обновления и освобождения выданных службой DHCP адресов;
  • NBTSTAT - отображает статистику и текущее соединение для протокола NetBIOS поверх TCP/IP;
  • NET - отображает список подкоманд команды NET;
  • NETSH - отображает и управляет сетевой конфигурацией локального и удаленных компьютеров;
  • NETSTAT - отображает текущие TCP/Ip соединения и статистику протокола;
  • NSLOOKUP - проверяет статус узла или IP-адреса при использовании с DNS;
  • PATHPING - проверяет сетевые пути и отображает информацию о потерянных пакетах;
  • PING - тестирует соединение с удаленным узлом;
  • ROUTE - управляет таблицами маршрутизации в системе;
  • TRACERT - во время цитирован и я определяет сетевой путь к удаленному узлу.

Чтобы научиться применять эти средства, наберите имя команды в командной строке без параметров: в большинстве случаев Windows Server 2003 выведет справку по ее использованию.

Использование команды NET

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

  • NET SEND - отправляет сообщения пользователям, зарегистрированным в указанной системе;
  • NET START - запускает службу в системе;
  • NET STOP - останавливает службу в системе;
  • NET TIME - отображает текущее системное время или синхронизирует системное время с другим компьютером;
  • NET USE - подключает и отключает от общего ресурса;
  • NET VIEW - выводит список доступных сетевых ресурсов.

Чтобы научиться использовать команду NЕТ, введите NET HELP и имя подкоманды, например NET HELP SEND. Windows Server 2003 выведет необходимые справочные сведения

Создание соединения удаленного рабочего стола

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

  1. Щелкните Пуск (Start ), затем Программы (Programs ) или Все программы (All Programs ), затем Стандартные (Accessories ), затем Связь (Communications ), затем Подключение к удаленному рабочему столу (Remote Desktop Connection). Откроется одноименное диалоговое окно;
  2. В поле Компьютер (Computer ) введите имя компьютера, с которым хотите установить соединение. Если вы не знаете имени, воспользуйтесь предлагаемым раскрывающимся списком или укажите в списке вариант Поиск других (Browse For More), чтобы открыть список доменом и компьютеров в этих доменах;
  3. По умолчанию Windows Server 2003 берет для регистрации на удаленном текущее имя пользователя, домен и пароль. Если нужна информация другой учетной записи, щелкните Параметры (Options) и зашагайте поля. Имя пользователя (User Name ), Пароль (Password ) и Домен (Domain );
  4. Щелкните Подключиться (Connect ). При необходимости ведите пароль и щелкните ОК. Если соединение создано успешно, вы увидите окно удаленного рабочего стола выбранного компьютера и получите возможность работать с ресурсами этого компьютера. Если соединение создать не удалось, проверьте введенную вами информацию и повторите попытку

С командой Подключение к удаленному рабочему столу (Remote Desktop Connection ) работать просто, но она неудобна, если вам приходится создавать удаленные соединения с компьютерами достаточно часто. Вместо нее рекомендуется обращаться к консоли Удаленные рабочие столы (Remote Desktops ). В ней можно настраивать соединения с несколькими системами и затем легко переключаться с одного соединения на другое.

Знакомство с DHCP

DHCP - средство централизованного управления выделением IP-адресов, но этим его функции не ограничиваются. DHCP-сервер выдает клиентам основную информацию, необходимую для работы сети TCP/IP: IP-адрес, маску подсети, сведения о шлюзе по умолчанию, о первичных и вторичных DNS- и WINS - серверах, а также имя домена DNS.

Клиент DHCP и IP-адрес

Компьютер с динамическим IP-адресом называют клиентом DHCP. При загрузке компьютера DHCP-клиент запрашивает IP-адрес из пула адресов, выделенных данному DHCP-серверу, и использует адрес определенное время, называемое сроком аренды (lease ). Спустя примерно половину этого срока клиент пытается возобновить аренду и повторяет эти попытки до успешного возобновления или до окончания срока аренды. Если возобновить аренду не удастся, клиент обращается к другому DHCP-серверу. Если клиент успешно связался с сервером, но его текущий IP-адрес не может быть возобновлен, DHCP-сервер присваивает клиенту новый IP-адрес.

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

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

Установка сервера DHCP

Динамическое выделение IP-адресов возможно только при наличии в сети DHCP-сервера. Компоненты DHCP устанавливаются при помощи мастера установки компонентов Windows, а запуск и авторизация сервера осуществляются из консоли DHCP Предоставлять клиентам динамические IP-адреса вправе только авторизованные серверы DHCP.

Установка компонентов DHCP

Чтобы сервер с Microsoft Windows Server 2003 мог работать в качестве DHCP-сервера, выполните следующие действия.

  1. В меню Пуск (Start ) выберите Программы (Programs ) или Все программы (All Programs ), затем щелкните Администрирование (Administrative Tools ) и Мастер настройки сервера.
  2. Дважды щелкните Далее (Next ). Появятся текущие роли сервера. Выделите роль DHCP - сервер и дважды щелкните Далее. Мастер установит DHCP и запустит Мастер создания области;
  3. Если вы хотите сразу же создать начальную область для DHCP-сервера, щелкните Далее (Next ) и выполните действия, вписанные в разделе «Управление областями DHCP ». В противном случае щелкните Отмена (Cancel ) и создайте необходимые области позднее.
  4. Щелкните Готово (Finish ). Чтобы использовать сервер, Вы должны авторизовать его в домене, как описало в разделе Авторизация сервера DHCP в Active Directory. Далее Вам необходимо создать и активизировать все необходимые области DHCP.

После установки DHCP-сервера настройка и управление динамической IP-адресацией осуществляется из консоли DHCP. Команда для ее запуска располагается в меню Администрирование (Administrative Tools ). В главном окне консоли DHCP две панели. Слева перечислены все DHCP-серверы домена, по IP-адресам, включая локальный компьютер, если окно открыто на DHCP-сервере. Справа приведены подробные сведения о выбранном объекте.

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

Желаю удачи в освоение данной ОС.

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

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

Внедрение и интеграция

В данной главе мы рассмотрим новые возможности Active Directory с нескольких точек зрения: внедрения этой службы, ее интеграции с другими каталогами, перехода с предыдущей версии (либо обновление с Windows NT 4.0, либо просто установка Active Directory с нуля). Прежде всего, необходимо отметить, что новые возможности Active Directory на базе Windows 2003 по большей части не совместимы с Active Directory на базе Windows 2000. Например, возможности переименовать домен или восстановить ранее деактивированный объект в схеме могут быть использованы только тогда, когда каталог находится на максимально возможном функциональном уровне: уровень домена - Windows Server 2003 и уровень леса - Windows Server 2003. Чтобы получить доступ к этим и другим возможностям, следует перевести лес на максимально функциональный уровень. Рассмотрим, что собой представляют эти самые функциональные уровни.

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


Администратор вручную повышает функциональный уровень

Замечу, что такая классификация была специально введена для обеспечения совместимости на уровне обратно-несовместимых возможностей. Даже если установить Active Directory с нуля, не выполняя никаких обновлений и не заботясь об интеграции, то есть просто установить новый сервер, а на него - первый контроллер в лесе, то получится система, которая изначально попадает на самый низкий уровень. Другими словами, уровень домена - Windows 2000 Mixed (смешанный) и уровень леса - Windows 2000. Таким образом, в этом режиме установленная система полностью соответствует всем тем возможностям, которые есть в Windows 2000 Active Directory. Чтобы перейти на более высокий уровень, необходимо выполнение определенных условий, например, домен может быть переведен на уровень Windows Server 2003 только после того, как все контроллеры этого домена будут переведены на эту операционную систему. Если говорить о переходе с Windows 2000, то, естественно, процесс перехода заключается в поэтапном обновлении существующих контроллеров. Невозможно все контроллеры разом перевести с Windows 2000 на Windows 2003, это можно делать только по очереди. Пока процесс перевода контроллеров не завершен, функциональный уровень домена остается на уровне Windows 2000 Mixed. Как только будут переведены все контролеры, можно перейти на следующий уровень. Администратор переключает функциональный уровень с помощью специальной консоли Active Directory Domains Trusts. Администратор не в состоянии понизить уровень, он может только перевести его на более высокую ступень, на котором система останется. После того, как администратор перевел домен на новый функциональный уровень, в Active Directory появляются определенные новые возможности.

Рассмотрим эти возможности для простоты изложения в режиме чистый лес - Windows 2003 и все домены - Windows 2003. Другими словами, максимально возможные уровни и, соответственно, максимальный спектр новых возможностей. Первое, на чем стоит остановиться - это функция, которая называется Application Partitions (по-русски - Разделы Приложений).


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


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

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

Следующей возможностью является поддержка класса объектов InetOrgPerson (RFC 2798). Она появилась только в Windows 2003, а Windows 2000 этот класс объектов не поддерживает. InetOrgPerson нужен для интеграции с другими LDAP-каталогами (Novell, Netscape). Active Directory умеет работать с этим классом, создавать объекты этого класса, возможна также прозрачная и плавная миграция объектов типа InetOrgPerson из других каталогов Active Directory. Соответственно, становится возможным перенос приложений, написанных для других LDAP-каталогов. Если приложения используют данный класс, то их можно безболезненно, прозрачно портировать на Active Directory, сохраняя всю функциональность.

Далее, появилась возможность переименования доменов. В данном случае, следует четко понимать, что под переименованием домена имеется в виду не просто смена названия домена (назывался раньше домен "abcd", а теперь называется "xyz"). На самом деле, структура каталога является деревом, в нем много доменов, а сами домены объединены в иерархию. Переименование домена, это, на самом деле, реструктуризация леса. Можно переименовать домен таким образом, что он окажется в другом дереве.



Переименование домена. Утилита rendom.exe


Рассмотрим домен Contoso, подчиненный домену Sales в дереве WorldWideImporters.com. Его можно переименовать и назвать Contoso.Fabrikam.com. Это не просто переименование, это перенесение домена из одного дерева в другое, то есть достаточно нетривиальная процедура. Логично предположить, что переименование домена может привести к созданию нового дерева. Можно переименовать домен Contoso, который был подчинен домену Sales, и назвать его Contoso.com. Тогда домен станет родоначальником другого дерева в этом же лесе. Именно поэтому процесс переименования домена можно считать весьма сложной и нетривиальной процедурой.

В Windows 2000 такой возможности, как переименовать домен в приведенном выше контексте, не было в принципе. Если домен создан, то на всю жизнь он останется со своим именем. Единственный способ изменить ситуацию - это удалить домен, а потом создать его заново с новым именем.

Вместе с Windows 2003 поставляется утилита, которая называется Rendom, буквально от слов Rename Domain. Утилита Rendom.exe - это утилита командной строки, которая может использоваться для переименования домена. Правда, этот процесс состоит из шести этапов. Подробную информацию о нем можно отыскать в службе справки Windows 2003, специальных технических документах для Microsoft .NET, на сайте MSDN. Там подробно описано, как моделировать, проектировать и проводить процесс переименования домена, с использованием утилиты rendom. В любом случае, это сложный, многоэтапный процесс, требующий тщательной подготовки: слишком много связок и указателей, имен и прочих взаимозависимостей, которые формируются при создании доменов. Просто взять и одним махом все это перенести - невозможно.

В плане внедрения Active Directory появился режим установки контроллера домена со съемного носителя. Что имеется в виду? Очень часто встречается ситуация, когда предприятие внедряет Active Directory в удаленных офисах: связь с удаленным офисом слабая, плохие линии связи между головными офисами и филиалами. Тем не менее нужно в филиале установить новый контроллер доменов. Когда создается новый контроллер в уже существующем домене, утилита DCPromo связывается с существующими, работающими контроллерами и перекачивает себе всю базу данных и реплики, которые можно собрать с контроллера её домена. Если эта база занимает несколько десятков или сотен килобайт, то есть пустая (она по-умолчанию занимает несколько сот килобайт), то проблем нет. Но если говорить о работающей системе, в которой база может занимать десятки или сотни мегабайт, то её перекачка может оказаться просто невыполнимой задачей. Поэтому в этой ситуации можно решить проблему очень простым способом. С помощью Windows NT Back-up сделать архив в режиме "system state", то есть выбрать в консоли Windows NT Back-up опцию Back-up->SystemState. После этого весь созданный Back-up записать на носитель, например, на CD или DVD, взять этот диск и приехать с ним в удаленный офис, там восстановить всю информацию из архива с помощью той же самой Windows NT Back-up. Только нужно сделать восстановление не по умолчанию, а в другой каталог, чтобы сами файлы были просто выложены на диск. Естественно, не нужно заменять ту системную информацию, которая есть на существующем компьютере. Далее следует запустить утилиту DCPromo с ключом "/adv" и указать путь к тому хранилищу, где находится распакованный файл. После этого процесс инсталляции нового контроллера будет создавать свою реплику на основании информации со съемного носителя. При этом все равно потребуется связь с головным офисом, потому что помимо перекачки реплики, требуется еще установление определенных отношений с существующим доменом. Поэтому связь должна быть, но требования к ней существенно снижены: подойдет даже очень слабая линия. В приведенном сценарии 95% информации, которые нужно было перекачивать на новый контроллер, были перенесены на системный носитель, а линию связи между головным офисом и филиалом не пришлось перегружать.

Важно отметить, что у заказчиков по-прежнему очень часто используется Windows NT 4.0. Windows 2003 позволяет перейти с существующих каталогов (с NT 4 или с Windows 2000) быстрее, более безболезненно и эффективно. Этой цели служит утилита Active Directory Migration Tool (ADMT) . ADMT поможет с миграцией с Windows NT на Windows 2003, а также с Windows 2000 на Windows 2003 в том случае, если потребуется какая-то реструктуризация доменов, перенесение учетных записей и т.д.



Мастера Active Directory Migration Tool (ADMT) v.2


Active Directory Migration Tool представляет собой набор программ-мастеров. Каждый мастер выполняет определенную задачу (см. картинку выше). Важно, что большинство программ-мастеров имеет режим, который называется "Test migration settings and migrate later" - моделирование процесса без реального выполнения операций. Другими словами, процесс миграции эмулируется, и администратор может посмотреть, каков будет результат и как все будет происходить. Реальные действия в этом режиме не выполняются. В случае, когда результаты работы тестового режима удовлетворительны, можно попросить Active Directory Migration Tool выполнить полноценную миграцию.

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

Данная глава посвящена инструментальному администрированию. В принципе, нельзя сказать, что здесь появилось много новых очень полезных возможностей. Однако кое-что все-таки есть. Например, поддержка Drag&Drop: до выхода Windows 2003 поддержки Drag&Drop не было. Теперь можно кликнуть на объект "пользователь" и перетащить его мышкой в новый контейнер. Это очень удобно. Жаль, что такого механизма в предыдущих версиях не было.

Появилась дополнительная консоль для хранения запросов к каталогу. Известно, что Active Directory - это LDAP-каталог. Значит, к LDAP-каталогам можно делать запросы на стандартном языке запросов. Если эти запросы делать и не запоминать, то это является дополнительной нагрузкой на администратора: каждый раз ему нужно запрос писать заново или копировать его из какого-то документа. Для упрощения данного процесса предлагается раздел, который называется Saved Queries. В нем собственно и сохраняются те запросы, которые администратор или пользователь ввели в консоли.



Консоль сохраненных запросов к каталогу


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

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



Утилиты командной строки


В этом нет, на самом деле, никакого противоречия. Дело в том, что очень много операций, которые приходится выполнять администратору, удобнее делать в виде командных файлов. Например, когда речь идет о модификации у одинаковых или похожих объектов какого-то атрибута, это часто удобнее сделать в командной строке, написав соответствующий скрипт. Если необходимо изменить какой-то параметр, например, телефоны пользователей, которые прописаны в учетной записи (у всех в подразделении может поменяться телефон), можно зайти в каждую учетную запись и изменить телефон. Если это делать через графический интерфейс, то придется произвести как минимум сто операций по изменению объекта "Учетная запись". Можно же взять одну простую команду, которая называется DSMod (модификация объекта), сформировать строчку для записи новой информации, после чего написать скрипт с условиями поиска и выполнить всё в виде одной команды. Для таких операций (а в повседневной работе администратора их множество) следует использовать утилиты командной строки и скрипты.

Репликация

Вопросы репликации очень актуальны при внедрении Active Directory, проектировании и планировании инфраструктуры.

В Windows 2000 есть определенные ограничения по количеству сайтов, в которых можно было бы автоматически сгенерировать топологию. Существует служба, которая называется Inter-Site Topology Generator (ISTG) . Когда создаются два или три, а лучше пять или даже десять сайтов, служба ISTG автоматически генерирует топологию репликаций между сайтами, сама выбирает узловые серверы, сама определяет, как будет выполняться сценарий этой репликации. Всё хорошо, но если сайтов порядка двухсот, то служба ISTG не справляется с объемом информации и зацикливается. Поэтому для Windows 2000 есть совершенно четкая рекомендация - количество сайтов не должно быть более двухсот, если необходимо, чтобы топология репликации между сайтами генерировалась автоматически. Если же сайтов больше - автоматическую генерацию надо отключить и настраивать все это вручную.

Проблема, казалось бы, не очевидна, но с ней люди реально сталкиваются, когда доходит до внедрения Active Directory на многосайтные системы. Windows Server 2003 снимает этот вопрос. В этой системе реализован абсолютно новый Inter-Site Topology Generator, который работает принципиально по-другому и генерирует топологию, используя новый алгоритм. Количество сайтов, которое может теперь автоматически генерироваться (топология которых может генерироваться автоматически с помощью службы ISTG), только на тестах было несколько тысяч. Неизвестно, кому может потребоваться столько сайтов, но, тем не менее, можно забыть о каком-либо ограничении только за счет модификации механизма ISTG.

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

Есть еще одно ограничение в том, как Active Directory в Windows 2000 реплицирует группы. Речь идет о группе безопасности. Когда дело касается назначения прав для доступа к каким-то объектам, обычно правильная практика администрирования подразумевает, что права назначаются группам. Пользователи либо включаются в группу, либо исключаются. Группа - это точно такой же объект в Active Directory, как и все остальные объекты. Объект же имеет атрибуты. Особенность группы заключается в том, что список членов группы - это не несколько атрибутов, это один атрибут с большим количеством значений, так называемый "Multi Value Attribute" (на самом деле, это один атрибут, у которого много значений). Механизм репликации Active Directory детализирован до уровня атрибута. Если объект модифицируется, то система будет реплицировать эти изменения ровно для тех атрибутов, которые изменились, а не для всего объекта целиком. Теперь вернемся к группе, у которой есть атрибут, состоящий, например, из ста значений. Если в группу входит сто человек, значит у этого атрибута сто значений. А если 5 тысяч? Ограничение заключается в следующем: если членство в группе составляет 5 тысяч объектов, то репликация такого объекта становилась невозможна. Как только появится 5001 член группы, сразу же разрушается процесс репликации этой группы на Windows 2000. Есть даже документированный способ атаки, когда администратор, обиженный на кого-то, может разрушить процесс репликации в системе, просто написав скрипт, который циклическим образом поместит в какую-то группу 5 тыс. членов. После чего возникают проблемы с репликацией каталога. Windows Server 2003 Active Directory вводит дополнительный механизм, который называется "Репликация присоединенных значений" ("Linked Value Replication").

В этом случае механизм предназначен исключительно для репликации атрибутов, у которых есть много значений. То есть теперь, при использовании этого механизма членство в группе реплицируется на уровне отдельных членов. Если включить нового человека в группу, то репликация будет вестись не всего списка, как атрибут, а только значения за счет механизма Linked Value Replication.

Еще одна проблема, связанная с репликацией, имела отношение к глобальному каталогу. Трудность заключалась в том, как ведет себя глобальный каталог, когда администратор модифицирует, так называемый, Partial Attribute Set (PAS) - список атрибутов, которые должны быть помещены в глобальный каталог.

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

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

Windows Server 2003 снимает эту проблему. Репликация и синхронизация глобального каталога будет проводиться исключительно в объеме добавленного атрибута. То есть когда проводится операция добавления атрибута к PAS, происходит просто сбор информации у тех объектов, у которых этот атрибут есть. А затем он [атрибут] добавляется к глобальному каталогу. Полной синхронизации не происходит.

Еще одна дополнительная функция, касающаяся глобального каталога - это механизм кэширования универсальных групп. Напомню, группы в Active Directory бывают трех типов: локальные, глобальные и универсальные. Локальные и глобальные хранятся вместе с репликой на контроллере, универсальные группы хранятся в глобальном каталоге. Когда сотрудник удаленного офиса хочет войти в сеть, система провести регистрацию пользователя в сети и создать его контекст безопасности. Для этого ей необходимо узнать, в какие группы входит пользователь. Узнать о локальных и глобальных группах Windows 2000 может на своем ближайшем контроллере, но по устройству сети, глобальный каталог находится в головном офисе. Проверить членство пользователя в универсальных группах можно только, сделав запрос к глобальному каталогу. Поэтому на момент регистрации необходимо послать запрос в головной офис. Если связь оборвана и глобальный каталог не доступен, то пользователю будет отказано в регистрации (по умолчанию в этой ситуации). Если в реестре поставить значение "игнорировать ошибки, связанные с членством в универсальных группах", в системе безопасности образуется дыра.

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

Доверие между лесами

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



Доверие между лесами


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

Windows 2000 позволяет сделать прямые и транзитивные отношения между конкретными доменами из разных лесов, но работать это будет только для данных доменов. Windows Server 2003 предлагает новый тип доверия, который называется "Отношение доменов между лесами". Эти отношения являются транзитивными для доменов, которые входят в каждый из лесов. То есть, когда два леса соединяются доверительными отношениями, пользователи из любого домена одного леса абсолютно прозрачно могут видеть объекты другого леса и обращаться к ним из любых доменов.

Можно сделать цепочку, например, из трех лесов A, B, C. A доверяет В, а В доверяет С. Из этого не следует, что между лесом А и С тоже установились доверительные отношения. Это как в Windows NT 4: не транзитивные отношения в том смысле, что они не транзитивны между лесами. Но между доменами, которые связывают два леса, отношения являются транзитивными.

Управление групповыми политиками

Групповые политики - это основной инструмент, который используется для управления практически всеми подсистемами и компонентами в рамках Windows. Будь то рабочая станция и ее настройки, будь то сервер и его сетевые службы, Active Directory, параметры безопасности - все это настраивается через групповые политики.

Механизм групповых политик позволяет назначать политики контейнерам, то есть организационным подразделениям, сайтам и доменам. Групповую политику нельзя назначить конкретному пользователю. При этом, поскольку структура контейнеров в Active Directory иерархична, можно на разных уровнях назначать разные групповые политики. Следовательно, работают механизмы наследования. У администратора есть определенные функции по блокировке наследования или, наоборот, по принудительному применению политики наследования. Администратор имеет возможность фильтровать применение групповых политик через права доступа. В любом случае, большое количество задач решается с помощью не меньшего количества инструментов. Для каждой задачи есть определенный инструмент. Таким образом, чтобы управлять групповыми политиками в Windows 2000, требуется знать порядка шести инструментов и использовать их для различных задач.

Windows Server 2003 позволяет существенно упростить жизнь администратору за счет появления специального инструмента, который называется Group Policy Management Console. Это интегрированная или консолидированная консоль, которая включает в себя интерфейс для выполнения абсолютно всех задач, связанных с групповыми политиками. Больше не нужно ломать голову, где делается данная операция - все в Group Policy Management Console, при этом консоль группирует информацию очень логично, интуитивно понятно.

Помимо того, что Group Policy Management Console является консолидированным графическим инструментарием, она еще и добавляет ряд новых функций к управлению групповыми политиками. Например, функции архивирования и восстановления групповых политик, функции копирования групповых политик между доменами одного леса и импорт/экспорт групповых политик.

Group Policy Management Console, как составная часть Windows Server 2003, отсутствует. Ее нужно скачивать с web-сервера Microsoft (http://www.microsoft.com/downloads ). Установить консоль можно либо на Windows Server 2003, либо на Windows XP при наличии Service Pack 1 и.NET Framework. Таким образом, с помощью Group Policy Management Console можно управлять групповыми политиками, даже не находясь непосредственно на контроллере домена. Можно установить консоль прямо на рабочую станцию Windows XP и с этой рабочей станции централизованно управлять всеми групповыми политиками леса. Кроме того, в составе Group Policy Management Console есть два мастера, которые позволяют анализировать и моделировать процесс применения групповых политик. Первый называется "Мастер результатов применения групповых политик" и он показывает, какие политики применялись к данному конкретному компьютеру, какие значения изменились и с каких политик эти значения были получены. Если что-то не применилось, мастер показывает, почему это не применилось.

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

Процесс такого моделирования выполняется с помощью консоли, которая расположена в Group Policy Management Console и называется Process Modeling. Моделирование не требует подключения к исследуемому компьютеру. Оно работает только с информацией, которая хранится в Active Directory. Достаточно просто иметь доступ к контроллеру Windows Server 2003 Active Directory. Можно, например, представить, что случится, если пользователь войдет в какую-то группу безопасности, можно условно поместить пользователя в какой-то контейнер и посмотреть, что произойдет.

Есть еще некоторые новые возможности Group Policy Management Console - это архивирование и восстановление групповых политик. Сами объекты можно сохранить в виде файла в определенном каталоге. Потом их можно восстановить обратно в случае какой-то проблемы или при экспериментах с доменом, Active Directory или групповыми политиками. Важно, что восстановить групповую политику можно только в том же домене, в котором она была заархивирована. Восстанавливается только объект групповой политики сам по себе: то, что было к нему дополнительно привязано, нельзя поместить в архив, соответственно, восстановить тоже.

Перейдем теперь к Windows Management Instrumentations (WMI). Это технология, которая сейчас является основной в управлении системами. WMI используется практически везде: любая служба так или иначе задействует WMI.

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

Политика ограничения на использование программ

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

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

Правила могут быть четырех типов (ранжированы по приоритету): Certificate (максимальный приоритет), Hash, Path и Zone. Приоритет актуален, когда есть несколько политик, определяющих одно и то же приложение разными правилами. Например, одна политика разрешает запускать все программы, которые расположены в каталоге "ABCD", а другая политика запрещает запускать программы, имеющие такой-то хэш. Если окажется, что эта программа, которую запрещено запускать, находится в разрешенном каталоге ABCD, то сильнее окажется правило запрета, потому что правило по хэшу "побеждает" правило по пути. Именно для этого используется приоритет.

Заключение

Можно резюмировать, что с появлением Windows Server 2003 добавилось не так уж и много полезных возможностей для работы с Active Directory. Тем не менее, некоторые из них очень полезны и могут сэкономить время и нервы системному администратору. Это, прежде всего, Group Policy Management Console и утилиты командной строки. Остальные изменения зачастую устраняют недоработки предыдущих версий системы (обновленные механизмы и алгоритмы), однако все равно необходимо знать, где именно возможности Active Directory расширены и как ими пользоваться...

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

DNS - это служба локатора (locator service), используемая Active Directory (и многими другими компонентами Windows). Active Directory делает свои службы доступными в сети, публикуя их в DNS . Когда устанавливается контроллер домена (или к нему добавляются службы), он использует динамические обновления для регистрации своих служб в DNS как записей SRV. После этого клиенты могут находить службы через простые DNS -запросы. По умолчанию служба Microsoft DNS работает на каждом контроллере домена под управлением Windows Server 2003.

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

Анализ существующей инфраструктуры

    Определение географической модели организации

    • Локальная модель

      Региональная модель

      Национальная модель

      Международная модель

    • Дочерние компании

    Создание карты территориального размещения организации

    Сбор сведений о информационных потоках в организации

    Анализ текущей модели администрирования

    Анализ топологии существующей сети

Планирование структуры AD

Первый шаг в проектировании структуры AD - определение лесов и доменов.

    Применение одного домена

    • Упрощение управления пользователями и группами

      Нет необходимости планировать доверительные отношения

      Для делегирования прав применяются OU

    Применение нескольких доменов

    • Возможность реализации разных политик безопасности

      Децентрализованное управление

      Оптимизация трафика

      Разные пространства имен

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

Применение одного домена

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

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

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

Домены Active Directory масштабируемы в гораздо большей мере, чем домены Windows NT. Поэтому исчезает существенное препятствие, не позволявшее применять однодоменные сети на основе Windows NT, в которых диспетчер учетных записей безопасности (Security Accounts Manager, SAM) поддерживал только до 40 000 объектов в домене. В отличие от Windows NT в домен Active Directory может входить более миллиона объектов.

Использование нескольких доменов

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

    Групповая политика и управление доступом действует на уровне домена

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

    Административные права, действующие между доменами, выдаются только для Администраторов предприятия

    Необходимо создавать доверяемые каналы

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

Применение нескольких деревьев в лесу

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

Два дерева, представляющие собой два пространства имен

Недостатки:

    Разное пространство имен, поддержка больше DNS -имен

    Проблемы связанные с применением нескольких доменов

    Возможности LDAP клиентов

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

Недостатки такого варианта:

    Поскольку у каждого дерева должно быть отдельное пространство имен DNS , ИТ-отделу придется поддерживать больше DNS -имен, чем в случае однодоменной модели.

    Чем больше деревьев, тем больше доменов, поскольку каждое дерево должно содержать минимум один домен. Следовательно, возникнут все проблемы, связанные с применением нескольких доменов.

    Возможно, что LDAP -клиенты (Lightweight Directory Access Protocol), разработанные не Microsoft, не смогут выполнять поиск по глобальному каталогу и вместо этого им придется вести LDAP -поиск по каждому дереву отдельно. В результате увеличится время отклика для таких клиентов.

С учетом этих недостатков имеет смысл подумать об альтернативном решении: объединить пространства имен и использовать одно дерево с разными доменами вместо нескольких деревьев.

Отдельные пространства имен, в одном дереве

Применение нескольких лесов

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

Леса представляют собой крайние границы зон безопасности. Между лесами невозможно административное управление или пользовательский доступ, если на то нет явного разрешения в конфигурации. Для этого предназначен новый тип доверия, введенный в Windows Server 2003, - доверие к лесу (forest trust), применяемое при управлении отношениями между двумя лесами.

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

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

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

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

    Создание изолированного подразделения. Изолированный лес отличается от автономного в первую очередь уровнем полномочий по управлению, доступных администраторам вне леса. В изолированном лесу гарантируется, что администратор вне леса не сможет повлиять на управление им.

Недостатки структуры из нескольких лесов

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

Архитектура с несколькими лесами имеет следующие недостатки.

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

    Сотрудникам, которым требуется входить на компьютеры, включенные во внешние леса, должны указывать при входе основное имя пользователя (user principal name, UPN) по умолчанию. От таких сотрудников требуется более высокий уровень подготовки.

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

    Администраторам приходится хранить несколько схем.

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

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

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

Соглашение о именовании

Чтобы найти сетевой ресурс, необходимо знать имя объекта или его одно из его свойств. Active Directory поддерживает несколько типов имен:

    Относительные составные имена

    Составные имена

    Основные имена пользователей

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

Решив, какую структуру доменов и лесов нужно создать, переключите свое внимание на именование элементов, входящих в эту структуру.

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

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

Относительные составные имена

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

CN=wjglenn,CN=Users,OC=kd,DC=ru относительным составным именем объекта является CN=wjglenn . RDN родительской организационной единицы (OU) - Users. У большинства объектов RDN - то же, что и атрибут Common Name.

Active Directory автоматически создает RDN по информации, указываемой при создании объекта, и не допускает, чтобы в одном и том же родительском контейнере существовали два объекта с одинаковыми RDN.

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

    DC - тэг Domain Component, который идентифицирует часть DNS -имени домена вроде СОМ или ORG.

    OU - тэг Organizational Unit, который идентифицирует организационную единицу, являющуюся контейнером.

    CN - тэг Common Name, который идентифицирует простое имя, присвоенное объекту Active Directory.

Составные имена

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

Вот типичный пример составного имени: CN=wjglenn,CN=Users,DC=kd,DC=ru

Это DN означает, что объект пользователя wjglenn содержится в контейнере Users, в свою очередь содержащемся в домене kd.ru. Если объект wjglenn переместят в другой контейнер, его DN изменится и будет отражать новое местоположение в иерархии. DN гарантированно уникальны в лесу - по аналогии с тем, как полное доменное имя (fully qualified domain name, FQDN) уникально идентифицирует местонахождение объекта в иерархии DNS . Существование двух объектов с одинаковыми DN невозможно.

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

Каноническое имя объекта используется во многом также, как и составное. Просто у него другой синтаксис. Составному имени, приведенному в предыдущем разделе, соответствовало бы следующее каноническое имя: kd.ru/Users/wjglenn

Как видите, в синтаксисе составных и канонических имен два основных отличия. Первое - каноническое имя формируется от корня к объекту, а второе - в каноническом имени не используются тэги LDAP -атрибутов (например CN и DC).

Основные имена пользователей

Основное имя пользователя (UPN), генерируемое для каждого объекта пользователя, имеет вид имя_пользователя@имя_домена . Пользователи могут входить в сеть под своими основными именами, а администратор при желании может определить для этих имен суффиксы. Основные имена пользователей должны быть уникальными, но Active Directory не проверяет соблюдение этого требования. Лучше всего принять соглашение об именовании, не допускающее дублирования основных имен пользователей.

Идентификаторы защиты

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

    Хозяин именования доменов

    • Один домен в каждом лесу, обрабатывает добавление и удаление доменов и генерирует уникальный идентификатор защиты (SID)

    Хозяин RID

    • Генерирует последовательности для каждого из контроллеров домена. Действует в пределах домена. Генерирует для каждого контроллера домена пул по 500 RID.

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

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

Однако при выработке стратегии именования представляют интерес две роли хозяев операций: именования доменов (domain naming master) и RID (relative ID master). Два сервера, выполняющих эти роли, должны быть доступны, когда создаются и именуются новые участники системы безопасности (security principals).

Определение стратегии именования

Следует учитывать требования и DNS и AD

    Поддерживается иерархия, длина имени до 64 символов

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

Совместимость с NetBios-именами

    Плоская модель, длина имени не более 16 символов

Существует возможность назначать разные NetBios и DNS имена, но такой подход не допустим.

При выработке стратегии именования необходимо учитывать требования к именованию, предъявляемые как Active Directory, так и DNS . Клиенты используют DNS для разрешения IP-адресов серверов, на которых выполняются важные сетевые сервисы Active Directory. Следовательно, Active Directory и DNS неразрывно связаны.

В DNS имена образуют иерархию и формируются путем «движения» от родительских доменов к дочерним. Так, у домена kd.ru может быть дочерний домен sales.kd.com, у того в свою очередь - дочерний домен europe.sales.kd.ru. Имя каждого домена соответствует пути, идентифицирующему домен в иерархии DNS , т. е. пути к корневому домену (корневой домен обозначается точкой).

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

Все имена доменов Active Directory идентифицируются по DNS , но можно использовать и NetBIOS-имена (Network Basic Input/Output System) - унаследованную систему именования, которая применялась в старых версиях Windows и по-прежнему поддерживается в Windows Server 2003. Windows автоматически генерирует NetBIOS-имена для каждой службы, выполняемой на компьютере, добавляя к имени компьютера дополнительный символ. Доменам также присваиваются NetBIOS-имена.

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

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

Используйте только символы, разрешенные стандартами Интернета: а-z, 0-9 и дефис (-). Хотя реализация DNS в Windows Server 2003 поддерживает и другие символы, применение стандартных символов гарантирует возможность взаимодействия с другими реализациями DNS .

Используйте короткие доменные имена, которые легко идентифицировать и которые соответствуют соглашению об именовании в NetBIOS.

В качестве основы имени корневого домена берите только зарегистрированные доменные имена. Даже если вы не используете в качестве имени корня леса зарегистрированное DNS -имя, это поможет избежать путаницы. Например, у компании может быть зарегистрирован домен kd.ru. Если вы не используете kd.ru в качестве имени корневого домена вашего леса, все равно формируйте имя, производное от kd.ru (скажем, sales.kd.ru).

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

Для большей безопасности создайте отдельные внутреннее и внешнее пространства имен, чтобы предотвратить несанкционированный доступ к закрытым ресурсам. И создавайте внутреннее имя на основе внешнего (например kd.ru и local.kd.ru).

Имена участников системы безопасности

Объекты участников системы безопасности - это объекты AD, которым назначены идентификаторы защиты и которые указываются при входе в сеть (учетные записи пользователей, компьютеров и групп)

При добавлении учетной записи администратор задает:

    Имя используемое для входа в сеть

    Имя домена, содержащего учетную запись

    Прочие атрибуты (имя, фамилия, телефон..)

Имена могут содержать любые символы Unicode, за исключением следующих: #, +, «, \, <, >

Объекты участников системы безопасности (security principal objects) - это объекты Active Directory, которым назначены идентификаторы защиты и которые указываются при входе в сеть и предоставлении доступа к ресурсам домена. Администратор должен давать объектам участников системы безопасности (учетным записям пользователей, компьютеров и групп) имена, уникальные в рамках домена. Следовательно, вы должны выработать стратегию именования, которая позволит это делать.

Добавляя в каталог учетную запись нового пользователя, администратор должен задать следующую информацию:

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

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

    прочие атрибуты, такие как имя, фамилия, номер телефона и т. д.

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

Правила имен участников системы безопасности

    Длина имен учетных записей пользователей не более 20 символов

    Имена учетных записей компьютеров не более 15 символов

    Длина имен учетных записей групп не более 63 символов

    Нельзя использовать только точки, пробелы и знак @

Имена участников системы безопасности не могут состоять только из точек, пробелов и знаков @. Любые точки или пробелы в начале имени пользователя отбрасываются.

Допускается применение одного и того же имени участника системы безопасности в разных доменах. Так, можно создать пользователя wjglenn в доменах hr.kd.ru и sales.kd.ru. Это не приведет к проблемам, поскольку составное, относительное составное и каноническое имена каждого объекта автоматически генерируются Active Directory и все равно позволяют глобально идентифицировать этот объект.

Проектирование структуры OU

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

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

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

Не следует создавать структуру OU исключительно ради того, чтобы иметь какую-то структуру, - OU используются в определенных целях. К этим целям относятся: делегирование административного управления объектами; ограничение видимости объектов; управление применением групповой политики.

Цели создания OU

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

    Ограничение видимости объектов

    Управление применением групповой политикой

Есть две основные архитектуры OU, применяемые для делегирования административных полномочий: на основе объектов и на основе задач. Эти две архитектуры рассматриваются в следующих разделах.

Архитектура основанная на объектах

Архитектура основанная на объектах

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

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

Служба каталогов Active Directory позволяет весьма точно управлять делегированием административных полномочий. Например, можно предоставить одной группе полный доступ ко всем объектам OU, второй - права на создание, удаление и изменение объектов OU определенного типа, а третьей - право управлять определенным атрибутом объектов конкретного типа (скажем, возможностью сбрасывать срок действия паролей учетных записей пользователей). Кроме того, можно сделать эти разрешения наследуемыми, чтобы они применялись не только к данному OU, но и ко всем создаваемым OU более низкого уровня. Такое тонкое управление обеспечивает огромную гибкость.

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

Архитектура основанная на задачах

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

Верхний уровень структуры OU

Верхний уровень структуры OU

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

Физические участки. В филиалах, физически расположенных в разных местах (особенно, когда компания действует на обширной территории, например в нескольких странах), часто имеются свои ИТ-отделы, поэтому у филиалов разные требования к администрированию. Создание отдельного OU верхнего уровня для каждого филиала - один из вариантов архитектуры, основанной на задачах; в зависимости от местонахождения определяются разные административные задачи.

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

Типы объектов. Как и структура, основанная на задачах, структура, в которой OU верхнего уровня соответствуют типам объектов, обеспечивает устойчивость архитектуры к изменениям.

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

Нижний уровень OU

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

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

Задачи решаемые с помощью OU

Применение OU для ограничения видимости объектов

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

Применение OU для управления групповой политикой

Групповая политика позволяет применять одни и те же параметры конфигурации сразу к нескольким объектам. С ее помощью можно определять параметры пользователей (например ограничения, налагаемые на пароли) или компьютеров. При использовании групповой политики вы создаете объект групповой политики (Group Policy Object, GPO) - объект, содержащий параметры конфигурации, которые вам нужно применить. Создав GPO, вы связываете его с доменом, сайтом или OU.

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

Планируйте структуру OU так, чтобы использовать как можно меньше GPO. Чем больше GPO связано с каким-либо объектом, тем больше времени потребуется пользователям, чтобы войти в сеть.

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

Создавайте дополнительные OU, чтобы обойтись без фильтрации для изъятия группы пользователей из OU, связанной с GPO.

Контейнеры и OU по умолчанию

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

Контейнер Домен (Domain). Корневой контейнер в иерархии Active Directory. Административные разрешения, применяемые к этому контейнеру, могут влиять на дочерние контейнеры и объекты всего домена. Не делегируйте полномочия на управление этим контейнером - им должны управлять администраторы служб.

Контейнер Встроенный (Built-in). Содержит учетные записи администраторов служб, используемые по умолчанию.

Контейнер Пользователи (Users). Применяемое по умолчанию хранилище учетных записей новых пользователей и групп, создаваемых в домене. Также не следует изменять разрешения на доступ к этому контейнеру, действующие по умолчанию. Если требуется делегировать управление определенными пользователями, создайте новые OU и перенесите в них объекты пользователей. Кроме того, с контейнером Пользователи (Users) нельзя связать GPO. Чтобы применить групповую политику к пользователям, вы также должны создать OU и перенести в них пользователей.

Контейнер Компьютеры (Computers). Применяемое по умолчанию хранилище новых учетных записей компьютеров, создаваемых в домене. Как и в случае контейнера Пользователи (Users), чтобы назначить разрешения или GPO компьютерам, следует создать OU.

OU Контроллеры домена (Domain Controllers). Здесь по умолчанию хранятся учетные записи компьютеров - контроллеров домена. К этому OU по умолчанию применяется ряд политик. Чтобы обеспечить единообразие применения этих политик ко всем контроллерам домена, рекомендуется не переносить объекты-компьютеры, являющиеся контроллерами домена, из этого OU. По умолчанию этим OU управляют администраторы служб. Не делегируйте управление этим OU пользователям, которые не являются администраторами служб.

Стандартные модели структуры OU

Существует пять базовых моделей структуры OU:

    На основе местоположения

    На основе структуры организации

    На основе функций

    Смешанная - сначала по местоположению, затем по структуре организации

    Смешанная - сначала по структуре, затем по местоположению

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

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

Модель по месту положения

Модель по месту положения

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

    OU Устойчивы к изменениям

    Для центрального 1Т-отдела легко реализовать общедоменные политики

    Легко определять положение ресурсов

    Легко создавать новые OU при расширении компании

Недостатки:

    Предполагает наличие в каждом филиале администратора

    Архитектура не соответствует бизнес-структуре или административной структуре

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

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

Модель на основе структуры организации

Модель на основе структуры организации

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

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

    Поддерживает слияния и расширения

    Удобна администраторам

Недостатки:

    Уязвима при реорганизации, т.к. может потребоваться изменение верхнего уровня структуры ОU

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

Модель на основе функций

Модель на основе функций

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

    Устойчивость при реорганизациях

Недостаток:

    Создание дополнительных OU для делегирования административного управления пользователями, компьютерами, принтерами.

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

Смешанная модель - по положению

Смешанная модель - по положению

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

    Поддерживает рост числа подразделений

    Позволяет создавать зоны безопасности

Недостатки:

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

    Необходимо взаимодействие между администраторами, работающими в разных отделах одного филиала

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

Смешанная модель - по структуре

Смешанная модель - по структуре

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

    Надежная защита на уровне отделов и подразделений

    И в тоже время возможность делегировать административные полномочия в зависимости от местоположения

Недостатки:

    Уязвимость при реорганизациях

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

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

Типы учетных записей

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

Компьютер. Всякий раз, когда в домен добавляется компьютер под управлением Microsoft Windows NT, Windows 2000, Windows XP или Windows Server 2003, для него создается учетная запись компьютера. Учетные записи компьютеров служат для аутентификации компьютеров, которые обращаются к сети и ресурсам домена.

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

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

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

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

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

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

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

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

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

Планирование учетных записей пользователей

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

Учетные записи пользователей предоставляют пользователям возможность входить в домен или на локальный компьютер и обращаться к ресурсам. Объекты учетных записей пользователей содержат информацию о пользователях и связывают с ними определенные привилегии или ограничения. Каждый объект Active Directory связан со списком управления доступом (Access Control List, ACL), который представляет собой список разрешений на доступ к объекту, заданных для пользователей и групп.

Типы учетных записей пользователей

В Windows Server 2003 существует два основных типа учетных записей пользователей.

Локальные учетные записи пользователей. Создаются в базе данных защиты локального компьютера и управляют доступом к ресурсам этого компьютера. Локальные учетные записи пользователей предназначены для управления доступом к изолированным компьютерам или к компьютерам, входящим в рабочую группу. Когда вы только что установили операционную систему на сервер, используются локальные учетные записи, управление которыми осуществляется через консоль Управление компьютером (Computer Management) в узле Локальные пользователи и группы (Local Users and Groups). Если вы сделаете сервер контроллером домена, инструмент Управление компьютером запретит доступ к этому узлу, и вместо него будет использоваться инструмент Active Directory - пользователи и компьютеры (Active Directory Users and Computers) (учетные записи пользователей на контроллерах домена хранятся в Active Directory).

Доменные учетные записи пользователей. Создаются в Active Directory и дают возможность пользователям входить в домен и обращаться к любым ресурсам сети. Вы можете создать доменную учетную запись пользователя с помощью Active Directory - пользователи и компьютеры (Active Directory Users and Computers). Такие учетные записи пользователей реплицируются на все контроллеры в домене, поэтому после репликации любой контроллер домена сможет аутентифицировать пользователя.

Встроенные учетные записи пользователей.

Windows автоматически создает несколько учетных записей пользователей, называемых встроенными. И на локальных компьютерах, и в доменах создается две ключевых учетных записи: и Гость (Guest) .

Учетная запись Администратор обладает наибольшими возможностями, поскольку она автоматически включается в группу Администраторы (Administrators) . Члены этой группы имеют высший уровень прав по управлению компьютером, им предоставляются почти все пользовательские права. Учетная запись Администратор уровня домена дает максимум возможностей по управлению доменом в целом; по умолчанию она включается в группу Администраторы домена (Domain Admins) [а администратор корневого домена леса, кроме того, входит в группы и ]. Учетную запись Администратор нельзя удалить, но ее можно переименовать (и это следует сделать для большей безопасности). Также следует задать для этой учетной записи непустой пароль и не передавать его другим пользователям.

Учетная запись Гость (Guest) - еще одна базовая встроенная учетная запись пользователя. Она предназначена для того, чтобы администратор мог задать единый набор разрешений для любых пользователей, которые иногда входят в сеть, но не имеют обычной учетной записи. Учетная запись Гость позволяет это сделать, так как автоматически включается в локальную группу Гости (Guests) . В среде, где есть домен, эта учетная запись также включается в группу Гости домена (Domain Guests) . По умолчанию учетная запись Гость отключена. И действительно, ее следует использовать только в сетях, не требующих особой защиты. Эту учетную запись нельзя удалить, но можно отключить и/или переименовать.

Правила именования учетных записей

    Каждый пользователь должен иметь уникальное имя (логин) в домене

    Длина имени не должна превышать 20 символов (из-за совместимости с предыдущими версиями Windows)

    Имена не чувствительны к регистру букв

    Имена не должны содержать символов: »/\:; = , + *?< >

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

    Учитывайте совместимость именования для других приложений (например для электронной почты)

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

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

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

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

    Смена пароля не чаще чем 1 раз сутки

    Длина пароля на должна быть короче 7 символов

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

Пароли - один из наиболее важных аспектов сетевой безопасности, поэтому политику определения паролей пользователей необходимо тщательно продумать. В Windows Server 2003 по умолчанию действуют более строгие ограничения на пароли, чем в предыдущих версиях. Например, в Windows Server 2003 имеется новое средство, проверяющее сложность пароля учетной записи Администратор (Administrator) . Если пароль пустой или недостаточно сложный, Windows предупреждает, что использовать нестойкий пароль опасно. Оставив пароль пустым, вы не сможете обращаться к учетной записи через сеть.

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

Стратегия аутентификации

Планирование групп

Типы групп

Группы безопасности

    Используются для объединения в одну административную единицу

    Используются ОС

Группы распространения

    Используются приложениями (не ОС) для задач не связанных с защитой

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

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

    Можно назначать разрешения или добавлять в локальные группы любого домена в данном лесу

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

    Существуют на контроллерах домена и используются для управления доступом к ресурсам локального домена

    Могут включать пользователей и глобальные группы в пределах леса

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

    Используются для назначение разрешений доступа к ресурсам нескольких доменов

    Существуют вне границ доменов

    Могут включать пользователей, глобальные группы и другие универсальные группы в пределах леса

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

Как и в случае учетных записей пользователей, группы бывают локальные и уровня домена. Локальные группы хранятся в базе данных защиты локального компьютера и предназначены для управления доступом к ресурсам этого компьютера. Группы уровня домена хранятся в Active Directory и позволяют помещать в них пользователей и управлять доступом к ресурсам домена и его контроллеров.

Вложение групп и их именование

    Способ упорядочить пользователей

    Глубина вложений должна быть минимальной (желательно 1 уровень вложенности)

    Требования при именовании такие схожи с требованиями для пользователей, но длина до 64 символов

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

Взаимодействие групп и пользователей

    Избегайте выдачи разрешений учетным записям

    Создавайте локальные группы домена

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

    Помещайте глобальные группы в локальные группы домена

    Не включайте пользователей в универсальные группы

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

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

Групповая политика - набор параметров конфигурации пользователей и компьютеров. Называется объектом групповой политики (GPO)

Существует два типа параметров групповой политики:

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

    • Используется для задания групповых политик, применяемых к определенным компьютерам

    Конфигурация пользователя

    • Используется для задания групповых политик, применяемых к определенным к определенным пользователям

Не зависимо от типа есть три категории:

    Параметры программ

    Параметры Windows

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

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

Групповая политика - набор параметров конфигурации пользователей и компьютеров, который можно связать с компьютерами, сайтами, доменами и OU в Active Directory. Такой набор параметров групповой политики называется объектом групповой политики (Group Policy Object, GPO).

Любой компьютер под управлением Windows 2000, Windows ХР или Windows Server 2003 (независимо от того, входит он в Active Directory или нет) содержит один локальный GPO, в котором заданы политики, применяемые к этому компьютеру. Если компьютер входит в Active Directory, к нему можно применить несколько дополнительных GPO, не являющихся локальными.

Существует два основных типа параметров групповой политики.

Параметры программ

Параметры применяемые для установки ПО на клиентских ПК (поддерживаются ОС Windows 2000 и более новые)

Используются два компонента:

    Служба установки Windows

    • Установка и обновление ПО в соответствии с инструкциями в установочных пакетах

    Установочные пакеты Windows

    • Исполняемые файлы сценариев со всеми инструкциями (msi)

Узел Параметры программ (Software Settings) содержит параметры, которые можно использовать для развертывания ПО на клиентских компьютерах, к которым применяется групповая политика. Для этого клиентские компьютеры должны работать под управлением Windows 2000 Professional, Windows 2000 Server, Windows XP Professional, Windows XP 64-Bit Edition или Windows Server 2003 и быть членами домена. Вы можете задать, для каких пользователей или на какие компьютеры будет установлено ПО, при необходимости указать обновления и даже удалить ПО. Для поддержки этой функции нужны два взаимодействующих компонента.

Служба установки Windows (Windows Installer service) - служба, которая развертывает и обновляет ПО в соответствии с инструкциями в установочных пакетах Windows (Windows Installer packages)

Установочные пакеты Windows (Windows Installer Packages) - исполняемые файлы сценариев со всеми инструкциями, нужными Windows Installer для установки, обновления или восстановления ПО. Файлы Windows Installer Package имеют расширение msi.

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

Существует два способа развертывания ПО с помощью групповой политики: публикация (publishing) и назначение (assigning) . Когда приложение назначается пользователю, создается ярлык, доступный пользователю и показываемый в меню Пуск (Start) или на рабочем столе этого пользователя. Это называется предложением (advertising) приложения пользователю. Когда пользователь щелкает ярлык (или открывает файл, связанный с программой), запускается программа установки. Когда приложение назначается компьютеру, приложение устанавливается при первом запуске компьютера после назначения.

Если вы публикуете приложение, оно становится доступным пользователям, которые могут установить его, когда пожелают. Приложения можно публиковать только для пользователей - сделать это для компьютера нельзя. Приложение становится доступным в апплете Установка и удаление программ (Add/Remove Programs) панели управления (Control Panel) и устанавливается по запросу пользователя, если тот откроет файл, связанный с программой.

Параметры Windows

Сценарии (Scripts). При настройке конфигурации компьютера можно задать сценарии, которые выполняются при его включении или выключении. При настройке конфигурации для пользователя можно задать сценарии, выполняемые при входе или выходе пользователя. Сценарии можно писать на любое языке сценариев с поддержкой ActiveX, в том числе на VBScript, JScript, Perl , языке командных файлов MS -DOS и др.

Параметры безопасности (Security Settings). Это параметры безопасности, задаваемые для компьютеров и пользователей.

Настройка Internet Explorer (Internet Explorer Maintenance). Этот узел доступен только для пользователей. Он служит для управления работой Internet Explorer на клиентских компьютерах.

Службы удаленной установки (Remote Installation Services, RIS). RIS позволяет автоматически выполнять удаленную установку операционной системы на новые клиентские компьютеры. Эти параметры тоже доступны только для конфигураций пользователей. Они управляют удаленной установкой операционных систем.

Перенаправление папок (Folder Redirection). И эти параметры доступны только для конфигураций пользователей. Они позволяют переопределить специальные папки Windows [такие как Мои документы (My Documents), Главное меню (Start Menu) и Application Data], изменив их местонахождение по умолчанию на сетевой каталог. Благодаря этому можно централизованно управлять папками пользователей.

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

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

Узел Конфигурация компьютера Конфигурация пользователя Описание
Панель управления Неприменимы X Определяет средства панели управления, доступные пользователю
Рабочий стол Неприменимы X Задает внешний вид рабочего стола пользователя
Сеть X X Управляет параметрами Автономные файлы и Сеть и удаленный доступ к сети
Принтеры X Неприменимы Параметры принтеров
Панель задач и меню «Пуск» Неприменимы X Параметры конфигурации для меню пуск и панели задач пользователя
Система X X Управление входом/выходом, запуск/остановка
Компоненты Windows X X Управление встроенными компонентами Windows

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

Локальный GPO - обрабатывается локальный GPO компьютера и применяются все параметры защиты, заданные в этом GPO.

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

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

GPO OU - обрабатываются GPO, связанные с любыми OU, содержащими пользователя или компьютер. Параметры, заданные на уровне OU, переопределяют параметры, примененные на локальном уровне или уровне домена/сайта, с которыми они конфликтуют. Один и тот же объект может входить в несколько OU. В этом случае сначала обрабатываются GPO, связанные с OU, находящимся на самом высоком уровне иерархии Active Directory, затем - с OU, находящимся на следующем уровне и т.д. Если с одной OU связано несколько GPO, администратор, как и в предыдущих случаях, может задать порядок их обработки.

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

    Дочерние контейнеры наследуют групповую политику от родительских контейнеров

    Есть возможность переопределить унаследованные параметры

    В GPO можно задавать активность/неактивность и не определенность параметров

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

    Дополнительные механизмы наследования:

    • Не перекрывать

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

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

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

Если GPO определены и для родителя, и для потомка и если заданные в них параметры совместимы, эти параметры комбинируются. Например, если в родительской OU задана определенная длина пароля, а в дочерней OU - некая политика блокировки учетных записей, будут использоваться оба этих параметра. Если параметры несовместимы, то по умолчанию с дочерним контейнером связывается значение параметра, переопределяющее значение параметра, который связан с родительским контейнером.

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

Конечно, описанное выше наследование применяется только по умолчанию. Имеется еще два механизма, применяемых при управлении наследованием групповых политик.

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

Блокировать наследование политики (Block Policy Inheritance). При выборе этого параметра контейнер не наследует параметры GPO, заданные для родительского контейнера. Однако, если для родительского контейнера указан параметр Не перекрывать, дочерний контейнер не может заблокировать наследование от своего родителя.

Планирование структуры GPO

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

Связывание GPO с доменом

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

Связывание GPO с сайтом

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

Связывание GPO с OU

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

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

Windows 95/98/Ме не поддерживают групповую политику.

Windows NT 4.0 и более ранних версий не поддерживает групповую политику.

Windows 2000 Professional и Server поддерживают многие параметры групповой политики, доступные в Windows Server 2003, но не все. Неподдерживаемые параметры игнорируются.

Windows XP Professional, Windows XP 64-bit Edition и Windows Server 2003 полностью поддерживают групповую политику.

Планирование сайтов

Планирование сайтов

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

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

Сайты не входят в пространство имен Active Directory- Пользователь, просматривающий логическое пространство имен, видит компьютеры и пользователей, сгруппированных в домены и OU, но сайты при этом не показываются. Однако имена сайтов используются в записях DNS (Domain Name System), поэтому у сайтов должны быть допустимые DNS -имена.

Если вы не конфигурируете в Active Directory собственные сайты, все контроллеры доменов автоматически входят в один сайт по умолчанию с именем Default-First-Site-Name, который создается при создании первого домена.

В целом, сайты служат для управления трафиком по WAN -каналам. А конкретнее, сайты используются для управления: трафиком входа на рабочие станции; трафиком репликации; распределенной файловой системой (Distributed File System, DPS) ; Сведения о TCP/IP-подсетях филиалов

Наблюдает за сетевыми соединениями и задает цены связей между сайтами.

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

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

Как определить, нужен ли контроллер домена для данного участка

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

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

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

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

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

Если сайт является узловым (hub site), т. е. связывает друг с другом остальные сайты меньшего размера, и если у этих сайтов меньшего размера нет своих контроллеров доменов, имеет смысл поместить контроллер домена в узловой сайт, чтобы уменьшить время отклика при входе.

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

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

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

Как определить количество необходимых контроллеров доменов

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

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

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

Если данный домен сайта охватывает от 1000 до 10 000 пользователей, в нем требуется установить не менее двух контроллеров.

Для каждых дополнительных 5000 пользователей следует добавлять по одному контроллеру. Например, если на сайт входят 20 000 пользователей домена, в этом домене следует установить четыре контроллера.

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

Первый домен, создаваемый в новом лесу, называется корневым доменом леса и занимает особое место среди доменов леса. Корневой домен леса закладывает основу структуры леса и пространства имен. Кроме того, данные о группах Администраторы предприятия (Enterprise Admins) и Администраторы схемы (Schema Admins) уровня леса так-же хранятся в корневом домене леса.

Доверительные отношения между доменами являются транзитивными, и вся аутентификация между разными доменами леса выполняется или через корневой домен леса (т. е. контроллер корневого домена леса), или через специально сконфигурированное доверие к сокращению (shortcut trusts) между региональными доменами. Если один сайт содержит несколько доменов, но корневой домен леса находится в другом сайте, можно определить доверие к сокращению или добавить контроллер корневого домена леса в локальный сайт. Это позволит аутентифицировать пользователей между доменами локального сайта, даже если WAN -канал неработоспособен.

Планирование серверов - хозяев операций

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

В Windows Server 2003 две роли хозяев операций уровня леса.

    Хозяин схемы (Schema Master). Первый контроллер домена в лесу принимает роль хозяина схемы и отвечает за поддержку и распространение схемы на остальную часть леса. Он поддерживает список всех возможных классов объектов и атрибутов, определяющих объекты, которые находятся в Active Directory- Если схему нужно обновлять или изменять, - как, например, в случае установки приложения, которое должно модифицировать классы или атрибуты схемы, - то делать это следует на хозяине схемы [т. е. должен быть доступен контроллер домена (DC), имеющий роль хозяина схемы] одному из членов группы Администраторы схемы (Schema Admins) . Если DC, являющийся хозяином схемы, недоступен, а вы должны внести изменения в схему, можно передать эту роль другому DC.

    Хозяин именования доменов (Domain Naming Master). Протоколирует добавление и удаление доменов в лесу и жизненно необходим для поддержания целостности доменов. Хозяин именования доменов запрашивается при добавлении к лесу новых доменов. Если хозяин именования доменов недоступен, добавление новых доменов невозможно; однако при необходимости эта роль может быть передана другому контроллеру. Здесь есть одна тонкость, о которой важно помнить в среде с несколькими доменами: хозяин именования доменов должен быть еще и сервером глобального каталога. Дело вот в чем. Чтобы проверить, является ли уникальным домен, создаваемый в лесу, хозяин именования доменов запрашивает глобальный каталог. Эти две роли автоматически назначаются первому контроллеру домена в лесу. В однодоменной среде (или в лесу с нескольким доменами, в котором все контролле-ры корневого домена леса хранят глобальный каталог) вы должны оставить обе роли хозяев операций уровня леса первому контроллеру, созданному в корневом домене леса.

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

Роли хозяев операций уровня домена

В Windows Server 2003 три роли хозяев операций уровня домена.

    Эмулятор основного контроллера домена отвечает за эмуляцию Windows NT 4.0 PDC для клиентских машин, которые еще не переведены на Windows Server 2003. Одна из основных задач эмулятора PDC - регистрировать устаревшие клиенты. Кроме того, к эмулятору PDC происходит обращение, если аутентификация клиента оказалась неудачной.

    Хозяин RID отвечает за выделение диапазонов относительных идентификаторов (RID) всем контроллерам в домене. Идентификатор защиты (security identifier, SID) - уникальный идентификатор каждого объекта в домене. SID в Windows Server 2003 состоит из двух частей. Первая часть общая для всех объектов в домене; для создания уникального SID к этой части добавляется уникальный RID. Вместе они уникально идентифицируют объект в домене и указывают, где он был создан.

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

Планирование серверов глобального каталога

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

Раздел схемы. Хранит определения всех объектов, которые можно создать в лесу, а также их атрибутов. В лесу существует только один раздел схемы. Его копия реплицируется на все контроллеры доменов, входящие в лес.

Раздел конфигурации. Определяет структура доменов, сайтов и объектов-серверов Active Directory. В лесу существует только один раздел конфигурации. Его копия реплицируется на все контроллеры доменов, входящие в лес.

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

Другая функция глобального каталога, полезная независимо от того, сколько доме-нов в вашей сети, - участие в процессе аутентификации при входе пользователя в сеть. Когда пользователь входит в сеть, указывая имя участника системы безопасности (user principal name, UPN) вида [email protected] , оно сначала сверяется с содержимым глобального каталога. Это позволяет входить в сеть с компьютеров в доменах, отличных от того, где хранится нужная пользовательская учетная запись. Кроме того, это позволяет входить в сеть, когда контроллер домена недоступен, например из-за того, что не работает WAN -канал.

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

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

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

Определение требований к процессорам

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

Если пользователей меньше 500, контроллеру домена под управлением Windows Server 2003 достаточно одного процессора с тактовой частотой 850 МГц или выше.

Если количество пользователей находится в пределах от 500 до 1500, контроллеру домена под управлением Windows Server 2003 требуется два процессора с тактовой частотой 850 МГц или выше.

Если пользователей больше 1500, контроллеру домена под управлением Windows Server 2003 нужно четыре процессора с тактовой частотой 850 МГц или выше.

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

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

На диске, на который устанавливается ОС Windows Server 2003, должно быть примерно 2 Гб свободного дискового пространства.

Определив минимальный объем дискового пространства, необходимый контроллерам доменов, вы должны выделить дополнительное дисковое пространство на тех контроллерах домена, на которых будет храниться глобальный каталог. Если в лесу только один домен, назначение контроллеру домена роли сервера глобального каталога не приведет к увеличению размера БД. Однако, если в лесу более одного домена, для каждого дополнительного домена размер глобального каталога увеличивается приблизительно на 50% от размера базы данных этого домена.

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

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

Если пользователей меньше 500, контроллеру домена требуется 512 Мб памяти.

Если количество пользователей находится в пределах от 500 до 1000, контроллеру домена требуется 1 Гб памяти.

Если пользователей больше 1000, контроллеру домена требуется 2 Гб памяти.

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

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

Процесс репликации

Как вы уже знаете, в Windows Server 2003 используется модель репликации с несколькими хозяевами, при которой на всех контроллерах домена хранятся равноправные копии БД Active Directory. Когда вы создаете, удаляете или переносите объект либо изменяете его атрибуты на любом контроллере домена, эти изменения реплицируются на остальные контроллеры домена.

Внутрисайтовая и межсайтовая репликация

Внутрисайтовая (между контроллерами домена одного сайта) и межсайтовая репликация (между контроллерами домена, относящимися к разным сайтам) выполняется по-разному.

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

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

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

SMTP применяется при репликации между сайтами, не связанными постоянными соединениями (необходимыми для работы RPC). Одно из ограничений при использовании SMTP - он не позволяет реплицировать информацию раздела домена (domain partition information) на DC, входящие в домен. Поскольку SMTP применяется только при репликации между сайтами, проблем с репликацией информации раздела домена внутри домена не возникает (в этом случае автоматически используется RPC). То есть SMTP полезен лишь при репликации схемы и глобального каталога.

Как выполняется репликация

Каждый контроллер домена в сайте представляется объектом-сервером. У каждого объекта-сервера есть дочерний объект NTDS Settings, управляющий репликацией данных контроллера домена внутри сайта, а у каждого объекта NTDS Settings - объект-соединение, в котором хранятся атрибуты соединения и который представляет коммуникационный канал, применяемый при репликации данных с одного контроллера домена на другой. Для репликации нужно, чтобы на обеих сторонах было по объекту-соединению.

Сервис Knowledge Consistency Checker (КСС) автоматически создает набор объек-тов-соединений для репликации с одного контроллера домена на другой. Однако при необходимости можно создать объекты-соединения вручную.

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

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

Мосты связей сайтов (site-link bridges) - логические соединения, использующие связи сайтов в качестве транспорта. Когда транзитивность связей включена, между всеми сайтами автоматически создаются логические мосты связей сайтов. А когда транзитивность связей отключена, вы должны создавать такие мосты вручную. На рис. показана простая группа из четырех сайтов, соединенных связями по принципу карусели. Если транзитивность связей для этих сайтов отключена, вам придется вручную создать мосты связей сайтов, чтобы сделать возможной репликацию между всеми сайтами. В основном такие мосты служат для того, чтобы при отключенной транзитивности связей у каждого сайта был путь репликации к другим сайтам. Рассуждайте следующим образом. Когда транзитивность связей включена, между всеми связями сайтов имеются мосты, поэтому все сайты могут обмениваться данными репликации друг с другом. А когда транзитивность отключена, вы должны самостоятельно создать мосты, поскольку связаны только те сайты, между которыми вручную сконфигурированы связи. Мосты связей сайтов передают трафик репликации между соответствующими сайтами по цепочке из нескольких связей.

Назначение цен связям сайтов

Всем связям сайтов назначается цена, которая определяет, насколько данный путь лучше или хуже других связей. По умолчанию все связи имеют цену 100. Если одну связь сделать дороже другой, то при репликации (и при работе других приложений и служб, например Domain Controller Locator ) предпочтение будет отдаваться связи с меньшей ценой.

Серверы - плацдармы

Серверы - плацдармы

После создания связей сайтов КСС автоматически назначает один или несколько контроллеров в каждом домене на роль серверов-плацдармов (bridgehead servers) , или серверов репликации между сайтами.

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

Соединения репликации, создаваемые КСС, случайным образом распределяются между всеми серверами сайта, которые могут быть плацдармами репликации между сайтами, - это делается для распределения нагрузки по поддержке репликации. Обычно КСС распределяет соединения, только когда создаются новые объекты-соединения. Однако в Windows Server 2003 Resource Kit имеется утилита Active Directory Load Balancing (ADLB) , которую можно использовать для перераспределения ролей серверов-плацдармов в любое другое время (например, при добавлении новых контроллеров домена).

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

    Планирование DNS

    Планирование WINS

    Планирование инфраструктуры сети и маршрутизации

    Планирование подключения к Интернету

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

Итоги

Были рассмотрены вопросы связанные с технологией построение службы каталогов на базе AD реализованной в ОС Windows Server 2003

Active Directory - служба каталогов корпорации Microsoft для ОС семейства Windows NT.

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

В чем суть работы Active Directory и какие задачи она решает? Читайте дальше.

Принципы организации одноранговых и многоранговых сетей

Но возникает другая проблема, что если пользователь user2 на РС2 решит изменить свой пароль? Тогда если пользователь user1 сменит пароль учетной записи, доступ user2 на РС1 к ресурсу будет невозможен.

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

А если их будет не 20 а 200?

Как вы понимаете администрирование сети при таком подходе превращается в кромешный ад.

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

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

Этим узлом и выступает контролер домена - Active Directory.

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

Контролер хранит базу данных учетных записей, т.е. он хранит учетку и для РС1 и для РС2.

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

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

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

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

Число таких сохраненных ресурсов может достигать миллионов объектов.

В качестве контролера домена могут выступать следующие версии MS Windows : Windows Server 2000/2003/2008/2012 кроме редакций Web-Edition.

Контролер домена помимо того, что является центром аутентификации сети, также является центром управления всеми компьютерами.

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

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

Установка Active Directory

Рассмотрим пример установки Active Directory на Windows Server 2008 R2. Итак для установки роли Active Directory, заходим в «Server Manager»:

Добавляем роль «Add Roles»:

Выбираем роль Active Directory Domain Services:

И приступаем к установке:

После чего получаем окно уведомления, об установленной роли:

После установки роли контролера домена, приступим к установке самого контролера.

Нажимаем «Пуск» в поле поиска программ вводим название мастера DCPromo, запускаем его и ставим галочку для расширенных настроек установки:

Жмем «Next» из предложенных вариантов выбираем создание нового домена и леса.

Вводим имя домена, например, example.net.

Пишем NetBIOS имя домена, без зоны:

Выбираем функциональный уровень нашего домена:

Ввиду особенностей функционирования контролера домена, устанавливаем также DNS-сервер .

Для централизованного управления факультетской сетью необходимо создать домен на основе Microsoft Windows Server 2003.

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

Задание 1. Установить на сервере службу каталога Active Directory, создать домен mydomain.ru.

Указания к выполнению

1. Запустите мастер установки Active Directory Start – Run – dcpromo.

2. Следуя шагам мастера установки, выберите следующие параметры установки:

В окне Domain Controller Type (Тип контроллера домена) – переключатель Domain controller for a new domain (Контроллер домена в новом домене);

В окне Create New Domain (Создать новый домен ) – переключатель Domain in a new forest (Домен в новом лесу );

В окне Install or Configure DNS (Установка или настройка DNS ) – переключатель No, just install and configure DNS on this computer (Нет, DNS уже установлена и настроена на этом компьютере ), если служба DNS уже установлена на сервере, или Yes, I will configure the DNS client (Да, я буду конфигурировать клиента DNS) ;

В окне New Domain Name (Новое доменное имя ) наберите mydomain.ru в строке Full DNS Name For New Domain (Полное DNS-имя нового домена );

В окне NetBIOS Domain Name (Доменное имя NetBIOS ) должна появиться запись MYDOMAIN ;

Убедиться, что для размещения базы данных и протокола выбран путь C:\WINDOWS\NTDS , а для размещения каталога SYSVOL указан путь C:\WINDOWS\SYSVOL ;

В окне Permissions (Разрешения ) выберите Permissions compatible only with Windows 2000 or Windows Server 2003 operating systems (Разрешения, совместимые только с операционными системами Windows 2000 или Windows Server 2003 );

В окне Directory Services Restore Mode Administrator Password (Пароль администратора для режима восстановления) введите пароль, который хотите присвоить этой учетной записи сервера Administrator в случае, если компьютер загрузится в режиме Directory Services Restore (Режим восстановления);

В окне Summary (Сводка) изучите список выбранных вами параметров установки и дождитесь завершения процесса установки Active Directory.

3. В окне Completing The Active Directory Installation Wizard (Завершение работы мастера установки Active Directory), щелкните кнопку Finish (Готово), а затем кнопку Restart Now (Перезагрузить компьютер сейчас).

Задание 2 . Просмотреть созданный домен одним из способов.

Указания к выполнению

1-й способ.

Откройте My Network Places – Entire Network Microsoft Windows Network (Мое сетевое окружение – Вся сеть – сеть Microsoft Windows). Убедитесь, что появилась запись о домене mydomain, в котором содержится один компьютер – Server.

2-й способ.

1 В меню Start – Programs – Administrative Tools (Пуск – Программы – Администрирование) выберите Active Directory Users And Computers (Пользователи и компьютеры Active Directory). Откроется одноименная оснастка.



2 В дереве оснастки дважды щелкните на mydomain.ru (или на имени вашего домена), чтобы увидеть содержимое узла mydomain.ru.

3 В разделе Domain Controllers (Контроллеры домена) дерева оснастки просмотрите название контроллера домена и его полное имя DNS (например, если имя изолированного сервера было server, то после установки домена должно стать server.mydomain.ru).

4 В разделе Users (Пользователи) просмотрите список встроенных учетных записей пользователей и групп пользователей домена.

5 Активизируйте встроенную учетную запись Guest (Гость) и попробуйте войти в систему. Удалась ли попытка сделать это? На контроллеры домена разрешен вход только администраторам домена.

6 Закройте консоль Active Directory Users And Computers.

Задание 3. Проверить работу службы DNS с помощью оснастки DNS.

Указания к выполнению

1. Откройте консоль DNS командой Start – Programs – Administrative Tools – DNS (Пуск – Программы – Администрирование – DNS).

2. В дереве консоли DNS щелкните правой кнопкой по имени вашего сервера и выберите команду Properties (Свойства). Откроется окно свойств SERVER (если у сервера другое имя, то в заголовке окна будет значиться оно).

3. Перейдите на вкладку Monitoring (Наблюдение).

4. В списке Select A Test Type (Выберите тип теста) пометьте флажки A Simple Query Against This DNS Server (Простой запрос к этому DNS-серверу) и A Recursive Query To Other DNS Servers (Рекурсивный запрос к другим DNS-серверам) и щелкните Test Now (Протестировать). В окне свойств Server в списке результатов тестирования должна появиться надпись PASS (Пройден успешно) или FAIL (Не пройден) – в столбцах Simple Query (Простой запрос) и Recursive Query (Рекурсивный запрос). Объясните полученные результаты.

Задание 4. Удалить службу Active Directory.

Указания к выполнению

Запустите мастер установки и удаления Active Directory Start – Run – dcpromo.

Самостоятельная работа

Согласно заданию проекта установите домен с именем faculty.ru, где контроллером домена является server.faculty.ru, IP-адрес которого 192.168.1.1.



Вопросы для самоконтроля

1. Опишите различия между рабочей группой и доменом.

2. Каково основное различие между ОС Windows XP и Windows Server 2003?

3. Возможно ли создать домен в сети, где все компьютеры сети работают под управлением ОС Windows XP?

4. Дайте определение контроллера домена.

5. Перечислите известные Вам встроенные учетные записи пользователей и групп пользователей домена и опишите их назначение.

6. Что означает термин «изолированный» сервер?

7. Опишите различия между рабочей группой и доменом.

8. Почему встроенная учетная запись Guest (Гость), как правило, бывает отключена?

Литература


Лабораторная работа № 4

Тема: Создание и администрирование учетных записей пользователей и групп

Задание 1. Создайте доменную учетную запись декана:

– имеет доступ ко всем ресурсам сети,

– может осуществлять вход на любой компьютер.

Указания к выполнению

1. Выполните команду Start All Programs Administrative Tools Active Directory Users and Computers (Пуск Программы Администрирование Пользователи и компьютеры Active Directory) .

2. Раскройте папку faculty.ru Users (Пользователи) .

3. В меню Action (Действие ) выберите команду New User (Создать Пользователь) .

4. Введите необходимые сведения о пользователе. В разделе User logon name (Имя пользователя при входе в систему ) введите dean (декан) . Обратите внимание на то, что при создании доменной учетной записи, в отличие от локальной, после имени пользователя отображается имя домена, отделенное от последнего знаком @ . Таким образом, полное имя пользователя (User logon name) [email protected] .

5. При определении пароля пользователя обязательно установите флажок User must change password at next logon (Пользователь должен сменить пароль при следующем входе в систему ).

6. Завершите создание учетной записи.

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

8. Убедитесь в том, что декан может входить в систему в любое время (вкладка Account Logon Hours (Учетная запись Часы входа) ).

9. Попробуйте войти в домен под учетной записью декана. Почему попытка не удалась?

10. Зарегистрируйтесь в системе как администратор.

11. Посмотрите свойство учетной записи декана, снова выполнив команду Start All Programs Administrative Tools –. В окне свойств учетной записи выберите вкладку Member of (Членство в группах ) и добавьте учетную запись декана в глобальную группу Администраторы домена с помощью следующих команд Add… Advanced… Find now… (Добавить… Дополнительно… Найти…) из полученного списка выберите Domain Admins (Администраторы домена ).

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

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

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

Указания к выполнению

1. Выполните команду Start All Programs Administrative Tools Active Directory Users and Computers .

2. Раскройте папку faculty.ru в левой панели окна. Во вложенных папках выберите Users .

3. В правой панели найдите учетную запись. Дважды щелкните по ней, и перейдите на вкладку Member of (Членство в группах). Среди списка групп выберите Domain Admins и нажмите Remove .

Задание 3. Разрешить учетной записи декана осуществлять вход на контроллер домена, не включая его в группу администраторов.

Указания к выполнению

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

2. Войдите в домен под учетной записью декана

3. Предложите другой способ, разрешающий вход на контроллер домена.

Задание 4. Создайте глобальную группу Teachers (Преподаватели ):

– тип группы – группа безопасности;

– преподаватели могут осуществлять вход на любой компьютер сети, кроме сервера;

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

Указания к выполнению

1. Выполните команду Start All Programs Administrative Tools Active Directory Users and Computers .

2. Раскройте папку faculty.ru в левой панели окна. Во вложенных папках выберите Users .

3. В меню Action выберите команду New Group (Новое Группа) .

4. В поле Group Name (Имя группы ) введите Teachers .

5. В области Group Scope (Область действия группы ) щелкните переключатель Global (Глобальная) , а в области Group Type (Тип группы ) – переключатель Security (Безопасность) .

6. Щелкните OK.

Задание 5. Добавьте в группу Teachers (Преподаватели ) члена группы – учетную запись декана.

Указания к выполнению

1. Убедитесь, что открыта оснастка Active Directory Users and Computers и выбран контейнер Users .

2. В окне свойств группы Teachers выберите вкладку Members (Члены группы ), а затем последовательно кнопки Add… Advanced… Find now… из полученного списка выберите учетную запись декана.

3. В окне свойств учетной записи декана найдите информацию о членстве в группе Teachers .

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

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

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

Таблица 8

Планирование групп

Таблица 9

Расписание входа в систему

Таблица 10

Планирование паролей

@ Придумайте не менее трех пользователей из каждой группы и в соответствии с требованиями проекта заполните таблицы 8–10. Внесите таблицы в отчет.

Задание 8. Создайте в соответствии со своими вариантам таблиц 8–10 необходимые по заданию проекта учетные записи пользователей и групп пользователей.

Задание 9. Проведите тестирование учетных записей. Например, измените системное время на 6.00 и попытайтесь войти в домен под учетной записью студента. Попытайтесь сменить пароль данной учетной записи.

Вопросы для самоконтроля

1. Опишите различия между локальной и доменной учетными записями.

2. С какой целью создают группы пользователей?

3. Объясните назначение локальных, глобальных и универсальных групп.

4. Объясните назначение групп безопасности и групп распространения.

5. Дайте определение и приведите примеры для следующих терминов: «права пользователей», «привилегии пользователей», «разрешения доступа пользователей».

6. Перечислите известные Вам встроенные учетные записи пользователей и групп пользователей домена и опишите их назначение.

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

8. Как запретить вход в систему в выходные дни и нерабочее время?

9. Как ограничить срок действия учетной записи?

10. Как отключить учетную запись сотрудника, например, во время его болезни?

12. Как изменить пароль пользователя?

13. Как запретить изменение пароля пользователем?

14. Каковы последствия удаления группы?

Литература


Лабораторная работа №5