Архив рубрики: Active Directory

#RuTeched: Отвечаю на вопросы. Будет ли работать Dynamic Access Control при использовании репликации?

imageКак я уже сказал, мои лабы на TechEd вполне удались, но все же я не смог ответить на ряд вопросов и пообещал сделать это позже, когда разберусь. Что ж, время пришло. Один из посетителей сказал мне, что в его опыте был случай, когда какое-то свойство файла не было отреплицировано через DFSR и поинтересовался, не поломается ли от репликации DAC. Я, разумеется мог поставить эксперимент (и сделаю это, на самом деле), но он только ответил бы на вопрос: “да” или “нет”. Ну или “возможно”. Но вряд ли бы он дал мне ответ на вопрос “почему?”. Так как я вовсе не на короткой ноге с репликацией файлов, мне пришлось просить помощи и я знал точное место, где ее можно было найти: блог AskDS.

Ответ пришел весьма быстро. Вкратце: “все будет супер”. Длинный ответ (в моем переводе) идет дальше:

“Позвольте мне уточнить некоторые аспекты вашего вопроса и ответить на каждую часть

При включении Dynamic Access Control для папок и файлов, следует рассматривать несколько аспектов.

Resource Properties

— Resource Properties определены в AD и используются в качестве шаблонов, чтобы проставить на файлы и папки дополнительные метаданные, которые могут использоваться в принятии решений об авторизации доступа. Эта информация хранится в дополнительных потоках данных (alternate data stream) папки или файла. И эта информация будет отреплицирована так же, как и дескриптор безопасности.

Security Descriptor

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

Все это никак не привязано к Dynamic Access Control—это просто результат репликации, к примеру, в случае репликации DFSR DAC не имеет никакого отношения к этим результатам.

Central Access Policy

Central Access Policy это способ распространить разрешения без внедрения их нпрямую в DACL дескриптора безопасности. Так что, когда Central Access Policy развернута на сервере, администратор должен прилинковать политику к папке на файловой системе. Это линкование осуществляется вставлением специального ACE в часть дескриптора безопасности, отвечающую за аудит и говорит Windows, что этот файл или папка защищены с помощью Central Access Policy.  Вследствии этого разрешения в Central Access Policy комбинируются с разрешениями Share и NTFS, чтобы получить итоговые разрешения.

Если файл или папка реплицируются на файловый сервер, который не имеет развернутой Central Access Policy, то DAC, очевидно, не применяется и разрешения так же не будут применяться.

Спасибо ребятам из этого блога: они лучшие Winking smile

Реклама

>Легенды и мифы ИТ #1: Number of previous logons to cache

>

imageЗнаете, как IT Pro я частенько сталкиваюсь с тем, что иначе как мифами и не назовешь. Видимо, IT уже настолько старая отрасль, что свои мифы в ней просто не обходимы. Иногда, столкновение с ними становится настолько частым, что объяснение что и где не так, как в этой легенде становится смертельно скучным. Что еще более удивительно, чем сам факт существования мифов, так это то, что описание того, как правильно, есть на куче ресурсов в Интернете, но… Ну, в любом случае, наверняка есть люди, которые знают людей, которые читают мой блог и не читают эти ресурсы, так что я все равно их тут изложу постепенно.

Давайте начнем с самого базового, но очень часто всплывающего мифа о работе одной настройки в групповых политиках. Да, ту самую, о которой сказано в заголовке. Я однажды встречал человека, которого из-за нее чуть не уволили. Правда. Как всегда: “входит шеф и говорит, что нужно запретить продажникам входить в их ноутбуки больше, чем 15 раз без подсоединения к корпоративной сети, а то задолбали вообще в офисе не появляться”. “Нет проблем”, отвечает ему администратор, меняет настройку политики на 15 и отчитывается о выполнении задачи. А спустя некоторое время выясняется, что задача вовсе и не выполнена и начальство спускает всех собак. Что же случилось и как это поправить?

