Переезд Netware --> WIN

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

P.S. Прошу прощения, если опять задел чьи-то чувства (что уже бывало, к сожалению). Я не фанат MS. Просто 15 лет админю Win сети и чуть-чуть netware/groupwise, с проблемами этими сталкивался только в начале карьеры.

p.s. Знаю, у Novell попроще и удобнее будет.

Я админю венду (с самой первой версии NT 3.1), NW (с версии 2.15C), *nix (linux с самых первых версий, с начала 1990-х) уже более двадцати лет, хорошо знаю сильные и слабые стороны и тех и других. Более того, многократно доводилось курсы по этой тематике проводить, народ учить (и сейчас учу, н-р, курс по ИТ безопасности в НГУ, я активно использую сравнение управления доступом в венде, NW, *nix-ах). Так что за просвещение спасибо, но мне конкретно оно какбэ не очень нужно - сам кого хочешь научу

Про назначение прав в венде ОДИН РАЗ и их раздачу используя группы (привет AGUDLP ), думаю, все в курсе. Просто в очередной раз был констатирован факт, что права на NFTS а) статические б) долго "прорастают". И всё.

Это, КСТАТИ, отдельная особенность которую нужно знать Netware админу. После добавления в группу/исключения из группы - это вступает в силу через некоторое (лень искать в документации) время, либо сразу если человек перелогинился.).

Про эту особенность, опять же, думаю, любой мало-мальски грамотный админ в курсе. Т.к. исключение из группы попадает под те же правила - удалил пользователя из группы, у которой назначены права, а юзер продолжает иметь доступ к ресурсу - это некоторых админов реально раздражает . Пока либо ишак не сдохнет, либо время жизни тикета не истечёт, либо пока юзер не перелогинится . Кстати, сейчас дефолтное время жизни сервисного тикета - которое вам лень искать - 10 часов. В более ранних версиях венды дефолт lifetime был посерьёзнее - 7 суток

Да, вспомнил ещё одну удобную вещь в раздаче прав на NTFS, эквивалента которой у NW не было и нет - возможность сделать DENY в DACL, а не только ALLOW. Пример, когда это удобно, навскидку: дал права какой-то группе на несколько разных ресурсов, и требуется для одного ресурса закрыть доступ для одного юзера, члена этой группы. Решение с DENY простое: делаем на требуемом ресурсе DENY для этого одного юзера, не удаляя его из группы. В Netware/OES запретить доступ одному юзеру можно только удалив его из списка членов группы, т.к. из-за эквивалента по безопасности он всегда будет иметь права НЕ МЕНЬШЕ, чем имеет группа.

Это (эквивалентность по безопасности) ещё более ярко проявляется, если, н-р, дать права какому-нибудь контейнерному объекту (OU) - после этого все объекты, у которых FDN содержит в правой части имя этого контейнерного объекта, будут иметь права не меньше, чем этот контейнерный объект. Т.е., если назначить RWECMFA для .LAB1.LAB.CORP на какой-нибудь ресурс, все юзеры с именем вида .User.LAB1.LAB.CORP меньше прав уже иметь не могут (н-р, если захочется оставить им только RF). Т.к. DENY нет, права могут только "добавляться", а не "вычитаться" И IRF действует НА ТО, на что назначены права, а НЕ НА ТОГО, кому они назначены. Т.е., урезать права на файлы/папки ниже по дереву - пожалуйста, а уменьшить права юзеру, если он получил эти права по эквиваленту безопасности (группа, контейнер) - обломись.

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

Сергей, вы не правы.
В модели Novell тоже можно сделат "лишенцев" и ровно по той же схеме - у группы (куда входит юзер) права есть, а у юзера в лоб - отняты (оставлен, например, read без filescan). И это работает. Потому как права не суммируются, а перебираются и если есть права "в лоб", то остальные уже не используются.

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

Сергей, вы не правы.
В модели Novell тоже можно сделат "лишенцев" и ровно по той же схеме - у группы (куда входит юзер) права есть, а у юзера в лоб - отняты (оставлен, например, read без filescan). И это работает. Потому как права не суммируются, а перебираются и если есть права "в лоб", то остальные уже не используются.

Вы неправы, прав я. Права именно СУММИРУЮТСЯ и, если группа (контейнерный объект) имеет какие-то права на ресурс, то все её члены не могут иметь прав на этот ресурс МЕНЬШЕ, чем у группы. Это фундаментальное свойство модели безопасности NW/OES (та самая эквивалентность по безопасности). При вычислении эффективных прав права СУММИРУЮТСЯ - назначенные явно, пришедшие "сверху" (унаследованные), от эквивалента по безопасности и др.

