Варяг и Novell

[Clericos]

Сергей Дубров

Главный довод против подхода со статическим прописыванием - долгое, заранее совершенно не вычисляемое и никак не регулируемое время "прорастания" прав.

Есть такая проблема, но при правильном использовании групп, она не так страшна.
Только на уровне групп раздаются права на NTFS, а раздача пользователям прав производится добавлением в группы. Правда и тут есть геморрой, надо просить пользователя "перелогиниться" как при добавлении его в группу, так и (!!!) при исключении (!) его из группы.

Есть забавные побочные эффекты от статического прописывания прав в ACL в случае подхода от M$: если вы перенесёте (сделаете move) какой-нибудь внутренний каталог, права на который были унаследованы "сверху", в какое-нибудь другое место на том же разделе (томе), то права на него благополучно переедут в новое место

Да, меня тоже раздражает.

Хотя, справедливости ради, надо упомянуть, что с DENY у M$ не всё так просто...

Тут как раз все просто. Явный запрет/разрешение сильнее унаследованного разрешения/запрета.
Кстати не знал, что правило в разных версиях NTFS менялось.

распределённые решения от M$ - тот ещё геморрой
...
Характерный момент: у самой M$ - всё в одном домене. И это "ж-ж-ж" неспроста

Согласен. Так в учебниках по AD и пишут -> добавляйте дополнительный домен и отдельный лес ТОЛЬКО если это действительно необходимо. Ибо это существенно увеличивает затраты на администрирование.
Одного большого домена вполне достаточно.
Есть делегирование прав на уровне OU.

[Сергей Дубров]

Сергей Дубров

Главный довод против подхода со статическим прописыванием - долгое, заранее совершенно не вычисляемое и никак не регулируемое время "прорастания" прав.

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

Да я полностью в теме. И сам про AGUDLP на курсах рассказываю . Долгое "прорастание" прав часто вылезает при назначении на развесистую структуру прав для нового админа. Или при массовом создании большого кол-ва файлов/директорий внутри существующего каталога с назначенными "выше" правами. У нас был случай - скопировали внутрь каталога какой-то продукт (сборник ГОСТов, что ли, не помню), чтобы народ с сетевого диска его запускать мог. Очень развесистая структура директорий/поддиректорий/файлов. Так до конца рабочего дня не дождались, когда им пользоваться можно будет, права всё "прорастали" . Тут никакие группы не спасут. Кстати, на этом же продукте видел своими глазами отказы в работе при бэкапе BackupExec-а - пока BE сканировал по подкаталогам, чего ему там бэкапить надо, медиа-сервер, не дождавшись ответа, отваливал по таймауту.

Правда и тут есть геморрой, надо просить пользователя "перелогиниться" как при добавлении его в группу, так и (!!!) при исключении (!) его из группы.

Да, известная фишка - при логоне пользователь получает тикет, в котором вписаны его SID и SID групп безопасности, в которые он входит. По этим SID-ам проверка доступа по DACL и проводится. И при изменении членства в группе (добавлении/удалении) тикет "на лету" не обновляется, приходится делать logoff/logon. Есть вариант без логофа, но он не очень практичен - время жизни тикета ограничено, через некоторое время пользователь его всё равно переполучит уже с обновлённым содержимым. Но ждать этого придётся неделю (дефолтное время жизни тикета)

Хотя, справедливости ради, надо упомянуть, что с DENY у M$ не всё так просто...

Тут как раз все просто. Явный запрет/разрешение сильнее унаследованного разрешения/запрета.

У меня есть несколько версий MSDN (за 14 лет), по которым можно убедиться, как на протяжении лет это поведение менялось. В старых версиях вообще никак не гарантировался порядок проверки и DENY мог не сработать, если проверялся после ALLOW (проверка прекращается после первого совпадения). Потом стали декларировать, что DENY всегда будет проверяться раньше, откуда бы этот DENY не "пришёл" - сверху или он был явно назначен на этом же уровне. Потом поменяли поведение на сегодняшнее - явное назначение имеет приоритет, т.е. сначала проверяется прямые назначения (DENY->ALLOW), потом - унаследованные (DENY->ALLOW). Но знаю как минимум пару случаев, когда это не выполняется, один из них - на Win2008R2 (при установке одного из продуктов вылезло - явно назначенный ALLOW не срабатывал, вместо него срабатывал пришедший "сверху" DENY на группу).

распределённые решения от M$ - тот ещё геморрой
...
Характерный момент: у самой M$ - всё в одном домене. И это "ж-ж-ж" неспроста

Согласен. Так в учебниках по AD и пишут -> добавляйте дополнительный домен и отдельный лес ТОЛЬКО если это действительно необходимо. Ибо это существенно увеличивает затраты на администрирование.
Одного большого домена вполне достаточно.
Есть делегирование прав на уровне OU.

