Попытка подключиться к общему сетевому ресурсу на сервере Samba из Windows Server 2019, поскольку учетная запись SYSTEM приводит к The password is invalid for \\server\share затем запрос на новый. Ожидаемый результат The command completed successfully.
Когда я пытаюсь подключиться к общему ресурсу, журнал машины на сервере Samba показывает:
get_user_from_kerberos_info: Username DOMAIN\COMPUTER$ is invalid on this system
Возникает вопрос: почему? Как я могу разрешить рядовому серверу аутентифицировать учетную запись компьютера?
Недавно я перенастроил сервер Samba (v4.5.16) и присоединил его к домену Active Directory на базе Samba на функциональном уровне 2008 R2. Я создал поделиться с помощью Windows ACL, предоставляя разрешения NTFS на чтение и выполнение для прошедших проверку пользователей и компьютеров домена, а также для всех пользователей с полным доступом к общему ресурсу. Просмотр и net useТестирование проходит нормально с учетной записью обычного пользователя в Windows 2019. Все хорошо и красиво.
НО! Поскольку этот общий ресурс содержит установочные файлы для развертывания программного обеспечения с помощью объектов групповой политики (GPO), он также должен быть доступен для учетных записей компьютеров (например, COMPUTER $). Но, по-видимому, это не так, несмотря на то, что также предоставляются разрешения на чтение для всех. Я тестирую с
psexec -i -s cmd.exe
net use \\server\share /user:%computername%$
... и вот тогда я вижу проблему.
Я также включил Ведение журнала установщика Windows который просто говорит источник (\\server\share\path\to\installer) является недействительным.
До этого все было нормально (программное обеспечение успешно развертывалось при запуске) со старыми машинами Windows (2003-2008), поскольку для общего ресурса был включен гостевой доступ, но Windows 10+ и 2016+ больше не допускают этого по умолчанию. (Я проверил позволяя это тоже, но это привело только к тому же запросу пароля.)
FWIW, член домена Samba, на котором размещается этот общий ресурс, настроен на использование серверная часть idmap объявления с опцией RFC2307. В результате я попытался добавить uidNumber в учетную запись компьютера в домене, но это не дало результата.
Я здесь на грани ума, потратив большую часть двух дней на поиск, тестирование, проклятия и т. Д., Так что теперь я смиренно ищу коллективную мудрость ServerFault.
Спасибо за ваше время и внимание!
Во-первых, я прошу прощения за то, что не поместил это в комментарий, но у меня недостаточно репутации для этого.
Чтобы уточнить ваш исходный пост - когда вы говорите:
В результате я попытался добавить 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 учетной записи вашего клиентского компьютера, для которой вы хотите иметь доступ к общему ресурсу как, убедитесь, что назначенный номер попадает в ваш определенный диапазон для этого домена) также будет работать для этого сценария (на самом деле я был бы очень удивлен, если бы он не сделал работай).
Наконец разобрался! При этой ошибке просто нужно создать пользователя с именем COMPUTER $ в окне Samba. Поскольку я использую серверную часть AD для idmap, мне также пришлось вручную установить uidNumber в AD в учетной записи COMPUTER $ и указать тот же uid, когда я создал пользователя UNIX, например adduser --force-badname "COMPUTER$" --uid 999000
Теперь выясним, как заставить Samba делать это автоматически, когда новый пользователь пытается аутентифицироваться в Samba ...