Microsoft University Online 2011 – Active Directory(Active Directory Right Management Service и Active Directory FS)

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

Настройка Active Directory Federation Services в Company.Local

Для начала нам необходимо развернуть Active Directory Federation Services в нашей организации и настроить её, для предоставления доверительных отношений между нашей организацией и её партнером. Для того чтобы развернуть Active Directory Federation Services мы воспользуемся стандартными средствами Windows Server 2008 R2, а именно Server Manager. С помощью, которого разворачиваются встроенные роли сервера. Нам необходима только роль Active Directory Federation Services.

TechDays Весна’2011

Ура, свершилось, известны даты проведения TechDays Весна’2011. Вся информация есть на http://blogs.technet.com/b/itproteamua/archive/2011/02/21/microsoft-techdays-2011.aspx.

До встречи на TechDays

Microsoft University Online 2011 – Active Directory (Active Directory Rights Management Services)

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

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

Microsoft University Online 2011 – Active Directory (Миграция AD с Windows Server 2003 на Windows Server 2008 R2)

Доброго времени суток коллеги. Это моя очередная статья, которая посвящена Microsoft University Online. В этой прошлой статье мы говори об обслуживании Active Directory Domain Services и об обслуживании Group Policy. Данная статья посвящена миграции Active Directory Domain Services c Microsoft Windows Server 2003 и Microsoft Windows Server 2003 R2 на Microsoft Windows Server 2008 или Microsoft Windows Server 2008 R2

Перед тем как приступать к самой миграции необходимо её спланировать. В планирование миграции входят такие важные моменты: определения исходных серверов, какие роли они будут выполнять, принадлежность к сайту. После того как выполнены следующие шаги необходимо выбрать тип миграции по которому и будет проходить миграция. Оптимальным вариантом для начала миграции является использование продукта компании Microsoft, который называется Microsoft Assessment and Planning (MAP) Toolkit. Данный продукт предназначен для анализа инфраструктуры, и предоставления рекомендационной документации. Полученная документация будет в дальнейшем весьма полезна, так как предоставит исчерпывающую информацию которая будет необходима при миграции.

Microsoft University Online 2011 – Active Directory (Обслуживание Active Directory Domain Services)

Доброго времени суток коллеги. Это моя очередная статья, которая посвящена Microsoft University Online. В этой прошлой статье мы говори о использовании Group Policy Preference, а также затронули вопрос моделирования, применяя групповых политик, и использования оснастки Group Policy Results. В данной статье мы поговорим об обслуживание Active Directory Domain Services и об обслуживание Group Policy.

Когда мы говорим об обслуживании групповых политик, как правило, мы подразумеваем управления их жизненным циклом. Так как в компании ИТ всегда развивается, появляются новые требования к безопасности, к настройке клиентских компьютеров и серверов, групповые политики постоянно обновляются. По этой причине необходимо всегда с осторожностью вводить изменения, оптимальным вариантом является проведения таких действий в тестовой лаборатории. Когда ведется работа с групповыми политиками важно помнить о том, что необходимо систематически проводит резервное копирование политик. Впрочем, когда мы говорим о резервном копировании Active Directory, мы должны понимать о том, что если мы делаем резервное копирование с помощью Windows Server backup, то мы делаем резервное копирование состояния системы. В резервное копирование состояния системы входит резервное копирование следующих объектов: реестр, COM+ база данных, загрузочные файлы, база Active Directory Certificate Services (AD CS), база Active Directory Domain Services (Ntds.dit), папка SYSVOL, информация о кластере, мета каталог Microsoft Internet Information Services (IIS). Разумеется, это можно производить с помощью создания резервных копий только папки SYSVOL, но этот метод не всегда является удобным, а в некоторых ситуациях восстановление из такой резервной копии весьма трудоёмкое или не возможным в силу тех или иных обстоятельств. По этой причине существует более удобный метод создания архива групповых политик, а именно использование возможностей оснастки Group Policy Management Console. Конечно же, у этого способа есть один большой недостаток, такое резервное копирование проходит в ручном режиме. Но если рассматривать идеальный вариант, когда политики вначале разрабатываются в тестовой среде, а в рабочей среде применяется только после проведения тестирования, то тогда данный недостаток не значителен. Давайте разберемся, как работает данная система.

В оснастке Group Policy Management Console мы должны выбрать домен, с которым мы будем работать. В нем мы должны выбрать раздел Group Policy Objects, который существует в каждом домене. В данном разделе находятся все групповые политики, которые присутствуют в домене, хочу заметить, что не все из этих политик обязательно должны быть закреплены за каким-то организационным подразделением или корнем домена. Из данного раздела мы и будем управлять резервным архивом наших политик, создавать резервные копии наших политик, и импортировать наши групповые политики. Нажав на сам раздел Group Policy Management Console, мы увидим основное меню, в этом меню мы можем создать политику, сделать резервное копирование всех политики, управлять резвыми копиями политик, создание таблицы миграции. Если мы нажмем правой кнопкой мишки на политике, то в меню мы увидим что можно сделать резервную копию политику, импортировать настройки политики, восстановить её из резервной копии, а также основные действия для работы с политикой. Раздел «создание таблицы миграции» используется при миграции политик из тестовой среды в рабочую среду, если необходимо в политиках менять внутренние переменные. Примером использования этого функционала очень простой. У вас есть тестовая среда, в которой вы разворачиваете политики. Вероятнее всего в ней название групп отличаются, а также UNC адреса, или любые другие переменные, например в тестовой среде адрес WSUS сервера wsus.test.company.com, а в рабочей среде wsus.company.com. Или UNC адрес порешаемой папки в тестовой среде у вас \\share.test.company.com\test, а в рабочей среде \\share.company.com\Users. Для того чтобы при импорте политик из тестовой среды, в рабочую, автоматически поменялись переменные, которые используются в тестовой среде на переменные которые используются в рабочей среде. Для проведения такой миграции, необходимо сделать резервную копию политики которую мы планируем импортировать с изменение переменных. После того как резервная копия готова, необходимо открыть редактор миграционной таблицы, и в меню этой таблицы в разделе Tools выбрать “Populate from Backup”, после чего выбираем резервную копию, и в этой резервной копии выбираем необходимую нам политику. После чего программа сама выберет все переменные и вставит их в таблицу, которую необходимо будет до редактировать, указав переменные на которые необходимо менять. После создания таблицы миграции, её необходимо сохранить и переместить в рабочую среду вместе с политикой. Для окончательной миграции групповой политики из тестовой среды в рабочую среду, необходимо в рабочей среде создать политику, после чего импортировать настройки из резервной копии, которую мы перенесли. Во время импорта политики, на первом шаге мастер предложит нам сделать резервную копию данной политики, но это не нужно, потому что политика была только создана и не содержит никаких настроек. После шага с резервным копированием мастер проверит политику на наличия переменных, которые можно изменить, используя таблицу миграции, и если такие существуют, он предложит выбор способа импорта. По умолчанию он будет перемешать существующие настройки, которые зашиты в резервной копии политики, но мы можем выбрать миграционный файл, на основе которого при импорте переменные будут заменены. Хотелось бы еще раз напомнить, что когда вы задаёте какие-то права, то желательно задавать их группе, а не пользователю. Также хочу обратить внимание, что перед импортом или восстановлением политики из резервной копии всегда можно посмотреть настройки политики, что очень полезно.

