Подлинность домена Windows 10 не подтверждена

Обновлено: 21.11.2024

В этой статье описывается несколько распространенных сообщений об ошибках, которые могут появиться при присоединении клиентских компьютеров под управлением Windows к домену. В этой статье также приводятся рекомендации по устранению этих ошибок.

Применимо к: Windows Server 2016, Windows Server 2012 R2
Исходный номер базы знаний: 4341920

Где найти файл Netsetup.log

Клиенты Windows регистрируют сведения об операциях присоединения к домену в файле %windir%\debug\Netsetup.log.

Сообщения об сетевых ошибках и решения

Ошибка 1

Не удалось разрешить DNS-имя контроллера домена в присоединяемом домене. Убедитесь, что этот клиент настроен на доступ к DNS-серверу, который может разрешать DNS-имена в целевом домене.

Разрешение

При вводе имени домена убедитесь, что вы вводите имя системы доменных имен (DNS), а не имя сетевой базовой системы ввода-вывода (NetBIOS). Например, если DNS-имя целевого домена — contoso.com , убедитесь, что вы вводите contoso.com вместо имени домена NetBIOS «contoso».

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

Ошибка 2

Не удалось разрешить DNS-имя контроллера домена в присоединяемом домене. Убедитесь, что этот клиент настроен на доступ к DNS-серверу, который может разрешать DNS-имена в целевом домене.

Разрешение

При вводе имени домена убедитесь, что вы вводите имя DNS, а не имя NetBIOS.

Ошибка 3

Попытка выполнения операции с несуществующим сетевым подключением.

Разрешение

При вводе имени домена убедитесь, что вы вводите имя DNS, а не имя NetBIOS. Кроме того, перезагрузите компьютер, прежде чем пытаться присоединить его к домену.

Ошибка 4

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

Разрешение

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

При вводе имени домена убедитесь, что вы вводите имя DNS, а не имя NetBIOS.

Ошибка 5

Разрешение

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

При вводе имени домена убедитесь, что вы вводите имя DNS, а не имя NetBIOS.

Кроме того, вы можете обновить драйвер сетевого адаптера.

Ошибка 6

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

Разрешение

Прежде чем присоединять компьютер к домену, убедитесь, что вы удалили все сопоставленные подключения к любым дискам.

При вводе имени домена убедитесь, что вы вводите имя DNS, а не имя NetBIOS.

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

Ошибка 7

Недопустимый формат указанного имени сети.

Разрешение

При вводе имени домена убедитесь, что вы вводите имя DNS, а не имя NetBIOS. Убедитесь, что у вас установлены самые последние версии драйверов для сетевого адаптера клиентского компьютера. Проверьте подключение между подключаемым клиентом и целевым контроллером домена через требуемые порты и протоколы. Отключите функцию разгрузки TCP Chimney и разгрузку IP.

Ошибка 8

Служба каталогов исчерпала пул относительных идентификаторов.

Разрешение

Убедитесь, что контроллер домена, на котором размещен мастер операций с относительным идентификатором (RID), находится в сети и работает. Дополнительные сведения см. в разделе Событие с кодом 16650: не удалось инициализировать распределитель идентификаторов учетных записей в Windows Server.

Вы можете использовать команду netdom query fsmo, чтобы определить, какой контроллер домена имеет роль хозяина RID.

Убедитесь, что Active Directory реплицируется между всеми контроллерами домена. Вы можете использовать следующую команду для обнаружения ошибок:

Ошибка 9

Вызов удаленной процедуры завершился неудачно и не был выполнен.

Разрешение

Убедитесь, что для сетевого адаптера клиентского компьютера установлены самые последние версии драйверов. Проверьте подключение между подключаемым клиентом и целевым контроллером домена через требуемые порты и протоколы. Отключите функцию разгрузки TCP Chimney и разгрузку IP.

Эта проблема также может быть вызвана одним из следующих условий:

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

Ошибка 10

Не удалось изменить DNS-имя основного домена этого компьютера на "". Имя останется ".". Указанный сервер не может выполнить операцию.

