Archive

Posts Tagged ‘Active Directory’

Планирование 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 (Групповые политики. Часть 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 (Групповые политики)

Февраль 1, 2011 1 комментарий

Доброго времени суток коллеги. Это вторая статья из цикла 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

Microsoft University Online 2011 – Active Directory (Развертывание Active Directory Domain Services)

Доброго времени суток коллеги. Это моя первая статья из цикла “Microsoft University Online 2011 – Active Directory”. Каждая статья из этого цикла будет рассказывать о той же теме, что была рассказана на самом мероприятии. В этой статье будут раскрыты следующие темы

1. Что такое Active Directory Domain Services

2. Требование к Active Directory Domain Services

3. Необходимость в DNS

4. Планирование Active Directory Domain Services

Что такое Active Directory Domain Services?

Многие системные администраторы бояться устанавливать Active Directory Domain Services, как правило, этот страх связан с тем, что они не понимают, как его настраивать, и не видят то, что он может им дать.

Active Directory Domain Services — в первую очередь это одна из ролей Microsoft Windows Server 2008/2008R2, в Microsoft Windows Server 2000 и Microsoft Windows Server 2003 эта роль называлась Active Directory. Active Directory Domain Services — это централизованная система аутентификации, которая хранит информацию о всех объектах вашей инфраструктуры. Данная служба является сердцем вашей инфраструктуры, так как на неё положены важные задачи, такие как аутентификация пользователей и централизованная система управления рабочими станциями. Для хранения данных используется LDAP база, что позволяет использовать более гибко её настроить. Для аутентификации используется протокол Kerberos, который тоже является стандартизированным. Использование стандартизированных протоколов облегчает разработку программного обеспечения для компании. Если рассмотреть Active Directory Domain Services с точки зрения Microsoft Infrastructure Optimization, то 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 являться единой точкой аутентификации то помогает упростить работу пользователей, так как им необходимо единожды аутентифицироваться, хотя в этом есть и ряд своих недостатков. Также в Active Directory Domain Services входят Group Policy. Group Policy это мощный инструмент который помогает администратору стандартизировать настройки компьютеров, а также стандартизировать настройки пользователя. В случае отсутствия такой системы, стоимость содержания инфраструктуры высока, и требует больших финансовых и физических затрат. Присутствие Active Directory Domain Services помогает сократить усилия на обслуживание вашей инфраструктуры, что в свою очередь повлечёт за собой уменьшение финансовых затрат, и повысит работоспособность инфраструктуры. По этому, как говорит Игорь Шаститко — “Must have!”.

Требование к Active Directory Domain Services.

Так как мы хотим шагать в ногу со временем системные требования к Active Directory Domain Services, я буду приводить с учетом того что мы будем использовать Microsoft Windows Server 2008R2.

Пользователей в домене

Минимальное количество процессоров и домен контролеров

1–499

Один – Один процессор (ядро)

500–999

Один – Два процессора (ядра)

1,000–2,999

Два – Два процессора (ядра)

3,000–10,000

Два – Четыре процессора (ядра)

Пользователей в домене

Минимальное количество памяти на домен контролерах

1–499

512 MB

500–999

1 GB

> 1,000

2 GB

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

Необходимость в DNS

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

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

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

Шаг 1: Определиться с количеством лесов

Шаг 2: Определиться с количеством доменов

Шаг 3: Назначить имена доменов

Шаг 4: Выбрать корневой домен

Шаг A1: Дизайн структуры OU

Шаг B1: Определиться с размещением домен контролеров

Шаг B2: Определиться с количеством домен контролеров

Шаг B3: Определиться с размещением глобального каталога

Шаг B4: Определяться с размещением FSMO

Шаг C1: Создание дизайна сайта

Шаг C2: Создание дизайна линков между сайтами

Шаг C3: Создание дизайна мостов

Шаг D1: Определиться с конфигурацией домен контролеров

Определиться с количеством лесов

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

Определиться с количеством доменов

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

Дизайн структуры OU

Есть несколько подходов к дизайну OU

1) Исходя из требований к делегации прав.