Граница безопасности по микрософтовски - как раз домен, ни больше и не меньше. И принципиально невозможно внутри домена обрезать права администратору(-ам) домена на какую-нибудь часть дерева каталога. У новела это делается легко и непринуждённо - назначаем на нужную ветку S для нового админа и обрезаем с помощью IRF права для админа "вышележащего". В случае, если политики безопасности требуют разделения полномочий (н-р, если недопустимо иметь суперадмина на всё-всё-всё), у M$ решение возможно только выделением в отдельный домен, со своей границей безопасности. Это принципиальный момент, так устроена AD. Слава богу, хоть в 2008 сделали возможность иметь разные политики безопасности для паролей, раньше они тоже были едиными для всего домена.

[Clericos]

распределённые решения от M$ - тот ещё геморрой
...
Характерный момент: у самой M$ - всё в одном домене. И это "ж-ж-ж" неспроста

Согласен. Так в учебниках по AD и пишут -> добавляйте дополнительный домен и отдельный лес ТОЛЬКО если это действительно необходимо. Ибо это существенно увеличивает затраты на администрирование.
Одного большого домена вполне достаточно.
Есть делегирование прав на уровне OU.

Граница безопасности по микрософтовски - как раз домен, ни больше и не меньше. И принципиально невозможно внутри домена обрезать права администратору(-ам) домена на какую-нибудь часть дерева каталога. У новела это делается легко и непринуждённо - назначаем на нужную ветку S для нового админа и обрезаем с помощью IRF права для админа "вышележащего". В случае, если политики безопасности требуют разделения полномочий (н-р, если недопустимо иметь суперадмина на всё-всё-всё), у M$ решение возможно только выделением в отдельный домен, со своей границей безопасности. Это принципиальный момент, так устроена AD. Слава богу, хоть в 2008 сделали возможность иметь разные политики безопасности для паролей, раньше они тоже были едиными для всего домена.

Здрасьте приехали. Как раз таки можно создать OU "Sales Department" - и делегировать на него (OU) права пользователю "Sales Department Admin".
После чего этот самый пользователь "Sales Department Admin" сможет создавать в OU пользователей, групповые политики и т.д.
Просто не надо пытаться "невозможно внутри домена обрезать права администратору(-ам) домена на какую-нибудь часть дерева каталога", а надо создать "простого" пользователя и сделать его через делегирование "админом" конкретного OU.

После чего можно даже создать отдельную оснастку "AD - Пользователи и компьютеры" с корнем - OU "Sales Department".

Получается "как отдельный поддомен" со своим администратором, который наследует (или не наследует, если не надо) групповую политику корня AD.

Вот вам и разбиение на "поддомены" без создания доп доменов. Счастье без геморроя.

[Clericos]

Главный довод против подхода со статическим прописыванием - долгое, заранее совершенно не вычисляемое и никак не регулируемое время "прорастания" прав.

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

Да я полностью в теме. И сам про AGUDLP на курсах рассказываю . Долгое "прорастание" прав часто вылезает при назначении на развесистую структуру прав для нового админа. Или при массовом создании большого кол-ва файлов/директорий внутри существующего каталога с назначенными "выше" правами. У нас был случай - скопировали внутрь каталога какой-то продукт (сборник ГОСТов, что ли, не помню), чтобы народ с сетевого диска его запускать мог. Очень развесистая структура директорий/поддиректорий/файлов. Так до конца рабочего дня не дождались, когда им пользоваться можно будет, права всё "прорастали" . Тут никакие группы не спасут. Кстати, на этом же продукте видел своими глазами отказы в работе при бэкапе BackupExec-а - пока BE сканировал по подкаталогам, чего ему там бэкапить надо, медиа-сервер, не дождавшись ответа, отваливал по таймауту.

Всякие случаи бывают. А можно "Очень развесистая структура директорий/поддиректорий/файлов" создать как отдельную Шару с правами на уровне Шары. Т.е. без использования NTFS вообще. Тогда права будут менее гибкими, но зато более быстро переназначаться.
Т.е. права NTFS использовать только когда без них не обойтись.

[Сергей Дубров]

Здрасьте приехали. Как раз таки можно создать OU "Sales Department" - и делегировать на него (OU) права пользователю "Sales Department Admin".
После чего этот самый пользователь "Sales Department Admin" сможет создавать в OU пользователей, групповые политики и т.д.
Просто не надо пытаться "невозможно внутри домена обрезать права администратору(-ам) домена на какую-нибудь часть дерева каталога", а надо создать "простого" пользователя и сделать его через делегирование "админом" конкретного OU.

Читаем внимательнее - про (не)возможность делегирования прав НА OU я ничего не говорил. Я говорил о другом - о принципиальной невозможности УРЕЗАНИЯ прав доменного администратора внутри домена. От доменного администратора внутри домена AD закрыться нельзя. В edir от пользователя с S на [root] (ака администратор дерева) - можно.

Вот вам и разбиение на "поддомены" без создания доп доменов. Счастье без геморроя.

Это не то, о чём я говорил . Попробуйте "спрятаться" от администратора домена внутри этого домена - не получится. Вопрос зачем это надо, оставляем за скобками, суть в том, что у решения от M$ такой возможности нет.

