Active directory простыми словами. что такое active directory. для чего нужен active directory

Active Directory от простого к сложному. ЧастьI

Часть I.

 Свободное изложение про это…

Давайте постепенно будем разбирать такое понятие как ActiveDirectory(AD) или я буду писать АД что бы не менять раскладку клавиатуры, а то постоянно забываю переключатся.

Итак, что такое ActiveDirectory?  Что бы понять это «понятие»,  и почему не только Микрософт но и другие производители операционных систем сделали такое же «фишку» в своих операционных системах( Novell  службу каталогов NDS), начнем с истории.

Почему с истории, да потому что тогда станет ясно, что сама жизнь указала на создание такого механизма или лучше скажем так – «не от хорошей жизни»  специалисты создали такую «фишку». Я называю пока ActiveDirectory«фишкой», так как предположим, что пока Вы, читатели,  не знаете что это за зверь такой ActiveDirectory. По ходу изложения мы будем излагаться все профессиональнее. 

Предположим у нас три компа и один сервер. В дальнейшем,  что бы не забыть,  я буду обозначать компы  — ПК от словосочетания персональный компьютер или PC. Так вот,  у нас три компа, и три пользователя.

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

Получится такая картина как на рисунке 1.

Рисунок 1.

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

Исходя из рисунка 1 сетевой администратор прописывает на ПК1 учетные записи для пользователей Вася и Катя, на ПК2 – Толю и Игоря, а на ПК3 – Ивана и Веру (как он это делает конкретно, мы рассмотрим позже).

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

И только прописал пользователей  админ, и сел попить пив….простите кофе после праведных трудов, как новое указание от «всевышних». Надо что бы не привязывать пользователей к строго определенному компьютеру, а позволить им работать за любым компьютером.

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

То теперь на каждом компьютере должны быть по 6 прописанных пользователей.

 Для тех кто не понимает что такое прописать пользователя – объясняю, вспомните если Вы конечно видели компьютеры, что иногда после того как вы включили компьютер, от Вас требуют какой-то «пароль», и Вы его спрашиваете у хозяина ПК и он «пароль» как правило  цифра 1 (это шутка, кто не понял, вернитесь после прочтения всех статьей и дико посмейтесь, над ламерами), и только после ввода пароля Вас пускают работать на компьютере. А требование ввести пароль не появляется при покупки компьютера, а специально прописывается сетевым администратором. И делается это для того что бы у каждого пользователя было свое собственное рабочее пространство, со своими «штучками» (под «штучками» пока что можете понимать какой фон рабочего стола у вас будет, какие программы будут доступны только вам и некому больше,и пока хватит) и еще это делается исхода из требований безопасности. И ХРАНЯТСЯ ВСЕ ЭТИ «пароли» ЛОКАЛЬНО, то есть на том ПК на котором они были прописаны (когда нет централизованного хранилища или AD, но об этом позже).  Только еще прошу запомнит что учетные записи еще называются «АКАУНТАМИ». Все!  — хватит для начала про учетные записи, так как я еще не сказал про «логин» и еще больше, Вас запутаю, но всему свое время и мы еще поговорим об Active Directory «по взрослому».

Итак, вернемся к нашему админу. Он идет и прописывает на каждом ПК всех сотрудников конторы.  Тоже пока что не страшно. А вот уже начинаются «мраки». В нашу контору взяли на работу еще сотрудников, и купили еще серверов и кучу компьютеров. Смотрите рисунок 2.

Рисунок 2. 

И тут понял админ что ему «крышка». Как стольких прописать, настроить, разрешить, одним словом – как все это «блин» администрировать.  Решил сперва застрелится, что бы не мучится. Это же ад, а не работа.  Но перед смертью решил написать Билу Гейтцу письмо. Пусть и у него совесть помучается.

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

Каждый пользователь грозится расправой когда в сотый раз на дню регистрируется на определенный сервер куда ему нужно, а так же что ничего не может найти в сети конторы. Шефы звереют от того что некоторые просматривают их любовную переписку. И так далее…(тут пропускаю). Так что прощай брат Бил..

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

