Clericos писал(а):А что за "Больше всего раздражает - время реакции на практически любые действия в АД"? Как-то не сталкивался и не совсем понимаю о чем вы.
Как-то я уже про это здесь писАл: у edir и AD принципиально разные технологии назначения (хранения) прав. Они разные как в каталогах, так и на уровне файловых систем - у AD это СТАТИЧЕСКОЕ прописывания DACL по ВСЕМ нижележащим объектам. То, что вы видите потом в виде "сереньких" галочек, стоящих напротив прав, унаследованных "сверху", на самом деле вписано в ACL объекта, права на который вы в данный момент изучаете. У новеловских edir/фс права назначаются (вписываются) ровно в ОДНОМ месте - в ACL того объекта, на который вы эти права даёте. Можно это сформулировать так: в AD наследование обеспечивается в момент назначения, а в edir - при обращении.
"За" и "против" того или иного подхода уже тоже здесь обсуждались. Главный довод против подхода со статическим прописыванием - долгое, заранее совершенно не вычисляемое и никак не регулируемое время "прорастания" прав. Долго - это могут быть часы, и даже сутки на больших и развестистых структурах (видел это неоднократно в реальной жизни). Против новеловской динамики - замедление при обращении к объекту, т.к. эффективные права вычисляются и проверяются "на лету", в т.ч. с активным "беганием" вверх по дереву. Зато собственно назначение и "прорастание" происходит практически мгновенно - одна запись в ровно один DACL.
Есть забавные побочные эффекты от статического прописывания прав в ACL в случае подхода от M$: если вы перенесёте (сделаете move) какой-нибудь внутренний каталог, права на который были унаследованы "сверху", в какое-нибудь другое место на том же разделе (томе), то права на него благополучно переедут в новое место (только галочки из серых станут чёрными
) и пользователи будут продолжать иметь доступ к содержимому перемещённого каталога. И это несмотря на то, что он уже переместился в "сторону" и вроде неоткуда взяться унаследованным "сверху" правам - он их с собой "перенёс"
.
А вот из того, что мне нравится в ACL от M$ - это сущность creator/owner, которую можно использовать в DACL (очень удобная вещь) и возможность в ACL иметь DENY, а не только ALLOW, как в новеловском подходе. В пользу DENY есть замечательный аргумент - если одному пользователю из группы нужно запретить доступ к конкретному ресурсу, то в случае от M$ вам достаточно сделать этому конкретному юзеру DENY на этот ресурс, а вот в новеловском подходе придётся удалять пользователя из группы, т.к. пока он является её членом, то он эквивалентен по безопасности группе и будет всегда иметь те права, что имеет группа, не меньше (ровно также пользователь не может иметь
меньше прав, чем любая правая часть его полного имени - он эквивалентен по безопасности OU, в котором состоит, O, [root], [public] - это замечательный, полностью объектный подход от Новела. У M$ принципалом безопасности может быть только очень ограниченный набор объектов, OU, к примеру, к ним не относится).
Хотя, справедливости ради, надо упомянуть, что с DENY у M$ не всё так просто - с одной стороны декларируется, что DENY имеет приоритет перед ALLOW (проверяется раньше), с другой - явно назначенный ALLOW на конкретный ресурс для конкретного юзера может(!) иметь приоритет перед DENY, назначенным для группы (членом которой является этот юзер) выше по дереву. И, что самое неприятное, это поведение менялось в разных версиях NTFS.
.