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

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-сервер .

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

Не секрет, что окончание поддержки Windows Server 2003 все ближе. День Х назначен на 17 июля 2015 года, а значит остается все меньше времени, чтобы успеть перевести свою инфраструктуру на более современные версии операционной системы. На Хабре мы уже делали несколько анонсов об окончании поддержки, на портале Microsoft Virtual Academy опубликован курс по материалам Jump Start , есть . В этой статье будет рассказано о миграции Active Directory и приведен пошаговый алгоритм, которым поможет вам при реализации переноса.

Перенос Active Directory с Windows Server 2003 на Windows Server 2012 R2 является одной из первоочередных задач, которые необходимо решить в процессе миграции.
На самом деле, перенос Active Directory не несет в себе каких-либо сложностей. Нужно выполнить лишь несколько шагов, о которых будет подробно рассказано далее.
Сначала выполним небольшую настройку на контроллере домена с установленной на нем Windows Server 2003. Обязательно проверьте, что для существующего домена и леса в качестве режима работы (functional level) выбран Windows Server 2003.
Для того, что изменить режим работы домена и леса необходимо запустить оснастку Active Directory Domains and Trust. Для изменения режима работы домена щёлкаем правой кнопкой мыши по домену, для режима работы леса – по Active Directory Domains and Trusts. Выбираем Raise Domain Functional Level и Raise Forest Functional Level соответственно.




В обоих случаях режим работы должен быть установлен на Windows Server 2003.




Следующим шагом нам нужно добавить к нашей сети второй контроллер домена под управлением Windows Server 2012 R2. Для этого на сервер с Windows Server 2012 R2 устанавливаем роль Active Directory Domain Services.


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


Необходимо указать, будет ли этот сервер выполнять роль DNS сервера и глобального каталога (Global Catalog – GC).


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


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


Далее нужно дождаться завершения установки и перезагрузить компьютер. В итоге, вы получите контроллер домена с установленной на нем Windows Server 2012 R2.
Теперь в оснастке Active Directory Users and Computers мы можем увидеть, что в нашей сети есть два контроллера домена.

После того, как выполнены предварительные шаги, мы можем перейти непосредственно к переносу Active Directory. Выполнять необходимые действия мы будем на контроллере домена под управлением Windows Server 2012 R2 в следующем порядке:

1. Перенос роли FSMO (Flexible Single Master Operations)
2. Изменение контроллера домена Active Directory
3. Изменение Мастера схемы (Schema Master)
4. Удаление контроллера домена под управлением Windows Server 2003 из глобального каталога (Global Catalog)

1. Перенос роли FSMO (Flexible Single Master Operations)

Для того, чтобы перенести роль FSMO, открываем оснастку Active Directory Users and Computers , щёлкаем правой кнопкой мышки по нашему домену и в появившемся подменю выбираем Operations Masters .


Нам нужно перенести роль хозяина операций. Для этого на каждой вкладке во вновь появившемся окне нажимаем кнопку Change и переносим роль с 2003 сервера на сервер под управлением 2012 R2.


Подтверждаем операцию переноса и дожидаемся ее благополучного завершения. Не забудьте проверить, что в итоге роль хозяина операций теперь находится на сервере под управлением Windows Server 2012 R2:

2. Изменение контроллера домена Active Directory

Теперь переходим к изменению контроллера домена Active Directory. Открываем консоль Active Directory Domains and Trusts , щёлкаем правой кнопкой мышки по лесу и выбираем пункт Change Active Directory Domain Controller .


В новом окне выберите пункт This Domain Controller or AD LDS instance и укажите сервер под управлением Windows Server 2012 R2.


Теперь снова щёлкаем правой кнопкой мышки по лесу и выбираем пункт Operations Master.


Переноси роль хозяина операций именования домена, нажав Change .

3. Изменение Мастера схемы (Schema Master)

Теперь приступаем к изменению мастера схемы (Schema Master). Запустите командную строку с правами Администратора и введите команду regsvr32 schmmgmt.dll