Перво-наперво, однозначно было ошибкой не проверить, а работает ли Ваше изменение (Я тоже наступал в свое время на эти грабли… Плохие воспоминания… Smile).

Во-вторых, эта настройка регулирует вовсе не то, что кажется на первый взгляд. Если мы прочитаем ее описание в первоисточнике (а это хорошая идея для реализации перед изменениями), то мы увидим следующее: “Determines the number of users who can have cached credentials on the computer”. Или в моём вольном переводе: “Определяет количество пользователей, которые могут иметь закешированные учетные данные на этом компьютере”. Вот оно! Количество самих учетных данных, которые можно кешировать, а не раз, которые можно использовать каждый из них. Так что если у Вас есть разъездной ноутбук, на котором работает 15 пользователей (ого…), то это может Вам помочь. Но не сможет ограничить количество раз, которое можно входить в систему без контакта с  контроллером домена. 

И в-третьих, плохие новости: я не знаю, как сделать то, что требовал тот самый начальник. По-крайней мере, не знаю, как сделать это встроенными средствами Windows. Если Вы знаете – поделитесь. Впрочем, незнание, это все равно не повод говорить шефу, что Вы решили эту задачу.  Smile

>Нажми на кнопку–получишь результат

>

GPOА Вы знаете, в какой точно момент происходит применение настроек GPO, когда Вы их правите? Когда Вы переключаете крыжик в положение “Enabled”? Или когда Вы закрываете консоль редактора групповых политик? Я довольно давно об этом задумался, но, конечно же, слишком ленился, чтобы проверить это самостоятельно ;) Однако, некоторое время назад я был на курсах, где спросил тренера об этом. Так как он не знал ответа, то мы (“мы пахали”, ага) тут же провели некий эксперимент. Выяснилось, что настройки появляются в Sysvol в момент, когда нажимается кнопка “OK” или “Apply” для каждой конкретной настройки. Вы мне не верите? И правильно – проведите свой эксперимент или, если Лень родилась не позже, то можете посмотреть этот короткий ролик:

>Делегирование полномочий на создание GPO в другом домене

>

imageТакая задача неизбежно встает во весь  рост, как только  Вы начинаете пользоваться концепцией ролевого администрирования. Если честно, то пребывая в эйфории от возможностей AGPM, я что оно яйца выеденного не стоит: включили учетную запись в некоторые группы, включая “Group Policy Creator Owners” и вуаля – вот оно. Ага, черта с два!=) Эта чертова группа – глобальная и поэтому не может содержать объекты из других доменов. Более того, мы даже не можем изменить этот факт: такие возможности недоступны:

image

По крайней мере, я пока не знаю, как это сделать (но пометил себе разобраться с этим вопросом в будущем). Таким образом, уделать “по-быстрому” у нас не получится. отступим ли мы? Конечно же нет! Если мы не можем добавить объект в группу, то нужно создать новую группу, выдать ей такие же полномочия и включить объект в нее. Какие разрешения есть у группы “Group Policy Creator Owners”? Насколько я знаю, чтобы создать любой GPO нам нужно иметь права на контейнере Policies в AD и на папке Policies в sysvol. Так что давайте делегируем такие права нашей свежесозданной группе “Role GP Creator Owners”:

1) На контейнер Domain/System/Policies в AD:

image

image

image

image

Причем я полагаю, что “Create All Child Objects” это немного слишком, и можно сделать более тонкую настройку (но я не проверял – просто предположение)однако группа “Group Policy Creator Owners” имеет именно такие полномочия, так что хуже мы точно не сделаем.

2) И на папке Policies:

image

image

Вот теперь все должно работать. У меня, вроде, работает, хотя я еще буду спрашивать об этом ребят из MS, да и Вам рекомендую все тщательно проверить на тестовых стендах. Если выяснятся новые детали, то статью я поправлю, разумеется.

>Дело о застрявших разрешениях

>