Вы, похоже, спутали приоритет явно назначенных прав перед зафильтрованными унаследованными (IRF).

Проведите простейшую проверку - я её проделал (в тысячный раз) вот только что:

1. Дал полные права RWECMF на папку \MED OU с именем .Medic.ASU.BINP;
2. На подпапку \MED\PAPKA1 дал права RF для юзера .Ivanova.Medic.ASU.BINP;
3. Правая кнопка мыши Inherited Rights and Filters -> правая кнопка на .Ivanova.Medic.ASU.BINP -> Current effective rights. И видим, что Ivanova имеет ПОЛНЫЕ права, несмотря на то, что ей на \MED\PAPKA1 явно назначены только RF. Эквивалент по безопасности, в полный рост. Абсолютно то же самое (я тоже проверил ), если в п.1 давать права не OU, а группе. Проверьте, это несложно.

По поводу:

а перебираются и если есть права "в лоб", то остальные уже не используются.

примерно так работает проверка в венде, она останавливает проверку при первом подходящем ALLOW/DENY (приоритет):

• Explicit Deny
• Explicit Allow
• Inherited Deny
• Inherited Allow

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

Да, про фильтр я забыл
Вы правы, я нет.

[Clericos]

Я админю венду (с самой первой версии NT 3.1), NW (с версии 2.15C), *nix (linux с самых первых версий, с начала 1990-х) уже более двадцати лет, хорошо знаю сильные и слабые стороны и тех и других. Более того, многократно доводилось курсы по этой тематике проводить, народ учить (и сейчас учу, н-р, курс по ИТ безопасности в НГУ, я активно использую сравнение управления доступом в венде, NW, *nix-ах). Так что за просвещение спасибо, но мне конкретно оно какбэ не очень нужно - сам кого хочешь научу

Знаю по нашим предыдущим дискуссиям. Снимаю шляпу

Про назначение прав в венде ОДИН РАЗ и их раздачу используя группы (привет AGUDLP ), думаю, все в курсе.

Вот это как раз под вопросом )))

Каждый раз когда тут на форуме пишут что-то вроде "часто приходится менять NTFS права и это выбешивает",
а в ответ вместо "нафига ты их постоянно меняешь, продумай структуру, сам-себе-злобный-буратино и т.п." (что кстати только Павел написал /*про правильное планирование структуры папок*/, за что ему плюсик в карму)
читаю "Да, всё плохо, NTFS ужасна, ничего сделать нельзя"

То что NTFS, AD, Exchange, Lync, Windows server это зло и не спасёт мир, мы уже выяснили.
А вот что "ничего сделать нельзя" я не согласен.

P.S. не будем начинать новый холивар. Я просто прокомментировал "зачем" я написал предыдущее сообщение

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

(что кстати только Павел написал /*про правильное планирование структуры папок*/, за что ему плюсик в карму)

Да, конечно, Павел абсолютно прав, говоря про правильное планирование. Тут можно привести примерно такое сравнение двух подходов: в NW/OES я могу смэпировать одну буковку в корень тома, и раздав на нём нужные права (в файловой системе), добиться необходимого уровня видимости/доступа папок/файлов, а на венде нечто подобное могу изобразить, создав нужную структуру не папок в файловой системе, а шар. И тогда при открытии \\SERVER\ я увижу список расшаренных ресурсов - подобно тому, как в NW, смэпировавшись в корень тома, я увижу папки первого уровня с соотв. правами на файловой системе.

И в NW, в силу указанных выше особенностей, принято и удобно разграничивать права в файловой системе. В венде правильнее ваш подход - "крупные" отдельные шары, зачастую действительно обходясь без DACL в NTFS. Собственно, о чём тут спорить и холиварить? Каждый инструмент нужно использовать адекватно, в соответствие с его предназначением и спецификой.

И, пожалуй, таки соглашусь с вашим "вот это как раз под вопросом" - очень часто вендоадмины не имеют достаточной квалификации для работы с имеющимся в их распоряжении инструментарием. До сих вспоминаю свою дискуссию с одним сертифицированным по самою не могу админом, который не знал, что групповые политики родными средствами венды можно назначать мельче, чем на OU (в венде: OU - domain - site, в NW (zenworks): user - group - OU).