Разрешение

Эта ошибка возникает при использовании пользовательского интерфейса присоединения к домену для присоединения компьютера рабочей группы Windows 7 или Windows Server 2008 R2 к домену Active Directory путем указания целевого домена DNS. Чтобы исправить эту ошибку, см. 2018583. При присоединении к домену Windows 7 или Windows Server 2008 R2 отображается ошибка «Не удалось изменить DNS-имя основного домена этого компьютера на «».

Сообщения об ошибках аутентификации и решения

Ошибка 1

Вы превысили максимальное количество учетных записей компьютеров, которые вам разрешено создавать в этом домене.

Разрешение

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

Чтобы присоединить компьютер к домену, учетной записи пользователя должны быть предоставлены разрешения на создание объектов компьютеров в Active Directory.

По умолчанию пользователь без прав администратора может присоединять к домену Active Directory не более 10 компьютеров.

Ошибка 2

Разрешение

Убедитесь, что контроллеры домена (DC) зарегистрированы с использованием правильных IP-адресов на DNS-сервере, а их имена участников-служб (SPN) правильно зарегистрированы в их учетных записях Active Directory.

Ошибка 3

Разрешение

Убедитесь, что у вас есть права на добавление компьютеров в домен. Чтобы присоединить компьютер к домену, учетной записи пользователя должно быть предоставлено разрешение на создание объекта компьютера в Active Directory.

Кроме того, убедитесь, что указанной учетной записи пользователя разрешен локальный вход на клиентский компьютер. Для этого настройте параметр Разрешить локальный вход в групповую политику в разделе Конфигурация компьютера > Параметры Windows > Параметры безопасности > Локальные политики > Назначение прав пользователя.

Ошибка 4

Разрешение

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

Ошибка 5

Сопоставление имен учетных записей и идентификаторов безопасности не выполнялось.

Разрешение

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

Ошибка 6

Недостаточно памяти для выполнения этой операции.

Разрешение

Эта ошибка может возникнуть, если размер токена Kerberos превышает максимальный размер по умолчанию. В этой ситуации необходимо увеличить размер токена Kerberos компьютера, который вы пытаетесь присоединить к домену.Дополнительные сведения см. в следующих статьях базы знаний:
935744 Сообщение об ошибке «Недостаточно памяти для выполнения этой операции» при использовании контроллера домена для присоединения компьютера к домену
327825 Проблемы с Kerberos аутентификация, когда пользователь принадлежит ко многим группам

Ошибка 7

Учетная запись не авторизована для входа с этой станции.

Разрешение

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

Ошибка 8

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

Разрешение

Убедитесь, что на контроллере домена, через который вы пытаетесь присоединиться к домену, запущена служба времени Windows.

Теперь доступен улучшенный портал Microsoft 365 Defender. Этот новый интерфейс переносит Защитник для конечной точки, Защитник для Office 365, Защитник Microsoft 365 и многое другое на портал Защитника Microsoft 365. Узнайте, что нового.

Относится к

Аутентификация электронной почты (также известная как проверка электронной почты) – это группа стандартов, направленных на предотвращение спуфинга (сообщений электронной почты от поддельных отправителей). Во всех организациях Microsoft 365 EOP использует следующие стандарты для проверки входящей электронной почты:

В оставшейся части этой статьи объясняется, как работают эти технологии и как EOP использует их для проверки входящей электронной почты.

Используйте аутентификацию по электронной почте, чтобы предотвратить спуфинг

DMARC предотвращает спуфинг, проверяя адрес отправителя в сообщениях. Адрес отправителя — это адрес электронной почты отправителя, который пользователи видят в своем почтовом клиенте. Целевые почтовые организации также могут проверить, прошел ли домен электронной почты SPF или DKIM. Другими словами, домен прошел проверку подлинности, поэтому адрес электронной почты отправителя не подделывается.

По состоянию на март 2018 г. только 9 % доменов компаний из списка Fortune 500 публикуют надежные политики проверки подлинности электронной почты. Остальные 91% компаний могут быть подделаны злоумышленником. Если не используется какой-либо другой механизм фильтрации электронной почты, электронная почта от поддельных отправителей в этих доменах может быть доставлена пользователям.