imageОднажды я получил запрос от одного из наших администраторов, которому были делегированы определенные права на AD в его сфере ответственности. Он жаловался мне, что он не имеет необходимых прав на одну из учетных записей. Что ж, нет проблем: небольшое исследование и – бинго! – я выяснил, что по непонятным причинам на этой учетной записи было отключено наследование прав. Починка не отняла у меня много времени: одна галка, кнопка “Ок” – не великая потеря времени. На следующий день я получил повторный запрос по тому же поводу и по той же самой учетной записи. Наследование опять было отключено. Ладно, я не такой уж новичек, я даже знаю кое-что о таких тайнах бытия, как adminCount, adminSDHolder и SDProp. Так что я пошел и удостоверился, что проблемный пользователь не является членом ни одной из защищенных групп – так оно и было. Так что я попробовал еще пару трюков навроде переноса учетки в другое OU и обратно. Безрезультатно. И в этот самый момент я получил еще одни запрос, от другого администратора про другую учетную запись, но с тем же самым эффектом. И эта другая учетная запись тоже когда-то была членом группы Domain Admins. 
Что ж, теперь было очевидно, что именно SDProp перезаписывает разрешения на объектах. Проверка атрбута adminCount показала, что наконец-то я был прав: он был установлен в 1.Как только я установил его в 0 и восстановил наследование, все пришло в норму. А еще немного поковырявшись, я выяснил, что когда объект покидает защищенную группу, adminCount не возвращается в значение 0. И это сделано специально, by design. Чуть больше деталей можно найти здесь и здесь. А я в следующий раз буду чуть менее ленивым и буду больше доверять своиему внутреннему Админу – глядишь, время сэкономлю Winking smile

>Как поменять атрибут в AD: варианты №2

>

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

создание какого-нибудь графического приложения

Есть множество вариантов: C#, VBScript, C, черт в ступе. Так как я несколько ленив, то вместо создания собственного приложения с нуля я взял некий скрипт, приложенный к Windows Administration Resource Kit из состава Windows 2008 resource kit, который называется “Object_Attribute_EmployeeNumber.hta”. Он позволяет просмотреть и изменить атрибут EmployeeNumber. Так как ранее я демонстрировал изменение EmployeeID, то и здесь мне пришлось внести некоторые правки типа замены слова “number” на слово “ID” (осторожно – не везде “number” нуждаетсяс в замене!), как здесь:

image

ну и поправить кое-какие баги. Минут 20 работы, правда. Как только я сделал это – вуаля:image

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

В любом случае, есть еще один метод:

расширение возможностей ADUC и других консолей

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

>Как поменять атрибут в AD: варианты

>

После моего сообщения о делегировании и filtered attributes я получил вопрос о болееудобных способах редактирования атрибутов (скажем, EmployeeID), чем редактор атрибутов в консоли ADUC.

Что ж, давайте посмотрим, что я смогу предложить.

ADUC

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

Просто запустите эту консоль, проверьте, что включены дополнительные возможности:

image_thumb1

Потом найдите в дереве AD и откройте вкладку Attribute Editor в его свойствах:

image_thumb3

Достаточно просто, но имеет некоторые недостатки:

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

ADSIEdit

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

Active Directory Administrative Center

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

image_thumb

Из плюсов: теперь не нужно знать, где конкретно лежит объект в структуре AD, его можно просто найти поиском и тут же редактировать.

PowerShell

Я люблю PoSh. Правда. Даже несмотря на то, что я не особо умею с ним обращаться и иногда он меня подводит (возможно из-за моего незнания), я все еще могу сделать с ним оооочень многое. В нашем случае, например, мы можем назначить пользователю новый employeeID как-то так:

image_thumb[1]

Я почти уверен, что это можно сделать в одну строчку, но в данном случае такой задачи передо мной не стояло. Очевидно, что в случае со скриптами Вы можете очень многое: сделать какое-то подобие GUI, или внести массовые изменения. Достаточно гибкий и удобный метод, на самом деле. 

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