И вот так появилось в помощь сетевым администраторов такой инструмент как ActiveDirectory.

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

После того как Бил помог Васи Пупкину,  акаунты (учетные записи) стали хранится централизовано, то есть в одном месте и отпало необходимость прописывать пользователей на каждом ПК и на каждом сервере в нашей сети, а пользователям достаточно один раз зарегистрироваться в сети и больше не надо регится на каждом сервере куда он хочет попасть.Красота. Да и вообще, все что есть у нас в сети ActiveDirectory хранит в одном месте, централизованно,а еще позволяет «пущать» и «не пущать» наглых пользователей куда попало, и позволяет так же управлять (администрировать)  всем что есть у нас в сети, не затрачивая дополнительные ресурсы, как в плане взятия на работу еще админов, так и в плане покупки дополнительных средств от сторонних производителей для администрирования сети и объектов находящихся в ней.

И вручил Бил от имени Мелкосовта персонально Васи такой инструмент как ActiveDirectory. И начал Вася с ним работать и увидел что это хорошо. И что у нас получилось с внедрением такого понятия как ActiveDirectory или как еще его называют – Службой каталогов. Смотрим рисунок 3.

Рисунок 3.

А теперь давайте поговорим по взрослому.

Каталог (directory) — называется совокупность информации об объектах, которые тем или иным способом связаны друг с другом.

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

Или более современный пример — телефонный справочник содержащий  информацию об абонентах телефонной сети.

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

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

Главная «фишка» или задача здесь в том, что бы предоставить пользователям возможность обнаружить (найти) эти объекты и использовать их, но под зорким глазом администратора, а не так как хотят пользователи.

Давайте разберем понятие объект. И рассмотрим это понятие именно в контексте сети. 

Объект – самостоятельная единица, которая представляет некий ресурс, существующий в сети (ПК, пользователи, ПО, …) со всеми его атрибутами.

 Что такое атрибут? Представьте, что у нас есть автомобиль, так вот автомобиль это объект, а его цвет, мощность и прочие это атрибуты или свойства и характеристики, или у Вас жена, жена объект, а цвет волос, длина ног, объем груди и талии,  вредность, ревнивость, и прочие это атрибуты характеризующие жену как объект (Гы!). Но мы не будем пользоваться, когда будем говорить об объектах в большинстве случае словосочетанием «свойства и характеристики» а будем говорить – его атрибуты. К примеру у объекта нашей сети такой как «пользователь» имеются такие атрибуты как -фамилия, имя, логин, пароль, адрес электронной почты и другие. Смотрите рисунок 4.

Рисунок 4.

Служба каталогов — (directoryservice),  (на то и служба что бы служить, и приносить нам хоть какуЮту пользу), и посредством исправной службы обеспечивает хранение всей необходимой для применения объектов и управление ими информации в одном месте (централизованно), и благодаря этому процесс обнаружения и администрирования ресурсами сети упрощается. В отличие от каталога, служба каталогов одновременно две роли;

  • Источника информации;
  • Механизма, с помощью которого эта информация подготавливается для доступа со стороны пользователей.

Служба каталогов – нечто вроде основной панели управления сетевой операционной системы (центрального пульта). Или что бы было совсем понятно.

Служба каталогов — это такое программное обеспечение (ну такая программа) в составе сетевой операционной системы, которая хранит всю информацию об объектах сети, и которая позволяет обнаруживать эти объекты (ну там различные компы, принтеры, юзверей и прочие, что есть у нас в сети, а все, что есть у нас в сети,  мы рассматриваем как объекты), предоставлять их в распоряжение пользователям,  и управлять ими (администрировать). Понятно? Нет???? Садитесь! Молчать! Два бала! Кх..Кх …отвлекся….