Доля малых и средних компаний, публикующих строгие политики проверки подлинности электронной почты, меньше. И это число еще меньше для доменов электронной почты за пределами Северной Америки и Западной Европы.

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

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

Композитная аутентификация

Если в домене нет традиционных записей SPF, DKIM и DMARC, эти проверки записей не передают достаточно информации о состоянии аутентификации. Поэтому Microsoft разработала алгоритм неявной проверки подлинности электронной почты. Этот алгоритм объединяет несколько сигналов в одно значение, называемое составной аутентификацией или сокращенно compauth. Значение compauth указывается в заголовке Authentication-Results в заголовках сообщений.

Исследуя заголовки сообщений, администраторы или даже конечные пользователи могут определить, как Microsoft 365 определил, что отправитель подделан.

Почему аутентификации по электронной почте не всегда достаточно, чтобы остановить спуфинг

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

В домене отправителя могут отсутствовать необходимые записи DNS или записи неправильно настроены.

Исходный домен имеет правильно настроенные записи DNS, но этот домен не соответствует домену в адресе отправителя. SPF и DKIM не требуют, чтобы домен использовался в адресе отправителя.Злоумышленники или легитимные сервисы могут зарегистрировать домен, настроить SPF и DKIM для домена, а в адресе отправителя использовать совершенно другой домен. Сообщения от отправителей в этом домене будут проходить SPF и DKIM.

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

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

Если домен в SPF или подпись DKIM не совпадают с доменом в адресе отправителя, сообщение может не пройти комплексную аутентификацию:

Решения для законных отправителей, отправляющих электронную почту без аутентификации

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

Настройте аутентификацию электронной почты для принадлежащих вам доменов

Этот метод можно использовать для устранения спуфинга внутри организации и междоменного спуфинга в случаях, когда вы владеете несколькими арендаторами или взаимодействуете с ними. Это также помогает устранить междоменную подделку, когда вы отправляете другим клиентам в Microsoft 365 или третьим сторонам, размещенным у других поставщиков.

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

Microsoft не предоставляет подробных рекомендаций по внедрению записей SPF, DKIM и DMARC. Тем не менее, есть много информации, доступной в Интернете. Существуют также сторонние компании, помогающие вашей организации настроить записи проверки подлинности электронной почты.

Вы не знаете всех источников электронной почты

Многие домены не публикуют записи SPF, поскольку не знают всех источников электронной почты для сообщений в своем домене. Начните с публикации записи SPF, содержащей все источники электронной почты, о которых вы знаете (особенно там, где находится ваш корпоративный трафик), и опубликуйте нейтральную политику SPF ?all . Например:

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

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

Начав с резервной политикой SPF ?all , вы сможете постепенно обнаруживать и включать в свои сообщения дополнительные источники электронной почты, а затем обновлять запись SPF, используя более строгую политику.

Настроить разрешенных отправителей электронной почты, не прошедших проверку подлинности

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

Для внешних доменов поддельный пользователь — это домен в адресе отправителя, а инфраструктура отправителя — либо исходный IP-адрес (разделенный на диапазоны CIDR /24), либо домен организации обратной записи DNS (PTR). .

Создайте разрешающую запись для пары отправитель/получатель

Чтобы обойти фильтрацию нежелательной почты, некоторые части фильтрации фишинга, но не фильтрацию вредоносных программ для определенных отправителей, см. раздел Создание списков надежных отправителей в Microsoft 365.

Попросите отправителя настроить аутентификацию электронной почты для доменов, которыми вы не владеете

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

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

Настройте SPF для публикации отправляющих IP-адресов домена и настройте DKIM (если доступно) для цифровой подписи сообщений. Им также следует подумать о настройке записей DMARC.

Если они используют массовые отправители для отправки электронной почты от своего имени, убедитесь, что домен в адресе отправителя (если он принадлежит им) совпадает с доменом, который проходит проверку SPF или DMARC.

