Пятница, 22.09.2017, 22:32
Приветствую Вас Гость | RSS

Я - за павсимесную и всиоблемущюю паддершку Аброзования!

Меню сайта
Форма входа
Категории раздела
Сети [14]
Сети
Windows сервер [14]
Сервера Windows. Администрирование
Active Directory [17]
Опрос
Как вы относетесь к порнографии
Всего ответов: 689
Облако тегов
апокриф библия история история религии маска сети настройка IP-адреса НОВЫЙ ЗАВЕТ Альбион гастарбайтер Гражданин и ты Брут Митридат политическая реклама Понт воскрешение гармония Дух плоть праведная плоть канон Аид гомер Мифология моментальность дружба женщина мужчина отношение VPN dns корневой домен DNS клиент FQDN HOSTS пространство имен разрешение имен MX зона DNS корневые Мастер установки Active Directory глобальный каталог раздел домена Раздел конфигурации Раздел схемы GUID.контроллер домена.Серверы плац Внутрисайтовая репликация межсайтовая репликация лес Домен Планирование Active Directory подразделение DNS-сервера DnsCmd DomainDnsZones ForestDnsZones SUPTOOLS.MSI настройка зоны DNS область распространения зоны DNS SOA Primary Name Server Start of Authority Transfer Zone зонная передача Начальная запись зоны DNS Основной сервер DNS передача зоны DNS nslookup дерево доверие доверительные отношения ADSL DMT ISP POTS xDSL Ntds.dit Active Directory.Зоны прямого просм Netlogon SVR Sysvol _msdcs _saites _tcp _udp Dcdiag Dcpromo.log Dcpromos.log Dcpromoui.log Netdiag Ntdsutil консоль ммс панель задач оснастка авторский параметры пользовательский расширение режим консоли
AdSense
Счетчики
PR-CY.ru Каталог@Mail.ru - каталог ресурсов интернет реклама в интернете, реклама сайта
Статистика

Онлайн всего: 1
Гостей: 1
Пользователей: 0

Каталог статей

Главная » Статьи » Active Directory

Планирование Active Directory. Первый этап.

Планирование Active Directory

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

Что необходимо понимать под таким мудреным определением как «Планирование Active Directory»? А если по простому – нельзя просто так «забацать» Windows Server 2003 а потом поднять  Active Directory и все, а потом «как карта ляжет», так как часто неопытные  сетевые администраторы так и делают, а потом пожизненно болеют "геморроем".

Вообще проектирование систем на базе Windows 2003 требует больших ресурсов,  как временных, так и людских. Успех проекта зависит во многом от того, насколько корректно управляется проект, как распределены ресурсы, от подготовленности специалистов и персонала. Довольно много работы, перед тем как начать самое простое в данном вопросе,  установку  Windows Server 2003, и поэтому и рассылка не началась с описанием установки, а поэтапно пыталась (в силу своих возможностей) объяснить основные термины и понятия которые нам понадобятся как раз для объяснения процесса планирования Active Directory. Самое главное это правильно сформулировать и определить  цели и задачи,  «зачем» и «для чего»  мы это делаем.

Процесс проектирования инфраструктуры Active Directory состоит из четырех этапов, а именно:

  • Создание плана лесов.
  • Создание плана доменов.
  • Создание плана подразделений.
  • Создание топологического плана сайтов.

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

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

Под понятием «проектным решением инфраструктуры Active Directory» мы будем понимать план, отражающий сетевую структуру нашего предприятия.

Итак, роли в проекте.

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

Руководитель проекта. Принимает решения по разворачиванию новой инфраструктуры в заданное время и в рамках, определенных в проекте. С членами команды определяет задачи проекта, спецификации новой инфраструктуры. Вырабатывает график работ. Глубоко знает свойства Windows ХР Professional   (Windows  7) и Windows 2003 Server.  Увязывает  цели руководства с целями команды.

Разработчик и тестировщик. Рассматривает технические решения, планируемые к использованию в новой инфраструктуре. Помогают разрабатывать начальное решение. Определяют потенциальные проблемы и способы их разрешения до разворачивания. Играет активную роль в разработке инфраструктуры. Знания в области разработки сложных служб операционной системы. Понимание технических требований. Отвечают за разработку отдельных звеньев, например, Active Directory, системы безопасности, почтовой системы и т. п. Высокий уровень знаний в своих областях и глубокое знание Windows 2003. Имеет навыки управления проектом.  Выполняют анализ производительности и масштабируемости.  Знание требований к совместимому оборудованию. Имеет опыт в отладке и тестировании систем и приложений.

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

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

  •  Active Directory;
  •  службу имен (DHS, WINS, DHCP);
  •  безопасность;
  •  администрирование;
  •  работу приложений  в среде Windows 2003 Server (различных необходимых производственных программ и баз данных)
  •  почту;
  •  конфигурирование клиентов;
  •  управление удаленными пользователями;
  •  .....

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

Чем проще, тем лучше.

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

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

Итак, сперва вам как допустим руководителю службы IT  и с вашей командой, нужно произвести ревизию сети, и всех имеющихся в сети ресурсов, программного обеспечения. Это обязательное начало, и при этом необходимо все это задокументировать. Так же нужно произвести анализ коммерческого контекста, бизнес процессов, направление имеющегося  потока данных. И это так же надо задокументировать.  О составлении и согласование  технического задания и прочего говорить не буду, хотя иногда это спасает от многих конфликтов, так как некоторые пользователи "просыпаются" тогда когда уже поздно менять что либо, поэтому вовлечение в проект всех будущих пользователей системой, и учет вех их требований (задокументированых) абсолютно необходимый процесс.  Перейдем непосредственно к проектированию  Active Directory.

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

Первый этап. Создание плана лесов.  

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

Давайте вспомним, чем характеризуется лес доменов:

  • наличием общей схемы,

  • общего контейнера конфигурации,

  • единого Глобального каталога (GC),

  • полных транзитивных доверительных отношений между доменами.

Это позволяет пользователям регистрироваться в пределах леса применяя свое основное имя (UPN), выполнять поиск ресурсов в GK и осуществлять к ним доступ в пределах всего леса. Администраторы же могут не заботиться о доверительных отношениях и легко управлять конфигурацией, что очень немаловажно.

Примечание:  UPN (user principal name) – основное имя пользователя. У каждой учетной записи есть «удобное» имя и называется она основным именем пользователя –UPN и это и есть учетная запись пользователя и еще в купе с именем домена  естественно, где эта учетная запись зарегистрирована и имеет смысл. Иногда UPN называют регистрационным именем пользователя или именем входа или логином от user login name.

Так сколько лесов создавать? Исходя из основного правила (смотри выше), слышу крики  - Only One!  (только один).  И вы правы! Именно в одном лесу пользователи работают с единым каталогом, задействуют все преимущества транзитивных доверительных отношений, а администраторы легко управляют всеми доменами. Однако существуют  ситуаций, когда  необходимо и мы вынуждены использовать несколько лесов. Примером может служить объединение нескольких предприятий партнеров, или приказ министра производить обмен информацией между самостоятельными предприятиями по горизонтали, но подчиняющимися по вертикали одному министерству, или покупка нашей фирмы другой фирмы с уже существующим лесом, ну не ломать же его. Да, их связывают тесные партнерские отношения, им часто надо обмениваться информацией. Но это еще не повод для того, чтобы предоставлять пользователям разных предприятий или партнерских фирм прозрачный доступ к своим ресурсам. Администраторы разных организаций могут не доверять друг другу, они могут не прийти к согласию в том, как лес может изменяться. В такой ситуации не обойтись без нескольких лесов.

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

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

  • Организационные единицы в силу «политических» причин разделены на самостоятельные группы.

  • Существует необходимость в разделенном ведении организационных единиц.

  • Леса содержат различные схемы каталога, контейнеров конфигурации и глобального каталога (GC). В этом случае требуется через создание лесов изолировать их друг от друга.

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

Кажись все.

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

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

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

В  технических  терминах  просто  определить,  кто  является владельцем  леса.  Группы Schema Admins (Администраторы  схемы), Enterprise Admins (Администраторы предприятия) и Domain Admins (Администраторы домена)  в корневом домене могут  быть  определены  как  владельцы  леса,  потому  что  они  управляют  теми  изменениями, которые могут быть сделаны в лесу. Это роли чисто технические, и люди в этих группах почти не имеют окончательных полномочий на то, будут ли на самом деле сделаны модификации к лесу.  Например, группа Schema Admins может изменять схему, но член группы Schema Admins обычно не имеет полномочий для принятия заключительного решения относительно того, будет ли запрос  на изменение схемы одобрен.

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

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

  • изменения  схемы  и

  • изменения  раздела  конфигурации  каталога ( например,  добавление  или  удаление  доменов  и разделов приложений каталога, изменение конфигурации сайта).

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

Документ «политика  управления  изменениями  леса»   должна  быть  сформирована  прежде,  чем  вы  начнете развертывать Active Directory.  Она так же должна быт прописана в документе более высокого ранга такой как «Политика IT безопасности предприятия» в целом. На   предприятиях   с  разнообразными  и  обособленными  деловыми подразделениями пояснение этой политики может быть трудным делом и занять много времени, но  и  после  развертывания Active Directory делать  это  совсем  не  легче.  Если  деловые подразделения  не  смогут  договориться  о  политике  управления  изменениями  леса  перед  развертыванием, вы должны принять решение о развертывании нескольких лесов, что весьма «не очень»

 И это правда, так как знаю по собственному опыту какие стрессы  и скандалы вызывают изменения, внесенные в лесе или даже в отдельном домене, если нет хорошо проработанного   документа  такой как «Политика IT безопасности предприятия» и все вытекающие из него документов.

Продолжение следует....

Категория: Active Directory | Добавил: AlterEgo25 (13.10.2010)
Просмотров: 13716 | Комментарии: 1 | Теги: Active Directory, Домен, лес, подразделение, Планирование Active Directory | Рейтинг: 4.4/9
Всего комментариев: 1
1  
"сперва вам как допустим руководителю службы IT и с вашей командой, нужно произвести ревизию сети, и всех имеющихся в сети ресурсов, программного обеспечения. Это обязательное начало, и при этом необходимо все это задокументировать. Так же нужно произвести анализ коммерческого контекста, бизнес процессов, направление имеющегося  потока данных. И это так же надо задокументировать."

Кто-нибудь знает где можно почитать об анализе ресурсов и их документировании? Я пока нигде не встречал.

Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]
Поиск
Подписатся
Подписаться на рассылку
"Active Directory - от простого к сложному."


 
Mail.Ru
Подписатся
Подписаться на:
Active Directory от простого к сложному | RSS
Имя:
E-mail

Посетите Каталог Maillist.ru.
Maillist.ru: Active Directory от простого к сложному
Поделись с другом
Поиск
Loading
Рейтинг чатов Поисковый каталог Эхо Ру счетчик посещений
счетчик посещений

Copyright MyCorp © 2017
Используются технологии uCoz