Также важной частью обслуживания Microsoft Active Directory Domain Services, является обслуживание файла с базой Microsoft Active Directory Domain Services. Основной утилитой для обслуживания Microsoft Active Directory Domain Services является утилита, которая называется NTDSUtil. Как вам наверно известно, файл базы данных Microsoft Active Directory Domain Services называется NTDS.Dit. При установке по умолчанию он находиться в папке Windows\NTDS. Но это не рекомендуемое разрешение для базы данных. Лучшей практикой является хранение файла базы данных Microsoft Active Directory Domain Services на отдельном диске. Но что же делать если на вашем домен контроллере используются настройки по умолчанию? Его можно просто перенести на другой диск с помощью утилиты NTDSUtil. Для этого необходимо остановить роль Microsoft Active Directory Domain Services это делается с помощью команды «NET stop NTDS», но данный способ возможен только в Microsoft Windows Server 2008 и Microsoft Windows Server 2008 R2. Если же у вас Microsoft Windows Server 2003 или Microsoft Windows Server 2003 R2 то вам необходимо перезагрузить ваш контролер домена и запустить его в режиме восстановления каталога. Чтобы войти в режим восстановления каталога этого необходимо перезагрузить ваш домен контролер и при начале загрузки нажать F8, в появившемся меню необходимо выбрать Directory Service Recovery Mode. Когда ваш домен контролер загрузится вам необходимо зайти под учетными данными администратора. Для этого в поле имя пользователя вводим .\Administrator, а пароль тот который был указан во время установки домен контролера. После этого вы можете работать с файлом базы Microsoft Active Directory Domain Services. Для этого необходимо запустить утилиту NTDSUtil. Когда вы запустите NTDSUtil, откроется командная строка управления этой утилиты. В начале необходимо подключиться инстансу, который называется NTDS, для этого необходимо написать в командной строке NTDSUtil «Ac In NTDS», что означает активировать инстанс NTDS. После того как мы активировали инстанс необходимо перейти в систему управления файлами, для этого пишем «files». Если вы работаете с Microsoft Windows Server 2008 и Microsoft Windows Server 2008 R2 и забыли остановить роль Microsoft Active Directory Domain Services, то появиться сообщение о том, что нет доступа к файлу и необходимо остановить сервис. Если никаких ошибок не было, то можно преступать к перемещению файла базы данных, также таким способом мы можем переместить лог файлы роль Microsoft Active Directory Domain Services. Для этого необходимо ввести следующую команду «move db to %path%», где %path% путь к новому размещению нашего файла базы данных Microsoft Active Directory Domain Services. Для перемещения логов необходимо ввести «move logs to %path%», где %path% путь к новому размещению логов Microsoft Active Directory Domain Services. После чего необходимо проверить права на доступ к новому размещению нашей базы данных и логов. Главное чтобы система и пользователи из группы Administrators имели полные права, и все дочерние объекты наследовали это правило, а также запретить наследование правил для этого объекта от его родителя. После этого необходимо в командной строке NTDSUtil ввести команду «integrity», для проверки целостности. После этого можно выходить из NTDSUtil для этого необходимо выполнить команду «quit».

Также с помощью этой оснастки можно перемешать, или захватывать роли Flexible Single Master Operation. Существует несколько действий, при которых недопустимы конфликты. Например создание нового домена в лесу. Допустим, два администратора решили в одно время создать по домену test в лесу corp.com, то система сама никогда не сможет определить какой из них нужно оставить. Поэтому и существуют роли, которые называются FSMO. Их задача не допускать конфликтов в Microsoft Active Directory Domain Services. Существует всего пять FSMO ролей, это Хозяин именования домена (Domain naming master), Хозяин схемы (Schema master), Хозяин инфраструктуры (Infrastructure Master),Эмулятор PDC (PDC emulator), Хозяин RID (RID Master). Две первые из них в лесу уникальны и существуют в одном экземпляре, и соответственно три присутствуют в каждом домене.

Роль хозяин именования домена (Domain naming master) — отвечает за изменение пространства доменных имен каталога в рамках леса. Только контроллер с этой ролью имеет право удалять и добавлять домены в каталог. Кроме того, он добавляет и удаляет перекрестные ссылки на домены во внешних каталогах.

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

Хозяин инфраструктуры (Infrastructure Master). Контроллер домена, выполняющий роль хозяина инфраструктуры, отвечает за обновление идентификаторов защиты (GUID и SID для участников безопасности) и различие имен объектов.

Эмулятор PDC (PDC emulator). Эмулятор основного контроллера домена необходим для синхронизации времени в рамках компании. В состав Windows входит служба времени W32Time, используемая протоколом проверки Kerberos. Все компьютеры под управлением Windows в рамках одной компании должны иметь одинаково настроенные часы. Эмулятор PDC домена выступает в роли главного эмулятора домена. Эмулятор PDC в корне леса становится главным эмулятором в пределах предприятия. Его следует настроить на получение значения времени от внутреннего источника. При выборе источника времени обладатели роли FSMO эмулятора основного контроллера домена следуют иерархии доменов.

