В 2002 году, прогуливаясь по коридору кафедры информатики своего любимого университета, я увидел на двери кабинета «Системы NT» свежий плакат. На плакате были изображены иконки пользовательских аккаунтов, объединенные в группы, от которых в свою очередь отходили стрелки к другим иконкам. Все это схематично объединялось в некую структуру, было написано что-то про единую систему входа, авторизацию и тому подобное. Насколько сейчас понимаю на том плакате была изображена архитектура систем Windows NT 4.0 Domains и Windows 2000 Active Directory. С этого момента началось и сразу же закончилось мое первое знакомство с Active Directory, так как потом была тяжелая сессия, веселые каникулы, после которых друг поделился дисками FreeBSD 4 и Red Hat Linux, и на ближайшие несколько лет я погрузился в мир Unix-подобных систем, но содержимое плаката я так и не забыл.
К системам на платформе Windows Server мне пришлось вернуться и более тесно с ними познакомиться, когда я перешел работать в компанию, где управление всей ИТ-инфраструктурой было основано на Active Directory. Помню, что главный админ той компании на каждом совещании все время что-то твердил про какие-то Active Directory Best Practices. Теперь, после 8 лет периодического общения с Active Directory, я достаточно хорошо понимаю, как работает данная система и что такое Active Directory Best Practices.
Как вы уже, наверное, догадались, речь пойдет про Active Directory.
Всем, кому интересна данная тема, добро пожаловать по кат.
Данные рекомендации справедливы для клиентских систем начиная с Windows 7 и выше, для доменов и лесов уровня Windows Server 2008/R2 и выше.
Стандартизация
Планирование Active Directory следует начать с разработки своих стандартов назначения имен объектов и их расположения в каталоге. Необходимо создать документ, в котором определить все необходимые стандарты. Конечно, это довольно частая рекомендация для ИТ специалистов. Принцип «сначала пишем документацию, а потом по данной документации строим систему» является очень хорошим, но он редко реализуем на практике по многим причинам. Среди этих причин - простая человеческая лень или отсутствие соответствующей компетенции, остальные причины являются производными от первых двух.
Рекомендую - сначала напишите документацию, все обдумайте и только потом приступайте к инсталляции первого контроллера домена.
Для примера приведу раздел документа по стандартам названия объектов Active Directory.
Именование объектов.
- Название пользовательских групп должно начинаться с префикса GRUS_ (GR - Group, US - Users)
- Название компьютерных групп н должно начинаться с префикса GRCP_ (GR - Group, CP - Computers)
- Название групп делегирования полномочий должно начинаться с префикса GRDL_ (GR - Group, DL - Delegation)
- Название групп доступа к ресурсам должно начинаться с префикса GRRS_ (GR - Group, RS - resources)
- Название групп для политик должно начинаться с префиксов GPUS_, GPCP_ (GP - Group policy, US - Users, CP - Computers)
- Название клиентских компьютеров должно состоять из двух, трех букв от названия организации, за которыми через дефис должен следовать номер, например, nnt-01.
- Название серверов должно начинаться только из двух букв, за которыми через дефис должна следовать роль сервера и его номер, например, nn-dc01.
Ваш подход к написанию документации должен быть очень основательным, это позволит сэкономить большое количество времени в дальнейшем.
Упрощайте все, что возможно, старайтесь достигнуть равновесия
При построении Active Directory необходимо следовать принципу достижения равновесия, делая выбор в пользу простых и понятных механизмов.
Принцип равновесия заключается в том, чтобы достигнуть необходимого функционала и безопасности при максимальной простоте решения.
Необходимо стараться построить систему так, чтобы ее устройство было понятно самому не искушенному администратору или даже пользователю. Например, в свое время была рекомендация создавать структуру леса из нескольких доменов. Более того рекомендовалось разворачивать не только мультидоменные структуры, но и структуры из нескольких лесов. Возможно, такая рекомендация существовала из-за принципа «разделяй и властвуй», либо потому-то Microsoft всем твердила, что домен - это граница безопасности и разделив организацию на домены, мы получим отдельные структуры, которые проще контролировать по отдельности. Но как показала практика, что более просто обслуживать и контролировать однодоменные системы, где границами безопасности являются организационные единицы (OU), а не домены. Поэтому избегайте создания сложных мультидоменных структур, лучше группируйте объекты по OU.
Конечно, следует действовать без фанатизма, - если невозможно обойтись без нескольких доменов, то нужно создавать несколько доменов, также и с лесами. Главное, чтобы вы понимали, что делаете, и к чему это может привести.
Важно понимать, что простую инфраструктуру Active Directory проще администрировать и контролировать. Я бы даже сказал, что чем проще, тем безопаснее.
Применяйте принцип упрощения. Старайтесь достигнуть равновесия.
Соблюдайте принцип – «объект - группа»
Начинайте создание объектов Active Directory с создания группы для данного объекта, и уже группе назначайте необходимые права. Рассмотрим на примере. Вам необходимо создать аккаунт главного администратора. Создайте сначала группу Head Admins и только потом создайте сам аккаунт и добавьте его в данную группу. Группе Head Admins назначьте права главного администратора, например, добавив ее в группу Domain Admins. Почти всегда получается так, что через некоторое время приходит на работу еще один сотрудник, которому нужны аналогичные права, и вместо того, чтобы заниматься делегированием прав на разные разделы Active Directory, будет возможно просто добавить его в необходимую группу, для которой в системе уже определена роль и делегированы необходимые полномочия.
Еще один пример. Вам необходимо делегировать права на OU с пользователями группе системных администраторов. Не делегируйте права напрямую группе администраторов, а создайте специальную группу вроде GRDL_OUName_Operator_Accounts, которой назначьте права. Потом просто добавьте в группу GRDL_OUName_Operator_Accounts группу ответственных администраторов. Обязательно получиться так, что в скором будущем, вам понадобиться делегировать другой группе администраторов права на данную OU. И в этом случае вы просто добавите группу данных администраторов в группу делегирования GRDL_OUName_Operator_Accounts.
Предлагаю следующую структуру групп.
- Группы пользователей (GRUS_)
- Группы администраторов (GRAD_)
- Группы делегирования (GRDL_)
- Группы политик (GRGP_)
- Группы серверов (GRSR_)
- Группы клиентских компьютеров (GRCP_)
- Группы доступа к общим ресурсам (GRRS_)
- Группы доступа к принтерам (GRPR_)
Соблюдайте принцип равновесия, ограничьте количество ролей для групп и помните, что название группы должно в идеале полностью описывать ее роль.
Архитектура OU.
Архитектуру OU в первую очередь следует продумывать с точки зрения безопасности и делегирования прав на данную OU системным администраторам. Не рекомендую планировать архитектуру OU с точки зрения привязки к ним групповых политик (хотя так чаще всего и делают). Для некоторых покажется немного странной моя рекомендация, но я не рекомендую вообще привязывать групповые политики к OU. Подробности читайте в секции Групповые политики.
OU Admins
Рекомендую выделить для административных аккаунтов и групп отдельную OU, куда поместить аккаунты и группы всех администраторов и инженеров технической поддержки. К данной OU следует ограничить доступ для обычных пользователей, а управление объектами из данной OU делегировать только главным администраторам.
OU Computers
OU для компьютеров лучше всего планировать с точки зрения географической принадлежности компьютеров и типов компьютеров. Распределите компьютеры с разных географических локаций по разным OU, а их в свою очередь разделите на клиентские компьютеры и серверы. Серверы можно еще поделить на Exchange, SQL и другие.
Пользователи, права в Active Directory
Пользовательским аккаунтам Active Directory следует уделять особое внимание. Как было сказано в секции про OU, пользовательские аккаунты следует группировать исходя из принципа делегирования полномочий на данные аккаунты. Также важно соблюдать принцип минимальных привилегий - чем меньше у пользователя прав в системе, тем лучше. Рекомендую сразу закладывать уровень привилегий пользователя в название его аккаунта. Аккаунт для повседневной работы должен состоять из Фамилии пользователя и инициалов на латинице (Например, IvanovIV или IVIvanov). Обязательными полями являются: First Name, Initials, Last Name, Display Name (на русском), email, mobile, Job Title, Manager.
Аккаунты администраторов должны быть следующих типов:
- С правами администратора на пользовательские компьютеры, но не серверы. Должны состоять из инициалов владельца и приставки local (Например, iivlocal)
- С правами на администрирование серверов и Active Directory. Должны состоять только из инициалов (Например, iiv).
Поясню, зачем следует разделять административные аккаунты на администраторов серверов и администраторов клиентских компьютеров. Делать это необходимо, из соображений безопасности. Администраторы клиентских компьютеров будут иметь право на установку софта на клиентских компьютерах. Какой и для чего софт будет устанавливаться, сказать никогда точно нельзя. Поэтому запускать установку программы с правами доменного администратора небезопасно, можно скомпрометировать весь домен. Необходимо администрировать клиентские компьютеры только с правами локального администратора данного компьютера. Это сделает невозможным целый ряд атак на аккаунты доменных администраторов, вроде «Pass The Hash». Дополнительно администраторам клиентских компьютеров необходимо закрыть подключение через службу терминалов и подключение по сети к компьютеру. Компьютеры технической поддержки и администраторов следует поместить в отдельный VLAN, чтобы ограничить к ним доступ из сети клиентских компьютеров.
Выделение прав администратора пользователям
Если вам необходимо дать права администратора пользователю, ни в коем случае не помещайте его учетную запись для повседневной работы в группу локальных администраторов компьютера. Учетная запись для повседневной работы должна быть всегда ограничена в правах. Создайте для него отдельную административную учетную запись вида namelocal и добавьте данную учетную запись в группу локальных администраторов при помощи политики, ограничив ее применение только на компьютере пользователя при помощи item-level targeting. Данной учетной записью пользователь сможет пользоваться, используя механизм Run AS.
Политики паролей
Создайте отдельные политики паролей для пользователей и администраторов при помощи fine-grained password policy. Желательно, чтобы пользовательский пароль состоял минимум из 8 символов и менялся хотя бы раз в квартал. Администраторам желательно менять пароль каждые два месяца, и он должен быть минимум из 10-15 символов и отвечать требованиям сложности.
Состав доменных и локальных групп. Механизм Restricted Groups
Состав доменных и локальных групп компьютерах домена должен контролироваться только в автоматическом режиме, при помощи механизма Restricted Groups. Почему это необходимо делать только таким образом, объясню на следующем примере. Обычно после того, как разрвенут домен Active Directory, администраторы добавляют себя в доменные группы вроде Domain admins, Enterprise admins, добавляют в нужные группы инженеров технической поддержки и остальных пользователей тоже распределяют по группам. В процессе администрирования данного домена процесс выдачи прав повторяется многократно и будет крайне сложно вспомнить, что ты вчера временно добавлял бухгалтера Нину Петровну в группу администраторов 1С и что сегодня необходимо ее из это группы убрать. Ситуация усугубится, если в компании работает несколько администраторов и каждый время от времени выдает права пользователям в подобно стиле. Уже через год будет почти невозможно разобраться в том, какие кому права назначены. Поэтому состав групп должен контролироваться только групповыми политиками, которые при каждом применении будут приводить все в порядок.
Состав встроенных групп
Стоит сказать, что встроенные группы вроде Account Operators, Backup operators, Crypt Operators, Guests, Print Operators, Server Operators должны быть пустыми, как в домене, так и на клиентских компьютерах. Эти группы в первую очередь необходимы для обеспечения обратной совместимости со старыми системами, и пользователи данных групп наделяются слишком большими правами в системе, и становятся возможны атаки на повышение привилегий.
Учетные записи локальных администраторов
При помощи механизма Restricted Groups необходимо блокировать учетные записи локальных администраторов на локальных компьютерах, блокировать гостевые учетные записи и очищать группу локальных администраторов на локальных компьютерах. Ни в коем случае не используйте групповые политики для установки паролей на учетные записи локальных администраторов. Этот механизм не безопасен, пароль можно извлечь прямо из политики. Но, если вы решили не блокировать учетные записи локальных администраторов, то для корректной установки паролей и их ротации используйте механизм LAPS. К сожалению, настройка LAPS не до конца автоматизирована, и поэтому нужно будет в ручном режиме добавлять атрибуты в схему Active Directory, выдавать на них права, назначать группы и так далее. Поэтому проще заблокировать аккаунты локальных администраторов.
Сервисные учетные записи.
Для запуска сервисов используйте сервисные учетные записи и механизм gMSA (доступен в системах Windows 2012 и выше)
Групповые Политики
Документируйте политики перед созданием/изменением.
При создании политики используйте принцип «Политика - группа». То есть перед созданием политики создайте сначала группу для данной политики, уберите из области применения политики группу Authenticated users и добавьте созданную группу. Политику привяжите не к OU, а к корню домена и регулируйте область ее применения при помощи добавления объектов в группу политики. Такой механизм я считаю более гибким и понятным, чем линковку политики к OU. (Именно про это я писал в секции про Архитектуру OU).
Всегда регулируйте область применения политики. Если вы создали политику только для пользователей, то отключайте структуру компьютер и наоборот, отключайте структуру пользователь, если создали политику только для компьютеров. Благодаря этим настройкам, политики будут более быстро применяться.
Настройте ежедневное резервное копирование политик при помощи Power Shell, чтобы в случае ошибок конфигурирования можно было всегда вернуть настройки к исходным.
Центральное хранилище шаблонов (Central Store)
Начиная с Windows 2008 стало возможным хранить ADMX-шаблоны групповых политик в центральном хранилище, в SYSVOL. До этого по умолчанию все шаблоны политик хранились локально, на клиентах. Чтобы разместить шаблоны ADMX в центральном хранилище, необходимо скопировать содержимое папки %SystemDrive%\Windows\PolicyDefinitions вместе с подпапками с клиентских систем (Windows 7/8/8.1) в директорию контроллера домена %SystemDrive%\Windows\SYSVOL\domain\Policies\PolicyDefinitions со слиянием содержимого, но без замены. Далее следует сделать такое же копирование с серверных систем, начиная с самой старой. В последнюю очередь, при копировании папок и файлов с самой последней версии сервера, сделайте копирование со слиянием и ЗАМЕНОЙ.
Копирование ADMX-шаблонов
Дополнительно в центральном хранилище можно размещать ADMX-шаблоны для любых программных продуктов, например, таких как Microsoft Office, продукты Adobe, Google и других. Зайдите на сайт поставщика программного продукта, скачайте ADMX-шаблон групповой политики и распакуйте его в папку %SystemDrive%\Windows\SYSVOL\domain\Policies\PolicyDefinitions на любом из контроллеров домена. Теперь вы сможете управлять нужным вам программным продуктом через групповые политики.
Фильтры WMI
Фильтры WMI не очень быстро работают, поэтому предпочтительнее использовать механизм item-level targeting. Но если item-level targeting использовать невозможно, и вы решили использовать WMI, то рекомендую сразу создать для себя несколько самых распространённых фильтров: фильтр «Только клиентские операционные системы», «Только серверные операционные системы», фильтры «Windows 7», фильтры «Windows 8», «Windows 8.1», «Windows 10». Если у вас будут готовые наборы WMI фильтров, то потом будет проще применить нужный фильтр к нужной политике.
Аудит событий Active Directory
Обязательно включите аудит событий на контроллерах домена и других серверах. Рекомендую включить аудит следующих объектов:
- Audit Computer Account Management - Success, Failure
- Audit Other Account Management Events - Success, Failure
- Audit Security Group Management - Success, Failure
- Audit User Account Management - Success, Failure
- Audit Kerberos Authentication Service - Failure
- Audit Other Account Logon Events - Failure
- Audit Audit Policy Change - Success, Failure
Расширенные настройки аудита
Подробно останавливаться на настройках аудита не буду, так как в Сети есть достаточное количество статей, посвященных данной теме. Дополню только, что помимо включения аудита, следует настроить оповещения по e-mail о критических событиях безопасности. Стоит также учесть то, что в системах с обильным количеством событий стоит выделить отдельные серверы для сбора и анализа файлов журнала.
Скрипты администрирования и уборки
Все однотипные и часто повторяемые действия необходимо выполнять при помощи скриптов администрирования. Среди таких действий: создание аккаунтов пользователей, создание аккаунтов администраторов, создание групп, создание OU и так далее. Создание объектов при помощи скриптов позволит соблюдать вашу логику названия объектов Active Directory, встроив проверки синтаксиса прямо в скрипты.
Также стоит написать скрипты уборки, которые будут в автоматическом режиме контролировать составы групп, выявлять пользователей и компьютеры, которые давно не подключались к домену, выявлять нарушение другие ваших стандартов так далее.
Я не встречал в качестве явной официальной рекомендации использование скриптов администрирования для контроля соблюдения стандартов и выполнения фоновых операций. Но сам предпочитаю проверки и процедуры в автоматическом режиме при помощи скриптов, так как это очень сильно экономит время и избавляет от большого количества ошибок и, конечно, здесь сказывается мой немного юниксовый подход к администрированию, когда проще набрать пару команд, чем щелкать мышкой по окнам.
Ручное администрирование
Часть операций по администрированию вам и вашим коллегам будет необходимо делать в ручном режиме. Для этих целей рекомендую использовать консоль mmc с добавленными в нее оснастками.
Как будет сказано далее, контроллеры домена у вас должны функционировать в режиме Server Core, то есть администрирование всего окружения AD следует выполнять только со своего компьютера при помощи консолей. Для администрирования Active Directory необходимо на свой компьютер поставить Remote Server Administration Tools. Консоли следует запускать на вашем компьютере из-под пользователя с правами администратора Active Directory, которому делегировано управление.
Искусство управления Active Directory при помощи консолей требует отдельной статьи, а может быть даже и отдельного обучающего видео, поэтому здесь только говорю про сам принцип.
Контроллеры домена
В любом домене, контроллеров должно быть, как минимум два. На контроллерах домена должно быть, как можно меньше служб. Не стоит делать из контроллера домена файловый сервер или, упаси вас бог, поднять на нем роль сервера терминалов. Используйте на контроллерах домена операционные системы в режиме Server Core, удалив полностью поддержку WoW64, это значительно уменьшит количество необходимых обновлений и увеличит их безопасность.
Microsoft раньше не рекомендовала виртуализировать контроллеры домена в виду того, что при восстановлении из моментальных снимков были возможны трудноразрешимые конфликты репликации. Возможно, были еще причины, точно сказать не могу. Сейчас гипервизоры научились сообщать контроллерам о восстановлении их из моментальных снимков, и эта проблема исчезла. Я же все время виртуализировал контроллеры, не делая никаких моментальных снимков, так как не понимаю, зачем вообще может понадобиться делать таковые на контроллерах домена. По-моему, проще сделать резервную копию контроллера домена стандартными средствами. Поэтому, рекомендую виртуализировать все контроллеры домена, которые только возможно. Такая конфигурация будет более гибкой. При виртуализации контроллеров домена располагайте их на разных физических хостах.
Если вам необходимо разместить контроллер домена в незащищенной физической среде или в филиале вашей организации, то для этих целей используйте RODC.
Роли FSMO, первичные и вторичные контроллеры
Роли FSMO контроллеров домена продолжают порождать страх в головах начинающих администраторов. Часто новички изучают Active Directory по устаревшей документации или слушают рассказы других администраторов, которые что-то где-то когда-то читали.
По всем пяти + 1 ролям вкратце следует сказать следующее. Начиная с Windows Server 2008 больше не существует первичных и вторичных контроллеров домена. Все пять ролей контроллеров домена переносимы, но не могут размещаться одновременно более, чем на одном контроллере. Если мы возьмем один из контроллеров, который, к примеру, был хозяином 4 ролей и удалим его, то все эти роли мы без проблем сможем перенести на другие контроллеры, и в домене ничего страшного не произойдет, ничего не сломается. Такое возможно потому, что всю информацию по работе, связанной с той или иной ролью ее хозяин хранит прямо в Active Directory. И если мы передаем роль другому контроллеру, то он в первую очередь обращается за сохраненной информацией в Active Directory и приступает к несению службы. Домен может достаточно долгое время существовать без хозяев ролей. Единственная «роль», которая должна быть всегда в Active Directory и без которой будет все очень плохо, это роль глобального каталога (GC), ее могут нести на себе все контроллеры в домене. Рекомендую назначать роль GC каждому контроллеру в домене, чем их больше, тем лучше. Конечно, вы сможете найти случаи, когда на контроллер домена не стоить устанавливать роль GC. Что ж, если не надо, так не надо. Следуйте рекомендациям без фанатизма.
Служба DNS
Служба DNS критична для работы Active Directory и работать она должна без сбоев. Службу DNS лучше всего ставить на каждый контроллер домена и хранить DNS зоны в самой Active Directory. Если вы будете использовать Active Directory для хранения зон DNS, то вам следует настраивать свойства TCP/IP соединения на контроллерах домена, таким образом, чтобы на каждом контроллере в качестве первичного DNS-сервера был любой другой DNS-сервер, а в качестве вторичного можно поставить адрес 127.0.0.1. Такую настройку делать необходимо потому, что для нормального старта службы Active Directory требуется работающий DNS, а для старта DNS должна быть запущена служба Active Directory, так как в ней лежит сама зона DNS.
Обязательно настройте зоны обратного просмотра для всех своих сетей и включите автоматическое безопасное обновление записей PTR.
Рекомендую дополнительно включить автоматическую уборку зоны от устаревших записей DNS (dns scavenging).
В качестве DNS-Forwarders рекомендую указать защищенные серверы Яндекс, если нет других более быстрых в вашей географической локации.
Сайты и репликация
Многие администраторы привыкли считать, что сайты - это географическое объединение компьютеров. Например, сайт Москва, сайт Петербург. Такое представление появилось из-за того, что первоначально деление Active Directory на сайты было сделано с целью балансировки и разделения сетевого трафика репликации. Контроллерам домена в Москве не обязательно знать, что в Петербурге было сейчас создано десять учетных записей компьютеров. И поэтому подобную информацию об изменениях можно передавать раз в час по расписанию. Или вообще производить репликацию изменений один раз в сутки и только ночью, для экономии полосы пропускания.
Про сайты я бы сказал так: сайты - это логические группы компьютеров. Компьютеров, которые соединены между собой хорошим сетевым соединением. А сами сайты соединены между собой соединением с малой пропускной способность, что в наше время большая редкость. Поэтому, я делю Active Directory на сайты не для балансировки трафика репликации, а для балансировки сетевой нагрузки вообще и для более быстрой обработки клиентских запросов компьютеров сайта. Поясню на примере. Есть 100-мегабитная локальная сеть организации, которую обслуживают два контроллера домена и есть облако, где располагаются серверы приложений этой организации с двумя другими облачными контроллерами. Такую сеть я поделю на два сайта для того, чтобы контроллеры в локальной сети обрабатывали запросы клиентов из локальной сети, а контроллеры в облаке запросы от серверов приложений. Дополнительно это позволит разделить запросы к службам DFS и Exchange. И так как сейчас я редко где встречаю канал в Интернет менее 10 мегабит в секунду, то я включу Notify Based Replication, это когда репликация данных происходит сразу, как только появились какие-либо изменения в Active Directory.
Заключение
Сегодня утром я думал о том, почему человеческий эгоизм не приветствуется в обществе и где-то на глубинном уровне восприятия вызывает крайне отрицательные эмоции. И единственный ответ, который пришел мне в голову, это то, что человеческая раса не выжила бы на этой планете, если бы не научилась совместному использованию физических и интеллектуальных ресурсов. Именно поэтому я и делюсь данной статьей с вами и, надеюсь, что мои рекомендации помогут вам улучшить свои системы, и вы станете значительно меньше тратить времени на поиск и устранение неисправностей. Все это приведет к освобождению большего количества времени и энергии для творчества. Гораздо приятнее жить в мире творческих и свободных людей.
Хорошо, если в комментариях вы по возможности поделитесь своими знаниями и практиками построения Active Directory.
Всем мира и добра!
Вы можете помочь и перевести немного средств на развитие сайта
Основополагающим компонентом доменных служб в каждой организации являются принципалы безопасности (оригинальное название - Security Principal), которые предоставляют пользователей, группы или компьютеры, которым требуется доступ к определенным ресурсам в сети. Именно таким объектам, как принципалам безопасности можно предоставлять разрешения доступа к ресурсам в сети, причем каждому принципалу во время создания объекта присваивается уникальный идентификатор безопасности (SID), который состоит из двух частей. Идентификатором безопасности SID называется числовое представление, которое уникально идентифицирует принципал безопасности. Первая часть такого идентификатора представляет собой идентификатор домена . Ввиду того, что принципалы безопасности расположены в одном домене, всем таким объектам присваивается один и тот же идентификатор домена. Второй частью SID является относительный идентификатор (RID) , который используется для уникальной идентификации принципала безопасности по отношению к ведомству, которое выдает SID.
Несмотря на то, что планирование и развертывание инфраструктуры доменных служб в большинстве организаций выполняется лишь один раз и в большинство объектов изменения вносятся очень редко, к важному исключению из этого правила можно отнести принципалы безопасности, которые необходимо периодически добавлять, изменять, а также удалять. Одним из основополагающих компонента идентификации являются учетные записи пользователей. По сути, учетные записи пользователей представляют собой физические объекты, в основном людей, которые являются сотрудниками вашей организации, но бывают исключения, когда учетные записи пользователей создаются для некоторых приложений в качестве служб. Учетные записи пользователей играют важнейшую роль в администрировании предприятии. К таким ролям можно отнести:
- Удостоверение личности пользователей , так как созданная учетная запись позволяет входить на компьютеры и в домены именно с теми данными, подлинность которых проверяет домен;
- Разрешения доступа к ресурсам домена , которые назначаются пользователю для предоставления доступа к доменным ресурсам на основании явных разрешений.
Объекты учетных записей пользователей можно отнести к самым распространенным объектам в Active Directory. Именно пользовательским учетным записям администраторы обязаны уделять особое внимание, так как пользователям свойственно приходить работать в организацию, перемещаться между отделами и офисами, жениться, выходить замуж, разводиться и даже увольняться из компании. Такие объекты представляют собой набор атрибутов, причем только одна пользовательская учетная запись может содержать свыше 250 различных атрибутов, что в несколько раз превышает количество атрибутов на рабочих станциях и компьютеров, работающих под операционной системой Linux. Во время создания учетной записи пользователя создается ограниченный набор атрибутов, а уже потом вы можете добавлять такие пользовательские учетные данные как организационные сведения, адреса проживания пользователей, телефонные номера и многое другое. Поэтому важно обратить внимание на то, что одни атрибуты являются обязательными , а остальные – опциональными . В этой статье я расскажу о ключевых методах создания пользовательских учетных записей, о некоторых опциональных атрибутах, а также будут описаны средства, позволяющие автоматизировать рутинные действия, связанные с созданием учетных записей пользователей.
Создание пользователей при помощи оснастки «Active Directory – пользователи и компьютеры»
В подавляющем большинстве случаев системные администраторы для создания основных принципалов безопасности предпочитают использовать оснастку , которая добавляется в папку «Администрирование» сразу после установки роли «Доменные службы Active Directory» и повышения сервера до контролера домена. Этот метод является наиболее удобным, так как для создания принципалов безопасности используется графический пользовательский интерфейс и мастер создания учетных записей пользователя очень прост в применении. К недостатку данного метода можно отнести тот момент, что при создании учетной записи пользователя вы не можете сразу задать большинство атрибутов, и вам придется добавлять необходимые атрибуты путем редактирования учетной записи. Для того чтобы создать пользовательскую учетную запись, выполните следующие действия:
- В поле «Имя» введите имя пользователя;
- В поле «Инициалы» введите его инициалы (чаще всего инициалы не используются);
- В поле «Фамилия» введите фамилию создаваемого пользователя;
- Поле «Полное имя» используется для создания таких атрибутов создаваемого объекта, как основное имя (Common Name) CN и отображения свойств имени. Это поле должно быть уникальным во всем домене, и заполняется автоматически, а изменять его стоит лишь в случае необходимости;
- Поле «Имя входа пользователя» является обязательным и предназначено для имени входа пользователя в домен. Здесь вам нужно ввести имя пользователя и из раскрывающегося списка выбрать суффикс UPN, который будет расположен после символа @;
- Поле «Имя входа пользователя (Пред-Windows 2000)» предназначено для имени входа для систем предшествующих операционной системе Windows 2000. В последние годы в организациях все реже встречаются обладатели таких систем, но поле обязательно, так как некоторое программное обеспечение для идентификации пользователей использует именно этот атрибут;
После того как заполните все требуемые поля, нажмите на кнопку «Далее» :
Рис. 2. Диалоговое окно создания пользовательской учетной записи
Рис. 3. Создание пароля для создаваемой учетной записи
Создание пользователей на основании шаблонов
Обычно в организациях существует множество подразделений или отделов, в которые входят ваши пользователи. В этих подразделениях пользователи обладают схожими свойствами (например, название отдела, должности, номер кабинета и пр.). Для наиболее эффективного управления учетными записями пользователей из одного подразделения, например, используя групповые политики, целесообразно их создавать внутри домена в специальных подразделениях (иначе говоря, контейнерах) на основании шаблонов. Шаблоном учетной записи называется учетная запись, впервые появившаяся еще во времена операционных систем Windows NT, в которой заранее заполнены общие для всех создаваемых пользователей атрибуты. Для того чтобы создать шаблон учетной записи пользователя, выполните следующие действия:
- Общие . Данная вкладка предназначена для заполнения индивидуальных пользовательских атрибутов. К этим атрибутам относятся имя пользователя и его фамилия, краткое описания для учетной записи, контактный телефон пользователя, номер комнаты, его электронный ящик, а также веб-сайт. Ввиду того, что данная информация является индивидуальной для каждого отдельного пользователя, данные заполненные на этой вкладке не копируются;
- Адрес . На текущей вкладке вы можете заполнить почтовый ящик, город, область, почтовый индекс и страну, где проживают пользователи, которые будут созданы на основании данного шаблона. Так как у каждого пользователя названия улиц обычно не совпадают, данные из этого поля не подлежат копированию;
- Учетная запись . В этой вкладке вы можете указать точно время входа пользователя, компьютеры, на которые смогут заходить пользователи, такие параметры учетных записей как хранение паролей, типы шифрования и пр., а также срок действия учетной записи;
- Профиль . Текущая вкладка позволяет вам указать путь к профилю, сценарий входа, локальный путь к домашней папке, а также сетевые диски, на которых будет размещена домашняя папка учетной записи;
- Организация . На этой вкладке вы можете указать должность сотрудников, отдел, в котором они работают, название организации, а также имя руководителя отдела;
- Члены групп . Здесь указывается основная группа и членство в группах.
Это основные вкладки, которые заполняются при создании шаблонов учетной записи. Помимо этих шести вкладок, вы можете еще заполнять информацию в 13 вкладках. Большинство из этих вкладок будут рассмотрены в последующих статьях данного цикла.
Рис. 5. Диалоговое окно копирования пользовательской учетной записи
Создание пользователей средствами командной строки
Как и в большинстве случаев, в операционной системе Windows есть утилиты командной строки с аналогичными функциями графического пользовательского интерфейса оснастки «Active Directory – пользователи и компьютеры» . Такие команды называются командами DS, так как они начинаются с букв DS. Для создания принципалов безопасности используется команда Dsadd . После самой команды указываются модификаторы, которые определяют тип и имя DN объекта. В случае с созданием учетных записей пользователей вам нужно указать модификатор user , который является типом объекта. После типа объекта необходимо ввести DN имя самого объекта. DN (Distinguished Name) объекта является результирующим набором, который содержит отличительное имя. Следом за DN обычно указывают имя пользователя UPN или имя входа предыдущих версий Windows. Если в имени DN присутствуют пробелы, то такое имя нужно заключить в кавычки. Синтаксис команды следующий:
Dsadd user DN_имя –samid имя_учетной_записи –UPN_имя –pwd пароль –дополнительные параметры
С данной командой можно использовать 41 параметр. Рассмотрим самые распространенные из них:
-samid – имя учетной записи пользователя;
-upn – имя входа пользователя пред-Windows 2000;
-fn – имя пользователя, которое в графическом интерфейсе заполняется в поле «Имя» ;
-mi – инициал пользователя;
-ln – фамилия пользователя, указываемая в поле «Фамилия» мастера создания пользовательской учетной записи;
-display – указывает полное имя пользователя, которое автоматически генерируется в пользовательском интерфейсе;
-empid – код сотрудника, который создается для пользователя;
-pwd – параметр, определяющий пользовательский пароль. В том случае, если вы укажете символ звездочки (*), вам будет предложено ввести пароль пользователя в защищенном от просмотра режиме;
-desc – краткое описание для пользовательской учетной записи;
-memberof – параметр, определяющий членство пользователя в одной или нескольких группах;
-office – местонахождения офиса, где работает пользователь. В свойствах учетной записи этот параметр можно найти во вкладке «Организация» ;
-tel – номер контактного телефона текущего пользователя;
-email – адрес электронной почты пользователя, который можно найти во вкладке «Общие» ;
-hometel – параметр, указывающий номер домашнего телефона пользователя;
-mobile – телефонный номер мобильного пользователя;
-fax – номер факсимильного аппарата, который использует текущий пользователь;
-title – должность пользователя в данной организации;
-dept – этот параметр позволяет указать наименование отдела, в котором работает данный пользователь;
-company – название компании, в которой работает создаваемый пользователь;
-hmdir – основной каталог пользователя, в котором будут расположены его документы;
-hmdrv – путь к сетевому диску, на котором будет размещена домашняя папка учетной записи
-profile – путь профиля пользователя;
-mustchpwd – данный параметр указывает на то, что при последующем входе в систему пользователь обязан изменить свой пароль;
-canchpwd – параметр, определяющий, должен ли пользователь изменять свой пароль. Если значением параметра указано «yes» , то у пользователя будет возможность изменения пароля;
-reversiblepwd – текущий параметр определяет хранение пароля пользователя с применением обратного шифрования;
-pwdneverexpires – параметр, указывающий на то, что срок действия пароля никогда не истечет. Во всех этих четырех параметрах, значениями могут выступать только «yes» или «no» ;
-acctexpires – параметр, определяющий, через сколько дней срок действия учетной записи истечет. Положительное значение представляет собой количество дней, через которое учетная запись истечет, а отрицательное означает, что срок действия уже закончен;
-disabled – указывает, что учетная запись уже отключена. Значениями для этого параметра также выступают «yes» или «no» ;
-q – указание тихого режима для обработки команды.
Пример использования:
Dsadd user “cn=Алексей Смирнов,OU=Маркетинг,OU=Пользователи,DC=testdomain,DC=com” -samid Alexey.Smirnov -upn Alexey.Smirnov -pwd * -fn Алексей -ln Смирнов -display “Алексей Смирнов” -tel “743-49-62” -email [email protected] -dept Маркетинг -company TestDomain -title Маркетолог -hmdir \\dc\profiles\Alexey.Smirnov -hmdrv X -mustchpwd yes -disabled no
Рис. 6. Создание пользовательской учетной записи средствами утилиты Dsadd
Создание пользователей при помощи команды CSVDE
Еще одна утилита командной строки CSVDE позволяет импортировать или экспортировать объекты Active Direcoty, представленные в виде cvd-файла – текстового файла с разделительными запятыми, которые можно создавать при помощи табличного процессора Microsoft Excel или простейшего текстового редактора Блокнот. В этом файле каждый объект представляется одной строкой и должен содержать атрибуты, которые перечислены в первой строке. Стоит обратить внимание на то, что при помощи данной команды вы не можете импортировать пользовательские пароли, то есть, сразу после завершения операции импорта пользовательские учетные записи будут отключены. Пример такого файла следующий:
Рис. 7. Представление CSV-файла
Синтаксис команды следующий:
Csvde –i –f filename.csv –k
- -i . Параметр, который отвечает за режим импорта. Если вы не укажите данный параметр, то эта команда будет использовать по умолчанию режим экспорта;
- -f
- -k
- -v
- -j
- -u . Параметр, позволяющий использовать режим Юникода.
Пример использования команды:
Csvde -i -f d:\testdomainusers.csv -k
Рис. 8. Импорт учетных записей пользователей из CSV-файла
Импорт пользователей средствами LDIFDE
Утилита командной строки Ldifde позволяет также импортировать или экспортировать объекты Active Directory, используя файловый формат LDIF (Lightweight Directory Access Protocol Data Interchange File). Данный файловый формат состоит из блока строк, которые образуют конкретную операцию. В отличие от файлов CSV, в данном файловом формате каждая отдельная строка представляет собой набор атрибутов, после которого следует двоеточие и само значение текущего атрибута. Также как и в CSV файле, первой строкой обязан быть атрибут DN. За ним следует строка changeType, которая указывает тип операции (add, change или delete). Для того чтобы научиться разбираться в этом файловом формате, вам нужно выучить по крайней мере ключевые атрибуты принципалов безопасности. Пример предоставлен ниже:
Рис. 9. Пример LDF файла
Синтаксис команды следующий:
Ldifde -i -f filename.csv -k
- -i . Параметр, который отвечает за режим импорта. Если вы не укажете данный параметр, то эта команда будет использовать по умолчанию режим экспорта;
- -f . Параметр, идентифицирующий имя файла, которое предназначено для импорта или экспорта;
- -k . Параметр, предназначенный для продолжения импорта пропуская все возможные ошибки;
- -v . Параметр, используя который вы можете вывести подробную информацию;
- -j . Параметр, отвечающий за расположение файла журнала;
- -d . Параметр, указывающий корень поиска LDAP;
- -f . Параметр, предназначенный для фильтра поиска LDAP;
- -p . Представляет собой область или глубину поиска;
- -l . Предназначен для указания списка атрибутов с разделительными запятыми, который будет включен в экспорт результирующих объектов;
Создание пользователей c помощью VBScript
VBScript является одним из самых мощных инструментов, предназначенных для автоматизации административных задач. Данный инструмент позволяет создавать сценарии, предназначенные для автоматизирования большинства действий, которые могут выполняться посредством пользовательского интерфейса. Сценарии VBScript представляют собой текстовые файлы, которые обычно пользователи могут редактировать при помощи обыкновенных текстовых редакторов (например, Блокнот). А для выполнения сценариев нужно просто дважды щелкнуть мышью по значку самого сценария, который откроется с применением команды Wscript. Для того чтобы создать пользовательскую учетную запись в VBScript не существует определенной команды, поэтому вам сначала нужно подключиться к контейнеру, затем использовать библиотеку адаптеров Active Directory Services Interface (ADSI) при помощи инструкции Get-Object, где выполняется строка запроса LDAP, предоставляющая собой моникер протокола LDAP:// с DN именем объекта. Например, Set objOU=GetObject(“LDAP://OU=Маркетинг,OU=Пользователи,dc=testdomain,dc=com”). Вторая строка кода активирует метод Create подразделения для создания объекта конкретного класса с конкретным отличительным именем, например, Set objUser=objOU.Create(“user”,”CN= Юрий Соловьев”). В качестве третьей строки указывается метод Put, где нужно указать наименование атрибута и его значение. Последняя строка данного сценария подтверждает сделанные изменения, то есть objUser.SetInfo().
Пример использования:
Set objOU=GetObject(“LDAP://OU=Маркетинг,OU=Пользователи,dc=testdomain,dc=com” Set objUser=objOU.Create(“user”,”CN= Юрий Соловьев”) objUser.Put “sAMAccountName”,”Yuriy.Soloviev” objUser.Put “UserPrincipalName” [email protected]” objUser.Put “givenName”,”Юрий” objUser.Put “sn”Соловьев” objUser.SetInfo()
Создание пользователей при помощи PowerShell
В операционной системе Windows Server 2008 R2 появилась возможность управлять объектами Active Directory средствами Windows PowerShell. Среда PowerShell считается мощнейшей оболочкой командной строки, разработанной на основе.Net Framework и предназначенной для управления и автоматизации администрирования операционных систем Windows и приложений, которые работают под данными операционными системами. PowerShell включает в себя свыше 150 инструментов командной строки, называемых командлетами, которые предоставляют возможность управления компьютерами предприятия из командной строки. Данная оболочка является компонентом операционной системы.
Для создания нового пользователя в домене Active Directory используется командлет New-ADUser, большинство значений свойств которого можно добавлять при помощи параметров данного командлета. Для отображения имени LDAP используется параметр –Path. Данный параметр задает контейнер или подразделение (OU) для нового пользователя. Если параметр Path не задан, командлет создает объект пользователя в контейнере по умолчанию для объектов пользователя в данном домене, то есть в контейнере Users. Для того чтобы указать пароль, используется параметр –AccountPassword со значением (Read-Host -AsSecureString "Пароль для вашей учетной записи"). Также стоит обязательно обратить внимание на то, что значением параметра –Country выступает именно код страны или региона выбранного пользователем языка. Синтаксис командлета следующий:
New-ADUser [-Name]
Как видно из данного синтаксиса, нет смысла описывать все параметры, так как они идентичны атрибутам принципала безопасности и не нуждаются в объяснениях. Посмотрим на пример использования:
New-ADUser -SamAccountName "Evgeniy.Romanov" -Name "Евгений Романов" -GivenName "Евгений" -Surname "Романов" -DisplayName "Евгений Романов" -Path "OU=Маркетинг,OU=Пользователи,DC=testdomain,DC=com" -CannotChangePassword $false -ChangePasswordAtLogon $true -City "Херсон" -State "Херсон" -Country UA -Department "Маркетинг" -Title "Маркетолог" -UserPrincipalName "[email protected]" -EmailAddress "[email protected]" -Enabled $true -AccountPassword (Read-Host -AsSecureString "AccountPassword")
Рис. 10. Создание учетной записи пользователя средствами Windows PowerShell
Заключение
В этой статье вы узнали о понятии принципал безопасности и о том, какую роль представляют учетные записи пользователей в доменной среде. Были подробно рассмотрены основные сценарии создания пользовательских учетных записей в домене Active Directory. Вы научились создавать пользовательские учетные записи при помощи оснастки «Active Directory – пользователи и компьютеры» , используя шаблоны, утилиты командной строки Dsadd, CSVDE и LDIFDE. Также вы узнали о методе создания пользовательских учетных записей при помощи языка сценариев VBScript и оболочки командной строки Windows PowerShell.
Аннотация: Данная лекция описывает основные понятия служб каталогов Active Directory. Даются практические примеры управления системой безопасности сети. Описан механизм групповых политик. Дается представление о задачах сетевого администратора при управлении инфраструктурой службы каталогов
Современные сети часто состоят из множества различных программных платформ, большого разнообразия оборудования и программного обеспечения. Пользователи зачастую вынуждены запоминать большое количество паролей для доступа к различным сетевым ресурсам. Права доступа могут быть различными для одного и того же сотрудника в зависимости от того, с какими ресурсами он работает. Все это множество взаимосвязей требует от администратора и пользователя огромного количества времени на анализ , запоминание и обучение.
Решение проблемы управления такой разнородной сетью было найдено с разработкой службы каталога. Службы каталога предоставляют возможности управления любыми ресурсами и сервисами из любой точки независимо от размеров сети, используемых операционных систем и сложности оборудования. Информация о пользователе, заносится единожды в службу каталога, и после этого становится доступной в пределах всей сети. Адреса электронной почты, принадлежность к группам, необходимые права доступа и учетные записи для работы с различными операционными системами - все это создается и поддерживается в актуальном виде автоматически. Любые изменения, занесенные в службу каталога администратором, сразу обновляются по всей сети. Администраторам уже не нужно беспокоиться об уволенных сотрудниках - просто удалив учетную запись пользователя из службы каталога, он сможет гарантировать автоматическое удаление всех прав доступа на ресурсы сети, предоставленные ранее этому сотруднику.
В настоящее время большинство служб каталогов различных фирм базируются на стандарте X.500 . Для доступа к информации, хранящейся в службах каталогов, обычно используется протокол (LDAP ). В связи со стремительным развитием сетей TCP/IP , протокол LDAP становится стандартом для служб каталогов и приложений, ориентированных на использование службы каталога.
Служба каталогов Active Directory является основой логической структуры корпоративных сетей, базирующихся на системе Windows . Термин " Каталог " в самом широком смысле означает " Справочник ", а служба каталогов корпоративной сети - это централизованный корпоративный справочник. Корпоративный каталог может содержать информацию об объектах различных типов. Служба каталогов Active Directory содержит в первую очередь объекты, на которых базируется система безопасности сетей Windows , - учетные записи пользователей, групп и компьютеров. Учетные записи организованы в логические структуры: домен, дерево , лес , организационные подразделения .
С точки зрения изучения материала курса "Сетевое администрирование " вполне возможен следующий вариант прохождения учебного материала: сначала изучить первую часть данного раздела (от основных понятий до установки контроллеров домена), затем перейти к "Служба файлов и печати" , а после изучения "Служба файлов и печати" вернуться к "Служба каталогов Active Directory" для изучения более сложных понятий служб каталогов.
6.1 Основные термины и понятия (лес, дерево, домен, организационное подразделение). Планирование пространства имен AD. Установка контроллеров доменов
Модели управления безопасностью: модель "Рабочая группа" и централизованная доменная модель
Как уже говорилось выше, основное назначение служб каталогов - управление сетевой безопасностью. Основа сетевой безопасности - база данных учетных записей (accounts) пользователей, групп пользователей и компьютеров, с помощью которой осуществляется управление доступом к сетевым ресурсам. Прежде чем говорить о службе каталогов Active Directory, сравним две модели построения базы данных служб каталогов и управления доступом к ресурсам.
Модель "Рабочая группа"
Данная модель управления безопасностью корпоративной сети - самая примитивная. Она предназначена для использования в небольших одноранговых сетях (3–10 компьютеров) и основана на том, что каждый компьютер в сети с операционными системами Windows NT/2000/XP/2003 имеет свою собственную локальную базу данных учетных записей и с помощью этой локальной БД осуществляется управление доступом к ресурсам данного компьютера. Локальная БД учетных записей называется база данных SAM (Security Account Manager ) и хранится в реестре операционной системы. Базы данных отдельных компьютеров полностью изолированы друг от друга и никак не связаны между собой.
Пример управления доступом при использовании такой модели изображен на рис. 6.1 .
Рис.
6.1.
В данном примере изображены два сервера (SRV-1 и SRV-2) и две рабочие станции (WS-1 и WS-2). Их базы данных SAM обозначены соответственно SAM-1, SAM-2, SAM-3 и SAM-4 (на рисунке базы SAM изображены в виде овала). В каждой БД есть учетные записи пользователей User1 и User2. Полное имя пользователя User1 на сервере SRV-1 будет выглядеть как "SRV-1\User1", а полное имя пользователя User1 на рабочей станции WS-1 будет выглядеть как "WS-1\User1". Представим, что на сервере SRV-1 создана папка Folder, к которой предоставлен доступ по сети пользователям User1 - на чтение (R), User2 - чтение и запись (RW). Главный момент в этой модели заключается в том, что компьютер SRV-1 ничего "не знает" об учетных записях компьютеров SRV-2, WS-1, WS-2, а также всех остальных компьютеров сети. Если пользователь с именем User1локально зарегистрируется в системе на компьютере, например, WS-2 (или, как еще говорят, "войдет в систему с локальным именем User1 на компьютере WS-2"), то при попытке получить доступ с этого компьютера по сети к папке Folder на сервере SRV-1 сервер запросит пользователя ввести имя и пароль (исключение составляет тот случай, если у пользователей с одинаковыми именами одинаковые пароли).
Модель "Рабочая группа" более проста для изучения, здесь нет необходимости изучать сложные понятия Active Directory. Но при использовании в сети с большим количеством компьютеров и сетевых ресурсов становится очень сложным управлять именами пользователей и их паролями - приходится на каждом компьютере (который предоставляет свои ресурсы для совместного использования в сети) вручную создавать одни и те же учетные записи с одинаковыми паролями, что очень трудоемко, либо делать одну учетную запись на всех пользователей с одним на всех паролем (или вообще без пароля), что сильно снижает уровень защиты информации. Поэтому модель "Рабочая группа" рекомендуется только для сетей с числом компьютеров от 3 до 10 (а еще лучше - не более 5), при условии что среди всех компьютеров нет ни одного с системой Windows Server.
Доменная модель
В доменной модели существует единая база данных служб каталогов, доступная всем компьютерам сети. Для этого в сети устанавливаются специализированные серверы, называемые контроллерами домена , которые хранят на своих жестких дисках эту базу. На рис. 6.2 . изображена схема доменной модели. Серверы DC-1 и DC-2 - контроллеры домена, они хранят доменную базу данных учетных записей (каждый контроллер хранит у себя свою собственную копию БД, но все изменения, производимые в БД на одном из серверов, реплицируются на остальные контроллеры).
Рис. 6.2.
В такой модели, если, например, на сервере SRV-1, являющемся членом домена, предоставлен общий доступ к папке Folder, то права доступа к данному ресурсу можно назначать не только для учетных записей локальной базы SAM данного сервера, но, самое главное, учетным записям, хранящимся в доменной БД. На рисунке для доступа к папке Folder даны права доступа одной локальной учетной записи компьютера SRV-1 и нескольким учетным записям домена (пользователя и группам пользователей). В доменной модели управления безопасностью пользователь регистрируется на компьютере ("входит в систему") со своей доменной учетной записью и, независимо от компьютера, на котором была выполнена регистрация, получает доступ к необходимым сетевым ресурсам. И нет необходимости на каждом компьютере создавать большое количество локальных учетных записей, все записи созданы однократно в доменной БД . И с помощью доменной базы данных осуществляется централизованное управление доступом к сетевым ресурсам независимо от количества компьютеров в сети .
Назначение службы каталогов Active Directory
Каталог (справочник) может хранить различную информацию, относящуюся к пользователям, группам, компьютерам, сетевым принтерам, общим файловым ресурсам и так далее - будем называть все это объектами. Каталог хранит также информацию о самом объекте, или его свойства, называемые атрибутами. Например, атрибутами, хранимыми в каталоге о пользователе, может быть имя его руководителя, номер телефона, адрес , имя для входа в систему, пароль, группы , в которые он входит, и многое другое. Для того чтобы сделать хранилище каталога полезным для пользователей, должны существовать службы, которые будут взаимодействовать с каталогом. Например, можно использовать каталог как хранилище информации, по которой можно аутентифицировать пользователя, или как место , куда можно послать запрос для того, чтобы найти информацию об объекте.
Active Directory отвечает не только за создание и организацию этих небольших объектов, но также и за большие объекты, такие как домены, OU (организационные подразделения ) и сайты.
Об основных терминах, используемых в контексте службы каталогов Active Directory , читайте ниже.
Служба каталогов Active Directory (сокращенно - AD ) обеспечивает эффективную работу сложной корпоративной среды, предоставляя следующие возможности:
- Единая регистрация в сети ; Пользователи могут регистрироваться в сети с одним именем и паролем и получать при этом доступ ко всем сетевым ресурсам и службам (службы сетевой инфраструктуры, службы файлов и печати, серверы приложений и баз данных и т. д.);
- Безопасность информации . Средства аутентификации и управления доступом к ресурсам, встроенные в службу Active Directory, обеспечивают централизованную защиту сети;
- Централизованное управление . Администраторы могут централизованно управлять всеми корпоративными ресурсами;
- Администрирование с использованием групповых политик . При загрузке компьютера или регистрации пользователя в системе выполняются требования групповых политик; их настройки хранятся в объектах групповых политик ( GPO ) и применяются ко всем учетным записям пользователей и компьютеров, расположенных в сайтах, доменах или организационных подразделениях;
- Интеграция с DNS . Функционирование служб каталогов полностью зависит от работы службы DNS. В свою очередь серверы DNS могут хранить информацию о зонах в базе данных Active Directory;
- Расширяемость каталога . Администраторы могут добавлять в схему каталога новые классы объектов или добавлять новые атрибуты к существующим классам;
- Масштабируемость . Служба Active Directory может охватывать как один домен, так и множество доменов, объединенных в дерево доменов, а из нескольких деревьев доменов может быть построен лес;
- Репликация информации . В службе Active Directory используется репликация служебной информации в схеме со многими ведущими (multi-master ), что позволяет модифицировать БД Active Directory на любом контроллере домена. Наличие в домене нескольких контроллеров обеспечивает отказоустойчивость и возможность распределения сетевой нагрузки;
- Гибкость запросов к каталогу . БД Active Directory может использоваться для быстрого поиска любого объекта AD, используя его свойства (например, имя пользователя или адрес его электронной почты, тип принтера или его местоположение и т. п.);
- Стандартные интерфейсы программирования . Для разработчиков программного обеспечения служба каталогов предоставляет доступ ко всем возможностям (средствам) каталога и поддерживает принятые стандарты и интерфейсы программирования (API).
В Active Directory может быть создан широкий круг различных объектов. Объект представляет собой уникальную сущность внутри Каталога и обычно обладает многими атрибутами, которые помогают описывать и распознавать его. Учетная запись пользователя является примером объекта. Этот тип объекта может иметь множество атрибутов, таких как имя, фамилия, пароль , номер телефона, адрес и многие другие. Таким же образом общий принтер тоже может быть объектом в Active Directory и его атрибутами являются его имя, местоположение и т.д. Атрибуты объекта не только помогают определить объект , но также позволяют вам искать объекты внутри Каталога.
Терминология
Служба каталогов системы Windows Server построена на общепринятых технологических стандартах. Изначально для служб каталогов был разработан стандарт X.500 , который предназначался для построения иерархических древовидных масштабируемых справочников с возможностью расширения как классов объектов, так и наборов атрибутов (свойств) каждого отдельного класса. Однако практическая реализация этого стандарта оказалась неэффективной с точки зрения производительности. Тогда на базе стандарта X.500 была разработана упрощенная (облегченная) версия стандарта построения каталогов, получившая название LDAP (Lightweight Directory Access Protocol ). Протокол LDAP сохраняет все основные свойства X.500 (иерархическая система построения справочника, масштабируемость , расширяемость ), но при этом позволяет достаточно эффективно реализовать данный стандарт на практике. Термин " lightweight " (" облегченный ") в названии LDAP отражает основную цель разработки протокола: создать инструментарий для построения службы каталогов, которая обладает достаточной функциональной мощью для решения базовых задач, но не перегружена сложными технологиями, делающими реализацию служб каталогов неэффективной. В настоящее время LDAP является стандартным методом доступа к информации сетевых каталогов и играет роль фундамента во множестве продуктов, таких как системы аутентификации , почтовые программы и приложения электронной коммерции. Сегодня на рынке присутствует более 60 коммерческих серверов LDAP , причем около 90% из них представляют собой самостоятельные серверы каталогов LDAP , а остальные предлагаются в качестве компонентов других приложений.
Протокол LDAP четко определяет круг операций над каталогами, которые может выполнять клиентское приложение . Эти операции распадаются на пять групп:
- установление связи с каталогом;
- поиск в нем информации;
- модификация его содержимого;
- добавление объекта;
- удаление объекта.
Кроме протокола LDAP служба каталогов Active Directory использует также протокол аутентификации Kerberos и службу DNS для поиска в сети компонент служб каталогов (контроллеры доменов, серверы глобального каталога , службу Kerberos и др.).
Домен
Основной единицей системы безопасности Active Directory является домен . Домен формирует область административной ответственности. База данных домена содержит учетные записи пользователей , групп и компьютеров . Большая часть функций по управлению службой каталогов работает на уровне домена (аутентификация пользователей, управление доступом к ресурсам, управление службами, управление репликацией, политики безопасности).
Имена доменов Active Directory формируются по той же схеме, что и имена в пространстве имен DNS. И это не случайно. Служба DNS является средством поиска компонент домена - в первую очередь контроллеров домена.
Контроллеры домена - специальные серверы, которые хранят соответствующую данному домену часть базы данных Active Directory. Основные функции контроллеров домена:
- хранение БД Active Directory (организация доступа к информации, содержащейся в каталоге, включая управление этой информацией и ее модификацию);
- синхронизация изменений в AD (изменения в базу данных AD могут быть внесены на любом из контроллеров домена, любые изменения, осуществляемые на одном из контроллеров, будут синхронизированы c копиями, хранящимися на других контроллерах);
- аутентификация пользователей (любой из контроллеров домена осуществляет проверку полномочий пользователей, регистрирующихся на клиентских системах).
Настоятельно рекомендуется в каждом домене устанавливать не менее двух контроллеров домена - во-первых, для защиты от потери БД Active Directory в случае выхода из строя какого-либо контроллера, во-вторых, для распределения нагрузки между контроллерами.it.company.ru есть поддомен dev.it.company.ru , созданный для отдела разработчиков ПО ИТ-службы.
- для децентрализации администрирования служб каталогов (например, в случае, когда компания имеет филиалы, географически удаленные друг от друга, и централизованное управление затруднено по техническим причинам);
- для повышения производительности (для компаний с большим количеством пользователей и серверов актуален вопрос повышения производительности работы контроллеров домена);
- для более эффективного управления репликацией (если контроллеры доменов удалены друг от друга, то репликация в одном может потребовать больше времени и создавать проблемы с использованием несинхронизированных данных); корневым доменом леса (forest root domain ), данный домен не может быть удален (он хранит информацию о конфигурации леса и деревьях доменов, его образующих).
Организационные подразделения (ОП).
Организационные подразделения (Organizational Units , OU ) - контейнеры внутри AD, которые создаются для объединения объектов в целях делегирования административных прав и применения групповых политик в домене. ОП существуют только внутри доменов и могут объединять только объекты из своего домена . ОП могут быть вложенными друг в друга, что позволяет строить внутри домена сложную древовидную иерархию из контейнеров и осуществлять более гибкий административный контроль. Кроме того, ОП могут создаваться для отражения административной иерархии и организационной структуры компании.
Глобальный каталог
Глобальный каталог является перечнем всех объектов , которые существуют в лесу Active Directory. По умолчанию, контроллеры домена содержат только информацию об объектах своего домена. Сервер Глобального каталога является контроллером домена, в котором содержится информация о каждом объекте (хотя и не обо всех атрибутах этих объектов), находящемся в данном лесу.
Технология Active Directory (AD) является службой каталогов, созданной компанией Microsoft. Служба каталогов содержит данные в организованном формате и предоставляет к ним упорядоченный доступ. Служба Active Directory - это не изобретение компании Microsoft, а реализация существующей индустриальной модели (а именно X.500), коммуникационного протокола (LDAP - Lightweight Directory Access Protocol) и технологии поиска данных (службы DNS).
Изучение Active Directory следует начать со знакомства с целью, поставленной перед этой технологией. В общем плане, каталогом считается контейнер хранения данных.
Телефонный справочник является наглядным примером службы каталогов, поскольку содержит набор данных и предоставляет возможность получения необходимых сведений из каталога. Справочник содержит различные записи, каждая из которых имеет собственное значение, например, имена/фамилии абонентов, их домашний адрес и, собственно, номер телефона. В расширенном справочнике записи группируются по географическому расположению, типу или обоим признакам. Таким образом, для каждого географического расположения может быть сформирована иерархия типов записей. Кроме того, телефонный оператор также подходит под определение службы каталогов, поскольку имеет доступ к данным. Следовательно, если дать запрос на получение каких-либо данных каталога, оператор выдаст требуемый ответ на полученный запрос.
Служба каталогов Active Directory предназначена для хранения информации о всех сетевых ресурсах. Клиенты имеют возможность отправлять запросы Active Directory для получения информации о любом объекте сети. В список возможностей Active Directory входят следующие функции.
- Безопасное хранилище данных. Каждый объект в Active Directory имеет собственный список управления доступом (ACL), который содержит список ресурсов, получивших право доступа к объекту, а также предопределенный уровень доступа к этому объекту.
- Многофункциональный механизм запросов, основанный на созданном Active Directory глобальном каталоге (GC). Все клиенты, поддерживающие Active Directory, могут обращаться к этому каталогу.
- Репликация данных каталога на все контроллеры домена упрощает доступ к информации, повышает степень ее доступности и увеличивает надежность всей службы.
- Концепция модульного расширения, которая позволяет добавлять новые типы объектов или дополнять существующие объекты. Например, к объекту “пользователь” можно добавить атрибут “зарплата”.
- Сетевое взаимодействие с использованием нескольких протоколов. Служба Active Directory основана на модели X.500, благодаря чему поддерживаются различные сетевые протоколы, например, LDAP 2, LDAP 3 и HTTP.
- Для реализации службы имен контроллеров доменов и поиска сетевых адресов вместо NetBIOS используется служба DNS.
Информация каталога распределяется по всему домену, тем самым позволяя избежать чрезмерного дублирования данных.
Хотя Active Directory распределяет информацию каталога по различным хранилищам, пользователи имеют возможность запросить Active Directory на получение информации о других доменах. Глобальный каталог содержит сведения о всех объектах леса предприятия, помогая осуществлять поиск данных в рамках всего леса.
При запуске утилиты DCPROMO (программы повышения обычного сервера до контроллера домена) на компьютере под управлением Windows для создания нового домена, утилита создает домен на сервере DNS. Затем клиент связывается с сервером DNS для получения информации о своем домене. Сервер DNS предоставляет информацию не только о домене, но и о ближайшем контроллере домена. Клиентская система, в свою очередь, подключается к базе данных домена Active Directory на ближайшем контроллере домена с целью нахождения необходимых объектов (принтеров, файловых серверов, пользователей, групп, организационных подразделений), входящих в домен. Поскольку каждый контроллер домена хранит ссылки на другие домены в дереве, клиент может выполнять поиск во всем дереве домена.
Разновидность Active Directory, которая перечисляет все объекты в лесу доменов, доступна для тех случаев, когда необходимо найти данные за пределами дерева доменов клиента. Подобная версия называется глобальный каталог. Глобальный каталог можно хранить на любом контроллере домена в лесу AD.
Глобальный каталог предоставляет быстрый доступ к каждому объекту, который располагаться в лесу доменов, но при этом содержит только некоторые параметры объектов. Для получения всех атрибутов следует обратиться к службе Active Directory целевого домена (контроллеру интересующего домена). Глобальный каталог можно настроить на предоставление необходимых свойств объектов.
Для упрощения процесса создания объектов Active Directory контроллер домена содержит копию и иерархию классов для всего леса. Служба Active Directory содержит структуры классов в расширяемой схеме, в которую можно добавить новые классы.
Схема (schema) - это часть конфигурационного пространства имен Windows, которое поддерживается всеми контроллерами доменов в лесу. Конфигурационное пространство имен Windows состоит из нескольких структурных элементов, таких как физическое расположение, сайты Windows и подсети.
Сайт (site) содержится внутри леса и может объединять компьютеры из любого домена, причем все компьютеры сайта должны иметь быстрые и надежные сетевые соединения для резервирования данных контроллера домена.
Подсеть (subnet) - это группа IP-адресов, выделенная сайту. Подсети позволяют ускорить репликацию данных Active Directory между контроллерами доменов.
Домен – это основная административная единица в сетевой инфраструктуре предприятия, в которую входят все сетевые объекты, такие как пользователи, компьютеры, принтеры, общие ресурсы и т.д. Совокупность (иерархия) доменов называется лесом. У каждой компании может быть внешний и внутренний домен.
Например сайт – внешний домен в сети Интернет, который был приобретён у регистратора имён. В данном домене размещён наш WEB-сайт и почтовый сервер. lankey.local –внутренний домен службы каталогов Active Directory, в котором размещаются учётные записи пользователей, компьютеров, принтеров, серверов и корпоративных приложений. Иногда внешние и внутренние доменные имена делают одинаковыми.
Microsoft Active Directory стала стандартом систем единого каталога предприятия. Домен на базе Active Directory внедрён практически во всех компаниях мира, и на этом рынке у Microsoft практически не осталось конкурентов, доля того же Novell Directory Service (NDS) пренебрежимо мала, да и оставшиеся компании постепенно мигрируют на Active Directory.
Active Directory (Служба каталогов) представляет собой распределённую базу данных, которая содержит все объекты домена. Доменная среда Active Directory является единой точкой аутентификации и авторизации пользователей и приложений в масштабах предприятия. Именно с организации домена и развёртывания Active Directory начинается построение ИТ-инфраструктуры предприятия. База данных Active Directory хранится на выделенных серверах – контроллерах домена. Служба Active Directory является ролью серверных операционных систем Microsoft Windows Server. В данный момент компания ЛанКей производит внедрение доменов Active Directory на базе операционной системы Windows Server 2008 R2.
Развёртывание службы каталогов Active Directory по сравнению с рабочей группой (Workgroup) даёт следующие преимущества:
- Единая точка аутентификации. Когда компьютеры работают в рабочей группе, у них нет единой базы данных пользователей, у каждого компьютера она своя. Поэтому по умолчанию ни один из пользователей не имеет доступа по сети к компьютеру другого пользователя или серверу. А, как известно, смысл сети, как раз в том, чтобы пользователи могли взаимодействовать. Сотрудникам требуется совместный доступ к документам или приложениям. В рабочей группе на каждом компьютере или сервере придётся вручную добавлять полный список пользователей, которым требуется сетевой доступ. Если вдруг, один из сотрудников захочет сменить свой пароль, то его нужно будет поменять на всех компьютерах и серверах. Хорошо, если сеть состоит из 10 компьютеров, но если их 100 или 1000, то использование рабочей группы будет неприемлемым. При использовании домена Active Directory все учётные записи пользователей хранятся в одной базе данных, и все компьютеры обращаются к ней за авторизацией. Все пользователи домена включаются в соответствующие группы, например, «Бухгалтерия», «Кадры», «Финансовый отдел» и т.д. Достаточно один раз задать разрешения для тех или иных групп, и все пользователи получат соответствующий доступ к документам и приложениям. Если в компанию приходит новый сотрудник, для него создаётся учётная запись, которая включается в соответствующую группу, и всё! Через пару минут новый сотрудник получает доступ ко всем ресурсам сети, к которым ему должен быть разрешён доступ, на всех серверах и компьютерах. Если сотрудник увольняется, то достаточно заблокировать или удалить его учётную запись, и он сразу потеряет доступ ко всем компьютерам, документам и приложениям.
- Единая точка управления политиками. В одноранговой сети (рабочей группе) все компьютеры равноправны. Ни один из компьютеров не может управлять другим, все компьютеры настроены по-разному, невозможно проконтролировать ни соблюдение единых политик, ни правил безопасности. При использовании единого каталога Active Directory, все пользователи и компьютеры иерархически распределяются по организационным подразделениям, к каждому из которых применяются единые групповые политики. Политики позволяют задать единые настройки и параметры безопасности для группы компьютеров и пользователей. При добавлении в домен нового компьютера или пользователя, он автоматически получает настройки, соответствующие принятым корпоративным стандартам. Также при помощи политик можно централизованно назначить пользователям сетевые принтеры, установить необходимые приложения, задать параметры безопасности Интернет-браузера, настроить приложения Microsoft Office и т.д.
- Интеграции с корпоративными приложениями и оборудованием. Большим преимуществом Active Directory является соответствие стандарту LDAP, который поддерживается сотнями приложений, такими как почтовые сервера (Exchange, Lotus, Mdaemon), ERP-системы (Dynamics, CRM), прокси-серверы (ISA Server, Squid) и др. Причем это не только приложения под Microsoft Windows, но и серверы на базе Linux. Преимущества такой интеграции заключается в том, что пользователю не требуется помнить большое количество логинов и паролей для доступа к тому или иному приложению, во всех приложениях пользователь имеет одни и те же учётные данные, т.к. его аутентификация происходит в едином каталоге Active Directory. Кроме того, сотруднику не требуется по нескольку раз вводить свой логин и пароль, достаточно при запуске компьютера один раз войти в систему, и в дальнейшем пользователь будет автоматически аутентифицироваться во всех приложениях. Windows Server для интеграции с Active Directory предоставляет протокол RADIUS, который поддерживается большим количеством сетевого оборудования. Таким образом, можно, например, обеспечить аутентификацию доменных пользователей при подключении к маршрутизатору CISCO по VPN.
- Единое хранилище конфигурации приложений. Некоторые приложения хранят свою конфигурацию в Active Directory, например Exchange Server или Office Communications Server. Развёртывание службы каталогов Active Directory является обязательным условием для работы этих приложений. Также в службе каталогов можно хранить конфигурацию сервера доменных имён DNS. Хранение конфигурации приложений в службе каталогов является выгодным с точки зрения гибкости и надёжности. Например, в случае полного отказа сервера Exchange, вся его конфигурация останется нетронутой, т.к. хранится в Active Directory. И для восстановления работоспособности корпоративной почты, достаточно будет переустановить Exchange сервер в режиме восстановления.
- Повышенный уровень информационной безопасности. Использование Active Directory значительно повышает уровень безопасности сети. Во-первых – это единое и защищённое хранилище учётных записей. В одноранговой сети учётные данные пользователей хранятся в локальной базе данных учётных записей (SAM), которую теоретически можно взломать, завладев компьютером. В доменной среде все пароли доменных пользователях хранятся на выделенных серверах контроллерах домена, которые, как правило, защищены от внешнего доступа. Во-вторых при использовании доменной среды для аутентификации используется протокол Kerberos, который значительно безопаснее, чем NTLM, использующийся в рабочих группах. Кроме того, для входа пользователей в систему можно использовать двухфакторную аутентификацию при помощи смарт-карт. Т.е. чтобы сотрудник получил доступ к компьютеру, ему потребуется ввести свой логин и пароль, а также вставить свою смарт-карту.
Масштабируемость и отказоустойчивость службы каталогов Active Directory
Служба каталогов Microsoft Active Directory имеет широкие возможности масштабирования. В лесе Active Directory может быть создано более 2-х миллиардов объектов, что позволяет внедрять службу каталогов в компаниях с сотнями тысяч компьютеров и пользователей. Иерархическая структура доменов позволяет гибко масштабировать ИТ-инфраструктуру на все филиалы и региональные подразделения компаний. Для каждого филиала или подразделения компании может быть создан отдельный домен, со своими политиками, своими пользователями и группами. Для каждого дочернего домена могут быть делегированы административные полномочия местным системным администраторам. При этом всё равно дочерние домены подчиняются родительским.
Кроме того, Active Directory позволяет настроить доверительные отношения между доменными лесами. Каждая компания имеет собственный лес доменов, каждый из которых имеет собственные ресурсы. Но иногда бывает нужно предоставить доступ к своим корпоративным ресурсам сотрудникам из компаний-партнёров. Например, при участии в совместных проектах сотрудникам из компаний партнёром может совместно понадобиться работать с общими документами или приложениями. Для этого между лесами организаций можно настроить доверительные отношения, что позволит сотрудникам из одной организации авторизоваться в домене другой.
Отказоустойчивость службы каталогов обеспечивается путём развёртывания 2-х и более серверов - контроллеров домена в каждом домене. Между контроллерами домена обеспечивается автоматическая репликация всех изменений. В случае выхода из строя одного из контроллеров домена, работоспособность сети не нарушается, т.к. продолжают работать оставшиеся. Дополнительный уровень отказоустойчивости обеспечивает размещение серверов DNS на контроллерах домена в Active Directory, что позволяет в каждом домене получить несколько серверов DNS, обслуживающих основную зону домена. И в случае отказа одного из DNS серверов, продолжат работать оставшиеся, причём они будут доступны, как на чтение, так и на запись, что нельзя обеспечить, используя, например, DNS сервера BIND на базе Linux.
Преимущества перехода на Windows Server 2008 R2
Даже если в вашей компании уже развёрнута служба каталогов Active Directory на базе Windows Server 2003, то вы можете получить целый ряд преимуществ, перейдя на Windows Server 2008 R2. Windows Server 2008 R2 предоставляет следующие дополнительные возможности:
Контроллер домена только для чтения RODC (Read-only Domain Controller). Контроллеры домена хранят учётные записи пользователей, сертификаты и много другой конфиденциальной информации. Если серверы расположены в защищённых ЦОД-ах, то о сохранности данной информации можно быть спокойным, но что делать, если котроллер домена стоит в филиале в общедоступном месте. В данном случае существует вероятность, что сервер украдут злоумышленники и взломают его. А затем используют эти данные для организации атаки на вашу корпоративную сеть, с целью кражи или уничтожения информации. Именно для предотвращения таких случаев в филиалах устанавливают контролеры домена только для чтения (RODC). Во-первых RODC-контроллеры не хранят пароли пользователей, а лишь кэшируют их для ускорения доступа, а во-вторых они используют одностороннюю репликацию, только из центральных серверов в филиал, но не обратно. И даже, если злоумышленники завладеют RODC контроллером домена, то они не получат пароли пользователей и не смогут нанести ущерб основной сети.
Восстановление удалённых объектов Active Directory. Почти каждый системный администратор сталкивался с необходимостью восстановить случайно удалённую учётную запись пользователя или целой группы пользователей. В Windows 2003 для этого требовалось восстанавливать службу каталогов из резервной копии, которой зачастую не было, но даже если она и была, то восстановление занимало достаточно много времени. В Windows Server 2008 R2 появилась корзина Active Directory. Теперь при удалении пользователя или компьютера, он попадает в корзину, из которой он может быть восстановлен за пару минут в течение 180 дней с сохранением всех первоначальных атрибутов.
Упрощённое управление. В Windows Server 2008 R2 были внесены ряд изменений, значительно сокращающих нагрузку на системных администраторов и облегчающих управление ИТ-инфраструктурой. Например появились такие средства, как: Аудит изменений Active Directory, показывающий, кто, что и когда менял; политики сложности паролей настраеваемые на уровне групп пользователей, ранее это было возможно сделать только на уровне домена; новые средства управления пользователями и компьютерами; шаблоны политик; управление при помощи командной строки PowerShell и т.д.
Внедрение службы каталогов Active Directory
Служба каталогов Active Directory – является сердцем ИТ-инфраструктуры предприятия. В случае её отказа вся сеть, все сервера, работа всех пользователей будут парализованы. Никто не сможет войти в компьютер, получить доступ к своим документам и приложениям. Поэтому служба каталогов должна быть тщательно спроектирована и развёрнута, с учётом всех возможных нюансов. Например, структура сайтов должна строиться на основе физической топологии сети и пропускной способности каналов между филиалами или офисами компании, т.к. от этого напрямую зависит скорость входа пользователей в систему, а также репликация между контроллерами домена. Кроме того, на основании топологии сайтов Exchange Server 2007/2010 осуществляет маршрутизацию почты. Также нужно правильно рассчитать количество и размещение серверов глобального каталога, которые хранят списки универсальных групп, и множество других часто используемых атрибутов всех доменов леса. Именно поэтому компании возлагают задачи по внедрению, реорганизации или миграции службы каталогов Active Directory на системных интеграторов. Тем не менее, нужно не ошибиться при выборе системного интегратора, следует убедиться, что он сертифицирован на выполнение данного вида работ и имеет соответствующие компетенции.
Компания ЛанКей является сертифицированным системным интегратором и обладает статусом Microsoft Gold Certified Partner. ЛанКей имеет компетенцию Datacenter Platform (Advanced Infrastructure Solutions), что подтверждает наш опыт и квалификацию в вопросах связанных с развёртыванием Active Directory и внедрением серверных решений компании Microsoft.
Все работы в проектах выполняют сертифицированные Microsoft инженеры MCSE, MCITP, которые имеют богатый опыт участия в крупных и сложных проектах по построению ИТ-инфраструктур и внедрению доменов Active Directory.
Компания ЛанКей разработает ИТ-инфраструктуру, развернёт службу каталогов Active Directory и обеспечит консолидацию всех имеющихся ресурсов предприятия в единое информационное пространство. Внедрение Active Directory поможет снизить совокупную стоимость владения информационной системой, а также повысить эффективность совместного использования общих ресурсов. ЛанКей также оказывает услуги по миграции доменов, объединению и разделению ИТ-инфраструктур при слияних и поглощениях, обслуживанию и поддержке информационных систем.
Примеры некоторых проектов по внедрению Active Directory, реализованных компанией ЛанКей:
| Заказчик | Описание решения |
|
В связи с совершением сделки по покупке 100% акций компании ОАО «СИБУР-Минудобрения» (впоследствии переименован в ОАО "СДС-Азот") Холдинговой компаний "Сибирский деловой союз" в декабре 2011 года, возникла необходимость в отделении ИТ-инфраструктуры ОАО «СДС-Азот» от сети Холдинга СИБУР. Комания ЛанКей произвела миграцию службы каталогов Active Directory подразделения СИБУР-Минудобрения из сети холдинга СИБУР в новую инфраструктуру. Также были перенсены учётные записи пользователей, компьютеры и приложения. По результатам проекта от заказчика получено благодарственное письмо . |
|
| В связи с реструктуризацией бизнеса, было выполнено развёртывание службы каталогов Active Directory для центрального офиса и 50 московских и региональных магазинов. Служба каталогов обеспечила централизованное уравление всеми ресурсами предприятия, а также аутентификацию и авторизацию всех пользователей. | |
| В рамках комплексного проекта по созданию ИТ-инфраструктуры предприятия, компания ЛанКей выполнила развёртывание домена Active Directory для управляющей компании и 3-х региональных подразделений. Для каждого филиала был создан отдельный сайт, в каждом сайте было развёрнуто по 2 контроллера домена. Также были развёрнуты службы сертификации. Все сервисы были развёртнуты на виртуальных машинах под управлением Microsoft Hyper-V. Качество работы компании ЛанКей было отмечено отзывом . | |
| В рамках комплексного проекта по созданию корпоративной информационной системы, было произведено развёртывание службы каталогов Active Directory на базе Windows Server 2008 R2. Система была развёрнута с использованием технологиии виртуализации серверов под управлением Microsoft Hyper-V. Служба каталогов обеспечила единую аутентификацию и авторизацию всех сотрудников больницы, а тажке обеспечила функционирование таких приложений, как Exchange, TMG, SQL и др. | |
|
|
Выполнено развёртывание службы каталогов Active Directory на базе Windows Server 2008 R2. С целью сокращения затрат инсталляция произведена в системе виртуализации серверов на базе Microsoft Hyper-V. |
| В рамках комплексного проекта по созданию ИТ-инфраструктуры предприятия была развёрнута служба каталогов на базе Windows Server 2008 R2. Все контроллеры домена были развёрнуты с использованием системы виртуализации серверов Microsoft Hyper-V. Качество работы подтверждено полученным от заказчика отзывом . | |
|
|
В кратчайшие сроки восстановлена работоспособность службы каталогов Active Directory в критической для бизнеса ситуации. Специалисты "ЛанКей" буквально за пару часов восстановили работоспособность корневого домена и написали инструкцию по восстановлению репликации 80 филиальных подразделений. За оперативность и качество работы от заказчика был получен отзыв . |
| В рамках комплексного проекта по созданию ИТ-инфраструктуры был развёрнут домен Active Directory на базе Windows Server 2008 R2. Работоспособность службы каталогов была обеспечена при помощи 5 контроллеров домена, развёрнутых на кластере виртуальных машин. Резервное копирование службы каталогов было реализовано при помощи Microsoft Data Protection Manager 2010. Качество работы подтверждено отзывом . | |
|
В рамках комплексного проекта по построению корпоративной информационной системы выполнено развёртывание службы единого каталога Active Directory на базе Windows Server 2008. ИТ-инфраструктура была построена с применением виртуализации Hyper-V. После завершения проекта был заключен договор на дальнейшее обслуживание информационной системы. Качесто работы подтверждено отзывом . |
|
| Нефтегазовые технологии | В рамках комплексного проекта по созданию ИТ-инфраструктуры, выполнено развёртывание единого каталога Active Directory на базе Windows Server 2008 R2. Проект был выполнен за 1 месяц. После завершения проекта, был заключен договор на дальнейшее обслуживание системы. Качество работы подтверждено отзывом . |
| Выполнено развёртывание Active Directory на базе Windows Server 2008 в рамках проекта по внедрению Exchange Server 2007. | |
| Произведена реорганизация службы каталогов Active Directory на базе Windows Server 2003 перед внедрением Exchange Server 2007. Качество работы подтверждено отзывом . | |
| Произведено развёртывание службы каталогов Active Directory на базе Windows Server 2003 R2. После завершения проекта был заключен договор на дальнейшее обслуживание системы. Качество работы подтверждено отзывом . | |
|
|
Произведено развёртывание Active Directory на базе Windows Server 2003. После завершения проекта был заключен договора на дальнейшее сопровождение системы. |