Больше всего удивило в той ситуации количество принявших самое активное участие в дискуссии вендоадминов, очень многие из которых имели сертификаты от M$, которые впервые про это услышали только в той самой дискуссии. Я потом припоминал курсы, которых мне немало довелось проводить по M$-технологиям (2279 так просто снился) - и ведь действительно, в разделе про групповые политики (с практикой, с флешевыми анимациями для изучения блокирования, форсирования gp и т.п.), никогда даже не намекалось на то, что можно GP назначить хоть на группу юзеров, хоть на отдельного юзера. Как и не говорилось (другая тема) о серьёзных проблемах, если внутренний домен сделать не совпадающим с "внешним" и назвать его (как венда предлагала ПО УМОЛЧАНИЮ) .local.

Из той дискуссии запомнилось решение, которое "знатоки" озвучили практически с ходу: переносить пользователей между OU, на которые назначены нужные GP. Потрясающе

Кстати, возвращаясь к NTFS, вспомнил, что теперешний порядок (приоритеты):

• Explicit Deny
• Explicit Allow
• Inherited Deny
• Inherited Allow

когда-то был другим (в NT4 - точно, в win2000 - не помню) - там DENY, даже унаследованный, имел приоритет перед explicity ALLOW. Что было не очень логично, согласитесь. Более того, в API была некая идеологическая ошибка, когда можно было получить вообще недетерминированный порядок проверки явных-унаследованных DENY-ALLOW, получая в итоге неконсистентные права желаемые и реальные.

[Clericos]

Как и не говорилось (другая тема) о серьёзных проблемах, если внутренний домен сделать не совпадающим с "внешним" и назвать его (как венда предлагала ПО УМОЛЧАНИЮ) .local.

Это, кстати, отдельная интересная тема для обсуждения.

Насколько я помню: MS в официальных MS книгах (и видимо на курсах, но тут вам виднее) рекомендует купить отдельный домен чисто для домена AD. Т.е. если фирма пользуется доменом в интернете firma.ru - купить домен, например, firmacorp.ru и создать на нём домен AD (для сайта его не использовать).

В то же время в некоторых НЕ MS книгах проскакивает практика firma.local. И вообще .local повсеместно распространен де-факто.

Несмотря на частые утверждения на форумах о вреде .local, я лично (может и ошибочно) пришёл к выводу, что "firma.local" лучшее решение, которое доставит как раз наименьшее количество проблем. Хотя firma.ru тоже не страшно, просто придётся постоянно поддерживать актуальность DNS "A" записей для firma.ru и www.firma.ru что не есть хорошо.

Единственный смертный грех в AD - это Single level domain, т.е. домен с названием просто "firma". Вот так не надо делать.

Я потом припоминал курсы, которых мне немало довелось проводить по M$-технологиям (2279 так просто снился) - и ведь действительно, в разделе про групповые политики (с практикой, с флешевыми анимациями для изучения блокирования, форсирования gp и т.п.), никогда даже не намекалось на то, что можно GP назначить хоть на группу юзеров, хоть на отдельного юзера.

Ну да. Тема просто плоха раскрыта в учебниках. Я сам об этом узнал то ли в интернете то ли в книжке какой-то. Оказалось что групповые политики тоже имеют ACL (вкладку безопасность) и можно как запретить некоторым пользователям/группам её читать (применять), так и выдать доступ только нужной группе пользователей. Это вопрос к MS - почему они плохо пиарят эту возможность...

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

Как и не говорилось (другая тема) о серьёзных проблемах, если внутренний домен сделать не совпадающим с "внешним" и назвать его (как венда предлагала ПО УМОЛЧАНИЮ) .local.

Это, кстати, отдельная интересная тема для обсуждения.

Насколько я помню: MS в официальных MS книгах (и видимо на курсах, но тут вам виднее) рекомендует купить отдельный домен чисто для домена AD. Т.е. если фирма пользуется доменом в интернете firma.ru - купить домен, например, firmacorp.ru и создать на нём домен AD (для сайта его не использовать).

В то же время в некоторых НЕ MS книгах проскакивает практика firma.local. И вообще .local повсеместно распространен де-факто.

Несмотря на частые утверждения на форумах о вреде .local, я лично (может и ошибочно) пришёл к выводу, что "firma.local" лучшее решение, которое доставит как раз наименьшее количество проблем. Хотя firma.ru тоже не страшно, просто придётся постоянно поддерживать актуальность DNS "A" записей для firma.ru и http://www.firma.ru что не есть хорошо.

Единственный смертный грех в AD - это Single level domain, т.е. домен с названием просто "firma". Вот так не надо делать.

С single level domain была фантастическая засада во времена 2003 (после какого-то сервис-пака). После этого стали категорически не рекомендовать его использовать. До этого считалось допустимым.

А по поводу внутренних/внешних доменов - согласно официальным курсам от M$ (в частности, 2278) есть три варианта, которые с точки зрения M$ имеют свои достоинства и недостатки и фактически какбэ равноценны:

1. Совершенно другой домен (н-р, "внешний" firma.ru, "внутренний" myfirma.local);
2. "Внутренний" как поддомен для "внешнего": "внешний" firma.ru, "внутренний" - corp.firma.ru;
3. Split-DNS - одинаковые "внешний" и "внутренний" домены: firma.ru.

На мой взгляд самый удобный и правильный - 3-ий. Да, чуть больше возни, для организации splitDNS, н-р (если говорить о DNS-сервере от M$, то они не умеют view, и сплит делается на физически разных серверах). Но в итоге не возникнет проблем, н-р, с сертификатами (если имена разные, то и сертификаты тоже должны быть разными). Не зря в серьёзных приличных конторах обычно используется именно вариант три, н-р, в ЦЕРНЕ: там и снаружи и внутри домен один - cern.ch. Правда недавно ЦЕРН получил свой собственный TLD - cern (можно зайти на home.cern), понятно, что свой AD они уже переделывать точно не будут, фактически перейдут к п.1.

Кстати, вспомнилось: M$ в своих курсах очень любят рассказывать про леса, федерации и т.п. развесистые структуры, не то что у Новела - одиночное скромное дерево . Но сами, в своей внутрикорпоративной сети, сидят ровно в ОДНОМ домене, признавая в кулуарах, что многодоменные структуры имеют серьёзные проблемы на практике, н-р, с репликациями (в решении одной такой проблемы доводилось принимать участие, когда "тяжёлая артиллерия" от M$ просидела у заказчика (Москва, Новосибирск, Барнаул) больше месяца, борясь с траблами синхронизации в конторе с развесистой распределённой структурой AD). Эпическая была битва (а людям при этом ещё и работать надо было ) - кончилось всё довольно неожиданно: переехали на однодоменную структуру (сайты (те, что микрософтовские, а не DNS), естественно, сразу были задействованы, и в многодоменной структуре). Как удалось под пытками выяснить у одного из гуру из Редмонта, они попадали на какую-то проблему с их DDNS, которая там присутствует by design в идеологии реплик. Рассказано было на условиях "я этого не говорил"

А по поводу TLD .local - неплохо возможные проблемы описаны в википедии: .local. Очень характерный момент, что чуть ли не в одном документе M$ то рекомендует использовать .local, то пишет "we do not recommend using unregistered suffixes, such as .local". Именно за .local, конечно, надо отдельно благодарить Apple, с их mDNS (бонжюр).

Ну да. Тема просто плоха раскрыта в учебниках. Я сам об этом узнал то ли в интернете то ли в книжке какой-то. Оказалось что групповые политики тоже имеют ACL (вкладку безопасность) и можно как запретить некоторым пользователям/группам её читать (применять), так и выдать доступ только нужной группе пользователей. Это вопрос к MS - почему они плохо пиарят эту возможность...

GP имеет две части - в AD и в файловой системе, и, совершенно естественно, это даёт возможность использовать для неё ACL - никакой магии. Действительно странно, что в официальных курсах про это даже не упоминается.

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

Коллеги!
В AD групповые политики действительно привязываются только к объектам типа сайт, домен и OU.
Но можно через ж..., то есть разрешения/запреты (вложенная ж...) оставить/отобрать возможность ее применить к группам и отдельным пользователям. Таким образом групповую политику можно сделать более избирательной в применении. Это в курсах рассказывается давно - в какой версии началось - не помню.
Но это ж не так как в NDS/eDir'e, когда что-то назначить можно на все дерево, контейнер любого уровня, группу или отдельного пользователя!
Сейчас я еще и линуксовые курсы веду - тут вообще у каждого производителя дистрибутива свои "особенности".
Еще раз озвучу свою мысль - мы давно работаем в гетерогенных средах, поэтому в любой из них стоит умело использовать их сильные стороны и стараться избегать слабых. Нет одного абсолютно всех устраивающего решения, поэтому учиться будем всему и улучшать свои системы постоянно.
Мне всегда импонировала позиция Новелл: "Используйте то лучшее, что подходит для решения ваших задач, а мы поможем вам это интегрировать!"

[Иван Левшин aka Ivan L.]

Оффтопик моде он

Прям Дэн Браун и теория заговора Нескучная, как я погляжу, у вендоадминов жизнь-то. Оказывается, на практике-то TCO не так уж и заманчив, как в их буклетах нарисовано? Я примерно представляю стоимость часа работы Field Engineer "от самого редмонда", да еще и со значком "гуру". Финдиректор должен был облезть многократно.

Оффтоп закончил.