С помощью этой команды происходит первичная регистрация динамической библиотеки DLL, которая является обязательной для оснастки Active Directory Schema.
После того, как команда выполнена, можно закрыть командную строку, запустить консоль MMC и добавить оснастку Active Directory Schema (для этого выберите File > Add / Remove Snap - in ).


В этой же консоли MMC щёлкаем правой кнопкой мыши по Active Directory Schema и выбираем Change Active Directory Domain Controller. Аналогично действиям, которые мы выполняли в пункте 2, в новом окне выберите пункт This Domain Controller or AD LDS instance и укажите сервер под управлением Windows Server 2012 R2 и нажмите ОК . Появится предупреждение о том, что оснастка схемы Active Directory не подключена. Нажмите ОК для продолжения.
Теперь снова щёлкаем правой кнопкой мышки по лесу и выбираем пункт Operations Master . Для переноса роли хозяина схемы в новом окне нажмите Change .
Теперь можно закрыть MMC консоль, открыть оснастку Active Directory Users and Computers и убедиться, что данные успешно реплицированы на ваш новый сервер под управлением Windows Server 2012 R2. Имейте ввиду, что процесс репликации может занять некоторое время (все зависит от количества объектов Active Directory, которые нужно реплицировать).

4. Удаление контроллера домена под управление Windows Server 2003 из глобального каталога (Global Catalog)

Осталось удалить контроллер домена под управлением Windows Server 2003 из глобального каталога. Для этого открываем Active Directory Sites and Services, разворачивает папку Sites, затем Default-First-Site-Name, затем Servers и, наконец, разворачиваем оба сервера.


Щёлкните правой кнопкой мышки по NTDS Settings для вашего старого сервера под управление Windows Server 2003, выберите Properties . Во вновь появившемся окне уберите галочку с пункта Global Catalog и нажмите ОК .

В Active Directory Users and Computers контроллер домена на Windows Server 2003 теперь не является глобальным каталогом.


Осталось проверить, что теперь роль FSMO запущена на Windows Server 2012 R2. Для этого в командной строке, открытой с правами Администратора запускаем команду netdom query fsmo


На этом миграция Active Directory завершена. На компьютере под управлением Windows Server 2003 запустите dcpromo (кстати, в Windows Server 2012 R2 dcpromo нет) для того, чтобы понизить роль компьютера с контроллера домена. Если после этого посмотреть на консоль Active Directory Users and Computers, вы увидите, что остался только один контроллер домена – под управлением Windows Server 2012 R2.

Надеюсь, что эта статья будем вам полезной!

Основные сведения о доменах Active Directory

Короче говоря, AD позволяет использовать единую точку администрирования для всех публикуемых ресурсов. В основе AD используется стандарт именования X.500, система доменных имён – Domain Name System (DNS) для определения местоположения, и в качестве основного протокола используется Lightweight Directory Access Protocol (LDAP).

AD объединяет логическую и физическую структуру сети. Логическая структура AD состоит из следующих элементов:

• организационное подразделение (organizational unit) – подгруппа компьютеров, как правило, отражающая структуру компании;
• домен (domain) – группа компьютеров, совместно использующих общую базу данных каталога;
• дерево доменов (domain tree) – один или несколько доменов, совместно использующих непрерывное пространство имен;
• лес доменов (domain forest) – одно или несколько деревьев, совместно использующих информацию каталога.

К физической структуре относятся следующие элементы:

• подсеть (subnet) – сетевая группа с заданной областью IP-адресов и сетевой маской;
• сайт (site) – одна или несколько подсетей. Сайт используется для настройки доступа к каталогу и для репликации.

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

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

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

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

В каждом лесе AD существуют следующие роли:

• Хозяин схемы (schema master) – управляет обновлениями и изменениями схемы каталога. Для обновления схемы каталога необходим доступ к хозяину схемы. Чтобы определить, какой сервер в данное время является хозяином схемы в домене, нужно в окне командной строки набрать команду dsquery server -hasfsmo schema
• Хозяин именования доменов (domain naming master) – управляет добавлением и удалением доменов в лесу. Чтобы добавить или удалить домен требуется доступ к хозяину именования доменов. Чтобы определить, какой сервер в данное время является хозяином именования доменов, в окне командной строки введите dsquery server -hasismo name

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