2) исходя из применения групповых политик.

Когда мы планируем, дизайн исходя из требований к делегации прав, это значит, что дизайн OU в домене подготавливается к использованию делегации прав. Это значит, что мы можем выдавать привилегии конкретной группе (пользователю) на администрирование определенного ОU. Хотя делегирование можно проводить на конкретный объект (компьютер, пользователь). Когда мы планируем делегирование прав, мы должны выполнить следующие шаги:

· Определить или создать административные группы, которым будут делегированы права.

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

· Назначить права административным группам в рамках каждого OU.

Когда мы планируем, дизайн исходя из применения групповых политик. Мы пытаемся построить такую иерархию, которая будет приемлема для применения групповых политик. Хорошим тоном считается отдельно разбить на отделы, внутри отдела разбить на пользователей и ПК, ну а ПК по версиям ОС установленной. Хоть и существует возможность отменить наследование групповых политик, но стоит разрабатывать структуру OU таким образом, чтобы не пришлось её использовать.

Дополнительную информацию о планирование вы всегда можете найти на сайте компании Microsoft, по адресу http://microsoft.com/ipd

http://www.techdays.in.ua/LectureViewer.aspx?LectureId=2c868829-c6e9-46ca-8967-ef09f20ff133

Active Directory Rights Management Services. Часть 4.

В прошлых статьях я рассказывал о работе Active Directory Rights Management Services. У многих могло сложиться впечатление, что назначать права на документ можно только для пользователей организации и никак нельзя предоставлять доступ пользователям за пределами организации. Но это не так, можно предоставления внешним пользователям Live ID доступа к цифровой информации. Также можно настроить доступ с помощью Active Directory Federation Services. В данной статье я расскажу о том как настроить доступ пользователям из другой организации с помощью Active Directory Federation Services.

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

Когда установлен Active Directory Federation Services нам необходимо настроить его. Для начала необходимо изменить имя сервера, используя которое сервер будет представляться. Что бы это сделать необходимо зайти в оснастку Federation Service, нажать правой кнопкой мыши на Trust Policy и выбрать Properties. В открывшемся окне необходимо изменить параметр Federation Service URI, как пример можно использовать имя url:adfs:company.local, а параметр Federation Service endpoint URL на https://adfs.company.local/adfs/ls/

После этого необходимо изменить правила заявки. Для этого в оснастке Active Directory Federation Services необходимо перейти в Trust Policy -> My Organization, после чего необходимо выбрать Organization Claims, нажать правой кнопку мыши и выбрать New -> Organization Claim. В открывшемся окне необходимо назначить имя параметра Claim name, лучше всего использовать ассоциативные имена, на сайте TechNet.com рекомендуют использовать имя — ProxyAddresses. Параметр Claim name чувствителен к регистру, поэтому будьте внимательней. Тип переменной необходимо установить как Custom claim.

Следующим шагом будет добавление хранилища учетных записей. Для этого в оснастке Active Directory Federation Services необходимо перейти в Trust Policy -> My Organization нажать правой кнопкой мыши на Account Stores и выбрать New -> Account Stores. В открывшемся окне необходимо параметр Account Store Type установить как Active Directory Domain Services и нажать Next. На следующем шаге необходимо выбрать Enable this account store. После чего необходимо дважды кликнуть на E-mail, в открывшемся окне установить галочку напротив Enabled и параметр LDAP attribute задать как mail. Далее необходимо кликнуть правой кнопкой на Active Directory и выбрать New -> Custom claim extraction в открывшемся окне параметр Attribute ввести ProxyAddresses.

