none
Не подключается сетевой диск с использованием FQDN или NETBIOS имени сервера-ресурса RRS feed

  • Вопрос

  • Добрый день.

    Столкнулся с интересной непостоянной проблемой. Имеется домен в состоянии апгрейда. Три контроллера домена 2003R2, 2008R2 и новый 2012R2. Хозяин FSMO сервер 2012R2. DHCP сервер он же. FFL DFL 2003.

    В DNS зонах _msdcs все служебные записи ведут только на эти три контроллера домена, в домене отсутствуют деления на сайты, все находится в Default сайте.

    Мониторинг репликации AD между серверами КД ошибок не показывает.

    Имеется в домене файл-сервер 2008R2 с сетевыми шарами.

    Имеются клиенты с Windows 7 которые пользуются шарами и мапят их как сетевые диски. DNS резолвинг работает как часы как прямой так и реверсный. Синхронизация времени настроена у всех на один и тот же источник времени и работает под политиками. Часы у всех синхронны.

    Обновления на все сервера устанавливаются через SUS регулярно.

    Так вот проблема которая стала возникать часто, после внедрения 2012R2 и подготовки к переводу всего домена на 2012R2 контроллеры в следующем:

    Изредка у пользователей отваливаются подмапленные сетевые диски, если маппинг идет с указанием понятного имени сервера (например \\fileserver\share\), ведущие на шары к серверу, причем не у всех а случайным образом то у одного то у другого. Повторное подключение шары с вводом логина пароля оканчивается неудачей, бесконечно запрашивает авторизацию. При этом, если подмапить шару указав IP адрес файл-сервера проходит отлично, и такие шары не отваливаются вообще (например \\10.1.1.15\share). Снова подмапить через понятное имя удается если перезагрузить клиентский компьютер. После этого подмапленная шара может проработать сутки, или неделю, или даже две, и снова отвалиться.

    В логах безопасности файл-сервера и контроллеров домена никаких явных failure не наблюдается. Одни success запросов на авторизацию... Куда копать дальше пока не знаю, направьте пожалуйста в какую сторону посмотреть?

    25 февраля 2015 г. 9:12