То есть на вопрос – что такое служба каталогов? Вы бойко отвечайте – это такое ПО (программное обеспечение) которая …далее что то мямлите … не забывая вставлять слово «хранит», «обнаруживать», «делать доступным пользователям»….и ….словосочетание «управлять ими», то бишь объектами.  

Контролер домена — это компьютер на котором установлено такое ПО как Active Directory. 

Так вот, уже слово «фишка», которым мы пользовались в начале нашего трудного повествования обрела некий смысл, и теперь она предстала перд нами как «Служба Каталогов». Что бы не путаться что такое  «Служба каталогов»  и «ActiveDirectory» ,  то я напишу так, а вы запомните «навечно».

Служба каталогов ActiveDirectory это программное обеспечение написанное (разработанное) Микрософтом. То есть Мелкософт назвал «службу каталогов» именем «ActiveDirectory». Novell  — NDS.

Ну, так окрестил свое детище Бил, правда по некоторым историческим данным он сперва хотел назвать «PupkinDirectory»,  но небезызвестный Вася был против (скромный блин).

И скажу даже больше –Служба каталогов ActiveDirectory входит в состав таких сетевых операционных системах производства Микрософт как – WindowsServer 2000 и  WindowsServer 2003 и старше.

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

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

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

Чем больше разрастается наша сеть, тем больше в ней объектов, которыми необходимо управлять, и тут без внедрения Службы Каталогов —  Active Directory не обойтись, что бы не уподобится Васи.

Характеристики служб Active Directory

  • Централизованное хранение данных. Все данные относящиеся к Active Directory хранятся в распределенном репозитарии что предполагает возможность доступа из любого места. Наличие единого репозитария хранилища данных сокращает издержки, связанные с администрированием и дублирование данных. Т есть храня все данные о наших объектах в одном месте (это место и есть каталог Active Directory) то нам и проще администрировать, и проще предоставлять пользователям доступ к ресурсам нашей сети. Можно добавить что появляется одна точка входа (читай регистрируются один раз и все) для пользователей (ПК , приложений) если нам что то нужно в сети.
  • Масштабируемость.  Active Directory позволяет масштабировать каталог (изменять, увеличивать) в соответствии с требованием нашей сети, путем конфигурирования доменов и деревьев, а так же позволяет добавлять новые контролеры доменов, количество объектов в составе одного домена могут исчисляться миллионами. Если другими словами то Active Directory обладает такими механизмами которые позволяют разбить этот репозитарий (читай базу данных) на разделы и при этом не потерять контроль над этой базой из-за ее большого размера,а так же ее централизацию (то есть хранить все в одном месте).  
  • Расширяемость. Структура базы данных (схема) Active Directory позволяет вносить в нее специальные типы данных, которых по умолчанию в нее нет. Эти типы данных определяют сами администраторы сети, если они ему так нужны.
  • Управляемость. В отличие от Windows NT в Active Directory построена на иерархической структуре объектов. Такое построение упрощает администрирование разрешений и других настройках безопасности, во -вторых позволяет пользователям найти сетевые ресурсы (папки, файлы, принтеры,…) легче.
  • Интеграция с системой доменных имен DNS. Active Directory обращается в своей работе к DNS. С помощью DNS клиенты определяют местоположение контролеров домена. При использовании собственной службы DNS Active Directory позволяет хранить первичные зоны непосредственно в Active Directory и их репликация среди других контролеров домена.
  • Администрирование на основе политик. Политики в Active Directory определяют что разрешено пользователям и компьютерам в рамках нашей сети (еще говорится сайта — но об этом чуть позже), домена или подразделения.
  • Возможность взаимодействия с другими службами каталогов. Active Directory построена на стандартных протоколах доступа к каталогам. Как понимать это предложение. А так перед тем как обратится к каталогам происходит такой ритуал в котором и обращающий и тот к кому обратился договариваются о способе взаимодействия. Договариваются посредством протоколов. Ну почти как мы посредством языка. Если язык один и тот же и (к примеру русский,то при желании можно договорится). Active Directory общается посредством так названого протокола — облегченный протокол службы каталогов (Lightweight Directory Access Protocol, LDAP). И любая другая служба каталогов которая поддерживает такой протокол может свободно договорится с Active Directory о взаимодействии между ними.