Теперь необходимо настроить pipeline с нашим кластером Active Directory Rights Management Services. Для этого в оснастке Active Directory Federation Services необходимо перейти в Trust Policy -> My Organization и нажать правую кнопку мыши на разделе Applications, после чего в меню выбрать New -> Application. В открывшемся окне необходимо значение параметра Application Type изменить на Claims-aware application и нажать кнопку Next. На следующем шаге задаётся название приложения и его URL, для этого заполняется параметр Application display name, а в Application URL пишем https://adrms.company.local/_wmcs/certificationexternal/. Далее на странице Accepted Identity Claims, поставте галочки напротив User principal name (UPN) и E-mail. И на следующем шаге необходимо поставить галочку возле Enable this application. По окончанию работы мастера в разделе Application появиться наше приложение, и нам необходимо в его настройках включить Custom Claim который мы назвали ProxyAddresses. После чего эти действия необходимо повторить те же действия, но необходимо поменять Application URL на другой, а именно на https://adrms.company.local/_wmcs/licensingexternal/. После чего первоначальная, и основная настройка Active Directory Federation Services закончена.

Теперь необходимо подготовить все наши сервера, которые входят кластер Active Directory Rights Management Services для работы с Active Directory Federation Services. Во первых необходимо пользователю от имени которого работает Active Directory Rights Management Services выставить привилегии на аудит. Для этого необходимо создать групповую политику в настройках безопасности компьютер перейти в User Rights Assignment, и изменить параметр Generate security audits добавив пользователя, от имени которого работает Active Directory Rights Management Services.

После этого необходимо включить Extranet cluster URL для нашего Active Directory Rights Management Services кластера. Это можно сделать, нажав на имени кластера правой кнопкой мыши и выбрать Propertiesи в открывшемся окне свойств выбрать закладку Cluster URLs. В этой вкладке необходимо поставить галочку напротив Extranet URLs и ввести значения адреса кластера лицензирования и сертификации в нашем случае это будет adrms.company.local, причем протокол должен быть HTTPS. После чего на всех серверах необходимо установить роль Identity Federation Support. Когда во время установки спросит адрес нашего Active Directory Federation Services сервера необходимо ввести adfs.company.local и нажать кнопку Validate.

Когда установлена роль Identity Federation Support для Active Directory Rights Management Services, необходимо в настройках кластера сделать еще небольшое изменение. Для этого войдем в консоль управления Active Directory Rights Management Services и включим Federated Identity Support, нажав на Enable Federated Identity Support. При необходимости, можно установить на какой срок будет выдаваться сертификат федеративному пользователю. Для этого необходимо нажать на Properties, предварительно выбрав Federated Identity Support, и в открывшемся окне изменить параметр Federated Identity Certificate validity period. После этого наш кластер Active Directory Rights Management Services полностью готов для работы с Active Directory Federation Services.

После этого осталось настроить только доверительные отношение между Active Directory Federation Services компании и партнером. Для начала приступим к настройке с Active Directory Federation Services сервера компании партнера. На уже за ранее установленном сервере в компании партнере необходимо изменить имя сервера, используя которое сервер будет представляться. Что бы это сделать необходимо зайти в оснастку Federation Service, нажать правой кнопкой мыши на Trust Policy и выбрать Properties. В открывшемся окне необходимо изменить параметр Federation Service URI, как пример можно использовать имя url:adfs:partner.local, а параметр Federation Service endpoint URL на https://adfs.partner.local/adfs/ls/

После этого необходимо изменить правила заявки. Для этого в оснастке Active Directory Federation Services необходимо перейти в Trust Policy -> My Organization, после чего необходимо выбрать Organization Claims, нажать правой кнопку мыши и выбрать New -> Organization Claim. В открывшемся окне необходимо назначить имя параметра Claim name, лучше всего использовать ассоциативные имена, на сайте TechNet.com рекомендуют использовать имя — ProxyAddresses. Параметр Claim name чувствителен к регистру, поэтому будьте внимательней. Тип переменной необходимо установить как Custom claim.