Убедитесь, что следующие местоположения (если они используются) включены в запись SPF:

Локальные почтовые серверы.
Электронное письмо, отправленное поставщиком программного обеспечения как услуги (SaaS).
Электронное письмо, отправленное из службы облачного хостинга (Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services и т. д.).

Для небольших доменов, размещенных у интернет-провайдера, настройте запись SPF в соответствии с инструкциями интернет-провайдера.

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

Информация для поставщиков инфраструктуры (ISP, ESP или служб облачного хостинга)

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

Убедитесь, что у ваших клиентов есть документация, объясняющая, как ваши клиенты должны настраивать свои записи SPF

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

Доставка в Microsoft не гарантируется, даже если вы аутентифицируете электронную почту, отправленную с вашей платформы, но, по крайней мере, это гарантирует, что Microsoft не отправит вашу электронную почту в мусор, потому что она не аутентифицирована.

Ссылки по теме

Дополнительную информацию о рекомендациях для поставщиков услуг см. в разделе Рекомендации M3AAWG по обмену мобильными сообщениями для поставщиков услуг.

В этой статье исправлена проблема, из-за которой приложение не могло аутентифицировать пользователей при выключении контроллера домена (DC).

Применимо к: Window 10 — все выпуски, Windows Server 2012 R2

Исходный номер базы знаний: 2683606

Симптомы

Приложения в домене используют диспетчер локальной сети NT (NTLM) или Kerberos для аутентификации пользователей. Некоторые приложения имеют шаблон, при котором клиенты часто повторно подключаются к серверу приложений.

Приложения чаще всего страдают при использовании NTLM. Приложения, использующие Kerberos, также могут быть затронуты, если для проверки подлинности, принимаемой приложением, используется проверка сертификата атрибута привилегий (PAC) Kerberos. Не во всех случаях эти проверки можно отключить.

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

В журналах диагностики и сетевых трассировках вы можете увидеть ошибки входа пользователя в систему или ошибку 0xc0000064 STATUS_NO_SUCH_USER, которая показывает, что указанная учетная запись не существует. Если вы используете Kerberos, вы можете увидеть ошибку 6, KDC_ERR_C_PRINCIPAL_UNKNOWN.

Причина

Могут возникнуть две проблемы:

Когда контроллер домена находится в фазе отключения, он обычно указывает текущим клиентам использовать другой контроллер домена для аутентификации, используя код ошибки 0xc00000dc (STATUS_INVALID_SERVER_STATE). Существует путь кода, где эта проблема не возникает.

Сервер не будет избегать ответа новым клиентам на запросы Netlogon User Datagram Protocol (UDP). Кроме того, клиенты, которые получили сообщение об ошибке, что контроллер домена отключен, не будут избегать выбора того же контроллера домена при последующем поиске контроллера домена.

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

В случае NTLM клиент является сервером приложений, поэтому он не может принимать новых клиентов, пока не будет выбран работающий контроллер домена.

Разрешение

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

Запустите Gpedit.msc

Откройте дерево настроек и перейдите к: Конфигурация компьютера > Настройки Windows > Сценарии > Завершение работы.

В командной строке нового сценария введите net stop netlogon && net stop kdc .

Хотя вы можете установить для параметра реестра NegativeCachePeriod низкое значение, это изменение не полностью устранит проблему, так как клиент будет чаще искать альтернативный контроллер домена.

Подробнее

В журнале Netlogon.log клиента вы увидите, что он получил от контроллера домена код ошибки STATUS_INVALID_SERVER_STATE:

[КРИТИЧЕСКОЕ] NlPrintRpcDebug: не удалось получить EEInfo для I_NetLogonSamLogonEx: 1761 (может быть допустимым для 0xc00000dc)
[КРИТИЧЕСКОЕ] : NlpUserValidateHigher: отказ в доступе после состояния: 0xc00000dc 0
[SESSION ] : NlSetStatusClientSession: Установить статус соединения на c00000dc
[SESSION] : NlSetStatusClientSession: Отвязать от сервера \\ . (TCP) 1.

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

