Управление одним доменом из множества ограничение прав – [конспект админа] Меньше администраторов всем / Сервер Молл corporate blog / Habr

[конспект админа] Меньше администраторов всем / Сервер Молл corporate blog / Habr

Продолжим про безопасность операционных систем – на этот раз «жертвой» станет MS Windows и принцип предоставления минимальных прав для задач системного администрирования.

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

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

Инцидент добавил седых волос, но второй контроллер домена спас ситуацию: роли FSMO перевели на него, а путешественника во времени повторно сделали контроллером домена. С тех пор в компании права «администратора домена» нужно заслужить.

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

Когда компьютеров немного, включить доменную группу безопасности «helpdesk» в локальную группу «администраторы» можно и руками. А вот на большом объеме приходят на помощь групповые политики. Удобных способов два.

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

Расположение политик Restricted groups.

Далее нужно создать группу «Администраторы» и добавить в нее нужную группу. Есть только один нюанс – если сделать именно так, то из локальной группы «Администраторы» исчезнут все, кроме встроенного администратора и самой группы. Даже Domain Admins:

Добавляем группу «Администраторы», в которую добавляем группу helpdesk.

И получаем локальную группу «Администраторы» без Domain admins.

Конечно, эту возможность можно использовать и во благо – зачистить локальные группы от лишних участников. Если же хочется избежать такой зачистки, то можно создать в «Группах ограниченного доступа» доменную группу и ее же назначить входящей в группу «Администраторы»:

При такой настройке локальная группа «Администраторы» не будет зачищена.

Вторым способом является настройка Предпочтения Групповых Политик (Group Policy Preference, далее – GPP). Искать следует в Конфигурации компьютера – Настройка – Локальные пользователи и группы.

Настройка группы безопасности через GPP.

Как и все настройки в GPP, эта проще в понимании и с более дружелюбным интерфейсом. Но если у вас в инфраструктуре присутствуют не обновленные Windows XP или даже Windows 2000, то остается только первый вариант.

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

Конечно, сотрудников отдела IT и системные учетные записи (например, под которыми выполняются задачи резервного копирования) проще сразу включить в группу «Enterprise Admins» и не знать горя.

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

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

Группа	Описание
Администраторы	Полные права на систему.
Пользователи	Возможность пользоваться без изменения системных параметров и без записи в системные разделы. Фактически пользователь – полноценный хозяин только в папке своего профиля.
Операторы архива	Группа, предназначенная для выполнения резервного копирования и восстановления. Участники группы могут завершать работу системы на серверах и переопределять права доступа в целях резервного копирования.
Опытные пользователи	Участники этой группы могут администрировать локальные учетные записи и группы (кроме администраторов), создавать сетевые ресурсы и управлять доступом на них, менять NTFS ACL (кроме смены владельца папки).
Пользователи удаленного рабочего стола	Членство дает возможность подключаться к компьютеру по RDP
Операторы печати	Операторы могут устанавливать и удалять принтеры, изменять их драйвера и настройки, останавливать и чистить очередь печати.
Операторы настройки сети	Могут менять настройки сетевых интерфейсов. Это полезная группа на случай если нужно переназначать получение адреса сетевой картой с автоматического на статическое. Мобильные пользователи скажут спасибо, если добавить их в эту группу.
Операторы учета	Пользователи в этой группе могут создавать/удалять/редактировать/перемещать учетные записи в Active Directory. Удобно дать эти права для сервиса, автоматически заводящего учетки сотрудников после приема на работу.

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

Если стандартных групп не хватает, то Windows позволяет настроить права доступа более тонко. Например, выдать отдельной группе пользователей право менять время или возможность принудительно завершать работу сервера по сети. Для этого существует механизм «назначение прав пользователей». Искать можно в локальной политике безопасности –

secpol.msc или в групповой политике по адресу Конфигурация компьютера – Конфигурация Windows – Параметры безопасности – Локальные политики – Назначение прав пользователя.

Настройка прав доступа через групповые политики.

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

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

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

Все эти технологии довольно давно существуют в системах Windows. С появлением Windows 10\2016 появилась еще одна интересная возможность ограничить учетные записи – речь о ней пойдет далее.

Just Enough Administration (JEA) – технология предоставления доступа к командлетам PowerShell. Работает на операционных системах вплоть до Windows 7 при установке Windows Management Framework 5.1 (правда, в самых старых операционных системах поддержка ограничена). Работа производится через так называемые «виртуальные аккаунты» и специально подготовленные файлы конфигурации. Примером использования JEA является выдача ограниченных прав на управление определенными виртуальными машинами – например, для ваших разработчиков.

Подробнее про JEA можно почитать в официальной документации, поэтому разберем конкретный пример предоставления возможности перезапуска виртуальной машины.

Сначала нам нужно разрешить удаленное подключение к серверу с помощью командлета Enable-PSRemoting, а заодно убедимся, что у нас Windows Management Framework нужной версии при помощи командлета $PSVersionTable.PSVersion.

Проверка версии и разрешение удаленных подключений при помощи PS.

Создадим группу безопасности и специального пользователя:

$VMOperatorGroup = New-ADGroup -Name "VM-operators" -GroupScope DomainLocal -PassThru
$OperatorUser = New-ADUser -Name "VMOperator" -AccountPassword (ConvertTo-SecureString 'P@ssword1' -AsPlainText -Force) -PassThru
Enable-ADAccount -Identity $OperatorUser
Add-ADGroupMember -Identity $VMOperatorGroup -Members $OperatorUser
 

Теперь создадим нужные для работы конфигурационные файлы и папки. Сначала общие:

New-Item -Path "C:\Program Files\WindowsPowerShell\Modules\Demo_Module" -ItemType Directory
New-ModuleManifest -Path "C:\Program Files\WindowsPowerShell\Modules\Demo_Module\Demo_Module.psd1"
New-Item -Path "C:\Program Files\WindowsPowerShell\Modules\Demo_Module\RoleCapabilities" -ItemType Directory

А затем создадим конкретный файл конфигурации для нашего оператора виртуальной машины с именем win. Для примера разрешим запуск и остановку виртуальной машины:

