- PVSM.RU - https://www.pvsm.ru -
Такая технология как динамический контроль доступа рассматривается в моих статьях уже достаточно давно, но, если честно, я еще не добрался даже до половины всех тем, которые мне хотелось бы рассмотреть. Но, тем не менее, эта статья позволит вам значительно лучше освоить данную технологию и узнать об очередном кирпичике, который крепится ко всему фундаменту динамического контроля доступа. Образно говоря, к такому кирпичику динамического контроля доступа можно отнести не что иное, как сам централизованный доступ. Центральный доступ, по своему существу, позволяет вам реализовать централизованный механизм соответствующих политик авторизации, благодаря которым вы сможете автоматизировать в своей компании «умное» распределение прав. Ведь если вы должным образом сгенерируете свои утверждения, распланируете и создадите все заточенные под ваш бизнес объекты свойств ресурсов, настроите требуемые списки свойств ресурсов и реализуете красивую и корректную классификацию, но допустите непреднамеренные банальные ошибки при работе с централизованными правилами или политиками доступа, весь ваш труд может полететь в тартарары.
Именно по этой причине крайне важно уделить должное внимание созданию своих уникальных централизованных правил и политик доступа и потратить на это столько времени, сколько будет необходимо для того, чтобы полностью предвидеть все возможные ситуации, которые могут произойти уже после того, как вы внедрите технологию динамического контроля доступа в свою производственную среду. Здесь очень важно, чтобы вы все тесты изначально провели в лабораторных условиях и, по возможности, с пилотной группой, так как в противном случае исход может быть самым непредсказуемым. В принципе, к планированию динамического контроля доступа мы с вами еще вернемся в одной из последних статей данного цикла, поэтому останавливаться подробнее на данном этапе в рамках этой темы попросту бессмысленно.
Сегодня будут рассмотрены такие моменты, как назначение самих централизованных правил доступа и централизованных политик доступа. Вы узнаете о том, каким образом можно создать, отредактировать и удалить такие правила и политики. Более того, в этой статье вы узнаете о самом распространении и применении централизованных политик доступа. Получается, как и в случае с четвертой статьей данного цикла, материала в этой статье будет достаточно много, по этой причине будем переходить к первому разделу.
Прежде чем мы начнем создавать централизованные правила доступа, следует определиться с тем, что же вообще это такое и для чего нужны такие объекты. По своему определению, Централизованное правило доступа – это выражение правил авторизации, которые могут включать одно или несколько условий, затрагивающих группы пользователей, требования пользователей и устройств, а также свойства ресурсов. Получается, сгенерированное централизованное правило доступа определяет, кому будет предоставлен доступ к определённой области ресурсов. Как и все объекты технологии динамического контроля доступа, такие правила обязательно должны включать в себя уникальные имена и, что, конечно, опционально, понятные описания. Более того, как я уже успел указать ранее, эти правила также включают в себя определенные выражения, которые представляют собой условные выражения языка SDDL (Security Descriptor Definition Language).
Также можно отметить и то, что несколько централизованных правил доступа можно объединить в централизованную политику доступа. В общих чертах, если для домена определены одно или несколько централизованных правил доступа, администраторы файловых ресурсов для своего удобства могут сопоставить определенные правила с определенными ресурсами и бизнес-требованиями.
В принципе, по теоретической части касательно централизованных правил доступа сказать уже, по сути, нечего, поэтому перейдем к более интересной части: практической. Далее я расскажу о создании, редактировании, а также об удалении централизованных правил доступа. Начинать мы, естественно, будем с
Прежде всего стоит знать о том, что по умолчанию на серверах не создается ни одного централизованного правила. Поэтому вам для дальнейшего использования централизованных правил доступа, а уж тем более централизованных политик доступа, обязательно нужно будет создавать таковые собственноручно. Само по себе создание уникальных централизованных правил доступа – задача не сложная. Этот процесс вам может напомнить создание всех объектов, о которых мы с вами говорили на протяжении всех предыдущих статей настоящего цикла, так как выполнить данную задачу вы можете как при помощи центра администрирования Active Directory, так и средствами такого инструмента как Windows PowerShell. Начинать будем, естественно, с консоли центра администрирования Active Directory. Весь этот процесс выглядит следующим образом:
[1]
Рис. 1. Создание нового централизованного правила доступа
В данном случае следует остановиться на втором варианте и после нажатия на кнопку «Изменить» (Edit) в уже привычном многим диалоговом окне дополнительных параметров безопасности добавить требуемую группу, например, «Маркетологи Лос-Анджелеса», которой будут назначены права «Чтение и выполнение», а также обычное «Чтение».
[2]
Рис. 2. Диалоговое окно создания нового централизованного правила доступа
Как видите, здесь нет ничего сложного. Теперь, пожалуй, рассмотрим такой момент, как создание централизованных правил доступа несколько иным методом, а если говорить точнее, то при помощи такого мощнейшего административного средства как Windows PowerShell. Если полностью обобщить командлеты PowerShell, отвечающие за управление такими политиками, то, как и в случае с управлением списками свойств ресурсов [3], о которых шла речь в предыдущей статье данного цикла, здесь можно выделить три различных командлета, а именно: New-ADCentralAccessRule, благодаря которому вы можете создавать новые централизованные политики доступа, Set-ADCentralAccessRule, позволяющий редактировать существующие правила, а также Remove-ADCentralAccessRule, который, соответственно, отвечает за удаление последних. Ввиду того, что операции по редактированию и удалению существующих правил доступа средствами PowerShell выполняются достаточно просто, эти операции в текущей статье будут попросту опущены. А сейчас же займемся созданием новой централизованной политики доступа.
Например, сейчас нужно создать политику, которая будет называться «Доступ маркетологов Лос-Анджелеса к ресурсам маркетинга» с описанием «Политика, разрешающая маркетологам получать доступ ко всем ресурсам, классифицированным для подразделения Marketing», которая разрешает соответствующей группе получать доступ ко всем ресурсам с правильной классификацией. В данном случае команда PowerShell будет выглядеть следующим образом:
New-ADCentralAccessRule -CurrentAcl:"O:SYG:SYD:AR(A;;FA;;;S-1-5-21-3046794806-2660339953-3139999740-1107)" -description:"Политика, разрешающая маркетологам получать доступ ко всем ресурсам, классифицированным для подразделения Marketing" -Name:"Доступ маркетологов Лос-Анджелеса к ресурсам маркетинга" -ProposedAcl:$null -ProtectedFromAccidentalDeletion:$true -ResourceCondition:"(@RESOURCE.Department_MS == `"Marketing`")" -Server:"DC.biopharmaceutic.local"
где:
Вывод данной команды очень простой: если вы не увидели ошибки – все хорошо и централизованное правило доступа у вас было создано. Пример вывода этой команды можно увидеть ниже:
[6]
Рис. 3. Создание централизованного правила доступа средствами Windows PowerShell
Всегда бывают такие ситуации, когда после создания нового объекта возникает необходимость в его изменении. Быть может, при создании была допущена ошибка, может быть вы просто забыли добавить требуемое разрешение, может, заданное условие было недостаточно исчерпывающим… Вариантов может быть много. Но самое главное то, что в случае нехватки требуемой информации созданный объект необходимо модифицировать. Само собой, централизованные правила доступа нормально относятся к такой ситуации, и для изменения существующего объекта от вас не требуется никаких сверхъестественных действий. Грубо говоря, вы переходите к тому же узлу, в котором было создано само правило (Dynamic Access Control > Central Access Rules), находите такое правило в списке области сведений, а затем либо из контекстного меню такого объекта, либо из панели задач выбираете опцию «Свойства» (Properties).
В отобразившемся диалоговом окне изменения созданного вами правил, вам предоставляются практически те же возможности, что и при создании такого правила, за исключением трех моментов:
На диалоговое окно свойств измененного централизованного правила доступа вы можете посмотреть на следующей иллюстрации:
[7]
Рис. 4. Диалоговое окно свойств измененного централизованного правила доступа
Операции по удалению существующих централизованных правил доступа, скорее всего, наипростейшие операции, которые только можно выполнить. Для этого вам следует в узле Dynamic Access Control > Central Access Rules центра администрирования Active Directory выделить ненужное более правило доступа, а затем либо из контекстного меню, либо из панели задач выбрать команду «Удалить» (Remove). В отобразившемся диалоговом окне подтверждения удаления вам нужно будет нажать на кнопку «Да», означающую, что вы однозначно определились со своим выбором. И все, правило будет моментально удалено.
В том случае, если перед вами отобразится диалоговое окно, свидетельствующее о нехватке прав, откройте диалоговое окно свойств удаляемого вами правила, а затем снимите флажок с опции Защита от случайного удаления (Protect from accidental deletion). После этого повторите действия по удалению правила.
С централизованными правилами доступа мы с вами уже разобрались, поэтому стоит переходить к следующей теме данной статьи, которая посвящается централизованным политикам доступа. Централизованные политики доступа – это политики авторизации, впервые появившиеся в серверной операционной системе Windows Server 2012 и включающие условные выражения. В принципе, такие политики представляют собой коллекции объектов централизованных правил доступа. Создавать такие политики можно при помощи центра администрирования Active Directory, а уже после этого вы сможете их распространять средствами функциональных возможностей групповой политики [8]. Например, если бизнес-требования организации включают ограничение доступа к личным сведениям файлов владельцем файла и членами какого-то подразделения, скажем, отдела кадров, которым разрешено просматривать личные сведения, тогда это общая политика организации, применимая к файлам личных сведений, на каком бы из файловых серверов организации они ни располагались. Как я уже сказал, централизованные политики доступа могут включать в себя одно или несколько централизованных правил доступа, а централизованные правила доступа, в свою очередь, могут быть членами нескольких различных централизованных политик доступа.
Тут, как я уже упоминал ранее, вам обязательно следует обратить внимание на то, что централизованные политики доступа повышают безопасность доступа к файлам и папкам, которые располагаются на выделенных файловых серверах, но никак не заменяют какие-либо локальные политики доступа или же избирательные таблицы управления доступом (DACL), которые уже применяются к тем же файлам или папкам. Иначе говоря, они работают слаженно и сообща. Возьмём такой простейший пример: в централизованной политике доступа четко прописано, что пользователь может использовать конкретный документ, размещенный на файловом сервере, но в списке DACL определено, что в доступе к файлу отказано. Таким образом, пользователь не сможет получить доступ к такому документу. С таким ограничением можно столкнуться по той причине, что правила запрета всегда будут превалировать над разрешающими правилами, причем независимо от того, при помощи какой технологии вы запрещали либо разрешали доступ к самому файлу или папке.
С назначением централизованных политик доступа мы с вами немного разобрались, но также желательно знать еще о некоторых предварительных требованиях, которые обязательно должны быть соблюдены перед тем, как вы начнете у себя в организации внедрять централизованные политики доступа. К этим требованиям можно отнести то, что:
Теперь перейдем к практической части этого раздела и посмотрим, каким образом можно создавать, редактировать, добавлять или удалять к такому объекту централизованные правила доступа, а также как можно удалить объекты централизованных политик доступа, причем как при помощи консоли центра администрирования Active Directory, так и средствами Windows PowerShell.
Задачи, связанные с управлением централизованными политиками доступа, очень похожи на задачи, связанные с реализацией централизованных правил доступа. В приведенном ниже примере будет показано создание централизованной политики доступа, основанное на первом созданном в этой статье правиле доступа. Итак, чтобы создать такую политику, нужно выполнить следующие действия:
Кстати, в группе централизованных правил доступа участников, в столбце «Состояние разрешений» (Permission State) вы можете обнаружить используемые централизованным правилом доступа списки разрешений, которые будут распространяться на это правило. Как видно на следующей иллюстрации, в качестве допустимых значений таких разрешений выступают значения «Предложенные», а также «Текущие» (Proposed, Current).
[10]
Рис. 6. Диалоговое окно создания централизованной политики доступа
С GUI-методом все понятно, поэтому перейдем к более сложному методу, а именно к созданию централизованной политики доступа средствами Windows PowerShell. По существу, командлеты, работающие с возможностями централизованных политик доступа в какой-то степени напоминают методы управления списками свойств ресурсов средствами Windows PowerShell. То есть вы не сможете просто так, при помощи одного командлета, полноценно создать централизованную политику доступа со всеми ее членами. Вам для начала нужно будет создать сам объект, а затем уже при помощи второго командлета добавить к созданной политике требуемые правила доступа.
Получается, для работы с этими объектами вы можете воспользоваться следующими пятью командлетами Windows PowerShell: New-ADCentralAccessPolicy, при помощи которого вы создаете сам объект централизованной политики доступа; Set-ADCentralAccessPolicy, отвечающий за изменение существующей политики; Remove-ADCentralAccessPolicy, благодаря которому, собственно, вы удаляете ненужные политики доступа, а также командлеты Add-ADCentralAccessPolicyMember и Remove-ADCentralAccessPolicyMember, предназначенные для добавления централизованных правил доступа в выбранные вами политики или их удаления. В следующем примере будут рассмотрены только два командлета, позволяющие добавить новую централизованную политику доступа, а также добавить для нее одно правило доступа. Итак, для начала нужно будет воспользоваться следующим командлетом:
New-ADCentralAccessPolicy -description:"Just another CAP" -Name:"Test CAP" -Server:"DC.biopharmaceutic.local" -ProtectedFromAccidentalDeletion:$true
Как видите, с этим командлетом вообще не должно возникнуть никаких проблем. Здесь параметр Name отвечает за имя правила, Description – за его описание, при помощи параметра Server вы можете указать целевой сервер для создаваемого правила, а при помощи параметра ProtectedFromAccidentalDeletion – запретить в дальнейшем удалять созданный вами объект.
Самое интересное начинается на этапе добавления централизованных правил доступа к созданному вами правилу. При помощи второй команды вы должны указать централизованные правила доступа, которые будут добавляться к вашей политике. Такая команда будет выглядеть следующим образом:
Add-ADCentralAccessPolicyMember -Identity:"CN=Test CAP,CN=Central Access Policies,CN=Claims Configuration,CN=Services,CN=Configuration,DC=biopharmaceutic,DC=local" -Members:"CN=Доступ маркетологов Лос-Анджелеса к ресурсам маркетинга,CN=Central Access Rules,CN=Claims Configuration,CN=Services,CN=Configuration,DC=biopharmaceutic,DC=local" -Server:"DC.biopharmaceutic.local"
Здесь фигурируют только два параметра, а именно: параметр Identity, позволяющий указать созданное ранее правило, а также параметр Members, где вам нужно будет через запятую указать все требуемые централизованные правила доступа. Как обычно, если после выполнения команд вы не увидите никаких предупреждений, значит, все было создано правильно. Пример вывода этих команд проиллюстрирован ниже:
[11]
Рис. 7. Создание централизованного правила доступа средствами Windows PowerShell
Изменение и удаление существующих централизованных политик доступа, скорее всего, представляют собой наипростейшие операции среди всех рассмотренных в этой статье задач. Такой вывод можно сделать по той причине, что как при помощи команды изменения свойств, так и во время удаления политик вы не столкнетесь с какими-либо новыми параметрами или свойствами. Чтобы изменить существующую политику доступа, вам нужно в центре администрирования Active Directory перейти к узлу Dynamic Access Control > Central Access Policies, выбрать требуемую политику доступа, а затем либо из контекстного меню, либо из панели «Задачи» (Tasks) выбрать команду «Свойства» (Properties).
Более того, если вам понадобится добавить к существующей централизованной политике доступа новое правило доступа, из того же контекстного меню или панели задач выберите команду «Добавить централизованные правила доступа» (Add Central Access Rule). После выбора этой опции отобразится диалоговое окно добавления централизованных правил доступа, о котором шла речь во втором этапе процедуры создания централизованной политики доступа.
С удалением более ненужных централизованных политик доступа у вас также не должно возникнуть каких-либо трудностей. Для этого в том же узле Central Access Policies выберите требуемый объект, а затем выполните команду «Удалить» (Delete) из контекстного меню.
Разумеется, сами по себе централизованные политики вам ничего не дадут. Чтобы начать их применять на ваших производственных файловых серверах, сперва их нужно централизованно распространить. Наилучшим методом автоматизации распространения практически любых настроек для операционных систем Windows является использование функциональных возможностей групповых политик. На данный момент при помощи групповой политики вы можете сделать практически все, что только можно себе представить, в плане кастомизации систем. Если это какие-то определенные параметры системы, которые можно найти в графическом интерфейсе, – пожалуйста, для вас были разработаны тысячи административных шаблонов [12]. Вам нужно установить приложение – для этого есть расширение CSE GPSI [13], определить политики паролей, настроить системные службы, ограничить доступ к системному реестру или, скажем, настроить политики ограничения доступа к программам, правила брандмауэра Windows или IPSEC – в этом помогут существующие параметры [14] из узла «Конфигурация Windows». Если вам нужно выполнить централизованную настройку какого-то определённого программного продукта, возможно, вендор уже выполнил за вас огромную часть работы, выпустив к своему продукту административные шаблоны [15]. Даже если вы не смогли найти для себя искомый параметр политики, вы всегда можете воспользоваться предпочтениями групповой политики [16], которые могут вас избавить от написания громоздких скриптов, в которых так просто допустить ошибку.
И такая технология как «Динамический контроль доступа», конечно, не обошлась без своего расширения клиентской стороны для групповой политики. Так как все создаваемые вами правила и политики хранятся в доменных службах Active Directory, по большому счету, остается лишь изъять такие объекты из требуемых контейнеров, а затем распространить указанные в них параметры на конкретные машины. На словах это звучит весьма просто, но посмотрим, что же собой представляет такая процедура на практике.
Итак, чтобы распространить свои созданные ранее централизованные политики доступа на файловые серверы, нужно будет выполнить следующие действия:
В принципе, так как в ряды функциональных возможностей групповой политики прибавилось расширение клиентской стороны, позволяющее управлять централизованными политиками доступа, настроенные вами политики обязательно должны в каком-то виде храниться в папке SYSVOL на всех контроллерах домена, которые участвуют в репликации. Например, чтобы локализовать сгенерированные параметры политики, на контроллере домена вам следует перейти к папке C:WindowsSYSVOLdomainPolicies{6DF180BA-22E3-4D52-A34F-158633E56956}MachineMicrosoftWindows NTCap, где C:WindowsSYSVOLdomainPolicies представляет собой путь к каталогу со всеми созданными в домене объектами групповой политики, {6DF180BA-22E3-4D52-A34F-158633E56956} – это GUID самого объекта групповой политики, который только что был создан и настроен (узнать это можно, вызвав диалоговое окно свойств для самого верхнего узла непосредственно из редактора управления групповыми политиками), а MachineMicrosoftWindows NTCap – это уже путь к папке, где располагается файл, в котором и будут определены указанные вами параметры политики.
В этом каталоге можно найти единственный INF-файл, который называется cap.inf (сокращение от Central Access Policy). Этот файл не зашифрован, и при желании вы можете просмотреть его содержимое. Например, в моем случае такой файл будет включать в себя следующие строки:
[Version]
Signature="$Windows NT$"
[CAPS]
«CN=Test CAP,CN=Central Access Policies,CN=Claims Configuration,CN=Services,CN=Configuration,DC=biopharmaceutic,DC=local»
«CN=Маркетологи Лос-Анджелеса,CN=Central Access Policies,CN=Claims Configuration,CN=Services,CN=Configuration,DC=biopharmaceutic,DC=local»
Полагаю, что из содержимого такого файла все понятно и не следует его рассматривать более подробно. Грубо говоря, как вы видите, здесь можно обнаружить различающиеся имена, которые определяют наименование и местоположение централизованной политики доступа, сохраненной в доменных службах Active Directory.
Выходит, что в этом INF-файле можно обнаружить только само наименование политики и ее расположение. То есть, если после получения такого файла вообще не выполнять никаких действий, то в этом случае клиент попросту не будет знать, что же собой представляют такие политики, не говоря уже о правилах. Именно по этой причине операционной системе необходимо предпринимать какие-то действия и реализовать механизмы, позволяющие правильно «понять, для чего нужны эти политики и что с ними можно сделать». Благо, в Windows Server 2012/2012 R2 уже все реализовано «из коробки». Уже после обновления параметров групповой политики системная библиотека auditcse.dll считывает требуемую информацию о централизованных политиках доступа из INF-файла, а затем посредством LDAP-запросов все необходимые системе данные будут получены из доменных служб благодаря расширению клиентской стороны и записаны в системный реестр целевого компьютера.
Если у вас есть желание локализовать и поизучать такие параметры, вам нужно будет воспользоваться редактором реестра и, находясь в окне regerdit, перейти к разделу HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaCentralizedAccessPolicies. Причем обратите внимание на то, что в разделе CAPEs можно найти централизованные правила доступа, а в разделе CAPs будут находиться параметры, отвечающие за централизованные политики доступа. Например, как для правил, так и для политик доступа можно обнаружить параметры Name и Description, которые отвечают, соответственно, за имя и описание определенного объекта. Как видно на следующей иллюстрации, в данном разделе реестра можно найти подразделы, которые включают в себя все распространенные вами централизованные политики доступа со своими параметрами:
[20]
Рис. 10. Раздел реестра с определенными параметрами централизованных политик и правил доступа
В принципе, я не вижу особого смысла подробно останавливаться на каждом параметре из этих двух разделов, так что рассматривать их в этой статье мы с вами попросту не будем.
После того, как были выполнены все упомянутые выше процедуры, к которым можно отнести создание централизованных правил доступа, настройку централизованных политик доступа и добавление в них ваших правил, а также распространение централизованных политик доступа средствами функциональных возможностей групповой политики, можно выполнить заключительную часть этого этапа, а именно само применение централизованных политик доступа к целевым папкам или файлам, размещенным на файловых серверах. Сразу после создания параметров в реестре операционная система распространяет определенные централизованные правила и политики доступа на локальную систему безопасности.
Чтобы применить централизованную политику доступа, вам нужно будет выполнить следующие действия:
[21]
Рис. 11. Вкладка централизованной политики дополнительных параметров безопасности
Итак, в этой статье мы с вами продолжили обсуждать динамический контроль доступа. Вы узнали о том, что собой представляют централизованные правила доступа и как можно управлять такими правилами, причем как при помощи консоли центра администрирования Active Directory, так и используя возможности Windows PowerShell. Более того, в этой статье было подробно рассказано о дальнейшей судьбе правил доступа, то есть об их членстве в централизованных политиках доступа. Также вы узнали о том, как можно управлять такими политиками. Еще вы могли узнать о распространении таких политик доступа средствами групповой политики, а в последнем, небольшом, разделе этой статьи речь шла о том, как можно применить сгенерированные и распространенные ранее централизованные политики доступа к целевым папкам и файлам размещенным на файловых серверах.
В следующей статье этого цикла мы с вами продолжим более детально рассматривать технологию динамического контроля доступа и подробнее остановимся на условных выражениях и предложенных разрешениях, будут рассмотрены несколько «живых» примеров использования централизованных политик доступа, а также много других интересных моментов, о которых я не успел упомянуть в первых пяти статьях настоящего цикла.
Автор: hb860
Источник [22]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/microsoft/50290
Ссылки в тексте:
[1] Image: http://habrastorage.org/storage3/dd0/29f/6a2/dd029f6a24da633ef95ee5a0f604190b.png
[2] Image: http://habrastorage.org/storage3/038/557/40a/03855740acd7cd426ed7d3a7b6b948f8.png
[3] управлением списками свойств ресурсов: http://habrahabr.ru/post/204212/
[4] ACE Strings: http://msdn.microsoft.com/en-us/library/windows/desktop/aa374928(v=vs.85).aspx
[5] SID Strings: http://msdn.microsoft.com/en-us/library/windows/desktop/aa379602(v=vs.85).aspx
[6] Image: http://habrastorage.org/storage3/20a/277/207/20a27720768ba70a214b699af1e3ad32.png
[7] Image: http://habrastorage.org/storage3/ad6/a11/87a/ad6a1187af826104eede0b4ce199a255.png
[8] групповой политики: http://dimanb.wordpress.com/category/%d0%b3%d1%80%d1%83%d0%bf%d0%bf%d0%be%d0%b2%d1%8b%d0%b5-%d0%bf%d0%be%d0%bb%d0%b8%d1%82%d0%b8%d0%ba%d0%b8/
[9] Image: http://habrastorage.org/storage3/81a/0b4/16d/81a0b416d14cbb9241443dd95770069c.png
[10] Image: http://habrastorage.org/storage3/3b5/9bf/355/3b59bf355b4c0ac2c0f11c3375286be9.png
[11] Image: http://habrastorage.org/storage3/2eb/5d8/2f2/2eb5d82f20d71fb8a98ac4db6c540675.png
[12] административных шаблонов: http://dimanb.wordpress.com/category/%d1%81%d0%be%d0%b2%d0%b5%d1%82-%d0%bd%d0%b5%d0%b4%d0%b5%d0%bb%d0%b8/
[13] GPSI: http://dimanb.wordpress.com/?s=%D0%A3%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0+%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE+%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8F+%D1%81%D1%80%D0%B5%D0%B4%D1%81%D1%82%D0%B2%D0%B0%D0%BC%D0%B8+%D0%B3%D1%80%D1%83%D0%BF%D0%BF%D0%BE%D0%B2%D0%BE%D0%B9+%D0%BF%D0%BE%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%B8
[14] существующие параметры: http://dimanb.wordpress.com/category/%d0%bb%d0%be%d0%ba%d0%b0%d0%bb%d1%8c%d0%bd%d0%b0%d1%8f-%d0%bf%d0%be%d0%bb%d0%b8%d1%82%d0%b8%d0%ba%d0%b0-%d0%b1%d0%b5%d0%b7%d0%be%d0%bf%d0%b0%d1%81%d0%bd%d0%be%d1%81%d1%82%d0%b8/
[15] административные шаблоны: http://dimanb.wordpress.com/category/msoffice-2010/
[16] предпочтениями групповой политики: http://dimanb.wordpress.com/category/%d0%bf%d1%80%d0%b5%d0%b4%d0%bf%d0%be%d1%87%d1%82%d0%b5%d0%bd%d0%b8%d1%8f-%d0%b3%d1%80%d1%83%d0%bf%d0%bf%d0%be%d0%b2%d0%be%d0%b9-%d0%bf%d0%be%d0%bb%d0%b8%d1%82%d0%b8%d0%ba%d0%b8/
[17] Локальная политика безопасности. Часть 6: группы с ограниченным доступом, системные службы, реестр и файловая система: http://dimanb.wordpress.com/2010/05/10/secgpo-06/
[18] Image: http://habrastorage.org/storage3/ea3/ea5/969/ea3ea596936ca418a0bceb1e2e310ae3.png
[19] Image: http://habrastorage.org/storage3/0ad/4cc/cdb/0ad4cccdb898f7216004e4081d0c989d.png
[20] Image: http://habrastorage.org/storage3/858/e9d/fdb/858e9dfdba83afdd1dd29d0d90434aee.png
[21] Image: http://habrastorage.org/storage3/28c/4e3/563/28c4e35633b1a5f3dd75145a6f3ecad5.png
[22] Источник: http://habrahabr.ru/post/205336/
Нажмите здесь для печати.