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

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

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

• 2 контроллера домена на основном сайте с внутренним DNS с использованием субдомена ad.companyname.com
• 2 сервера CentOS BIND, обслуживающих все запросы DNS в интрасети - основная зона: companyname.com
• 2 BIND CentOS сервера, обслуживающие все запросы DNS внешнего сайта - основная зона: companyname.com

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

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

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

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

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

• При подключении к fileserver.companyname.com
  • Пользователь должен аутентифицироваться как ad.companyname.com\shortname ИЛИ
  • Пользователь должен аутентифицироваться как shortname@ad.companyname.com
  • Использование AD\shortname не работает
• При подключении к fileserver.ad.companyname.com
  • Пользователь может аутентифицироваться как просто короткое имя

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

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

• Пользователи могут проходить аутентификацию в веб-интерфейсе PHP, используя только краткое имя
• Пользователи не могут проходить аутентификацию во время регистрации на устройстве iOS с использованием своих учетных данных AD

Заметки:

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

Вопросы:

• Поможет ли в этом настройка сервера WINS?
• Поможет ли в этом настройка домена поиска по умолчанию из DHCP?
• Есть ли какой-нибудь способ, чтобы узел Samba4 AD-Joined имел доменное имя в базовом домене (фактически, а не просто отдельную запись в BIND, указывающую на тот же IP-адрес)?
  • Если это так, возможно ли это сделать с помощью внутреннего DNS?
• Существует ли какой-либо способ интеграции DNS Samba4 AD непосредственно с настройкой DNS BIND в интрасети, чтобы присоединенные к домену хосты получали имена DNS, а не базовый домен DNS (companyname.com)?