$VMRoleCapabilityParams = @{
  Author = 'Сервер Молл'
  Description = 'VM Role Capability File'
  CompanyName = 'ServerMall'
VisibleCmdlets= 'Get-VM',
 @{ Name='Start-VM'; Parameters=@{ Name='Name'; ValidateSet='win' } },
 @{ Name = 'Stop-VM'; Parameters = @{ Name = 'Name'; ValidateSet = 'win'}}
New-PSRoleCapabilityFile -Path "$ENV:ProgramFiles\WindowsPowerShell\Modules\Demo_Module\RoleCapabilities\VMRoleCapability.psrc" @VMRoleCapabilityParams 

Теперь необходимо подготовить файл сессии PowerShell:

$NonAdministrator = "DOMAIN\VM-win-Operators"

$ConfParams = @{
  SessionType = 'RestrictedRemoteServer'
  RunAsVirtualAccount = $true
  RoleDefinitions = @{
    $NonAdministrator = @{ RoleCapabilities = 'VMRoleCapability'}
  }
  TranscriptDirectory = "$env:ProgramData\JEAConfiguration\Transcripts"
}

New-Item -Path "$env:ProgramData\JEAConfiguration" -ItemType Directory
$SessionName = 'VM_OperatorSession'
New-PSSessionConfigurationFile -Path "$env:ProgramData\JEAConfiguration\VM.pssc" @ConfParams

Зарегистрируем файл сессии:

Register-PSSessionConfiguration -Name 'VM_OperatorSession' -Path "$env:ProgramData\JEAConfiguration\VM.pssc"

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

Enter-PSSession -ComputerName SERVERNAME -ConfigurationName VM_OperatorSession -Credential (Get-Credential)

Проверим список доступных команд командой get-command и попробуем остановить нашу виртуальную машину win, а затем другую машину win2.

Доступ к серверу ограничен управлением одной виртуальной машиной.

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

Интерфейс JEA Toolkit Helper.

При необходимости есть возможность через групповые политики включить аудит выполнения модулей по адресу Конфигурация компьютера – Административные шаблоны – Windows Powershell – Включить ведение журнала модулей. Тогда в журнале Windows будут отображаться записи о том что, где и когда.

Журнал выполнения PowerShell.

Альтернативой будет включение записи в файл. Также через групповые политики настраивается параметр «Включить транскрипции PowerShell». Путь можно задать как в самой политике (и тогда запись туда будет вестись для всех модулей), так и в файле конфигурации сессии JEA в параметре TranscriptDirectory.

Файловый журнал JEA.

С помощью делегирования, назначения прав и JEA можно добиться отказа от использования учетных записей с администраторскими правами в повседневной работе. В конце-концов, к UAC в Windows ведь тоже привыкли и не отключаем просто потому, что «заткнись, я и так знаю что мне делать со своими файлами!».

habr.com

Делегирование административных задач в Active Directory / Habr

Ввиду того, что во время Хабравстречи я рассказывал об 11 различных сценариях, естественно, мне хотелось бы на каждом из этих моментов остановиться подробнее. Другими словами, начиная с этой статьи я рассмотрю большинство моментов, о которых шла речь во время предыдущего доклада. Итак…
Относительно недавно мне в Windows Live Messenger задали несколько вопросов, связанных с делегированием административных полномочий в Active Directory. Однако, прежде чем переходить к самим вопросам по этой теме, я буквально в двух словах расскажу, что же собой представляет делегирование и для чего оно нужно.

Делегирование объектов Active Directory

Более чем очевидно, что практически в каждой организации ИТ-подразделение включает в себя нескольких администраторов, и различные административные задачи должны быть распределены среди администраторов, либо, скажем, среди членов службы поддержки. Например, как в данном примере, скажем сотрудники подразделения поддержки должны вносить компьютеры в домен. Однако такая группа пользователей не должна иметь возможности выполнять остальные операции, помимо тех, которые вы хотите им разрешить.
А вот те разрешения, которые можно назначать пользователям, группам или компьютерам, иначе говоря принципалам безопасности, называются записями контроля доступа (Access Control Entry, ACE). Следовательно, с помощью ACL модифицируются разрешения доступа для объекта. Списки ACL вы можете просматривать непосредственно при помощи таких оснасток как «Active Directory – пользователи и компьютеры», «Центр администрирования Active Directory», а также в таких оснастках и средствах как «Active Directory – Сайты и службы», «Редактор ADSI», а также «LDP» (некоторые средства будут подробнее рассмотрены далее в данной статье). Если же говорить о разрешениях контроля доступа к объектам AD, то сразу следует отметить, что они разделены на стандартные разрешения и на особые разрешения. Особые разрешения представляют собой гранулированные опции, которые применяются к конкретному объекту, а стандартные разрешения доступа уже составляются из набора особых разрешений, которые разрешают, либо, наоборот, запрещают определенную функцию. Исключительно в качестве примера можно выделить такое стандартное разрешение как чтение, ведь на самом деле оно включает в себя записи таких особых разрешений как чтение разрешений, список содержимого, а также прочитать все свойства. Но это уже совсем другая тема.
Собственно, все записи ACE располагаются в дискреционном списке контроля доступа, иначе говоря, в оригинале это звучит как Discretionary Access Control List, или же, проще говоря, в списке DACL. Это список записей управления доступом, определяющий разрешения доступа для каждого принципала безопасности к объекту. В свою очередь, каждый принципал безопасности, который добавляется в объект, получает список разрешений, в котором указано, что конкретный пользователь либо группа пользователей может выполнять конкретные операции с самим объектом. Здесь всегда следует помнить то, что записи ACE, которые были назначены явным образом, всегда будут оцениваться перед унаследованными записями ACE. А также всегда следует учитывать то, что запрещающие записи всегда будут превалировать над разрешающими.
Сам по себе список DACL является составляющей списка ACL самого объекта, который еще содержит системный список контроля доступа, другими словами System Access Control List, SACL. Этот список определяет параметры аудита для объекта, включая все принципалы безопасности и операции, для которых должен выполняться аудит.
Таким образом, возвращаясь к самой теме данного раздела, делегированием административных задач называется наследование разрешений родительского объекта для принципала безопасности, созданного в Active Directory.

Пример делегирование административных полномочий

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

1. Для начала следует на контроллере домена открыть оснастку «Active Directory – пользователи и компьютеры». Здесь необходимо создать глобальную группу безопасности, члены которой смогут присоединять компьютеры пользователей к домену. Другими словами, эта группа будет выглядеть следующим образом:

   
   Рис. 1. Свойства группы, отвечающей за присоединение компьютеров к домену

2. Следующим делом необходимо указать, что компьютеры присоединять к домену могут только лишь пользователи, входящие в созданную на предыдущем этапе глобальную группу безопасности. Для этого следует открыть оснастку «Управление групповой политикой» и перейти к редактору GPME для созданного по умолчанию объекта GPO «Default Domain Controllers Policy», который располагается в подразделении «Domain Controllers».
   В отобразившейся оснастке следует перейти к узлу «Конфигурация компьютера\Политики\Конфигурация Windows\Параметры безопасности\Локальные политики\Назначение прав пользователей» и локализовать параметр политики, который называется «Добавление рабочих станций к домену». Открыв диалоговое окно данного параметра политики, вы сразу сможете обнаружить, что по умолчанию там указана группа «Прошедшие проверку», благодаря которой присоединять компьютеры к домену может каждый пользователь. Теперь, для того, чтобы разрешить присоединять к домену компьютеры только пользователям из группы безопасности «Поддержка», следует удалить группу, указанную в этом параметре политики по умолчанию, а затем при помощи кнопки «Добавить пользователя или группу» и диалога поиска объектов Active Directory, следует добавить созданную ранее глобальную группу безопасности. Процесс добавления такой группы изображен на следующей иллюстрации:

   
   Рис. 2. Изменение группы, отвечающей за присоединение компьютеров к домену

3. Теперь несмотря на то, что немного ранее было описано, в каких сценариях выполняется делегирование, и что в большинстве случаев делегирование выполняется на уровне подразделений, в данном случае для предоставления возможности присоединения компьютеров к домену, нам следует в оснастке «Active Directory – пользователи и компьютеры» вызвать мастер делегирования непосредственно для уровня всего домена. Следовательно, в оснастке «Active Directory – пользователи и компьютеры» необходимо в области дерева самой оснастки вызвать контекстное меню для домена и выбрать опцию «Делегирование управления», как показано ниже:

   
   Рис. 3. Вызов мастера делегирования управления

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

   
   Рис. 4. Добавление группы, для которой выполняется делегирование управления
   После того, как группа будет добавлена, для перехода к следующей странице мастера следует нажать на кнопку «Далее».

5. Страница «Делегируемые задачи» позволяет вам определить конкретные операции, которые должны выполнять в доменных службах Active Directory пользователи или группы пользователей, которые были добавлены на предыдущей странице мастера. Так как в данном примере делегируется задача присоединения компьютеров к домену и такую задачу можно найти в предоставленном списке распространенных задач, следует напротив задачи «Присоединение компьютера к домену» установить флажок и нажать на кнопку «Далее». Стоит обратить внимание на то, что данный мастер позволяет делегировать не только те задачи, которые фигурируют в данном списке, и в том случае, если вы не смогли здесь сразу найти конкретную задачу, нужно будет создавать особую задачу для делегирования. Создание особой задачи будет показано далее в этой статье, а делегирование задачи присоединения компьютера к домену изображено на следующей иллюстрации:

   
   Рис. 5. Делегирование задачи присоединения компьютеров к домену для членов группы «Поддержка»

6. На последней странице мастер повторно проинформирует о том, что работа мастера была успешно выполнена и определенной группе пользователей было передано управление для присоединения компьютеров к домену, что, собственно, и являлось поставленной перед нами задачей:

   
   Рис. 6. Завершение процесса делегирования управления

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

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

Сразу после того, как была предоставлена возможность присоединения компьютеров к домену определенной группе безопасности, возник вопрос такого характера: «Можно ли как-то просмотреть делегированные ранее задачи»? Здесь ответ простой: просмотреть можно, причем далеко не единственным методом. Все возможные варианты просмотра задач, для которых было передано делегирование, в рамках одной статьи рассматривать просто бессмысленно, поэтому далее в данной статье будут представлены несколько основных вариантов:

1. Первый метод – это использование оснастки «Active Directory – пользователи и компьютеры». Прежде всего, для того чтобы просмотреть задачи, которые были делегированы, следует в меню «Вид» включить для самой оснастки отображение дополнительных компонентов. После этого необходимо перейти к диалоговому окну свойств подразделения, для которого выполнялось делегирование. Так как в предыдущем разделе выполнялось делегирование для уровня всего домена, в данном примере открывается диалоговое окно свойств домена.
   В отобразившемся диалоговом окне следует перейти на вкладку «Безопасность», а затем оттуда вызвать диалоговое окно дополнительных параметров безопасности. Здесь, в отобразившемся диалоговом окне, вы можете обнаружить все записи ACE, которые были заданы как по умолчанию, так и при помощи мастера делегирования. Например, на следующей иллюстрации видно, что для группы «Поддержка» было добавлено разрешение, позволяющее создавать объекты «Компьютер»:

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

2. Теперь рассмотрим более изощренный метод, а именно использование LDP.exe. На этот раз следует выполнить следующие действия:
   Откройте инструмент LDP и при помощи меню «Подключение» подключитесь к контроллеру домена по порту 389, как показано на следующей иллюстрации:

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

   
   Рис. 9. Выполнение привязки
   Теперь можно подключиться к необходимому подразделению или же сразу ко всему домену, выбрав команду «Дерево» из меню «Вид». В том случае, если следует просмотреть весь домен, можно оставить поле пустым, однако если вы планируете просматривать конкретное подразделение, следует указывать различающееся имя в следующем формате: «OU=имя OU, DN=domain…».
   Затем для того, чтобы увидеть, кому было предоставлено делегирование, следует просмотреть всю структуру в древовидном представлении. Другими словами, из меню «Вид» выбираем команду «Дерево» и в отобразившемся диалоговом окне «Дерево» указываем базовое расширяемое имя (либо, так как в приведенном примере необходимо просмотреть весь домен, можно оставить данное текстовое поле пустым).
   Уже находясь в привычной области дерева, необходимо выбрать подразделение, предоставление прав к которому следует проверить, а затем из контекстного меню выбрать команду «Дополнительно» и «Дескриптор безопасности». В отобразившемся диалоговом окне обязательно удостоверьтесь в том, что у вас выбран правильный DN, а также в том, что установлен флажок на опции «Список ACL», как показано на следующей иллюстрации:

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

   
   Рис. 11. Просмотр и изменение делегируемых разрешений для группы поддержки

3. Третий вариант в какой-то степени можно назвать более модернистическим, так как сейчас мы определим, какие разрешения были назначены этой же группе поддержки, но уже при помощи оснастки «Центр администрирования Active Directory». Для этого следует открыть данное средство, выбрать в дереве оснастки подразделение, для которого следует просмотреть, кому было предоставлено делегирование, а затем перейти к свойствам выбранного объекта, например, как показано на следующей иллюстрации, непосредственно из контекстного меню:

   
   Рис. 12. Переход к свойствам выбранного объекта
   После работы с оснасткой «Active Directory – пользователи и компьютеры» вы сможете сразу определиться, что нужно сделать. В отобразившемся диалоговом окне следует перейти к группе «Разрешения», и просто останется лишь выбрать требуемую группу и перейти к диалогу дополнительных параметров безопасности. Группа разрешений отображена ниже:

   
   Рис. 13. Разрешения группы безопасности поддержки

4. Если вы любитель командной строки, то вас никто не ограничивает. Для просмотра разрешений, позволяющих контролировать действия пользователей в Active Directory, предусмотрена такая утилита командной строки как DSACLS. Зачастую данная команда выполняется с отличительным именем объекта. Например, для того, чтобы узнать, у кого есть разрешения ко всему домену, следует выполнить команду:
   DSACLS DC=331zone,DC=com
   Результат выполнения команды виден на следующей иллюстрации:

   
   Рис. 14. Проверка разрешений для группы поддержки средствами командной строки

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

Разрешения перемещения объектов между подразделениями

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

Рис. 15. Страница создания особой задачи для делегирования
После этого, на следующей странице мастера, странице «Разрешения» — следует указать, что делегируется разрешение «Запись», и этого будет достаточно.
Так как задачу по перемещению можно разделить на две части – удаление объекта из контейнера «Computers» и последующее создание объекта в другом подразделении – исключительно в качестве примера, создание объектов в специально созданном подразделении для учетных записей компьютеров будет продемонстрировано средствами изменения дополнительных параметров безопасности для требуемого подразделения (подобные действия были рассмотрены в предыдущем разделе).
Сейчас, в том случае, если вы закрывали оснастку «Active Directory – пользователи и компьютеры», нужно включить для нее отображение дополнительных компонентов, а затем перейти к диалоговому окну свойств подразделения, в которое должны перемещаться учетные записи компьютеров. В моем случае это подразделение «Клиенты».
В диалоговом окне свойств данного подразделения следует перейти ко вкладке «Безопасность», а затем открыть диалоговое окно дополнительных параметров безопасности. В отобразившемся диалоговом окне следует локализовать добавленную ранее группу и удостовериться, что сотрудникам группы поддержки разрешается присоединять компьютеры к домену, но разрешения, связанные с удалением объектов, здесь отсутствуют, а затем перейти к диалогу изменения разрешений посредством нажатия на кнопку «Добавить».
В отобразившемся диалоговом окне «Элемент разрешения для Computers» необходимо добавить группу, которой будут применяться разрешения. Другими словами, нажмите на ссылку «Выберите субъект» и при помощи соответствующего диалогового окна локализуйте группу «Поддержка». Так как внутри созданного ранее подразделения могут находиться дочерние подразделения с различной разбивкой (например, компьютеров по отделам), из раскрывающегося списка «Применяется к» следует выбрать опцию «Этот объект и все дочерние объекты», что и установлено по умолчанию.
Осталось только выбрать требуемое разрешение. Так как нам нужно разрешить перемещать компьютеры, а это означает, что объекты будут создаваться внутри данного и всех вложенных контейнеров, следует установить флажок напротив разрешения «Создание объектов: Компьютер», после чего сохранить все внесенные изменения. Диалоговое окно «Элемент разрешения для «Клиенты»» показано ниже:

Рис. 16. Добавление разрешений для создания объектов компьютеров

Вместо заключения

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

habr.com

Немного о том, как не надо защищать учетные записи в Active Directory / Habr

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

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

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

К сожалению, у этого способа есть один недостаток — если злоумышленник получил доступ к списку учетных записей, он сможет заблокировать их все. Здесь, в частности, следует помнить об одной вещи — любая учетная запись в домене AD может отправлять запросы к службе каталогов и по умолчанию имеет права на чтение практически всех её разделов. На практике это значит, что, если злоумышленник узнает логин-пароль хотя бы одного пользователя, он с помощью простого LDAP-запроса сможет получить список ВСЕХ (да, совсем всех) учетных записей в домене. И, если у вас включена политика блокировки учеток, он сможет все их заблокировать. Представьте себе последствия и попробуйте придумать, что вы будете делать, если вас постигнет подобная участь.

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

Как можно не выстрелить себе в ногу? Например, задуматься над вопросом, а нужна ли вам вообще блокировка записей, и не лучше ли будет отслеживать неудачные попытки входа сами по себе, благо даже штатными средствами Windows можно повесить алерты на попавшие в Event Log события и обрабатывать эти события так, как вам нужно (а не просто путем «три неудачные попытки — выстрел»). При этом, однако, стоить помнить, что учетка может авторизоваться на любом контроллере домена в сети, и каждый КД надо мониторить отдельно. Можно вспомнить, что в более-менее современных версиях Windows политик безопасности может быть несколько. Следовательно, можно более аккуратно подойти к вопросу, какие учетки блокировать, а какие — нет. В-третьих, можно даже заняться вопросом, которым обычный администратор Windows никогда не занимается, а именно ограничением данных пользователю по умолчанию прав в AD (замечу, что это может иметь смысл и вне контекста защиты именно учеток).

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

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

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

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

Подводя некоторые итоги:

1. Не следует относиться даже к базовым моментам ИБ как к «простому» вопросу. Думайте, и думайте хорошо, особенно если вы — новичок.
2. Иллюзия защищенности, которую может создать следование не слишком хорошо продуманным советам — хуже, чем понимание, что у тебя есть проблема и недостаточно знаний для решения.
3. Если вы хотите писать статью на тему, а не просто делитесь личным опытом в стиле «я сделал так, что вы об этом думаете?» — пожалуйста, как следует изучите тему, по которой пишете. Некомпетентности в мире и так более чем достаточно, не стоит её приумножать, попутно рискуя создать большие проблемы тем, кому вы, по идее, хотите помочь.

habr.com

Права и привилегии встроенных групп в Active Directory

Привилегия	Описание	Значение по умолчанию
Функционирование в виде части операционной системы	Позволяет процессу олицетворять любого пользователя без проверки подлинности. Таким образом, процесс может получить доступ к тем же локальным ресурсам, что и пользователь.Процессы, требующие эту привилегию, вместо использования отдельной учетной записи пользователя со специально назначенной привилегией должны применять учетную запись «Локальная система», которая уже содержит эту привилегию. Эта привилегия назначается пользователям, только если на серверах организации запущены Windows 2000 или Windows NT 4.0 и используются приложения с паролями в виде обычного текста.	«Локальная система»
Добавление рабочих станций в домен	Определяет группы или пользователей, которые могут добавлять рабочие станции в домен.Это право пользователя используется только для контроллеров доменов. По умолчанию это право имеет любой прошедший проверки подлинности пользователь; он также может создавать до 10 учетных записей компьютера в домене. Благодаря добавлению учетной записи в домен, компьютер распознает учетные записи и группы, существующие в доменной службе Active Directory (AD DS).	Контроллеры домена. «Прошедшие проверку»
Настройка квот памяти для процесса	Определяет пользователей, которые могут изменять максимальный объем памяти, используемый процессом.Это право пользователя определено в объекте групповой политики «Контроллер домена по умолчанию» и локальной политике безопасности рабочих станций и серверов.	«Администраторы»
Архивирование файлов и каталогов	Определяет пользователей, которые могут обойти разрешения на файлы, каталоги, реестр и другие постоянные объекты при резервном копировании системы.	«Администраторы» и «Операторы архива»
Обход перекрестной проверки	Определяет, какие пользователи могут производить обзор деревьев каталога, даже если у этих пользователей отсутствуют разрешения на каталог. Эта привилегия не позволяет пользователям просматривать содержимое каталога, а позволяет только выполнять обзор.Это право пользователя определено в объекте групповой политики «Контроллер домена по умолчанию» и локальной политике безопасности рабочих станций и серверов.	Рабочие станции и серверы. «Администраторы», «Операторы архива», «Опытные пользователи», «Пользователи», «Все»Контроллеры домена. «Администраторы» и «Прошедшие проверку»
Изменение системного времени	Определяет пользователей и группы, которые могут изменять время и дату на внутренних часах компьютера. Пользователи, имеющие данное право, могут изменять внешний вид журналов событий. При изменении системного времени регистрируемые события будут отображать новое время, а не фактическое время возникновения события.Это право пользователя определено в объекте групповой политики «Контроллер домена по умолчанию» и локальной политике безопасности рабочих станций и серверов.	Рабочие станции и серверы. «Администраторы« и «Опытные пользователи»Контроллеры домена. «Администраторы» и «Операторы сервера»
Создание файла подкачки	Позволяет создавать файл подкачки и изменять его размер. Для этого в группе Параметры быстродействия на вкладке Дополнительно диалогового окнаСвойства системы следует указать размер файла подкачки для определенного диска.	«Администраторы»
Создание объекта типа токен	Позволяет процессу создавать токен, который затем может использоваться для доступа к любому локальному ресурсу при применении NtCreateToken() или других API, создающих токен.Процессы, требующие эту учетную запись, вместо использования отдельной учетной записи пользователя со специально назначенной привилегией должны применять учетную запись «Локальная система», которая уже содержит эту привилегию.	Нет
Создание глобальных объектов	Определяет учетные записи, которые могут создавать глобальные объекты в сеансе служб терминалов или служб удаленного рабочего стола.	«Администраторы» и «Локальная система»
Создание постоянных общих объектов	Позволяет процессу создавать объект каталога в диспетчере объектов операционной системы. Эта привилегия полезна для работающих в режиме ядра компонентов, расширяющих пространство имен объекта. Компоненты, работающие в режиме ядра, уже имеют эту привилегию, поэтому назначать ее не нужно.	Нет
Отладка программ	Определяет пользователей, которые могут прикреплять отладчик к любому процессу или ядру. Разработчикам, выполняющим отладку собственных приложений, это право назначать не нужно. Это право следует назначить разработчикам, выполняющим отладку новых системных компонентов. Это право предоставляет полный доступ к важным компонентам операционной системы.	«Администраторы» и «Локальная система»
Разрешение доверия к учетным записям компьютеров и пользователей при делегировании	Определяет пользователей, которые могут устанавливать параметр Делегирование разрешено в объекте пользователя или компьютера.Пользователь или объект, получившие это право, должны иметь доступ на запись к управляющим флагам учетной записи объекта пользователя или компьютера. Серверный процесс, выполняемый на компьютере (или в пользовательском контексте), которому разрешено делегирование, может получить доступ к ресурсам другого компьютера, используя делегированные учетные данные клиента, пока в учетной записи клиента не будет установлен управляющий флаг Учетная запись не может быть делегирована. Это право пользователя определено в объекте групповой политики «Контроллер домена по умолчанию» и локальной политике безопасности рабочих станций и серверов.	Контроллеры домена. «Администраторы»
Принудительное удаленное завершение работы	Определяет, кому из пользователей разрешено удаленное завершение работы компьютера. Неправильное применение этого права пользователя может стать причиной отказа в обслуживании.Это право пользователя определено в объекте групповой политики «Контроллер домена по умолчанию» и локальной политике безопасности рабочих станций и серверов.	Рабочие станции и серверы. «Администраторы»Контроллеры домена. «Администраторы» и «Операторы сервера»
Создание аудитов безопасности	Определяет, какие учетные записи могут быть использованы процессом для добавления записей в журнал безопасности. Журнал безопасности используется для отслеживания несанкционированного доступа в систему. Неправильное применение этого права пользователя может стать причиной формирования множества событий аудита, которые могут скрыть свидетельства атаки или вызвать отказ в обслуживании, если включен параметр безопасности Аудит: немедленное отключение системы, если невозможно внести в журнал записи об аудите безопасности. Дополнительные сведения см. в разделе Аудит: немедленное отключение системы, если невозможно внести в журнал записи об аудите безопасности (страница может быть на английском языке)(http://go.microsoft.com/fwlink/?LinkId=136299).	«Локальная система»
Олицетворение клиента после проверки подлинности	Определяет учетные записи, разрешенные для олицетворения других учетных записей.	«Администраторы» и «Служба»
Увеличение приоритета выполнения	Определяет, какие учетные записи могут использовать процесс, имеющий право доступа «Запись свойства» для другого процесса, для увеличения приоритета выполнения, назначенного другому процессу. Пользователь, имеющий данную привилегию, может изменять приоритет выполнения процесса через пользовательский интерфейс диспетчера задач.	«Администраторы»
Загрузка и выгрузка драйверов устройств	Определяет, кто из пользователей может динамически загружать и выгружать драйверы устройств или другой код в режиме ядра. Данное пользовательское право не применяется к драйверам устройств Plug and Play. Поскольку драйверы устройств выполняются как доверенные (или с высокими привилегиями) программы, не назначайте эту привилегию другим пользователям. Вместо этого используйте API StartService().	«Администраторы»
Блокировка страниц в памяти	Определяет, какие учетные записи могут использовать процессы для сохранения данных в физической памяти для предотвращения сброса этих данных в виртуальную память на диске. Применение этой привилегии может существенно повлиять на производительность системы, снижая объем доступной оперативной памяти (ОЗУ).	Нет; некоторые системные процессы имеют эту привилегию изначально
Управление аудитом и журналом безопасности	Определяет, кто из пользователей может указывать параметры аудита доступа к объектам для отдельных ресурсов, таких как файлы, объекты Active Directory и разделы реестра.Данный параметр безопасности не позволяет пользователю включить аудит доступа к файлам и объектам в целом. Для включения такого аудита нужно настроить параметр доступа к объекту «Аудит» в пути «Конфигурация компьютера\Параметры Windows\Параметры безопасности\Локальные политики\Политики аудита». Дополнительные сведения см. в статье Доступ к объекту «Аудит» (страница может быть на английском языке) http://go.microsoft.com/fwlink/?LinkId=136283. События аудита можно просмотреть в журнале безопасности средства просмотра событий. Пользователь с данной привилегией может также просматривать и очищать журнал безопасности.	«Администраторы»
Изменение значения параметров аппаратной среды	Определяет, кто может изменять значения параметров аппаратной среды. Переменные аппаратной среды — это параметры, сохраняемые в энергонезависимой памяти компьютеров, архитектура которых отлична от x86. Действие параметра зависит от процессора. На компьютерах архитектуры x86 единственное значение аппаратной среды, которое можно изменить назначением данного права пользователя, — это параметр Последняя удачная конфигурация, который должен изменяться только системой. В компьютерах на базе процессоров Itanium загрузочные данные хранятся в энергонезависимой памяти. Данное право пользователя требуется для выполнения программы Bootcfg.exe и изменения параметра Операционная система по умолчанию компонента Загрузка и восстановлениедиалогового окна Свойства системы. На всех компьютерах это право пользователя требуется для установки и модернизации Windows.	«Администраторы» и «Локальная система»
Профилирование одного процесса	Определяет пользователей, которые могут использовать средства мониторинга производительности для отслеживания производительности несистемных процессов.	«Администраторы», «Опытные пользователи» и «Локальная система»
Профилирование производительности системы	Определяет пользователей, которые могут использовать средства мониторинга производительности для отслеживания производительности системных процессов.	«Администраторы» и «Локальная система»
Отключение компьютера от стыковочного узла	Определяет, может ли пользователь отстыковать портативный компьютер от стыковочного узла без входа в систему.Если данная политика включена, пользователь перед отключением портативного компьютера от стыковочного узла должен войти в систему. Если данная политика отключена, пользователь может отключить портативный компьютер от стыковочного узла, не входя в систему.	Отключено
Замена токена уровня процесса	Определяет, какие учетные записи пользователей могут инициализировать процесс замены токена по умолчанию, связанного с запущенным подпроцессом.Это право пользователя определено в объекте групповой политики «Контроллер домена по умолчанию» и локальной политике безопасности рабочих станций и серверов.	«Локальная служба» и «Сетевая служба»
Восстановление файлов и каталогов	Определяет пользователей, которые могут обойти разрешения на файлы, каталоги, реестр и другие постоянные объекты при восстановлении резервных копий файлов и каталогов, а также пользователей, которые могут назначить любого действительного субъекта безопасности владельцем объекта.В частности, это право пользователя подобно предоставлению следующих разрешений пользователю или группе для всех папок и файлов в системе: Обзор папок/Выполнение файлов Запись	Рабочие станции и серверы. «Администраторы» и «Операторы архива»Контроллеры домена. «Администраторы», «Операторы архива» и «Операторы сервера»
Завершение работы системы	Определяет пользователей, которые после локального входа в систему могут завершить работу операционной системы при помощи команды Завершить работу. Неправильное применение этого права пользователя может стать причиной отказа в обслуживании.	Рабочие станции. «Администраторы», «Операторы архива», «Опытные пользователи», «Пользователи»Серверы. «Администраторы», «Операторы архива», «Опытные пользователи» Контроллеры домена. «Операторы учетных записей», «Администраторы», «Операторы архива», «Операторы сервера», «Операторы печати»
Синхронизация данных службы каталогов	Определяет пользователей и группы, которые имеют право синхронизировать все данные службы каталогов. Это также называется синхронизацией Active Directory.	Нет
Смена владельцев файлов или иных объектов	Определяет пользователей, которые могут стать владельцем любого защищаемого объекта системы, в том числе: объектов Active Directory, файлов и папок, принтеров, разделов реестра, процессов и потоков.

pyatilistnik.org

Максимальные ограничения Active Directory

Active Directory — структура очень гибкая и масштабируемая, однако она все же имеет свои ограничения. Некоторые из них возможно достичь лишь в теории, с другими мы сталкиваемся регулярно. Начнем с наиболее глобальных.

Максимальное количество доменов в лесу

Для Windows 2000 максимальное рекомендованное количество доменов в лесу составляло не более 800, а начиная с Windows Server 2003 (функциональный уровень леса Windows Server 2003) было увеличено до 1200 доменов. Это ограничение связано с максимальным размером записи базы данных AD.

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

Максимальное рекомендуемое количество домен-контроллеров (DC) в домене — 1200. Эта цифра обусловлена ограничением службы репликации (File Replication System, FRS), которая не в состоянии осуществлять репликацию папки SYSVOL между большим количеством объектов.

Максимальное количество объектов

Каждый контроллер домена в лесу Active Directory за время своего существования может создать чуть меньше 2.15 миллиарда объектов. Ограничение касается всех объектов из всех разделов AD, хранящихся на данном контроллере домена. Связано это ограничение с тем, что каждый DC имеет собственный пул идентификаторов Distinguished Name Tags (DNTs). Диапазон значений DNTs лежит в диапазоне от 0 до 2 147 483 393. При создании каждого объекта из этого пула выделяется уникальный DNT, который не может быть использован повторно, даже если объект будет удален. Таким образом, контроллеры домена ограничены в создании примерно 2-мя миллиардами объектов (включая объекты, создаваемые путем репликации).

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

По умолчанию в домене AD можно создать около одного миллиарда субъектов безопасности (пользователей, компьютеров или групп). Ограничение связано с тем, что каждому субъекту безопасности  при создании назначается уникальный идентификатор (Relative ID, RID) из общего пула. В Windows Server 2008 R2 и более ранних операционных системах общий размер пула RID ограничен 2³⁰ (1 073 741 823) идентификаторами.  Начиная с Windows Server 2012 при достижении этого предела есть возможность разблокировать 31-й разряд, тем самым увеличив пул RID вдвое — до 2³¹ (2 147 483 628) идентификаторов.

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

К каждому аккаунту пользователя или компьютера в домене можно применить не более 999 объектов групповых политик (Group Policy objects, GPO). Это не значит, что общее количество GPO в системе жестко ограничено, просто один пользователь или компьютер не сможет обработать больше 999 GPO. Ограничение это установлено для повышения производительности.

Ограничение на членство в группах

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

Максимальное количество членов группы

В домене Windows 2000 максимальное рекомендованное число членов группы составляет 5000. Эта рекомендация основана на количестве одновременных атомарных изменений, которые могут быть совершены в одной транзакции базы данных. Начиная с Windows Server 2003 (уровень функционирования леса Windows Server 2003) для репликации используется технология Linked Value Replication (LVR), позволяющая реплицировать отдельные значения многозначного атрибута. Т.е. в Windows 2000 при изменении одного из членов группы (группа как вариант многозначного атрибута) вся группа должна быть реплицирована, тогда как при использовании LVR реплицируется только тот член группы, который был изменен. Это позволяет превысить ограничение на 5 000 членов в группе.

На данный момент каких либо новых рекомендаций на этот счет нет. Согласно данным Microsoft, в производственной среде зафиксировано более 4 миллионов членов группы, а в тестовой — 500 миллионов.

Максимальное количество записей в ACL

Доступ к объектам в AD регулируется списками доступа (AccessControl List, ACL) — Discretionaly ACL (DACL), который определяет пользователей и группы, которым разрешен или запрещен доступ к объекту и Security ACL (SACL), который отвечает за аудит доступа к объекту.

Каждый ACL содержит записи контроля доступа (Access Control Entry, ACE), в которых хранится SID пользователя или группы и маска доступа, определяющая его права. Максимальный размер ACL составляет 64К, поэтому, исходя из того, что ACE  различаются по размеру, максимальное количество записей составляет около 1820.

Ограничение на имена и пути файлов

Файловые объекты, использующиеся службой AD, такие как папка SYSVOL, файл базы данных ntds.dit и лог-файлы ограничены длиной имени в 260 символов. Это ограничение обусловлено параметром MAX_PATH для Win32 API. Поэтому при выборе места для SYSVOL и базы данных следует избегать вложенных структур папок, которые делают полный путь к файлу длиннее 260 символов.

Ограничение на полное доменное имя

Полное доменное имя (Fully Qualified Domain Name, FQDN) должно быть не более 64 символов, включая точки и дефисы. Это важное ограничение, которое необходимо иметь в виду при выборе доменного имени. Связано ограничение также с параметром MAX_PATH, ограничивающим длину пути к папке SYSVOL. Типичный UNC-путь для доступа к групповой политике выглядит примерно так:

\\<domain-name>\sysvol\<domain-name>\Policies\<GUID>\<Machine|User>\<GroupPolicy-Extension-Specific-Path>

Если этот путь превысит ограничение MAX_PATH в 260 символов, то политика не сможет быть прочитана и применена.

Дополнительные ограничения на длину имен

• NetBIOS имя компьютера или домена не должно превышать 15 символов;
• DNS имя компьютера должно быть не более 24 символов;
• имя организационной единицы (OU) не должно превышать 64 символов;
• user logon name — имя входа пользователя. Имеет ограничение в 256 символов;
• sAMAccountName, известное также как pre-Windows 2000 logon name — в схеме имеет ограничение в 256 символов. Однако для обеспечения обратной совместимости для него установлен лимит в 20 символов для пользователя и 16 для компьютера;
• display name — отображаемое имя пользователя. Представляет из себя комбинацию имен First name, Initials и Last name и может иметь максимальную длину 256 символов;
• common name (cn) — предоставляемое имя объекта, используется для поиска. Максимальная длина 64 символа;
• distinguished name (dn) — различающееся имя. Однозначно определяет объект и указывает его расположение в структуре AD. Например ″CN=Vasily Pupkin, OU=Employees, OU=Accounts, DC=Contoso, DC=com″.  Максимальная длина dn составляет 256 символов, при превышении этой длины LDAP-клиент не сможет получить доступ к объекту и выдаст ошибку.

Такие вот ограничения. Помнить их все наизусть вовсе необязательно, но если вы работаете с AD, то нужно хотя-бы знать об их существовании. Более подробно об ограничениях Active Directory можно узнать из статьи Active Directory Maximum Limits — Scalability.

windowsnotes.ru

Администрирование учетных записей в домене Active Directory::Журнал СА 4.2007

Рубрика: Администрирование /  Администрирование

Facebook Twitter Мой мир Вконтакте Одноклассники Google+

Александр Емельянов

Администрирование учетных записей в домене Active Directory

Одна из важнейших задач администратора – управление локальными и доменными учетными записями: аудит, квотирование и разграничение прав пользователей в зависимости от их потребностей и политики компании. Что может предложить в этом плане Active Directory?

В продолжение цикла статей об Active Directory сегодня мы поговорим о центральном звене в процессе администрирования – управлении пользовательскими учетными данными в рамках домена. Нами будет рассмотрено:

• создание учетных записей и управление ими;
• типы профилей пользователей и их применение;
• группы безопасности в доменах AD и их сочетания.

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

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

Знакомство с Active Directory – Users and Computers

После того как вы установили свой первый контроллер в домене (тем самым вы собственно и организовали домен), в разделе «Администрирование» появляется пять новых элементов (см. рис. 1).

Рисунок 1. Новые элементы для администрирования домена

Для управления объектами AD используется Active Directory – Пользователи и компьютеры (ADUC – AD Users and Computers, см. рис. 2), которая также может быть вызвана через меню «Выполнить» посредством DSA.MSC.

Рисунок 2. Active Directory — Users and Computers

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

Существует также возможность для управления объектами AD без обращения к серверу напрямую. Ее обеспечивает пакет ADMINPAK.MSI, расположенный в директории «%SYSTEM_DRIVE%\Windows\system32». Развернув его на своей машине и наделив себя правами администратора домена (если таковых не было), вы сможете администрировать домен.

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

• Builtin. Здесь содержатся встроенные локальные группы, которые есть на любой серверной машине, включая и контроллеры домена.
• Users и Computers. Это контейнеры, в которые по умолчанию размещаются пользователи, группы и учетные записи компьютеров при установке системы поверх Windows NT. Но для создания и хранения новых учетных записей нет необходимости пользоваться только этими контейнерами, пользователя можно создать даже в контейнере домена. При включении компьютера в домен он появляется именно в контейнере Computers.
• Domain Controllers. Это организационная единица (OU, Organizational Unit), содержащая по умолчанию контроллеры домена. При создании нового контроллера он появляется здесь.
• ForeignSecurityPrincipals. Это контейнер по умолчанию для объектов из внешних доверяемых доменов.

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

Вводим компьютер в домен

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

Выбираем «Мой компьютер -> Свойства -> Имя компьютера», нажимаем кнопку «Изменить» и в меню «Является членом» выбираем «домена». Вводим имя домена, в который мы хотим добавить наш компьютер, и далее доказываем, что у нас есть права на добавление рабочих станций к домену, введя аутентификационные данные администратора домена.

Создаем пользователя домена

Для создания пользователя нужно выбрать любой контейнер, в котором он будет располагаться, нажать на нем правой кнопкой мыши и выбрать «Создать -> Пользователь». Откроется мастер создания пользователя. Здесь вы сможете указать множество его атрибутов, начиная с имени пользователя и временными рамками входа в домен и заканчивая настройками для терминальных служб и удаленного доступа. По завершении работы мастера вы получите нового пользователя домена.

Нужно заметить, что в процессе создания пользователя система может «ругаться» на недостаточную сложность пароля или его краткость. Смягчить требования можно, открыв «Политику безопасности домена» (Default Domain Security Settings) и далее «Параметры безопасности -> Политики учетных записей -> Политика паролей».

Пусть мы создали пользователя Иван Иванов в контейнере Users (User Logon Name: [email protected]). Если в системах NT 4 это имя играло лишь роль украшения, то в AD оно является частью имени в формате LDAP, которое целиком выглядит так:

cn=»Иван Иванов», cn=»Users», dc=»hq», dc=»local»

Здесь cn – container name, dc – domain component. Описания объектов в формате LDAP используются для выполнения сценариев WSH (Windows Script Hosts) либо для программ, использующих протокол LDAP для связи с Active Directory.

Для входа в домен Иван Иванов должен будет использовать имя в формате UPN (Universal Principal Name): [email protected]. Также в доменах AD будет понятно написание имени в старом формате NT 4 (пред Win2000), в нашем случае HQ\Ivanov.

При создании учетной записи пользователя ей автоматически присваивается идентификатор защиты (SID, Security Identifier) – уникальный номер, по которому система и определяет пользователей. Это очень важно понимать, так как при удалении учетной записи удаляется и ее SID и никогда не используется повторно. А каждая новая учетная запись будет иметь свой новый SID, именно поэтому она не сможет получить права и привилегии старой.

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

Рабочая среда пользователя

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

Локальный профиль

Рассмотрим основные составляющие профиля пользователя:

• Раздел реестра, соответствующий определенному пользователю («улей» или «hive»). Фактически данные этой ветки реестра хранятся в файле NTUSER.DAT. Он располагается в папке %SYSTEMDRIVE%\Documents and Settings\User_name, которая содержит профиль пользователя. Таким образом, при входе конкретного пользователя в систему в раздел реестра HKEY_CURRENT_USER загружается «улей» NTUSER.DAT из папки, содержащей его профиль. И все изменения настроек пользовательской среды за сеанс будут сохраняться именно в этот «улей». Файл NTUSER.DAT.LOG – это журнал транзакций, который существует для защиты файла NTUSER.DAT. Однако для пользователя Default User вы вряд ли его найдете, поскольку он является шаблоном. Об этом далее. Администратор имеет возможность редактировать «улей» определенного пользователя прямо из своей рабочей среды. Для этого с помощью редактора реестра REGEDIT32 он должен загрузить «улей» в раздел HKEY_USERS, а затем после внесения изменений выгрузить его.
• Папки файловой системы, содержащие файлы пользовательских настроек. Они располагаются в специальном каталоге %SYSTEMDRIVE%\Documents and Settings\User_name, где User_name – имя пользователя, вошедшего в систему. Здесь хранятся элементы рабочего стола, элементы автозагрузки, документы и др.

Если пользователь впервые входит в систему, происходит следующее:

1. Система проверяет, существует ли локальный профиль этого пользователя.
2. Не найдя его, система обращается к контроллеру домена в поиске доменного профиля по умолчанию, который должен располагаться в папке Default User на общем ресурсе NETLOGON; если система обнаружила этот профиль, он копируется локально на машину в папку %SYSTEMDRIVE%\Documents and Settings с именем пользователя, в противном случае он копируется из локальной папки %SYSTEMDRIVE%\Documents and Settings\Default User.
3. В раздел реестра HKEY_CURRENT_USER загружается пользовательский «улей».
4. При выходе из системы все изменения сохраняются локально.

В конечном итоге рабочее окружение пользователя – это объединение его рабочего профиля и профиля All Users, в котором находятся общие для всех пользователей данной машины настройки.

Теперь несколько слов о создании профиля по умолчанию для домена. Создайте фиктивный профиль на своей машине, настройте его в соответствии с вашими нуждами либо с требованиями корпоративной политики. Затем выйдите из системы и снова зайдите как администратор домена. На общем ресурсе NETLOGON-сервера создайте папку Default User. Далее при помощи вкладки User Profiles в апплете System (см. рис. 3) скопируйте ваш профиль в эту папку и предоставьте права на ее использование группе Domain Users или какой-либо другой подходящей группе безопасности. Все, профиль по умолчанию для вашего домена создан.

Рисунок 3. Вкладка «User Profiles» апплета System

Перемещаемый профиль

Active Directory как гибкая и масштабируемая технология позволяет работать в среде вашего предприятия с перемещаемыми профилями, которые мы рассмотрим далее.

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

Перемещаемые профили хранятся на сервере. Путь к ним указывается в настройках пользователя домена (см. рис. 4).

Рисунок 4. Здесь указывается путь к перемещаемому профилю

При желании можно указать перемещаемые профили для нескольких пользователей одновременно, выделив нескольких пользователей, и в свойствах во вкладке «Профиль» указать %USERNAME% вместо папки с именем пользователя (см. рис. 5).

Рисунок 5. Путь к перемещаемым профилям нескольких пользователей

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

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

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

Технология IntelliMirror в системах Windows последних версий позволяет осуществлять перенаправление определенных папок пользователей, таких как «Мои документы», «Мои рисунки» и др., на сетевой ресурс.

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

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

В первом случае нужно кликнуть на иконке «Мои документы» на рабочем столе либо в меню «Пуск» правой кнопкой мыши и выбрать свойства. Дальше все предельно просто.

Во-втором случае нужно открыть групповую политику OU или домена, для которых мы хотим применить перенаправление, и раскрыть иерархию «Конфигурация пользователя ‑> Конфигурация Windows» (см. рис. 6). Далее перенаправление настраивается либо для всех пользователей, либо для определенных групп безопасности OU или домена, к которым эта групповая политика будет применяться.

Рисунок 6. Настройка перенаправления папок при помощи групповых политик

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

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

К недостаткам перемещаемых профилей можно отнести следующее:

• может возникнуть ситуация, когда, например, на рабочем столе пользователя будут существовать ярлыки некоторых программ, а на другой машине, где захочет поработать обладатель перемещаемого профиля таких программ не установлено, соответственно часть ярлыков не будет работать;
• многие пользователи имеют привычку хранить документы, а также фотографии и даже видео на рабочем столе, в результате при загрузке перемещаемого профиля с сервера каждый раз создается дополнительный трафик в сети, а сам профиль загружается очень долго; для решения проблемы используйте разрешения NTFS, чтобы ограничить сохранение «мусора» на рабочем столе;
• каждый раз, когда пользователь входит в систему, для него создается локальный профиль (точнее, профиль с сервера копируется локально), и если меняет рабочие машины, то на каждой из них остается такой «мусор»; этого можно избежать, настроив определенным образом групповые политики («Конфигурация компьютера -> Административные шаблоны -> System -> User Profiles», политика «Delete cached copies of roaming profiles»).

Введение уже существующего пользователя в домен

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

Создайте на общем сетевом ресурсе (например, Profiles) на сервере папку с именем пользователя и задайте для нее разрешения на запись для группы Everyone. Пусть она называется HQUser, а полный путь к ней выглядит так: \\Server\Profiles\HQUser.

Создайте пользователя домена, который будет соответствовать пользователю вашей локальной сети, и в качестве пути к профилю укажите \\Server\Profiles\HQUser.

На компьютере, содержащем локальный профиль нашего пользователя, нужно войти под учетной записью администратора и при помощи вкладки User Profiles апплета System скопировать его в папку \\Server\Profiles\HQUser.

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

Квотирование

Очень часто пользователи загружают ненужной информацией сетевые диски. Чтобы избежать постоянных просьб почистить свои личные папки от ненужного мусора (почему-то он всегда оказывается нужным), можно использовать механизм квотирования. Начиная с Windows 2000 это можно делать стандартными средствами на томах NTFS.

Для включения механизма квотирования и его настройки нужно зайти в свойства локального тома и открыть вкладку «Квота» (Quota) (см. рис. 7).

Рисунок 7. Включение дисковых квот

Далее помечаем «Включить управление квотами» и настраиваем дисковые квоты по умолчанию для всех пользователей, записывающих информацию на этот том.

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

Рисунок 8. Управление дисковыми квотами для отдельных пользователей домена

Группы пользователей в AD

Управление пользователями в рамках домена – задача несложная. Но когда нужно настроить доступ к определенным ресурсам для нескольких десятков (а то и сотен) пользователей, на раздачу прав доступа может уйти уйма времени.

А если возникает необходимость тонко разграничить права участникам нескольких доменов в рамках дерева или леса, перед администратором встает задача сродни задачам из теории множеств. На помощь здесь приходит использование групп.

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

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

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

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

Чтобы понять описанное выше и основные принципы вложенности групп, рассмотрим пример. Пусть у нас есть лес, содержащий два домена HQ.local и SD.local (какой из них корневой в данном случае, не важно). Каждый из доменов содержит ресурсы, к которым нужно предоставить доступ, и пользователей (см. рис. 9).

Рисунок 9. Предоставление доступа на основе групп

Из рис. 9 видно, что к ресурсам Docs и Distrib должны иметь доступ все пользователи в лесу (зеленые и красные линии), поэтому мы можем создать универсальную группу, содержащую пользователей из обоих доменов, и использовать ее при указании разрешений на доступ к обоим ресурсам. Либо мы можем создать две глобальные группы в каждом домене, которые будут содержать пользователей только своего домена, и включить их в универсальную группу. Любую из этих глобальных групп также можно использовать для назначения прав.

Доступ к каталогу Base должны иметь пользователи только из домена HQ.local (синие линии), поэтому мы включим их в локальную доменную группу, и этой группе предоставим доступ.

Каталогом Distrib будут иметь право пользоваться как члены домена HQ.local, так и члены домена SD.local (оранжевые линии на рис. 9). Поэтому пользователей Manager и Salary мы можем добавить в глобальную группу домена HQ.local, а затем эту группу добавить в локальную группу домена SD.local вместе с пользователем IT. Затем этой локальной группе и предоставить доступ к ресурсу Distrib.

Сейчас мы рассмотрим вложенность этих групп подробнее и рассмотрим еще один тип групп – встроенные локальные доменные группы.

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

На каком-то ресурсе в Интернете, посвященном сертификационным экзаменам Microsoft, я увидел упоминание о такой формуле – AGUDLP, что значит: учетные записи (Account) помещаются в глобальные группы (Global), которые помещаются в универсальные (Universal), которые помещаются в локальные доменные группы (Domain Local), к которым и применяются разрешения (Permissions). Эта формула в полной мере описывает возможность вложенности. Следует добавить, что все эти виды могут быть вложены в локальные группы отдельно взятой машины (локальные доменные исключительно в рамках своего домена).

Вложенность доменных групп 

Вложенность	Локальные группы	Глобальные группы	Универсальные группы
Учетная запись	+	+	+
Локальные группы	+ (за исключением встроенных локальных групп и только в пределах собственного домена)	–	–
Глобальные группы	+	+ (только в пределах собственного домена)	+
Универсальные группы	+	–	+

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

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

Приложение

Нюансы доменной аутентификации

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

Такая ситуация возникает из-за кэширования мандата пользователя и может быть исправлена внесением изменений в реестр. Для этого в папке HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\Winlogon создать (если таковой нет) запись с именем CachedLogonCount, типом данных REG_DWORD и установить ее значение в ноль. Аналогичного результата можно добиться при помощи групповых политик.

1. Емельянов А. Принципы построение доменов Active Directory, //«Системный администратор», №2, 2007 г. – С. 38-43.

Facebook

Twitter

Мой мир

Вконтакте

Одноклассники

Google+

samag.ru

управление ресурсами по-новому / Habr

Как известно каждому системному администратору Windows, начиная с серверной операционной системы Windows Server 2008, такая важнейшая комплексная роль, позволяющая эффективно управлять идентификацией и доступом в организациях, как доменные службы Active Directory, была разделена на целых пять ролей. Если говорить точнее, то всем понятно, что основной задачей роли «Доменные службы Active Directory» (Active Directory Domain Services) выступает выполнение операций, связанных с идентификацией и доступом. То есть тут вам задачи, связанные с проверкой подлинности и авторизацией, тут же есть возможности создания и управления принципалами безопасности, сайтами, службами, а также доверительными отношениями. К этой же роли смело можно отнести централизованную настройку рабочих мест, реализуемую средствами функциональных возможностей групповой политики, и многое другое. Помимо этого, для того, чтобы воспользоваться всеми богатейшими возможностями служб каталогов, также еще можно работать со прочими серверными ролями.
СПОЙЛЕР: В данной статье подается сугубо теоретический материал, и эта статья не предполагает никаких поэтапных процедур.
Рассмотрим такие роли. Как я уже сказал выше, их можно насчитать четыре, а именно:

• Службы сертификации Active Directory, а именно Active Directory Certification Services, AD CS. Средние и крупные организации могут также у себя внедрять службы сертификации AD CS в инфраструктуре открытых ключей PKI для того, чтобы создавать центр сертификации для выдачи цифровых сертификатов, которые привязывают объект идентификации пользователя, устройства или службы к соответствующему частному ключу. Другими словами, службы AD CS предоставляют эффективный безопасный способ самостоятельной выдачи сертификатов и, как следствие, управления ими;
• Службы управления правами Active Directory – Active Directory Rights Management Services, то есть AD RMS. Возможности этой серверной роли, которыми, между прочим, очень многие пренебрегают, предоставляют технологию защиты информации, с помощью которой можно реализовать шаблоны устойчивых политик использования, задающих разрешенное и неавторизированное применение в сети и вне ее, а также внутри и вне периметра брандмауэра;
• Службы федерации Active Directory, что на английском звучит как Active Directory Federation Services,или же попросту AD FS. С помощью этих служб организация может некоторым образом расширить инфраструктуру идентификации и доступа на множестве платформ, включая не только среды Windows, а также обеспечить для доверенных партнеров защиту прав IDA вне периметра безопасности. В среде федерации организациям предоставляется возможность поддержки и контроля собственных объектов идентификации;
• Службы облегченного доступа к каталогам, то есть Active Directory Lightweight Directory Services, или просто AD LDS. Эта роль представляет собой, грубо говоря, каталог LDAP, который хранит только данные приложений, которым требуется доступ к хранилищу каталогов, но информацию о которых не следует реплицировать на все контроллеры домена.

И если ко всему этому еще добавить возможности развертывания контроллеров домена только для чтения, виртуализацию контроллеров домена, а также такие новые возможности, как активацию операционных систем через Active Directory и историю командлетов Windows PowerShell, можно сделать вывод, что возможности Active Directory чуть ли не безграничны. Однако, если посмотреть на то, каким образом предоставляется доступ к информации, то тут можно сказать, что все совсем грустно. Ведь права на основе NTFS не позволяют вам контролировать доступ к документам согласно какой-то строгой классификации файлов, не позволяют проводить гранулированный аудит согласно каким-либо специфическим политикам, не предоставляют возможности генерации «заявок на доступ» и еще имеют некий ряд ограничений.
Но теперь, с выходом такой серверной операционной системы от Microsoft, как Windows Server 2012, про все эти ограничения доступа к файлам посредством списков контроля доступа, то есть ACL-ов, можно забыть, так как появилась технология, именуемая динамическим контролем доступа (Dynamic Access Control), которая позволяет управлять доступом к информации на основе конкретных атрибутов или определенных критериев. Начиная с этой статьи, я вам расскажу об этой замечательной технологии, вы узнаете о том, каким образом можно ее использовать, о различных сценариях, о том, что такое утверждения (также в некоторых случаях именуемые заявками или клаймами, так как на английском это звучит как claim), какие существуют свойства ресурса. Еще вы узнаете о централизованных политиках и правилах доступа, о том, как именно можно опубликовывать и применять такие централизованные политики доступа, кое-что узнаете об аудите, о классификации различных файлов и папок, об устранении неполадок, связанных с динамическим контролем доступа, а также обо многом другом.
Естественно, глядя на все эти моменты, о которых я только что написал, сразу понятно, что одной статьей об этой технологии обойтись ну никак не получится, поэтому, образно говоря, я постараюсь полностью раскрыть эту технологию на протяжении 6-10 статей, рассмотрев большинство возможных сценариев, тонкостей этой технологии, а также примеров как на основе использования центра администрирования Active Directory, так и средств Windows PowerShell, что также немаловажно.
О чем же именно вы узнаете из этой, первой, статьи по такой технологии как динамический контроль доступа? А из этой статьи вы подробнее узнаете о следующих моментах:

• О том, для чего предназначена эта технология;
• О том, чем же эта технология лучше предоставления доступа на основе списков ACL;
• Узнаете о преимуществах и ограничениях текущей технологии;
• А также я расскажу о нескольких сценариях, в которых целесообразно будет использовать динамический контроль доступа и централизованные политики доступа.

Ну что же, приступим.

Назначение и отличия динамического контроля доступа от списков ACL

Как я уже отметил в большой вводной части первой статьи, посвященной этой технологии, динамический контроль доступа позволяет вам по-новому взглянуть на механизм предоставления общего доступа к корпоративным ресурсам, расположенным преимущественно на контроллерах домена и файловых серверах, работающих под управлением операционной системы Windows Server 2012. Так почему же мы сможем взглянуть на предоставление доступа по-новому, и чем же тут так не угодили списки контроля доступа?
Прежде всего, давайте вспомним, каким же образом предоставлялся доступ к ресурсам до выхода этой, пока еще загадочной, технологии.

Как раньше назначались разрешения доступа?

Если говорить в общих чертах, то разрешения на управление доступом назначаются общим объектам и объектам Active Directory для определения того, каким образом разные пользователи могут использовать каждый объект. Как знает каждый – не только администратор, но и обычный пользователь ПК, — общий объект или общий ресурс представляет собой объект, который предполагает использование одним или несколькими пользователями по сети. Такими объектами, естественно, могут быть файлы, принтеры, папки и службы. В Active Directory управление доступом осуществлялось на уровне объектов путем задания для объектов разных уровней доступа или разрешений, таких как «Полный доступ», «Запись», «Чтение» или «Нет доступа». Разрешения управления доступом как к общим объектам, так и к объектам Active Directory, хранятся в их дескрипторах безопасности.
В дескрипторе безопасности содержатся два списка управления доступом (ACL), используемые для назначения и контроля сведений безопасности по каждому объекту. Само собой, это избирательная таблица управления доступом (DACL) и системная таблица управления доступом (SACL).

• Избирательные таблицы управления доступом (Discretionary access control list, DACL). Как известно из официальных источников, в DACL указаны пользователи и группы, которым явным образом разрешен или запрещен доступ к объекту. По вполне понятной причине, если определенный пользователь или группы, в которые он входит, явно не указаны в DACL, этому пользователю будет запрещен доступ к объекту. По умолчанию DACL управляется владельцем объекта или пользователем, который создал этот объект, и содержит записи управления доступом (ACE — Access control entries), определяющие доступ пользователя к объекту;
• Системные таблицы управления доступом (System access control list, SACL). В свою очередь, в SACL указаны пользователи и группы, для которых требуется выполнять аудит успешных и безуспешных попыток доступа к объекту. Аудит служит для наблюдения за событиями, относящимися к безопасности системы или сети, а также для обнаружения недостатков в системе безопасности и для определения объемов и расположения любых повреждений. По умолчанию, как и в случае с DACL, SACL управляется владельцем объекта или создавшим его пользователем. SACL содержит записи управления доступом, определяющие, требуется ли записывать успешные или безуспешные попытки доступа пользователя к объекту с использованием данного разрешения, например, «Полный доступ» или «Чтение».

По умолчанию DACL и SACL связаны с каждым объектом Active Directory, что снижает вероятность сетевых атак злоумышленников и случайных ошибок пользователей домена. Однако, если злоумышленник узнает имя и пароль любой учетной записи, имеющей права администрирования Active Directory, данный лес будет уязвим для атак.
Также не стоит забывать и том, что по умолчанию объекты Active Directory наследуют ACE из дескриптора безопасности объекта родительского контейнера. Наследование позволяет применять сведения управления доступом, определенные для объекта контейнера Active Directory, к дескрипторам безопасности любого подчиненного объекта, включая другие контейнеры и их объекты. Это избавляет от необходимости применять разрешения к каждому новому дочернему объекту. При необходимости можно изменить наследуемые разрешения. Однако рекомендуется не изменять используемые по умолчанию разрешения и параметры наследования объектов Active Directory.
Хотя процесс авторизации выглядит для пользователя как единое событие, он состоит из двух частей:
Пользователь предоставляет параметры доступа, обычно имя пользователя и пароль, которые затем проверяются в базе данных AD DS. Если имя пользователя и пароль совпадают с информацией, хранящейся в базе, пользователь становится авторизованным, и контроллером домена для него выпускается билет для получения билета. На этом этапе пользователь не имеет доступа к ресурсам сети.
Вторичный фоновый процесс передает билет контроллеру домена на рассмотрение и запрашивает доступ к локальной машине. Контроллер домена выдает служебный билет пользователю, который затем может взаимодействовать с локальным компьютером. На этом этапе процесса пользователь авторизован в AD DS и зарегистрирован на локальной машине.
Когда пользователь впоследствии пытается установить соединение с другим компьютером в сети, снова запускается вторичный процесс, и билет для получения билета передается на рассмотрение ближайшему контроллеру домена. Когда контроллер домена возвращает служебный билет, пользователь получает доступ к компьютеру в сети, которая генерирует событие авторизации на этом компьютере.
Компьютер, соединенный с доменом, также авторизуется в AD DS при запуске – факт, который часто упускают из внимания. Вам не видна транзакция, когда компьютер использует свое имя учетной записи и пароль для авторизации в доменных службах Active Directory. Пройдя проверку подлинности, компьютер становится участником группы авторизованных пользователей. Хотя процесс авторизации компьютера не имеет визуального подтверждения в графическом интерфейсе пользователя, стоит помнить, что существуют протоколы событий, которые фиксируют эту активность. Кроме того, если активирован аудит, в журнал безопасности Event Viewer будет внесено больше событий, доступных для просмотра.

А чем же лучше динамический контроль доступа?

Собственно, исходя из того, что собой представляет предоставление доступа на основании списков управления доступом, можно прийти к такому выводу, что при использовании такого метода разрешения предоставляются исключительно основываясь на членстве конечного объекта в определенной группе. Вы не можете ограничивать или, наоборот, разрешать доступ для конкретного устройства пользователя, основываясь на каких-то сторонних характеристиках, а также, само собой, о каких-либо нестандартных сценариях можно сразу забыть.
Динамический контроль доступа, в свою очередь, снимает эти ограничения и позволяет создавать более гранулированные правила, основываясь на которых вы можете предоставлять доступ согласно различным критериям. Другими словами, в первую очередь стоит обратить внимание на то, что эта технология предоставляет возможность управления доступом к файлам и данным посредством создания централизованных политик безопасности, позволяя наиболее подробным образом определять, кто вправе использовать ту или иную информацию. Иначе говоря, вы можете создавать такие политики, которые будут наилучшим образом отражать стратегию вашего бизнеса и полностью соответствовать любым нормативным требованиям. Более того, идентифицировать такую информацию вы можете при использовании классификации файлов, как в ручном, так и в автоматическом режиме. Только эти две возможности практически моментально могут уложить на лопатки управление доступом при использовании списков ACL.
Однако это еще не все. Самые распространенные типы данных, к которым предоставляют доступ, – это офисные документы, то есть файлы, которыми можно управлять при помощи продуктов Microsoft Office. Раньше для того, чтобы задать конкретным пользователям или группам уникальные разрешения с шифрованием документов, для каждого такого документа использовалась служба управления правами Active Directory, то есть AD RMS. Эта технология себя отлично зарекомендовала и сейчас, с появлением динамического контроля доступом, вам предоставляется возможность применения защиты RMS, с использованием автоматического шифрования на основе конкретных критериев.
В наше время одним из самых ценных активов многих компаний является не что иное, как сама информация, которая не должна выходить за пределы организации. Неправомерное использование такой информации может пагубно повлиять на дальнейшую судьбу всей компании. Благодаря централизованным политикам аудита данной технологии, вы можете создавать отчеты для дальнейшего проведения аудита доступа к файлам или же, в случае крайней необходимости, криминалистического анализа. Другими словами, вам не нужно будет прибегать к использованию каких-либо сторонних приложений и программных продуктов.
Что еще можно выделить помимо этого? А можно выделить то, что текущую технологию вы можете использовать, не внося изменений в схему Active Directory, без развертывания дополнительных ролей или же какого-то специфического программного обеспечения, да и, вообще, как говорится, «прямо из коробки». Более того, специально для реализации возможности использования динамического контроля доступа был разработан новый механизм авторизации и аудита для операционных систем Windows, а также для возможностей проверки подлинности Kerberos были реализованы некоторые новшества, о которых я уже писал в третьей части статьи про Kerberos, которая называлась «Сетевой протокол аутентификации Kerberos или зачем нужны утверждения».

А есть ли у него какие-то ограничения?

К сожалению, как и следовало ожидать, у данной технологии также есть некоторый ряд ограничений. Прежде всего, в организации должны быть развернуты доменные службы Active Directory. То есть, если вы захотите воспользоваться динамическим контролем доступа для компьютеров, входящих в состав рабочей группы, у вас ничего из этого не выйдет. Во-вторых, динамический контроль доступа – это не просто отдельная функциональная возможность. Эта технология представляет собой решение для файловых серверов, построенное на основании инфраструктуры Windows Server 2012, включающее поддержку прямых утверждений Kerberos, поддержку Active Directory специально для хранения свойств ресурсов, а также утверждений пользователей и компьютеров, поддержку Active Directory специально для хранения централизованных политик доступа, реализацию распространения таких централизованных политик доступа средствами функциональных возможностей групповой политики, а также многое другое.
Следовательно, согласно всем этим требованиям, можно сделать такой вывод: у вас в организации должен быть развернут как минимум один контроллер домена под управлением операционной системы Windows Server 2012, а также, в том случае, если в вашем лесу развернуто несколько доменов, то в каждом таком домене должно быть развернуто хотя бы по одному контроллеру домена под Windows Server 2012. Это делается специально для возможности использования утверждений между доменами, для которых установлены доверительные отношения. Да и более того, как я уже говорил, в Windows Server 2012 служба KDC была значительно усовершенствована специально для работы с утверждениями в рамках билета Kerberos.
Операционной системой на файловом сервере, естественно, должна быть Windows Sever 2012. Когда пользователь подключается к общей папке, файловый сервер выполняет проверку доступа к ресурсу, используя учетные данные входящего подключения. Это означает, что файловый сервер определяет доступ к общедоступному ресурсу. Это также означает, что различные компоненты на файловом сервере должны поддерживать утверждения, такие как LSA и сервер приложений Kerberos. Получается, файловый сервер, на котором будут располагаться данные, к которым пользователи будут получать доступ, должны быть в состоянии считать утверждения и данные авторизации устройства из билета Kerberos, перевести эти идентификаторы безопасности (SID) и утверждения билета в маркер проверки подлинности и сравнить данные авторизации в маркере с условиями, включенными в дескрипторе безопасности. То есть более старые версии ОС, как следствие, не подойдут.
Ну а в том случае, если у вас будут указаны утверждения для устройств, в качестве клиентов могут использоваться исключительно компьютеры под управлением операционных систем Windows 8 или Windows Server 2012. Другими словами, это ограничение можно назвать веской причиной для миграции клиентов на восьмерку.

Ключевые сценарии использования динамического контроля доступа

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

• Централизованное развертывание политик авторизации. В первую очередь, одной из основных задач этой технологи является создание централизованных политик доступа для файлов компании, позволяющих предоставлять пользователям или их устройствам доступ к файлам на основании конкретных условий, а также, что очевидно, управление такими политиками. Создаются они исключительно на основании потребностей каждой конкретной компании, что делает эту технологию особенно ценной. Каким образом реализуется данный сценарий:
  
  1. Первым делом, необходимо оценить направление вашего бизнеса и определиться с тем, каким образом будут работать такие политики. То есть для начала вы должны определить, для чего вообще вам нужны централизованные политики доступа, иначе говоря, вы локализуете ресурсы, для которых должны будут в будущем применяться такие политики. После этого создается список всех политик, которые вы будете применять в своей среде. Если говорить не так размыто, то вы условно разделяете свои файловые ресурсы на отделы, на какие-либо конкретные категории, а в случае с большим количеством филиалов вы продумываете, как будет выгоднее ограничивать доступ в зависимости от физического расположения, и так далее;
  2. Затем следует реализация выражений политики доступа в структурных компонентах Windows Server в форме, понятной для сервера. Что означает весь этот набор слов? А означает он то, что вторым шагом в реализации данного сценария выступает преобразование требуемой для вас политики доступа в правильное выражение. Такие политики, по большому счету, очень просто конвертируются из обычной, понятной для каждого, формы в язык, требуемый для предоставления авторизации принципалам безопасности. То есть такие политики доступа обладают правилами применимости, условиями доступа, а также исключениями. Это все мы с вами будет очень подробно рассматривать в одной из следующих статей данного небольшого цикла;
  3. После этого, задачей под номером три является определение групп пользователей, свойств ресурсов, а также требуемых утверждений. То есть сейчас вам нужно проанализировать, на какие конкретные ресурсы и для каких принципалов безопасности будут применимы утверждения, создаваемые для каждой централизованной политики доступа;
  4. И, что очевидно, последним пунктом для вас будет определение серверов, на которые будут распространяться такие централизованные политики доступа. Например, вы можете распространять такие политики как сразу на все файловые серверы, так и на серверы, согласно их изначальному назначению.
• Реализация утверждений между лесами. Операционная система Windows Server 2012 была разработана таким образом, чтобы в ней так называемые словари утверждений могли использоваться в каждом лесу, причем все они будут определяться непосредственно на уровне доменных служб Active Directory. Базовые сценарии представляют собой ситуацию, когда клиенту нужно получить утверждение на доступ, которое будет каким-либо образом обходить границу доверия.
  Очевидно, что утверждения относятся к объектам, с которыми таковые связаны, и для каждого леса Active Directory определяются свои типы утверждений. Преобразования межлесовых утверждений позволяют им распознаваться и применяться в доверяющих и доверенных лесах. Чтобы было немного понятнее:
  Доверяющий лес может использоваться для трансформации утверждений во избежание атак, связанных с повышенными привилегиями, благодаря фильтрации входящих утверждений согласно конкретным значениям. Они также выдают утверждения для принципалов через границы доверия в том случае, если доверенные леса не поддерживают, или не выпускают определенные утверждения.
  В свою очередь, доверенные леса могут использовать преобразование утверждений с целью воспрепятствовать определенным типам утверждений, а также не допустить проникновения утверждений с определенными параметрами в доверяющий лес.
  Между прочим, очень важно понимать, что в создании политик преобразований утверждений задействованы два компонента, а именно: объекты политики преобразования утверждений, а также ссылки преобразования. Эти моменты, как и сценарий в частности, будут подробнее рассмотрены в соответствующей статье по данной технологии.
• Улучшенная поддержка пользователей, которым было отказано в доступе. В принципе, штатная ситуация: пользователь N приходит на работу и получает задание, связанное с какой-то определенной информацией, расположенной на файловом сервере, но доступа к которой такому пользователю не предоставляется. Что происходит далее: этот же пользователь N пытается перейти к общей папке, однако при попытке открытия таковой он получает единственный ответ, который гласит: «В доступе отказано». После этого пользователь связывается со службой поддержки и, как показывает практика, в понятной только лишь этому пользователю форме он попытается объяснить, к какой документации ему нужен доступ, зачем он нужна, где находится такая документации и так далее.
  В чем же преимущество использования динамического контроля доступа? При помощи правильного использования данной технологии вы можете дать возможность такому вот сотруднику и владельцу этих данных справиться со своими проблемами самостоятельно, причем практически без использования технической поддержки, а если уже ничего не получится, то обеспечить полномочному персоналу передачу всей необходимой информации без разъяснений от самого пользователя.
  Но вот что сразу хотелось бы отметить. Таких сценариев, связанных с отказами в доступе может быть невероятное множество, причем каждая такая ситуация может быть частной. Поэтому продумать единое решение просто невозможно. Что же в таком случае предлагает сделать Microsoft? А можно, так сказать, пойти следующим путем:
  
  1. Для начала следует определиться с тем, каким образом будет предоставляться первоначальная помощь страждущим при возникновении отказа в доступе. А именно, можно сделать так, чтобы при возникновении такого сообщения у пользователя сразу отображалось кастомизированное сообщение с соответствующей кнопкой, позволяющей отправить владельцу такой папки письмо при помощи электронной почты. Либо вместо этой кнопки с отправкой почты можно сформировать ссылку, перейдя по которой пользователю нужно будет заполнить веб-форму на внутреннем портале. Здесь все зависит от того, что у вас присутствует в инфраструктуре и каким образом будет проще для вас и ваших пользователей реализовать такую поддержку;
  2. После этого вам нужно будет указать уполномоченных лиц, будь то администраторы, либо владельцы самих папок, которым будут капать все эти пользовательские запросы;
  3. Далее настраивается сам шаблон сообщения, которое будет отображено пользователю при отказе в доступе;
  4. В случае необходимости, вы прорабатываете все возможные исключения. Причем крайне желательно, чтобы вы это сделали еще на самом этапе планирования, максимум во время пилотного развертывания;
  5. В конце концов прорабатывается план, согласно которому оказывается помощь на уровне самого файлового ресурса. То есть вы можете указать в самом сообщении уполномоченных лиц или выполнить какие-либо дополнительные действия.
• Разграничение значимой информации при помощи классификации файлов. Как я уже успел написать выше, в наше время один самых значимых ресурсов компаний – их информация, причем как открытая для всего мира, так и, что куда важнее, закрытая внутренняя информация. Причем не конечным пользователям, а именно ИТ-персоналу приходится отвечать за сохранность таких данных и, естественно, за назначение прав только лишь уполномоченным лицам. Другими словами, нужно не только следить за тем, чтобы такая документация была всегда доступна пользователям и чтобы ресурсы таких хранилищ не истощались (за это еще давно отвечала та же DFS-R), а нужно еще и отслеживать то, чтобы ресурсы наиболее эффективным образом использовались только лишь по назначению. А это, естественно, целесообразно реализовывать при помощи каких-либо определенных политик, так как назначать такие права и прочие возможности нужно централизованно.
  Windows Server 2012 совместно с технологией динамического контроля доступа позволяют применять классификации файлов, что дает возможность получить общую картину среди всех ваших ресурсов, причем если вы захотите, можно полностью автоматизировать этот процесс, тем самым сэкономив свое время. Другими словами, среди всех возможностей классификации файлов можно воспользоваться ручным методом, программным, либо использовать автоматические методы классификации файлов. Каким образом следует поступать, вы определите самостоятельно, когда столкнетесь с таким сценарием. А тут все относительно просто:
  
  1. Сначала вы проводите полную инвентаризацию всех возможных файлов, которые можно найти в вашей организации. Для чего вообще это делается? А такие действия следует выполнять для того, чтобы вы могли в дальнейшем использовать классификацию и знали, какие файлы или же папки у вас будут подлежать самой классификации;
  2. После того как файлы, подлежащие классификации, будут определены и вы для себя где-то составите такой план, вам следует выбрать способы классификации таких файлов. То есть можно вручную классифицировать файлы, используя соответствующие средства, можно их классифицировать на основе расположения, причем выполнять это все можно как вручную, так и при помощи классификатора папок, или же, что важнее всего, можно выполнять классификацию на основе содержимого. Обо всем этом мы еще поговорим подробнее в одной из следующих статей по текущей технологии.
• Защита конфиденциальной информации на основе классификации документов Microsoft Office. AD RMS… Как много смысла хранится в этих пяти буквах. Для организации может быть важно не только предоставление доступа к различной секретной документации, но также очевидно и то, что информацию нужно защищать. А общепринятым методом защиты секретной информации является шифрование последней. Для шифрования документации очень хорошо зарекомендовала себя служба управления правами Active Directory. А сейчас, с выходом Windows Server 2012, вы можете автоматизировать процесс шифрования документов, основанных на классификации файлов Microsoft Office, практически в прозрачном режиме, причем сразу же после того, как такие файлы будут появляться на ваших файловых серверах. Что для этого всего следует предпринять:
  
  1. Прежде всего, вам нужно будет определиться с файлами, которые должны быть зашифрованы в автоматическом режиме. Тут, кстати, практически сразу можно столкнуться с небольшой трудностью. Файлы-то на ваших ресурсах могут быть не только конфиденциальными, а они еще и могут обладать личностным характером. То есть первым делом вы должны определить то, какие именно файлы должны подлежать шифрованию. После этого вам нужно будет определить то, согласно каким именно свойствам ресурса будут определяться такие типы файлов. Другими словами, вам нужно будет либо воспользоваться предустановленными свойствами ресурсов, либо создать свои собственные, уникальные свойства ресурсов, которые и будут фигурировать для определения файлов, которые должны быть зашифрованы;
  2. Сразу после этого вам нужно будет определить шаблоны политики прав, которые будут использоваться при шифровании таких файлов. Они уже используются, как вы, вероятнее всего, знаете, непосредственно службой AD RMS. То есть вы выбираете принципалы безопасности и указываете права, которые для них будут доступны при использовании таких файлов. Здесь уже все зависит от ваших бизнес-требований, от разрешений ваших групп пользователей, а также от того, насколько важными являются такие файлы. Например, вы можете разрешить просматривать определенные документы группе финансистов, но запретите им возможности изменения и печати. Вариантов применения службы управления правами для ваших файлов может быть множество;
  3. В конце концов, используя эту технологию, вы смело можете отдавать на ознакомление свою документацию партнерам, не волнуясь о том, что с вашими файлами будут выполняться какие-то неправомерные деяния.
• Создание периодов хранения информации на файловых серверах. Перед тем как начать разбираться с этим сценарием, следует определиться с простым термином: что такое период хранения информации? Согласно официальной терминологии, «периодом хранения называется время, в течение которого следует хранить документ, прежде чем он будет просрочен». Само собой, у всех этот период будет разным. То есть, опять же, давайте вернемся к классификации файлов. По сути, файлы можно классифицировать как кратко-, средне- и долгосрочные для хранения, а после этого уже можно будет для таких периодов определиться с временными рамками. Следовательно, для всей этой процедуры, имеется в виду, для управления периодами хранения, технология динамического контроля доступа использует инфраструктуру классификации файлов совместно с диспетчером ресурсов файлового сервера, с которым многие уже знакомы по предшествующим версиям серверных операционных систем от Microsoft. После того, как срок хранения будет подходить к концу, естественно, владелец получит по электронной почте какое-либо уведомление. И, опять же, как будет выглядеть реализация такого сценария:
  
  1. В первую очередь, вам нужно будет определиться, как долго смогут храниться различные файлы на ресурсах вашей организации, учитывая повышение отказоустойчивости, а также сокращение объема сохраненных данных. Это очень важные факторы, и поэтому при разработке такого расписания вам обязательно нужно будет консультироваться с уполномоченными членами вашей организации;
  2. После этого, само собой, вы определяете тип таких хранимых данных на своих файловых ресурсах. Вы задаете свойства, согласно которым файлы не могут быть случайно удалены конечными пользователями, а также определяете свойства классификации.
• Аудит доступа к файлам. В конце концов, очень важным сценарием выступает аудит безопасности, позволяющий поддерживать порядок и благополучие в вашей среде. Какова основная задача? Естественно, это соблюдение порядка в компании и искоренение неправомерных деяний, которые могут происходить в вашей среде. Тогда может возникнуть следующий вопрос: что позволяет делать аудит безопасности в данном ключе? Тут не сложно догадаться, что аудит безопасности позволяет отслеживать соблюдение установленных вами политик, а также позволяет выявлять и предотвращать вероятностные уязвимости и, в случае необходимости, как сейчас принято выражаться, позволяет выполнять так называемый криминалистический анализ.
  Что же можно сделать с динамическим контролем доступа для соблюдения аудита безопасности? Во-первых, можно настраивать политики аудита на основании конкретных выражений. Что это означает: можно создавать так называемые адресные политики аудита, основанные на требованиях ресурсов, пользователей или их устройств. Во-вторых, можно формировать события аудита при любой попытке доступа к целевым файлам, после чего фильтровать журналы событий на наличие потенциальных точек уязвимости. Более того, вы, естественно, можете определять изменения на основании изменений в атрибутах конкретных файлов, что может повлиять на ограничение доступа, изменения атрибутов конечных пользователей и компьютеров, что, в свою очередь, может послужить как причиной возникновения проблем доступа к жизненно важным файлам, так и дать пользователям излишние права. Также вы можете определять изменения в определениях утверждений, которые включают в себя имя, описание или какие-либо дополнительные значения свойств, изменения связанные с центрированными политиками и какими-либо правами доступа к ресурсам, определяющими то, кто именно может использовать необходимые ресурсы, а также многое другое.
  Естественно, на этих всех моментах, как и на возможностях всех предшествующих сценариев, я еще остановлюсь более подробно, с живыми примерами и процедурами настройки.

Хотите знать больше?

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

habr.com