Политика безопасности домена windows 2012

Управление групповыми политиками Active Directory (AD GPO)

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

Виртуальный сервер на базе Windows

• Лицензия включена в стоимость
• Тестирование 3-5 дней
• Безлимитный трафик

Что такое групповые политики и зачем они нужны?

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

Групповые политики позволяют настраивать параметры для определенного набора пользователей или компьютеров внутри домена Active Directory. Также позволяют указать политики в одном месте для группы и применить к целевому набору пользователей.

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

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

Компоненты GPO

Существует два компонента групповых политик — серверный компонент и клиентский, т.е. данная структура относится к архитектуре “клиент-сервер”.

Серверный компонент — оснастка Microsoft Management Console (MMC), которая используется для указания настроек групповой политики. MMC может быть использована для создания политик для контроля и управления административными шаблонами и настройками безопасности (скрипты, установка ПО и прочее). Каждый из них называется расширением и в свою очередь каждый из них имеет дочернее расширение, которое разрешает добавление новых компонентов или обновление существующих без возможности затронуть или подвергнуть риску всю политику.

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

Для администрирования GPO используют Group Policy Management Console (GPMC) и Group Policy Management Editor.

Сценарии использования Active Directory GPO:

• Централизованная настройка пакета программ Microsoft Office.
• Централизованная настройка управлением питанием компьютеров.
• Настройка веб-браузеров и принтеров.
• Установка и обновление ПО.
• Применение определенных правил в зависимости от местоположения пользователя.
• Централизованные настройки безопасности.
• Перенаправление каталогов в пределах домена.
• Настройка прав доступа к приложениям и системным программам.

Оснастка Управление групповыми политиками

После установки роли Active Directory Domain Service (AD DS) на контроллер домена на сервере появится оснастка Group Policy Management. Для того, чтобы ее открыть нажмите комбинацию клавиш Win+R и в открывшемся окне введите:

Если оснастку не удается открыть, то возможно по определенным причинам она не установлена. Установить ее можно через стандартное меню Add roles and features в диспетчере сервера, выбрав компонент Group Policy Management.

Оснастка выглядит следующим образом:

Создание объектов групповой политики

Для создания объекта групповой политики перейдите во вкладку Forest -> Domains -> -> Group Policy Objects. С помощью правой кнопки мыши откройте меню и выберете New.

В открывшемся окне в поле Name введите удобное для вас имя групповой политики.

После этого вы увидите созданный объект в списке.

Теперь необходимо настроить созданный объект под конкретные задачи. в качестве примера удалим ссылку Games из меню Start. Для это с помощью правой кнопки мыши откройте меню объекта и выберете пункт Edit.

В редакторе групповых политик перейдите по иерархии User Configuration -> Policies -> Administrative Templates -> Start Menu and Taskbar. Найдите опцию Remove Games link from Start Menu и в контекстном меню выберете пункт Edit.

В открывшемся окне отметьте Enable для включения правила и при необходимости напишите комментарий. Нажмите OK для сохранения изменений.

На этом создание объекта групповой политики закончено.

Поиск объектов групповой политики

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

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

Удаление объекта групповой политики

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

Источник

Изменения в функциях безопасности Active Directory в Windows Server 2012

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

Компания Microsoft позиционировала недавно выпущенную серверную операционную систему, Windows Server 2012, как основной строительный блок для частного «облака». Многочисленные изменения появились в диспетчере виртуальных машин Hyper-V, в частности, новые функции безопасности для более гибкой сетевой изоляции между виртуальными машинами клиентов, использующих один экземпляр Hyper-V. Но в Server 2012 также реализованы важные изменения еще в одном элементе частного «облака»: Active Directory (AD).

В данной статье я расскажу об основных изменениях, относящихся к безопасности Active Directory в Server 2012. Многое можно сказать о динамическом контроле доступа, который представляет собой значительный сдвиг в модели авторизации Windows и AD. Кроме того, в Server 2012 AD появилось несколько более мелких, но не менее важных изменений в мерах безопасности.

Главное — заявки

Динамический контроль доступа — вероятно, самое существенное изменение в системе безопасности, введенное компанией Microsoft в Server 2012. Динамический контроль доступа объединяет модель управления доступом на основе заявок claims-based access control (CBAC) с операционной системой Windows и AD. Заявки представляют собой заявления о пользователях или устройствах (например, «Имя моей учетной записи — JanDC», «Я — сотрудник отдела продаж») и выпускаются надежным центром авторизации. Модель CBAC была реализована в первой версии служб Active Directory Federation Services (ADFS v1) в составе Windows Server 2003.

