none
После падения канала VPN пользователи дочернего домена не могут войти в систему RRS feed

  • Вопрос

  • Доброго времени суток всем!

    Суть вопроса в заголовке.

    О структуре:

    Корневой домен name.local, контроллеры домена: dc1.name.local , dc2.name.local. Первичный (с поднятой ролью хозяев на Win2008R2, вторичный - 2003)

    Дочерние (их 4) fil1.name.local и т.п., три домена создавались не мной и они работают корректно. Четвертый создавал я и он при падении ВПН не авторизует юзеров. В каждом филиале по одному или более контроллеров домена. ДНС везде указывается только из их узлов, на "глобальный" ДНС пересылка (в том числе и общие, для интернета). Все филиалы разнесены по сайтам со своими подсетями.

    Репликация проходит успешно (ну бывают сбои в связи, в общем - корректно все, сбои редкие).

    Вопрос: Куда копать?

    Буду благодарен спецам за любой совет!

    31 марта 2015 г. 17:48

Ответы

  • Да, пишет. Пишет "Не удалось подключиться к контроллеру домена" или как-то так, дословно к сожалению не помню. Читал, что рекомендуют "переделать" ДНС-сервер, не совнем понимаю что это значит. ДНС в филиалах на АД, что там переделывать так же не описано. В клиентских ПК ДНС указал ТОЛЬКО узла. То есть для 192.168.5.0/24  ДНС-сервер 192.168.5.2 (он же АД) и все!
    Посмотрите, объявляет ли себя тамошний контроллер домена глобальным каталогом. Например с помощью nltest /dsgetdc:fil4.name.local - там в выдаче команды есть строка "Flags:", посмотрите, присутсвует ли в ней "GC".

    Слава России!

    2 апреля 2015 г. 9:51