Все ответы

  • А на клиентах что в логах выподает когда пытаются подключиться к шаре?
    25 февраля 2015 г. 9:16
  • Наблюдаемая вами картина говорит об ошибках либо разрешения имён DNS, либо протокола аутентификации Kerberos.

    1. В момент возникновения ошибки на клиенте проверьте, что имя файлового сервера (FQDN или NetBIOS - то, которое использовано для подключения к файловому серрверу) разрешается именно в тот адрес IP, который вы ожидаете. Проверять надо командой ping - она использует системный механизм разрешения имён, а не командой nslookup (она делает запросы самостоятельно).

    2. Если с разрешением имён всё нормально, то надо смотреть ошибки Kerberos. Включите регистрацию этих ошибок на клиентах и на файловом сервере (на контроллерах домена она включена по умолчанию) - см. статью 262177 MS KB - и ищите ошибки Kerberos в журналах событий системы на клиентах, файловом сервере или контроллерах доменов.


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

    25 февраля 2015 г. 10:00
  • Включил логирование всех Failure эвентов на клиентской машине - ровно никаких Failure эвентов не появляется при попытке подключать диск. Включил Success, тоже ничего относящегося к File Systems.

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

    Забавно то, что не имеет значения какую шару подключать в таком режиме. Ни одна шара на текущем сервере не подключается. Более того, пробую подключить SMB шару на файловом хранилище линукс сервера, с самбой, с таким же результатом. Но на сервере регистрируются в логе самбы следущие события:

    smbd/service.c:684(make_connection_snum)

    create_connection_server_info failed: NT_STATUS_ACCESS_DENIED

    Тоесть не опознает передаваемые ей учетные данные. А какие именно это учетные данные - не логирует.

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

    25 февраля 2015 г. 10:09
  •  Такое ощущение что зависают какие то соединения и их сброс происходит только после ребута или входа другого пользователя.

    Скорее всего, файл-сервер (или служба TGS на КД) почему-то не хочет принимать кэшированные на клиенте билеты Kerberos. Для диагностики можно в случае проблемы попробовать их на клиенте сбросить:

    klist purge

    (в XP klist.exe в самой системе нет, он входит, если не ошибаюсь, в состав Support Tools - они ставятся из папки Support дистрибутивного диска).

    Ну а чтобы найти причину, почему файл-серверу/TGS кэшированные билеты не нравятся, нужно включить запись событий Kerberos (см. мой предыдущий ответ) и смотреть журналы событий системы файл-сервера и КД.


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

    25 февраля 2015 г. 10:31
  • понял, спасибо. буду ждать отказа в подключении. сейчас пока все подключено и работает...

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

    klist в наличии на всех задействованных машинах, там же семерки 2008 и 2012...


    • Изменено _RAW_ 26 февраля 2015 г. 14:26
    26 февраля 2015 г. 14:25
  • А каким механизмом вы прицепляете диски ? Это отдельные cmd команды ? или вы используете GPO (User configuration - Preferences - Windows Settings - Drive Maps)

    SSL

    3 марта 2015 г. 23:24
  • Заметил кстати что подмапленые через полиси диски не отваливаются никогда. А отваливаются именно подмапленные вручную "по пользовательски" через "Мой компьютер". Еще так же обратил внимание, что отваливаются чаще всего после перезагрузки какого либо контроллера домена. Сегодня в сервисный интервал перегружал КД с 2008R2, на который смотрит файловый сервер. Утром пользователь пришел и пожаловался что у него отвалилась и не мапится шара подключенная им вручную и по имени. Сделал на клиенте klist purge, убедился что тикетов на системе нет. попробовал подмапить диск - не вышло. Тикеты на клиенте появились.

    Включил логи кербероса на клиенте и сервере. Изучаю проблемные логи.

    Вообще надо выводить старые два контроллера домена с 2003 и 2008.... Лишние они имхо.

    Просто тут у ребят есть линуксовые сервера с самбой и тоже шары организованы. Как бы не получилось что их самба с моими новыми кд не подружились.

    10 марта 2015 г. 11:37

  • Включил логи кербероса на клиенте и сервере. Изучаю проблемные логи.

    Вообще надо выводить старые два контроллера домена с 2003 и 2008.... Лишние они имхо.

    Просто тут у ребят есть линуксовые сервера с самбой и тоже шары организованы. Как бы не получилось что их самба с моими новыми кд не подружились.

    Получилось понять в чем проблема и решить её? Столкнулся с похожим поведением, жду советов
    12 января 2016 г. 10:39
  • Авторизацию запрашивает именно на шару или все таки на dns сервер (который авторизован в АД)?

    Файл сервер имеет динамическую или статическую запись в днс?

    Уровень домена выше 2003 не позволяет использовать разрешения NetBios имен, поэтому вам нужно их выключить и избавиться от не поддерживаемых система windows ХР/2003.

    При переходе на новый уровень вы потеряете всех клиентов.

    12 января 2016 г. 12:21
  • Авторизацию запрашивает именно на шару или все таки на dns сервер (который авторизован в АД)?

    Файл сервер имеет динамическую или статическую запись в днс?

    Уровень домена выше 2003 не позволяет использовать разрешения NetBios имен, поэтому вам нужно их выключить и избавиться от не поддерживаемых система windows ХР/2003.

    При переходе на новый уровень вы потеряете всех клиентов.

    Простите, вы бы не могли не делать такие странные утверждения?

    "Авторизацию на DNS сервер" клиент запросить в принципе не может, это попросту не предусмотрено протоколом разрешения имен. В AD все записи в DNS являются динамическими (стандартная ситуация), если только не заведены вручную, и в данном сценарии это не имеет никакого значения. Windows XP и Windows Server 2003 прекрасно живут в домене уровня Server 2008 и более высоком. Разрешение имен через NetBIOS не имеет ничего общего с разрешением имен в домене AD - там используется DNS. Ну и, разумеется, при повышении уровня домена никакого "вы потеряете всех клиентов" не будет.


    Evgeniy Lotosh // MCSE: Server infrastructure, MCSE: Messaging

    12 января 2016 г. 12:39