Назад | Перейти на главную страницу

Проблемы с аутентификацией, когда клиенты обращаются к серверу, присоединенному к домену, с DNS-имени субдомена, отличного от Samba4

У нас есть проблема, с которой мы боролись довольно долгое время с тех пор, как около 3 лет назад мы развернули 10 контроллеров домена Samba4 в нашем главном офисе и на всех удаленных сайтах.

Упрощенная текущая конфигурация:

В этой конфигурации мы настроили внутренние серверы BIND так, чтобы внутренние DNS контроллеров домена AD S4 были полномочными для ad.companyname.com, поэтому клиенты, подключенные к серверам BIND, могут разрешать любые запросы Samba. Это позволяет всем клиентским машинам в локальной сети разрешать любой динамический DNS-адрес, создаваемый AD, присоединяться к домену и т. Д., И его легко настроить при инициализации новых контроллеров домена. (Это важно при таком большом количестве контроллеров домена).

Когда мы предоставляем серверы, которые привязаны к домену, клиенты получают к ним доступ через записи DNS, настроенные на основных DNS-серверах BIND, поэтому у них есть адреса, такие как hostname.companyname.com, которые клиенты используют для подключения к серверам / службам. У них также есть имена хостов ad.companyname.com, созданные внутренней DNS S4, но мы не указываем клиентам эти имена.

Эта проблема:

Некоторым службам (в основном, серверам OS X, которые мы заметили до сих пор), когда они привязаны к AD, похоже, не нравится, когда клиенты указывают на другое DNS-имя, отличное от поддомена samba. Например:

OS X 10.11 (также пробовал 10.6) Сервер, связанный с AD, на котором запущен файловый сервер SMB:

Другой пример:

OS X Server 10.11, привязанный к AD, на котором запущен Profile Manager:

Ноты:

В первом примере одно из решений - просто указать клиентам на fileserver.ad.companyname.com, но руководство сопротивляется этой идее. Во втором примере для диспетчера профилей MDM сервер находится в DMZ, поэтому клиенты за пределами кампуса по-прежнему подключаются к MDM, и он имеет как внутренние, так и внешние записи DNS, поэтому наличие общедоступного адреса ad.companyname.com не является отличный вариант.

Вопросы: