Здравая мысль в порядке бреда

А, да, профиты - SSO, возможность ввести в домен даже всякие Home/starter edition, избавляемость от виндового сервера как класса вообще.

Велосипед знатный, но годный. Потом непременно расскажите о результатах.

work-in-progress, 70% complete

А можно ссылку? Или это ты сам делаешь и ещё никуда не выложил?

4. Поднимаем на винде сервис, который автоматом заводит учетки юзеров и групп, беря их из LDAP и синхронизировала содержание групп [work-in-progress, 70% complete]

А вот тут может возникнуть косяк во взаимодействии непосредственно между вендокомпьютерами. Из-за того, что SID'ы разные...

Не возникнет. В керберосном режиме они SID'ами не обмениваются.

Интересно, не знал.

Или это ты сам делаешь и ещё никуда не выложил?

Сам делаю, сейчас тестирую - у меня уже работает синхронизация юзеров, групп и членства в группах. Осталось обернуть это дело в обертку сервиса и написать инсталятор.

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

Реквестирую манула. Сейчас как раз есть подопытный домен, а вендосервер раздражает своей прожорливостью и бесполезностью.

Глянь FreeIPA, вроде бы тоже самое, только не уверен есть ли синхронизация учёток на компах в Kerberos

самбой 3 в виде нт4 домена

Ещё один. Повторюсь - я хочу _вообще_ избавиться от термина «домена» и необходимости в самбе. _В_приципе_

И всё - у нас есть живой SSO без самбы

и без сети?

это очень полезная и нужная штука :)

Задача подразумевает изрядное количество виндовых машин. Тогда есть вариант 2: отправляем все компы в АД, получаем SSO, «видны все юзеры» и т.п, те же политики для неблагонадёжных пользователей, вполне надёжный ldap/kerberos для всяких своих нужд, по цене невменяемого количества аттрибутов в ldap, и необходимости устанавливать smb-common на серверах перед некоторыми операциями, и 2х «лишних» виндовзов. Чем это хуже?

отправляем все компы в АД

Предварительно закупив и установив на все компы Windows 7 Porfessional или Ultimate, ага. Ну и еще заплатив за Windows Server 2008R2. А чо, деньги нужны чтобы их тратить, верно?

А зачем ставить целью именно избавление от домена? Особенно в свете того, что он и сделан для облегчения администрирования?
То, что в топике заменяется 3й самбой, 4я с АДом уже в 18й альфе и скоро вполне себе будет энтерпрайзненькой.
Так что винсервер и не нужен. Экономия при приобретении хоум вместо про клиентов? Так поддержка домена это не все отличия, из-за которых пользовать хоум неудобно.

А лицензия хоум разве позволяет подобное использование?

подобное использование

Какое именно?
Если мутить, как того хочет ТС - да пожалуйста, есть же/были сторонние DS под винду. А подключать её к вендодомену просто так невозможно - повырезано всё, так или иначе придётся переделывать её в про, чему она(XP по крайней мере) активно сопротивляется и без нового серийника при этом не работает.

Плюсую этого автора.

Позволяет. Работайте на здоровье. Только AD работать не будет.

Я имел ввиду лицензионные ограничения.

Погуглил, пишут, что ограничений нет, ок.

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

Вообще говоря костылизм - это виндовые домены. Собственно виндомены это костыли от MS навернутые вокруг kerberos+ldap. Просто на определенном этапе пошел классический embrace&extend когда MS вносит кривизну, мелкие изменения, таким образом что бы затруднить использование оригинального открытого стандарта не софтом от MS.

То есть, фактически, данное предложение хорошо тем что исправляет не то что сделано прямыми руками, то есть kerberos&LDAP , а то что сделано кривыми руками на костылях.

Я думаю что решения аналогичные данному не стали популярными ( и вообще ситуация не стала развиваться в этом направлении) потому что нужно будет массово делать на винде пункты 4,5. А «поддержка домена» вроде как это и есть в том числе 4,5 только от самой MS ну и за соотв. деньги.

В вики!

потому что нужно будет массово делать на винде пункты 4,5

А чем запуск opendirectory_setup.exe /u:defaults.cfg отличается от «My computer -> Properties -> Computer name -> Change -> Domain ...» ???

В смысле? Сначала сделать надо, а уж потом «в вики» :-)

П.5 - фигня, домен тоже надо настраивать.
А вот п.4 мне и не нравится тем, что на клиентах будет заведена куча пользователей. В идеале они должны получаться удалённо, как афаик делала нетварь в своё время. Но она емнип заменяла winlogon.

В смысле? Сначала сделать надо, а уж потом «в вики» :-)

Я так, заранее :) А то вдруг забудешь.

В идеале они должны получаться удалённо, как афаик делала нетварь в своё время

Если память мне не изменяет, то нифига подобного. При логине она автоматически логинилась в винду под именем юзера, совпадающим с именем нетварьского юзера и с паролем нетварьского юзера. А если такового не было - спрашивала «А под каким юзером тебя в винду запускать?». И при смене пароля был крыжик «сменить также пароль соответствующего виндового юзера».

