proNovell

Коллеги!

Позвольте опубликовать последний мой пост на данном форуме. Заказчик полностью отказался от продуктов Новел, в следствии чего стоят в ожидании последней команды три сервера с уже загашенными службами.

Что могу сказать после почти годичного практически полной миграции на МС?
Кроме интереса к самому процессу перехода получили полностью вывернутые наизнанку мозги (раздача прав на папки и каталоги, выставление аттрибутов на запрет удаление и переименование), крайне неудобный интерфейс по службе печати печати (хрен пойми что за принтер - все разнесено по станциям-серверам_печати), периодический вылет кластеров почтовой системы и выпадение из-под контроля (наблюдения) почти половины служб. Имеется ввиду только штатные средства.

Порадовали - Линк (Lync), и феерические средства получения отчетов и прочей ерунды.

Так, что "прощайте, товарищи, с богом, уррра!"

так и надо этому заказчику

Олжас -хорошее то, что они, заказчики 100% будут чаще нуждаться в Вас.

В этих вопросах естественно интересно и мнение принимающей(руководства заказчика) - получили они то, что хотели или нет.

давненько разговаривал с админом Авдеевского Коксохимзавода. они мигрировали на MS (в том числе и с groupwise) . от него не слышалособых матюков или ругани по тому, что они получили..

По старой памяти решил зайти на форум, хотя сам уже давно отодвинут от новелловских продуктов и , в принципе, администрирования .. Ну, да се ля ви.

Олжас,
у вас должно быть это свежо и в первых задачах.

Вы решали следующую задачу, - как для файлового сервера на виндовз сделать так, чтобы по_умолчанию у создателя папки/файла (owner-а) не было прав на раздачу прав ? (смена разрешений, смена владельца) Можно ли в принципе?

Уже не помню точно, но, кажется, такая задача на нетвари решалась очень просто..

Lab писал(а): такая задача на нетвари решалась очень просто..

Хм... - Access Control ??

Lab писал(а): как для файлового сервера на виндовз сделать так, чтобы по_умолчанию у создателя папки/файла (owner-а) не было прав на раздачу прав ? (смена разрешений, смена владельца) Можно ли в принципе?

Для расшариваемой папки отключить наследование сверху, убрать все упоминания о Creator/Owner и принудительно перезаписать все разрешения вниз по дереву папок.
Не нужно пользоваться правами на уровне шары. Для шары ставите чтение-запись. Всё остальное на уровне NTFS.

Тут уже ответили в принципе. Могу от себя только заметить, что нужно мировоззрение поменять для АД - потому как АД - это вывернутое наизнанку Дерево. Понять сразу сложно, но придется. Больше всего раздражает - время реакции на практически любые действия в АД. Может быть, если бы у нас были права донастроить все, то оно было бы нормально и быстро, но ситуация пока такова...

Сулейменов Олжас писал(а):Тут уже ответили в принципе. Могу от себя только заметить, что нужно мировоззрение поменять для АД - потому как АД - это вывернутое наизнанку Дерево. Понять сразу сложно, но придется. Больше всего раздражает - время реакции на практически любые действия в АД. Может быть, если бы у нас были права донастроить все, то оно было бы нормально и быстро, но ситуация пока такова...

По поводу мировоззрения согласен.
AD - это просто ДРУГОЕ дерево, а не вывернутое наизнанку. Как раз относительно реальности, ситуация скорее в том, что у специалистов по продуктам Novell сознание вывернуто относительно действительности.
Вместо того, чтобы почитать книги или посетить курсы по базовому траблшутингу, специалисты Novell пробуют работать с AD как с eDir. И наступают на грабли, которые специалисты по AD даже не понимают и не сталкиваются.

Работаю с AD и меня она всем устраивает. И назначение прав NTFS устраивает. ЧЯДНТ?

А что за "Больше всего раздражает - время реакции на практически любые действия в АД"? Как-то не сталкивался и не совсем понимаю о чем вы.

Тут как раз все в порядке - и книжки читали и курсы первичные прошли. Если спецов АДовых посадить за Дерево, у них тоже будут затыки, но дело не в этом, ведь я не сравниваю эти продукты, а высказываю свое (и не только) мнение об удобстве администрирования.

Время реакции таково, что права, выданные на ресурс не сразу падают в раздачу, хосты в домене после корректного ввода не сразу отдаются в управление. Опять-таки напомню, что нам отданы только службы в поддержку, сами сервера и домен АД не в нашем рулеже, может, и поэтому нестыковок много. Да и однодоменная структура с удаленностью 9 филиалов до 300 км друг от друга тоже сказывается.

Тем не менее, плавание продолжается. Всем спасибо!

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.

Сулейменов Олжас писал(а):Да и однодоменная структура с удаленностью 9 филиалов до 300 км друг от друга тоже сказывается.

Вот это-то как раз не проблема - проблемой было бы, если бы у вас было 9 доменов - замучались бы с доверительными отношениями и ADFS. А так - только следить за мультисайтовой репликацией. Здесь тоже подводных камней много, если сайтов такое количество, вполне возможно, что стоит подумать об уменьшении их количества.

Timur Kazimirov писал(а):

Сулейменов Олжас писал(а):Да и однодоменная структура с удаленностью 9 филиалов до 300 км друг от друга тоже сказывается.

Вот это-то как раз не проблема - проблемой было бы, если бы у вас было 9 доменов - замучались бы с доверительными отношениями и ADFS.

А смысл использования ADFS в этом случае? Все девять доменов объединяешь в один лес - и никаких федераций. Федеративный сервис - это связь между совсем уж слабо связанными сущностями, типично - обеспечение ограниченного доступа юзеров одной фирмы к ресурсам другой. А тут речь про филиалы одной конторы. Это - в лес

Timur Kazimirov писал(а):А так - только следить за мультисайтовой репликацией. Здесь тоже подводных камней много, если сайтов такое количество, вполне возможно, что стоит подумать об уменьшении их количества.

Да уж, про межсайтовую репликацию на территориально разнесённых площадках можно много нехороших слов написать . Типичный пример: приехал человек с ноутом из московского головного офиса в какой-нибудь удалённый филиал - и логин в домен у него вместо обычных нескольких секунд начинает минут по 20-30 выполняться. Механизм репликаций у M$ - это нечто (если внимательно покопаться в низкоуровневой технологии). В WS2012 главные проблемы грозятся принципиально забороть...

Сергей Дубров писал(а):А смысл использования ADFS в этом случае? Все девять доменов объединяешь в один лес - и никаких федераций.

Да уж. Задача просто тривиальна - 9 доменов в лес объединить, ага. Тут два домена совместно со спецами из МС уже два года объединяют, а конца и краю не видно...

Timur Kazimirov писал(а):

Сергей Дубров писал(а):А смысл использования ADFS в этом случае? Все девять доменов объединяешь в один лес - и никаких федераций.

Да уж. Задача просто тривиальна - 9 доменов в лес объединить, ага. Тут два домена совместно со спецами из МС уже два года объединяют, а конца и краю не видно...

Да я какбэ про то же и говорю - распределённые решения от M$ - тот ещё геморрой. Поэтому мне было непонятен смысл привлечения ещё одной сущности, озвученной здесь - ADFS, если даже в едином лесу проблем выше крыши. С помощью M$, действительно, и в двух доменах заблудиться можно . Характерный момент: у самой M$ - всё в одном домене. И это "ж-ж-ж" неспроста .

Хм, тут подумал - а ведь ADFS, вероятно, может спасти в некоторых распределённых конфигурациях - это ведь слабосвязанные сущности, там как раз никаких репликаций головной офис<->филиалы не требуется. Но там другие головные боли практически гарантированы... Нет в жизни счастья

Про леса-домены - вспоминается "любимый" микрософтовский курс 2279 (проводил его раз десять, не меньше), там как раз много игрищ с многодоменными конфигурациями приходится делать. И был у меня рекорд - то ли 8, то ли 10 доменов (два инструкторских плюс по домену на каждую пару студенческих серверов) в одном лесе. Всё в локальной сети, расстояния - максимум три-четыре метра между машинами, работающими через один коммутатор. И даже там возникали серьёзные проблемы с репликациями и синхронизацией. До смешного доходило: две пары студентов делают домен-поддомен - всё быстренько проходит, работает, у третьей пары - хоть тресни, не идут репликации, ни с какими бубнами (типа перезагрузок netlogon-а и т.п.). Иногда помогал вовремя устроенный перерыв, приходишь после обеда - о, репликации "проросли", но не всегда так везло - было пару случаев, когда репликации так до конца дня и не оживали. Мистика...

Сергей Дубров писал(а):Но там другие головные боли практически гарантированы... Нет в жизни счастья

Какое тут счастье... Геморрой сплошной