Все ответы

  • Вопрос первый: на этом вашем отдельном КД глобальный каталог есть?

    Если нет - включите (галочка в свойствах объекта NTDS Settings KL в AD Sites & Services).


    Слава России!

    31 марта 2015 г. 21:38
  • Благодарю за содействие!

    Да, галочка установлена. Но, правда, установлена она была не сразу, а где-то через месяц.

    Что еще нужно проверить?

    1 апреля 2015 г. 16:15
  • Лучше всего не гадать, а включить аудит неудачных событий входя в систему на клиентских ПК, а после сбоя - посмотреть в журнал событий Безопасность ПК: как правило, там пишется более подробная информация о причинах неудачи входа.

    Слава России!

    1 апреля 2015 г. 17:09
  • Да, пишет. Пишет "Не удалось подключиться к контроллеру домена" или как-то так, дословно к сожалению не помню. Читал, что рекомендуют "переделать" ДНС-сервер, не совнем понимаю что это значит. ДНС в филиалах на АД, что там переделывать так же не описано. В клиентских ПК ДНС указал ТОЛЬКО узла. То есть для 192.168.5.0/24  ДНС-сервер 192.168.5.2 (он же АД) и все!
    • Изменено Comelot 1 апреля 2015 г. 19:10
    1 апреля 2015 г. 19:04
  • Добрый день!

    А сайты настроены https://technet.microsoft.com/ru-ru/library/cc782048(v=ws.10).aspx ?

    2 апреля 2015 г. 7:08
  • Да, пишет. Пишет "Не удалось подключиться к контроллеру домена" или как-то так, дословно к сожалению не помню. Читал, что рекомендуют "переделать" ДНС-сервер, не совнем понимаю что это значит. ДНС в филиалах на АД, что там переделывать так же не описано. В клиентских ПК ДНС указал ТОЛЬКО узла. То есть для 192.168.5.0/24  ДНС-сервер 192.168.5.2 (он же АД) и все!
    Посмотрите, объявляет ли себя тамошний контроллер домена глобальным каталогом. Например с помощью nltest /dsgetdc:fil4.name.local - там в выдаче команды есть строка "Flags:", посмотрите, присутсвует ли в ней "GC".

    Слава России!

    2 апреля 2015 г. 9:51
  • Приветствую!

    Да, сайты настроены. Каждый филиал на своем сайте.

    Повторюсь - с другими филиалами такого нет, все работает корректно.

    14 апреля 2015 г. 16:51
  • Вот вывод:

            Флаги: GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE FULL_SECRET WS
    Команда выполнена успешно.

    По идеи, все должно работать корректно, всю голову сломал уже (хорошо, что канал пока не падает, есть время на раздумья).

    ADReplicationStatusTool показывает, что репликация замечательно проходит что с хозяином схемы, что со вторичным контроллером корневого домена.

    • Изменено Comelot 14 апреля 2015 г. 17:18
    14 апреля 2015 г. 16:56
  • Ни у кого больше нет ни каких идей в какую сторону капнуть?

    Может у кого есть хоть приблизительное понимание процесса в чем может быть "затык"?

    Буду благодарен за любую помощь!

    22 апреля 2015 г. 16:57
  • Боюсь, что придётся ловить ошибку в момент падения связи (например, приехать туда и положить связь для диагностики): явно не хватает информации.

    Но, на всякий случай покажите, как именно настроены серверы DNS на ПК в филиале (ipconfig /all) и проверьте (командой nslookup), что сервер DNS на местном КД отвечает на запросы с клиентов по настроенному адресу.


    Слава России!


    • Изменено M.V.V. _ 22 апреля 2015 г. 17:58
    22 апреля 2015 г. 17:57
  • Приветствую!

    Клиентские части проверялись в первую очередь. Там все корректно работает - только местный ДНС, настройки раздаются по DHCP. На сервере ДНС стоит пересылка (не путать со вторичным ДНС!) на сервера корневого домена и, при отсутствии связи с корневым - на сервера гугла и яндекса (для интернета).

    Приехать лично мне нет возможности - я в 1000 км от места. Может есть какой вариант удаленно "ловить"?

    PS: Я как-то посчитал изначально не важным этот факт, сейчас думаю нужно уточнить. Проблема проявляется не с самими клиентскими ПК (там кеширование), а в момент подключения к серверу RemoteApp с ПО для работы (одним из ПО является 1С). На сервере статический IP и только местный ДНС.

    29 апреля 2015 г. 17:36
  • Проверьте на местном DNS наличие зоны для поддомена _msdcs корневого домена леса: записи для GC прописываются там.

    Слава России!

    29 апреля 2015 г. 18:06
  • Приветствую всех!

    Итак, нашлось время "копнуть глубже" и вот что мне удалось выяснить:

    Примерно за год до того как я устроился работать был какой-то непонятный трабл с подключением VPN, пока разбирались прошло значительное время (больше времени захоронения). Сейчас при запуске диагностики я получаю сообщения, что домены (вторичные, которые установлены в других филиалах) превысили время захоронения. При этом никаких траблов с авторизацией пользователей или еще чего-то не обнаружено в тех доменах, они назначены GC. Новый домен, с которым собственно проблема, был добавлен гораздо позднее. Соответственно dcdiag выдает, что данный домен не закончил повышение роли до GC. И, если я верно понял теорию по репликации АД, то проблема с невозможностью повышения роли до GC как раз и кроется в том, что другие домены превысили время захоронения. Следовательно проблемный домен не может с ними реплицировать данные и не может завершить тем самым повышение до GC.

    Вопрос номер раз - Кто с подобным сталкивался?

    Вопрос номер два - Существуют ли пути решения данной проблемы?

    2 ноября 2015 г. 12:31
  • Ответ номер раз - лично я у себя до такого безобразного состояния репликацию не доводил, но что в таких случая происходит - очень хорошо понимаю.

    Ответ номер два - репликацию-то включить можно, но потом придётся проконтролировать наличие, а при наличии - решать те самые потенциальные проблемы, из-за возможности которых репликация в таких случаях отключается. В принципе, проблемы эти - решаемые, но решение может потребовать хорошего понимания работы AD и творческого подхода к конкретному вашему случаю.

    Рекомендации Microsoft по решению этой проблемы изложены в статье 2020053 MS KB

    Если в ходе выполнения этих рекомендаций возникнут вопросы - пишите сюда, помогу.


    Слава России!

    2 ноября 2015 г. 13:10
  • Благодарю за ответ!

    Сам в ужасе от сложившейся ситуации, предшественники (их оказывается было двое до меня) вот такой сюрприз оставили (а может и не их вина - сейчас уже это не важно). 

    Буду разбираться со статьей, спасибо.

    3 ноября 2015 г. 8:14