Я понимаю, что название, вероятно, менее понятно, чем должно быть, но я не мог придумать ничего лучше.
У нас есть два домена, назовем их example.com и subnet.example.com. Первый управляется сервером Active Directory и содержит некоторые серверы, а также все клиенты Windows. В последнем находится несколько Unix-машин (в основном Solaris). Есть одностороннее доверие из области SUBNET.EXAMPLE.COM к EXAMPLE.COM.
При такой настройке обычные вещи работают нормально, например, вход по ssh, NFSv4 и т. Д.
Теперь я хочу иметь возможность запускать серверы Samba на машинах Unix в subnet.example.com. Пользователи Windows должны иметь доступ к файлам на этих серверах.
Я настроил аутентификацию Kerberos в Samba, и она отлично работает с любым клиентом Linux. Я могу получить доступ к машинам через smbclient когда у меня есть Kerberos TGT, и он перестает работать, если я его уроню. Сопоставление пользователей работает точно так, как ожидалось. Машины имеют cifs/hostname записи на сервере MIT Kerberos.
Однако клиенты Windows не могут сделать то же самое. Просматривая журналы Samba, я вижу, что сервер Samba пытается связаться с сервером AD, но ему не разрешено это делать, поскольку сервер Samba не присоединился к домену AD.
Итак, я слышал, вы спрашиваете: «Почему бы вам просто не присоединиться к домену AD?». Ответ заключается в том, что я не могу этого сделать, поскольку системы в подсети - это тестовые системы, которые устанавливаются и переустанавливаются, часто много раз в день, и мы не хотим, чтобы администратор AD настраивал это (и удалял их а также) каждый раз, когда тестовая система устанавливается или отключается.
Кроме того, все работает идеально для клиентов Linux, что наводит меня на мысль, что это должно быть возможно как-то заставить это работать.
Итак, мой вопрос: возможно ли это вообще? Есть ли какие-то ограничения в Windows, которые мешают им быть клиентами в обычной сфере Kerberos? Если да, то как лучше всего решить эту проблему?
Я решил проблему. Проблема заключалась в том, что клиент Windows не знал, что subnet.example.com принадлежит другому царству. Решение - сообщить об этом клиенту. Это можно сделать с помощью следующих двух команд, которые, как мне кажется, похожи на добавление информации о домене в krb5.conf в системе Unix:
ksetup /addkdc SUBNET.EXAMPLE.COM hostname.of.kerberos.server
ksetup /addhosttorealmmap .subnet.example.com SUBNET.EXAMPLE.COM
После того, как я это сделал, аутентификация клиента работала должным образом.