Организационно-штатная структура компании 'Рога Копыта'
Введение
операционный windows
доменный пространство
В современно мире производственно - коммерческие
предприятия, находящиеся как в частной, так и в государственной собственности в
силу требований экономического рынка, с целью сохранения конкурентоспособности,
вынуждены постоянно расширять зону своего влияния, охватывая все новые и новые
территории. В связи с этим для таких территориально-распределенных компаний с
каждым годом все острее становится вопрос выбора координационной технологии,
позволяющей быстро и с сохранением необходимого уровня безопасности
осуществлять обмен информацией между центральным офисом и филиалами. По мере
развития информационных и коммуникационных технологий мировому сообществу было
предложено несколько различных механизмов осуществления координационных
действий путем централизации управления и разделения ресурсов.
Одним из таких механизмов, заслуживающим особого
внимания является служба каталогов Active Directory. «Активный каталог» -
служба каталогов корпорации Microsoft, разработанная для операционных систем
семейства Windows NT. Active Directory позволяет администраторам использовать
групповые политики для обеспечения единообразия настройки пользовательской
рабочей среды, разворачивать программное обеспечение на множестве компьютеров
через групповые политики или посредством System Center Configuration Manager
(ранее Microsoft Systems Management Server), устанавливать обновления
операционной системы (ОС), прикладного и серверного программного обеспечения
(ПО) на всех компьютерах в сети, используя Службу обновления Windows Server
[5]. Поскольку данная служба каталогов хранит данные и настройки среды в
централизованной базе данных, а для аутентификации пользователей по умолчанию
используется надежный протокол Kerberos, это позволяет использовать данный
механизм не только в коммерческих компаниях, но и в сферах, требующих
повышенной защиты. А интегрирование службы Active Directory с DNS и стеком
протоколов TCP/IP в значительной степени упрощает развертывания и настройку
данной службы каталогов для сетевых администраторов.
Представление Active Directory состоялось в 1999
году, продукт был впервые выпущен с Windows 2000 Server, а затем подвергался
модификации и улучшению при выпуске всех последующих серверных операционных
систем семейства Windows Server, вплоть до Windows Server 2008 и Windows Server
2008 R2.
В ходе выполнения данной работы были рассмотрены
вопросы определения необходимого количество лесов для организации, порядка их
разбиения на домены, планирования доменного пространства имен организации и
структуры доменов, определены механизмы разделения ресурсов компании по
организационным подразделениям, рассмотрены основные вопросы (проблемы)
конфигурации сайтов и разработана стратегия для управления учетными записями
пользователей компании, а также произведено тестовое развертывание
разработанной модели каталога Active Directory на база серверной операционной
системы Windows Server 2008 применительно к центральному офису компании.
1.Определение количества лесов для
сети компании
.1 Определение леса
Очевидно что, прежде чем реализовывать серверную
инфраструктуру на предприятии и с целью избежать большинства неприятных
моментов по окончанию развертывания, ее следует тщательно спланировать. При
планировании структуры Active Directory первым вопросом, которые необходимо
решить является вопрос определения необходимого количества лесов.
Согласно определению, лесом называется набор из
одного либо нескольких доменов Active Directory (административных единиц внутри
которых совместно используются определенные возможности и характеристики), не
образующих непрерывного пространства имен. Он представляет собой наивысший
уровень иерархии логической структуры доменных служб. Первый установленный в
лесу домен называется корневым. Лес содержит единственное описание конфигурации
и один экземпляр каталога схемы, хранящийся в корневом домене. В связи с этим
крайне нежелательным является переименование или удаление корневой домен,
поскольку это повлечет за собой удаление всего леса Active Directory [4].
Леса представляют собой крайние границы зон
безопасности. Между лесами невозможно административное управление или
пользовательский доступ, если на то нет явного разрешения в конфигурации. Для
этого предназначен тип доверия, введенный в Windows Server 2003, - доверие к
лесу (forest trust), применяемый при управлении отношениями между двумя лесами.
Доверительные отношения - это специальный
механизм, позволяющий объектам в одном домене/лесе (доверяемом) обращаться к
ресурсам в другом (доверяющем). При этом стоит отметить, что доверие к лесу не
является транзитивным на уровне лесов, т.е., если первый лес доверяет второму,
а второй - третьему, то это еще не означает, что первый автоматически доверяет
третьему. Также необходимо учитывать, что для использования доверия к лесу
нужно, чтобы оба леса находились на функциональном уровне Windows 2008 - все
контроллеры доменов в обоих лесах должны работать под управлением Windows
Server 2008 [2].
Таким образом, становиться очевидным, что
определение количества лесов в сети компании, а также последующий выбор модели
их построения являются ключевыми задачами в процессе развертывания службы
каталогов Active Directory, в значительной степени определяющих в последствие
уровень эффективности управления ресурсами сконструированной сетевой
инфраструктуры. Поэтому при планировании будущей структуры Active Directory в
первую очередь следует провести инвентаризацию существующей инфраструктуры
предприятия и на базе анализа полученных результатов обследования определить
перечень производственных требований, которым должна удовлетворять
разрабатываемая структура доменных служб. После определения полного перечня
производственных требований необходимо определить количество лесов в
планируемой схеме развертывания. В большинстве случаев наиболее часто
используемой структурой является Служба каталогов, основанная на едином лесе.
1.2 Единый лес
Данная модель является простейшей моделью леса и
считается низкоуровневой, так как все объекты каталога принадлежат одному лесу
и все сетевые ресурсы контролирует одна централизованная ИТ-группа. Такой
проект требует минимальных административных расходов и считается самым
рентабельным среди всех моделей. Модель одного леса является удачным выбором
для малых и средних организаций, где действует лишь одна ИТ-группа и все ее
филиалы управляются этой группой из центрального офиса [3].
Преимущества:
Возможность сотрудничества: обмен электронными
сообщениями, общий доступ к Интернет-сети, общие документы, общий механизм
аутентификации, авторизации и поиска.
Аутентификация Kerberos: обеспечивает обоюдную
аутентификацию и делегирование полномочий.
Автоматические транзитивные доверительные
отношения: между всеми доменами в лесе созданы транзитивные доверительные
отношения в иерархическом порядке.
Один глобальный каталог объектов: информация
всех объектов леса сохраняется в каталоге, в котором можно выполнять поиск.
Низкая стоимость.
Недостатки
Невозможность обеспечить независимость от
владельцев служб: невозможность обеспечить автономность службы одного леса,
если нет согласия в настройке конфигурации службы.
Невозможно обеспечить изоляцию от владельцев
служб: администратор организации может аннулировать параметры безопасности,
установленные владельцами отдельных доменов.
Проблемы репликации из-за больших объемов каталога:
проблема информации уровня леса, подлежащего репликации, в частности данные
конфигурации и схема; проблема репликации информации глобального каталога на
все серверы глобальных каталогов леса; при избытке информации репликация
становится недопустимо медленной
1.3 Несколько лесов
В некоторых случаях, модель построения единого
леса не способна удовлетворить всех предъявляемых в организации требований и
необходимо использовать схему построения нескольких лесов.
Реализация данной структуры допускается в следующих
случаях:
Объединение двух существующих организаций
Независимо от того, слияние это или поглощение,
можно столкнуться с тем, что появятся два полностью раздельных леса, которые
нужно связать друг с другом для совместного использования ресурсов.
) Создание автономного подразделения.
Поскольку леса являются крайними зонами
безопасности, отдельный лес можно использовать для того, чтобы создать сеть, в
которой администрирование в значительной мере независимо от основного леса. В
таком случае для отдельного леса схема может поддерживаться и изменяться, не
оказывая влияния на другие леса.
Административная автономия предполагает полный
административный контроль над некоторыми компонентами леса на уровне леса,
домена или подразделения. Тем не менее, автономия не означает получения
эксклюзивного контроля. Существуют администраторы с более широкими
полномочиями, которые тоже могут управлять этими ресурсами и при необходимости
могут лишить полномочий подчиненных администраторов.
Создание изолированного подразделения
Административная изоляция предполагает получение
эксклюзивного контроля над компонентом каталога. В случае административной
изоляции никто, кроме указанных администраторов не может получить права
управлять ресурсами, и никто из администраторов не может лишить их этих прав.
Однако, прежде чем приступить к планированию
структуры нескольких лесов, необходимо принять к сведению, что большая часть
функциональности, доступной в пределах одного леса, недоступна между лесами.
Кроме того, поддержка нескольких лесов требует значительно больше усилий в
администрировании, чем поддержка одного леса [2].
Архитектура с несколькими лесами имеет следующие
недостатки:
При поиске ресурсов от пользователей требуется
более высокий уровень подготовки.
Сотрудники, которым требуется входить на
компьютеры, включенные во внешние леса, должны указывать при входе основное имя
пользователя (User Principal Name, UPN) по умолчанию.
Администраторам приходится хранить несколько
схем.
Для каждого леса используются отдельные
контейнеры конфигурации. Изменения в топологии необходимо реплицировать в
другие леса.
Любую репликацию информации между лесами
приходится настраивать вручную.
Администраторам приходится настраивать списки
управления доступом (ACL) к ресурсам, чтобы соответствующие группы из разных
лесов могли обращаться к этим ресурсам, а также создавать новые группы, чтобы
можно было использовать роли одних лесов в других лесах.
Часто для наблюдения за отдельными лесами и
управления ими нужен дополнительный персонал, а значит расходуются средства на
подготовку большего штата сотрудников и на оплату их труда.
В соответствие с данными задания компания
«Рога&Копыта» осуществляет свою деятельность на территории Украины и имеет
древовидную топологию объединяющая центральный офис, находящийся в г. Киеве, с
региональными центрами: западный (Львов), восточный (Донецк), центральный
(Чернигов), южный (Симферополь), а региональные центры - с областными
подразделениями. При этом в соответствие с основными задачами центрального
подразделения компании головной офис должен обеспечивать и организовывать
производственную деятельности компании, вести финансово-коммерческую
деятельность и координировать и организовывать работы региональных центров.
Очевидно, что для выполнения данных целевых задач, структурная схема каталога
Active Directory должна предоставлять возможности централизованного управления
всей деятельностью компании, включая удаленные филиалы. Кроме того,
коммерческая компания «Рога&Копыта» имеет единый центр управления, а
региональные центры являются подотчетными центральному офису организации и не
нуждаются в административной автономии либо изоляции. В связи с этим наиболее
предпочтительной моделью развертывания Службы каталогов представляется Модель
единого леса.
2.Определение
порядка разбиения лесов
После определения количества лесов организации
необходимо определить порядок его разбиения на домены и детализацию доменной
структуры в пределах каждого из лесов.
Домен - единая область, в пределах которой
обеспечивается безопасность данных в компьютерной сети под управлением ОС Windows.
Это важнейшая часть в иерархической структуре корпоративной сети. Ей подчинены
абсолютно все остальные структурные единицы, такие как серверы, приложения,
пользовательские устройства и даже сетевые принтеры. Они используются для
разделения большого леса на более мелкие компоненты для целей репликации или
администрирования и являются основным и важнейшим элементом логической
структуры Службы каталогов [1].
Основными свойствами домена, которые необходимо
учитывать при планировании доменной структуры являются:
) Граница репликации: границы домена
являются границами репликации для раздела домена каталога и для информации
домена, хранящейся в папке Sysvol на всех контроллерах домена. В то время как
другие разделы каталога (раздел схемы, конфигурации и GC) реплицируются по
всему лесу, раздел каталога домена реплицируется только в пределах одного
домена.
2) Граница доступа к ресурсам: границы
домена являются также границами для доступа к ресурсам. По умолчанию пользователи
одного домена не могут обращаться к ресурсам, расположенным в другом домене,
если только им не будут явно даны соответствующие разрешения.
3) Граница политики безопасности: некоторые
политики безопасности могут быть установлены только на уровне домена, например,
политика паролей, политика блокировки учетных записей и политика билетов
Kerberos, применяются ко всем учетным записям домена.
В первую очередь при определении доменной
структуры в пределах леса необходимо определить один из двух вариантов организации
доменной структуры, а именно: разворачивать один домен или несколько.
2.1 Применение одного домена
Простейшая модель Active Directory -
единственный домен. В модели с единственным доменом все объекты находятся в
одной зоне безопасности, поэтому не приходится заниматься планированием
доверительных отношений с другими доменами или реализовать кросс-доменные
аутентификацию и разрешения. Кроме того, при использовании одного домена
гораздо проще обеспечить централизованное управление сетью. Модель с единственным
доменом упрощает управление пользователями и группами, а также реализацию
групповых политик. По сути, становится легче выполнять почти все операции по
управлению сетью, а значит, требуется меньше усилий на планирование,
администрирование и устранение неполадок, что в итоге приведет к сокращению
общих затрат [2].
Преимущества:
упрощение управления пользователями и группами.
нет необходимости планировать доверительные
отношения.
для делегирования прав применяются
организационные подразделения.
Недостатком использования модели с единым
доменом в лесу можно назвать сложность технической реализации развертывания
одного домена и непрактичность данного решения в случае большой территориальной
распределенности ресурсов производственной компании, для которой выполняется
развертывание Службы каталогов.
Поскольку производственно - коммерческая
компания «Рога&Копыта» осуществляет свою деятельность на всей территории
Украины и имеет многоуровневую и хорошо разветвленную древовидную структуру
организации филиалов, использование схемы развертывания леса с единым доменном
представляется экономически, технически и организационно нецелесообразным.
2.2 Использование нескольких доменов
Хотя однодоменная модель дает существенное
преимущество - простоту, иногда приходится использовать несколько доменов.
Использование многодоменной структуры леса является предпочтительным в тех
случаях, если:
) Трафик репликации должен быть ограничен:
раздел каталога домена, который является самым большим и наиболее часто
изменяемым разделом каталога, копируется на все контроллеры домена в домене.
) Между офисами компании существуют медленные
сетевые подключения или в офисах имеется много пользователей: единственный
способ ограничить в этом случае трафик репликации состоит в том, чтобы создать
дополнительные домены.
) Любые офисы компании, связь между которыми
обеспечивается только простым протоколом передачи почты (SMTP), должны
конфигурироваться как отдельные домены: информация домена не может
реплицироваться через связи сайта, использующие протокол SMTP.
) Единственный способ иметь различную политику
паролей, политику блокировки учетных записей и политику билетов Kerberos
состоит в развертывании отдельных доменов.
) Необходимо ограничивать доступ к ресурсам и
иметь административные разрешения.
) В некоторых случаях дополнительные домены
создаются потому, что лучший путь перехода для организации состоит в
модернизации нескольких уже имеющихся доменов.
При этом стоит отметить, что лучше планировать
домены так, чтобы все они входили в одно дерево доменов. Под доменным деревом
понимается набор доменов, имеющих общую логическую структуру и конфигурацию, и
образующих непрерывное пространство имен. Так как все домены в одном дереве
делят одно пространство имен, административные издержки будут значительно ниже,
чем при использовании нескольких деревьев[2].
возможность реализации разных политик
безопасности.
децентрализованное управление.
оптимизация трафика.
разные пространства имен.
необходимо сохранить существующую архитектуру
доменов Windows NT.
размещение хозяина схемы в отдельный домен.
Поскольку производственно - коммерческая
компания «Рога&Копыта» имеет территорильно-распределенную организационную
структуру более предпочтительной моделью разбиения леса представляется
проектирование нескольких доменов в соответствие с территориальным признаком.
В случае выбора многодоменной модели разбиения
леса следующим шагом в процессе планирования структуры Службы каталогов
компании является выбор одной из нижеприведенных моделей построения лесов,
определяющих доменную структуру леса и иерархию отношений между доменами.
Возможные модели построения лесов приведены в Приложении В.
На основе анализа приведенных моделей построения
леса для рассматриваемой компании «Рога &Копыта» наиболее целесообразной
представляется модель единого леса, в котором каждый регион являться дочерним
доменом центрального домена. Данный выбор основывался на следующих выводах:
) Поскольку, региональные домены являются
дочерними, между ними и центральным офисом автоматически создаются транзитивные
доверительные отношения, что избавляет администратора от ручного
конфигурирования доверия между доменами, как этого требую иные две модели;
) Сокращение количества компьютеров -
контроллеров домена из-за отсутствия корневого "пустого" домена, что
в свою очередь ведет к снижению экономических затрат на развертывание и
поддержания доменной структуры;
) Структурное подчинение регионов,
позволяющие реализацию централизованного управления филиалами из головного
офиса.
3.Определение порядка назначения
доменных имен и проектирование инфраструктуры DNS
.1 Общие сведения
Следующим этапом планирования развертывания
службы каталогов является проектирование инфраструктуры DNS.
DNS (англ.
<#"700622.files/image001.gif">
Рис.3.1 - Иерархия DNS
В сети Windows Server 2008 с
доменными службами Active Directory (AD DS) каждое
связанное с каталогом устройство также будет связано с системой разрешения имен
DNS, на которую
оно будет полагаться при идентификации всех служб во время взаимодействия.
Например, при загрузке компьютера, присоединенного к домену, выполняется
стандартный процесс, который начинается с идентификации записей ресурсов SRV (Service Location Record) на DNS-сервере для
определения ближайшего контроллера домена. Затем, после выполнения системой DNS своей части
работы, начинается процесс проверки подлинности между компьютером и
контроллером домена. Однако без разрешения системой DNS имен
записей ресурсов SRV службам AD DS будет
довольно сложно выполнить проверку подлинности рядового компьютера [1].
Однако, поскольку в службе Active
Directory все домены имеют DNS-имена, прежде чем использовать данную службу в
сети, необходимо спланировать пространство имен DNS. Ключевое решение проекта
состоит в том, чтобы определить, где расположить домены Active Directory в
пределах этого пространства имен[2]. Проектирование инфраструктуры DNS состоит
из нескольких этапов.
3.2 Исследование существующей
инфраструктуры DNS
Первый шаг в проектировании инфраструктуры DNS
должен состоять в исследовании уже имеющейся инфраструктуры DNS. В большинстве
случаев служба DNS в Active Directory должна взаимодействовать с имеющейся инфраструктурой
DNS. Это может означать просто конфигурирование ретранслятора в существующем
сервере DNS, использование имеющегося DNS-сервера как основного для Active
Directory или отсутствие развертывания DNS в Windows Server 2008. Active
Directory требует, чтобы работала служба DNS, однако существует несколько
вариантов ее развертывания [5].
3.3 Выбор доменных имен DNS
При настройке DNS-серверов рекомендуется сначала
выбрать и зарегистрировать уникальное родительское имя DNS, которое будет
представлять организацию в Интернете. Это имя является доменом второго уровня
внутри одного из доменов верхнего уровня, используемых в Интернете.
Родительское имя DNS можно соединить с именем местоположения или подразделения
внутри организации для формирования других имен доменов следующих уровней.
Для внедрения Active Directory существуют два
вида пространств имен (внутреннее и внешнее), при этом пространство имен Active
Directory совпадает с заданным зарегистрированным пространством имен DNS или
отличается от него.
3.4 Совпадающие внутреннее и внешнее
пространства имен
Согласно этому сценарию, организация использует
одно и то же имя для внутреннего и внешнего пространств имен - имя компании
применяется как внутри, так и вне организации. При реализации этого сценария пользователи
внутренней частной сети компании должны иметь доступ как к внутренним, так и к
внешним серверам (по обе стороны брандмауэра). Для защиты конфиденциальной
информации клиенты, осуществляющие доступ извне, не должны иметь доступ к
внутренним ресурсам компании или иметь возможность разрешать свои имена. Кроме
того, необходимы две раздельные зоны DNS, одна из которых, за пределами
брандмауэра, обеспечивает разрешение имен для общедоступных ресурсов. Она не
сконфигурирована для разрешения имен внутренних ресурсов, поэтому доступ к ним
извне получить нельзя [2].
3.5 Отличающиеся
внутреннее и внешнее пространства имен
В этом случае компания использует различные
внутреннее и внешнее пространства имен - изначально в зонах по разные стороны
брандмауэра имена различаются. Для этого необходимо зарегистрировать два
пространства имен в DNS Интернета. Если имя не зарезервировано, внутренние
клиенты не смогут отличить внутреннее имя от имени, зарегистрированного в
общедоступной сети пространства имен DNS. Таким образом, устанавливаются две
зоны: одна отвечает за разрешение имен во внешнем пространстве, другая - во
внутреннем. Пользователям не составит труда различать внутренние и внешние
ресурсы [1].
Для рассматриваемой в данной работе
производственной компании «Рога&Копыта», основной задачей которой является
осуществление производственно-коммерческой деятельности на территории Украины,
что автоматически предусматривает предоставление авторизованным клиентам
доступа к определенным выделенным ресурсам компании предлагается выбрать модель
Совпадающего внутреннего и внешнего пространства имен. Выбор данной модели
предполагается экономически более целесообразным, поскольку не требует
дополнительных расходов на регистрацию второго пространства имен. Возникающие
же при выборе данной модели вопросы защиты конфиденциальной информации
предприятия предлагается решить за счет разработки и последующего внедрения
соответствующей политики безопасности, предполагающей, в частности,
предоставление доступа только авторизованных клиентов компании и только к
ограниченному списку ресурсов предприятия.
Результаты проектирования порядка назначения
доменных имен представлены в Приложении Г. Разработанная в соответствие с
выбранными ранее моделями построения единого леса, в котором каждый домен
является дочерним доменом центрального домена, предлагает назначение доменных
имен в соответствие с территориальным признаком. Для центрального домена
предлагается выбрать имя RGCenter.Gonchar.com,
для дочерних доменов, являющихся региональными центрами, имена,
указывающие территориальное положение региона в соответствие со стороной света
- South.RGCenter.Gonchar.com,
West. RGCenter.Gonchar.com,
East. RGCenter.Gonchar.com
и North. RGCenter.Gonchar.com.
3.6 Проектирование структуры OU
После определения структуры домена организации и
планирования доменного пространства имен необходимо разработать структуру
организационных единиц (organizational unit (OU) или подразделений - ОП). OU
позволяют разделить домен на зоны административного управления, т.е. создавать
единицы административного управления внутри домена [1].
Проектирование OU позволяет:
) Отразить структуру компании и организации
внутри домена: без OU все пользователи поддерживаются и отображаются в одном
списке независимо от подразделения, местоположения и роли пользователя;
) Делегировать управление сетевыми ресурсами, но
сохранить способность управлять ими, то есть присваивать административные
полномочия пользователям или группам на уровне OU;
) Изменять организационную структуру компании;
) Группировать объекты так, чтобы администраторы
легко отыскивали сетевые ресурсы.
На основе анализа существующей
организационно-штатной структуры компании, необходимо определить структуру
доменов и порядок делегирования административные полномочий. Можно создать
иерархию OU в домене: в отдельном домене разместить пользователей и ресурсы,
повторив структуру компании в конкретном подразделении. Таким образом, можно
создать логичную и осмысленную модель организации и делегировать
административные полномочия на любой уровень иерархии. При этом в каждом домене
разрешается внедрять собственную иерархию OU.
Стоит отметить, что при планировании иерархии OU
важно соблюсти следующие правила:
Хотя глубина иерархии OU не ограничена,
производительность мелкой иерархии выше, чем глубокой.
OU должны отражать неизменные структурные
единицы организации.
При этом особое внимание следует уделить второму
пункту, ведь если несоблюдение первого правила может оказать влияние лишь на
скорость обработки информации в системе, то некорректно выбранные структурные
единицы организации, изменяющиеся со временем, могут создать для администратора
массу проблем, вплоть до полного переопределения структуры организационных
подразделений в домене.
Поскольку OU имеют иерархическую структуру в них
можно выделить верхний и нижний уровни. Особое внимание следует уделить
верхнему уровню структуры OU, который всегда должен отражать относительно
неизменную часть структуры предприятия, чтобы его не приходилось изменять в
случае реорганизации [3].
На этапе планирования развертывания Active
Directory важно определить на основание какого критерия или критериев будет
разрабатываться структура OU компании. Стандартных модели, которые могут быть
положены в основу иерархии OU приведены в Приложении Д.
Для рассматриваемой в данной работе
производственной компании «Рога&Копыта» предполагается использовать две
различные модели для центрального и региональных доменов. В центральном домене
предлагается выбрать Модель структуры OU на основе структуры организации, поскольку
она позволяет обеспечивать определенный уровень автономии для каждого отдела и
упрощенное администрирование. Для региональных же доменов предлагается
использовать Смешанную модель структуры OU - сначала по местоположению, затем
по структуре организации. Данный выбор позволяет отразить структуру компании
внутри каждого домена и упрощает для администраторов обеспечение различных
требований безопасности каждого из отделов организации. Это является весьма
важным фактором, поскольку в ряде отделов рассматриваемой в работе организации
предполагается циркулирование конфиденциальной информации не предназначенной
для широкого пользования. А использование в смешанной модели распределения OU
вначале по местоположению позволяет отразить географическое местоположение филиалов,
а также способствует устойчивости модели в случае реорганизации. Результаты
разработки структуры OU компании «Рога&Копыта» представлены в Приложении Е.
4.Разработка стратегии управления
учетными записями пользователей и группами безопасности на предприятии
Следующим этапом в планировании развертывания
Службы каталогов Active
Directory после определения
механизма разделения ресурсов компании по организационным подразделениям
является разработка стратегии управления учетными записями пользователей компании
и требований к группам безопасности предприятия.
Принципалы безопасности (Security Principal),
которые предоставляют пользователей, группы или компьютеры, которым требуется
доступ к определенным ресурсам в сети, являются основополагающим компонентом
доменных служб в каждой организации. Именно таким объектам, как принципалам
безопасности можно предоставлять разрешения доступа к ресурсам в сети, причем
каждому принципалу во время создания объекта присваивается уникальный
идентификатор безопасности (SID) - числовое представление, которое уникально
идентифицирует принципал безопасности [3].
Несмотря на то, что планирование и развертывание
инфраструктуры доменных служб в большинстве организаций выполняется лишь один
раз и в большинство объектов изменения вносятся очень редко, к важному
исключению из этого правила можно отнести принципалы безопасности, которые
необходимо периодически добавлять, изменять, а также удалять. Одним из
основополагающих компонента идентификации являются учетные записи пользователей.
4.1 Учетные записи пользователей
По сути, учетные записи пользователей
представляют собой физические объекты, в основном людей, которые являются
сотрудниками организации, но бывают исключения, когда учетные записи
пользователей создаются для некоторых приложений в качестве служб. Учетные
записи пользователей играют важнейшую роль в администрировании предприятии.
Объекты учетных записей пользователей можно
отнести к самым распространенным объектам в Active Directory. Такие объекты
представляют собой набор атрибутов, причем только одна пользовательская учетная
запись может содержать свыше 250 различных атрибутов, что в несколько раз
превышает количество атрибутов на рабочих станциях и компьютеров, работающих
под операционной системой Linux. Важно обратить внимание на то, что одни
атрибуты являются обязательными (основными), а остальные опциональными
(вспомогательными). Основных атрибутов
учетной
записи
шесть:
CN (Full name), SAM Account Name (User Logon Name), Instance Type, Object
Category, Object Class, Object SID. Первые два
вышеперечисленных атрибута конфигурируются на основе данных, обеспечиваемых при
создании учетной записи, а остальные конфигурируются автоматически.
Учетные записи пользователей позволяют
идентифицировать пользователей, входящих в сеть, задавать, к каким ресурсам они
вправе обращаться, и указывать о них всевозможную информацию. Администраторы
также являются пользователями, но с более широкими правами доступа к ресурсам,
связанным с управлением сетью. Учетные записи пользователей предоставляют
пользователям возможность входить в домен или на локальный компьютер и
обращаться к ресурсам. Объекты учетных записей пользователей содержат
информацию о пользователях и связывают с ними определенные привилегии или
ограничения. Каждый объект Active Directory связан со списком управления
доступом (AccessControl List, ACL), который представляет собой список
разрешений на доступ к объекту, заданных для пользователей и групп [2].
В Windows Server 2008 существует два основных
типа учетных записей пользователей:
Локальные учетные записи пользователей,
создаваемые в базе данных защиты локального компьютера и управляющие доступом к
ресурсам этого компьютера, являющегося изолированным или входящим в рабочую
группу.
Доменные учетные записи пользователей, создаваемые
в Active Directory и дающие возможность пользователям входить в домен и
обращаться к любым ресурсам сети. Такие учетные записи пользователей
реплицируются на все контроллеры в домене, поэтому после репликации любой
контроллер домена сможет аутентифицировать пользователя.
Помимо этих учетных записей, Windows Server 2008
автоматически создает несколько таких учетных записей пользователей, которые
называются встроенными. И на локальных компьютерах, и в доменах создается две
ключевые учетные записи Администратор и Гость [6].
Тщательное планирование схемы именования учетных
записей пользователей позволяет стандартизировать идентификацию пользователей
домена. Единое соглашение также облегчает распознавание и запоминание имен
пользователей.
Контроллеры домена должны проверять
идентификацию пользователя или компьютера, прежде чем предоставить доступ к
системным и сетевым ресурсам. Такая проверка называется аутентификацией и
выполняется всякий раз при входе в сеть.
При планировании стратегии аутентификации с целью
исключения уязвимостей сети, связанных с политикой управления учетными записями
пользователей, необходимо соблюдать ряд нижеприведенных правил:
политика блокировки учетных записей;
ограничение времени, в которое разрешен вход;
политика истечения сроков билетов (tickets)
(значение по умолчанию - 10 часов);
не использовать административные учетные записи
для обычной работы.
переименовать или отключить встроенные учетные
записи.
Еще одним важнейшим аспектом, на котором
строится сетевая безопасность являются пароли, поскольку при аутентификации
пользователь удостоверяет свою личность введением своего логина и пароля. В
связи с этим политику определения паролей пользователей необходимо тщательно
продумать и жестко регламентировать, программно ограничив рядовому пользователю
любые возможности несоответствия предъявляемым политикой паролей требованиям
[2].
4.2 Стратегия управления учетными
записями пользователей компании
Создание учетных записей пользователей Active
Directory может
осуществляться путем использования одной из нижеследующих средств:
через интерфейс средствами оснастки Active
Directory
Users and
Computers; - посредством
команды командной строки (dsadd);
через утилиты CSVDE и LDIFDE;
Кроме того, при создании учетной записи
пользователя через интерфейс средствами оснастки Active
Directory
Users and
Computers для создания
нескольких типовых пользователей могут быть использованы шаблоны учетных
записей пользователей. Это специально созданные, отключенные учетные записи,
содержащие уже настроенные типовые установки и свойства.
Таким образом, основываюсь на анализе
существующей организационный структуры рассматриваемого в работе предприятия, а
также на базе вышеозначенных правил и рекомендаций по разработке стратегии
управления учетными записями пользователями, были разработаны и предложены
следующие основные элементы механизма управления учетными записями для
предприятия «Рога&Копыта».
. Поскольку численность центрального
подразделения компании составляет 100 человек, а количество рабочего персонала
в каждом из 26 структурных (областных) подразделений компании насчитывается в
диапазоне от 300 до 500 человек, для упрощения создания учетных записей
пользователей в каждом из организационных подразделений предлагается создать
шаблоны учетных записей пользователей с базовыми настройками, соответствующими
характеристикам персонала соответствующего отдела предприятия. Таким образом,
при добавлении новых работников в отдел администратору не нужно будет задавать
весь перечень свойств новой учетной записи, а лишь изменить некоторый типовые
настройки.
. При назначении основного имени
пользователя UPN
придерживаться следующего формата: Инициалы.Фамилия.Должность, с целью
облегчения идентификации и запоминания имен пользователей.
. Все учетные записи пользователей, за
исключением учетных записей верховного административного менеджмента
предприятия, должны быть срочными и реактивироваться администратором раз в 3
месяца.
. Разрешенное время входа в домен для
всех учетных записей пользователей без исключения ограничивается рабочим
временем предприятия - с 8:00 до 20:00 в будние дни и запрещено в выходные.
. Пароль учетных записей пользователей
должен быть не менее 10 символов для пользователей группы Рабочие, не менее 15
символов - для участников группы Руководители отделов и не менее 17 символов
для членов групп Президенты и административных учетных записей.
. Срок действия пароля 45
дней.
. Блокирование входа в случае 5-кратной
ошибки аутентификации для обычных пользователей и 3-кратной для пользователей,
входящих в группы Руководители отделов, Президенты и административных учетных
записей.
4.3 Планирование групп безопасности
Как уже было сказано ранее назначать доступ к
сетевым ресурсами рекомендуется группам, а не индивидуально для каждого
отдельного пользователя, поскольку в противном случае списки контроля доступа
ACL вскоре станут неуправляемыми и при изменении отдела пользователем
администратору нужно будет учесть все возможные разрешения доступа. Чаще всего
группы используются для идентификации ролей пользователей и компьютеров,
фильтрации групповой политики, назначения уникальных политик паролей, прав,
разрешений доступа, приложений электронной почты и многое другое. Сами по себе,
группы представляют собой принципалы безопасности с уникальными SID, которые
могут содержать в атрибуте Member такие принципалы безопасности, как
пользователи, компьютеры, группы и контакты.Directory включает в себя два типа
групп (безопасности и распространения) домена с тремя областями действия (локальная
в домене, глобальная и универсальная) в каждой из них.
Группы безопасности - относятся к принципалам
безопасности с SID-идентификаторами. В связи с этим данный тип группы считается
самым распространенным и группы такого типа можно использовать для управления
безопасностью и назначения разрешений доступа к сетевым ресурсам в списках ACL.
В свою очередь, группа распространения изначально используется приложениями
электронной почты, и она не может быть принципалом безопасности. Кроме того,
важно также отметить, что группы безопасности можно использовать как с целью
назначения доступа к ресурсам, так и с целью распространения электронной почты,
что в свою очередь позволяет организации использовать только этот тип группы
[3].
Область действия группы определяет диапазон, в
котором применяется группа внутри домена. Помимо того, что группы могут
содержать пользователей и компьютеры, они могут быть членами других групп,
ссылаться на списки ACL, фильтры объектов и групповых политик и пр. Граница
диапазона области действия группы может определяться заданием режима работы
домена [4].
В Active Directory существует три области
действия групп, рассмотрим подробнее каждую из них:
Локальная группа в домене - предназначена для
управления разрешениями доступа к ресурсам и функционируют в том случае, если
домен работает на функциональном уровне не ниже Windows 2000. Локальную группу
в домене можно добавлять в списки ACL любого ресурса на любом рядовом
компьютере домена. В локальную группу в домене могут входить пользователи,
компьютеры, глобальные и локальные группы в текущем домене, любом другом домене
леса, а также универсальные группы в любом домене леса. В связи с этим,
локальные группы в домене обычно используют для предоставления правил доступа
во всем домене, а также для членов доверительных доменов.
Глобальная группа - основной целью данной группы
безопасности является определение коллекции объектов доменов на основании
бизнес-правил и управление объектами, которые требуют ежедневного
использования. Глобальная группа может содержать пользователей, компьютеры и
другие глобальные группы только из одного домена. Несмотря на это, глобальные
группы могут быть членами любых универсальных и локальных групп как в своем
домене, так и доверяющем домене. Помимо этого, глобальные группы можно
добавлять в списки ACL в домене, лесу и в доверяющем домене, что делает
управление группами более простым и рациональным.
Универсальная группа - позволяет управлять
ресурсами, распределенными на нескольких доменах, поэтому универсальные группы
считаются самыми гибкими. Универсальные группы определяются в одном домене, но
реплицируются в глобальный каталог. Универсальная группа может быть членом
другой универсальной или локальной группы домена в лесу, а также может
использоваться для управления ресурсами. Эти группы целесообразно задействовать
только в лесах, состоящих из множества доменов для их объединения.
Стоит отметить, что после создания группы, ее
область действия можно изменить на вкладке «Общие» диалогового окна свойств
группы, преобразовав одну в другую. При этом важно отметить, что хотя
глобальную группу просто так невозможно модифицировать в локальную группу в
домене, возможно осуществить данное преобразование, преобразовав сначала
глобальную группу в универсальную, а затем уже получившуюся универсальную
группу - в локальную группу в домене.
4.4 Определение требование к группам
безопасности на предприятии
Группы безопасности упрощают предоставление
разрешений пользователям, поскольку назначить разрешения группе и добавить
пользователей в эту группу гораздо проще, чем по отдельности назначать
разрешения многочисленным пользователям и управлять этими разрешениями, а когда
пользователи входят в группу, для изменения того или иного разрешения всех этих
пользователей достаточно одной операции. В связи с этим для управления
разрешениями доступа к ресурсам производственной компании «Рога&Копыта»
приняты следующие решения:
. Поскольку верховный административный
менеджмент предприятия должен иметь неограниченный доступ к информационным
ресурсам предприятия от президента до начальников региональных центров компании
(Приложение А), к группе безопасности, в которую должны входить учетные записи
этих пользователей предъявляются следующие требования:
назначенные разрешения должны действовать при
попытке доступа к ресурсам нескольких доменов;
группа должна существовать вне границ доменов;
в группу могут входить пользователей и другие
группы в пределах леса.
Этим требованиям в полной мере соответствует
универсальны группа безопасности, в связи с чем, для верховного
административного менеджмента предприятия предлагается создать в центральном
домене универсальную группу Президенты.
. Поскольку требования к безопасности, а
также разрешения доступа к ресурсам компании для руководителей отделов
отличаются от разрешений предоставляемых верховному административному
менеджменту, но в то же время им предполагается разрешенный доступ к ряду
конфиденциальных данных, функционирующей в компании для них предлагается
создать отдельную глобальную группу безопасности Руководители отделов. Учетные
записи пользователей, которым также разрешен доступ к конфиденциальной
информации предприятия, являющихся сотрудниками секретных отделов, например,
отдела информационной безопасности, также предлагается включить в данную
группу, поскольку они имеют тот же уровень доступа и, как следствие к ним
выдвигаются идентичные требования политики безопасности компании.
. Поскольку рядовой персонал центрального
офиса и подразделений не требуется доступ к ресурсам компании вне пределов их
домена, для них предлагается создавать локальную группу безопасности Рабочие.
5.Конфигурация
сайтов
Финальным этапом в планировании развертывания
Службы каталогов Active
Directory является
определение физической инфраструктуры компании и планирование на ее основе
конфигурации сайтов, позволяющей оптимизировать трафик Службы каталогов,
протекающий в компьютерной сети предприятия.
Сайт - это группа контроллеров домена, которые
расположены в единой или нескольких IP-подсетях, связанных быстрым и надежным
сетевым соединением. Поскольку сайты основаны на IP-подсетях, они обычно
соответствуют топологии сети, а значит соответствуют и географической структуре
компании. Сайты соединяются с другими сайтами WAN-каналами. Если домены Active
Directory - основные элементы логической структуры Службы каталогов, то сайты
являются элементами физической структуры.
Таким образом, структура сайта связана с
физической средой и поддерживается отдельно от логической среды и структуры
домена, позволяя отделить логическую организацию структуры каталогов (структуры
лесов, доменов и OU) от физической структуры сети. Стоит отметить, что
поскольку сайты не зависят от структуры доменов, в один домен может входить
несколько сайтов, или, наоборот, один сайт может содержать несколько доменов или
частей нескольких доменов. Сайты содержат объекты только двух типов: контролеры
доменов, входящие в сайт, и связи сайтов (site links), настраиваемые для
соединения с другими сайтами [2]. В целом сайты служат для управления трафиком
по WAN-каналам. Основная задача сайта - обеспечивать хорошее сетевое
соединение.
5.1 Планирование структуры сайта
Из вышеприведенных данных очевидно, что задача
планирования структуры сайтов предприятия сводиться главным образом к
оптимизация трафика, порождаемого работой развертываемой Службы каталогов, а
именно: регистрации рабочей станций и репликации каталогов. При этом следует
учитывать, что чтобы задать регистрацию рабочей станции только на определенных
контроллерах доменов, необходимо спланировать сайты так, чтобы только эти
контроллеры доменов располагались в той же подсети, что и рабочая станция.
Основной информацией, учитываемой при разработке
конфигурации сайтов являются данные
о физической структуре сети и сведения о
выбранной ранее логической архитектуре Active Directory.
5.2 Создание модели сайта
Как только информация о сети компании собрана,
можно приступать к проектированию сайта. После определения количества сайтов
для Active Directory осуществляется проектирование каждого сайта. Каждый сайт в
ActiveDirectory связан с одной или более подсетями IP, поэтому нужно
определить, какие подсети будут включены в каждый сайт. Также при
проектировании сайта необходимо определить места размещения серверов,
необходимых для обеспечения нужных служб каталога Active Directory, среди
которых особо важными являются:
) DNS-сервера
Без службы DNS пользователи не смогут находить
контроллеры домена Active Directory, а контроллеры домена не смогут находить
друг друга для репликации. DNS должна быть развернута в каждом офисе
организации, за исключением, быть может, только очень маленьких офисов с
несколькими пользователями [1].
2) Контроллеры домена
Как правило, контроллеры домена следует
располагать в большинстве офисов компании, где есть значительное количество
пользователей, поскольку, в случае отказа в сети это позволить пользователям
все равно войти в сеть, а также даст гарантию, что трафик входа клиентов в
систему не будет пересекаться с WAN-подключениями к различным офисам. При этом
важно помнить, что при развертывании контроллера домена в отдельном филиале
необходимо создать и сайт, чтобы весь трафик входа в систему остался в пределах
сайта. Однако, если филиал не имеет никаких средств физической защиты серверов,
размещение в нем контроллера домена является крайне нежелательным, поскольку
несет прямую угрозу безопасности компании в целом [4].
) Сервера глобального каталогасерверы
нужны пользователям для входа на домены, которые работают на функциональном
уровне Windows 2000, или когда пользователи делают поиск информации каталога в
Active Directory. Если домен работает на основном функциональном уровне Windows
2000, то нужно поместить GC-сервер в каждый сайт. В идеале все это должно быть
сбалансировано трафиком репликации, который создается в результате помещения GC-сервера
в каждом сайте. Общее правило состоит в том, чтобы размещать GC-сервер в каждом
сайте и несколько GC-серверов - в крупных сайтах [2].
) Сервера хозяев операций
Мастера операций (роли контроллеров) разделяются
на:
) Роли хозяина операций, которые могут
быть назначены едином контроллеру домена в лесу (действующие в границах леса):
хозяин схемы - первый контроллер домена в лесу,
отвечающий за поддержку распространения схемы на остальную часть леса, а также
поддерживающий списки всех возможных классов объектов и атрибутов;
хозяин именования доменов - контролер домена,
протоколирующий добавление и удаление доменов в лесу, является жизненно
необходимым для поддержания целостности доменов.
) Роли хозяина операций, которые могут быть
назначены одному из контроллеров в каждом домене (общедоменные роли):
хозяин RID - контролер домена, отвечающий за
выделение диапазона относительных идентификаторов RID всем контроллерам в
домене;
эмулятор основного контроллера домена -
контролер домена, оперирующий в качестве основного контролера домена для ОС
ниже Windows
2000;
хозяин инфраструктуры - контролер домена,
регистрирующий изменения, вносимые в контролируемые объекты в домене [1].
Основываясь на анализе существующей
географической топологии рассматриваемого в данной работе предприятия, а также
на базе вышеприведенных теоретических сведений и рекомендаций были предложены
нижеследующие аспекты планирования сайтов:
) С целью оптимизации трафика регистрации
рабочих станций в каждом филиале предполагается разместить собственный
контроллер домена и выделить его в отдельный сайт.
2) DNS-сервер
также будет располагаться в каждом филиале.
) Поскольку все домены планируемого леса
будут работать на функциональном уровне Windows 2008 от размещения сервера
глобального каталога в каждом филиале принято решение отказаться,
установив
по одному на каждый домен.
) Сервера хозяев операций, действующих в
границах леса, предлагается установить в центральном офисе компании,
соответствующему центральному домену.
) Сервера общедоменных хозяев операций
предлагается разместить в офисах региональных центров предприятия за исключения
эмулятора основного контроллера домена.
Разработанная схема конфигурации сайтов, на
примере одного из регионов, с указанием стоимостных связей сайтов приведена в
Приложении Ж.
6.Развертывание
тестовой среды Active
Directory
Процесс установки серверной ОС Windows
Server 2008, выполнения
послеустановочных настроек, а также установка роли Active
Directory
Domain Services
приведены в Приложении З. Теперь необходимо развернуть лес и первый домен в
соответствие со спланированной ранее структурой. Для этого осуществляем
последовательный переход Start
- Run, а затем вводим
команду dcpromo.exe для запуска Мастера установки доменных служб Active
Directory (Active
Directory
Domain Services
Installation
Wizard). В открывшемся
окне щелкаем по кнопке Next
для перехода на страницу Operating
System Compatibility
и ознакамливаемся с предупреждением о заданных по умолчанию параметрах
безопасности для контроллеров доменов системы Windows
Server 2008, а затем жмем
кнопку Next.
Но открывшейся
странице
Choose a Deployment Configuration устанавливаем
флажок
Create a New Domain in a Forest и
щелкаем
по
кнопке
Next. На
следующей странице Name
the Forest
Root Domain
в свободном поле указываем имя создаваемого корневого домена леса - RG.Center.Gonchar.com
и жмем кнопку Next, после чего
система проверит уникальность имен DNS
и NetBIOS в сети (Рис.6.1).
Рис.6.1 - Окно Active
Directory
Domain Services
Installation
Wizar, введение имени
домена и проверка уникальности DNS
и NetBIOS в сети
На странице Set
Forest Functional
Level выбираем
функциональный уровень Windows
Server 2008, означающий,
что все домены в лесу будут работать на уровне Windows
Server 2008 и жмем кнопку
Next. После этого
откроется страница Additional
Domain Controller
Options, в которой по
умолчанию выбран DNS-сервер,
чтобы DNS-инфраструктура леса создавалась при установке доменных служб Active
Directory (Рис.6.2).
Рис.6.2 - Выбор функционального уровня леса и
страница Additional
Domain Controller
Options
Первый контроллер в лесу должен быть сервером
глобального каталога GC
(Global Catalog)
и не может быть контроллером домена только для чтения RODC
(Read-Only
Domain Controller),
поскольку первый контроллер домена в лесу принимает роль хозяина схемы и
отвечает за поддержку распространения схемы на остальную часть леса, а
размещает разделы только для чтения базы данных, принимает только изменения,
сделанный в и никогда сам не инициирует репликацию. Поскольку планируется
использовать службу DNS, интегрированную с Active Directory, нажимаем кнопку Next.
В противном случае, если инфраструктура DNS уже существует и контроллер домена
не планируется использовать в качестве DNS-сервера, необходимо предварительно
снять флажок DNS-сервер.
На экран будет выведено предупреждение о
назначении статического IP-адреса,
которое в данном контексте можно проигнорировать. Щелкаем
по кнопке Yes, the
Computer
Will Use
a Dynamically
Assigned
IP Address
(Not Recommended),
а затем еще раз нажимаем кнопку Yes
в окне предупреждения мастера установки доменных служб, о том что для этого
DNS-сервера не будет делегирования, для закрытия окна (Рис.6.3).
Рис.6.3 - Предупреждение о назначении
статического IP-адреса
На странице Location
for Database,
Log Files
and SYSVOL
принимаем заданное по умолчанию размещение для файла базы данных, файлов
журнала службы каталогов и SYSVOL
и нажимаем кнопку Next.
Однако стоит отметить, что система архивации данных Windows Server 2008 создает
резервные службы каталогов по томам, и поэтому для обеспечения эффективности
резервного копирования и восстановления рекомендуется хранить эти файлы на
отдельных томах, которые не содержат приложений или других файлов, не имеющих
отношения к каталогу. На странице Directory
Services
Restore Mode
Administrator
Password вводим строгий
пароль Password
Confirmed
Password в поля
соответственно и щелкаем кнопку Next
(Рис.6.4). Этот пароль необходимо использовать для запуска доменных служб
Active Directory в режиме восстановления служб каталогов для задач, выполняемых
в автономном режиме.
Рис.6.4 - Выбор размещения для файла базы
данных, файлов журнала службы каталогов и SYSVOL
и создание пароля восстановления
На странице Summary
просматриваем выбранные параметры и в случае необходимости нажимаем кнопку Back,
чтобы внести модификации в настройки. Стоит также отметить, что избранные
настройки можно сохранить в файле ответов, который может использоваться для
автоматизации последующих операций с доменными службами Active Directory. Для
этого необходимо нажать кнопку Export
settings, а затем ввести
имя файла ответов и нажать кнопку Save
(Рис.6.5).
Рис.6.5 - Просмотр выбранных параметров
настройки и сохранение файла ответов
Если же все параметры корректны, дважды щелкаем
по кнопке Next. После
этого начнется процесс настройки AD
DS, по окончании
которого необходимо перезагрузить сервер. Чтобы не делать этого вручную
устанавливаем флажок Reboot
on Complection
(Рис.6.6).
Рис.6.6 - Процесс настройки AD
DS
После развертывания домена перейдем к созданию
его структурных подразделений. Организационные подразделения (organizational
units - OU) являются административными контейнерами, обычно используемыми для
определения департаментов или других отделений и служат для группирования
объектов с общими требованиями администрирования, конфигурации или видимости.
Для того чтобы создать организационное подразделение заходим на машину CSGonchar
под учетной записью администратора и осуществляем последовательный переход Start
- Administrative
Tools - Server
Manager. После этого на
экран будет выведено окно с заголовком Server
Manager. В левой части
открывшегося окно раскрываем последовательно узлы Roles
- Active Directory
Domain Services
и
открываем оснастку Active
Directory
Users And
Computers, а затем
разворачиваем узел домена RG.Center.Gonchar.com.
Щелкнув правой кнопкой мыши по узлу домена, в появившемся меню действий
выбираем пункт New и применяем команду Organizational Unit.
После этого откроется новое окно с заголовком New
Object - Organizational
Unit. Вводим в поле Name
имя создаваемого подразделения - Finance
и убеждаемся, что флажок Protect Container
From Accidental
Deletion установлен
(устанавливается по умолчанию). Protect Container From Accidental Deletion -
новая опция, появившаяся в административных средствах Windows Server 2008. Она предусматривает
для подразделения (OU) возможность использовать переключатель безопасности,
позволяющий избежать случайного удаления OU. В подразделение добавляются два
разрешения: Evеrуоnе::Deny::Delete и Everyone::Deny::Delete Subtree. Поэтому
пользователи и даже администраторы не могут случайно удалить подразделение и
его содержимое. Нажимаем кнопку ОК для подтверждения создания подразделения.
После этого вновь созданное подразделение появится в левой части окна Server
Manager в узле домена RG.Center.Gonchar.com.
Щелкаем по подразделению правой кнопкой мыши и применяем команду Properties. В
открывшемся окне с заголовком Finance
Properties в поле Описание
Description вводим описание - Economic planning, finance and personnel
department, аналогичным образом заполняем поля Street
Country/region
(Рис.6.7).
Рис.6.7 - Создание организационного
подразделения и задание его свойств
Щелкаем ОК. Аналогичным образом создаем другие
подразделения, отражающие организационную структуру офиса предприятия. В
результате выполнения вышеуказанных действий, в узле домена RG.Center.Gonchar.com
будут созданы подразделения- Accounting,
Commerce, Labor
protection, Energetics,
Metrology, Technology,
Operation, Construction,
Maintenance
and Mechanics,
Jurisprudence
Security, Admin
и Group с заполненными
полями Description
(Рис.6.8). Стоит отметить, что поскольку в домене центрального офиса находится
только данный офис структура OU
является не смешанной, а моделью разбиения по отделам.
Рис.6.8- Структура OU
центрального офиса предприятия
Теперь в каждом из сформированных подразделений
создадим по 3-5 пользователей, относящихся к различным группам безопасности.
Для начала в соответствие с выбранной стратегией управления учетными записями
пользователей создадим шаблон учетной записи в выбранном подразделении.
Например, для того чтобы создать шаблон учетной записи пользователя в
организационном подразделении заходим на машину CSGonchar
под учетной записью администратора и осуществляем последовательный переход Start
- Administrative
Tools - Active
Directory
Users and
Computers (Рис.6.9).
Рис.6.9 - Вызов
окна
Active Directory Users and Computers
В открывшемся окне разворачиваем узел домена UIB.com
и, щелкнув правой кнопкой мыши по созданному ранее организационному
подразделению Accounting,
выбираем в появившемся меню действий опцию New, а затем применяем команду
Пользователь User (Рис.6.10).
Рис.6.10 - Добавление нового объекта - шаблона
учетной записи пользователя
В открывшемся окне с заголовком New Object User
в поле First Name вводим имя - _ Accountant
с символом подчеркивания, в поле Last Name - Shablon,
в поле User Logon Name - _ Accountant
_Shablon с символами
подчеркивания. При этом стоит отметить, что поля Full
Name (полное имя
пользователя) и User Logon Name (Рге-Windows 2000) (имя входа пользователя
(пред- Windows 2000) будут заполнены автоматически на основании данных вводимых
в полях First Name, Last Name и User Logon Name соответственно, однако при
необходимости их можно изменить вручную. Щелкаем кнопку Nextи в обновившемся
окне в полях Password и Confirm Password вводим сложный пароль (Pa$$w0rd).
Политика паролей домена Active Directory по умолчанию требует назначить пароль
как минимум из восьми символов, а кроме того, пароль должен содержать три из
четырех типов символов: прописные буквы (A-Z), строчные буквы (a-z), цифры
(0-9) и особые символы (такие, как, например, !, @, #,$, %). Также пароль не
должен содержать атрибуты имени пользователя.Устанавливаем флажок Account
Is Disabled
(Рис.6.11). Щелкаем кнопку Next, а затем кнопку Finish.
Рис.6.11 - Создание шаблона учетной записи
пользователя
Благодаря символу подчеркивания в начале имени
учетной записи шаблон следует первым в списке пользователей в подразделении Accounting,
при этом значок объекта пользователя содержит стрелку, направленную вниз,
обозначающую, что учетная запись отключена. Дважды щелкаем шаблонную учетную
запись, для открытия ее диалогового окна Properties и в появившемся окне
переходим на вкладку Organization. Заполняем ее в соответствии со структурой
организации. Переходим на вкладку Profile
и в поле Profile
Path вводим \\ CSGONCHAR
\profiles\%usemame%
(Рис.6.12) и щелкаем кнопку ОК.
Рис.6.12 - Вкладки
Organization и Profile
На этом шаге создание шаблонной учетной записи,
которую можно копировать с целью генерирования учетных записей для новых
сотрудников в организационном подразделении Accounting
завершено.
Для создания учетную запись на основе ранее
созданного шаблона _ Accountant
_Shablon щелкаем по нему
правой кнопкой мыши и в появившемся меню действий выбираем примените команду
Сору. После этого на экран будет выведно новое диалоговое окно Copy Object -
User. В открывшемся окне в поле First Name вводим имя добавляемого пользователя
- Margarita, в поле Last Name
- фамилию пользователя - Gonchar,
в поле User Logon Name - имя входа пользователя - M.A.Gonchar.
Accountant и щелкаем кнопку
Next. В обновившемся окне в полях Password и Confirm Password вводим сложный
пароль (Pa$$w0rd2) и, предварительно сбросив флажок Account is Disabled,
щелкаем кнопку Next, а затем кнопку Finish.
Открываем свойства учетной записи пользователя Margarita
Gonchar и убеждаемся, что
сконфигурированные в шаблоне атрибуты скопированы в новую учетную запись, за
исключением атрибута Job
Title, оставшегося
пустым (Рис.6.13).
Рис.6.13 - Создание учетной записи пользователя
на основе шаблона
Аналогичным образом создаем других пользователей
в данном организационном подразделении (Рис.6.14). Также создаем шаблоны и на
их основе другие учетные записи пользователей в других OU.
Рис.6.14 - Созданные на основе шаблона
пользователи
Теперь создадим в организационном подразделении Group
группы безопасности в соответствии с выбранными ранее требованиями. Для того
чтобы создать учетную запись объекта группа открываем оснастку Active
Directory
Users And
Computers и, развернув в
дереве консоли узел домена RgCenter.Gonchar.com,
выбираем, созданное ранее организационное подразделение Group.
Щелкаем по выбранному подразделению правой кнопкой мыши и в появившемся меню
действий выбираем опцию New, а затем применяем команду Group. После этого на
экран будет новое окно с заголовком New Object - Group (Рис.6.15).
Рис.6.15 - Создание новой учетной записи группы
В появившемся окне в поле Group Name вводим имя
группы Presidents.
При этом поле Group Name (Pre-Windows 2000 будет заполнено автоматически,
оставляем его неизменным. Затем выбираем для группы тип Security и область
действия Universal,
путем установления соответствующих флагов (установлен по умолчанию Global),
и щелкаем по кнопке ОК для создания учетной записи. После этого созданная
учетная запись объекта группа появится в выбранном ранее подразделении Groups.
Щелкаем по группе правой кнопкой мыши и применяем команду Properties.
На экран будет выведено окно Presidents
Properties, состоящее из 4
вкладок: General
(общие сведения о группе), Members
(список учетных записей, являющихся членами данной группы), Member
Of (список групп,
членом которых является данная группа) и Managed
By (кем управляется
данная группа) (Рис.6.16). Просматриваем доступные свойства группы и, оставив
эти атрибуты неизменными, щелкаем по кнопке ОК для закрытия окна.
Рис.6.16 - Просмотр свойств созданной учетной
записи группы
Аналогичным образом создаем в том же
подразделении группы безопасности Heads
of departments
(Глобальную) и Worker
(Локальную) (Рис.6.17)
Рис.17 - Просмотр созданных групп
Добавим в созданные ранее группы в качестве
членов учетные записи пользователей, созданные ранее. Для этого открываем
оснастку Active
Directory
Users and
Computers и открываем
свойства своей административной учетной записи в подразделении Accounting.
В открывшемся окне Margarita
Gonchar Properties
переходим на вкладку Member Of. Стоит отметить, что выбранная учетная запись
уже входит в группу Domain
Users. Щелкаем кнопку
Add. В открывшемся диалоговом окне Select Groups вводим имя Worker
и дважды щелкаем по кнопке ОК в этом окне и в следующем для закрытия окна
свойств учетной записи. Стоит отметить, что для выбора имен выбираемых объектов
достаточно ввести несколько первых букв данного объекта и щелкнуть кнопку Check
Names, после чего система выдаст список всех объектов, которые начинаются с
введенных букв (символов), из которого необходимо выбрать нужное имя (Рис.6.18)
.
Рис.6.18 - Добавление учетной записи
пользователя в группу Worker
Открываем свойства созданной ранее группы Heads
of departments
в подразделении Groups
и, перейдя на вкладку Members, щелкаем по кнопке Add. В открывшемся диалоговом
окне Select Users, Contacts,
Computers, or
Groups вводим несколько
первых букв имени пользователя Sveta
Trozenko и щелкаем кнопку
Check Names. Имя будет разрешено (введенное имя будет подчеркнуто) (Рис.6.19).
Щелкаем ОК. Дважды щелкаем по кнопке ОК в этом окне и в следующем для закрытия
окна Select Users, Contacts,
Computers, or
Groups и окна свойств
группы.
Рис.6.19 - Подтверждение корректности
добавляемого объекта
Аналогичным образом размещаем в созданные ранее
группы пользователей, в соответствие с представленной выше методикой.
Теперь сконфигурируем индивидуальные политики
безопасности для каждой из групп, в соответствии с выбранными ранее
требованиями. В Windows Server 2008 политику паролей и блокировки в домене
можно заменить новой гранулированной политикой паролей и блокировки, которую
называют просто гранулированной политикой паролей. Эту политику можно применять
к одной или нескольким группам пользователей в домене. Для использования
гранулированной политики паролей домен должен работать на функциональном уровне
Windows Server 2008. Этот компонент - очень ценное дополнение в Active
Directory, при помощи гранулированных политик паролей администратору
предоставляется возможность создавать различные коллекции параметров паролей и
блокировки учетных записей для выбранных пользователей или групп пользователей.
Граннулироанные политики паролей Server 2008
хранятся в новом контейнере AD, именуемом AD Password Settings Container,
который находится в контейнере System контекста именования домена AD. Чтобы
определить новую гранулированную политику паролей, необходимо создать в этом
контейнере новый объект AD класса msDS-PasswordSettings. В документации
Microsoft объекты этого класса именуются объектами настроек пароля (Password
Settings object, PSO). По умолчанию только члены группы Domain Admins могут
создавать объекты PSO, так как только члены этой группы имеют разрешения AD
Create Child и Delete Child в контейнере Password Settings.
Создадим объект PSO, применяющий строгую
гранулированную политику паролей к пользователям в группе Heads
of departments.
Стоит отметить, что для выполнения этой операции группа Heads
of departments
должна находиться в контейнере Users.
Открываем оснастку ADSI Edit, осуществив
последовательный переход Start
- Administrative
Tools -ADSI Edit и в
открывшемся окне ADSI Edit щелкаем правой кнопкой узел ADSI Edit, а затем в
появившемся меню действий выбираем команду Connect To.
После этого на экран будет выведено новое окно с
заголовком Connection
Settings, в котором в поле
Name вводим имя домена - UIB.com и щелкаем ОК для закрытия окна (Рис.6.20).
Рис.6.20 Окно Connection
Settings
В обновившемся окне ADSI Edit (узел UIB.com по
умолчанию - развернут) последовательно разворачиваем папки DC=RGCenter,
DC=Gonchar,DC=com
, CN=System и выбираем элемент CN=Password
Settings
Container (Рис.6.21). Все
объекты PSO создаются и хранятся в контейнере параметров паролей PSC (Password
Settings Container), однако изначально данный контейнер пуст.
Рис.6.21 - Контейнер параметров паролей PSC
Щелкаем правой кнопкой мыши контейнер PSC и в
появившемся меню действий выбираем команду New, а затем щелкаем опцию Object
(Рис.6.22).
Рис.6.22 - Создание объекта PSO
После этого на экран будет выведено новое
диалоговое окно с заголовком Create Object, в котором необходимо выбрать тип
создаваемого объекта. Здесь представлен только один тип: msDS-Password
Settings, являющийся техническим именем класса объекта PSO (Рис.6.23).
Рис.6.23 - Выбор типа создаваемого объекта
Щелкаем кнопку Next и в обновившемся окне
последовательно указываем значение для каждого атрибута PSO щелкая кнопку Next
после назначения очередного атрибута:
- Common Name: PSO Heads of
departments
- Параметр msDS-Password Settings Precedence: 1
- означающий, что этот объект PSO получит наивысший уровень приоритета,
поскольку его значение ближе всего к единице (Рис.6.24).
Рис.6.24 - СN
создаваемого объекта и параметр msDS-Password
Settings
Precedence
Параметр msDS-Password
Reversible
Encryption
Enabled: False
- пароль не будет храниться с использованием обратимого шифрования
Параметр msDS-Password History Length: 30
-пользователь не сможет повторно использовать последние 30 паролей (Рис.6.25).
Рис.6.25 - Параметры
ms DS-Password Reversible Encryption Enabled и
msDS-Password History Length
- Параметр msDS-Password Complexity Enabled:
True - включающий правила сложности паролей.
Параметр msDS-Minimum Password Length: 15 -
устанавливающий минимальную длину пароля не менее 15 символов (Рис.6.26).
Рис.6.26 - Параметры
msDS-Password Complexity Enabled и
msDS-Minimum Password Length
- Параметр msDS-MinimumPasswordAge: 1:00:00:00 -
означающий, что пользователь не может изменить свой пароль в течение одного дня
после предыдущего изменения (временной период задается в формате d:hh:mm:ss
(дня, часы, минуты, секунды)).
Параметр Maximum Password Age: 45:00:00:00 -
пароль необходимо изменять каждые 45 дней (Рис.6.27).
Рис.6.27 - Параметр
msDS-Minimum Password Age и
Maximum Password Age
- Параметр insDS-LockoutThreshold: 3 - после
пяти ошибок входа в течение интервала времени, указанного следующим атрибутом,
учетная запись пользователя блокируется.
Параметр msDS-Lockout
Obsewation
Window: 0:01:00:00 -
после пяти ошибок входа (как указано предыдущим атрибутом) в течение одного часа
учетная запись блокируется (Рис.6.28).
Рис.6.28 - Параметр
insDS-Lockout Threshold и
ms DS-Lockout Obsewation Window
- Параметр ms DS-Lockout Duration: 1:00:00:00 -
учетная запись блокируется в течение одного дня или до ручного снятия
блокировки. Стоит отметить, что значением 0 задают блокировку учетных записей
до тех пор, пока они не будут разблокированы администратором (Рис.6.29).
Рис.6.29 - Параметр msDS-Lockout Duration
Все выше перечисленные атрибуты являются
обязательные. Для того, чтобы отконфигурировать дополнительные атрибуты щелкаем
кнопку Next на странице атрибута msDS-Lockout Duration и в обновившемся окне
щелкаем кнопку More Attributes, а затем в открывшемся окне cn=
PSO Heads
of departments
в поле Edit Attributes вводим CN= Heads
of departments,
DC=RGCenter, DC=Gonchar,
DC=com и щелкаем ОК (Рис.6.30).
Рис.6.30 - Настройка дополнительного атрибута
Щелкаем кнопку Finish для завершения процесса
создания объекта PSO, после чего созданный объект добавиться в контейнер PSC
(Рис.6.31)
Рис.6.31 - Созданный объект PSO
Аналогичным образом создаем необходимые политики
безопасности для каждой из групп.
7.Развертывание службы облегченного
доступа к каталогам (AD LDS)
.1 Общие сведения
LDS (Active
Director
Lightweight
Directory
Services) - это служба
каталогов, работающая по протоколу LDAP (Lightweight Directory Access Protocol
- облегчённый протокол доступа к каталогам) и обеспечивающая гибкую поддержку
приложений, ориентированных на работу с каталогами, избавляя администратора от
требований, предъявляемых к традиционной службе каталогов Active Directory
(Active Directory Domain Services, AD DS).
Служба AD
LDS не имеют
зависимостей и доменных ограничений, их можно запускать на рядовых или
отдельных серверах. Кроме того стоит отметить, что даже на одном сервере можно
запустить несколько экземпляров AD
LDS с независимой
управляющей схемой для каждого экземпляра службы.
Таким образом, используя службы AD
LDS, ранее известные
как Active
Directory
Application
Mode (ADAM),
можно производить развертывание служб каталогов для приложений, ориентированных
на работу с каталогами, в то же время избавляясь от необходимости развертывания
доменов и лесов, а также использования единой схемы каталога в пределах всего
леса.
Служба каталогов Active Directory обеспечивает
поддержку как серверов под управлением ОС Microsoft Windows Server, так и
приложений, ориентированных на работу с каталогами. Для каждой серверной
операционной системы служба AD DS хранит важную информацию о сетевой
инфраструктуре, пользователях и группах, сетевых службах и так далее. В таком
режиме работы служба AD DS должна использовать единую схему для всего леса
доменов.
С другой стороны, роль AD LDS, установленная на
сервере, обеспечивает поддержку служб каталогов специально для приложений,
ориентированных на работу с каталогами. Для работы AD LDS не требуется наличия
доменов или лесов Active Directory. Тем не менее, в окружениях с развернутыми
службами AD DS служба AD LDS может использовать информацию AD DS для проверки
подлинности участников безопасности Windows. Основные функциональные
возможности роли AD LDS приведены в Приложении И.
7.2 Анализ необходимости
развертывания службы AD LDS на исследуемом предприятии
Поскольку в соответствии со стратегией развития
рассматриваемой в данной работе производственной компании «Рога&Копыта», в
каждом из региональных центров предприятия предполагается прохождение
подготовки новых кадров - стажеров, с целью минимизации риска нанесения ущерба
компании, вследствие ошибочных действий неопытного персонала предлагается
развернуть службу AD LDS. Поскольку данная служба обладает практически тем же
функционалом, что и развернутая на предприятии служба AD DS, однако же
изменения произведенные в отдельном экземпляре службы облегченного доступа к
каталогам, не выйдут за пределы этого экземпляра. Таким образом реализация
данного решения, с одной стороны, позволит стажерам наработать и закрепить
практические навыки работы со службами каталогов, а с другой - гарантирует, что
в случае критических изменений, по ошибке произведенных в отдельном экземпляре
AD LDS, ущерб будет нанесен лишь этому отдельному экземпляру, а не будет
реплицирован по всему домену или, хуже того, лесу. Описание процесса тестового
развертывания службы AD LDS также приведены в Приложении К.
Выводы
В данной курсовой работе, основываясь на базе
теоретических сведений, а также анализе существующей инфраструктуры и
бизнес-процессов производственной компании «Рога Копыта» была разработана и
предложена к внедрению модель развертывания службы каталогов Active Directory.
Так, были рассмотрены вопросы определения необходимого количество лесов для
организации, порядок их разбиения на домены, планирования доменного
пространства имен организации и структуры доменов, определены механизмы
разделения ресурсов компании по организационным подразделениям, рассмотрены
основные вопросы (проблемы) конфигурации сайтов, а также разработана стратегия
для управления учетными записями пользователей компании и группами безопасности
на предприятии.
Для рассматриваемой в работе организации была
выбрана модель единого леса с центральным доменом и четырьмя региональными
доменами, являющимися дочерними по отношению к центральному. Порядок назначения
доменных имен основывался на территориальном признаке, позволяющему отразить
географическую структуру компании, а также являющемуся устойчивым к
реорганизации. Для разделения ресурсов между организационными подразделениями
для центрального домена была выбрана Модель структуры OU на основе структуры
организации, поскольку она позволяет обеспечивать определенный уровень
автономии для каждого отдела и упрощенное администрирование. Для региональных
же доменов была предложена Смешанная модель структуры OU - сначала по
местоположению, затем по структуре организации, позволяющая отразить структуру
компании внутри каждого домена и географическое местоположение филиалов. Была
выработана собственная стратеги управления учетными записями и группами
безопасности предприятия, а также рассмотрены вопросы конфигурации сайтов.
Также было произведено тестовое развертывание разработанной модели каталога
Active Directory на база серверной операционной системы Windows
Server 2008 применительно
к центральному офису компании «Рога Копыта». Кроме того, с учетом того, что в
каждом из региональных центров проходит подготовка новых кадров (стажеров), был
проведен анализ необходимости развертывания службы облегченного доступа к
каталогам (AD
LDS), а также
развернут тестовый экземпляр службы AD
LDS.
Список
использованной литературы
1.Холмс
Д.,
Реет
Н.,
Реет
Д.
Настройка
Active Directory Windows Server 2008. Учебный курс
Microsoft / Пер. с англ. - М.: Издательство «Русская редакция», 2011. - 960
стр. : ил.
.Электронный
ресурс: http://www.intuit.ru
.Электронный
ресурс: http://www.oszone.net
.Электронный
ресурс: http:// www.refdb.ru
.Электронный
ресурс: http:// www.ru.wikipedia.org
.Электронный
ресурс: http:// www.technet.microsoft.com
.Электронный
ресурс: http://www.windowsazure.com
1.