Хозяин RID (RID Master). Контроллер домена, выполняющий роль хозяина RID, отвечает за обработку запросов пула RID от остальных контроллеров в рамках определенного домена, а также удаление объектов из домена и помещение их в другой домен. Идентификатор SID участника безопасности должен быть уникальным для всего домена, поэтому каждому участнику безопасности присваивается уникальный идентификатор безопасности SID, который содержит идентификатор домена и относительный идентификатор RID, который является уникальным для каждого принципала безопасности. Во всех идентификаторах SID присутствуют четыре различных элемента.

Для передачи роли необходимо выполни следующие команды. Вначале запустить утилиту NTDSUtil. После чего выполнить подключение к серверу, которому вы хотите передать одну из ролей FSMO. Для этого в командной строке NTDSUtil пишем «connections», этой командой мы переходим в меню управления соединениями. После выполнить команду подключения к серверу, для этого выполняем «connect to server <имя конечного сервера>». Теперь необходимо перейти в основное меню, для этого пишем «quit». И теперь можно передавать роль, для этого пишем «Transfer <имя роли>». По окончанию передачи ролей, выполняем команду выхода, выполнив «quit». Таким же образом происходит и захват роли, только вместо «Transfer <имя роли>», выполняем «SEIZ <имя роли>». Захват ролей необходим для тех случаев когда домен контроллер, которому принадлежала роль вышел из строя, и по этой причине нельзя её перенести.

Введение в IO

Перед каждым «полевым» администратором очень часто ставится задача о построении инфраструктуры с нуля. И администратор сразу же берется за дело. Берет первый попавшееся железо, и начинает на него «сетапить» все, что он считает нужным, не задумываясь о последствиях таких не контролируемых установок. Ведь когда мы начинаем строить или достраивать инфраструктуру мы должны начинать не с установки, а с планирования. Мы должны понимать то что в «правильном офисе», всё должно быть объединено в одно целое, и работать как одно целое. Многие администраторы часто употребляют выражение «зоопарк», не понимая истинного его значения. Для многих понятие «не зоопарк», это среда с одной ОС, что не весьма верно.

Давайте примем что «зоопарк», это не контролируемая и соответственно не стандартизированная инфраструктура, с разрозненными системами которые. Если смотреть на данную структуру с позиции уровней зрелости, которую предлагает компания Microsoft, то «зоопарк» это базовый уровень. Какие есть проблемы в инфраструктуре такого уровня, во-первых низкий уровень автоматизации процессов управления, и как следствие, большие затраты на обслуживание такой инфраструктуры, большое время простоя, низкий уровень безопасности. Но самое главное это отсутствие возможности динамического развития инфраструктуры. Методы установка ПО и выбор ПО, настройки прав доступа, а также методы организация безопасности в такой инфраструктуре разрознены и, как правило, производятся по личному желанию администратора. А если в организации несколько системных администраторов, нередко один администратор, не знает или даже не догадывается что делает другой, что приводит к проблемам ИТ отдела с руководством компании. Как следствие такой разнородности, неспособности инфраструктуры удовлетворять требования безопасности, а также повышенные затраты на обслуживание ПК, не благоприятно сказываются как на ИТ, так и на бизнесе. Данный уровень можно сравнить с «рабством» по отношению к системному администратору, ведь системный администратор занимается беганьем от пользователя к пользователю и не занимается внедрением систем, которые упрощают ведение бизнеса. В связи с тем что в такой инфраструктуре ничего не стандартизировано, нету систем мониторинга и автоматизации, проще говоря нету ничего, ИТ является весьма затратным, из-за неспособности помочь в работе бизнеса. И это приводит к нежеланию руководства вкладывать деньги в ИТ, что в свою очередь не позволяет ИТ внедрять какие либо системы из-за отсутствия финансирования.

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

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

Когда необходимо построить инфраструктуру, которая будет максимально оптимизировать работу бизнеса и подстраиваться под задачи бизнеса, нам необходима динамическая инфраструктура. Содержание этой инфраструктуры дороже, чем рациональной, но для бизнеса она является более приемлемой. В такой инфраструктуре присутствуют системы называемые «Self-Service» , также автоматизированы бизнес процессы и другие системы автоматизации для упрощения работы пользователей. Уменьшено количество сущностей, что за собой влечет уменьшение точек отказа и уменьшение затрат на обслуживание. С точки зрения безопасности, она более надежная и как показывает практика количество инцидентов безопасности стремиться к нулю, что весьма важно для продуктивной работы компании. Такая инфраструктура хоть и более затратная, но она помогает увеличить производительность вашего персонала и уменьшить время простоя, что явным образом отразиться на прибыли вашей компании.

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

Каждая компания должна сама выбрать тот уровень, который её больше подходит. В выборе уровня инфраструктуры вы можете всегда обратиться к партнерам компании Microsoft за помощью, которые всегда вам смогут помочь с выбором необходимого вам уровня, а также помогут в её построении. Также компания Microsoft предлагает электронную документацию, которая поможет вам в выборе, а также в построении необходимого уровня инфраструктуры исходя из ваших ресурсов, эту информацию вы всегда можете найти по адресу http://microsoftio.partnersalesresources.com/. Само главное нужно понимать, что правильно построенная инфраструктура может приносить деньги компании.

Планирование Active Directory Domain Services. Часть 1

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

Когда мы говорим о планировании Active Directory Domain Services, мы должны понять какие существуют важные моменты в планирование Active Directory Domain Services. Не стоит, забывает то, что Active Directory Domain Services одна из самых важных систем в вашей инфраструктуре, так как на неё ложится важная роль аутентификации пользователей и не только. Как любит говорить один из лучших специалистов компании Microsoft Игорь Шаститко о Active Directory Domain Services – «Это наше всё».

Если смотреть на Active Directory Domain Services с точки Microsoft Infrastructure Optimization model, то данная система должна присутствовать на всех уровнях зрелости, начиная со стандартного, а это еще рациональный и динамический уровень зрелости инфраструктуры.

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

Давайте рассмотрим, как должно проходить планирование Active Directory Domain Services. Как пример давайте возьмём какую-то придуманную компанию и попытаемся спланировать для неё Active Directory Domain Services.Пускай этой компанией будет некая компания “Pupkin Company”, у которой 5 основных офисов и 11 филиалов. Офисы пускай находятся в Киеве, Львове, Одессе, Москве, Санкт-Петербурге, также по два филиала в каждом из выше перечисленных городов и один в Харькове. В целом численность сотрудников, которые постоянно работают с компьютером в основных офисах 4 тысячи и 500 человек в филиалах.

