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

Конфигурация DNS и Active Directory для филиала

У нас есть филиал, в котором нет никаких услуг на месте, и мы хотели бы это изменить. Самая большая цель - настроить несколько файловых серверов, но также приветствуются более быстрые входы в систему и разрешение DNS.

Я провожу некоторые эксперименты с некоторыми виртуальными машинами в отдельной подсети / VLAN, так что скажем, у меня есть лес и домен. domain.com:

  1. Есть единый сайт Office с подсетью 192.168.1/24 и одну первичную зону DNS domain.com
  2. Добавлен вторичный сайт TestSite с подсетью 192.168.100/24
  3. Создано 192.168.100 зона обратного просмотра в DNS
  4. Создал виртуальную машину Branch-DC01 под управлением Server 2012 с IP-адресом 192.168.100.1
  5. Добавлен к domain.com как член
  6. Установлены AD DS в качестве контроллера домена только для чтения (RODC) в TestSite
  7. Главный DNS сервер для Branch-DC01.domain.com является 127.0.0.1
  8. Настройте область DHCP для нового сервера и настройте DHCP на постоянное обновление DNS.
  9. Создано Branch-PC01 ВМ под управлением Windows 8 и добавлена ​​в domain.com
  10. Branch-PC01 получил IP-адрес 192.168.100.20 с DHCP, DNS сервера 192.168.100.1, запись для члена в зоне прямого просмотра domain.com присутствует, но не в зоне обратного просмотра (важно?)
  11. На Branch-PC01 казнен nslookup domain.com - результат вернулся с IP-адресами основного DCs из Office сайт (192.168.1 подсеть)

Теперь это не в моем уме - не должно ли это вернуться? 192.168.100.1? Или я неправильно понимаю всю концепцию - и почему вход в систему должен быть быстрее?

Нужна ли мне отдельная зона DNS (как бы это работало без поддомена, который я не хочу создавать, если не требуется)?

Любые идеи / статьи, на которые я могу указать, были бы замечательными; Я прочитал кучу статей в TechNet и ничего не понял.

Спасибо

Обновить

Большое спасибо @TheCleaner и @ charleswj81, ваши усилия оценены.

Я только что попробовал nltest, и результат такой же для DC филиала и клиентского ПК:

U:\>nltest /dsgetdc:domain.com /server:Branch-DC01.domain.com
           DC: \\Branch-DC01.domain.com
      Address: \\192.168.100.1
     Dom Guid: d97516d3-4afb-4f0a-8c3f-04a800cd69fb
     Dom Name: domain.com
  Forest Name: domain.com
 Dc Site Name: TestSite
Our Site Name: TestSite
        Flags: GC DS LDAP KDC TIMESERV DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE P
ARTIAL_SECRET WS DS_8
The command completed successfully

Обновление 2

  1. Очищены записи DNS, поэтому любые контейнеры _sites с TestSite имеют только записи SRV для Branch-DC01 который после перезапуска клиента не помог.

  2. nltest на клиенте:

    `U:> nltest /dsgetdc:domain.com

           DC: \\DC01.domain.com

  Address: \\192.168.1.3

 Dom Guid: d97516d3-4afb-4f0a-8c3f-04a800cd69fb

 Dom Name: domain.com

    Имя леса: domain.com

    Имя сайта DC: Офис

    Название нашего сайта: TestSite

        Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC DNS_DOMAIN

    DNS_FOREST FULL_SECRET WS

    Команда успешно выполнена.

Для клиента на одном сайте совершенно нормально получить разрешение DNS для домена на контроллер домена на другом сайте. Причина в том, что все A-записи «(такие же, как родительские) для зоны прямого просмотра домена. Каждый DC будет указан для домена по циклическому перебору.

Это не самый идеальный вариант для эффективности разрешения DNS (и может вызывать проблемы, если некоторые сайты недоступны), но вы можете настроить такие вещи, как DNS с геотегами, чтобы смягчить его, и это совершенно нормальное поведение. Как только клиент получит DC, любой DC, для ответа, этот DC будет использовать конфигурацию Sites and Zones, чтобы выбрать DC в своей соответствующей зоне и проинформировать клиента, чтобы он направил дальнейшие запросы к этому DC. Когда клиент входит в систему, он кэширует свой сайт и в основном использует% LOGONSERVER% для будущих транзакций.