Tw-city.info

IT Новости
1 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Безопасность контроллера домена

Для системного администратора

Горячая десятка настроек безопасности для Active Directory

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

Создание административной учетной записи для самого себя

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

Примечание:Это означает, что вы НЕ должны использовать встроенную учетную запись администратора для администрирование Active Directory!

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

Примечание:Благодаря членству в группе администраторов домена (Domain Admins) в корневом домене (первый домен в лесу), у вас есть возможность добавления или удаления пользователей из групп администраторов схемы (Schema Admins) и корпоративных администраторов (Enterprise Admins). Поэтому нет необходимости быть членом этих групп до тех пор, пока у вас не возникнет необходимость выполнения действий, которые требуют прав такого уровня.

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

Установка сложного и длинного пароля для учетной записи администратора

Теперь, когда у вас есть учетная запись для администрирования домена, вы должны защитить встроенную учетную запись администратора по полной. Сначала нужно защитить эту учетную запись. Как минимум, вы должны сделать пароль для этой учетной записи длинным (желательно 15 – 20 символов) и сложным. Примерами таких паролей могут служить:

  • I wish I drove a Porsche 930 Turbo.
  • Pizza is best with hot Italian sausage.
  • There is no better sport than NCAA Final Four basketball.

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

Переименование учетной записи администратора в первом домене AD

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

Установка политики паролей в доменной политики по умолчанию (Default Domain Policy)

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

Здесь некоторые пояснения для настройки этих политик:

Active Directory и безопасность. Часть 1. Построение защищенных служб каталога

Архив номеров / 2014 / Выпуск №7-8 (140-141) / Active Directory и безопасность. Часть 1. Построение защищенных служб каталога

СТЕПАН МОСКАЛЕВ, инженер ИТ-систем, MCSE, MCSE:S, MCSE:M, MCITP EA, MCITP EMA, HP AIS, wsv121@mail.ru

ЛЕОНИД ШАПИРО, архитектор ИТ-систем, MVP, MCT, MCSE, MCITP:EA, MCSE:S, MCSE:M, CCEE, shapiro_leonid@yahoo.com

Active Directory и безопасность
Часть 1. Построение защищенных служб каталога

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

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

Еще в далеком 2000 году Scott Culp опубликовал статью «10 Immutable Laws of Security Administration» [1]. Ее актуальность по-прежнему очень высока, несмотря на то что с тех пор прошло уже 14 лет. К сожалению, далеко не все ИТ и ИБ-специалисты знакомы с этой важнейшей статьей, и поэтому угрозы их системам по-прежнему чрезвычайно велики.

Первым основополагающим законом ИБ, о котором рассказывается в статье, является следующий: «Никто не верит, что может произойти что-то плохое до тех пор, пока оно на самом деле не происходит» [1]. Выполняя аудит службы каталогов, мы регулярно встречались с ситуацией, когда администраторы ИТ и ИБ не уделяют должного внимания защите AD DS, будучи уверенными, что их системе ничего не угрожает, например, от «внутреннего» злоумышленника, что часто приводит к печальным последствиям.

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

Таким образом, не следует заботиться об одном из аспектов ИБ, пренебрегая другим. Подход к обеспечению ИБ должен быть комплексным, необходимо постараться учесть все особенности. Здесь как раз может помочь модель глубоко эшелонированной обороны компании Microsoft [2], которая дает возможность обеспечить декомпозицию.

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

Рисунок 1. Уровни защиты ИТ-окружения

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

На что следует обратить особое внимание, проектируя и поддерживая AD?

Здесь имеет смысл воспользоваться базовыми рекомендациями, содержащимися в руководстве Best Practices for Securing Active Directory [3]. Ниже представлен перечень мер, которые помогут значительно снизить вероятность повреждения или внесения несанкционированных изменений в базу данных Active Directory.

1) Своевременное обновление ОС и ПО позволяет уменьшить вероятность компрометации системы и осуществления несанкционированной злонамеренной деятельности внутри ИТ-инфраструктуры организации. Проводимое на регулярной основе обновление серверов и рабочих станций организации является обязательным требованием для повышения уровня безопасности службы каталога.

2) Эффективная антивирусная защита и защита от зловредного ПО позволяет существенно повысить защищенность ИТ-инфраструктуры организации в целом.

3) Регулярное резервное копирование AD обеспечивает возможность оперативно восстановить БД СК и удаленные в результате ошибочных действий администраторов объекты AD, а также службу каталога в ситуации катастрофического сбоя. Здесь, разумеется, не стоит забывать о правильном хранении резервных копий.

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

5) Безопасность контроллеров доменов (DC) обеспечивают серверы, хранящие реплику БД службы каталога AD, которые выполняют функции управления данными AD. Если доступ к контроллеру домена получает злоумышленник, то его деструктивные действия могут вывести из строя или скомпрометировать всю организацию. Обеспечение безопасности контроллеров домена – одна из наиболее важных задач службы ИБ [4].

6) Защита учетных записей привилегированных пользователей. Учетные записи администраторов сервисов и администраторов данных представляют интерес для взломщика, т.к. дают доступ к ключевым функциям системы и к объектам службы каталога. Необходимо обеспечить их безопасность и мониторинг [5]. Ошибочное включение пользователей в высокопривилегированные группы может привести к краху системы как из-за отсутствия достаточных знаний и навыков, так и в результате злонамеренных действий.

7) Использование дополнительных возможностей ОС по обеспечению безопасности. Иногда ИТ-администраторы отключают ряд систем защиты ОС или ее отдельных служб для упрощения выполнения повседневных рутинных задач. Характерные примеры – User Account Control и Windows Firewall. Не обеспечив использование более совершенных средств защиты, администратор отказывается от имеющихся под рукой и централизованно управляемых встроенных средств ОС, понижая общий уровень безопасности.

Читать еще:  Как поменять домен на почте

8) Использование принципа наименьших привилегий позволит существенно повысить уровень безопасности, уменьшая для злоумышленника область атаки.

9) Блокировка возможности развертывания и выполнения неавторизованных приложений и сервисов, очевидно, повышает безопасность системы.

10) Наличие доступа к Интернету значительно снижает безопасность всей инфраструктуры. Обеспечение безопасного доступа в Интернет и доступа из Интернета к ресурсам организации является одной из важнейших задач по повышению общего уровня безопасности системы. Более детально сводные рекомендации по построению защищенных служб каталога на основе Microsoft AD представлены в таблице 1.

Таблица 1. Сводные рекомендации по построению защищенных служб каталога на основе Microsoft Active Directory

Атаки на Active Directory. Разбираем актуальные методы повышения привилегий

Содержание статьи

Другие статьи про атаки на Active Directory

Пароли из SYSVOL и GPP

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

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

Из этого следует вывод: получение учетных данных администратора на одной из машин сделает злоумышленника админом сразу на всех. Рассмотрим два способа добиться такого результата.

Учетные данные в SYSVOL

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

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

Пример VBS-скрипта с официального сайта MSDN

Этот сценарий доступен в галерее Microsoft TechNet, из-за чего нередко используется системными администраторами, которые предпочитают готовые решения. Извлечь из него пароль не составляет никакого труда. А поскольку скрипт хранится в SYSVOL, к которому у каждого пользователя домена есть доступ для чтения, наличие пароля автоматически превращает его обладателя в локального администратора на всех сетевых машинах с виндой на борту.

Настройки групповой политики

В 2006 году инструмент PolicyMaker от Microsoft Bought Desktop Standard был переименован и выпущен вместе с Windows Server 2008 как Group Policy Preferences (GPP, «предпочтения групповой политики»). Одна из наиболее полезных функций GPP — возможность создавать локальных пользователей, настраивать и изменять их учетки, а также сохранять учетные данные в нескольких файлах сценариев:

  • карта дисков (Drives.xml);
  • источники данных (DataSources.xml);
  • конфигурация принтера (Printers.xml);
  • создание/обновление сервисов (Services.xml);
  • запланированные задачи (ScheduledTasks.xml).

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

Теперь давай посмотрим, как эта штука работает. При создании нового предпочтения групповой политики в SYSVOL генерируется связанный XML-файл с соответствующими данными конфигурации. Если в ней указан пароль пользователя, он будет зашифрован AES 256 бит. Но в 2012 году Microsoft опубликовала в MSDN ключ AES, который можно использовать для расшифровки пароля.

Ключ шифрования, представленный MSDN

Иными словами, любой авторизованный в домене юзер может найти в общем ресурсе SYSVOL файлы XML, содержащие cpassword, то есть зашифрованный пароль AES.

Пример содержимого файла Groups.xml

Быстро найти эти значения можно следующей командой:

Для расшифровки пароля можно воспользоваться инструментом Cryptool, при этом нужно в ручном режиме декодировать Base64 и указать ключ с MSDN (подробная инструкция по расшифровке приведена в статье на Хабре). Существует и полностью автоматизированное средство под названием gpp-decrypt, которое требует только значение cpassword и уже предустановлено в Kali Linux. Аналогичная утилита для Windows называется Get-GPPPassword, ее можно отыскать в наборе программ PowerSploit.

Ну а для очень ленивых есть модуль smb_enum_gpp из набора Metasploit. Этот инструмент попросит указать только учетные данные пользователей и адрес контроллера домена.

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

DNSAdmins

Microsoft не только реализовала собственный DNS-сервер, но и внедрила для него протокол управления, позволяющий интегрировать DNS-сервер с доменами Active Directory. По умолчанию контроллеры домена также являются DNS-серверами, поэтому DNS-серверы должны быть доступны каждому пользователю домена. Это, в свою очередь, открывает потенциальную возможность для атаки на контроллеры домена: с одной стороны мы имеем сам протокол DNS, а с другой — протокол управления, основанный на RPC.

Пользователь, входящий в группу DNSAdmins или имеющий права на запись в объекты DNS-сервера, может загрузить на DNS-сервер произвольную DLL с привилегиями System. Это очень опасно, поскольку многие корпоративные сети используют контроллер домена в качестве DNS-сервера.

Таким образом, для реализации атаки мы можем просто загрузить на DNS-сервер произвольную библиотеку с помощью dnscmd (путь \ops-builddll должен быть доступен для чтения DC):

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

Так как наш пользователь — член группы DNSAdmins, мы можем перезапустить службу DNS:

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

Пример PowerShell-кода в DLL

После успешного выполнения скрипта мы будем прослушивать на своем хосте обратное подключение:

Пример успешного бэкконнекта

В результате мы получим права system на DC.

Делегирование Kerberos

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

Схема взаимодействия с базой данных через веб-сервер

Исходя из этой схемы, веб-сервер должен работать с сервером базы данных от имени пользователя. Здесь и помогает делегирование — к учетным записям пользователей в среде Windows применяется флаг TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION (T2A4D) User-Account-Control .

Атрибут User-Account-Control (который не следует путать с механизмом контроля учетных записей Windows) устанавливает определенные атрибуты для учетных записей Active Directory — например, если учетная запись отключена, заблокирована или пароль пользователя никогда не истекает.

Для реализации делегирования Microsoft внедрила расширение протокола Kerberos «Служба для доступа пользователя к себе» ( S4U2Self ). Это расширение позволяет службе запрашивать токен для другого пользователя, предоставляя имя пользователя, но не вводя пароль. Когда учетная запись пользователя имеет флаг T24AD , такие токены могут быть запрошены с атрибутом forwardable, который дает службе возможность аутентифицироваться с этими токенами для других служб.

Чтобы избежать неограниченного делегирования, Microsoft гарантировала, что данные токены могут использоваться только для определенных служб, которые настроены для учетной записи пользователя через расширение «Служба для пользователя через прокси» ( S4U2proxy ). Этот параметр контролируется атрибутом msDS-AllowedToDelegateTo в учетной записи пользователя. Он содержит список имен участников службы, который указывает, на какие службы Kerberos пользователь может перенаправлять эти токены (так же, как выполняется обычное ограниченное делегирование в Kerberos). Например, ты хочешь, чтобы твоя веб-служба имела доступ к общей папке для пользователей. Тогда учетная запись службы должна иметь атрибут