Читайте также:  Бесплатная компьютерная помощь. компьютерная помощь онлайн

В Windows Server 2003 протокол LDAP подписывается и шифруется.

Учитывая все сказанное давайте уточним еще раз что нам дает применение службы каталогов Active Directory:

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

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

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

Источник: http://alterego.ucoz.org/publ/active_directory/ad1/4-1-0-30

Просто о сложном

23.12.2013

Dmitry Bulanov Active Directory, Групповые политики, Предпочтения групповой политики, Windows Server 2012

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

Более продвинутые пользователи также знают и о том, что, начиная с 90-х годов минувшего столетия, мир впервые узнал о таком ассоциируемом с Windows-системами понятии, как Plug and Play или, проще говоря, о PnP, что представляет собой технологию, позволяющую операционной системе автоматически выполнять некоторые конфигурационные настройки для подключенных устройств. Ну а для появления дополнительных возможностей и корректной работы подключенных устройств, конечно, следует устанавливать драйверы, разработанные производителями комплектующих. В свою очередь, такие драйверы администраторы могут устанавливать на целевые компьютеры различными методами: могут самостоятельно бегать по компьютерам с компакт- или DVD-дисками и инсталлировать такие драйверы; могут разместить их в общедоступной папке на файловых серверах и инсталлировать их при помощи скриптов; интегрировать драйверы в операционные системы при помощи таких средств, как Windows ADK; устанавливать драйверы при помощи Microsoft System Center Configuration Manager, а также многими другими методами. Но, по большому счету, данная статья не об этом.

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

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

Больше

12.12.2013

Dmitry Bulanov Active Directory, Групповые политики, Предпочтения групповой политики, Windows Server 2012

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

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

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

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

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

Далее вы узнаете о том, какие бывают локальные учетные записи пользователей, кое-что узнаете об учетных записях групп, а также о том, каким образом можно управлять такими объектами при использовании функциональных возможностей групповой политики и элемента предпочтений «Локальные пользователи и группы». А начинать мы сейчас будем с

Больше

11.12.2013

Dmitry Bulanov Active Directory, Dynamic Access Control, Windows 8, Windows Server 2012

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

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

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

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

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

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

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

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

Более того, в этой статье вы узнаете о самом распространении и применении централизованных политик доступа.

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

Больше

02.12.2013

Dmitry Bulanov Active Directory, Windows 8, Windows Server 2012

Уже на протяжении трех статей этого цикла мы с вами обсуждаем интересную и относительно новую технологию, которая называется «Динамический контроль доступа» или же, как это звучит в оригинале, «Dynamic Access Control», DAC.

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

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

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

Более того, очень много внимания в данной, четвертой, статье этого интересного цикла будет отведено такой теме, как классификация файлов, причем, для реализации которой вы узнаете о таком средстве, как «Диспетчер ресурсов файлового сервера» или, проще говоря, FSRM.

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

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

Больше

27.11.2013

Dmitry Bulanov Active Directory, Windows 8, Windows Server 2012

Ты должен увидеть это сам. Не поздно отказаться. Потом пути назад не будет.

Примешь синюю таблетку — и сказке конец.

Ты проснешься в своей постели и поверишь, что это был сон.

Примешь красную таблетку — войдешь в страну чудес.

Я покажу тебе, насколько глубока кроличья нора.

К/ф. «Матрица»

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

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

Читайте также:  L2tp vpn-сервер на centos 7. установка и настройка сервера впн

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

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

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

Ну что же, далее я предлагаю нам проверить, «насколько глубока эта кроличья нора»…

Больше

25.04.2013

Dmitry Bulanov Active Directory, Windows Server 2012

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

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

