none
"правильный" контроллер домена RRS feed

  • Вопрос

  • есть головной офис (172.17.*.*) и филиал (192.168.0.*) между ними поднят vpn канал (tmg site-to-site). домен vmk.loc режим домена - 2003. в головном офисе 2 КД 
    server1 - 172.17.0.40 
    server33 - 172.17.0.92

    недавно в филиале установили КД роль rodc
    man-ad - 192.168.45

    соответственно все компьютеры ввели в домен. всё вроде нормально но заметил одну странность. если на клиенте в филиале дать команду 
    C:\>set lo
    LOGONSERVER=\\SERVER1

    т.е. клиент логинится на КД находящимся в филиале.

    даю команду 

    C:\>nltest/dsgetdc:vmk.loc /force
               DC: \\man-ad.vmk.loc
          Address: \\192.168.0.45
         Dom Guid: 8577d395-ef81-45cb-9dbf-f1d6c904f76f
         Dom Name: vmk.loc
      Forest Name: vmk.loc
     Dc Site Name: manager
    Our Site Name: manager
            Flags: GC DS LDAP KDC DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE 0x2800
    The command completed successfully

    вроде всё правильно. нашёл ближайший КД. тут же через минуту опять даю эте же команду

    C:\>nltest/dsgetdc:vmk.loc /force
               DC: \\server1.vmk.loc
          Address: \\172.17.0.40
         Dom Guid: 8577d395-ef81-45cb-9dbf-f1d6c904f76f
         Dom Name: vmk.loc
      Forest Name: vmk.loc
     Dc Site Name: Default-First-Site-Name
    Our Site Name: manager
            Flags: PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST
     CLOSE_SITE
    The command completed successfully

    и опять получаю КД в филиале.

    как можно клиентов "заставить" логиниться на ближайшем КД?

    serg

    13 марта 2013 г. 6:40

Ответы

  • >Это как и где делается? Я думал, что при привязке DC к сайтам оно само должно править нужные DNS-записи.

    Не совсем так. То, о чем задался вопросом ТС, зовется automatic site coverage, механизм при котором КД "страхуют" клиентов при регистрации, обнаруживая сайты, где менее 2х КД, и лихо прописываяюсь туда, %) дабы обслужить запросы клиентов- все сделано с благими целями. Лечится просто выключением этого механизма в настройках ГП (рядышком где Кирилл и подсказал), либо, как было верно замечено отменой регистрации конкретных записей за сайт - что тоньше и лучшее, не так топорно- можно в разных сценариях использовать разные подходы.

    > выполнил эти команды на клиенте в филиале -

    Здорово. Эти команды выполняет клиентская машина при старте, и ищет всякое в DNS- настройками выше можно ей сказать, что она должна видеть, чего нет.

    А Вы конкретно запустили nslookup, который по умолчанию зацепился за первый в списке сервер, прописанный на сетевой карточке.Как политики настроете, так записей не увидите- они просто в DNS регистрироваться не будут, вот и все.

    Самый простой вариант в Вашем сценарии- Главный офис и филиал-  отключить автоматическое обслуживание сайтов, более тонко и с заделом на будущее- рисовать записи.

    Да, кстати, у Вас DNS на rodc настроен неправильно - первым в списке д.б.  IP адрес самого сервера- т.е. 192.168.0.45


    • Изменено Dmitriy RazbornovEditor 14 марта 2013 г. 20:56 поправил опч
    • Помечено в качестве ответа sergeyk1 15 марта 2013 г. 0:04
    14 марта 2013 г. 20:01
    Отвечающий

Все ответы

  • Филиальный RODC привязан к нужному сайту? На RODC кешируются данные аккаунта пользователя?

    Сергей Панченко

    13 марта 2013 г. 6:49
  • >Филиальный RODC привязан к нужному сайту?

    да. на всякий случай его

    C:\>ipconfig/all


    Настройка протокола IP для Windows

       Имя компьютера  . . . . . . . . . : man-ad
       Основной DNS-суффикс  . . . . . . : vmk.loc
       Тип узла. . . . . . . . . . . . . : Гибридный
       IP-маршрутизация включена . . . . : Нет
       WINS-прокси включен . . . . . . . : Нет
       Порядок просмотра суффиксов DNS . : vmk.loc

    Ethernet adapter Подключение по локальной сети 3:

       DNS-суффикс подключения . . . . . :
       Описание. . . . . . . . . . . . . : Realtek PCIe GBE Family Controller
       Физический адрес. . . . . . . . . : 00-1A-4D-94-19-BD
       DHCP включен. . . . . . . . . . . : Нет
       Автонастройка включена. . . . . . : Да
       IPv4-адрес. . . . . . . . . . . . : 192.168.0.45(Основной)
       Маска подсети . . . . . . . . . . : 255.255.255.0
       Основной шлюз. . . . . . . . . : 192.168.0.1
       DNS-серверы. . . . . . . . . . . : 172.17.0.40
                                           192.168.0.45
       NetBios через TCP/IP. . . . . . . . : Включен

    Туннельный адаптер isatap.{377E423B-27AF-4A78-B43E-1DA39EFB8DCA}:

       Состояние среды. . . . . . . . : Среда передачи недоступна.
       DNS-суффикс подключения . . . . . :
       Описание. . . . . . . . . . . . . : Адаптер Microsoft ISATAP
       Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP включен. . . . . . . . . . . : Нет
       Автонастройка включена. . . . . . : Да

    ещё заметил странность, если зайти в консоль dns то во всех ветках где есть описание сайта manager (сайт филиала) есть запись ссылающаяся на server1. например

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

    >На RODC кешируются данные аккаунта пользователя?

    да. только при чём тут пользователь?


    serg


    • Изменено sergeyk1 14 марта 2013 г. 0:29
    13 марта 2013 г. 23:05
  • так и должно быть (server1 является носителем всех ролей)? или можно/нужно эти записи удалить руками?
    Удалять вручную не нужно - не поможет, следует настроить DNS-записи DC Locator, которые регистрирует контроллер и запретить КД с центральной площадки регистрировать свои записи в сайтах.
    14 марта 2013 г. 3:51
    Отвечающий
  • следует ... запретить КД с центральной площадки регистрировать свои записи в сайтах.

    Это как и где делается? Я думал, что при привязке DC к сайтам оно само должно править нужные DNS-записи. По крайней мере, у меня при переносе RODC в другой сайт все записи в зоне _sites.НУЖНЫЙ_САЙТ сами верно прописалимсь. Нельзя ли подробностей этого момента?

    Сергей Панченко


    • Изменено Daemon-GTC 14 марта 2013 г. 4:09
    14 марта 2013 г. 4:07
  • Computer Configuration/Administrative Templates/System/NetLogon/DC Locator DNS Record/DC Locator DNS Records not registered by the DCs

    Подробнее могу позже, но нужно добраться до компа.

    http://blogs.technet.com/b/activedirectoryua/archive/2011/06/03/typo-in-the-mnemonic-of-dclocator-dns-record-in-windows-server-2003-active-directory-branch-office-guide.aspx и http://support.microsoft.com/kb/306602/en-us плюс гугление по "dc locator dns records not registered by the dcs"


    14 марта 2013 г. 4:56
    Отвечающий
  • так и должно быть (server1 является носителем всех ролей)? или можно/нужно эти записи удалить руками?

    Удалять вручную не нужно - не поможет, следует настроить DNS-записи DC Locator, которые регистрирует контроллер и запретить КД с центральной площадки регистрировать свои записи в сайтах.

    хорошо. как  настроить DNS-записи DC Locator, которые регистрирует контроллер? нашёл статью -

     http://www.osp.ru/win2000/2004/01/176614/ здесь пишут что сначала клиент ищет КД в своём сайте посылая аналог команд

    nslookup -querytype=srv 

    _ ldap._tcp.sitename._sites.dc._msdcs 

    .domain.name 

    выполнил эти команды на клиенте в филиале -

    C:\>ipconfig/all

    Настройка протокола IP для Windows

            Имя компьютера  . . . . . . . . . : comp138
            Основной DNS-суффикс  . . . . . . : vmk.loc
            Тип узла. . . . . . . . . . . . . : неизвестный
            IP-маршрутизация включена . . . . : нет
            WINS-прокси включен . . . . . . . : нет
            Порядок просмотра суффиксов DNS . : vmk.loc

    Подключение по локальной сети - Ethernet адаптер:

            DNS-суффикс этого подключения . . :
            Описание  . . . . . . . . . . . . : Realtek RTL8139/810x Family Fast Eth
    ernet NIC
            Физический адрес. . . . . . . . . : 00-17-31-7D-E9-DF
            Dhcp включен. . . . . . . . . . . : нет
            IP-адрес  . . . . . . . . . . . . : 192.168.0.3
            Маска подсети . . . . . . . . . . : 255.255.255.0
            Основной шлюз . . . . . . . . . . : 192.168.0.1
            DNS-серверы . . . . . . . . . . . : 192.168.0.45

    C:\>nslookup -querytype=srv
    Default Server:  man-ad.vmk.loc
    Address:  192.168.0.45

    > _ldap._tcp.manager._sites.dc._msdcs
    Server:  man-ad.vmk.loc
    Address:  192.168.0.45

    _ldap._tcp.manager._sites.dc._msdcs.vmk.loc     SRV service location:
              priority       = 0
              weight         = 100
              port           = 389
              svr hostname   = man-ad.vmk.loc
    man-ad.vmk.loc  internet address = 192.168.0.45

    > vmk.loc
    Server:  man-ad.vmk.loc
    Address:  192.168.0.45

    vmk.loc
            primary name server = server33.vmk.loc
            responsible mail addr = admin
            serial  = 123392
            refresh = 900 (15 mins)
            retry   = 600 (10 mins)
            expire  = 86400 (1 day)
            default TTL = 3600 (1 hour)
    >

    как сказать что у сайта manager КД man-ad а не server33 (в оснастке ad сайты и службы стоит man-ad)? 


    serg

    14 марта 2013 г. 5:57
  • как сказать что у сайта manager КД man-ad а не server33 (в оснастке ad сайты и службы стоит man-ad)?
    К сожалению до конца недели ограничен в доступе, но неплохо описано у Дмитрия в блоге
    14 марта 2013 г. 6:57
    Отвечающий
  • А сайт то вообще всегда правильно определяется?

    nltest /dsgetsite

    14 марта 2013 г. 7:46
  • >Это как и где делается? Я думал, что при привязке DC к сайтам оно само должно править нужные DNS-записи.

    Не совсем так. То, о чем задался вопросом ТС, зовется automatic site coverage, механизм при котором КД "страхуют" клиентов при регистрации, обнаруживая сайты, где менее 2х КД, и лихо прописываяюсь туда, %) дабы обслужить запросы клиентов- все сделано с благими целями. Лечится просто выключением этого механизма в настройках ГП (рядышком где Кирилл и подсказал), либо, как было верно замечено отменой регистрации конкретных записей за сайт - что тоньше и лучшее, не так топорно- можно в разных сценариях использовать разные подходы.

    > выполнил эти команды на клиенте в филиале -

    Здорово. Эти команды выполняет клиентская машина при старте, и ищет всякое в DNS- настройками выше можно ей сказать, что она должна видеть, чего нет.

    А Вы конкретно запустили nslookup, который по умолчанию зацепился за первый в списке сервер, прописанный на сетевой карточке.Как политики настроете, так записей не увидите- они просто в DNS регистрироваться не будут, вот и все.

    Самый простой вариант в Вашем сценарии- Главный офис и филиал-  отключить автоматическое обслуживание сайтов, более тонко и с заделом на будущее- рисовать записи.

    Да, кстати, у Вас DNS на rodc настроен неправильно - первым в списке д.б.  IP адрес самого сервера- т.е. 192.168.0.45


    • Изменено Dmitriy RazbornovEditor 14 марта 2013 г. 20:56 поправил опч
    • Помечено в качестве ответа sergeyk1 15 марта 2013 г. 0:04
    14 марта 2013 г. 20:01
    Отвечающий
  • >Самый простой вариант в Вашем сценарии- Главный офис и филиал-  отключить автоматическое обслуживание сайтов, более тонко и с заделом на будущее- рисовать записи.

    как я наконец то понял из этой статьи :) вся проблема в том что у меня в Головном офисе есть КД 2003 кот. не знает про rodc. сделал правкой реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters.

    Да, кстати, у Вас DNS на rodc настроен неправильно - первым в списке д.б.  IP адрес самого сервера- т.е. 192.168.0.45

    я читал что каждый днс должен в первую очередь ссылаться сам на себя, но вот здесь есть другая рекомендация или она уже устарела? 

    ЗЫ по поводу блога - "http://fromreallife.wordpress.com/2012/05/28/dnrecords/" он у меня не доступен. говорит "Сетевой адрес, позволяющий идентифицировать сайт в сети «Интернет», включен в Единый Реестр доменных имен, указателей страниц сайтов сети «Интернет» и сетевых адресов, позволяющих идентифицировать сайты в сети «Интернет», содержащие информацию, распространение которой в Российской Федерации запрещено." стал разбираться, оказалось что по крайней мере один из его адресов (66.155.9.238) попал в дол### реестр запрещённых сайтов :(


    serg


    PPS

    после правки реестра на server1 этот КД исчез из списка контроллеров обслуживающих сайт manager. перегружаю клиентский компьютер в филиале и ...

    C:\work>set lo
    LOGONSERVER=\\SERVER33

    C:\work>nltest/dsgetdc:vmk.loc
               DC: \\server33.vmk.loc
          Address: \\172.17.0.92
         Dom Guid: 8577d395-ef81-45cb-9dbf-f1d6c904f76f
         Dom Name: vmk.loc
      Forest Name: vmk.loc
     Dc Site Name: VMK
    Our Site Name: manager
            Flags: GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST 0x3000
    The command completed successfully

    C:\work>nltest/dnsgetdc:vmk.loc
    List of DCs in pseudo-random order taking into account SRV priorities and weights:
    Non-Site specific:
       server1.vmk.loc  172.17.0.40:389
       server33.vmk.loc  172.17.0.92:389
    The command completed successfully

    C:\work>nltest/dsgetsite
    manager
    The command completed successfully

    C:\work>ping -n 1 server33

    Обмен пакетами с server33.vmk.loc [172.17.0.92] по 32 байт:

    Ответ от 172.17.0.92: число байт=32 время=9мс TTL=126

    C:\work>ping -n 1 man-ad

    Обмен пакетами с man-ad.vmk.loc [192.168.0.45] по 32 байт:

    Ответ от 192.168.0.45: число байт=32 время<1мс TTL=128


    даю команду -

    C:\work>nltest/dsgetdc:vmk.loc /force
               DC: \\man-ad.vmk.loc
          Address: \\192.168.0.45
         Dom Guid: 8577d395-ef81-45cb-9dbf-f1d6c904f76f
         Dom Name: vmk.loc
      Forest Name: vmk.loc
     Dc Site Name: manager
    Our Site Name: manager
            Flags: GC DS LDAP KDC DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE 0x2800
    The command completed successfully

    C:\work>nltest/dsgetdc:vmk.loc /force
               DC: \\man-ad.vmk.loc
          Address: \\192.168.0.45
         Dom Guid: 8577d395-ef81-45cb-9dbf-f1d6c904f76f
         Dom Name: vmk.loc
      Forest Name: vmk.loc
     Dc Site Name: manager
    Our Site Name: manager
            Flags: GC DS LDAP KDC DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE 0x2800
    The command completed successfully

    C:\work>nltest/dsgetsite
    manager
    The command completed successfully

    C:\work>nltest/dnsgetdc:vmk.loc
    List of DCs in pseudo-random order taking into account SRV priorities and weight
    s:
    Non-Site specific:
       server33.vmk.loc  172.17.0.92:389
       server1.vmk.loc  172.17.0.40:389
    The command completed successfully


    после перезагрузки -

    C:\>set lo
    LOGONSERVER=\\SERVER33

    C:\work>nltest/dsgetdc:vmk.loc
               DC: \\server1.vmk.loc
          Address: \\172.17.0.40
         Dom Guid: 8577d395-ef81-45cb-9dbf-f1d6c904f76f
         Dom Name: vmk.loc
      Forest Name: vmk.loc
     Dc Site Name: VMK
    Our Site Name: manager
            Flags: PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST

    The command completed successfully

    ****

    в чём может быть причина? ведь man-ad находится в той-же сети что и комп. клиента. пинги до него идут быстрее, почему клиент при загрузке постоянно выбирает удалённый КД?

    • Изменено sergeyk1 15 марта 2013 г. 0:35
    14 марта 2013 г. 23:22
  • Всё заработало нормально после добавления учётных записей компьютеров в группу кэширования.

    Но остался вопрос с правильностью днс настроек. Как всё таки правильнее?


    serg

    15 марта 2013 г. 5:06
  • Ага, там 2003 год. Можно настраивать перекрестные адреса (и будет работать и так и так), я вот на выходных обещаю засесть и написать статью- народ с февраля просит и стонет ) - так что ловите меня на слове )

    Главное, чтобы бложик не забанили зверски за распостранение ТЗ :-9

    15 марта 2013 г. 5:47
    Отвечающий
  • Меня смущает тот факт, что режим домена у Вас - 2003. А RODC появились только в 2008. Может быть, включить отладку Входа в систему и посмотреть, что будет в логе?

    Сергей Панченко

    15 марта 2013 г. 6:05
  • Лечится просто выключением этого механизма в настройках ГП (рядышком где Кирилл и подсказал), либо, как было верно замечено отменой регистрации конкретных записей за сайт - что тоньше и лучшее, не так топорно- можно в разных сценариях использовать разные подходы.
    У меня с hub-and-spoke использовалась отмена регистрации для КД центральных площадок их LdapIPAddress Ldap DcByGuid Kdc Dc Rfc1510Kdc Rfc1510UdpKdc Rfc1510Kpwd Rfc1510UdpKpwd Gc GcIpAddress GenericGc, но надо понимать, что это в целом 80+ контроллеров и 120+ сайтов, в вашем же случае - смотрите сами :)

    15 марта 2013 г. 6:42
    Отвечающий
  • Меня смущает тот факт, что режим домена у Вас - 2003. А RODC появились только в 2008. Может быть, включить отладку Входа в систему и посмотреть, что будет в логе?

    Сергей Панченко


    Я думаю это не проблема. Схема была обновлена и ошибок не было. Помогла правка реестра и вкл. учётных записей компьютеров в группу кэширования.

    serg

    15 марта 2013 г. 6:53
  • Меня смущает тот факт, что режим домена у Вас - 2003. А RODC появились только в 2008. 

    Сергей Панченко

    Есть только определенные нюансы работы RODC с 2003ми машинами, а вообще нормально будут работать.
    15 марта 2013 г. 6:58
    Отвечающий