Для наглядности рассмотрим схему аутентификации Kerberos.

Схема аутентификации Kerberos

  1. Пользователь аутентифицируется в веб-сервисе с использованием не Kerberos-совместимого механизма аутентификации.
  2. Веб-служба запрашивает билет для учетной записи user без указания пароля, как для учетной записи svc_web .
  3. KDC проверяет значение svc_web userAccountControl для флага TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION , а также не заблокирован ли целевой пользователь для делегирования. Если все в порядке, KDC возвращает перенаправляемый билет для учетной записи пользователя ( S4U2Self ).
  4. Затем служба передает этот билет обратно в KDC и запрашивает билет для службы cifs/fs.contoso.com .
  5. KDC проверяет поле msDS-AllowedToDelegateTo в учетной записи svc_web . Если служба указана в списке, она вернет билет службы для общей папки ( S4U2proxy ).
  6. Веб-служба теперь может проходить проверку подлинности на общем ресурсе в качестве учетной записи пользователя с использованием предоставленного билета.
Читать еще:  Настройка доменного сервера

Неограниченное делегирование

При неограниченном делегировании Kerberos на сервере, на котором размещена служба, контроллер домена DC помещает копию TGT (ticket granting ticket — билет для получения билета) пользователя в TGS (Ticket Granting Server — сервер выдачи билетов или разрешений) службы. Когда данные пользователя предоставляются серверу для доступа к службе, сервер открывает TGS и помещает TGT пользователя в LSASS (Local Security Authority Subsystem Service — сервис проверки подлинности локальной системы безопасности) для дальнейшего использования. Сервер приложений теперь может выдавать себя за этого пользователя без ограничений!

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

Обнаружить все компьютеры с неограниченным делегированием Kerberos очень просто: у них будет выставлен флаг TrustedForDelegation . Это определяется с помощью инструмента ADModule, а конкретнее — следующей команды:

Того же результата можно достигнуть, выполнив такую команду PowerView:

Теперь нужно отослать запрос MS-RPRN RpcRemoteFindFirstPrinterChangeNotification (аутентификация Kerberos) на сервер печати DC (служба Spooler). DC немедленно отправит ответ, который включает TGS (полную копию TGT) учетной записи компьютера контроллера домена, так как на нашем хосте используется неограниченное делегирование.

Чтобы это сделать, сначала поставим прослушивание входящих соединений с помощью Rubeus:

Теперь инициируем запрос с помощью SpoolSample:

В Rubeus мы увидим подключение.

Подключение Rubeus

Теперь получим TGT:

Имея TGT, мы можем выполнить DCSync-атаку с помощью mimikatz:

DCSync krbtgt

Мы добыли NTLM-хеш учетной записи krbtgt и теперь можем сделать golden ticket, с которым получим полный доступ ко всей инфраструктуре домена:

Теперь можно удаленно подключиться к контроллеру домена с учетной записью администратора:

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Безопасность компьютерных сетей. Настройка контроллера домена и управление безопасностью домена. Групповая политика безопасности домена

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

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

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

После добавления группы пользователю нажмите «Ок»

Добавлять пользователей в группу безопасности можно и по-другому. Найдите в каталоге домена нужную группу, и в ее свойствах откройте вкладку «Члены группы» и нажмите кнопку «Добавить…». Аналогичным образом введите начальные символы в строке запроса, за исключением того что вам нужно вводить уже не имя группы, а сетевое имя пользователя, например p_petrov. Кстати группа «Администраторы домена» по умолчанию входит в группу «Администраторы», и следовательно пользователям данной группы по умолчанию будут представлены все права доступа и управления. Отличие этих групп состоит в том, что группа безопасности «Администраторы» является локальной по отношению к данному домену, в отличии от группы безопасности «Администраторы домена» которая является глобальной, если у вас в сети несколько доменов объеденных в лес. После того как вы добавили себя в группу «Администраторы домена» зайдите на контроллер домена под своей учетной записью для дальнейшего управления службой каталогов.