А начинать, как видно из самого заголовка статьи, следует ни с чего иного, как с утверждений (они же, как я уже писал в предыдущей статье, еще называются заявками, клаймами и прочими словами, которыми можно заменить claim), которые смело можно отнести к одной из основных составляющих динамического контроля доступа.

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

Больше

15.04.2013

Dmitry Bulanov Active Directory, Windows 8, Windows Server 2012

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

Если говорить точнее, то всем понятно, что основной задачей роли «Доменные службы Active Directory» (Active Directory Domain Services) выступает выполнение операций, связанных с идентификацией и доступом.

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

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

СПОЙЛЕР: В данной статье подается сугубо теоретический материал, и эта статья не предполагает никаких поэтапных процедур.

Больше

Источник: https://dimanb.wordpress.com/category/active-directory/

Управление организационными подразделениями (OU) в домене Active Directory

Организационное подразделение (Organizational Unit — OU) представляет собой контейнер в домене Active Directory, который может содержать различные объекты из того же самого домена AD: другие контейнеры, группы, аккаунты пользователей и компьютеров. OU представляет собой единицу административного управления внутри домена, на который администратор может назначить объекты групповых политик и назначить разрешения другим пользователем.

Таким образом, выделим две основные задачи использования OU кроме хранения объектов Active Directory

  • Делегирование управления и административных задач внутри домена другим администраторам и обычным пользователям без предоставления им прав администратора домена;
  • Назначение групповых политик на все объекты (пользователей и компьютеры), которые находятся в данном подразделении (OU).

Как создать Organizational Unit с помощью консоли ADUC

Для создания Organizational Unit ваша учетная запись должна обладать правами Domain Admins, или ей должны быть делегированы полномочия на создание новый OU (во всем домене или конкретном контейнере).

Откройте оснастку Active Directory Users and Conputers (ADUC – dsa.msc) и выберите контейнер домена, в котором вы хотите создать новый OU (мы создадим новый OU в корне домене). Щелкните ПКМ по имени домена и выберите New -> Organizational Unit. Укажите имя создаваемого OU.

По умолчанию все создаваемые Organizational Unit защищены от случайного удаления.

Если вы откроете свойства созданного OU, вы увидите что на вкладке Object включена опция «Protect object from accidental deletion». Чтобы вы могли удалить данный OU, нужно снять данный чекбокс. При удалении OU удаляются все другие объекты, которое содержатся в контейнере.

Структура OU в Active Directory

В небольших инфраструктурах AD (20-50 пользователей) необязательно создавать новые OU, можно все складывать в дефолтные контейнеры в корне (Users и Computer). В большой инфраструктуре желательно разделить все объекты на разные контейнеры. В основном используется иерархический дизайн Organizational Unit в AD, по географическому или функциональному принципу.

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

Внутри последних можно создать отдельные контейнеры для администраторов, групп, компьютеров, серверов и пользователей (см скриншот). При необходимости вы можете добавить дополнительные уровни иерархии (здания, отделы и т.д.).

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

Как создать OU с помощью PowerShell

Ранее для создания OU в AD можно было использовать консольную утилиту dsadd. Например, для создания OU в домене можно выполнить такую команду:

dsadd ou “ou=Kazahstan,dc=vmblog,dc=ru”

В Windows Server 2008 R2 появился отдельный модуль для работы с AD: Active Directory module для Windows PowerShell (входит в состав RSAT). Для создания Organizational Unit можно использовать командлет New-ADOrganizationalUnit. Например, создадим новый OU с именем Belarus в корне домена:

New-ADOrganizationalUnit -Name «Belarus»

Чтобы создать новый OU в существующем контейнере, выполните команду:

New-ADOrganizationalUnit -Name Minsk -Path «OU=Belarus,DC=vmblog,DC=ru» -Description «Belarus central office » -PassThru

Как делегировать полномочия на OU

При делегировании полномочия на OU другим пользователям желательно предоставлять права не непосредственно учетным записям пользователям, а административным группам. Таким образом, чтобы предоставить права на OU новому пользователю достаточно добавить его в предварительно созданную доменную группу.

