Active Directory не отвечает: что проверить по порядку

Утро, сотрудники не могут войти в свои компьютеры, на экране «Не удаётся связаться с контроллером домена». Или вошёл один человек, а десять других нет. Или всё работает, кроме сетевых папок.

Причин у этого немного, и они выстраиваются в понятный порядок проверки. Пойдём по нему сверху вниз: от самой частой к редким.

Первое: DNS

Больше половины случаев «домен недоступен» - это DNS, и проверять его надо раньше всего остального.

Active Directory построен на DNS: компьютер не знает, где стоит контроллер домена, он спрашивает об этом у DNS-сервера. В доменной сети эту роль выполняет сам контроллер: он хранит служебные записи, по которым клиенты его и находят.

Отсюда правило, которое нарушают чаще всего: компьютеры в домене должны получать адрес DNS контроллера домена, а не провайдера и не роутера. Публичный DNS о вашем домене не знает ничего и знать не может.

Ломается это обычно так. Настраивали сеть, где-то прописали публичный адрес вроде общеизвестных восьмёрок: в настройках роутера, в раздаче адресов или руками на конкретной машине. Интернет работает прекрасно, и связь с доменом кажется ни при чём. А домен отваливается, потому что искать контроллер стало негде.

Проверяется просто: посмотреть, какой DNS-сервер получает проблемный компьютер. Если это не адрес контроллера домена: причина найдена. Внешние адреса при этом никуда не деваются: контроллер сам пересылает запросы дальше, в интернет, и сотрудники ничего не теряют.

Второе: время

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

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

Расхождение берётся из мелочей: на старом компьютере садится батарейка на материнской плате, и после выходных время сбрасывается, а на виртуальной машине часы могут приходить от гипервизора, который синхронизируется со своим источником, тогда в одной сети оказывается два разных времени. Иногда время просто уводит вручную сам пользователь.

Проверяется сравнением времени на проблемной машине и на контроллере. Разница в минуты - уже повод.

Третье: сеть до контроллера

Компьютер должен просто физически дотягиваться до контроллера домена, и это не всегда очевидно.

Типовые случаи: машину перенесли в другой сегмент сети, и между сегментами нет маршрута; на компьютере или на сервере включили межсетевой экран с настройками по умолчанию; сотрудник работает удалённо, подключение к офису установилось, а маршрут до сети, где стоит контроллер, не прописан. Последнее особенно часто: удалённый доступ работает, интернет есть, а домен не виден. Про то, как устроен удалённый доступ и что в нём ломается, у нас есть отдельная статья.

Четвёртое: сам контроллер

Если предыдущие три пункта чисты, смотрим на сервер.

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

Компьютер «потерял доверие к домену»

Отдельный симптом с характерным текстом: не удалось установить доверительные отношения между рабочей станцией и доменом. Пароль сотрудника тут ни при чём.

У каждого компьютера в домене есть собственный пароль, отдельный от пользовательских. Он меняется автоматически по расписанию, компьютер и контроллер держат его согласованно. Если эти два значения разошлись, машина перестаёт считаться своей.

Разойтись они могут, если компьютер долго не включали (дольше, чем живёт этот пароль) и согласование при возвращении в сеть не прошло. Но чаще и неприятнее другое: машину восстановили из резервной копии или снапшота, снятого до смены пароля. Восстановленная система помнит старый пароль, контроллер знает новый, и доверие не сходится.

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

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

Лечится потеря доверия переподключением машины к домену. Данные пользователя не теряются, но локальный профиль может подхватиться не сразу: это стоит учитывать, если чините на бегу.

Пользователь не входит: разбираем учётную запись

Когда домен доступен, а конкретный человек войти не может, причина почти всегда в его записи. Вариантов четыре, и они разные.

Запись заблокирована после нескольких неудачных попыток. Тут есть важный поворот: чаще всего виноват не сам сотрудник. Где-то остался сохранённый старый пароль: в почтовом клиенте на телефоне, в подключённом сетевом диске, в задаче планировщика на сервере, и он методично долбится в домен, пока запись не заблокируется. Сотрудник сменил пароль, а забытая копия старого продолжает работать против него. Разблокировка без поиска источника даёт передышку на полчаса.

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

Запись отключена. Так бывает после увольнения и возвращения сотрудника или после плановой чистки, когда отключили лишнее и задели нужное.

Истёк срок действия самой записи: не пароля, а учётки целиком. Такое ставят подрядчикам и временным сотрудникам, а потом забывают продлить.

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

Групповые политики применились не ко всем

Обычная ситуация, и обычно это не поломка.

Политики не применяются мгновенно. Часть подхватывается при входе пользователя и загрузке компьютера, остальное обновляется по расписанию с заметным интервалом. Поэтому «у одних работает, у других нет» через полчаса после изменения: нормальное состояние, а не повод искать ошибку.

Не ко всем - тоже объяснимо. Политика привязана к конкретной ветке структуры домена и действует только на объекты внутри неё. Компьютер, стоящий в другом подразделении, её не увидит. Плюс политика делится на две части: одна применяется к компьютерам, другая к пользователям, и их регулярно путают: настройку кладут не в ту половину, и она не срабатывает никогда.

Если после ожидания и проверки расположения политика всё равно не действует, дальше смотрят порядок применения: политики накладываются друг на друга, и более близкая к объекту переопределяет более общую.

Один контроллер домена - это риск, о котором надо знать

Если контроллер в компании один, его падение останавливает работу целиком: никто не войдёт в компьютер, не откроет сетевую папку, не подключится к терминальному серверу.

Второй контроллер нужен не всем. Компания на тридцать человек, где допустимо потерять полдня на восстановление, может обойтись одним: при условии, что резервная копия делается и проверяется. Но решение это должно быть осознанным, а не таким, о котором узнают в день отказа.

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

Если домена ещё нет

Короткий раздел для тех, кто дочитал из любопытства.

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

Когда без него спокойнее: компания до пятнадцати человек, нет своего файлового сервера, почта и документы живут в облаке, компьютеры у людей личные. В такой конфигурации домен добавит работы больше, чем снимет.

Когда стоит звать нас

Первые три проверки (DNS, время, сеть) стоит пройти самостоятельно: они закрывают большинство случаев и не требуют ничего, кроме внимательности.

Дальше цена ошибки растёт: контроллер не поднимается после перезагрузки, политики ведут себя непредсказуемо, нужен второй контроллер или переезд домена на новый сервер. Отдельный случай: когда непонятно, что вообще происходит, а компания стоит.

Мы в ITHOUSE обслуживаем серверы и домены для 25+ компаний, самому долгому сопровождению - 15 лет. Работаем по будням с 9:00 до 19:00, реагируем на заявку в течение часа. Абонентское обслуживание - от 25 000 ₽ в месяц, разовые работы - от 4 000 ₽ в час.

Если домен работает, но никто в компании не знает, как он устроен, это тоже повод: разберём и опишем, пока не сломалось.