По умолчанию в новом созданном домене есть уже одна политика безопасности которая применяется ко всему домену. Открыть для редактирования ее можно путем открытия свойств домена и перехода на вкладку «Групповая политика».

Данная политика имеет имя «Default Domain Policy» и распространяет свое действие на весь домен, все его объекты, пользователей, компьютеры, серверы. Обычно в данной групповой политике безопасности определяют такие параметры как аудит событий безопасности, политику паролей, общие права доступа пользователей и другие политики безопасности. Частные политики и настройки касающиеся отдельных процессов и задач решаемых пользователями создаются отдельными групповыми политиками и применяются для отдельных организационных юнитов и даже для отдельных групп пользователей, но об этом по порядку.

Для редактирования данной политики нажмите на данной вкладке кнопку «Изменить». При этом откроется оснастка редактора объекта групповой политики.

Любая групповая политика имеет два раздела — «Конфигурация компьютера» и «Конфигурация пользователя». Отличаются они, кроме составом параметров, еще и тем что политики «Настройка компьютера» применяется к настройкам связанным с настройкой операционной системы и применяется при загрузке операционной системы на компьютере добавленному в домен, еще до момента ввода пользователем пароля и логина. Групповая политика пользователя применяется к настройкам пользователя после прохождения им аутентификации в сети. Таким образом для разных пользователей, даже работающих на одном компьютере могут быть централизовано настроены разные политики. При создании частных политик безопасности для отдельных организационных юнитов в групповой политике компьютера можно, например, определить к каким папкам на компьютере будут иметь доступ пользователи, к какому центру обновлений операционной системы будет подключен данный компьютер, какие программы должны стоять на данном компьютере, и т.п. В групповой политике пользователя обычно настраивают параметры обозревателя Internet Explorer, параметры рабочего стола, разграничивать доступ пользователей к различным ресурсам операционной системы и т.п. Также с помощью групповой политики можно удаленно запускать на компьютере пользователя в момент загрузки операционной системы и аутентификации пользователей различные Java и VB скрипты. Обо всех данных настройках я буду рассказывать в своих последующих статьях, а сейчас давайте рассмотрим поподробней что можно сделать с групповой политикой домена «Default Domain Policy».

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

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

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

Читать еще:  Понижение контроллера домена 2020

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

В «Параметрах безопасности» можно настроит общие параметры безопасности компьютера, например, переименовать и отключить системные учетные записи.

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

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

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

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

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

Это разграничение доступа можно изменить, а именно применение групповой политики безопасности можно ограничить группой компьютеров или группой пользователей. Редактирование политики (запись) по умолчанию разрешено только администраторам. Это правило тоже можно изменить, назначить какого-то отдельно выделенного сотрудника и предоставить ему доступ на запись групповой политики.

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

Служба каталогов Active Directory

Настройка параметров безопасности (Шаблоны безопасности, Анализ и настройка безопасности)

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

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

  1. Сначала откроем чистую консоль mmc .

Кнопка » Пуск » — » Выполнить » — mmc — кнопка » ОК «.

Меню » Консоль » — » Добавить или удалить оснастку » — кнопка » Добавить » — выбрать оснастку » Анализ и настройка безопасности » — кнопка » Добавить » — выбрать оснастку » Шаблоны безопасности » — кнопка » Добавить » — кнопка » Закрыть » — кнопка » ОК » (рис. 6.57).

В полученной консоли (ее можно будет сохранить и использовать в дальнейшем неоднократно) можно делать следующее:

  • изучить параметры стандартных шаблонов безопасности (оснастка «Шаблоны безопасности») и даже попробовать сконструировать собственные шаблоны на основе стандартных (можно сохранить какой-либо шаблон с другим именем и изменить какие-либо параметры шаблона);
  • провести анализ (сравнение) текущих параметров безопасности сервера (оснастка » Анализ и настройка безопасности «).

