Как разрешить учетной записи компьютера/машины аутентифицироваться на Samba AD член домена?
Проблема
Попытка подключиться к сетевому ресурсу на сервере Samba с Windows Server 2019 от имени учетной записи SYSTEM приводит к The password is invalid for \\\server\share then a prompt for a new one. Ожидаемый результат - Команда выполнена успешно.
Когда я пытаюсь подключиться к общему ресурсу, журнал для машины на сервере Samba показывает:
get_user_from_kerberos_info: Username DOMAIN\COMPUTER$ is invalid on this system
Итак, вопрос: почему? Как я могу разрешить серверу-участнику аутентифицировать учетную запись компьютера?
Предыстория
Недавно я перенастроил сервер Samba (v4.5.16) и присоединил его к домену Active Directory на базе Samba на функциональном уровне 2008 R2. Я настроил общий ресурс с помощью Windows ACLs, предоставив разрешения Read & Execute NTFS аутентифицированным пользователям и доменным компьютерам, а также всем пользователям полный контроль над ресурсом. Браузинг и использование сети отлично проверяются с учетной записью обычного пользователя на компьютере с Windows 2019. Все отлично и прекрасно.
НО! Поскольку этот ресурс содержит установочные файлы для развертывания программного обеспечения с помощью объектов групповой политики (GPO), он также должен быть доступен для учетных записей машины (например, COMPUTER$), но, по-видимому, это не так, несмотря на то, что всем предоставлены права на чтение. Я тестирую с
psexec -i -s cmd.exe
net use \\server\share /user:%computername%$
... и тут я вижу проблему.
Я также включил Windows Installer logging, который просто говорит, что источник (\\\server\share\path\to\installer) недействителен.
До этого все было в порядке (программное обеспечение успешно развертывалось при запуске) на старых машинах Windows (2003-2008), поскольку в общем ресурсе был включен гостевой доступ, но Windows 10+ и 2016+ больше не позволяют этого по умолчанию. (Я пробовал разрешить его тоже, но это привело только к тому же запросу пароля.)
FWIW, член домена Samba, размещающий этот ресурс, настроен на использование ad idmap back-end с опцией RFC2307. В результате я попробовал добавить uidNumber к учетной записи компьютера в домене, но это не дало никакого эффекта.
Я нахожусь в затруднительном положении, потратив большую часть двух дней на поиск, тестирование, проклятия и т.д., так что теперь я смиренно обращаюсь к коллективной мудрости ServerFault.
Спасибо за ваше время и внимание!
Наконец-то разобрался! С этой ошибкой нужно просто создать пользователя с именем COMPUTER $ в окне Samba. Поскольку я использую серверную часть AD для idmap, мне также пришлось вручную установить uidNumber в AD в учетной записи COMPUTER $ и указать тот же uid, когда я создал пользователя UNIX, например adduser --force-badname "COMPUTER $" --uid 999000
Теперь выясним, как заставить Samba делать это автоматически, когда новый пользователь пытается аутентифицироваться в Samba ...
Во-первых, я прошу прощения за то, что не поместил это в комментарий, но у меня недостаточно репутации для этого.
Чтобы уточнить ваш исходный пост - когда вы говорите:
В результате я попытался добавить uidNumber в учетную запись компьютера в домене, но это не дало результата.
Означает ли это, что вы пытались добавить uidNumber в учетную запись компьютера Samba Box или в учетную запись компьютера, который пытался аутентифицироваться в общей папке?
Я спрашиваю, потому что я думаю, что это может даже не понадобиться создать учетную запись COMPUTER $ на сервере Samba. Я не могу сказать наверняка с учетными записями компьютеров, но мне пришлось получить управляемую учетную запись службы, которую SQL использовал для аутентификации на общем ресурсе Samba (под управлением v4.8.5, также с использованием серверной части AD, с schema_mode rfc2307), и все, что мне нужно было сделать, это добавить атрибут uidNumber для MSA в AD, чтобы он заработал. Сделав это, я смог увидеть в журналах, что оно изменилось с сообщения
Имя пользователя DOMAIN \ MSA $ недействительно в этой системе
на:
Успешный AuthZ: [SMB2, krb5] пользователь [DOMAIN] \ [MSA $] ...
И вот так же мое задание BACKUP DATABASE из SQL (работающего как MSA) в этот общий ресурс начало работать.
Поскольку MSA обрабатываются так же, как учетные записи компьютеров, когда дело доходит до аутентификации и т.п., я не удивлюсь, если то же исправление (просто присвоение действительного uidNumber учетной записи вашего клиентского компьютера, для которой вы хотите иметь доступ к share as, убедившись, что назначенный номер попадает в указанный вами диапазон для этого домена) также подойдет для этого сценария (на самом деле я был бы очень удивлен, если бы он не работал ).