[SESSION] : NlSessionSetup: попытка настройки сеанса
[SESSION] : NlDiscoverDc: запуск синхронного обнаружения
[MISC] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c01ffff1
[MAILSLOT] NetpDcPingListIp: : Отправлен ping UDP на 10.10.103.87
[SESSION] Получена функция NETLOGON_CONTROL_TC_QUERY.
[MAILSLOT] NetpDcPingListIp: : отправлен UDP-пинг на 10.10.103.93
[MAILSLOT] NetpDcPingListIp: : отправлен UDP-пинг на 10.10.103.92

Второй эхо-запрос отправляется на DC при завершении работы.

Контроллер домена ответит, хотя уже вернул клиенту сообщение об ошибке:

[LOGON] HM-REBOOT: SamLogon: Transitive Вход в сеть \test1 из HM-REBOOT-SRV1 (через HM-REBOOT-SRV1) Вход
[LOGON] HM-REBOOT: SamLogon: Transitive Сетевой вход \test1 из HM-REBOOT-SRV1 (через HM-REBOOT-SRV1) возвращает 0xC00000DC
.
[MAILSLOT] Получен ping-запрос от HM-REBOOT-SRV1 (нулевой) на UDP LDAP
[MAILSLOT] : Ping-ответ 'Sam Logon Response Ex' (null) на \\ Site: Default-First-Site -Name в UDP LDAP
[MAILSLOT] : Ping-ответ 'Sam Logon Response Ex' (null) на \\ Site: Default-First-Site-Name в UDP LDAP

В этой статье представлены общие решения проблем, связанных с неправильной работой контроллера домена.

Применимо к: Windows Server 2012 R2
Исходный номер базы знаний: 837513

Симптомы

При запуске средства Dcdiag на контроллере домена под управлением Microsoft Windows 2000-Server или на контроллере домена под управлением Windows Server 2003 может появиться следующее сообщение об ошибке:

Диагностика контроллера домена
Выполнение первоначальной настройки:
[DC1] привязка LDAP завершилась ошибкой 31

При локальном запуске утилиты REPADMIN /SHOWREPS на контроллере домена может появиться одно из следующих сообщений об ошибке:

[D:\nt\private\ds\src\util\repadmin\repinfo.c, 389] Ошибка LDAP 82 (локальная ошибка).

Последняя попытка @ yyyy-mm-dd hh:mm.ss не удалась, результат 1753: конечные точки больше не доступны в сопоставителе конечных точек.

Последняя попытка @ гггг-мм-дд чч:мм.сс не удалась, результат 5: доступ запрещен.

Если вы используете сайты и службы Active Directory для запуска репликации, вы можете получить сообщение об отказе в доступе.

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

Нет доступных серверов входа (c000005e = "STATUS_NO_LOGON_SERVERS")

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

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

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

Клиентам Microsoft Outlook, подключенным к компьютерам Microsoft Exchange Server, использующим уязвимые контроллеры домена для проверки подлинности, может быть предложено ввести учетные данные для входа, даже если имеется успешная проверка подлинности входа с других контроллеров домена.

Инструмент Netdiag может отображать следующие сообщения об ошибках:

Тест списка DC . . . . . . . . . . . : Ошибка
[ПРЕДУПРЕЖДЕНИЕ] Не удается вызвать DsBind для . ( ). [ERROR_DOMAIN_CONTROLLER_NOT_FOUND]
Тест Kerberos. . . . . . . . . . . : Ошибка
[FATAL] У Kerberos нет билета для krbtgt/ .

[FATAL] У Kerberos нет билета для .
Тест LDAP. . . . . . . . . . . . . : Пройдено
[ПРЕДУПРЕЖДЕНИЕ] Не удалось запросить регистрацию имени участника-службы на контроллере домена

В журнале системных событий затронутого контроллера домена может быть зарегистрировано следующее событие:

Разрешение

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