В каждом домене AD обязательно существуют следующие роли:

• Хозяин относительных идентификаторов (relative ID master) – выделяет относительные идентификаторы контроллерам доменов. Каждый раз при создании объекта пользователя, группы, или компьютера, контроллеры назначают объекту уникальный идентификатор безопасности, состоящий из идентификатора безопасности домена и уникального идентификатора, который был выделен хозяином относительных идентификаторов. Чтобы определить, какой сервер в данное время является хозяином относительных идентификаторов домена, в командной строке введите dsquery server -hasfsmo rid
• Эмулятор PDC (PDC emulator) – в смешанном или промежуточном режиме домена действует как главный контроллер домена Windows NT. Он аутентифицирует вход в Windows, обрабатывает изменения пароля и реплицирует обновления на BDC, если они есть. Чтобы определить, какой сервер в данное время является эмулятором PDC домена, в командной строке введите dsquery server -hasfsmo pdc
• Хозяин инфраструктуры (infrastructure master) – обновляет ссылки объектов, сравнивая данные своего каталога с данными GC. Если данные устарели, он запрашивает из GC обновления и реплицирует их на остальные контроллеры домена. Чтобы определить, какой сервер в данное время является хозяином инфраструктуры домена, в командной строке введите dsquery server -hasfsmo infr

Эти роли, общие для всего домена и должны быть в нем уникальны.

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

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

Инсталляция контроллера домена (DC) на базе Windows Server 2003 с помощью мастера установки Active Directory

Установка контроллера домена производится с помощью мастера Active Directory Installation Wizard. Чтобы повысить статус сервера до контроллера домена необходимо убедиться в выполнении всех необходимых для этого требований:

1. На сервере должен быть хотя бы один раздел NTFS для размещения системного тома SYSVOL.
2. Сервер должен иметь доступ к DNS серверу. Желательно установить службу DNS на этом же сервере. Если используется отдельный сервер, то необходимо убедиться, что он поддерживает ресурсные записи Service Location (RFC 2052) и протокол Dynamic Updates (RFC 2136).
3. Необходимо иметь учётную запись с правами локального администратора на сервере.

Рассмотрим подробно повышение роли сервера до контроллера домена Active Directory по шагам:

1. Чтобы запустить мастер повышения статуса сервера необходимо в меню Start (Пуск) выбрать Run… (Выполнить…), ввести dcpromo и нажать OK.
2. После запуска мастера установки Active Directory нажмите Next (Далее).
3. На странице Domain Controller Type (Тип контроллера домена) выберите вариант Domain controller for a new domain (Контроллер домена в новом домене). Нажмите Next .

   
   

4. На странице Create New Domain (Создать новый домен) выберите вариант Domain in a new forest (Новый домен в новом лесу). Нажмите Next .
5. На странице New Domain Name (Новое имя домена) введите полное (FQDN) DNS-имя для создаваемого нового домена леса Active Directory (например, mydomain.local). Не рекомендуется использовать одиночное (single label) имя домена (например, mydomain). Нажмите Next .
6. Проверьте NetBIOS-имя на странице NetBIOS Domain Name (NetBIOS-имя домена). Хотя домены Active Directory обозначаются в соответствии со стандартами именования DNS, необходимо так же задать NetBIOS-имя. NetBIOS-имена по возможности должны совпадать с первой меткой DNS-имени домена. Если первая метка DNS-имени домена Active Directory отличается от его NetBIOS-имени, в качестве полного доменного имени используется DNS-имя, а не NetBIOS-имя. Нажмите Next .
7. На странице Database and Log Folders (Папки базы данных и журналов) введите путь, по которому будут располагаться папки базы данных и журналов, или нажмите кнопку Browse (Обзор), чтобы указать другое расположение. Убедитесь, что на диске достаточно места для размещения базы данных каталога и файлов журналов, чтобы избежать проблем при установке или удалении Active Directory. Мастеру установки Active Directory необходимо 250 МБ дискового пространства для установки базы данных Active Directory и 50 МБ для файлов журналов. Нажмите Next .
8. На странице Shared System Volume (Общий доступ к системному тому) укажите расположение, в которое следует установить папку SYSVOL, или нажмите кнопку Browse (Обзор), чтобы выбрать расположение. Папка SYSVOL должна находиться на томе NTFS, так как в ней находятся файлы, реплицируемые между контроллерами домена в домене или лесу. Эти файлы содержат сценарии, системные политики для Windows NT 4.0 и более ранних версий, общие папки NETLOGON и SYSVOL и параметры групповой политики. Нажмите Next .
9. На странице DNS Registration Diagnostics (Диагностика регистрации DNS) проверьте правильность установки параметров. Если в окне Diagnostic Results (Результаты диагностики) отображается сообщение об ошибках диагностики, нажмите кнопку Help (Справка) для получения дополнительных инструкций по устранению ошибки. Нажмите Next .
10. На странице Permissions (Разрешения) выберите требуемый уровень совместимости приложений с операционными системами pre-Windows 2000, Windows 2000 или Windows Server 2003. Нажмите Next .
11. На странице Directory Services Restore Mode Administrator Password (Пароль администратора для режима восстановления) введите и подтвердите пароль для учетной записи администратора режима восстановления Active Directory для данного сервера. Этот пароль необходим для восстановления резервной копии состояния системы данного контроллера домена в режиме восстановления Active Directory. Нажмите Next .
12. Проверьте сведения на странице Summary (Сводка) и нажмите Next .
13. После завершения установки нажмите кнопку Finish (Готово). Для перезагрузки компьютера нажмите кнопку Restart Now (Перезагрузить сейчас), чтобы изменения вступили в силу.

Основы управления доменом Active Directory

Ряд средств в оснастках Microsoft Management Console (MMC) упрощает работу с Active Directory.

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

Для запуска оснастки Active Directory Users and Computers (Active Directory – пользователи и компьютеры) выберите одноименную команду в меню Administrative Tools (Администрирование).

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

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

• Saved Queries (Сохраненныезапросы) – сохраненные критерии поиска, позволяющие оперативно повторить выполненный ранее поиск в Active Directory;
• Builtin – список встроенных учетных записей пользователей;
• Computers – контейнер по умолчанию для учетных записей компьютеров;
• Domain Controllers – контейнер по умолчанию для контроллеров домена;
• ForeignSecurityPrincipals – содержит информацию об объектах из доверенного внешнего домена. Обычно эти объекты создаются при добавлении в группу текущего домена объекта из внешнего домена;
• Users – контейнер по умолчанию для пользователей.

Некоторые папки консоли по умолчанию не отображаются. Чтобы вывести их на экран, выберите в меню View (Вид) команду Advanced Features (Дополнительные функции). Вот эти дополнительные папки:

• LostAndFound – потерявшие владельца, объекты каталога;
• NTDS Quotas – данные о квотировании службы каталогов;
• Program Data – сохраненные в службе каталогов данные для приложений Microsoft;
• System – встроенные параметры системы.

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

OU

Рассмотрим пример создания учётной записи пользователя домена. Чтобы создать учётную запись пользователя щелкните правой кнопкой контейнер, в который вы хотите поместить учетную запись пользователя, выберите в контекстном меню New (Создать), а затем – User (Пользователь). Откроется окно мастера New Object – User (Новый объект – Пользователь):

1. Введите имя, инициал и фамилию пользователя в соответствующих полях. Эти данные потребуются для создания отображаемого имени пользователя.
2. Отредактируйте полное имя. Оно должно быть уникальным в домене и иметь длину не более 64 символов.
3. Введите имя для входа. С помощью раскрывающегося списка выберите домен, с которым будет связана учетная запись.
4. При необходимости измените имя пользователя для входа в системы с ОС Windows NT 4.0 или более ранними версиями. По умолчанию в качестве имени для входа в системы с предыдущими версиями Windows используются первые 20 символов полного имени пользователя. Это имя также должно быть уникальным в домене.
5. Щёлкните Next (Далее). Укажите пароль для пользователя. Его параметры должны соответствовать вашей политике паролей;
   Confirm Password (Подтверждение) – поле, используемое для подтверждения правильности введенного пароля;
   User must change password at next logon (Требовать смену пароля при следующем входе в систему) – если этот флажок установлен, пользователю придется изменить пароль при следующем входе в систему;
   User cannot change password (Запретить смену пароля пользователем) – если этот флажок установлен, пользователь не может изменить пароль;
   Password never expires (Срок действия пароля не ограничен) – если этот флажок установлен, время действия пароля для этой учетной записи не ограничено (этот параметр перекрывает доменную политику учетных записей);
   Account is disabled (Отключить учетную запись) – если этот флажок установлен, учетная запись не действует (параметр удобен для временного запрета использования кем-либо этой учетной записи).

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

Сценарии входа определяют команды, выполняемые при каждом входе в систему. Они позволяют настроить системное время, сетевые принтеры, пути к сетевым дискам и т.д. Сценарии применяются для разового запуска команд, при этом параметры среды, задаваемые сценариями, не сохраняются для последующего использования. Сценариями входа могут быть файлы сервера сценариев Windows с расширениями.VBS, .JS и другие, пакетные файлы с расширением.ВАТ, командные файлы с расширением.CMD, программы с расширением.ЕХЕ.

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

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

• создавать централизованно управляемые специальные папки, например My Documents (Мои документы);
• управлять доступом к компонентам Windows, системным и сетевым ресурсам, инструментам панели управления, рабочему столу и меню Start (Пуск);
• настроить сценарии пользователей и компьютеров на выполнение задачи в заданное время;
• настраивать политики паролей и блокировки учетных записей, аудита, присвоения пользовательских прав и безопасности.

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

Оснастка Active Directory Domains and Trusts (Active Directory – домены и доверие) служит для работы с доменами, деревьями доменов и лесами доменов.

Оснастка Active Directory Sites and Services (Active Directory – сайты и службы) позволяет управлять сайтами и подсетями, а так же межсайтовой репликацией.

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

• Dsadd – добавляет в Active Directory компьютеры, контакты, группы, организационные подразделения и пользователей. Для получения справочной информации введите dsadd /? , например dsadd computer/?
• Dsmod – изменяет свойства компьютеров, контактов, групп, организационных подразделений, пользователей и серверов, зарегистрированных в Active Directory. Для получения справочной информации введите dsmod /? , например dsmod server /?
• Dsmove – перемещает одиночный объект в новое расположение в пределах домена или переименовывает объект без перемещения.
• Dsget – отображает свойства компьютеров, контактов, групп, организационных подразделений, пользователей, сайтов, подсетей и серверов, зарегистрированных в Active Directory. Для получения справочной информации введите dsget /? , например dsget subnet /?
• Dsquery – осуществляет поиск компьютеров, контактов, групп, организационных подразделений, пользователей, сайтов, подсетей и серверов в Active Directory по заданным критериям.
• Dsrm – удаляет объект из Active Directory.
• Ntdsutil – позволяет просматривать информацию о сайте, домене или сервере, управлять хозяевами операций (operations masters) и обслуживать базу данных Active Directory.

Так же существуют средства поддержки Active Directory:

• Ldp – Осуществляет в Active Directory Administration операции по протоколу LDAP.
• Replmon – Управляет репликацией и отображает ее результаты в графическом интерфейсе.
• Dsacls – Управляет списками ACL (списками управления доступом) для объектов Active Directory.
• Dfsutil – Управляет распределенной файловой системой (Distributed File System, DFS) и отображает сведения о её работе.
• Dnscmd – Управляет свойствами серверов, зон и записей ресурсов DNS.
• Movetree – Перемещает объекты из одного домена в другой.
• Repadmin – Управляет репликацией и отображает её результаты в окне командной строки.
• Sdcbeck – Анализирует распространение, репликацию и наследование списков управления доступом.
• Sidwalker – Задает списки управления доступом для объектов, в прошлом принадлежавших перемещенным, удаленным или потерянным учетным записям.
• Netdom – Позволяет управлять доменами и доверительными отношениями из командной строки.

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

Иходная ситуация - существует домен, testcompany.local . Для упрощения в нем будет один контроллер домена под Windows Server 2003, с именем dc01 . DNS-сервер также на нем, основная зона интегрирована в Active Directory.

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