Теперь давайте приступим непосредственно к планированию. Исходя из документации компании Microsoft касательно планирования Active Directory Domain Services, вначале нам не обходимо определится с количеством лесов. На самом-то деле нам необходимо определится, будем ли мы использовать много лессовую структуру. Есть несколько основных причин использования много лессовой инфраструктуры. Во первых это разница в схемах, как пример слияние двух компаний которые используют свои приложения которым необходима определенная схема, или в разных отделах используют разное программное обеспечение работоспособность которого напрямую зависит от схемы. И как следствие может возникнуть конфликт схем. Одной из причин может быть требование безопасно использования двух лесов, или опять же при слиянии 2 компаний ни одна из компаний не желает передавать управление своей инфраструктурой Active Directory Domain Services ИТ отделу другой компании. Так же существуют примеры использование отдельного леса для разворачивания в нём ресурсов. Для данной ситуации необходимо определится, будет ли компания дальше развивать. Так как при развитии компании база Active Directory Domain Services будет неуклонно расти, а при больших размерах базы её репликация может оказаться большой проблемной. Если компания планирует дальше развиваться и открывать свои представительства в других городах, то стоит задуматься о создании нескольких лесах. Так как мы планируем развиваться и в других городах, и нашей компании не требуется специфические настройки Active Directory Domain Services, и всё устраивает отдел безопасности, мы можем использовать один лес. Но хочу обратить ваше внимание на то, что с самого начало необходимо всё согласовать, начиная от программного обеспечения которое будет использовать Active Directory Domain Services для своих нужд, до отдела безопасности, и только после этого принимать решение о количестве лесов в вашей компании. Также не стоит забывать что много лёссовая инфраструктура требует больше финансовых затрат, как на оборудование, так в прочем и на персонал который будет этим заниматься.

После этого мы должны преступить к шагу, в котором мы будем определиться с количества доменов в нашем лесу или лесах, всё зависит от решения, которое вы приняли на предыдущем шаге. Для любой начинающей компании достаточно будет одного домена, обслуживание такого инфраструктуры Active Directory Domain Services менее затратное, так как не требует покупки дополнительного программного обеспечения и оборудования, но такой вариант не всегда может отвечать требованиям, которые выдвигает бизнес, служба безопасности и т.д. Также используя один домен ресурсы на его управления намного меньше. Но как я уже говорил раньше не всегда подходит однодоменная структура. Обычно необходимость в создании дополнительных доменов связана с проблемами в репликации. Основные проблемы это или большой размер реплицируемых данных и часто меняющиеся атрибуты. Когда мы говорим о репликации данных, необходимо учитывать каналы для обеспечения репликация. Также необходимость в создании нового домена может быть связана с необходимостью использовать разные уровни домов. Иногда потребность много доменной структуре вызвана необходимостью создания автономных подразделений и предоставления для них отдельного подразделения (OU) в домене не достаточно. Некоторые компании создают N+1 доменов. Это связано с тем, что один домен является корневым и используется исключительно для управления инфраструктурой и предоставления некоторых ресурсов. Такое решение бесспорно является более затратным, но помогает достичь более высокого уровня безопасности.

Для нашего примера я бы посоветовал использовать 3 домена, один из них был-бы корневым и в нем находились общие ресурсы, и два по названию стран в которых они находятся. Хотя построить такую структуру не с нуля, требует больших финансовых затрат и является весьма трудоёмкой. В данном случае корневая зона физически должна находиться на основной площадке, но с точки зрения безопасности и построения отказоустойчивости, её желательно реплицировать на другую площадку. В данной ситуации подразумевается, что существует 2 тех площадки, одна в Украине, а другая в России, и наш домен получается размазанным между двумя площадками. Хотя можно обойтись и двумя домена, но в таком случае они будут не равноправными. Что может повлечь за собой нежелательные последствия.