Способ 1. Исправьте ошибки системы доменных имен (DNS).
Способ 2. Синхронизируйте время между компьютерами.
Способ 3. Установите флажок Доступ к этому компьютеру из прав пользователя сети.
Способ 4. Убедитесь, что атрибут userAccountControl контроллера домена имеет значение 532480.
Способ 5. Исправьте область Kerberos (убедитесь, что раздел реестра PolAcDmN и раздел реестра PolPrDmN совпадают).
Способ 6. Сбросьте пароль учетной записи компьютера, а затем получите новый билет Kerberos.

Способ 1. Исправление ошибок DNS

В командной строке введите команду netdiag -v. Эта команда создает файл Netdiag.log в папке, где была запущена команда.
Прежде чем продолжить, устраните все ошибки DNS в файле Netdiag.log. Инструмент Netdiag находится в составе средств поддержки Windows 2000 Server на компакт-диске Windows 2000 Server или доступен для загрузки.
Убедитесь, что DNS настроен правильно. Одной из наиболее распространенных ошибок DNS является указание контроллера домена на поставщика услуг Интернета (ISP) для DNS вместо указания DNS на самого себя или на другой DNS-сервер, который поддерживает динамические обновления и записи SRV. Мы рекомендуем указать контроллер домена на себя или на другой DNS-сервер, который поддерживает динамические обновления и записи SRV. Мы рекомендуем настроить серверы пересылки к провайдеру для разрешения имен в Интернете.

Для получения дополнительных сведений о настройке DNS для службы каталогов Active Directory щелкните следующие номера статей базы знаний Майкрософт:
254680 Планирование пространства имен DNS

Способ 2. Синхронизируйте время между компьютерами

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

Способ 3. Проверьте права пользователя "Доступ к этому компьютеру из сети"

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

Измените файл Gpttmpl.inf для политики контроллеров домена по умолчанию. По умолчанию в политике контроллеров домена по умолчанию определяются права пользователя для контроллера домена. По умолчанию файл Gpttmpl.inf для политики контроллеров домена по умолчанию находится в следующей папке.

Sysvol может находиться в другом месте, но путь к файлу Gpttmpl.inf будет таким же.

Для контроллеров домена Windows Server 2003:

C:\WINDOWS\Sysvol\Sysvol\\Policies\\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf

Для контроллеров домена Windows 2000 Server:

C:\WINNT\Sysvol\Sysvol\\Policies\\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf

Справа от записи SeNetworkLogonRight добавьте идентификаторы безопасности для администраторов, для прошедших проверку пользователей и для всех. См. следующие примеры.

Для контроллеров домена Windows Server 2003:

Для контроллеров домена Windows 2000 Server:

Администраторы (S-1-5-32-544), прошедшие проверку пользователи (S-1-5-11), все (S-1-1-0) и контроллеры предприятия (S-1-5-9) ) используйте общеизвестные идентификаторы безопасности, одинаковые во всех доменах.

Удалите все записи справа от записи SeDenyNetworkLogonRight (запретить доступ к этому компьютеру из сети), чтобы соответствовать следующему примеру.

Пример одинаков для Windows 2000 Server и Windows Server 2003.

По умолчанию Windows 2000 Server не имеет записей в записи SeDenyNetworkLogonRight. По умолчанию Windows Server 2003 имеет только строковую учетную запись Support_random в записи SeDenyNetworkLogonRight. (Учетная запись строки Support_random используется удаленным помощником.) Поскольку учетная запись строки Support_random использует разные идентификаторы безопасности (SID) в каждом домене, ее нелегко отличить от обычной учетной записи пользователя, просто взглянув на SID. Вы можете скопировать SID в другой текстовый файл, а затем удалить SID из записи SeDenyNetworkLogonRight. Таким образом, вы сможете вернуть его обратно, когда закончите устранение неполадки.

SeNetworkLogonRight и SeDenyNetworkLogonRight можно определить в любой политике. Если предыдущие шаги не помогли решить проблему, проверьте файл Gpttmpl.inf в других политиках в Sysvol, чтобы убедиться, что там также не определяются права пользователя. Если файл Gpttmpl.inf не содержит ссылки на SeNetworkLogonRight или SeDenyNetworkLogonRight, эти параметры не определены в политике, и эта политика не вызывает эту проблему. Если такие записи существуют, убедитесь, что они соответствуют параметрам, указанным ранее для политики контроллера домена по умолчанию.