Заявки обеспечивают гибкий механизм для обмена доверенными атрибутами идентичности между серверами ADFS. Компании могут использовать заявки для защиты данных файлов и папок, сохраненных на компьютерах Server 2012 и Windows 8, подключенных к домену. Контроллеры домена (DC) Server 2012 могут выдавать значения для заявок в процессе проверки подлинности пользователей и компьютеров, встраивая заявки в билет проверки подлинности пользователя или компьютера. Дополнительные сведения о заявках и их использовании в продуктах Microsoft можно найти в публикации «A Guide to Claims-based Identity and Access Control» (http://msdn.microsoft.com/en-us/library/ff423674.aspx).

В основе динамического контроля доступа лежит несколько новых и усовершенствованных функций авторизации данных Windows для классификации и снабжения данных метками, применения настроек CBAC, аудита доступа к данным и шифрования данных. Для динамического контроля доступа разработчикам Microsoft пришлось внести многочисленные изменения в ключевые компоненты Windows, службы и протоколы, в том числе AD, объекты групповой политики GPO, DNS, Kerberos, Local Security Authority (LSA) и процессы Netlogon, а также сетевые протоколы, такие как Server Message Block (SMB), LDAP и удаленный вызов процедур (RPC). Требованиями динамического контроля доступа обусловлено несколько изменений в Server 2012, в том числе:

• расширение логики DC и Kerberos Key Distribution Center (KDC) позволяет использовать заявки в маркерах проверки подлинности;
• изменился формат маркера Kerberos, чтобы обеспечить передачу заявок;
• добавлены альтернативные потоки данных (ADS) в NTFS для назначения пользовательских свойств файлам и папкам;
• появилась возможность хранения условных выражений в списках ACL файлов и папок в целях повышения гибкости настроек аудита и управления доступом;
• расширена схема AD в целях централизованного хранения свойств и политик динамического контроля доступа.

Динамический контроль доступа может использовать AD для хранения централизованных политик доступа central access policies (CAP) и объектов группового доступа (GPO), а также доставки этих политик членам домена. Разработчики Microsoft также добавили вкладку централизованной политики Central Policy, показанную на экране 1, в диалоговом окне дополнительных параметров безопасности Advanced Security Settings для папок. Из этой вкладки администраторы могут выбрать централизованную политику доступа, назначаемую данной папке. Благодаря этим изменениям можно предоставить доступ к файлам и папкам на основе значений стандартных или пользовательских атрибутов объектов пользователя или компьютера в AD. Например, можно отказать пользователю в доступе к файловому ресурсу общего доступа на сервере, если атрибут Department объекта пользователя в AD не содержит значения Sales или Marketing. Такая новая логика авторизации сильно отличается от логики на основе SID пользователя и группы, которая использовалась в течение многих лет. Политики CAP можно определить из контейнера Dynamic Access Control в обновленном центре администрирования Active Directory Administrative Center (ADAC), показанном на экране 2, или с помощью команд Windows PowerShell. Можно обращаться к одному и тому же инструментарию для работы с заявками для атрибута объекта пользователя или компьютера в AD и для задания значений этих атрибутов. Контроллер домена Server 2012 добавит утверждения заявок маркерам проверки подлинности пользователя и компьютера, которые собственно содержат информацию и связаны с действующим типов заявки. Прежде чем контроллеры домена Server 2012 смогут выпускать заявки, необходимо явно разрешить им выдавать утверждения заявок; по умолчанию контроллеры домена Server 2012 отключены для CBAC. Чтобы включить CBAC, используйте параметр объекта групповой политики GPO Domain Controller support for Dynamic Access Control and Kerberos armoring в контейнере Computer ConfigurationPoliciesAdministrative TemplatesSystemKDC. Чтобы использовать объекты GPO для доставки политик CAP в компьютеры, можно задействовать новый параметр GPO Central Access Policy в контейнере Computer ConfigurationPoliciesWindows SettingsSecurity SettingsFile System container.

Динамический контроль доступа обеспечивает гибкость заявок не только при управлении доступом к файлам и папкам, но и при аудите доступа к ним. Например, в Server 2012 можно настроить правило аудита для отслеживания всех пользователей, которым разрешен или запрещен доступ к папкам, имеющим свойство confidential. Чтобы централизованно определить параметры аудита на основе заявок для файлов и папок, необходимо вызвать функцию Global Object Access Auditing на объекте GPO, которая была введена в Windows Server 2008 R2, а теперь дополнена поддержкой динамического контроля доступа.

Администраторы также могут определить гибкие параметры управления и аудита доступа для файлов и папок, в дополнение или независимо от централизованно определенных политик CAP. Специалисты Microsoft изменили диалоговые окна Advanced Security Settings в Windows 8 и Server 2012, разрешив задавать условные выражения в параметрах авторизации и аудита файлов и папок. На экране 3 показан новый интерфейс, который содержит определение разрешения с условным выражением для папки с именем SharedData.

Помимо управления и аудита доступа, динамический контроль доступа предоставляет новые, гибкие механизмы классификации данных. Хороший пример — возможность добавлять пользовательские свойства папки и файла, именуемые глобальными свойствами ресурсов, к диалоговым окнам параметров управления и аудита доступа файлов и папок. И вновь, сделать это можно с использованием ADAC или команд PowerShell. Чтобы распространить пользовательские свойства по компьютерам домена, клиенты Windows 8 и Server 2012 дополнены специальным расширением, которое использует протокол LDAP для подключения к AD и извлечения этих свойств. Эта новая функция классификации данных позволяет гибко классифицировать данные на основе выбранных атрибутов и соответственно применять меры защиты.

Файлы и папки можно классифицировать вручную с помощью вкладки Classification в свойствах файла или папки, как показано на экране 4. Вкладка Classification отображается только на компьютерах, на которых установлен компонент Desktop Experience или размещена служба роли диспетчера ресурсов файлового сервера File Server Resource Manage (FSRM).

Для файлов процесс классификации можно автоматизировать с помощью компонента классификации файлов File Classification Infrastructure (FCI). FCI появился в Server 2008 R2; он позволяет администраторам задать специальные метки классификации, назначить правила классификации и сроки действия и составлять отчеты о классификации. Администраторы могут управлять FCI из диспетчера ресурсов файлового сервера FSRM. FCI также можно использовать со средством RMS Bulk Protection Tool, автоматически применяя защиту RMS к файлам (http://www.microsoft.com/en-us/download/details.aspx?id=9902).

Это очень краткое введение в динамический контроль доступа. Обширные дополнительные сведения, в том числе об установке, настройке и диагностике динамического контроля доступа, можно найти в документе «Understand and Troubleshoot Dynamic Access Control in Windows Server 8 Beta» (http://www.dynamic-access-control.com/whitepapers/item/understand-and-troubleshoot-dynamic-access-control-in-windows-server-8-beta.html).

Новые функции управления безопасностью в ADAC

В Server 2012 центр ADAC стал основным интерфейсом администрирования AD. По уровню административной функциональности ADAC даже превзошел своего предшественника, оснастку Active Directory Users and Computers консоли управления Microsoft. Два новшества, которые понравятся многим администраторам — графический интерфейс для восстановления удаленных объектов AD и настройка параметров детальной политики паролей fine-grained password policy (FGPP).

Корзина AD реализована в Server 2008 R2 с целью восстановления удаленных объектов AD и их атрибутов. Важный недостаток корзины AD в Server 2008 R2 — отсутствие графического интерфейса. Администраторам приходилось использовать ldp.exe или команды PowerShell. Из-за этих инструментов процесс восстановления объектов AD становится более сложным и медленным.

Как показано на экране 5, Microsoft дополнила интерфейс ADAC встроенным контейнером Deleted Objects в Server 2012. Теперь можно без труда восстановить удаленный объект пользователя с помощью ссылок Restore или Restore To в правой части ADAC. В Server 2012 на корзину AD налагаются такие же ограничения.

• Она не активна по умолчанию (ее можно включить из ADAC).
• Функциональный уровень леса AD должен быть не ниже Server 2008 R2.
• Удаленные объекты можно восстановить только в течение срока жизни удаленного объекта (DOL), который по умолчанию составляет 180 дней.

Дополнительные сведения о корзине AD приведены в руководстве «Active Directory Recycle Bin Step-by-Step Guide» (http://technet.microsoft.com/nl-BE/library/dd392261.aspx).

Второе полезное расширение графического интерфейса в ADAC относится к настройке детальной политики паролей FGPP. Компания Microsoft ввела политики FGPP в Server 2008, чтобы определить несколько политик паролей домена Windows и блокировки учетных записей, привязанных к различным группам администраторов и пользователей AD. Прежде Windows Server поддерживала только одну политику паролей домена. Для применения политик FGPP компания Microsoft ввела новый тип объекта AD, именуемый объектом параметров паролей Password Settings Object (PSO).

Как и для корзины, Microsoft не предоставила графического интерфейса для настройки политики FGPP в Server 2008. Администраторам приходилось использовать такие инструменты, как команды PowerShell, ADSI Edit или LDIFDE, чтобы определить объекты PSO. В Server 2012 можно задействовать графический интерфейс ADAC, чтобы определить новые политики FGPP и объекты PSO из контейнера Password Settings, который находится в контейнере System, как показано на экране 6. Как и раньше, для использования политик FGPP функциональный уровень домена должен быть не ниже Server 2008. Дополнительные сведения приведены в руководстве «AD DS Fine-Grained Password Policy and Account Lockout Step-by-Step Guide» (http://technet.microsoft.com/en-us/library/cc770842(v=ws.10).aspx).

Групповые управляемые учетные записи службы

Управляемые учетные записи служб Managed Service Accounts (MSA) — специальный тип учетной записи домена, поддерживаемый в Server 2008 R2 AD и более поздних версиях. Учетные записи MSA устраняют проблемы с управлением паролями, с которыми сталкиваются администраторы, назначая пользовательскую учетную запись домена для проверки подлинности службы. Администраторы предпочитают определять пользовательские учетные записи, которые позволяют лучше изолировать привилегии приложения, нежели при использовании встроенной локальной учетной записи с высокими привилегиями (то есть Local System, Local Service, Network Service) в качестве учетной записи службы. Но в отличие от этих встроенных локальных учетных записей, пользовательские учетные записи не предусматривают автоматического управления паролями. Поэтому при работе пользовательских учетных записей службы необходимо вручную управлять паролями или создать прикладное решение для управления.

Управляемые учетные записи служб MSA решают эту проблему, обеспечивая автоматическое управление паролями. Они также упрощают назначение имен участников-служб Service Principal Names (SPN) для службы. К сожалению, MSA, появившиеся в Server 2008 R2, не могут применяться службами кластеризации или службами балансировки нагрузки (то есть в веб-ферме), которые используют одну учетную запись службы и пароль. В таких случаях администраторам необходимо вручную синхронизировать пароли экземпляров служб или внедрить собственное решение для автоматизированной синхронизации паролей.

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

Позади групповых MSA на каждом контроллере домена Server 2012 выполняется новая служба, именуемая Microsoft Key Distribution Service. Эта служба гарантирует, что пароль единственной учетной записи службы, который используется экземплярами службы веб-фермы, синхронизирован между экземплярами. Чтобы воспользоваться групповыми MSA, необходимо обновить схему AD до уровня Server 2012, и требуется один или несколько контроллеров домена Server 2012, на которых работает служба Microsoft Key Distribution Service. Служба автоматически устанавливается на каждом DC, но по умолчанию запускается вручную. Вы можете создавать и администрировать групповые MSA с помощью набора команд PowerShell. Дополнительные сведения о групповых MSA приведены в документе «Getting Started with Group Managed Service Accounts» (http://technet.microsoft.com/en-us/library/jj128431).

Основные компьютеры для перенаправления папок и перемещаемые профили

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

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

В основе функции Primary Computer лежит набор новых параметров GPO и расширение схемы AD. Когда пользователь регистрируется на компьютере Windows 8 или Server 2012, алгоритм процедуры регистрации проверяет состояние управляемых GPO параметров Download roaming profiles on primary computers only («Загрузить перемещаемые профили только на основные компьютеры») и Redirect folders on primary computers only («Перенаправить папки только на основные компьютеры»). От их состояния зависит, влияет ли атрибут msDS-PrimaryComputer, связанный с объектом учетной записи пользователя AD, на решение переместить профиль пользователя или применить перенаправление папок. Новые параметры GPO находятся в контейнерах User ConfigurationPoliciesAdministrative TemplatesSystemFolder Redirection и User ConfigurationPoliciesAdministrative TemplatesSystemUser Profiles.

С помощью ADAC или команд PowerShell можно внести в атрибут msDS-PrimaryComputer объекта пользователя AD список различающихся имен DistinguishedName учетных записей компьютеров, которые следует отметить как основные компьютеры пользователя. На экране 7 показано, как использовать ADAC и его встроенный редактор атрибутов, чтобы задать атрибут msDS-PrimaryComputer для пользователя с именем Jack.

Для использования функции Primary Computer необходимо обновить схему AD до уровня Server 2012. Функция применима только к присоединенным к домену компьютерам Server 2012 и Windows 8. Чтобы получить дополнительные сведения об этой функции, рекомендую прочитать заметку в блоге группы Storage «Configuring Primary Computers for Folder Redirection and Roaming Profiles in Windows Server 8 Beta» (http://blogs.technet.com/b/filecab/archive/2012/03/30/configuring-primary-computers-for-folder-redirection-and-roaming-profiles-in-windows-server-8-beta.aspx).

Изменение модели

Динамический контроль доступа представляет собой самое крупное изменение в модели авторизации и аудита для файлов и папок Windows со времени появления AD, а может быть, даже NTFS. Динамический контроль доступа — несомненно, самое большое изменение в системе безопасности в Server 2012 и AD, не только для разработавших его инженеров Microsoft, но и для всех пользователей. Архитекторам и администраторам Windows и AD рекомендуется тщательно протестировать и изучить динамический контроль доступа, прежде чем применять его.

Кроме того, пришло время использовать ADAC и PowerShell для общих и относящихся к безопасности задач управления AD в Server 2012. Как и динамический контроль доступа, ADAC и PowerShell предназначены в основном для повышения гибкости и упрощения повседневной настройки и администрирования AD.

Поделитесь материалом с коллегами и друзьями

Источник