Что такое Active Directory? - Информационная система
advertisement
Управление структурой информационной системы предприятия на основе Active directory Что такое Active Directory? Active Directory (AD) является мощнейшей службой каталога операционной системы (NOS) Windows Server 2003/2000, предназначенной для управления пользователями, группами и сетевыми ресурсами. Она позволяет системному администратору эффективно управлять различной информацией, распределенной в глобальном масштабе, через центральный репозиторий. Достаточно однократно добавить информацию о пользователях, группах, компьютерах и принтерах, приложениях и сервисах, в службу AD, чтобы она стала доступна именно тем категориям пользователям, которым она должна быть доступна. При этом структура представления информации будет соответствовать структуре организации и пользователи могут с легкостью обнаружить в AD информацию о коллеге из другого отдела или общем принтере своего отдела. С помощью объектов класса Organizational Unit вы можете распределять функции управления и контроля именно так, как это необходимо. AD поддерживает возможность управления очень большим количеством объектов. Полностью интегрированная в Windows 2003 Server, служба Active Directory обеспечивает иерархическое представление объектов. Она расширяема, масштабируема и обладает распределенной системой безопасности. Active Directory позволяет администраторам, разработчикам и конечным пользователям получить доступ к службе каталога, прозрачно интегрированной как в глобальную, так и корпоративную среду. Active Directory — важная часть распределенных систем и позволяет конечным пользователям и администраторам обращаться к службе каталогов как источнику информации и решать с ее помощью административные задачи. Active Directory объединяет концепцию пространства имен Интернета со службой каталога ОС. Пространство имен (namespace) — это структурированная совокупность данных, в которой для символического представления информации применяются имена; порядок создания и использования этих имен регулируется правилами именования. Объединение концепции пространства имен и службы каталогов позволяет унифицированно управлять пространствами имен в разнородных программных и аппаратных средах корпоративных сетей. Основным протоколом в Active Directory является LDAP, способный взаимодействовать с различными ОС, включающими независимые пространства имен. Протокол LDAP позволяет управлять каталогами других приложений, а также каталогами сетевых ОС, что упрощает администрирование и снижает стоимость обслуживания множества пространств имен. Active Directory не является каталогом Х.500 — роль протокола доступа играет LDAP, поддерживается и информационная модель Х.500, но без свойственной ей избыточности. Стандарт на службу каталогов X.500 был разработан изначально для организации публичных справочников общего доступа, позволяющий хранить информацию из любой области человеческих знаний. Он представляет собой набор рекомендаций комитета CCITT/ITU, описывающих исключительно принципы построения и форматы данных для взаимодействия систем, предоставляющих сервисы поиска в глобальных хранилищах информации. Выбор средств реализации полностью возлагается на разработчика. Существуют две редакции этих рекомендаций - 1988 и 1992 года. Этим достигается высокий уровень совместимости с существующими разнородными сетями. История появления AD Сердцем Windows NT NOS является база данных SAM (Security Accounts Management - управление безопасными учетными записями). Она представляет центральную базу данных учетных записей, включающую все учетные записи пользователей и групп в домене. Эти учетные записи используются для управления доступом к совместным ресурсам, принадлежащим любому серверу в домене Windows NT. В SAM было много ограничений, поэтому данная система не очень хорошо поддавалась масштабированию. Поскольку все администраторы домена Windows NT 4 имеют, по существу, неограниченные административные привилегии, создание отдельных доменов было единственным методом установления границ администрирования. Однако в пределах домена все администраторы имели полный контроль над серверами и службами, которые на них выполнялись. Создание дополнительных доменов не было привлекательным методом, поскольку каждый новый домен требовал дополнительных серверных аппаратных средств, что приводило к увеличению административных накладных расходов. По мере роста количества доменов в организации обеспечение уверенности относительно доверительных отношений, которые делали возможным пользовательскую идентификацию для доступа к ресурсам внешних доменов, также приводило к росту накладных расходов. Чтобы справиться с этой растущей сложностью доменов и доверительных отношений, сетевые администраторы реализовывали одну из четырех доменных моделей: отдельный домен (single domain), домен с одним хозяином (master domain), домен с несколькими хозяевами (multiple master domain, или multimaster) и отношения полного доверия (complete trust). При поддержке этих доменных моделей самые большие административные хлопоты состояли в необходимости создания и сопровождения большого количества доверительных отношений. Это было не просто, потому что все доверительные отношения между доменами Windows NT 4 должны были создаваться с двух сторон, т.е. в обоих доменах на концах доверительных отношений. Разрабатывая следующую версию NOS-систем Windows, компания Microsoft рассматривала службу каталога Exchange Server в качестве модели для будущей реализации службы каталога. Дополнительная выгода от развития сетевой службы каталога на базе существующей службы каталога Exchange Server состояла в том, что в будущих выпусках Exchange Server могла бы быть общая платформа службы каталога, которая обслуживала бы и сетевую среду, и среду Exchange Server. Эта цель была достигнута с выпуском Windows 2000. Устойчивая служба каталога Active Directory, которая скромно начиналась как служба каталога Exchange Server версии 4, была в итоге выпущена с Windows 2000. Служба Active Directory заменила базу данных SAM в качестве службы каталога для сетевых сред от Microsoft. Эта новая реализация службы каталога была направлена на преодоление ограничений службы Windows NT 4 SAM и обеспечивала дополнительные выгоды сетевым администраторам. Главная выгода Active Directory в реализации Windows 2000 состоит в том, что она масштабируема. Новый файл базы данных учетных записей может достигать 70 Тб, что является весомым усовершенствованием по сравнению с лимитом SAM в 40 Мб. Самая последняя, улучшенная и усовершенствованная, версия Active Directory, представленной в Windows 2000, является компонентом всех членов семейства Windows Server 2003 за исключением Web Edition, которая не нуждается в компоненте Active Directory и не реализует его. Служба Active Directory семейства Windows Server 2003 предлагает сетевым администраторам масштабируемость, возможности доступа и функциональность, необходимые для управления инфраструктурой службы каталога вычислительной среды современных предприятий. Чтобы удовлетворить растущие запросы службы каталога в неизменно плюралистической вычислительной среде современного предприятия, Microsoft должен был включить открытые вычислительные стандарты в свои NOS и в свою реализацию службы каталога. Представляется все более вероятным, что, в конечном счете, серверное пространство средних и больших организаций будет содержать разнообразные системы NOS, выполняющиеся на различных типах серверных аппаратных средств. Серверное пространство может включать серверы Windows и Novell Netware, выполняющиеся на платформах Intel, UNIX-платформы, выполняющиеся на базе аппаратных средств RISC (компьютеры с сокращенным набором команд), и серверы рабочих групп семейства Linux, выполняющиеся на любых платформах, к которым могут приложить руки администраторы. Для реализации этих систем NOS должны взаимодействовать с помощью общего языка или языков. Потребность в общих языках является основой для вычислительной техники открытых стандартов. Вместо напряженных усилий, прилагаемых в рамках старой парадигмы однородной серверной среды, использующей закрытые (лицензированные) реализации службы каталога, вычислительная среда современных предприятий стремится быть объединенной сетевой службой. Рассмотрим пару открытых стандартов, на которых основана Active Directory: иерархия пространства имен Х.500 и протокол LDAP. Иерархии Х.500 Стандарт пространства имен Х.500 (namespace) определяет то, как объекты сохраняются в Active Directory. Пространство имен Х.500 представляет собой иерархическую структуру имен, которая идентифицирует уникальный путь к контейнеру службы каталога. Он обеспечивает также уникальный идентификатор для каждого объекта в этом контейнере. Используя имя в стандарте Х.500 или идентификатор объекта (OID -Object Identifier), все объекты во всех структурах службы каталога могут быть уникально идентифицированы. Служба каталога Active Directory основана на стандарте Х.500, и Microsoft включил в нее все основные (или оригинальные) заданные стандартом классы. Этот пространство имен можно представлять или в точечной (dotted), т.е. числовой нотации, или в строковой (string). Например, идентификатор Х.500 OID, равный 2.5.4.10, является эквивалентом атрибута Organization-Name (Название организации) (с отображаемым LDAP-именем - «о»). Числовое представление класса этого объекта уникально идентифицирует его в пределах иерархии Х.500, и таким образом объект становится уникальным. Объекты Active Directory могут быть также уникально идентифицированы с помощью строковой нотации Х.500, известной также как каталог взаимодействия открытых систем (OSI - Open Systems Interconnection). В строковой нотации пользовательский объект может быть представлен как: cn= Roman Petrov, cn=Users, dc= ami, dc=nstu, dc=ru Имя Х.500 включает название контейнера, в котором найдена учетная запись пользователя (типа OU), и дает возможность названию учетной записи пользователя быть уникальной. Строковое представление пространства имен Х.500 определено в документе Request for Comments (RFC) 1779, который доступен на сайте http://www.faqs.org/rfcs/rfcl779.html. Облегченный протокол службы каталогов (LDAP) Протокол LDAP является как протоколом доступа, так и моделью службы каталога в Active Directory Windows Server 2003. Как информационная модель иерархия имен LDAP подобна иерархии имен каталогов X.500/OSI. Как протокол доступа LDAP определен в комплекте TCP/IP для доступа к данным, находящимся в LDAP-совместимых каталогах. Как открытый стандарт LDAP облегчает обмен данными между платформами с различными службами каталога. Ключевые функции и преимущества службы Active Directory Централизованный каталог Единая регистрация Делегированное администрирование Интерфейс общего управления Интегрированная безопасность Масштабируемость Архитектура Active Directory Active Directory составляют несколько основных архитектурных компонентов: схема, модели данных, безопасности и администрирования. Модель данных Унаследована от модели данных Х.500. Каталог содержит объекты, представляюшие различные компоненты сети. Каждый объект представлен атрибутами. Совокупность объектов, допустимых для хранения в каталоге, определяется схемой. Схема Реализована как набор экземпляров классов объектов, хранимых в каталоге. Схема может обновляться динамически, т. е. приложение вправе добавить в схему новые атрибуты и классы и сразу использовать эти расширения. Схема обновляется путем создания или изменения хранимых в каталоге объектов схемы. Как и все объекты хранилища Active Directory, объекты схемы защищены списками управления доступом (access control list, ACL), поэтому изменять схему разрешено только правомочным пользователям. Модель безопасности Каталог — полноценная составляющая инфраструктуры безопасности Windows 2000. ACL защищает все объекты в хранилище Active Directory. Средства авторизации доступа Windows 2000 применяют ACL для разрешения доступа к объектам или атрибутам в хранилище Active Directory. Модель администрирования Active Directory администрируют только авторизованные пользователи. Администратор вправе предоставить пользователю некий стандартный набор разрешений для выполнения только определенных действий над указанной совокупностью экземпляров или классов объектов в конкретном поддереве каталога, т. е. делегировать административные полномочия. Это позволяет четко контролировать распределение полномочий, не предоставляя каждому отдельному пользователю конкретные разрешения. Физическая структура службы Active Directory Физическое проявление службы Active Directory состоит в наличии отдельного файла данных, расположенного на каждом контроллере домена в домене. Физическая реализация службы Active Directory описывается местоположением контроллеров домена, на которых расположена служба. При реализации службы Active Directory можно добавлять столько контроллеров доменов, сколько необходимо для поддержания служб каталога в данной организации. Имеется пять определенных ролей, которые может играть каждый из контроллеров домена. Они известны как роли хозяина операций (operations master roles). Еще одна роль, которую может выполнять любой отдельный контроллер домена в домене, связана с глобальным каталогом (GC — Global Catalog). Хранилище данных каталога Все данные базы данных службы Active Directory хранятся в отдельном файле Ntds.dit на контроллере домена. Этот файл данных по умолчанию находится в папке %SystemRoot%\NTDS, расположенной на контроллере домена. В нем хранится вся информация каталога, предназначенная для данного домена, а также данные, являющиеся общими для всех контроллеров домена в данной организации. Контроллеры домена По определению любой компьютер, на котором выполняется Windows Server 2003, и который поддерживает копию базы данных службы Active Directory, является контроллером домена. Все контроллеры домена создаются равными за несколькими исключениями. При использовании процесса репликации с несколькими хозяевами домена (multimaster), каждый контроллер домена в домене поддерживает новейшую копию базы данных домена и способен создавать изменения в ней. В дополнение к контроллерам домена, которые содержат службу Active Directory, имеется несколько контроллеров домена специального назначения, которые требуются службе Active Directory для выполнения определенных функций. Серверы глобального каталога На сервере глобального каталога находится глобальный каталог (GC). Он является частичной, предназначенной только для чтения копией всех контекстов именования домена (NC - Naming Context) в лесу. Каталог GC содержит основной, но неполный набор атрибутов для каждого объекта леса в каждом домене NC. Данные каталога GC получают из всех разделов каталога доменов в лесу, они копируются с использованием стандартного процесса репликации службы Active Directory. Первый контроллер домена, установленный в домене, автоматически является контроллером глобального каталога. Зачем вообще нужны GC-серверы? Во-первых, они используются для поиска в Active Directory. Без каталога GC поиск по запросам, полученным контроллером домена, который не обладает запрошенным объектом, приведет к тому, что он переправит запрос на контроллер домена другого домена. Во-вторых, GC-серверы необходимы для обработки пользовательских входов в систему. Обычно каждый раз, когда пользователь входит в домен, выполняется обращение к GC-каталогу. Это происходит потому, что контроллеры домена, не являющиеся глобальными, не содержат никакой информации об универсальном членстве группы. Универсальные группы могут содержать учетные записи пользователей и групп из любого домена определенного леса. Так как универсальное групповое членство распространяется на лес, то групповое членство может быть разрешено только тем контроллером домена, который имеет информацию каталога на уровне леса, т.е. информацию глобального каталога (GC). Логическая структура Active Directory После того как вы установили Active Directory в свою сетевую среду и начали реализовывать проект службы, подходящий для ваших деловых целей, вы будете работать с логической структурой Active Directory. Она является моделью службы каталога, которая определяет каждого участника безопасности на предприятии, а также организацию этих участников. База данных Active Directory содержит следующие структурные объекты: • разделы; • домены; • деревья доменов; • леса; • сайты; • организационные единицы. Разделы Active Directory Как вы уже знаете, база данных Active Directory хранится в файле на жестком диске каждого контроллера домена. Она разделена на несколько логических разделов, каждый из которых хранит различные типы информации. Разделы Active Directory называются контекстами именования (NC - naming contexts). Домены Домен является основным строительным блоком в модели службы Active Directory. Устанавливая Active Directory на своем компьютере, работающем под управлением Windows Server 2003, вы создаете домен. Домен служит в качестве административной границы, он определяет и границу политик безопасности. Каждый домен имеет, по крайней мере, один контроллер домена (оптимально иметь два или более). Домены Active Directory организованы в иерархическом порядке. Первый домен на предприятии становится корневым доменом леса, обычно он называется корневым доменом или доменом леса. Корневой домен является отправной точкой для пространства имен Active Directory Деревья доменов Домены, которые создаются в инфраструктуре Active Directory после создания корневого домена, могут использовать существующее пространство имен Active Directory совместно или иметь отдельное пространство имен. Чтобы выделить отдельное пространство имен для нового домена, нужно создать новое дерево домена. Леса Лес представляет самую дальнюю репликацию и является границей безопасности для предприятия. Все домены и доменные деревья существуют в пределах одного или несколько лесов Active Directory. Лес является общим для всех контроллеров домена в лесу. Доверительные отношения По умолчанию домен является границей доступа к ресурсам в организации. Имея соответствующие разрешения, любой участник безопасности (например, учетная запись пользователя или группы) может обращаться к любому общедоступному ресурсу в том же самом домене. Для получения доступа к ресурсам, которые находятся за пределами домена, используются доверительные отношения службы Active Directory. Доверительные отношения представляют собой опознавательную связь между двумя доменами, с помощью которой участники безопасности могут получать полномочия на доступ к ресурсам, расположенным на другом домене. Есть несколько типов доверительных отношений, включающих: • транзитивные доверительные отношения; • односторонние доверительные отношения; • доверительные отношения леса; • доверительные отношения области. Сайты Все логические компоненты Active Directory, обсуждаемые до сих пор, практически не зависят от физической инфраструктуры сети. Например, при проектировании структуры домена для корпорации вопрос о том, где расположены пользователи, является не самым важным. Все пользователи в домене могут находиться в единственном офисном строении или в офисах, расположенных по всему миру. Независимость логических компонентов от сетевой инфраструктуры возникает вследствие использования сайтов в Active Directory. Сайты обеспечивают соединение между логическими компонентами Active Directory и физической сетевой инфраструктурой. Сайт представляет область сети, где все контроллеры домена связаны быстрым, недорогим и надежным сетевым подключением. В большинстве случаев сайт содержит одну или более подсетей с протоколом интернета (IP), связанных локальной сетью (LAN) или быстродействующей глобальной сетью (WAN), подключенных к остальной части сети через более медленные WAN-подключения. Основная причина для создания сайтов состоит в том, чтобы иметь возможность управлять любым сетевым трафиком, который должен использовать медленные сетевые подключения. Сайты используются для управления сетевым трафиком в пределах сети Windows Server 2003 тремя различными способами. • Репликация. В пределах сайта любое изменение, сделанное в каталоге, будет копироваться в течение приблизительно пяти минут. Графиком репликации между сайтами можно управлять так, чтобы репликация происходила во время нерабочих часов. По умолчанию трафик репликации между сайтами сжат для сохранения пропускной способности сети, в пределах сайта трафик репликации не сжимается. • Идентификация. Когда пользователь входит в домен Windows Server 2003, компьютер клиента пробует подключить контроллер домена, находящийся в том же самом сайте, где находится клиент. • Сетевые службы, учитывающие наличие сайтов. Третий способ, который позволяет сайтам сохранять высокую пропускную способность, состоит в ограничении клиентских подключений к сайту только теми приложениями и службами, которые учитывают наличие сайтов. Например, используя распределенную файловую систему (DFS -Distributed File System), вы можете создавать несколько реплик папки на различных сайтах в сети. Поскольку система DFS спроектирована так, что она учитывает конфигурацию сайта, компьютеры клиента всегда пробуют обратиться к DFS-реплике на своем собственном сайте, прежде чем использовать связи WAN-сети, чтобы получить доступ к информации на другом сайте. Каждый компьютер в сети Windows Server 2003 будет назначен сайту. Когда служба Active Directory устанавливается в среде Windows Server 2003, создается заданный по умолчанию сайт, называемый Default First Site Name (заданное по умолчанию имя первого сайта), и все компьютеры леса будут назначены этому сайту, если не создается дополнительных сайтов. Организационные единицы Путем реализации нескольких доменов в лесу в виде одного или нескольких деревьев служба Active Directory Windows Server 2003 может масштабироваться так, чтобы обеспечить услуги каталога для сети любого размера. Многие из компонентов Active Directory, такие как глобальный каталог и автоматические транзитивные доверительные отношения, предназначены для того, чтобы сделать использование и управление каталогом предприятия эффективным, независимо от того, насколько большим становится каталог. Организационные единицы (OU - Organizational Unit) предназначены для того, чтобы облегчить управление службой Active Directory. OU используются для того, чтобы сделать более эффективным управление единственным доменом, вместо того чтобы иметь дело с управлением несколькими доменами службы Active Directory. OU служат для создания иерархической структуры в пределах домена. Домен может содержать сотни тысяч объектов. Управление таким количеством объектов без использования определенных средств организации объектов в логические группы затруднено. Организационные единицы выполняют именно эти функции. OU являются контейнерами объектов, содержащими несколько типов объектов службы каталога: • компьютеры; • контакты; • группы; • inetOrgPerson; • принтеры; • пользователи; • общедоступные папки; • организационные единицы. Организационные единицы используются для группировки объектов в административных целях. Они могут делегировать административные права и управлять группой объектов как отдельным подразделением. Active Directory и доменная система имен Служба каталога Active Directory Microsoft Windows Server 2003 при поиске ресурсов в сети полностью полагается на доменную систему имен (DNS). Проектирование структуры Active Directory Развертывание службы каталога Active Directory в Microsoft Windows Server 2003 требует планирования и проектирования. Проектирование структуры леса Самое главное решение, которое вы должны принять на раннем этапе разработки, - сколько лесов вам потребуется. Развертывание единственного леса Active Directory означает, что будет возможно простое совместное использование ресурсов и доступ к информации в пределах компании. Использование единственного леса для большой корпорации требует высокой степени доверия между разнообразными и, возможно, разъединенными деловыми подразделениями. В конечном счете, количество развертываемых лесов зависит от того, что является наиболее важным для вашей компании: легкость совместного использования информации в пределах всех доменов леса или поддержка полностью автономного и изолированного управление частями структуры каталога. Леса и проект Active Directory Лес Active Directory предназначен для того, чтобы быть отдельным самодостаточным модулем. Внутри леса легко совместно использовать информацию и сотрудничать с другими пользователями из того же самого подразделения. Однако действия одного человека могут воздействовать на каждого члена леса. Проектируя самый высокий уровень инфраструктуры Active Directory, вы должны решить, нужно ли вам развертывать один лес или несколько. Каждый лес является интегрированным модулем, потому что он включает следующее. • Глобальный каталог. Лес имеет один глобальный каталог (GC). Каталог GC облегчает поиск объектов в любом домене леса и вход на любой домен леса независимо от того, на каком домене зарегистрирована учетная запись пользователя. • Раздел конфигурации каталога. Все контроллеры домена совместно используют один и тот же раздел конфигурации каталога. Эта информация используется для оптимизации репликации информации в пределах леса, для хранения приложений и информации Active Directory, поддерживающей приложения, и для совместного использования информации с помощью раздела приложений каталога. • Доверительные отношения. Все домены в лесу связаны двухсторонними транзитивными доверительными отношениями. Не существует никакой опции, позволяющей изменить это. В то время как служба Active Directory облегчает совместное использование информации, она предписывает множество ограничений, которые требуют, чтобы различные подразделения в компании сотрудничали различными способами. Эти ограничения включают следующее. • Одна схема. Все домены в лесу используют одну схему. Это обстоятельство как будто упрощает дело, но оно может быть одной из причин развертывания нескольких лесов в корпорации. Если одно подразделение решает развертывать приложение, которое изменяет схему, то это оказывает воздействие на все подразделения. Возможно, вам покажется, что такое событие не будет иметь большого воздействия на всю службу, но оно может стать непреодолимым, если двадцать подразделений решат, что им требуется развернуть приложения, изменяющие схему. Каждая модификация схемы должна быть проверена для гарантии того, что она не находится в противоречии с другими изменениями схемы. Это потребует значительного времени и усилий. • Централизованное управление. Развертывание единственного леса означает, что некоторые компоненты сетевого управления должны быть централизованы. • Политика управления изменениями. Поскольку изменения леса могут затрагивать каждый домен и должны выполняться только централизованно, требуется четкая политика управления изменениями. • Доверенные администраторы. Развертывание одного леса требует определенной степени доверия администраторам всех доменов. Любой администратор, обладающий правами управления контроллером домена, может сделать такие изменения, которые затронут весь лес. Это означает, что все администраторы доменов должны быть высоко доверенными людьми. Проектирование доменной структуры Как только вопрос о количестве развертываемых лесов улажен, необходимо определить доменную структуру в пределах каждого из лесов. Домены и проект Active Directory Домены используются для разделения большого леса на более мелкие компоненты для целей репликации или администрирования. Следующие характеристики домена крайне важны при проектировании Active Directory. • Граница репликации. • Граница доступа к ресурсам. По умолчанию пользователи одного домена не могут обращаться к ресурсам, расположенным в другом домене, если только им не будут явно даны соответствующие разрешения. • Границы политики безопасности. Некоторые политики безопасности могут быть установлены только на уровне домена. Эти политики, такие как политика паролей, политика блокировки учетных записей и политика билетов Kerberos, применяются ко всем учетным записям домена. Проектирование инфраструктуры DNS Как только вы определились с количеством доменов и их иерархией, следующий шаг должен состоять в проектировании инфраструктуры DNS для вашей сети. Служба Active Directory Windows Server 2003 требует DNS, поскольку каждое имя домена теперь является частью пространство имен DNS. Ключевое решение проекта состоит в том, чтобы определить, где расположить домены Active Directory в пределах этого пространства имен. В дополнение к этому вы должны также спроектировать конфигурацию сервера DNS. Если компания уже имеет свою инфраструктуру DNS, то вам придется спроектировать свое пространство имен, чтобы вписаться в текущее пространство имен, а также сконфигурировать DNS-серверы Windows Server 2003 для взаимодействия с существующими серверами DNS. Проектирование структуры организационной единицы Как только проектирование на уровне доменов закончено, следующий шаг состоит в создании модели организационной единицы OU для каждого домена. OU используются для создания иерархической структуры в пределах домена. Эта иерархия может затем использоваться для делегирования административных задач или применения групповых политик к совокупности объектов. Организационные единицы и проектирование Active Directory Организационные единицы характеризуются следующим. • Проектирование OU не оказывает влияния на проектирование пространства имен DNS. OU получают имена каталога в пределах пространства имен DNS. Например, организационная единица может иметь отличительное имя OU=Аспиратны, OU=ПМт, DC=ami, DC=nstu, DC=ru. В этом случае ami.nstu.ru является DNS-именем, а LDAP-имена внутри пространства имен DNS являются именами OU. • Организационные единицы могут быть созданы внутри других единиц. • Организационные единицы OU прозрачны для конечных пользователей. • По сравнению с другими компонентами Active Directory, такими как домены и леса, структуру OU легко изменить после развертывания. Проектирование структуры OU Проект OU, основанный на делегировании администрирования Проект OU, основанный на проекте групповых политик Начните разрабатывать проект OU с организационных единиц высшего уровня. Их труднее модифицировать после развертывания из-за OU, расположенных ниже. OU высшего уровня должны основываться на чем-то неизменном: на географических регионах или деловых подразделениях. Проектирование топологии сайта Поскольку проектирование сайта сильно зависит от организационной инфраструктуры сети, первый шаг в создании проекта состоит в документировании этой инфраструктуры. Документирование должно включать: • схемы топологии глобальной (WAN) и локальной сети (LAN), детализирующие сеть корпорации, в которых содержится информация о полной пропускной способности и доступной пропускной способности между всеми офисами компании; • список всех офисов компании, в которых компьютеры связаны через высокоскоростные сетевые соединения. Определение высокоскоростного подключения меняется в зависимости от таких факторов, как количество пользователей в офисах компании, общее количество объектов в домене и доменов в лесу. Кроме того, нужно определить, какая часть из полной полосы пропускания сети доступна для репликации. В большинстве случаев сетевые подключения в пределах сайта должны иметь скорость доступной полосы пропускания 512 Кб/с. В крупной компании в качестве минимальной скорости сетевого подключения в пределах сайта устанавливается скорость в 10 Мб/с; • для каждого офиса компании уточните количество пользователей, компьютеров, серверов и локальных подсетей IP. Создание модели сайта Как только информация о сети компании собрана, можно приступать к проектированию сайта. Для начала исследуйте каждый офис компании, в котором компьютеры связаны через высокоскоростные сетевые подключения. Сколько пользователей находится в каждом месте? Достаточно их для того, чтобы там требовался контроллер домена? Каковы сетевые соединения от этого офиса до других офисов компании? Каждый сайт должен иметь контроллер домена, а большинство из них - и GC-сервер. Если вы решаете, создавать ли сайт для офиса компании с несколькими пользователями и медленным сетевым соединением, то на самом деле решается вопрос о том, нужен ли здесь контроллер домена. Для этого определите, какой вариант приведет к наименьшему количеству сетевого трафика. Что создаст большее количество трафика: входы клиентов на контроллер домена из других офисов компании или трафик репликации между контроллерами домена? Для тяжелого трафика нужно рассмотреть другие факторы. Если вы не поместите контроллер домена в данное место, то следует рассмотреть возможность прерывания работы пользователей в случае отказа сетевого подключения, потому что пользователи не смогут войти в домен. Если вы все равно развертываете Windows Server 2003 в данном месте, то не может ли он быть также и контроллером домена сайта? После определения количества сайтов для Active Directory создается проект каждого сайта. Каждый сайт в Active Directory связан с одной или более подсетями IP, поэтому нужно определить, какие подсети будут включены в каждый сайт. Проектирование размещения серверов Размещение DNS-серверов Размещение контроллеров домена Размещение серверов глобального каталога Размещение серверов хозяев операций (PDC) Лекция 2 Переход от домена Windows NT 4 к Active Directory Существует три пути перехода: обновление домена; реструктуризация домена; обновление с последующей реструктуризацией. При переходе через обновление накладывается много ограничений, в том числе: имя домена изменить нельзя. Реструктуризация домена - процесс выборочный, здесь имеется возможность выбора тех объектов, которые вы хотите перенести на новую платформу. (Обновление домена — это бескомпромиссная сделка, т.е. каждый объект домена Windows NT 4 обновляется до Windows Server 2003 и Active Directory.) Проектирование реструктуризации домена - прекрасный момент, чтобы убрать все дубликаты, пассивные, тестовые и другие более не функционирующие учетные записи пользователей и групп. Они исчезнут, когда вы перейдете к новой модели домена и дадите новое назначение старым контроллерам домена. При этом реструктуризация может выполняться либо перемещением, либо клонированием. Предпочтительным методом передачи участников безопасности в чистый лес Windows Server 2003 является клонирование, поскольку позволяет всегда исправить последствия неправильных действий. Проблемы при переходе: Для обеспечения прозрачности перехода используется атрибут SIDHistory. SID-History является атрибутом участников безопасности Active Directory, который используется для хранения старых идентификаторов защиты (SID) объекта. Если пользователь X имел в домене Windows NT 4 некий идентификатор SID, равный S-1-5-21-2127521184-160401292018879275 27-324294, то такое же значение появится в поле атрибута SIDHistory для созданного объекта учетной записи Windows Server 2003. При перемещении группы из домена Windows NT 4 в домен Active Directory SID домена Windows NT 4 сохраняется в атрибуте SID-History данной группы. При перемещении пользователей и групп учетные записи пользователя автоматически назначаются членами групп, перенесенных в домен Windows Server 2003. Это значит, что права доступа, назначенные для группы в домене Windows NT 4, сохраняются в процессе перехода. Новый SID, сгенерированный целевым контроллером домена, помещается в атрибут SID перемещенной учетной записи. Каким образом сохраняется доступ к ресурсам? Когда пользователь X пытается обратиться к общей папке, расположенной на файловом сервере Windows NT 4, подсистема защиты проверяет его лексему доступа, чтобы удостовериться в наличии необходимых разрешений на доступ к папке. Лексема доступа содержит не только SID пользователя X и SID всех групп, к которым он принадлежит, но и все входы SID-History самого пользователя и учетных записей его групп. Если найдено соответствие между дискреционным списком управления доступом (DACL -discretionary access control list) на дескрипторе защиты папки и предыдущим SID (теперь включенным в лексему доступа с помощью атрибута SID-History), то выдается разрешение на доступ к папке. Как работает атрибут SID-History в сценарии обновления домена? Ответ: он не работает. При обновлении домена поддерживаются SID учетных записей групп и пользователей. Пользователь X сможет нормально обращаться к ресурсам. Как SID-History работает в сценарии обновления с последующей реструктуризацией? Ответ: так же, как в сценарии с простым обновлением домена, т.е. доступ к ресурсам сохраняется за счет поддержки первоначального SID объекта в атрибуте SID-History. Единственное различие состоит в том, что Active Directory требует, чтобы идентификаторы SID появлялись в лесу только один раз, включая оба поля: SID и SID-History. Критерии выбора пути перехода Следующие вопросы уместно задать при определении наиболее подходящего пути перехода для вашей организации. 1. Удовлетворены ли вы моделью вашего домена? Отвечает ли существующая модель домена Windows NT 4 вашим организационным и деловым потребностям? 2. Какую степень риска вы можете допустить при переходе к новой модели домена? 3. Сколько времени вы готовы потратить на выполнение перехода? 4. Какое количество рабочего времени системы потребуется на проект перехода? 5. Какие ресурсы доступны для выполнения перехода? 6. Каков бюджет проекта перехода? 7. Какое количество серверных приложений, которые не смогут выполняться на Windows Server 2003, должны быть поддержаны после перехода? Представьте себе возможные ответы в виде спектра от низкого к высокому уровню, причем, путь обновления домена находится на самом низком уровне, а путь реструктуризации домена – на самом высоком. Процесс перехода к Active Directory требует тщательного планирования и может занимать длительное время. Защита Active Directory Одна из основных причин развертывания службы каталога Active Directory состоит в обеспечении безопасности корпоративной сети. Каждая компания хранит важнейшую для своего бизнеса информацию на файловых серверах в сети. Управление безопасным доступом к информации должно гарантировать, что доступ к данным получат только должным образом уполномоченные пользователи. Защита Active Directory строится на двух типах объектов и на взаимодействии между ними. Первый объект - участник безопасности, который представляет пользователя, группу, службу или компьютер, который нуждается в доступе к некоторому ресурсу в сети. Второй объект это сам ресурс, являющийся объектом, к которому нужно получить доступ участнику безопасности. Чтобы обеспечить надлежащий уровень защиты, служба Active Directory должна идентифицировать участников безопасности, а затем предоставлять правильный уровень доступа к ресурсам. Участники безопасности Только участники безопасности службы Active Directory могут входить в Active Directory и получать разрешения на доступ к ресурсам сети. Участник безопасности - это объект Active Directory, который представляет пользователя, группу, службу или компьютер. Каждому участнику безопасности при создании объекта назначается идентификатор защиты (SID). Идентификатор SID составлен из двух частей. Первая часть идентификатор домена, все участники безопасности в домене имеют один и тот же идентификатор домена. Вторая часть идентификатора SID относительный идентификатор (RID), который является уникальным для каждого участника безопасности в домене Active Directory. Идентификатор SID является основным компонентом конфигурирования защиты для ресурсов, расположенных в сети Windows Server 2003. При выдаче разрешения на доступ к ресурсу вы используете отображаемое имя участника безопасности, но Windows Server 2003 фактически использует SID для управления доступом к ресурсу. Когда пользователь пытается обратиться к ресурсу, расположенному на сервере в домене, операционная система предоставляет разрешение идентификатору SID пользователя, а не имени человека. Это означает, что если отображаемое имя пользователя изменено, разрешения, представленные пользователю, не изменяются. Однако если пользовательский объект удален, а затем создан заново с тем же самым именем, пользователь не сможет обращаться к ресурсам, так как SID изменится. Списки управления доступом Еще один компонент, включенный в защиту Active Directory, - это объект, к которому участник безопасности должен обращаться. Этот может быть другой объект Active Directory, например, организационная единица (OU), принтер или участник безопасности. Объект может быть файлом на сервере с системой Windows Server 2003 или почтовым ящиком на сервере с Microsoft Exchange 2000 Server. Разрешения, которые предоставляются этим объектам, расположены в списке управления доступом (ACL - Access Control List), также называемом дескриптором защиты (security descriptor). Каждый объект в Active Directory или в разделе файловой системы NTFS имеет дескриптор защиты. Дескриптор защиты включает идентификатор SID участника безопасности, который владеет объектом, а также SID для основной группы объекта. Кроме того, каждый объект имеет два отдельных списка ACL: список управления разграничительным доступом (DACL — Discretionary Access Control List) и список управления системным доступом (SACL System Access Control List). Список DACL перечисляет участников безопасности, которым были назначены разрешения на доступ к объекту, а также уровень разрешений, которые были назначены каждому участнику безопасности. Список DACL состоит из записей управления доступом (АСЕ — Access Control Entries). Каждая запись АСЕ содержит идентификатор SID и определяет уровень доступа к объекту, который разрешен данному SID. Список АСЕ включает записи для всех типов участников безопасности. Например, учетная запись пользователя может иметь разрешение Read (Чтение) для файла, а группа защиты -разрешение Full Control (Полное управление). Список DACL для файла имеет, по крайней мере, две записи АСЕ, одну - на предоставление пользователю разрешения Read, другую - на предоставление группе разрешения Full Control. Список SACL перечисляет участников безопасности, чей доступ к ресурсу должен подвергаться аудиту. Список записей АСЕ в SACL указывает, чей доступ должен подвергаться аудиту, а также необходимый уровень аудита. Примечание. Список DACL может содержать записи АСЕ, которые предоставляют доступ к ресурсу, а также АСЕ, которые запрещают доступ. Записи АСЕ, которые запрещают доступ, всегда перечисляются первыми в ACL, так что подсистема защиты сначала оценивает их. Если АСЕ запрещает доступ к ресурсу, то подсистема защиты не оценивает другие записи АСЕ, т.е. запись АСЕ, запрещающая доступ к ресурсу, всегда отменяет любую запись АСЕ, которая предоставляет доступ определенному идентификатору SID. Лексемы доступа Связующей точкой между SID участника безопасности и ACL является лексема доступа. Когда пользователь аутентифицируется через Active Directory, в процессе входа в систему ему назначается лексема доступа. Эта лексема включает основной SID пользователя, идентификаторы SID всех групп, которым принадлежит пользователь, а также права и привилегии пользователя. Лексема доступа используется подсистемой защиты всякий раз, когда пользователь пытается обратиться к ресурсу. В этом случае лексема предъявляется компьютером клиента любому процессу или приложению, которые запрашивают информацию, касающуюся безопасности, перед получением доступа к ресурсу. Аутентификация Чтобы процессы защиты, включающие использование идентификаторов SID и записей ACL, работали должным образом, должен существовать какойто способ, которым пользователь получает доступ к сети. По существу, пользователи должны иметь возможность доказать, что они являются теми, кем они себя представляют, чтобы извлечь свою лексему доступа с контроллера домена. Этот процесс называется аутентификацией. Аутентификация происходит перед входом клиента в систему. Когда пользователь садится за компьютер с системами Windows 2000 или Microsoft Windows XP Professional и вводит Ctrl+Alt+Del, служба Winlogon локального компьютера переключается на экран входа в систему и загружает файл Graphic Identification and Authentication (GINA) (Графическая идентификация и аутентификация) из библиотеки динамической компоновки (DLL). По умолчанию этот файл — Msgina.dll. Однако сторонние производители могут создавать альтернативные файлы GINA (например, клиент системы Netware использует файл Nwgina.dll). После того как пользователь впечатал имя пользователя, пароль и выбрал домен, GINA передает введенные «верительные грамоты» службе Winlogon. Winlogon передает информацию локальной службе безопасности LSA (Local Security Authority). Служба LSA немедленно применяет к паролю пользователя операцию одностороннего кэширования и удаляет понятный текстовый пароль, который пользователь напечатал. Затем вызывается соответствующий провайдер защиты (SSP — Security Support Provider) через интерфейс провайдеров защиты (SSPI Security Support Provider Interface). Windows Server 2003 обеспечивает двух основных SSP-провайдеров для сетевой аутентификации — KerbeVos SSP и NT LAN Manager (NTLM) SSP. Если клиенты с системой Windows 2000, или более поздней, входят в сеть системы Windows 2000 или Windows Server 2003, выбирается SSP Kerberos, и информация передается SSP. Затем SSP связывается с контроллером домена для подтверждения подлинности пользователя. Опознавательный процесс с использованием протокола Kerberos будет описан далее в этой главе. Если процедура входа в систему прошла успешно, значит, пользователь аутентифицирован, и ему предоставлен доступ к сети. Если пользователь вошел в домен и все ресурсы, к которым пользователю нужно обратиться, находятся в том же самом лесу, то это единственный момент аутентификации пользователя. Пока пользователь не выйдет из системы, все разрешения, которые он получит в сети, будут основаны на начальной аутентификации. Разрешение Разрешение (authorization) — это второй шаг в процессе получения доступа к сетевым ресурсам, он происходит после аутентификации. В процессе аутентификации вы доказываете свою идентичность, впечатывая правильное имя пользователя и пароль. В процессе разрешения вам дается доступ к сетевым ресурсам. В процессе аутентификации для вас создается лексема доступа. В процессе разрешения вы предъявляете лексему доступа серверу или службе и запрашиваете доступ к ресурсу. Если идентификатор SID в вашей лексеме доступа соответствует идентификатору SID в записи ACL, которая предоставляет доступ, вам предоставляется доступ к ресурсу. Основной механизм аутентификации в Active Directory — это протокол Kerberos Всякий раз, когда клиент с системой Windows 2000, или более поздней, подтверждает свою подлинность в Active Directory, он использует протокол Kerberos. Другой протокол, использующийся для подтверждения подлинности в Active Directory, - это NTLM, который поддерживается для обратной совместимости с клиентами, пользующимися более старыми версиями операционных систем. Протокол Kerberos имеет множество преимуществ по сравнению с NTLM: Взаимная аутентификация. При использовании протокола NTLM аутентификация происходит только в одном направлении, т.е. сервер подтверждает подлинность клиента. При использовании протокола Kerberos клиент может также подтверждать подлинность сервера, гарантируя, что сервер, который отвечает на запрос клиента, является правильным сервером. Более эффективный доступ к ресурсам. Когда пользователь обращается к сетевому ресурсу в сети, использующему протокол NTLM (например, Microsoft Windows NT 4), то сервер, на котором расположен ресурс, должен контактировать с контроллером домена для проверки разрешения на доступ данного пользователя. В сети, использующей Kerberos, клиент соединяется с контроллером домена и получает билет на сетевое соединение, чтобы получить доступ к серверу ресурса. Это означает, что сервер ресурса не должен соединяться с контроллером домена. Улучшенное управление доверительными отношениями. Доверительные отношения NTLM всегда односторонние, не транзитивные, они конфигурируются вручную. Доверительные отношения Kerberos конфигурируются автоматически, поддерживаются между всеми доменами леса и являются транзитивными и двусторонними. Кроме того, доверительные отношения Kerberos могут быть сконфигурированы между лесами и доменами Kerberos Windows Server 2003 и другими реализациями протокола Kerberos. Делегированная аутентификация. Когда клиент подключается к серверу, используя аутентификацию NTLM, сервер может использовать сертификаты клиента для доступа к ресурсам, расположенным только на локальном сервере. С аутентификацией Kerberos сервер может использовать сертификаты клиента для доступа к ресурсам, расположенным на другом сервере. В системе, основанной на протоколе Kerberos, имеется три компонента. Во-первых, клиент, который должен получить доступ к сетевом ресурсам. Во-вторых, сервер, который управляет сетевыми ресурсами и гарантирует, что только должным образом заверенные и уполномоченные пользователи могут получать доступ к ресурсу. Третий компонент — центр распределения ключей (KDC - Key Distribution Center), который служит центральным местом хранения пользовательской информации и главной службой, подтверждающей подлинность пользователей. Протокол Kerberos определяет то, как эти три компонента взаимодействуют между собой. Это взаимодействие основано на двух ключевых принципах. Прежде всего, Kerberos работает, основываясь на предположении, что опознавательный трафик между рабочей станцией и сервером пересекает незащищенную сеть. Это означает, что никакой конфиденциальный опознавательный трафик никогда не посылается по сети открытым, незашифрованным текстом, а пользовательский пароль никогда не посылается по сети, даже в зашифрованной форме. Второй принцип состоит в том, что протокол Kerberos имеет в своей основе опознавательную модель с общим секретом. В этой модели клиент и опознающий сервер владеют общим секретом, который неизвестен кому-либо еще. В большинстве случаев общий секрет — это пароль пользователя. Когда пользователь входит в сеть, защищенную протоколом Kerberos, пароль пользователя используется для шифрования пакета информации. Когда сервер Kerberos получает пакет, он расшифровывает информацию, используя копию пароля, хранящегося на сервере. Если расшифровка прошла успешно, то опознающий сервер знает, что пользователю известен общий секрет, и ему предоставляется доступ. Делегирование административных задач Поскольку все объекты в Active Directory имеют ACL-список, вы можете управлять административным доступом к любому свойству любого объекта. Это означает, что вы можете предоставлять другим администраторам Active Directory очень точные разрешения, чтобы они могли выполнять только делегированные им задачи. Хотя при делегировании административных прав можно очень сильно их детализировать, необходимо поддерживать равновесие между сохранением максимально возможной простоты вещей и удовлетворением требований безопасности. В большинстве случаев делегирование административных разрешений в Active Directory подпадает под один из следующих сценариев. Назначение полного управления одной OU. Довольно типична ситуация, когда компания имеет несколько офисов с локальным администратором в каждом офисе, который должен управлять всеми объектами локального офиса. Этот вариант может также использоваться компаниями, которые слили домены ресурсов Windows NT в OU одного домена Active Directory. Прежним администраторам доменов ресурсов можно дать полное управление всеми объектами, расположенными в определенной OU. Использование этой опции означает, что можно практически полностью децентрализовать администрирование вашей организации, имея единственный домен. Назначение полного управления определенными объектами в OU. Это разновидность первого сценария. В некоторых случаях компания может иметь несколько офисов, но локальные администраторы должны управлять только определенными объектами в OU данного офиса. Например, можно позволить локальному администратору управлять всеми объектами пользователей и групп, но не компьютерными объектами. В ситуации, когда домены ресурсов стали организационными единицами (OU), вы, возможно, захотите, чтобы администраторы OU управляли всеми компьютерными учетными записями и локальными группами в OU, но не пользовательскими объектами. Назначение полного управления определенными объектами всего домена. Некоторые компании имеют высоко централизованное администрирование пользователями и группами, когда только одна группа имеет разрешение добавлять и удалять учетные записи групп и пользователей. В этом сценарии данной группе можно давать полное управление объектами пользователей и групп независимо от того, где в пределах домена расположены объекты. Этот сценарий довольно типичен для компании с централизованной группой администрирования компьютерами и серверами. Компьютерной группе можно дать полное управление всеми компьютерными объектами в домене. Назначение прав на модификацию только некоторых свойств объектов. В некоторых случаях можно предоставить группе административное разрешение управлять поднабором свойств объекта. Например, устанавливать пароли для всех учетных записей пользователя, но не иметь других разрешений. Отделу кадров можно дать разрешение на модификацию личной и открытой информации, касающейся всех учетных записей пользователя в домене, но не давать разрешение на создание или удаление учетных записей пользователя. Планирование делегирования администрирования Active Directory Windows Server 2003 предоставляет средства, предназначенные для делегирования административных разрешений в вашем домене. Однако вместе с положительными сторонами делегирования разрешений вы получаете риск назначения неправильных разрешений. Пользователям можно предоставить слишком большое количество разрешений, позволяющее им делать в Active Directory то, что им делать не положено. Пользователям можно предоставить слишком малое количество разрешений, не позволяющее делать то, что они должны делать. Создание структуры делегирования, которая обеспечит пользователей точными разрешениями, в которых они нуждаются, требует серьезного планирования. Тщательно документируйте административные требования для всех потенциальных администраторов. В большинстве компаний вы обнаружите, что имеются различные группы, которые нуждаются в некоторых административных разрешениях в домене. Если компания использовала Windows NT, многие из этих пользователей могли быть членами группы Domain Admins. Документируя административные задачи, которые эти пользователи должны выполнять, вы обнаружите, что на самом деле они нуждаются в гораздо более низком уровне доступа. Часто единственный способ документирования уровня административных разрешений, в которых нуждается каждая группа, состоит в документировании всей административной работы, которую они делают каждый день. Документируя действия, которые администраторы должны выполнять, вы сможете разработать точные разрешения, которые для этого следует иметь. Перед тем как сделать какие-либо изменения в производственной среде, проверьте все модификации защиты в испытательной среде. Создание неправильной конфигурации защиты может иметь серьезные последствия для вашей сети. Используйте испытательную лабораторию для гарантии того, что модификации разрешений отвечают необходимым требованиям, но не дают разрешений, которые не являются необходимыми. Используйте Effective Permissions (Фактические разрешения) в окне Advanced Security Settings (Дополнительные параметры настройки защиты) для мониторинга и проверки разрешений, которые имеют пользователи. Окно Effective Permissions является отличным новым инструментом службы Active Directory Windows Server 2003, который может использоваться для определения точных разрешений пользователя или группы. Используйте этот инструмент в испытательной среде для гарантии того, что ваша конфигурация точна, а затем используйте его в производственной среде, чтобы удостовериться, что ваша реализация соответствует плану. Документируйте все разрешения, которые вы назначаете. Из всех задач, возложенных на сетевых администраторов, документирование изменений, сделанных в сети, относится к самым неприятным, потому что это очень утомительно и кажется не особо важным. В результате документация часто оказывается неполной или устаревшей. Единственный путь эффективного управления конфигурацией защиты вашей сети состоит в том, чтобы документировать начальную конфигурацию, а затем взять обязательство обновлять документацию всякий раз, когда один из первоначальных параметров настройки изменен. Управление объектами Active Directory Большинство компаний создает и реализует проект Active Directory один раз. После развертывания с большинством объектов Active Directory произойдут небольшие изменения. Однако работа с объектами user (пользователь) и объектами group (группа) является исключением из этого правила. По мере того как служащие присоединяются к компании или оставляют ее, администратор тратит время на управление пользователями и группами. Служба Active Directory содержит другие объекты, такие как printer (принтер), computer (компьютер) и shared folder (общие папки), которые также требуют частого администрирования. Управление пользователями В службе Active Directory Windows Server 2003 существуют три объекта, которые используются для представления индивидуальных пользователей в каталоге. Два из них, объект user (пользователь) и объект inetOrgPerson, являются участниками безопасности, которые могут использоваться для назначения доступа к ресурсам вашей сети. Третий объект contact (контакт) не является участником безопасности и используется для электронной почты. Объекты User Один из наиболее типичных объектов в любой базе данных Active Directory — объект user. Объект user, подобно любому другому объекту класса Active Directory, представляет собой совокупность атрибутов. Фактически, он может иметь более 250-ти атрибутов. Этим служба Active Directory Windows Server 2003 сильно отличается от службы каталога Microsoft Windows NT, в которой объекты user имеют очень мало атрибутов. Поскольку Active Directory может обеспечить эти дополнительные атрибуты, она полезна именно как служба каталога, а не просто как база данных для хранения опознавательной информации. Active Directory может стать основным местом хранения большей части пользовательской информации в вашей компании. Каталог будет содержать пользовательскую информацию: номера телефона, адреса и организационную информацию. Как только пользователи научаться делать поиск в Active Directory, они смогут найти практически любую информацию о других пользователях. Когда вы создаете объект user , нужно заполнить некоторые из его атрибутов. При создании учетной записи пользователя требуется только шесть атрибутов, причем атрибуты сп и sAMAccountName конфигурируются на основе данных, которые вы вводите при создании учетной записи. Остальные атрибуты, включая идентификатор безопасности (SID), автоматически заполняются системой безопасности. Вы можете просматривать и изменять любой атрибут объекта user, используя инструменты Adsiedit.msc или Ldp.exe. Объекты inetOrgPerson Одним из новых объектов Active Directory Windows Server 2003 является объект inetOrgPerson. Он является основной учетной записью пользователя, которая используется другими каталогами с применением облегченного протокола службы каталогов (Lightweight Directory Access Protocol — LDAP) и Х.500, совместимыми с требованиями документа Request for Comments (RFC) 2798. Вводя объект inetOrgPerson, Microsoft облегчил интеграцию службы Active Directory с другими каталогами и упростил перемещение из каталогов в Active Directory. Объект inetOrgPerson может быть создан с помощью инструмента Active Directory Users And Computers. Для этого найдите контейнер, в котором вы хотите создать объект, щелкните на нем правой кнопкой мыши и выберите New>InetOrgPerson. При создании объекта inetOrgPerson вы должны ввести пользовательское имя входа в систему и полное имя. Объект inetOrgPerson является подклассом объекта user, т.е. он имеет все характеристики пользовательского класса, включая и то, что он действует как участник безопасности. Объекты inetOrgPerson управляются и используются теми же способами, как и объект user. Учетные записи Contact Третий тип объектов, который может использоваться для представления пользователей в Active Directory, — это объект contact (контакт). Объекты contact отличаются от объектов user и inetOrgPerson тем, что они не является участниками безопасности (security principal). Обычно объекты contact используются только для информационных целей. Чтобы создать объект contact в инструменте Active Directory Users And Computers, найдите контейнер, в котором вы хотите создать объект, щелкните на нем правой кнопкой мыши и выберите New>Contact. При создании объекта contact вы должны ввести полное имя, можно также заполнить множество атрибутов объекта, включая номера телефона и адрес. Контакты полезны в нескольких сценариях. Например, имеется пользователь, который не является участником безопасности в вашем домене, но чья контактная информация должна быть доступной. Это могут быть консультанты, работающие в вашем офисе и не имеющие прав на вход в сеть, но их контактная информация должна храниться в компании, чтобы ее могли легко найти все сотрудники. Другой вариант использования объекта contact возникает при реализации Microsoft Exchange 2000 Server, который, в отличие от более ранних версий, не имеет своей собственной службы каталога. Вместо этого Exchange 2000 Server требует наличия Active Directory, и вся информация сервера хранится в каталоге Active Directory. В Exchange Server 5.5 и более ранних версиях вы можете создавать собственного получателя. Собственный получатель имеет адрес электронной почты, вы можете посылать ему почту, но у него нет почтового ящика на вашем Exchange-сервере. Если вы используете Exchange 2000 Server, то объект contact с поддержкой электронной почты заменит объект собственного получателя. Когда вы включаете почту для объекта contact, вы назначаете учетной записи адрес электронной почты, и он становится видимым для почтового клиента. Когда вы посылаете почту объекту contact, она доставляется по правильному адресу электронной почты. Управление группами Основная функция Active Directory состоит в санкционировании доступа к сетевым ресурсам. В конечном счете, доступ к сетевым ресурсам основан на индивидуальных учетных записях пользователя. В большинстве случаев вы не захотите управлять доступом к. ресурсам с их помощью. В крупной компании это может привести к слишком большой загрузке администратора, кроме того, списки управления доступом (ACL) на сетевых ресурсах быстро стали бы неуправляемыми. Поскольку управление доступом к сетевым ресурсам с помощью индивидуальных учетных записей трудно поддается обработке, вы будете создавать объекты group для одновременного управления большими совокупностями пользователей. Типы групп В системе Windows Server 2003 имеется два типа групп, называемых группами распространения (distribution group) и группами безопасности (security group). Когда вы создаете новый объект group, вам необходимо выбрать тип создаваемой группы