UPD: Из той же оперы - не знаю кому как, но меня лично напрягает факт, что администратор домена безусловно является локальным администратором на всех рабочих станциях, входящих в домен. Убрать группу "Админстраторы домена" из группы "Локальные администраторы", конечно, можно, но групповым политиками и рестриктед группами это быстро исправляется обратно, даже если вам, как пользователю рабочей станции, это не нравится и вы против этого. Т.е., закрыться от доменадмина нельзя не только в AD, но и на локальной рабочей станции;

[Павел Гарбар]

Теперь границей безопасности является ЛЕС, а не домен. Домен - административная граница для админа этого домена. А админ корневого домена леса - всем админам админ! Теперь для явного разделения прав и усиления всякой безопасности рекомендуют делать разные ЛЕСА, даже если в них и будет по одному домену...

[Clericos]

Читал я достаточно внимательно. "Урезания прав" действительно нет.

Однако подход изначально не верный. Вместо урезания, надо создать НОВОГО пользователя, ему делегировать права на нужные OU - вот вам и урезание прав. Получиться Администратор с нужными правами. То же самое, просто делается иначе.

Вопрос зачем это надо, оставляем за скобками, суть в том, что у решения от M$ такой возможности нет.

Предлагаю как раз таки и не оставлять это за скобками, т.к. мне не понятно, зачем такая возможность вам нужна? Если есть "типовая-аналогичная".
ИМХО опять прослеживается симптом "специалисты Novell пробуют работать с AD как с eDir" в итоге плюются, плачут, но продолжают есть кактус.
Опять возвращаемся к "нужно мировоззрение поменять".

[Сергей Дубров]

Теперь границей безопасности является ЛЕС, а не домен. Домен - административная граница для админа этого домена.

Да, Павел, ты прав, это верное уточнение, я тут напутал.

А админ корневого домена леса - всем админам админ! Теперь для явного разделения прав и усиления всякой безопасности рекомендуют делать разные ЛЕСА, даже если в них и будет по одному домену...

Ага. И становится совершенно понятным, зачем нужна ADFS

[Сергей Дубров]

Читал я достаточно внимательно. "Урезания прав" действительно нет.

Всё, дальше можно было не продолжать.

Однако подход изначально не верный.

У вас. Я же явно обозначил, для чего бывают нужно в реальной жизни именно УРЕЗАНИЕ прав суперадмина. Вон Павел правильно написал, что если это (урезание прав) потребуется, то для этого уже не просто отдельный домен рекомендуется заводить, а целый отдельный лес. И это со слов самой M$. Мне, мягко говоря, как-то не по себе осознавать, что вся тысячапитьсот пользователей зависят ровно от одного админа.

Вместо урезания, надо создать НОВОГО пользователя, ему делегировать права на нужные OU - вот вам и урезание прав. Получиться Администратор с нужными правами. То же самое, просто делается иначе.

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

Вопрос зачем это надо, оставляем за скобками, суть в том, что у решения от M$ такой возможности нет.

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

На это по сути уже был дан ответ. Если политики безопасности не допускают, чтобы один единственный админ имел принципиально неограничиваемые и полные права на весь лес (включая рабочие станции) - вам вынужденно придётся выращивать другой лес(-а), как бы ни была удобна однодоменная структура. Повторю: это рекомендация от M$.

ИМХО опять прослеживается симптом "специалисты Novell пробуют работать с AD как с eDir" в итоге плюются, плачут, но продолжают есть кактус.
Опять возвращаемся к "нужно мировоззрение поменять".

Нет, не так, снова передёргиваете. Просто "пианист играет, как умеет", а с каталогом (AD) у M$ получилось в меру их тогдашнего понимания ситуации и многие их фундаментальные решения были откровенно неудачными. А после этого включилась стандартная пиар-машина от M$, которая усиленно заясняет про "единственно верный" путь.

Просто примите как факт, что в решение от Новел, при создании субадмина, можно урезать права суперадмину, а можно и не урезать - делайте, как вам удобно. А вот в решении от M$ права суперадмина урезать невозможно. Всё. Это ровно то, что я сразу и сказал. И давайте на этом закончим: все рассуждения про другое "мировозрение" вместо простого признания факта невозможности сделать так, как могут делать другие - пустой трёп и демагогия.

[Ковалев Артем]

Сергей Дубров
Видимо мы не понимаем друг друга.

Всё что я хотел сказать - AD позволяет гибко разграничить права.

Вы не правы. Разграничить - это и отнять. Отнимите у себя (доменного админа) права на любую часть домена. Слабо?

[Clericos]

Вы не правы. Разграничить - это и отнять. Отнимите у себя (доменного админа) права на любую часть домена. Слабо?

Нет не слабо.
Я не использую в повседневной работе учетную запись администратора домена. Поэтому и не понимаю зачем нужно у неё удалять права.

[Сергей Дубров]

Вы не правы. Разграничить - это и отнять. Отнимите у себя (доменного админа) права на любую часть домена. Слабо?

Нет не слабо.

Слабо. Отобрать права у администратора домена внутри домена принципиально НЕВОЗМОЖНО. Тема закрыта.

Я не использую в повседневной работе учетную запись администратора домена. Поэтому и не понимаю зачем нужно у неё удалять права.

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