Для делегирования щелкните ПКМ по OU и выберите пункт Delegate Control.

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

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

В данном примере мы делегировали членам группы AccountOperators полномочия на смену паролей всех пользователей в контейнере Belarus.

Источник: https://vmblog.ru/organization-units-ou-v-active-directory/

Наводим порядок в Active Directory

13.08.2009 Тони Мюррей

Знаете ли вы, какие объекты в вашем каталоге AD уже не нужны? А к кому обращаться, если требуется изменить содержимое или структуру лесов AD?

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

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

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

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

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

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

Ниже приводятся приемы и советы, как все это сделать. Для этого вводится концепция ответственных за объекты AD. Объектам AD назначаются ответственные — реальные сотрудники, которые помогут обеспечить регулярный контроль и порядок в среде AD.

Уточнение терминологии

Ответственный за объект AD — это конкретный человек, который непосредственно отвечает за объект или хотя бы просто знает, для чего служит данный объект.

Можно было бы использовать термин «контакт», но это слово уже применяется для обозначения определенного типа объектов в AD.

Можно было бы воспользоваться термином «владелец», но он тоже уже задействован в модели безопасности AD для обозначения создателя/владельца объекта.

Было бы замечательно, если бы в AD был предусмотрен атрибут «ответственный», который можно заполнять для указания ответственных за различные типы объектов AD.

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

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

Зачем нужны ответственные?

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

Некоторые полезные инструменты могут помочь обнаружить неиспользуемые объекты (например, утилита командной строки dsquery, а также AdFind и OldCmp от компании Joeware), но, поскольку удаление объектов потенциально опасно для систем и приложений, использующих AD, важно быть уверенным в том, что удаляемый объект действительно никем не используется. Как правило, для этого лучше всего переговорить с сотрудником, который отвечает за данный объект.

Во многих случаях этого человека трудно найти по атрибутам объекта. Часто у вас есть только имя объекта, с которым надо разобраться, например группа с названием OKP100 Staff.

Хорошо, если название OKP100 вам о чем-то говорит, в противном случае разобраться будет трудно. Описание объекта может содержать некоторую полезную информацию («Прежде чем вносить изменения, свяжитесь с Дж. П.

 Картером»), но может оказаться, что нужный сотрудник уже не работает в организации.

Как можно убедиться, встроенная функциональность позволяет определить владельца объекта AD. Для этого мы введем концепцию ответственных за объекты.

Ответственные могут пригодиться и при работе с активными объектами. Например, при обработке запроса на включение пользователя в состав группы, сотрудники могут обратиться к ответственному для подтверждения или отклонения запроса.

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

Назначение ответственных за объекты пользователя

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

Помимо стандартного применения — хранения учетных записей реальных людей, объекты пользователей могут создаваться для «должностных» учетных записей, используемых несколькими лицами (например, оператор автоматизированной системы), ресурсных учетных записей (почтовые ящики для переговорных комнат). Кроме того, это могут быть учетные записи системных служб или вспомогательные учетные записи для целей администрирования.

Я рекомендую назначать ответственных за все объекты пользовательских учетных данных, к какому бы виду они ни относились. Рассмотрим пример ресурсной учетной записи для почтового ящика переговорной комнаты Meeting Room C. Назначим хранителем учетной записи, скажем, Мэри Тейлор.

В оснастке Active Directory Users and Computers консоли MMC находим учетную запись Meeting Room C, открываем ее свойства и переходим на вкладку Organization. В разделе Manager нажимаем Change и с помощью выбора объектов находим и добавляем учетную запись пользователя Мэри Тейлор (см. экран 1).

Атрибут Manager является связанным атрибутом. Он представляет собой прямую ссылку, а парный ему атрибут directReports представляет собой соответствующую обратную ссылку.

Поскольку эти атрибуты являются связанными, после назначения Мэри менеджером учетной записи Meeting Room C при просмотре объекта Мэри Тейлор объект Meeting Room C будет отображаться в списке Direct reports (прямое подчинение; см. экран 2).