Приведем краткие характеристики стандартных шаблонов безопасности:

  • DC security — используемые по умолчанию параметры безопасности контроллера домена;
  • securedc — защищенный контроллер домена (более высокие требования к безопасности по сравнению с шаблоном DC security, отключается использование метода аутентификации LanManager );
  • hisecdc — контроллер домена с высоким уровнем защиты (более высокие требования к безопасности по сравнению с шаблоном securedc, отключается метод аутентификации NTLM, включается требование цифровой подписи пакетов SMB);
  • compatws — совместимая рабочая станция или совместимый сервер (ослабляет используемые по умолчанию разрешения доступа группы «Пользователи» к реестру и к системным файлам для того, чтобы приложения, не сертифицированные для использования в данной системе, могли работать в ней);
  • securews — защищенная рабочая станция или защищенный сервер (аналогичен шаблону securedc, но предназначен для применения к рабочим станциям и простым серверам);
  • hisecws — рабочая станция или защищенный сервер с высоким уровнем защиты (аналогичен шаблону hisecdc, но предназначен для применения к рабочим станциям и простым серверам);
  • setup security — первоначальные настройки по умолчанию (параметры, устанавливаемые во время инсталляции системы);
  • rootsec — установка стандартных (назначаемых во время инсталляции системы) NTFS-разрешений для папки, в которую установлена операционная система;

Теперь на примере рассмотрим, как проводить анализ настроек безопасности.

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

Щелкнем правой кнопкой мыши на значке оснастки » Анализ и настройка безопасности «, выберем » Открыть базу данных «, укажем путь и название БД (по умолчанию БД создается в папках профиля того администратора, который проводит анализ), нажмем кнопку » Открыть «, выберем нужный нам шаблон (например, hisecdc ) и нажмем » ОК » (рис. 6.58):

  1. Выполним анализ настроек безопасности.

Щелкнем правой кнопкой мыши на значке оснастки » Анализ и настройка безопасности «, выберем » Анализ компьютера «, укажем путь и название файла с журналом ошибок (т.е. протоколом проведения анализа), нажмем «ОК», будет выполнено сравнение текущих настроек с параметрами шаблона (рис. 6.59):

  1. Теперь можно провести уже настоящий анализ настроек безопасности.

Откроем любой раздел оснастки (например, » Политики паролей «, рис. 6.60):

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

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

Этой же оснасткой можно одним действием привести настройки нашего компьютера в соответствии с параметрами шаблона (щелкнуть правой кнопкой мыши на значке оснастки » Анализ и настройка безопасности «, выбрать » Настроить компьютер «). Не рекомендуем это делать, не изучив в деталях, какие последствия это может повлечь для всей сети. Высокие требования к параметрам безопасности препятствуют работе в домене Active Directory компьютеров с системами Windows 95/98/ME/NT. Например, данные системы поддерживают уровень аутентификации NTLM версии 2 (который назначается шаблонами hisecdc и hisecws ) только при проведении определенных настроек на компьютерах со старыми системами. Поэтому, прежде чем принимать решение об установке более высоких параметров безопасности в сети, необходимо тщательно изучить состав сети, какие требования к серверам и рабочим станциям предъявляют те или иные шаблоны безопасности, предварительно установить нужные обновления и настроить нужные параметры на «старых» системах и только после этого применять к серверам и рабочим станциям Windows 2000/XP/2003 шаблоны с высокими уровнями сетевой безопасности.

Заметим дополнительно, что данные оснастки имеются не только на серверах, но и на рабочих станциях под управлением Windows 2000/XP Professional, и они позволяют производить аналогичный анализ и настройки на рабочих местах пользователей.

Резюме

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

  • домен;
  • дерево;
  • лес;
  • организационное подразделение.

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

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

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

Задачи сетевого администратора при управлении инфраструктурой службы каталогов:

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