идентификация машинного клиента в samba

- зачем машинные аккаунты нужны, как таковые?

Затем, что доверие между компьютерами домена строятся на них.

можно ли заставить самбу при логоне доменного пользователя проверять валидность машинного аккаунта клиентского хоста?

Она и так это делает. При входе в домен.

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

Ровно так же себя ведет классический домен.

Более того, самба без вопросов пустит «локального» пользователя, если у такового совпадают логин и пароль с каким-либо доменным пользователем.

map untrusted to domain (G)

If a client connects to smbd using an untrusted domain name, such
as BOGUS\user, smbd replaces the BOGUS domain with it's SAM name
before attempting to authenticate that user. In the case where smbd
is acting as a PDC this will be DOMAIN\user. In the case where smbd
is acting as a domain member server or a standalone server this
will be WORKSTATION\user.

In previous versions of Samba (pre 3.4), if smbd was acting as a
domain member server, the BOGUS domain name would instead be
replaced by the primary domain which smbd was a member of. In this
case authentication would be deferred off to a DC using the
credentials DOMAIN\user.

When this parameter is set to yes smbd provides the legacy behavior
of mapping untrusted domain names to the primary domain. When smbd
is not acting as a domain member server, this parameter has no
effect.

Default: map untrusted to domain = no

Не очень понятно. То есть если пользователь логинится в самбу с не введенной в домен машины, используя валидное доменное имя пользователя (вида DOMAIN\user) с правильным паролем, то его надо пускать? Или не надо? Во первом случае см. «map untrusted to domain», а во втором не знаю, по-моему такой возможности нет.

Это все хорошо. За разъяснения спасибо. Вопрос я сформулировал не очень четко, каюсь.

Уточняю вопрос. Есть возможность заставить самбу отказывать в соединении с хостов, которые не принадлежат домену (в котором она исполняет роль PDC)? Даже если используются валидные логин/пароль пользовательского аккаунта?

То, о чем ты сказал «так же себя ведет классический домен», меня не устраивает по определенным причинам.

Например, есть сеть, компы в домене, юзеры в домене, все ок. Но вот приносит некто (этакий инсайдер) ноут, настраивает на нем сетку (а если dhcp, то и настраивать особо нечего), спокойно сливает на ноут все что угодно .. ну.. в пределах досягаемости, скажем). Юзера особо логрны/пароли свои не берегут. Флехи и пр.. залочены. Но вот с таким сценарием затык.

Понятно, что административно можно пресечь. Технически как не допустить?

То, о чем ты сказал «так же себя ведет классический домен», меня не устраивает по определенным причинам.

Поскольку samba3 является совместимой реализацией классического NT4 домена, то и возможности наследует те же, если вас это не устраивает - не пользуйтесь.

Но вот приносит некто (этакий инсайдер) ноут, настраивает на нем сетку (а если dhcp, то и настраивать особо нечего),

802.11x вас спасет - подключился к сети с компьютера, который не введен в домен? Не попал в нужный vlan, не получил доступ на сетевом уровне вообще.

Не слишком категорично, дружище? Устраивает, пользуюсь.

Речь, если что, о том, как добиться требуемого результата «отказывать в соединении с хостов, которые не принадлежат домену» средствами самой самбы, а не о соответсвии в поведении NT-домену. Если есть конкретные идеи, welcome.

Про 802.11x с виланами вообще не в тему. Или поясните? Принес чел ноут, воткнул его в сеть вместо рабочего компа, и...что? При чем тут виланы?

Не слишком категорично, дружище? Устраивает, пользуюсь.
То, о чем ты сказал «так же себя ведет классический домен», меня не устраивает по определенным причинам.

Устраивает, но не устраивает.

Речь, если что, о том, как добиться требуемого результата «отказывать в соединении с хостов, которые не принадлежат домену» средствами самой самбы,

Я вроде как намекнул, что такого функционала нет и объяснил, почему.

Или поясните? Принес чел ноут, воткнул его в сеть вместо рабочего компа, и...что?

И ничего. Нет домен контроллера у него в сети у него в сети, потому что он не предъявил ключ компьютера (не авторизовался в сети).

При чем тут виланы?

При том, что когда предъявит и он совпадет, тогда его коммутатор перебросит в нужный vlan, где есть ресурсы серверов и он начнет работать.

Насколько я понимаю, в домене бегает kerberos, а следовательно, оно тебя пустит с любого ресурса, если ты просто введёшь валидный userprincipalname. Компы видимо друг-другу доверяют, и пускает без пароля так-как на компьютер генерируется какой-нибудь SPN наверно.

Тоже очень сумбурно, но в целом я думаю надо смотреть возле этого. :) Тогда начнёт наступать понимание домена как такового.

Делать аутотентификацию на порту свитча можно, можно сделать public сеть с VLAN.

Если чел. принёс в сеть не авторизованную железку - то тебе надо пользовать 802.11x, чтобы не пускать его никуда кроме страницы где будет рассказано как получить доступ к сети.

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

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

Все, благодарю, идею понял.

Если ты, например, одмин на пяти разных конторах и лазаешь с личного ноута из одной в другую, тебе что, каждый раз этот несчастный ноут из домена в домен пересовывать?

Не, доверительные отношения между доменами настраивать )

К сожалению, существующая инфраструктура предприятия не позволяет безболезненно внедрить 802.11x port-based authorization. Это решение отложено на будущее.

Я когда-то интересовался VFS-модулями (расширениями) для самбы. Сейчас это пригодилось. Т.е. есть путь реализации задачи в отельно взятом домене. Алгоритм примерно такой.

Нужен VFS-модуль (расширение) со следующим функционалом:

- на событие коннекта вешаем свой обработчик

- в обработчике получаем имя клиентского хоста

- проверяем наличие имени хоста в базе аккаунтов, нету - сразу до свидания

- имя хоста есть в базе (подделать имя не составит труда для настойчивых и не совсем тупых)

- на этот случай в обработчике делаем коннект с сервера на клиентский хост на шару smb://host/IPC$/admin$ под рутом

- если комп в домене, коннект с сервера на админскую шару клиента будет удачным, не в домене - фейл.

Как-то так. Предварительные тесты показали работоспособность решения.