После чего нам необходимо определиться с именами наших доменов в лесу. У домена есть два имени, первое это NetBIOS имя, для преобразования которого используется служба WINS, второе это DNS имя, для преобразования которого и используется служба DNS. Поэтому при планировании, на этом шаге, мы должны руководствоваться исходя из некоторых ограничений и советов. Основным ограничением является длина NetBIOS имени, которое не может превышать 15 символов, и не может включаться в себя следующие символы (\), (/),(:), (*), (?), ("), (<), (>), (|). Также стоит сразу же определиться с именем, и оно должно быть уникальным, чтобы при объединении с другой компанией не начались конфликты имен. По этой причине не стоит давать доменам NetBIOS имена, такие как firma, corp, company. Когда мы говорим о DNS имени нам стоит помнить то, что нам необходимо выбрать уникальное доменное имя, для этого можно пойти двумя путями. Первый путь это купить домен, что является более приемлемым решением. Второй способ это создавать домен в не существующей зоне, как пример это может быть зона local или my, но в этом случае могут возникнуть проблемы, когда мы будем разворачивать свой центр сертификации, и делать публикации сервисов во внешний мир. В целом может быть много таких проблем. Опять же может возникнуть проблема при объединении с другой компанией, если окажется что у вас одинаковое именное пространство. Как показывает практика, очень часто используются имена доменов, такие как firma.local, corp.local, company.local, что является в корне не правильным и указывает на отсутствие планирования Active Directory Domain Services в организации. Когда мы выбираем DNS имя, мы должны помнить что в его имени не могут присутствовать некоторые символы, а именно (,), (~), (:), (!), (@), (#), ($), (%), (^), (&), (‘), (()), ({}), (_)

Для нашего случая я рекомендовал бы сделать выдать следующие DNS имена, корневому домену дать имя pupkin.com. Напомню что из него идет управления другими доменами. И соответственно два других домена назовём Ukraine.pupkin.com и Russia.pupkin.com. Каждый из этих доменов будет являться дочерним доменом pupkin.com. Если мы говорим о NetBIOS именах, но у корневого домен контролера оно будет pupkin, и соответственно Ukraine и Russia у двух других доменов в нашей инфраструктуре.

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

Данный материал был подготовлен опираясь на информацию, размешенную на сайте http://www.microsoft.com/ipd и technet.com.

Дополнительный материалы для изучения http://technet2.microsoft.com/windowsserver/en/library/fba18139-1168-4259-82b3-c3b4c81945981033.mspx?mfr=true

http://technet.microsoft.com/ru-ru/library/cc759036(WS.10).aspx

Microsoft University Online 2011 – Active Directory (Group Policy Preference)

Доброго времени суток коллеги. Это моя очередная статья, которая посвящена Microsoft University Online. В прошлой статье мы говори о том, как менять политику паролей, как использовать гранулярные политики паролей и какие существуют политики безопасность. Сегодня же пойдет разговор о использовании Group Policy Preference, а также затронем вопрос моделирования, применяя групповых политик, и использования оснастки Group Policy Results.

Начнем мы с Group Policy Preference. Данная часть групповых политик весьма функциональна, и может использоваться для замены большинства Logon скриптов. Хоть о данном функционале мало говорят, но он занимает очень важную роль в групповых политиках. Group Policy Preference очень простой в использовании. Но к сожалению есть некоторые проблемы при его внедрении в вашей организации. Основной проблемой при внедрении является то что не во всех версия Microsoft Windows присутствует необходимый функционал. Для применения Group Policy Preference на компьютере под управлением Microsoft Windows XP/2003 необходимо установить обновление, которое можно скачать по следующей ссылке http://support.microsoft.com/kb/943729. Настраивать Group Policy Preference можно из серверных операционных систем, а именно из Microsoft Windows 2008/2008R2. Также можно настраивать Group Policy Preference из клиентских операционных систем, а именно из Microsoft Windows Vista c установленным Service Pack 1 и установленным RSAT, или из Microsoft Windows Seven также с установленным RSAT.

RSAT для Windows 7 http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997

RSAT для Windows Vista http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=9ff6e897-23ce-4a36-b7fc-d52065de9960

Операционная система	Применение	Настройка
Windows XP	√ (необходимо установить CSE)	X
Windows 2003	√ (необходимо установить CSE)	X
Windows Vista	√	√ (SP1 + RSAT)
Windows 2008	√	√
Windows 7	√	√ (RSAT)
Windows 2008 R2	√	√

После того когда все требования к применению и управлению Group Policy Preference можно приступать к внедрению его в вашей инфраструктуре. Но всё же в первую очередь, вы должны разобраться в том, что может предложить вам Group Policy Preference. В этом я вам и попытаюсь помочь.

Разуметься с помощью Group Policy Preference вы можете настраивать как компьютеры, так и пользователей. В Group Policy Preference существует два основных раздела это Windows Settings и Control Panel Settings.

Для начала разберем Windows Settings для компьютера. В данном разделе существуют следующие параметры: Environment, Files, Folders, INI Files, Registry, Network Shares, Shortcuts. Давайте теперь заберемся с каждым из этих параметров.

Environment. Данный раздел используется для того чтобы создать, изменить, или удалить системных переменных. Например, нахождения какой-то папки. Многие из вас часто переходят в папку с временными файлами её имя tmp, для перехода в эту папку используя командную строку, мы можем воспользоваться командой cmd %tmp%. В данном разделе мы настраиваем такие переменные, но для компьютера. Такими переменными могут пользоваться не только пользователи, но и программы. Часто такие переменные используются в скрипт.

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

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

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

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

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

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

Теперь можно перейти разделу Windows Settings для пользователя. В данном разделе существуют следующие параметры: Application, Drive Maps, Environment, Files, Folders, INI Files, Registry, Shortcuts. Как вы заметили большая часть политик для пользователя, идентична с политиками для компьютера. Поэтому разделы, Environment, Files, Folders, INI Files, Registry, Network Shares, Shortcuts, мы рассматривать не будем.

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

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

Теперь давайте рассмотрим Control Panel Settings для компьютера. Сюда входят следующие разделы: Data Sources, Devices, Folder Options, Local Users and Groups, Network Options, Power Options, Printers, Scheduled Tasks, Services

Раздел Data Sources предназначен для управления источниками данные на компьютере. Примером использования может быть необходимость ситуация когда на определенной группе компьютеров необходимо создать подключение к SQL серверу.

Раздел Devices может использоваться для отключения устройств.

Раздел Folder Options используется для настройки типов файлов и описание действий для работы с этим типом файлов. Примером использования может быть задание приложения для открытия определенного типа фалов.

Раздел Local Users and Groups используется для управления локальными пользователями и группами. Примером может быть отключение или включение локальной учетной записи и заданием её определенного пароля.

С помощью раздела Network Options мы можем распространять настройки для VPN или Dial-up соединений.

Раздел Power Options используется для настройки политик управления питанием.

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

Раздел Scheduled Tasks предназначен для распространения задач планировщика.

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

В оснастке Group Policy Management Console есть возможность моделирования применения политик, данный раздел называется Group Policy Modeling. Во время использования данного функционала, нам необходимо указать, где находиться компьютер и пользователь, также необходимо указать в каких группах безопасности присутствуют они и какие WMI фильтры применять. В результате мы получим результат моделирования, в котором будет видно, какие политики будут применяться. Данная оснастка очень полезна при внедрении групповых политик, а также во время Active Directory Domain Services.

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

Microsoft University Online 2011 – Active Directory (Групповые политики. Часть 2)

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

Когда мы говорим о политиках безопасности, мы подразумеваем настройку операционной системы и раздачу прав пользователям на те или иные действия на определённом компьютере. Разумеется, с точки зрения групповых политик, политики безопасности существуют как для компьютера, так и для пользователя. Политики безопасности для пользователя весьма скудны по сравнению с политиками безопасности компьютера. В политиках безопасности пользователя существует только две настройки, а именно, Public Key Policies и Software Restriction Policies.

Раздел Public Key Policies предназначен для управления сертификатами. С помощью этого раздела мы можем настраивать политики сертификатов, также задавать политики авто выдачи сертификатов и распространения доверительных сертификатов. Раздел Software Restriction Policies предназначен для задания политик, которые определяют, какое программное обеспечение можно запускать на компьютер, а какое нет.

В случае с настройкой безопасности для компьютера ситуация более интересная, так как основная часть политик предназначена для компьютера. В политиках безопасности для компьютера находятся следующие разделы: Restricted Groups, Account Policies, Local Policies, Event Log, System Services, Registry, File System, Wired Network Policies, Windows Firewall with Advanced Security, Network List Manager Policies, Wireless Network Policies, Public Key Policies, Software Restriction Policies, Network Access Protection, Application Control Policies, IP Security Policies, Advanced Audit Policy Configuration. Давайте разберемся для чего существует каждый из этих разделов.

Restricted Groups. Данный раздел используется для определения участников безопасности к группе, проще говоря, задаёт список участников группы, или для определения членства этой группы, проще говоря, задания списка в каких группах состоит определенная группа.

Account Policies. Данный раздел предназначен для описания политик паролей, политик блокировки аккаунта, а также описывает политики протокола Kerberos. О политике паролей пойдет речь чуть дальше, и этот вопрос будет рассмотрен более детально.

Local Policies. Данный раздел является одним из самых важных при настройке локальной безопасности компьютера. С помощью этого раздела включается поддержка аудита тех или иных событий. Начиная с Windows 7/2008 R2 можно настраивать данную политику более детально используя раздел Advanced Audit Policy Configuration. В разделе дочернем разделе, раздела Local Policies, существует еще два, не менее важных раздела, которые напрямую связаны с безопасностью компьютера, это User Rights Assignment и Security Options. В разделе User Rights Assignment мы задаем права для пользователей на те, или иные действия. Хочу обратить ваше внимание, что лучше всего связывать права не с конкретным пользователем, а с группой, чтобы в дальнейшем было проще управлять инфраструктурой, и уменьшить риски в случае человеческих ошибок. Примером такой человеческой ошибки может быть ситуация когда человека переводят в другой отдел, изменили его членство в группе но, из-за того что какие-то права были заданы ему напрямую права за ним остались. В раздел Security Options находятся политики связанные с безопасность в сети, настройки UAC, и прочие настройки которые связаны с безопасностью компьютера.

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

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

Registry. Этот раздел предназначен для управления правами доступа к веткам реестра.

File System. Идентичен разделу «Registry», он также предназначен для определения прав, но не на реестр, а на файловую систему.

Wired Network Policies. Данные раздел предназначен для настройки проводной сети. Если у вас в сети используется IEEE 802.1X то данный раздел вам будет интересен. Данная политика применима к компьютерам под управлением Windows Vista и новее.

Wireless Network Policies. Этот раздел, как и Wired Network Policies, предназначен для настройки сети, но не проводной, а беспроводной. Также политики этого раздела могут распространяться на компьютеры под управлением Windows XP. При создании политики в данном разделе вы можете выбрать два типа политик. Одна для Windows Vista и более новых версий Windows, вторая для Windows XP. Разумеется, что политика для Windows Vista и более новых версий Windows, более функциональна, она позволяет запретить пользователям подключаться к тем или иным беспроводным сетям, или вообще запретить подключаться ко всем кроме списка разрешенных, это может быть полезно для настройки корпоративных ноутбуков.

Network List Manager Policies. Тут мы можем настроить отображение нашей доменной сети, а также как какие сети будут определяться другие сети. Опять же данный параметр очень полезен при настройке корпоративных ноутбуков. Данный параметр применим только для компьютеров с установленной Windows Vista и более новой версией Windows.

Windows Firewall with Advanced Security. С помощью этого раздела мы настраиваем и распространяем расширенные настройки нашего брандмауэра Windows.

Public Key Policies. Задача данного раздела управлять сертификатами. С помощью этого раздела мы можем настраивать политики сертификатов, также задавать политики авто выдачи сертификатов и распространения доверительных сертификатов.

Software Restriction Policies. Данный раздел предназначен для задания политик, которые определяют, какое программное обеспечение можно запускать на компьютер, а какое нет.

Network Access Protection. Данный раздел предназначен для настройки клиента Network Access Protection. Более детально вы можете прочитать перейдя по следующей ссылке http://technet.microsoft.com/en-us/library/dd197544(WS.10).aspx

Application Control Policies. Данный раздел предназначен для настройки политик AppLocker. Задача AppLockerа идентична задаче которая лежит на «Software Restriction Policies», но по с равнению с ним, AppLocker более функциональный. AppLocker доступен только в Windows 7, и только в двух её редакциях, а именно в Ultimate и Enterprise.

Advanced Audit Policy Configuration. В этом разделе мы можем более детально настроить политики аудита, аудит чего именно необходимо вести. Хотя расширенная политика аудита была сделана еще для Windows Vista, но возможность настраивать политики аудита используя групповые политики появилась только в Windows 7.

Password Policy. Данный раздел предназначен для создания политики пароля для пользователей домена. В данном разделе есть 6 разных политик, а именно – «Минимальная длина пароля», «Максимальный срок действия пароля», «Минимальны срок действия пароля», «Пароль должен отвечать требованиям сложности», «Хранить пароли, используя обратимое шифрование» и «Вести журнал паролей». Значение каждого из этих параметров очень важно для нас, как для администратора, который занимается проблемами безопасности.

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

Максимальный срок действия пароля. Этот параметр безопасности определяет период времени (в днях), в течение которого можно использовать пароль, пока система не потребует от пользователя сменить его. Срок действия пароля может составлять от 1 до 999 дней; значение 0 соответствует неограниченному сроку действия пароля. Если значение максимального срока действия пароля составляет от 1 до 999 дней, то значение минимального срока действия пароля должно быть меньше максимального. Если значение максимального срока действия пароля равно 0, то минимальный срок действия пароля может принимать любые значения в диапазоне от 0 до 998 дней. Рекомендуется устанавливать для срока действия паролей значение от 30 до 90 дней, в зависимости от рабочей среды. В этом случае у злоумышленника ограничено время, в течение которого он может взломать пароль пользователя и получить доступ к сетевым ресурсам.

Минимальная длина пароля. Этот параметр безопасности определяет минимальное количество знаков, которое должно содержаться в пароле пользователя. Можно установить значение от 1 до 14 знаков, либо 0 знаков, если пароль не требуется.

Минимальный срок действия пароля. Этот параметр безопасности определяет период времени (в днях), в течение которого пользователь должен использовать пароль, прежде чем его можно будет изменить. Можно установить значение от 1 до 998 дней либо разрешить изменять пароль сразу, установив значение 0 дней. Значение минимального срока действия пароля должно быть меньше значения максимального срока действия пароля, за исключением значения максимального срока, равного 0 дней, означающего, что срок действия пароля никогда не истечет. Если значение максимального срока действия пароля равно 0, то минимальный срок действия пароля может принимать любые значения в диапазоне от 0 до 998 дней. Установите значение минимального срока действия пароля больше 0, чтобы включить ведение журнала паролей. Без установки минимального срока действия пароля пользователь может изменять пароли повторно, пока не получит свой старый предпочитаемый пароль. Значение по умолчанию установлено вопреки этой рекомендации, поэтому администратор может назначить пользователю пароль, а затем потребовать сменить его при входе пользователя в систему. Если для журнала паролей установлено значение 0, пользователю не нужно выбирать новый пароль. По этой причине значение для журнала паролей по умолчанию равно 1.

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

Латинские заглавные буквы (от A до Z)

Латинские строчные буквы (от a до z)Цифры (от 0 до 9)

Отличающиеся от букв и цифр знаки (например, !, $, #, %)

Требования сложности применяются при создании или изменении пароля.

Хранить пароли, используя обратимое шифрование. Этот параметр безопасности определяет, используется ли операционной системой для хранения паролей обратимое шифрование. Эта политика обеспечивает поддержку приложений, использующих протоколы, требующие знание пароля пользователя для проверки подлинности. Хранение паролей с помощью обратимого шифрования – по существу то же самое, что и хранение паролей открытым текстом. По этой причине данная политика не должна применяться, пока требования приложения не станут более весомыми, чем требования по защите паролей. Эта политика необходима при использовании проверки подлинности протокола CHAP через удаленный доступ или службу проверки подлинности в Интернете (IAS). Она также необходима при использовании краткой проверки подлинности в IIS.

Хочу обратить ваше внимание, что политика паролей в домене задаётся в одном месте, и вы не можете для разных подразделений ставить разные политики пароля. Политика паролей задаётся в политике по умолчанию (“Default Domain Policy”). И тут сразу же возникает вопрос, а что же делать если у меня есть пользователи, которым надо завысить требования к паролю, допустим пользователям которые имеют доступ к важной информации. Неужели необходимо ставить всем пользователям завышенную политику, если политика паролей назначается в одном месте? Нет не обязательно. Главное в этой ситуации найти золотую середину. Как правило, выставлением требований к безопасности должен занимать отдел безопасности. После того как политика по умолчанию сформирована нам необходимо создать гранулярные политики. Они создаются не классическим методом привязки политики с помощью Group Policy Management Console, а с помощью ADSIEdit. Хоть это и выглядит очень страшно, ничего страшного в этом нет. Для начала нам необходимо подключиться к нашему серверу используя оснастку ADSIEdit и подключиться к «Default naming context». И перейти в CN=Password Setting Container, CN= System, DC=<DOMAIN>. Если переходить, используя древовидную иерархию, мы перейдем в начале в DC=<DOMAIN>, потом CN= System , и в конце в интересующий нас контейнер в котором и будут находиться наши гранулярные политики, его имя CN=Password Setting Container. Для того чтоб создать новую политику необходимо выбрать создание нового объекта, после чего откроется визард, с помощью которого мы и будем создавать нашу политику. В ходе визрда у вас будут спрашиваться переменные, описание которых находиться ниже.

msDS-PasswordSettingsPrecedence. Этот параметр задает приоритет данной политики. Значение должно быть больше чем 0

msDS-PasswordReversibleEncryptionEnabled. Этот параметр безопасности определяет, используется ли операционной системой для хранения паролей обратимое шифрование. Эта политика обеспечивает поддержку приложений, использующих протоколы, требующие знание пароля пользователя для проверки подлинности. Значение может быть FALSE / TRUE

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

msDS-PasswordComplexityEnabled. Этот параметр безопасности определяет, должен ли пароль отвечать требованиям сложности. Если эта политика включена, пароли должны удовлетворять следующим минимальным требованиям. Значение может быть FALSE / TRUE

msDS-MinimumPasswordLength. Этот параметр безопасности определяет минимальное количество знаков, которое должно содержаться в пароле пользователя. Значение может быть от 0 до 255

msDS-MinimumPasswordAge. Этот параметр безопасности определяет период времени, в течение которого пользователь должен использовать пароль, прежде чем его можно будет изменить. Заполняется в виде Дни:Часы:минуты:секунды

msDS-MaximumPasswordAge. Этот параметр безопасности определяет период времени, в течение которого можно использовать пароль, пока система не потребует от пользователя сменить его. Заполняется в виде Дни:Часы:минуты:секунды

msDS-LockoutThreshold. Этот парамент безопасности определяет порог неудачных попыток входа до блокировки учетных записей пользователей. Значение может быть от 0 до 65535

msDS-LockoutObservationWindow. Этот парамент безопасности определяет, через какой промежуток времени счетчик неудачных попыток будет сброшен. Заполняется в виде Дни:Часы:минуты:секунды

msDS-LockoutDuration. Этот параметр безопасности определяет, через какой период времени будет разблокирована учетная запись пользователя, в случае её автоматической блокировки. Заполняется в виде Дни:Часы:минуты:секунды

После того как политика готова необходимо изменить её атрибут msDS-PSOAppliesTo который указывает к кому будет применяться данная политика.

Microsoft University Online 2011 – Active Directory (Групповые политики)

Доброго времени суток коллеги. Это вторая статья из цикла Microsoft University Online. В предыдущей статье мы поговорили о том что такое Active Directory Domain Services, какие существуют требование к Active Directory Domain Services, по какой причине необходимо присутствие DNS сервер и о важных моментах в планировании Active Directory Domain Services.

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

Создание групповых политик.

Создание и управление групповыми политиками происходит с помощью оснастки Group Policy Management Console. Из неё происходит создание и связка, а также удаление и разрыв связи, групповых политик с определенными организационными подразделениями (Organizational Unit), и настройка групповых политик, если быть более точным, то с помощью оснастки Group Policy Management Console мы вызываем Group Policy Editor в котором уже мы и редактируем саму групповую политику. Когда мы создали и привязали политику к определенному организационному подразделению (Organizational Unit), нам необходимо её отредактировать, так как по умолчанию она пустая. Когда вы создаёте политику, вы можете использовать Starter GPO, но для возможности использовать Starter GPO, их необходимо создать. Starter GPO — хранит заготовки для создания наших групповых политик. Групповые политики часто называют GPO, что расшифровывается как Group Policy Object, так как групповая политика является в первую очередь объектом.

Когда мы создаём чистую групповую политику и начинаем её редактировать (открываем Group Policy Editor) , мы видим два основных раздела:

1. Computer Configuration

2. User Configuration

Из их названий понятно, что в разделе Computer Configuration находятся настройки компьютера, а в User Configuration находятся настройки пользователя. В каждом из этих разделов находятся еще по два раздела, а именно:

1. Policy

2. Preferences

В разделе Policy находятся сами политики, которые разделены на 3 категории, первая Software Settings, вторая Windows Settings и третья Administrative Templates. Раздел Preferences также называется Group Policy Preference, данный раздел помогает заменить большую часть Logon скриптов и в целом очень сильно помогает администратору для решения некоторых задач, более подробно о GPP будет рассказано в одной из следующих статей.

Раздел Software Settings предназначен для распространения программного обеспечения, о нем мы поговорим чуть позднее в этой же статье. В разделе Windows Settings находятся настройки связанные с безопасностью системы, Logon\Logoff скрипты для пользователей и Startup\Shutdown скрипты для компьютера. Также здесь находиться раздел, с помощью которого распространяться политики определения доменных имен (Name Resolution Policy), этот раздел особо важен, если вы используете DirectAccess, так как он использует данный функционал. Раздел Name Resolution Policy доступен только в разделе настроек компьютера (Computer Configuration). Также в разделе Policy находить раздел политик QoS, который предназначен для распространения QoS политик, которые помогают более гибко настроить исходящие сетевые потоки.

Распространение программного обеспечения с помощью групповых политик

Для распространения программного обеспечения с помощью групповых политик существует раздел Software Settings. Для того чтобы распространять программное обеспечение используя данные раздел, необходимо иметь MSI файл. Существуют 2 метода распространения программного обеспечения используя раздел Software Settings, это Assigned и Published. Метод Published доступен только для пользователей, так как он не подразумевает обязательную установку программного обеспечения, а предполагает участие пользователя в его установке. Используя данный метод, публикуется приложение, и пользователь по желанию может его установить, используя оснастку управления программным обеспечением на компьютере. Метод Assigned, доступен как для политик пользователя, так и для политик компьютера. Данный метод принудительно устанавливает программное обеспечение, которое указано в политике. Для того чтобы распространять программное обеспечение необходимо создавать точки распространения. Точками распространения являются сетевые папки, в которых находятся программное обеспечение, которое необходимо распространять. Стоит заменить, что у пользователей и компьютеров, которые будут получать программное обеспечение должен быть доступ на чтение сетевой папки, которая выступает в качестве точки распространения. При необходимости обновления программного обеспечения на более новую версию необходимо добавить её как новое программное обеспечение которое будет распространяться, и в старой версии указать приложения указано место нахождения более нового программного обеспечения. В результате этого старое программное обеспечение будет удалено, а вместо него установлено новое. В случае удаления из политики информации о программном обеспечении, появиться вопрос о том, как поступать с данным программным обеспечением, и мы можем удалить это программное обеспечение или оставить. Также весьма важной частью установки программного обеспечения является умение распознавать платформу инсталляционного пакета и возможность запрета или разрешения установки 32 битные приложения на 64 битные операционные системы.

Использование Security Filtering

Данная функция позволяет более гибко настраивать пределы применения групповой политики. По умолчанию Security Filtering настроен таким образом, что все аутентифицированные пользователи могут получать политику. Но при необходимости можно указать, кому будут применяться политика. Стоит помнить, что если вы настраиваете политику для компьютера и хотите использовать Security Filtering, то необходимо указывать что компьютер имеет доступ к данной политике. Security Filtering для политики настраивается с помощью оснастки Group Policy Management Console. Когда вы перейдете в оснастку Delegation, и если вы не меняли значение Security Filtering, то на закладке Delegation вы увидите, что для Authenticated users стоит разрешение, на чтение политики исходя из Security Filtering. Но если вам необходимо просто указать, кому не надо иметь доступ к данной политике стоит воспользоваться закладкой Delegation в Group Policy Management Console. В данной закладке необходимо добавить нового пользователя и явным образом запретить ему применение политики, это делается в расширенном режиме (кнопка Advanced). Примером использования Security Filtering может быть ситуация, когда у вас в одном организационном подразделении находятся все сотрудники отдела продаж, но есть необходимость, чтобы определенная политика применялась только к определенной группе сотрудников. Для этого, всех сотрудников, к которым должна примениться политика помешаем в новую группу, и используя Security Filtering задаём группу к которой применяется политика.

Использование WMI Filtering

WMI Filtering как и Security Filtering предназначен для фильтрации применения политик. Но работает он по другому принципу. Вначале администратором или человеком ответственным за групповые политики создается WMI запрос, который привязывается к групповой политике. В случае если WMI запрос возвращает TRUE, то политика применяется, если вернется FALSE, то политика не применяется. Как пример использования WMI Filtering, можно взять ситуацию когда необходимо чтобы групповая политика применилась только к клиентским компьютерам под управлением Windows Vista и Windows 7. Для этого необходимо запустить Group Policy Management Console, на панели навигации выбираю WMI Filters, там правая кнопка мышки и New. В поле Name набираю Windows 7 и нажимаю Add. В поле Query набираю «select * from Win32_OperatingSystem where Version like "6.%" and ProductType = "1"». В данном запросе используется значение двух переменных, первая Version, вторая ProductType. ProductType — это тип продукта: для клиентские версий Windows он ровняется 1, для серверные версии Windows, выступающие в роли контроллера домена – 2, а для серверные версии Windows, не выступающие в роли контроллера домена – 3. Version это версия ОС для Windows Server 2008 R2 или Windows 7 – 6.1%, для Windows Server 2008 или Windows Vista – 6.0%, для Windows Server 2003 – 5.2%, Windows XP – 5.1%, Windows 2000 – 5.0%. На самом деле это не единственный пример использования WMI Filtering. Его можно использовать для определения: установлено ли программное обеспечение, достаточно ли системных ресурсов, присутствие ли необходимые аппаратные устройства и т.д.

Правила применения политик

Групповые политики применяются снизу вверх. Это значит что в начале применяются политики которые непосредственно привязаны к организационному подразделению, потом применяются политики которые привязаны к родительскому подразделению, и так до самого верхнего уровня. После этого сразу же возникает вопрос, а в какой последовательности внутри организационного подразделения применяются групповые политики, внутри каждого организационного подразделения есть возможность регулировать в какой последовательности они будут применяться, фактически у каждой политики есть свой номер. Настроить последовательность применения групповых политик в приделах организационной единицы, можно с помощью Group Policy Management Console