IP-адрес - 192.168.1.11
Маска - 255.255.255.0
Шлюз - 192.168.1.1
DNS-сервер - 192.168.1.11

Задача - установить контроллер домена на другом сервере, причем работающем под Windows Server 2008 R2, старый контроллер понизить до рядового сервера (а затем возможно, удалить вообще), а все функции старого контроллера передать новому.

Подготовительные работы

В качестве подготовительных работ следует запустить команды netdiag (эта команда существует только в 2003 Server, Support Tools) и dcdiag , убедиться в отсутствии ошибок, а при их наличии исправить эти ошибки.

В первую очередь определяем держателя FSMO-ролей в домене, командой:

Утилита netdom.exe в состав Windows Server 2003 по умолчанию не входит, поэтому нужно установить Support Tools (http://support.microsoft.com/kb/926027). В рассматриваемом случае от нее смысла никакого нет, так как контроллер домена всего один и роли FSMO все равно все на нем. Тем же, у кого контроллеров домена больше одного, это будет полезно, чтобы знать, какие именно роли и откуда переносить. Результат команды будет примерно таким:

IP-адрес - 192.168.1.12
Маска - 255.255.255.0
Шлюз - 192.168.1.1
DNS-сервер - 192.168.1.11

и вводим его в существующий домен, testcompany.local в нашем случае.

Обновление схемы леса и домена

Следующий этап - обновление схемы леса и домена до Windows Server 2008 R2, что мы будем делать с помощью утилиты adprep . Вставляем установочный диск с Windows Server 2008 R2 в сервер dc01 . На диске нас интересует папка X:\support\adprep (X: - буква диска DVD-ROM). Если windows Server 2003 у вас 32-х битная, следует запускать запускать adprep32.exe, в случае 64-х битной - adprep.exe .

Для выполнения команды никаких требований к функциональному режиму леса нет. Для выполнения команды adprep /domainprep требуется, чтобы в домене использовался функциональный уровень домена не ниже Windows 2000 native.

Вводим команду:

X:\support\adprep>adprep32.exe /forestprep

После предупреждения о том, что все контроллеры домена Windows 2000 должны быть минимум с SP4 вводим С и нажимаем Enter:

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

Adprep successfully updated the forest-wide information.

После этого вводим команду:

X:\support\adprep>adprep32.exe /domainprep /gpprep

Которая отработает не в пример быстрее:

Также стоит выполнить команду adprep /rodcprep . Даже если вы и не собираетесь использовать в вашей сети контроллеры домена только для чтения (Read Only Domain Controller - RODC), эта команда как минимум уберет ненужные сообщения об ошибках в журнале событий.

После завершения действия команд по обновлению схемы можно приступать к повышению роли нового сервера до контроллера домена.
На сервере dc02 заходим в Server Manager, добавляем роль Active Directory Domain Services . После установки роли, зайдя в Server Manager > Roles > Active Directory Domain Services, мы увидим желтую подсказку «Run the Active Directory Domain Services Installation Wizard (dcpromo.exe )». Ее и запускаем. Либо можно в командной строке набрать dcpromo , что будет равноценно вышеприведенному действию.

Так как освещение процесса установки контроллера домена в эту статью не входит, остановлюсь лишь на некоторых ключевых моментах. На шаге Additional Domain Controller Options поставьте обе галки, DNS Server и Global catalog .

Если галку Global Catalog и DNS Server не поставить, придется их переносить отдельно. А при миграции с 2003 на 2003 это придется делать в любом случае, так как в Windows 2003 такой возможности нет. О переносе глобального каталога и DNS-сервера будет немного ниже.

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

Передача ролей FSMO

Передачу ролей FSMO можно производить как через графический интерфейс, так и с помощью утилиты ntdsutil.exe . В этой статье будет описан способ с использованием графического интерфейса, как более наглядный, кого интересует другой способ, он по этой ссылке: http://support.microsoft.com/kb/255504 . Передача ролей FSMO будет состоять из следующих шагов:

Заходим на сервер dc02 , на тот, на который будем передавать роли. Для того, чтобы получить доступ к оснастке Active Directory Schema , сначала необходимо зарегистрировать библиотеку schmmgmt.dll . Это делается с помощью команды:

regsvr32 schmmgmt.dll

В дереве оснастки нужно щелкнуть правой кнопкой мыши элемент Active Directory Schema и выбрать пункт Change Domain Controller . Там меняем контроллер на dc02 .
Далее опять нажимаем правой кнопкой мыши элемент Active Directory Schema и выбираем пункт Operations Master . Появляется вот такое окно:

Нажимаем Change > Yes > OK и закрываем все эти окна.

Открываем оснастку , щелкаем правой кнопкой мыши элемент Active Directory Domains and Trusts и выбираем команду Change Active Directory Domain Controller . Это действие необходимо, если работа ведется не с контроллера домена, которому передается роль. Пропустите его, если подключение к контроллеру домена, чья роль передается, уже установлено. В открывшемся окне выбираем контроллер домена, которому присваивается роль (dc02 в нашем случае), в списке и нажимаем кнопку ОК .
В оснастке щелкаем правой кнопкой мыши элемент Active Directory Domains and Trusts и выбираем пункт Operations Master . В появившемся окне нажимаем кнопку Change .

Чтобы подтвердить передачу роли, нажимаем кнопку ОК , а затем - Close .

Открываем оснастку . Щелкаем правой кнопкой мыши элемент Active Directory Users and Computers и выбираем команду Change Domain Controller . Пропустите его, если подключение к контроллеру домена, чья роль передается, уже установлено. В открывшемся окне выбираем контроллер домена, которому присваивается роль (dc02 в нашем случае), в списке и нажимаем кнопку ОК.

В оснастке щелкаем правой кнопкой мыши элемент Active Directory Users and Computers , выбираем пункт All Tasks , а затем Operations Master .

Выбираем вкладку, соответствующую передаваемой роли (RID , PDC или Infrastructure Master ), и нажимаем кнопку Change .
Чтобы подтвердить передачу роли, нажимаем кнопку ОК , а затем - Close .

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

Если мы делаем миграцию не на 2008, а на 2003, в котором при добавлении добавочного контроллера домена глобальный каталог не ставиться, либо вы не поставили галку Global Catalog в шаге 2, тогда нужно назначить роль глобального каталога новому контроллеру домена вручную. Для этого, заходим в оснастку Active Directory Sites and Services , ракрываем Sites > сайт Default-First-Site-Name > Servers > DC02 > щелкаем правой кнопкой мыши по NTDS Settings > Properties. В открывшемся окне ставим галку Global Catalog > OK.

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

Event Type: Information
Event Source: NTDS General
Event Category: (18)
Event ID: 1110
Date: 12.07.2011
Time: 22:49:31
User: TESTCOMPANY\Administrator

Description:
Promotion of this domain controller to a global catalog will be delayed for the following interval.

Interval (minutes):
5

This delay is necessary so that the required directory partitions can be prepared before the global catalog is advertised. In the registry, you can specify the number of seconds that the directory system agent will wait before promoting the local domain controller to a global catalog. For more information about the Global Catalog Delay Advertisement registry value, see the Resource Kit Distributed Systems Guide.

http://go.microsoft.com/fwlink/events.asp .

Ждем пять минут и дожидаемся события 1119 о том, что этот контроллер стал глобальным каталогом.

Event Type: Information
Event Source: NTDS General
Event Category: (18)
Event ID: 1119
Date: 12.07.2011
Time: 22:54:31
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: dc02.testcompany.local
Description:
This domain controller is now a global catalog.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp .

Перенастройка интерфейсов, DNS и другие послеустановочные задачи

Далее, так как DNS-сервер на dc02 мы установили, теперь нужно в свойствах сетевого интерфейса первичным DNS-сервером указать самого себя, т.е. адрес 192.168.1.12. И на dc01 соответственно поменять на 192.168.1.12.

В свойствах DNS-сервера на dc02 проверьте вкладку Forwarders , на 2003, в отличие от 2008, она не реплицируется. После этого можно понижать контроллер домена dc01 до рядового сервера.

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

После смены IP-адреса выполните команды ipconfig /registerdns и dcdiag /fix .