Читайте также:  Диск может быть переполнен или защищен от записи, либо файл занят другим приложением. нет доступа при удалении

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

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

Ниже приведены примеры результатов поиска с помощью средства AdFind, доступного на сайте www.joeware.net. В первом примере приведен запрос на выдачу всех пользовательских учетных записей, для которых Мэри Тейлор является хранителем.

На экране 3 приведен результат выполнения этого поискового запроса.

Следующий пример показывает, как найти ответственного за переговорную комнату:

Результат выполнения этого запроса будет выглядеть примерно следующим образом: CN=Mary Taylor, OU=Standard User Accounts, DC=ad, DC=fisheagle, DC=net.

Назначение ответственных за объекты групп

К сожалению, для объектов групп атрибуты manager и directReports не поддерживаются. Вместо них я рекомендую использовать аналогичную пару атрибутов managedBy и managedObjects.

Рассмотрим сказанное на примере группы Consulting Team, ответственным за которую мы назначим ту же Мэри Тейлор. Для этого в оснастке AD Users and Computers выберите данную группу, откройте свойства и перейдите на вкладку Managed By. В разделе Name нажмите Change и воспользуйтесь выбором объекта для поиска и добавления учетной записи Мэри Тейлор, как показано на экране 4.

Когда вы вносите изменения в оснастку AD Users and Computers, AD присваивает атрибуту managedBy группового объекта значение полного имени (DN) учетной записи Мэри Тейлор.

Обратите внимание, что при установке значения параметра Managed By вы можете установить флажок Manager can update membership list для изменения менеджером состава группы, см. экран 4.

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

Нужно иметь в виду, что в отличие от directReports, обратная ссылка managedObjects недоступна в оснастке Active Directory Users and Computers. Для просмотра обратной ссылки потребуется выполнить запрос LDAP или воспользоваться инструментарием типа ADSIEdit; отмечу, что необходимой возможностью обладает новая утилита Attribute Editor из комплекта Windows Server 2008.

Как и в случае атрибутов manager и directReport объектов пользователя, для просмотра взаимосвязей между группой и хранителем можно выполнить запрос к AD с помощью утилиты AdFind, как показано в следующем примере:

На экране 5 приведен результат выполнения запроса.

Чтобы определить ответственного для данного объекта, выполните следующий запрос AdFind:

Результатом его исполнения будет CN=Mary Taylor, OU=Standard User Accounts, DC=ad, DC=fisheagle, DC=net.

Указание ответственных для других типов объектов

Нетрудно распространить концепцию ответственных и на другие типы объектов AD. Например, компьютеры и организационные подразделения (OU) — следующие типы объектов, которые первыми приходят на ум. Они также поддерживают атрибуты связывания managedBy и managedObjects, так что можно задавать ответственного точно так же, как и для групп.

Ответственные и управление жизненным циклом объектов

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

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

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

Если у Мэри была вторая учетная запись для выполнения административных задач, я бы сразу удалил ее.

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

Наведение порядка в действующей инфраструктуре AD

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

Довольно часто встречается ситуация, когда объект AD создается для решения какой-то временной задачи, а потом про него все забывают. Например, для работы с новой системой управления документами часто создаются новые учетные записи и группы.

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

Ниже приведены примеры применения средств командной строки для обнаружения неиспользуемых объектов. Эти примеры никоим образом не претендуют на полноту, но могут послужить хорошей отправной точкой. Из соображений единообразия для поиска неактивных пользователей и компьютеров я использую AdFind, хотя тех же результатов можно достичь с использованием OldCMP или dsquery.

Поиск неактивных пользователей

Приведенный ниже запрос (пишется в одну строку) использует AdFind для поиска учетных записей пользователей, которые никогда не выполняли регистрацию в домене или не регистрировались в домене с начала 2008 года. Результат выполнения запроса будет выдан в формате CSV.

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

При поиске используется атрибут lastLogonTimestamp (это реплицируемый атрибут, который периодически обновляется и который не так точен, как нереплицируемый атрибут lastLogon).

Поиск по реплицируемому атрибуту позволяет опрашивать один контроллер домена (DC) и не пытаться консолидировать значения lastLogon для всех имеющихся в домене контроллеров. Атрибут lastLogonTimestamp появился, начиная с Windows Server 2003, и используется во всех более новых версиях.

Поиск неактивных объектов компьютера

Как и при поиске неактивных учетных записей пользователей, приведенный ниже запрос (пишется в одну строку) использует AdFind для поиска учетных записей компьютеров, которые никогда не регистрировались в домене или не регистрировались с начала 2008 года.

Поиск групп, не содержащих никаких объектов

Бывает очень трудно определить, используется ли группа в AD.

В случае с пользователями и компьютерами вы можете определить, когда последний раз менялся пароль объекта в домене (атрибут pwdLastSet) или когда пользователь или компьютер в последний раз регистрировался в домене (атрибут lastLogonTimestamp). Но у групп нет паролей, они не регистрируются в AD и у них нет атрибутов, которые могли бы ответить, используется ли данная группа.

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

В приведенном ниже запросе AdFind используется для обнаружения всех групп, не имеющих членов, что, как отмечалось ранее, является признаком неиспользуемой группы. Обратите внимание, что из поиска исключаются критически важные системные объекты (такие, как встроенная группа Enterprise Admins), которые могут быть пустыми и никогда не должны удаляться из AD.

Обратите внимание: очень важно проверять правильность результатов этих поисковых запросов. Поиск через LDAP объектов AD, как в приведенных выше примерах, — только один аспект общей задачи. Необходимо также тщательно проверить полученные результаты.

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

Максимальный результат при минимуме усилий

Какую бы терминологию вы ни использовали — менеджер, владелец, контакт или ответственный, концепция связывания объектов AD с реальными людьми не нова. В конце концов, разработчики Microsoft предусмотрели эти взаимосвязи в AD через связанные пары атрибутов managedBy и managedObjects для определенных типов объектов.

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

Тони Мюррей (tony@activedir.org) — специалист по службам каталогов и почтовым системам, поддерживает сайт ActiveDir.org. Имеет звание MVP и сертификат MCSE

Источник: https://www.osp.ru/winitpro/2009/06/9845768

Структура хранилища Active Directory

В статье кратко представлена информация о структуре и архитектуре Active Directory, терминология и основные компоненты.

Термины

В таблице приведена терминология Active Directory.

Сервер Компьютер, выполняющий определённые роли в домене
Контроллер домена Сервер, хранящий каталог и обслуживающий запросы пользователей к каталогу. Помимо хранения данных контроллер домена может выступать в качестве одной из FSMO-ролей
Домен Минимальная структурная единица организации Active Directory (может состоять из пользователей, компьютеров, принтеров, прочих общих ресурсов)
Дерево доменов Иерархическая система доменов, имеющая единый корень (корневой домен)
Лес доменов Множество деревьев доменов, находящихся в различных формах доверительных отношений

Что такое AD?

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

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

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

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

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

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

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

Схема по умолчанию содержит все определения и описания объектов, которые необходимы для корректной работы Active Directory.

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

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

Структура и архитектура хранилища Active Directory

Структура и архитектура хранилища Active Directory состоит из четырех частей:

Домены и леса

Леса, домены и организационные единицы (OU) составляют основные элементы логической структуры Active Directory. Лес определяет единый каталог и представляет границу безопасности. Леса содержат домены.

DNS

DNS обеспечивает разрешение имен в иерархической архитектуре, которую может использовать Active Directory.

Схема (Schema)

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

 

Хранилище данных (Data Store)

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

 

Более подробная информация находится на сайте разработчика Microsoft.

Источник: https://1cloud.ru/help/windows/struktura-hranilischa-active-directory

Ссылка на основную публикацию