А чтобы не было на компах кучи локальных юзеров, народ использовал виндовый домен (домен NT4 или AD) и нетварьский логин. Это походу связано с тем, что нормального NSS как в юниксах на винде так никогда и не было - enum юзеров был реализован в SAM, а нужных хуков чтобы туда подцепиться не было.

А чем запуск opendirectory_setup.exe /u:defaults.cfg отличается от «My computer -> Properties -> Computer name -> Change -> Domain ...» ???

Именно тем что нужно сначала сделать opendirectory_setup.exe , а потом залезть в My computer -> opendirectory -> xxx -> yyy . И opendirectory_setup.exe в случае венды банально идет в составе дистрибутива, и он совместимый.

При чем для сети opendirectory нужен умный админ который сгенерит defaults.cfg а что бы настроит домен в его примитивных формах, емнип, нужен админ не такой умный. easy of use на начальном этапе - обычно один из ключевых моментов для принятия технологии.

Если резюмировать - в этой схеме есть банальный лишний барьер, это раз.

Два, и самое главное - вендовые домены не распространились сами. Их продавила огромная сеть интеграторов-партнеров MS, внедренцев и тп. Собственно сами домены фактически существуют в такой форме для большего удобства их пропихивания.

PS
Сама идея на тему того что «войну нужно переносить на территорию противника» она архиверная. Но она должна комплексно решатся, не «„счас пихнем скриптов. В том числе и комбайнами с линукс стороны.

Грубо говоря нужно решение легкое и безгиморное. *Более* легкое и безгиморное чем у MS, в *комплексе* И сейчас такого на стороне линукса(юникса) просто нет.

Грубо говоря нужно решение легкое и безгиморное. *Более* легкое и безгиморное чем у MS, в *комплексе* И сейчас такого на стороне линукса(юникса) просто нет.

А есть проекты, двигающиеся в этом направлении?

Именно тем что нужно сначала сделать opendirectory_setup.exe

А вот это я сейчас и делаю :-) Почти сделал, точнее. Сейчас только разберусь как вендовый сервис на C# написать, и заверну в красивую обертку «пре-альфу версии 0.1» :-)

work-in-progress, 70% complete

А можно ссылку? Или это ты сам делаешь и ещё никуда не выложил?

Двачую данного оратора

Там всё просто. Проще просто некуда.

4. Поднимаем на винде сервис, который автоматом заводит учетки юзеров и групп, беря их из LDAP и синхронизировала содержание групп [work-in-progress, 70% complete]

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

Вот кстати, в плане ликбеза, есть ли для линукса толковые варианты реализации SSO/политик безопасности и подобного Ынтерпрайза?

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

Можно, конечно, сделать свою реализацию домена для винды, которая бы выглядела и действовала как доменный клиент. Только вот геморрою дохрена.

Она называется SAMBA. Ж;-)

Как при такой схеме централизованно рулить ресурсами сети?

неа, самба - это серверная часть, а то, что делает no-dashi это именно клиентская часть, для клиентской винды.

и получать определённые права

Нету такого АФАИК. В немалой степени из-за зоопарка софта. Выходом могли бы стать высокоуровневые политики, которые бы для применения на локальной машине превращались бы в кучу скриптов для управления установленным у клиента софтом.

В каком месте «кучу» если оно полностью все прикуривает с сервера, включая удаление объектов, причем только при 100% уверенности в цельности полученных данных?

Насколько я понимаю, это можно бы сделать через тот-же SELinux/AppArmor, только вот грамотная автоматическая настройка этого добра - дело непростое.

вендовый сервис на _C#_

Oh noes!!
<Картинка с Вейдером/>

Здрасте... Это я с серверной части сейчас сижу на машине с Linux в домене AD? SAMBA, вообще-то, с обеих сторон работает...

sssd рулит всем стеком аутентификации, consolekit помогает в авторизации. А как сделать скрипт что будет вытягивать архив конфигов - наверное сам сообразишь :-)

В каком месте «кучу» если оно полностью все прикуривает с сервера, включая удаление объектов, причем только при 100% уверенности в цельности полученных данных?

Нет ничего, на 100% надёжного и работоспособного. И если этот костыль почему-то сломается (тривиальный вариант - очень умный пользователь поменял себе пароль локально или снёс «лишнюю» учётную запись) - начинаются проблемы. Это просто навскидку.

В топике разговор вроде шёл про виндовых клиентов. Или я неправильно распарсил твоё сообщение

Посмотрите в качестве инсталятора на WIX, msi пакеты, да XML, да ад, зато open source, инсталятор virtualbox как раз юзает сабж.

Да дело это не столько сложное, сколько хлопотное и кропотливое.
Опять же вопрос - SELinux, AppArmor юниксовые права или ещё что-то? А может просто ярлычок у юзера удалить? =)
Как быть с ДЕ? Если рулить правами через MAC/RBAC, надо эти права как-то отражать в разных средах.