что такое сайты в active directory
С чего начинается дружба с Active Directory
Мне часто приходится сталкиваться с обработкой информации из Active Directory. Так как данная система много где распространена, я решил поделиться своим опытом работы с ней.
Началось всё с того, что я раздавал доступ в MS Sharepoint. В заявках от сотрудников, в лучшем случае, приходили учетные записи, в худшем могли написать что-то типа “Мне и моему начальнику”. Это поначалу напрягало, и я, чувствуя себя заправским админом, посылал такие заявки обратно нерадивым юзерам, чтобы они всё переделали. Это превращалось в ворох пропитанных гневом писем и звонков. Я даже стал задумываться, не случайно ли совпадение сокращения от Active Directory – AD с русским словом “Ад”. В итоге, осознав, что надо менять мир к лучшему, я решил детально разобраться, что вообще хранится в Active Directory и как это можно использовать, для автоматической раздачи доступа и других полезных вещей.
Решение этой задачи было найдено и растиражировано во множество утилит и программных продуктов, активно используемых внутри компании. Одной из наиболее используемых утилит стала программа поиска информации по сотруднику. Она ищет сотрудника или сотрудников по различным критериям и выдаёт наиболее полную информацию о них, совмещая данные из Active Directory и Oracle. Особой популярностью пользуются фотографии сотрудников, которые хранятся в базе данных.
Так же стоит отметить интеграцию Active Directory не только с Oracle но и с MS Sharepoint. Благодаря найденному решению появилось приложение способное быстро дать доступ группе пользователей из Active Directory на страницы портала Sharepoint, а так же удалить из него пользователей, которые по различным причинам, ушли из неё.
Связи сайтов в Active Directory. Разрушаем стереотип
Если вы хотите узнать, почему я считаю такие диаграммы вредными (хотя и признаю их удобство), то добро пожаловать под кат.
В чём же проблема? Дело в том, что такие диаграммы закрепляют очень серьёзный стереотип — связь сайтов связывает два сайта в рамках домена.
Совсем недавно, ко мне обратились за рекомендациями по организации топологии Active Directory домена. У заказчика используется классический вариант звезды, с одним центральным сайтом в основном дата центре и несколькими удалёнными филиалами. У заказчика появилось желание организовать второй основной сайт в той же локации (у хостинга появился второй дата центр в том же городе, соединённый с первым очень хорошим каналом) для повышения надёжности инфраструктуры. Соответственно встал вопрос, как правильно добавить новый сайт в текущую структуру сайтов. После нескольких минут беседы я, с удивлением, понял, что человек вообще не знает, что можно связать несколько сайтов одной и той же связью между сайтами. То есть, если его спросить, то он вспомнит, что в оснастке управления вам дают выбрать список сайтов, входящих в связь, но в его сознании топология домена всегда представлена вот такой диаграммой, где связи это линии соединяющие два сайта.
Я не отрицаю удобство такого представления и факта, что чаще всего большего и не нужно. Просто жаль, что закрепляя такой стереотип, люди лишают себя части возможностей, предоставляемых этим инструментом. Не забывайте, что даже Microsoft в своей статье о репликации в Active Direcotry отмечает, что связь сайтов может включать несколько сайтов, если все они соединены друг с другом одинаково хорошо («all the sites are equally well connected», если будете искать по фразе).
Конкретно в этой истории, используя эту возможность можно было выбрать два варианта организации связей между сайтами, которые обеспечивали принципиально разное поведение системы.
Ключевым вопросом, для понимания того, как правильно организовать структуру сайтов заказчика здесь является следующий — будет ли второй основной сайт stand-by DR локацией, которая должна использоваться только если возникли проблемы с первым или первый и второй основные сайты станут равноправными и должны разделять нагрузку.
В варианте stand-by DR локации нам, действительно, достаточно связей сайтов парами. Всё что нам нужно для того, чтобы добавить новый сайт это связать его только с основным с весом связи меньше чем для любого удалённого сайта (ну и, конечно, выбрать опцию Bridge All Site Links). Таким образом, если в первом основном сайте произойдёт сбой, то для контроллеров во всех удалённых сайтах именно второй основной сайт станет партнёром по репликации и сможет помочь с аутентификацией, если и в удалённом сайте начнутся проблемы.
Однако, заказчик хотел именно равноправные сайты. Он собирался размещать многие сервисы во втором дата центре. В этом случае такой вариант будет не правильным. Чтобы этого достичь, помимо создания новой связи нам нужно изменить каждую из существующих, добавив в неё новый сайт. Линии на диаграмме нам теперь не помогут. Это можно изобразить как-то так.
В этой статье нет каких-то откровений. Я думаю, что большинство читателей и так всё это знали. Тем не менее, я уверен, что были и те, кто до сих пор, зная, что оснастка создания связи сайтов позволяет добавить туда больше двух объектов, мысленно рисовали себе диаграммы топологии Active Directory репликации только со связями в виде стрелочек.
АПД: Последняя диаграмма была изменена после получения ценных замечаний от ildarz в комментариях.
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
В наших прошлых материалах мы разобрали общие вопросы касающиеся служб каталогов и Active Directory. Теперь пришла пора переходить к практике. Но не спешите бежать к серверу, перед развертыванием доменной структуры в вашей сети необходимо ее спланировать и иметь четкое представление о назначении отдельных серверов и процессах взаимодействия между ними.
Перед тем как создавать ваш первый контроллер домена необходимо определиться с режимом его работы. Режим работы определяет доступные возможности и зависит от версии применяемой операционной системы. Мы не будем рассматривать все возможные режимы, кроме тех которые имеют актуальность на текущий момент. Таких режимов три: Windows Server 2003, 2008 и 2008 R2.
Режим Windows Server 2003 следует выбирать только тогда, когда в вашей инфраструктуре уже развернуты сервера на данной ОС и планируется использовать один или несколько таких серверов в качестве контроллеров домена. В остальных случаях нужно выбирать режим Windows Server 2008 или 2008 R2 в зависимости от купленных лицензий. Следует помнить, что режим работы домена можно всегда повысить, а вот понизить уже не удастся (разве что восстановив из резервной копии), поэтому подходите к данному вопросу осмотрительно, с учетом возможных расширений, лицензий в филиалах и т.д. и т.п.
Мы сейчас не будем подробно рассматривать сам процесс создания контроллера домена, к этому вопросу мы вернемся позже, а сейчас хотим обратить ваше внимание на то, что в полноценной структуре Active Directory контроллеров домена должно быть не менее двух. В противном случае вы подвергаете себя неоправданному риску, так как в случае отказа единственного контроллера домена ваша структура AD будет полностью уничтожена. Хорошо если будет актуальная резервная копия и из нее удастся восстановиться, в любом случае все это время ваша сеть будет полностью парализована.
Поэтому сразу же после создания первого контроллера домена нужно развернуть второй, вне зависимости от размеров сети и бюджета. Второй контроллер должен быть предусмотрен еще на стадии планирования и без него за развертывание AD даже не стоит браться. Также не стоит совмещать роль контроллера домена с любыми иными серверными ролями, в целях обеспечения надежности операций с базой AD на диске отключается кэширование записи, что приводит к резкому падению производительности дисковой подсистемы (это объясняет и долгую загрузку контроллеров домена).
В итоге наша сеть должна принять следующий вид:
Вопреки распространенному мнению, все контроллеры в домене равнозначны, т.е. каждый контроллер содержит полную информацию о всех объектах домена и может обслужить клиентский запрос. Но это не значит, что контроллеры взаимозаменяемы, непонимание этого момента зачастую приводит к отказам AD и простою сети предприятия. Почему так происходит? Самое время вспомнить про роли FSMO.
Когда мы создаем первый контроллер, то он содержит все доступные роли, а также является глобальным каталогом, с появлением второго контроллера ему передаются роли хозяина инфраструктуры, хозяина RID и эмулятора PDC. Что будет если администратор решил временно вывести из строя сервер DC1, например чтобы почистить от пыли? На первый взгляд ничего страшного, ну перейдет домен в режим «только чтение», но работать то будет. Но мы забыли про глобальный каталог и если в вашей сети развернуты приложения требующие его наличия, например Exchange, то вы узнаете об этом раньше, чем снимете крышку с сервера. Узнаете от недовольных пользователей, да и руководство вряд ли придет в восторг.
Из чего следует вывод: в лесу должно быть не менее двух глобальных каталогов, а лучше всего по одному в каждом домене. Так как у нас домен в лесу один, то оба сервера должны быть глобальными каталогами, это позволит вам без особых проблем вывести любой из серверов на профилактику, временное отсутствие каких либо ролей FSMO не приводит к отказу AD, а лишь делает невозможным создание новых объектов.
Как администратор домена, вы должны четко знать каким образом роли FSMO распределены между вашими серверами и при выводе сервера из эксплуатации на длительный срок передавать эти роли другим серверам. А что будет если сервер содержащий роли FSMO необратимо выйдет из строя? Ничего страшного, как мы уже писали, любой контроллер домена содержит всю необходимую информацию и если такая неприятность все же произошла, то нужно будет выполнить захват необходимых ролей одним из контроллеров, это позволит восстановить полноценную работу службы каталогов.
Проходит время, ваша организация растет и у нее появляется филиал в другом конце города и возникает необходимость включить их сеть в общую инфраструктуру предприятия. На первый взгляд ничего сложного, вы настраиваете канал связи между офисами и размещаете в нем дополнительный контроллер. Все бы хорошо, но есть одно но. Данный сервер вы контролировать не можете, а следовательно не исключен несанкционированный доступ к нему, да и местный админ вызывает у вас сомнения в его квалификации. Как быть в такой ситуации? Для этих целей специально существует особый тип контроллера: контроллер домена доступный только на чтение (RODC), данная функция доступна в режимах работы домена начиная с Windows Server 2008 и выше.
Контроллер домена доступный только для чтения содержит полную копию всех объектов домена и может быть глобальным каталогом, однако не позволяет вносить никаких изменений в структуру AD, также он позволяет назначить любого пользователя локальным администратором, что позволит ему полноценно обслуживать данный сервер, но опять таки без доступа к службам AD. В нашем случае это то, что «доктор прописал».
Следующий фактор, отравляющий нам жизнь в этой ситуации, это репликация. Как известно, все изменения, сделанные на одном из контроллеров домена, автоматически распространяются на другие и называется этот процесс репликацией, он позволяет иметь на каждом контроллере актуальную и непротиворечивую копию данных. Служба репликации не знает о нашем филиале и медленном канале связи и поэтому все изменения в офисе тут же будут реплицироваться в филиал, загружая канал и увеличивая расход трафика.
Здесь мы вплотную подошли к понятию сайтов AD, которые не следует путать с интернет сайтами. Сайты Active Directory представляют способ физического деления структуры службы каталогов на области отделенные от других областей медленными и/или нестабильными каналами связи. Сайты создаются на основе подсетей и все клиентские запросы отправляются в первую очередь контроллерам своего сайта, также крайне желательно иметь в каждом сайте свой глобальный каталог. В нашем случае потребуется создать два сайта: AD Site 1 для центрального офиса и AD Site 2 для филиала, точнее один, так как по умолчанию структура AD уже содержит сайт, куда входят все ранее созданные объекты. Теперь рассмотрим как происходит репликация в сети с несколькими сайтами.
Будем считать, что наша организация немного подросла и главный офис содержит целых четыре контроллера домена, репликация между контроллерами одного сайта называется внутрисайтовой и происходит моментально. Топология репликации строится по схеме кольца с условием, чтобы между любыми контроллерами домена было не более трех шагов репликации. Схема кольца сохраняется до 7 контроллеров включительно, каждый контроллер устанавливает связь с двумя ближайшими соседями, при большем числе контроллеров появляются дополнительные связи и общее кольцо как бы превращается в группу наложенных друг на друга колец.
Межсайтовая репликация происходит иначе, в каждом домене автоматически выбирается один из серверов (сервер-плацдарм) который устанавливает связь с аналогичным сервером другого сайта. Репликация по умолчанию происходит раз в 3 часа (180 минут), однако мы можем установить собственное расписание репликации и для экономии трафика все данные передаются в сжатом виде. При наличии в сайте только RODC репликация происходит однонаправленно.
Безусловно, затронутые нами темы весьма глубоки и в данном материале мы только слегка их коснулись, однако это тот необходимый минимум знаний, который нужно иметь перед практическим внедрением Active Directiry в инфраструктуру предприятия. Это позволит избежать глупых ошибок при развертывании и авральных ситуаций при обслуживании и расширении структуры, а каждая из поднятых тем еще будет обсуждаться более подробно.
Дополнительные материалы:
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