Способ 4. Убедитесь, что атрибут userAccountControl контроллера домена имеет значение 532480

Нажмите "Пуск", выберите "Выполнить" и введите adsiedit.msc.
Разверните NC домена, разверните DC=domain, а затем разверните OU=контроллеры домена.
Щелкните правой кнопкой мыши соответствующий контроллер домена и выберите "Свойства".
В Windows Server 2003 установите флажок Показать обязательные атрибуты и флажок Показать необязательные атрибуты на вкладке Редактор атрибутов.В Windows 2000 Server нажмите "Оба" в поле "Выбор свойств для просмотра".
В Windows Server 2003 щелкните userAccountControl в поле Атрибуты. В Windows 2000 Server щелкните userAccountControl в поле Выберите свойство для просмотра.
Если значение не равно 532480, введите 532480 в поле "Изменить атрибут", нажмите "Установить", нажмите "Применить", а затем нажмите "ОК".
Выйти из редактора ADSI.

Способ 5. Исправьте область Kerberos (убедитесь, что раздел реестра PolAcDmN и раздел реестра PolPrDmN совпадают)

Этот метод подходит только для Windows 2000 Server.

Этот раздел, метод или задача содержат инструкции по изменению реестра. Однако при неправильном изменении реестра могут возникнуть серьезные проблемы. Поэтому убедитесь, что вы внимательно выполните следующие действия. Для дополнительной защиты создайте резервную копию реестра перед его изменением. Затем вы можете восстановить реестр, если возникнет проблема. Для получения дополнительных сведений о резервном копировании и восстановлении реестра щелкните следующий номер статьи базы знаний Майкрософт:
322756 Как выполнить резервное копирование и восстановление реестра в Windows

Запустите редактор реестра.
На левой панели разверните раздел Безопасность.
В меню "Безопасность" нажмите "Разрешения", чтобы предоставить локальной группе "Администраторы" полный доступ к кусту SECURITY и его дочерним контейнерам и объектам.
Найдите ключ HKEY_LOCAL_MACHINE\SECURITY\Policy\PolPrDmN.
На правой панели редактора реестра один раз щелкните запись REG_NONE.
В меню «Вид» нажмите «Отобразить двоичные данные». В разделе "Формат" диалогового окна нажмите "Байт".
Имя домена отображается в виде строки в правой части диалогового окна "Двоичные данные". Имя домена совпадает с доменом Kerberos.
Найдите раздел реестра HKEY_LOCAL_MACHINE\SECURITY\Policy\PolACDmN.
На правой панели редактора реестра дважды щелкните запись REG_NONE.
В диалоговом окне двоичного редактора вставьте значение из PolPrDmN. (Значение из PolPrDmN будет доменным именем NetBIOS).
Перезапустите контроллер домена.

Способ 6. Сбросьте пароль учетной записи компьютера, а затем получите новый билет Kerberos

Остановите службу центра распространения ключей Kerberos, а затем установите значение запуска вручную.

Используйте инструмент Netdom из инструментов поддержки Windows 2000 Server или из инструментов поддержки Windows Server 2003, чтобы сбросить пароль учетной записи компьютера контроллера домена:

Убедитесь, что команда netdom успешно завершена. Если это не так, команда не сработала. Для домена Contoso, где затронутым контроллером домена является DC1, а рабочим контроллером домена является DC2, выполните следующую команду netdom из консоли DC1:

Перезапустите затронутый контроллер домена.

Запустите службу центра распространения ключей Kerberos, а затем установите для параметра запуска значение "Автоматически".

Для получения дополнительных сведений об этой проблеме щелкните следующие номера статей, чтобы просмотреть статьи базы знаний Майкрософт:
323542 Не удается запустить средство "Пользователи и компьютеры Active Directory", так как сервер не работает

Читайте также: