none
Пропало доверие между доменами RRS feed

  • Вопрос

  • Есть два домена. Один на Windows 2003 R2, второй на Windows 2008. Было доверие, но после ребута одного из серверов трасты пропадали. Восстанавливались после проверки соединения с Windows 2008 ( с 2003 трасты не поднимались). После очередной перезагрузки трасты пропали окончательно. Дополнительные зоны на обоих серверах есть. dcdiag /fix, netdiag /fix не помогают. Визард создания доверия завершает работу с ошибкой "Мастер создания нового доверия не может продолжать работу, поскольку не удается обратиться к указанному домену".
    Nslookup имена резолвит. Пинг идет в обе стороны. И почему то не работает на 2003 сервере оснастка "домены и доверия" со стандартного значка. Лишь если ее добавить руками. Ну это просто как аддишенл инфо. Куда рыть уже совсем непонятно! Все апдейты для серверов стоят.
    Из командной строки
    C:\>netdom trust msk.domen.ru /d:klg.domen.ru /add /twoway
    Указанный домен не существует или к нему невозможно подключиться.
    8 октября 2009 г. 13:07

Все ответы

  • PDC-эмуляторы в обоих доменах доступны друг для друга?
    Разрешение имен, как я понял у вас настроено?

    8 октября 2009 г. 14:23
    Отвечающий
  • Разрешение имен настроено и работает.
    Ping от dc.msk.domen.ru к dc.klg.domen.ru и обратно работает. Как по ip так и по имени
    9 октября 2009 г. 6:51
  • А в логах ошибки есть?
    9 октября 2009 г. 6:54
    Отвечающий
  • Нет. И dcdiag не выдает никаких ошибок. Все тесты пройдены. Как и netdiag. Уже просто загадка!
    9 октября 2009 г. 7:02
  • Ваши домены в одном дереве, одном лесу или разных лесах?

    9 октября 2009 г. 10:18
  • В разных лесах. Имя второго уровня совпадает но это разные леса.
    Причем создали отдельный домен сейчас, так  он создал трасты и с klg.domen.ru и с msk.domen.ru.
    А между собой они никак не хотят
    9 октября 2009 г. 11:28
  • Так какой тип доверительных отношений вы пытаетесь создать: между лесами или внешний между доменами?

    9 октября 2009 г. 11:38
  • Внешний между доменами. Так визард предлагает два варианта - либо сфера либо внешний. Сфера создается а внешний завершает работу.
    К 3му домену сразу подхватывает как внешний и предлагает варианты двухсторонний итд, транзитивный не транзитивный
    9 октября 2009 г. 11:51
  • Почему бы вам не поднять уровни лесов до 2003-го и не попробовать установить доверительные отношения между лесами?

    realm trust использует аутентификацию kerberos. external trust - ntlm. мб, у вас что-то не так с этим протоколом. в любом случае, довертельные отношения между лесами более предпочтительны, ИМХО.
    9 октября 2009 г. 14:11
  • Оба домена работают в режиме 2003 native. Тут просто какие то чудеса. После запуска nltest трасты поднялись на какое то время, а потом пропали.
    С домена msk.domain.ru
    C:\>nltest /dclist:klg.domain.ru
    Cannot find DC to get DC list from.Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN
    The command completed successfully

    C:\>nltest /server:klg.domain.ru
    The command completed successfully
    12 октября 2009 г. 6:49
  • У вас время синхронизировано? Контроллеры доменов в одной сети?
    12 октября 2009 г. 8:57
  • Время синхронизировано. Сети разные. Соединение через VPN порты все открыты. Запрос к днс из сети в сеть идет.
    Есть мысль что от старых трастов где то торчат хвосты. Но непонятно где их скать
    12 октября 2009 г. 9:08
  • Объеты trustedDomain можно посмотреть с помощью ADSIEdit. http://support.microsoft.com/kb/228477

    Проверьте nslookup-ом, во что у вас разрешается имя _ldap._tcp.Default-First-Site-Name._sites.klg.domain.ru. В качестве сервера укажите DNS домена msk.domain.ru.

    Сами доверительные отношения, насколько я понял, в оснастке AD Domains and Trusts у вас не отображаются?
    12 октября 2009 г. 11:40
  • trustedDomain объекта нет.

    > _ldap._tcp.Default-First-Name._sites.klg.domain.ru
    Server:  dc.msk.domain.ru
    Address:  192.168.10.4

    DNS request timed out.
        timeout was 2 seconds.
    *** dc.msk.domain.ru can't find _ldap._tcp.Default-First-Name._sites.klg.domain.ru: Non-existent domain
    > _ldap._tcp.Default-First-Name._sites.klg.domain.ru.
    Server:  dc.msk.biztrend.ru
    Address:  192.168.10.4

    Отношения не отображаются потому что их нет
    12 октября 2009 г. 12:35
  • Фразу "пропало доверие" можно трактовать двояко. Доверительные отношения отсутствуют, либо они есть, но не работают.

    Теперь еще один дурацкий вопрос. Когда вы проверяли запись в nslookup, вы заменили domain.ru на свой домен?
    И если заменили, то правильно ли я понял, что nslookup эту запись не нашел?
    12 октября 2009 г. 14:48
  • Сначала они просто перестали работать. После их удаления завести их по новой не получилось. Естественно домен менял. Запуск nslookup проводился как из консоли днс сервера так и с клиентской машины (на всякий случай). Да запись не нашел. Еще две ошибки по разным командам:
    C:\>nltest /dsgetdc: /pdc /force /avoidself
    DsGetDcName failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

    C:\>repadmin /showrepl dc=klg,dc=domain,dc=ru
    Repadmin experienced the following error trying to resolve the DC_NAME: dc=klg,dc=domain,dc=ru
    Error: An error occured:
        Win32 Error 8419(0x20e3): Не удается найти объект DSA.


    13 октября 2009 г. 5:25
  • В таком случае у вас либо проблемы с DNS, либо с UDP траффиком.

    Вы писали, что настраивали "дополнительные зоны". Вы имели ввиду вторичные зоны для соответствующих доменов? Передача зон работает нормально? В самой вторичной зоне есть записи SRV? Мб, проще настроить условный форвардинг?

    13 октября 2009 г. 5:40
  • Да. На каждом сервера нестроена вторичная зона прямая.
    Записи NS, SOA, default-first-site-name._tcp _gc, _kerberos, _ldap присутствуют.
    Форвардинг прописан просто во все другие DNS домены прописаны dns другого домена. Создать еще одну зону пересылки с именем домена не получается - пишет что такая зона уже существует.
    Вобщем и зона прямого просмотра есть и форвардинг есть. И передача зоны нормально работает и в ручном режиме и после изменения индекса зоны на другом сервере.
    И tcp и udp пакеты ходят в обе стороны.
    Причем после поднятия чистого домена рядом трасты опять проработали сутки и тоже пропали безвозратно
    13 октября 2009 г. 5:53
  • Первое, что делает nltest /dclist:domain - пытается найти ldap сервер для домена domain, т.е. выполняет DNS запрос для указанной выше SRV записи, используя протокол UDP. У вас либо DNS сервер не находит запись в базе, либо пакеты запроса/ответа теряются. Поставьте сетевой монитор и последите за пакетами.

    Если честно, я не понял, как у вас настроен форвардинг. Мб, вы имели в виду безусловный форвардинг? Впрочем, это не важно, раз во вторичной зоне реплика SRV записей имеется. Данные должны браться оттуда.
    13 октября 2009 г. 6:11
  • Это все верно. Но! При опросе nslookup с сервера msk.domain.ru
    > set type=ns
    > klg.domain.ru
    Server:  dc.msk.domain.ru
    Address:  192.168.10.4

    klg.domain.ru nameserver = dc.klg.domain.ru
    dc.klg.domain.ru      internet address = 192.168.1.4

    Т.е. все опрашивается нормально. Зона существует. А дальше уже непонятно!
    set type=srv тоже отрабатывает полностью
    13 октября 2009 г. 6:48
  • Мб, у вас все-таки что-то не так с SRV записями вторичной зоны? Вы сайты в AD не используете?

    В nslookup-е ls -t SRV klg.domain.ru, возвращает все SRV записи, в том числе и _ldap._tcp.Default-First-Site-Name._sites.klg.domain.ru?
    Надо только предварительно разрешить трансфер зоны на хост, с которого выполняете запрос.
    13 октября 2009 г. 7:04
  • А имя корневого домена в обоих лесах какое?

    13 октября 2009 г. 7:07
    Отвечающий
  • Может что то и не так. Но как это понять?  У нас по одному домен контроллеру. Сайты не используем.
    [dc.msk.domain.ru]
     _gc._tcp.Default-First-Site-Name._sites SRV    priority=0, weight=100, port=3268, dc.msk.domain.ru
     _kerberos._tcp.Default-First-Site-Name._sites SRV    priority=0, weight=100, port=88, dc.msk.domain.ru
     _ldap._tcp.Default-First-Site-Name._sites SRV    priority=0, weight=100, port=389, dc.msk.domain.ru
     _gc._tcp                       SRV    priority=0, weight=100, port=3268, dc.msk.domain.ru
     _kerberos._tcp                 SRV    priority=0, weight=100, port=88, dc.msk.domain.ru
     _kpasswd._tcp                  SRV    priority=0, weight=100, port=464, dc.msk.domain.ru
     _ldap._tcp                     SRV    priority=0, weight=100, port=389, dc.msk.domain.ru
     _xmpp-client._tcp              SRV    priority=0, weight=100, port=5222, server.msk.domain.ru
     _xmpp-server._tcp              SRV    priority=0, weight=100, port=5269, server.msk.domain.ru
     _kerberos._udp                 SRV    priority=0, weight=100, port=88, dc.msk.domain.ru
     _kpasswd._udp                  SRV    priority=0, weight=100, port=464, dc.msk.domain.ru
     _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones SRV    priority=0, weight=100, port=389, dc.msk.domain.ru
     _ldap._tcp.DomainDnsZones      SRV    priority=0, weight=100, port=389, dc.msk.domain.ru
     _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones SRV    priority=0, weight=100, port=389, dc.msk.domain.ru
     _ldap._tcp.ForestDnsZones      SRV    priority=0, weight=100, port=389, dc.msk.domain.ru
    13 октября 2009 г. 7:37
  • dc.klg.domain.ru
    dc.msk.domain.ru
    13 октября 2009 г. 7:38
  • dc.klg.domain.ru
    dc.msk.domain.ru

    т. е вы хотели сказать klg.domain.ru и msk.domain.ru?

    13 октября 2009 г. 7:41
    Отвечающий
  • Ну да )))))
    13 октября 2009 г. 7:45
  • Может что то и не так. Но как это понять?  У нас по одному домен контроллеру. Сайты не используем.
    вы показали SRV записи для домена msk.domain.ru,  а у вас nslookup не находит SRV запись домена klg.domain.ru.
    13 октября 2009 г. 8:06
  • Я это вижу. Но во вторичной зоне то они есть если руками на них посмотреть
    13 октября 2009 г. 8:10
  • Не надо на них смотреть руками. Надо - nslookup-ом. :)
    Просто я чего-то не понимаю. Вы запускаете nslookup, вводите ls -t SRV klg.domain.ru и получаете SRV записи для домена msk.domain.ru?
    13 октября 2009 г. 8:35
  • > ls -t SRV klg.domain.ru
    [dc.msk.domain.ru]
    *** Can't list domain klg.domain.ru: Query refused
    Но зона то передается!
    • Изменено Pero.mob 13 октября 2009 г. 13:25
    13 октября 2009 г. 12:47
  • разрешите в свойствах зоны трансфер.
    13 октября 2009 г. 12:52
  • Зоны передаются. Трансфер разрешен. msk все изменения зоны klg получает.
    Сейчас попробовал получить зону klg повторно. Вот что в логах
    DNS-сервер получил запрос от "192.168.10.4" о передаче несуществующей или неполномочной зоны "SRV.".
    И дальше
    Более свежая версия 624 зоны klg.domain.ru найдена на DNS-сервере на 192.168.1.4. Осуществляется передача зоны.
    DNS-сервер записал версию 624 зоны klg.domain.ru в файл "klg.domain.ru.dns"
    Вот как так?!

    13 октября 2009 г. 13:10
  • В свойствах вторичной зоны разрешите ее передачу, чтобы nslookup сработал.
    13 октября 2009 г. 13:26
  • Да разрешена передача! И сервера имен указаны вторичные. Как ее еще разрешить то кроме передачи зон? Там вообще стоит передавать зону на любой сервер!
    13 октября 2009 г. 13:48
  • Вы не понимаете. Или я не понимаю.

    У вас разрешена передача оригинальной зоны, т.е. на сервере dc.msk.domain.ru в свойствах первичной зоны вы передачу этой зоны разрешили. Чтобы nslookup отработал (у вас он выдает сообщение Query refused) надо в свойствах вторичной зоны на сервере dc.klg.domain.ru разрешить и ее передачу так же.

    После этого nslookup должен отработать и выдать все SRV записи, который переданы из первичной зоны во вторичную.

    13 октября 2009 г. 13:55
  • Мужики, а чего Вы так с передачей зон носитесь, а? Настройте "Conditional Forwarding", что ли... :))

    13 октября 2009 г. 14:24
    Отвечающий
  • я уже предлагал. но что-то там не задалось у Pero.Mob с форвардингом. ну и ладно. в данном случае это не принципиально. важно понять, работает разрешение имен или нет. а вот это пока никак и не удается выяснить. :)
    13 октября 2009 г. 14:34
  • После разрешения передачи вторичной зоны она стала отдаваться. Но трасты не создаются

    > ls -t SRV klg.domain.ru
    [dc.msk.domain.ru]
     _gc._tcp.Default-First-Site-Name._sites SRV    priority=0, weight=100, port=3268, dc.klg.domain.ru
     _kerberos._tcp.Default-First-Site-Name._sites SRV    priority=0, weight=100, port=88, dc.klg.domain.ru
     _ldap._tcp.Default-First-Site-Name._sites SRV    priority=0, weight=100, port=389, dc.klg.domain.ru
     _gc._tcp                       SRV    priority=0, weight=100, port=3268, dc.klg.domain.ru
     _kerberos._tcp                 SRV    priority=0, weight=100, port=88, dc.klg.domain.ru
     _kpasswd._tcp                  SRV    priority=0, weight=100, port=464, dc.klg.domain.ru
     _ldap._tcp                     SRV    priority=0, weight=100, port=389, dc.klg.domain.ru
     _xmpp-client._tcp              SRV    priority=0, weight=100, port=5222, dc.klg.domain.ru
     _xmpp-server._tcp              SRV    priority=0, weight=100, port=5269, dc.klg.domain.ru
     _kerberos._udp                 SRV    priority=0, weight=100, port=88, dc.klg.domain.ru
     _kpasswd._udp                  SRV    priority=0, weight=100, port=464, dc.klg.domain.ru
     _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones SRV    priority=0, weight=100, port=389, dc.klg.domain.ru
     _ldap._tcp.DomainDnsZones      SRV    priority=0, weight=100, port=389, dc.klg.domain.ru
     _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones SRV    priority=0, weight=100, port=389, dc.klg.domain.ru
     _ldap._tcp.ForestDnsZones      SRV    priority=0, weight=100, port=389, dc.klg.domain.ru

    C:\>nslookup _ldap._tcp.Default-First-Site-Name._sites.klg.domain.ru
    Server:  localhost
    Address:  127.0.0.1

    Name:    _ldap._tcp.Default-First-Site-Name._sites.klg.domain.ru
    Форвардинг таки вроде весь везде включен
    14 октября 2009 г. 7:21
  • Дело в том, что разрешение на передачу зоны никак в данном случае не могло повлиять на работу DNS вообще, и корректного разрешения записи _ldap в частности. Я лишь хотел в зглянуть на SRV записи, а разрешения нужны для работы команды ls в nslookup.

    Pero.mob, вы уверены, что перый раз DNS не мог найти эту запись? Мб, тогда вы ее не правильно указывали? Если DNS работает, должен отработать и nltest /dclist:klg.domain.ru

    Ну и заодно, как именно у вас настроен форвардинг? из предыдущего поста не все было понятно. у вас ведь всего два домена. ну и, наверное, выход в инет. Раз вы создали вторичные зоны для доменов, на форвардинг остается только инет - безусловный форвард на DNS провайдера?
    14 октября 2009 г. 14:25
  • >nltest /dclist:klg.domain.ru
    Cannot find DC to get DC list from.Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN
    The command completed successfully

    Домены соединены через VPN поэтому интернет им не нужен. Но он безусловно есть ))))
    Форвардинг настроен: Свойства днс сервера - пересылка. Там прописаны днс шлюза, днс провайдера + днс klg.
    Ну и плюс подгружена вторичная зона. Вроде бы это все возможные пересылки. Или я что то упустил?
    15 октября 2009 г. 5:47
  • nltest вы запускаете на том же DC. что и nslookup? странно все это...
    я предлагаю вам поставить сетевой монитор. можно на рабочую станцию в домене msk.domain.ru. скопировать туда же nltest.
    ну и посмотреть, что происходит, когда вы выполняете команду nltest /dclist:klg.domain.ru.
    если проблема не в DNS, то тогда она в LDAP или RPC.

    dcdiag & netdiag на контроллере dc.klg.domain.ru не показывают никаких ошибок?

    VPN вы поднимали сами? или его вам предоставляет провайдер?

    ну а с форвардингом у вас все более-менее... :)

    15 октября 2009 г. 13:16
  • nslookup nltest я запускаю прямо на dc.msk.domain.ru
    так что все запросы идут через localhost. Какие тут могут быть сетевые проблемы да еще и при отключенном файрволе.
    С клиентской машины запросы отрабатывают также.
    Я к домену и по ldap цепляюсь без нареканий. Все пользователи и группы видны.
    Причем все клиентские машины нормально входят в домен.
    У меня openvpn. Тут нет никаких проблем ибо простой туннель со всеми открытыми портами. Все остальные службы не касающиеся АД работают отлично.
    И для меня все это странно. Куда рыть уже совсем непонятно.
    и dcdiag и netdiag на обоих dc показывают все более менее одинаково. Нет ошибок.
    15 октября 2009 г. 13:46
  • ну, чем странне, тем интересней. я имею в виду - разбираться. :)

    если вам не надоело экспериментировать, попробуйте на машине в домене msk.domain.ru в качестве первичного DNS сервера прописать dc.klg.domain.ru и посмотрите, что скажет nltest. машины из домена klg.domain.ru по эту сторону VPN-а у вас есть? что, если на их запустить nltest?

    ну и все же, поставьте Network Monitor. штука хорошая, в хозяйстве пригодится. :) А нам позволит посмотреть где именно затыкается nltest.
    15 октября 2009 г. 14:21
  • Так.
    Вобщем машина из сети klg легко вошла в домен msk.
    На машине из сети msk был поставлен днс из сети Klg но в домен не вводилась.
    Имеем:
    C:\>nltest /dclist:klg.domain.ru
    Get list of DCs in domain 'klg.domain.ru' from '\\DC.klg.domain.ru'.
    You don't have access to DsBind to klg.biztrend.ru (\\DC.klg.domain.ru) (Trying NetServerEnum).
    I_NetGetDCList failed: Status = 6118 0x17e6 ERROR_NO_BROWSER_SERVERS_FOUND

    C:\>nslookup dc.klg.domain.ru
    Server:  dc.klg.domain.ru
    Address:  192.168.1.4

    Name:    dc.klg.domain.ru
    Address:  192.168.1.4

    ls -t SRV klg.domain.ru тоже отрабатывается нормально


    19 октября 2009 г. 6:39
  • все это вновь указывает на проблемы с DNS.
    давайте попробуем слегка упростить конфигурацию ваших DNS серверов. прежде всего я предлагаю удалить вторичные зоны. обе. затем в домене, который "смотрит" в интернет, удалите безусловный форвардин на DNS сервер второго домена и пропишите условный форвардинг для второго домена. А на DNS сервере второго домена оставте все как есть, только убедитесь, что на вкладке форвардеров, запись, указывающая на DNS сервер первого домена, стоит первой в списке. и очистите кэш на обоих DNS серверах.
    19 октября 2009 г. 19:12
  • Оба домена смотрят в интернет и в впн. |домен msk| --- |шлюз| --vpn--|шлюз|---|домен klg|
                                                                                             |                     |
                                                                                       интернет          интернет
    Вот как то так примерно.. Безусловный удален. Условный имеется ввиду просто в писок днс для пересылки прописать днс сервер не указывая зоны и поставить первым? Просто при наличии вторичной зоны прописать четко днс для конкретной зоны при наличии вторичной зоны нельзя
    20 октября 2009 г. 5:30
  • так даже лучше. в таком случае безусловный - это внешнии DNS сервера на вкладке Forwarders для "All other DNS domains". условный - на той же вкладке New... прописываете имя соседнего домена, а затем указываете ip DNS сервера этого домена(и больше ничего!). и так с обеих сторон. вторичные зоны придеться пока прибить.
    20 октября 2009 г. 5:49
  • Ошибок намекающих о проблемах с Kerberos нет?
    20 октября 2009 г. 11:30
  • Готово.
    C:\>nltest /dclist:klg.domain.ru
    Get list of DCs in domain 'klg.domain.ru' from '\\DC.klg.domain.ru'.
    You don't have access to DsBind to klg.biztrend.ru (\\DC.klg.domain.ru) (Tryin
    g NetServerEnum).
    I_NetGetDCList failed: Status = 6118 0x17e6 ERROR_NO_BROWSER_SERVERS_FOUND

    C:\>nslookup dc.klg.biztrend.ru
    Server:  localhost
    Address:  127.0.0.1

    Name:    dc.klg.domain.ru
    Address:  192.168.1.4

    С двух сторон одно и то же.
    Может таки права какие то нужны. Чет подкрутили невзначай. Хотя с двух сторон врядли...
    21 октября 2009 г. 6:18
  • Да вроде в логах не наблюдаются
    21 октября 2009 г. 6:18
  • А попробовать сейчас установить доверительные отношения?

    21 октября 2009 г. 6:27
  • Заработало!!!!!!!!!!!!!
    И
    C:\>nltest /dclist:klg.domain.ru
    Get list of DCs in domain 'klg.domain.ru' from '\\DC.klg.domain.ru'.
        DC.klg.domain.ru [PDC] [DS] Site: Default-First-Site-Name
    The command completed successfully

    Теперь как бы закрепить успех? Ибо ошибка так и непонятна!
    21 октября 2009 г. 9:13
  • Скорее всего, дело было в том, что в списке форвардеров у вас значился DNS сервер соседнего домена. Видимо, это вызывало конфликт с данными вторичной зоны. Ну а поскольку в списке форвардеров ваш DNS был прописан последним, некоторые запросы уходили на внешние DNS сервера, ну а те честно отвечали, что им о ваших внутренних доменах ничего не известно. Боюсь, точно назвать причину такого поведения без мониторинга DNS запросов, вряд ли, получится.

    Сейчас вы вполне можете заменить условный форвардинг на вторичные зоны. Должно работать. Вопрос - надо ли? Вот что вам надо, так это обзавестить дополнительными контроллерами в обоих домена. Ну и, мб, вместо внешних доверительных отношений между доменами, поднять доверительные отношения между лесами.

    21 октября 2009 г. 11:50
  • Врядли получится. По сути это работает как доверие между лесами. Тут оба домена 3го уровня выступают как домены 2го уровня.
    Имя второго уровня у них совпадает т.к. это логическое имя организации в целом. А имя 3го уровня выдает принадлежность к конкретной организации.
    21 октября 2009 г. 13:42
  • Получится. У вас же домен второго уровня не является доменом AD? Это просто домен DNS, как и домен RU. Так что в таком совпадении ничего страшного нет. Другое дело, что и особых причин менять тип доверительных отношений тоже нет. Разве что задуматься о слиянии. Но это уже другая история. :)

    21 октября 2009 г. 15:54
  • У меня похожие проблемы. Но на доменах 2003.
    Доверие вроде как было, но потом начало пропадать. Не было времени разбираться, всё удалил.
    Теперь вот основательно потребовалось доверие.
    Перепробовал уже несколько вариантов, в т.ч. те шаги, которые описаны здесь. 
    nik.loc - dc-1, dc-2
    nikel.loc - dc-1, dc-2
    С НИКа создать доверие на НИКЕЛ получается, но подтвердить его не удаётся.
    С НИКЕЛа создать доверие в принципе не удаётся, не доходит до вопроса внешние или внутренние.
    Пошёл дальше и выяснил, что:
    1) dc-1.nikel.loc can't see NIK.LOC
    2) NIK.LOC see dc-2.nikel.loc, but not dc-1.nikel.loc
    3) dc-2.nikel.loc know about NIK.LOC

    Ребятушки, помогите, а?
    Какие логи нужны? 

    Первый раз в жизни не могу разрешить задачу и пишу.
    25 декабря 2009 г. 0:09
  • Заработало)))
    После того, как вычистил всё, а в пересылке днс добавил нужный домен и сервер.

    Но заработало как-то очень интересно:
    1) В dsa.msc нельзя подключиться ко второму домену.
    2) В группы АД одного леса нельзя добавить пользователей другого леса.
    3) При этом права на папки можно давать, всё работает, логиниться перекрестно тоже получается.

    И серверы пересылки не реплецировались на контроллерах.
    25 декабря 2009 г. 8:51
  • Если кто-то ещё столкнётся с такой проблемой.
    Описание, приведенное выше, работает. Просто в структуре АД разобраться потом нужно. 
    Способ действительно помогает настроить доверие.
    26 декабря 2009 г. 20:40