Теперь добавим в оснастке Active Directory Federation Services информацию о Active Directory Federation Services сервере компании company.local, которая необходима для работы Active Directory Federation Services компании partner.local. Для этого в оснастке Active Directory Federation Services необходимо перейти в Trust Policy -> Partner Organization, после чего необходимо выбрать Organization Claims, нажать правой кнопку мыши и выбрать New -> Resource Partner. На странице Resource Partner Details необходимо заполнить следующие данные: Display name, Federation Service URI, Federation Service endpoint URL. Federation Service URI должен быт url:adfs:company.local, Federation Service endpoint URL — https://adfs.company.local/adfs/ls/. На следующей странице мастера для параметра Federation Scenario выберите Federated Web SSO и нажмите Next. Далее установите галочки напротив UPN Claim и E-mail Claim. И на последнем шаге не забываем поставить галочку напротив Enable this resource partner. После этого на созданном resource partner необходимо кликнуть правой кнопкой мыши и выбрать New -> Outgoing Custom Claim Mapping. В открывшемся окне для параметра Outgoing custom claim name ввести ProxyAddresses.

Теперь осталось настроить доверия к компании партнеру (partner.local) на сервер Active Directory Federation Services компании company.local. Для этого в оснастке Active Directory Federation Services необходимо перейти в Trust Policy -> Partner Organization, после чего необходимо выбрать Organization Claims, нажать правой кнопку мыши и выбрать New -> Account Partner. На странце мастера Resource Partner Details необходимо задать значения для параметров Display name, Federation Service URI, Federation Service endpoint URL. Параметр Federation Service URI должен быть url:adfs:partner.local, а параметр Federation Service endpoint URL должен быть https://adfs.partner.local/adfs/ls/. На следующей страницу вам необходимо выбрать сертификат которым будут подписаны токены, его необходимо получить от партнера (импортировать с сервера компании partner.local). Далее необходимо выбрать Federated Web SSO. При выборе клеймов необходимо выбрать UPN Claim и E-mail Claim. После чего необходимо задать параметры Accepted UPN Suffixes и Accept E-mail Suffixes, их значение должно быть partner.local. На последнем шаге необходимо поставить галочку напротив Enable this account partner. После этого на созданном resource partner необходимо кликнуть правой кнопкой мыши и выбрать New -> Outgoing Custom Claim Mapping. В открывшемся окне для параметра Outgoing custom claim name ввести ProxyAddresses. После этого мы можем назначать доступ к файлом для партнеров.

Хочу обратить ваше внимание, что у пользователей компании parent.local необходимо изменить реестр. По адресу HKEY_LOCAL_MACHINE\Microsoft\MSDRM\Federation\ необходимо добавить переменную с именем FederationHomeRealm, типом String Value и значением uri:adfs:partner.local

Политика паролей и гранулярная политика паролей

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

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

Если в оснастке редактирования групповых политик мы перейдем в «Конфигурация компьютера -> Конфигурация Windows -> Параметры безопасности -> Политики паролей», то мы попадем в раздел, который описывать политики паролей нашего домена. В данном разделе есть 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 который указывает к кому будет применяться данная политика.

Active Directory Recycle Bin

Декабрь 21, 2010 1 комментарий

Многие из нас сталкивались с ситуацией когда случайно, или не очень случайно, были удалены обьекты Active Directory. Для восстановления удаленных данных в Windows Server 2003 и Windows Server 2008 требовался ряд усилий для их востановления. Хоть объекты не полностью удалялись из базы Active Directory это была все ровно не простая задача. С приходом Windows Server 2008 R2 проблема с восстановлением удаленный объектов Active Directory Domain Services намного упростилась. В Windows Server 2008 R2 была создана "корзина" Active Directory, которая и облегчает работу при восстановлении удаленных данных. Кроме всего прочего, при использовании корзины, вы восстанавливаете удаленные объекты в горячем режиме, что в свою очередь уменьшает время простоя.

Давайте разберемся что необходимо для того чтобы можно было пользоваться корзиной. Для того чтобы воспользоваться корзиной её необходимо включить. Но перед этим необходимо убедиться что все домен контролеры работают под управлением Windows Server 2008 R2, а также режим работы леса Active Directory Domain Services поднят до уровня Windows Server 2008 R2. Для того чтобы поднять уровень леса можно воспользоваться команд летом Set-ADForestMode (Power Shell)

Set-ADForestMode -Identity <Корневой домен леса> [-ForestMode] <Уровень леса>

или воспользовавшись оснасткой Active Directory Domains and Trusts, которая обезательно присутствует на вашем домен контролере. Исключением является только тот случай когда наш домен контролер работает под управлением Server Core, в котором нету оснасток, так как он лишен привычного нам графического интерфейса. Если вы будите производить повышение леса до уровня Windows Server 2008 R2 с помощью Power Shell вам необходимо включить модуль Active Directory, это делается с помощью следующей команды

Import-Module ActiveDirectory

После чего можно включать корзину Active Directory командой Enable-ADOptionalFeature

Пример

Enable-ADOptionalFeature –Identity ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, DC=company, DC=local’ –Scope ForestOrConfigurationSet –Target ‘company.local’

image

Теперь мы все подготовили и включили корзину Active Directory.

Для того чтобы восстановить объект мы можем также воспользоваться команд летами Power Shell. Для восстановления удаленного объекта Active Directory используется команд лет Restore-ADObject, но проще всего использовать его совместно с Get-ADObject.

Если мы используем Get-ADObject для поиска удаленного объекта нам необходимо указать что поиск необходимо производить и в удаленных объектах, это делаться с помощью ключа –IncludeDeletedObjects.

Пример

Get-ADObject -Filter {name –like "*Vasia Pupkin*} -IncludeDeletedObjects | Restore-ADObject

Но для того чтобы отсеять похожие объекты, но которые не удалены проще всего указать поиск в разделе где находятся все удаленные объекты, но еще не стерты из Active Directory. Это делается с помощью ключа –SearchBase и указание что искать необходимо в контейнере Deleted Objects, в который помешаются все объекты, после того как их удалили

Пример

Get-ADObject –SearchBase "CN=Deleted Objects,DC=company,DC=local" -Filter {name –like "*Vasia Pupkin*"} -IncludeDeletedObjects | Restore-ADObject

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

Если был удален целый Organization Unit и нам необходимо восстановить объект который находился в этом Organization Unit, то сперва необходимо восстановить Organization Unit в котором на находился интересующий нас объект. Для того чтобы узнать кто был родителем интересующего нас объекта, необходимо воспользоваться ключом  —Properties с параметром lastKnownParent

Пример

Get-ADObject –SearchBase "CN=Deleted Objects,DC=company,DC=local" -Filter {name –like "*Vasia Pupkin*"} –IncludeDeletedObjects  –Properties lastKnownParent

image

В данном примере мы видим то что пользователь Vasia Pipkin находился в Organization Unit IT_Department который был тоже удален, что видно из его видоизмененного имени на на следующем шаге нам нужно подняться на уровень выше и узнать существует ли его родитель.(После удаления имя объекта меняется, в него добавляется значение DEL и GUID объекта, что значительно уменьшает количество необходимых действий при восстановлении объекта). Заменив в предыдущем запросе name –like "*Vasia Pupkin*" на ObjectGUID –eq “f50811a2-4412-423f-90b7-314648591747”, мы сделаем запрос поиска объекта с конкретным GUID, что на порядок уменьшит время обработки запроса. (GUID удаленного объекта пишется в его измененном имени, он идет после DEL":)

Пример

Get-ADObject –SearchBase "CN=Deleted Objects,DC=company,DC=local" -Filter {ObjectGUID –eq “f50811a2-4412-423f-90b7-314648591747”} –IncludeDeletedObjects  –Properties lastKnownParent

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

Хочу обратить ваше внимание на то что объекты которые вы удаляете не на всегда остаются в корзине. Время их нахождения в корзине зависит от параметра известного как “время жизни могилки” или tombstoneLifetime. По умолчанию этот параметр имеет значени 180 дней. Для того чтобы изменить этот параметр можно воспользоваться Power Shell, или изменить с помощью ADSIEdit. Если вы решили изменить его с помощью Power Shell то вам необходимо выполнить следующую команду:

Set-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=company,DC=local” –Partition “CN=Configuration,DC=company,DC=local” –Replace:@{“tombstoneLifetime” = 500}

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

Отслеживать

Get every new post delivered to your Inbox.

Join 285 other followers