Установка сеанса к контроллеру домена windows nt или windows 2000 для домена не отвечает
Обновлено: 03.07.2024
У нас есть основной контроллер домена Server 2008 R2, у которого , похоже, возникает амнезия, когда речь заходит о том, в какой сети он находится. (Только) сетевое соединение определяется при запуске как «Публичная сеть».
Тем не менее, если я отключу, а затем снова включу соединение, оно с радостью обнаружит, что оно на самом деле является частью доменной сети.
Это потому, что доменные службы AD не запускаются при первоначальном определении сетевого расположения?
Эта проблема вызывает некоторые проблемы с правилами брандмауэра Windows (которые, как я знаю, могут быть решены другими способами), поэтому мне просто интересно узнать, знает ли кто-нибудь, почему это происходит.
Пожалуйста, повторите со мной: «Основного контроллера домена не существует, и с момента появления Windows 2000 его не было». Мои искренние извинения. Веб-разработчику приходится присматривать за сетью Windows! Сколько контроллеров домена у вас есть? Когда мы выполняем техническое обслуживание, иногда технические специалисты перезагружают оба контроллера домена одновременно! что не очень разумно (даже если это середина ночи), когда вы можете просто перезагружать перезагрузки, чтобы поддерживать все службы в рабочем состоянии.У вас есть шлюз по умолчанию для этого соединения? Он отвечает на запросы ping?
Windows использует шлюзы для идентификации сетей; если у него нет настроенного шлюза или если он не может успешно пропинговать его, он не сможет определить сеть, к которой он подключен, и предположит, что она является общедоступной.
Мы делаем - шлюз также является сервером Server 2008 R2 с Forefront Threat Management Gateway, который контроллер домена может пропинговать. Ваш DC имеет более одного NIC установленного и используемого ?? Понял - случайно включил IPv6, поэтому пытался найти шлюз через v6. Выключил и все работает нормально. Это определенно неправильно. На контроллере домена состояние брандмауэра не зависит от шлюза по умолчанию.Будет ли сеть в контроллере домена классифицируется как сеть домена не зависит от конфигурации шлюза.
Поведение ложной классификации сети может быть вызвано NLA службой (осведомленность о местоположении сети) starts before the domain is available . В этом случае общедоступная или частная сеть выбирается и впоследствии не корректируется.
Как проверить, возникает ли данная ситуация сбоя
Когда контроллер домена после перезагрузки находится в общедоступной сети, перезапустите службу NLA или отключите / повторно подключите сеть. После этого контроллер домена должен находиться в доменной сети.
Как ее решить
Это может помочь настроить службу NLA на отложенный запуск . Лучше проверьте, почему домен должен долго присутствовать. Похоже, что домен требует больше времени для запуска при наличии нескольких сетевых карт.
Когда это не помогает
Когда ни ускорение загрузки домена, ни задержка NLA не помогают, и ошибка вызвана длительной загрузкой домена (смотрите: «как проверить . »), тогда есть некоторые больше вещей, которые можно сделать.
-
Написать скрипт для его перезапуска и запустить его с планировщиком (опасно)
Сдвиньте загрузку службы NLA до конца запуска службы, изменив порядок загрузки в реестре (опасно)
Следующая запись реестра устанавливает зависимости NSI RpcSs TcpIp Dhcp Eventlog NTDS DNS :
Выполните «IPCONFIG / RENEW» из планировщика при запуске с задержкой в 1 или 2 минуты (лучше, чем запуск службы NLA)
Еще одна причина также может быть, когда на контроллере домена настроены два или более IP-адресов (на одной или других сетевых картах), а дополнительные сети не настроены в DNS.
Воспроизведение поведения
На тестовом контроллере домена (один DC!) Я удалил запись шлюза по умолчанию и установил DNS Server в delayed start . Для этого домену нужно было долго загружаться, и сеть была классифицирована как public . После отсоединения и повторного подключения сетевого кабеля сеть была правильно классифицирована как domain network .
редактировать
с благодарностью от комментариев Daniel Fisher lennybacon и Joshua Hanley :
Вариант с установкой отдельного роутера на nt, mikrotik, linux, bsd не предлагать. В сети есть достаточно гнусно написанное ПО, от которого и так багов с бугами, а если еще из-за сети проблемы пойдут, то.
Однако, проблемы повалились как всегда в другом месте.
похоже не работает integrated authentification
netbeui зачем вообще стоит? я бы удалил, если нет веских оснований.
з.ы. я бы начал troubleshooting c DNS
Самое быстрое (но, увы, не самое простое) :
использовать сниффер для диагностики (например, Microsoft Network Monitor).
Для этого взять хаб (не свитч!), на один PC установить сниффер, второй PC выключить и включить (при этом начать сниффить). Далее - фильтр и анализ. Все будет понятно как в ясный день.
Windows IP Configuration
Host Name . . . . . . . . . . . . : alfa
Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
Ethernet adapter local_64:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Dual Port Network Connection
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.64.3
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.64.1
Ethernet adapter local_248:
Connection-specific DNS Suffix . :
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.248.3
Subnet Mask . . . . . . . . . . . : 255.255.248.0
ALFA ROUTE PRINT
DNS Servers . . . . . . . . . . . : 127.0.0.1
КЛИЕНТ IPCONFIG
Windows 2000 IP Configuration
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
Ethernet adapter local:
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.249.219
Subnet Mask . . . . . . . . . . . : 255.255.248.0
Default Gateway . . . . . . . . . : 192.168.248.1
DHCP Server . . . . . . . . . . . : 192.168.248.3
DNS Servers . . . . . . . . . . . : 192.168.248.3
192.168.248.30
Primary WINS Server . . . . . . . : 192.168.248.65
Lease Obtained. . . . . . . . . . : 23 ¬ ав 2005 Ј. 15:59:02
Lease Expires . . . . . . . . . . : 31 ¬ ав 2005 Ј. 16:59:02
КЛИЕНТ ROUTE PRINT
===========================================================================
Interface List
0x1 . MS TCP Loopback interface
0x1000003 . 00 11 2f 87 f3 bf . Marvell Ethernet Controller
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.248.1 192.168.249.219 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.248.0 255.255.248.0 192.168.249.219 192.168.249.219 1
192.168.249.219 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.249.255 255.255.255.255 192.168.249.219 192.168.249.219 1
224.0.0.0 224.0.0.0 192.168.249.219 192.168.249.219 1
255.255.255.255 255.255.255.255 192.168.249.219 192.168.249.219 1
Default Gateway: 192.168.248.1
===========================================================================
Persistent Routes:
None
Добавлено:
Что интересно. Клиентские компьютеры, котрые стоят рядом с Windows 2000 работают по-разному при одинаковых настройках. Вернее, при динамичских настройках, которые для всех одинаковые. набо протоколов одинаков. Но один входи в домен номально и быстро - как раньше. А другой медленно - минут 7-10 проходит с момента загрузки Windows до появления logon-screen. И вот что на это ПК пишется в логах:
Возможно проблема в этом.
Gate умеет роутить из 248 сетки в 64? Если нет, то:
на dc ALFA как я понял у вас 2 интерфейса 192.168.248.3 и 192.168.64.3 и оба автоматом регистрируются в DNS. Клиенты обращаясь к ALFA получают случайно либо тот, либо другой ip (по технологии round robin). Если они получают 192.168.248.3, то все ОК, если 192.168.64.3 то ? Поэтому клиенты то нормально заходят, то нет. А тормоза потому что tcp/ip netbeui dns wins - пока по всему пройдется 10 мин и пройдет.
А ошибки NETLOGON на клиентах исчезли?
Тормоза могут быть еще и потому что у вас теперь две подсети и при обмене информации между ними, все пакеты проходят через Gate, а там еще небось 100 Mb адаптер, а у вас 200 компов.
Как вы понимаете, если вы просто поменяете в процессе перехода 64 подсеть на 248 то для этих клиентов все должно работать. А для тех кто остается в 64 прописываете DNS из 248 и они тоже работают, но через роутер и возможно с тормозами (если много обращений к dc) или ставите дополнительный контроллер в их подсеть.
Надо на DNS-сервере удалять записи ссылающиеся на 192.168.64.3, очищать его кэш, очищать кэш клиентов, проверять что на seceondary DNS настроено. У вас написано, что на APSERV прописан 192.168.64.3. Все надо проверить.
Однако, возникла проблема другого толка - сейчас любой пользователь может подсоединить ПК в домен. Ну это уже другая история.
В этой статье данная статья содержит общие решения проблемы, из-за которой контроллер домена не функционирует правильно.
Применяется к: Windows Server 2012 R2
Исходный номер КБ: 837513
Симптомы
Диагностика DC
Выполнение начальной установки:
[DC1] Сбой привязки LDAP с ошибкой 31
[D: \ nt \ private \ ds \ src \ util \ \ repadmin repinfo.c, 389] LDAP error 82 (Local Error).
Последняя попытка @ yyyy-mm-dd hh:mm.ss не удалась, результат 1753: конечные точки больше не доступны из конечной карты.
Последняя попытка @ yyy-mm-dd hh:mm.ss не удалась, результат 5. Доступ отказано.
Нет серверов с логотипами (c000005e = "STATUS_NO_LOGON_SERVERS")
Данные именования не могут быть расположены, так как. Для проверки подлинности не удалось связаться с никакими полномочиями. Свяжитесь с системным администратором, чтобы убедиться, что домен правильно настроен и в настоящее время находится в сети.
Данные именования не могут быть расположены, так как: имя целевой учетной записи неверно. Свяжитесь с системным администратором, чтобы убедиться, что домен правильно настроен и в настоящее время находится в сети.
Клиенты Outlook Майкрософт, подключенные к компьютерам Microsoft Exchange Server, использующим затронутые контроллеры домена для проверки подлинности, могут быть вызваны для проверки подлинности, несмотря на успешную проверку подлинности логотипов от других контроллеров домена.
Тест списка DC . . . . . . . . . . . : Не удалось
[WARNING] Не удается вызвать DsBind <servername> на .<fqdn> (<ip address>). [ERROR_DOMAIN_CONTROLLER_NOT_FOUND]
Тест Kerberos. . . . . . . . . . . : Не удалось
[FATAL] Kerberos не имеет билета для krbtgt/ <fqdn> .[FATAL] Kerberos не имеет билета <hostname> на .
Тест LDAP. . . . . . . . . . . . . : Пройдено
[WARNING] Не удалось запросить регистрацию SPN в DC <hostname><fqdn>
Следующее событие может быть в журнале событий системы затронутого контроллера домена:
Решение
Существует несколько решений для этих симптомов. Ниже приводится список методов, которые следует попробовать. За списком следуют действия для выполнения каждого метода. Попробуйте каждый метод, пока проблема не будет решена. Статьи базы знаний Майкрософт, описывая менее распространенные исправления для этих симптомов, перечислены позже.
- Метод 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 средств поддержки сервера на Windows 2000 Server CD-ROM или в качестве загрузки.
- Убедитесь, что DNS настроен правильно. Одной из наиболее распространенных ошибок DNS является указать контроллер домена поставщику интернет-служб (ISP) для DNS вместо того, чтобы указать DNS на себя или на другой DNS-сервер, который поддерживает динамические обновления и записи SRV. Рекомендуется указать контроллер домена себе или другому DNS-серверу, который поддерживает динамические обновления и записи SRV. Рекомендуется настроить переадверители в интернет-провайдер для разрешения имен в Интернете.
Дополнительные сведения о настройке службы каталогов DNS для Active Directory щелкните следующие номера статей, чтобы просмотреть статьи в базе знаний Майкрософт:
Планирование пространства имен DNS 254680
Метод 2. Синхронизация времени между компьютерами
Убедитесь, что время правильно синхронизируется между контроллерами домена. Кроме того, убедитесь, что время правильно синхронизируется между клиентские компьютеры и контроллеры домена.
Метод 3. Проверка прав пользователя "Доступ к этому компьютеру из сети"
Измените файл Gpttmpl.inf, чтобы подтвердить, что соответствующие пользователи имеют доступ к этому компьютеру от сетевого пользователя прямо на контроллере домена. Для этого выполните следующие действия:
Измените файл Gpttmpl.inf для политики контроллеров домена по умолчанию. По умолчанию политика контроллеров домена по умолчанию определяет права пользователей для контроллера домена. По умолчанию файл Gpttmpl.inf для политики контроллеров домена по умолчанию расположен в следующей папке.
Sysvol может быть в другом расположении, но путь для файла Gpttmpl.inf будет одинаковым.
Для Windows контроллеров домена Server 2003:
C: \ WINDOWS \ Sysvol \ Sysvol \ <Domainname> \ Policies \ < 6AC1786C-016F-11D2-945F-00C04fB984F9>\ MACHINE Microsoft Windows NT \ \ \ SecEdit \ GptTmpl.inf
Для Windows контроллеров домена Server 2000:
C. \ WINNT \ \ Sysvol Sysvol \ <Domainname> \ Policies \ < 6AC1786C-016F-11D2-945F-00C04fB984F9>\ MACHINE Microsoft Windows NT \ \ \ SecEdit \ GptTmpl.inf
Справа от записи SeNetworkLogonRight добавьте идентификаторы безопасности для администраторов, для пользователей с проверкой подлинности и для всех. См. следующие примеры.
Для Windows контроллеров домена Server 2003:
SeNetworkLogonRight = * S-1-5-32-554, * S-1-5-9, * S-1-5-32-544, * S-1-1-0
Для Windows контроллеров домена Server 2000:
SeNetworkLogonRight = * S-1-5-11, * S-1-5-32-544, * S-1-1-0
Администраторы (S-1-5-32-544), пользователи с проверкой подлинности (S-1-5-11), Все (S-1-1-0) и контроллеры Enterprise (S-1-5-9) используют известные идентификаторы безопасности, одинаковые в каждом домене.
Удалите все записи справа от записи SeDenyNetworkLogonRight (запретить доступ к этому компьютеру из сети), чтобы соответствовать следующему примеру.
Пример такой же для Windows 2000 и 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
Метод 5. Исправление области Kerberos (подтверждение совпадения ключа реестра PolAcDmN и ключа реестра PolPrDmN)
Этот метод действителен только для Windows 2000 Server.
В этот раздел, описание метода или задачи включены действия, содержащие указания по изменению параметров реестра. Однако неправильное изменение параметров реестра может привести к возникновению серьезных проблем. Поэтому следует в точности выполнять приведенные инструкции. Для дополнительной защиты создайте резервную копию реестра, прежде чем редактировать его. Так вы сможете восстановить реестр, если возникнет проблема. Дополнительные сведения о том, как создать и восстановить реестр, щелкните следующий номер статьи, чтобы просмотреть статью в базе знаний Майкрософт:
322756 Создание резервной копии и восстановление реестра Windows
- Начните редактор реестра.
- В левой области расширьте безопасность.
- В меню Безопасность щелкните Разрешения, чтобы предоставить локальной группе Администраторов полный контроль над ульем SECURITY и его детскими контейнерами и объектами.
- Найдите HKEY_LOCAL_MACHINE\SECURITY\Policy\PolPrDmN ключ.
- В правой области редактора реестра нажмите <No Name> кнопку : REG_NONE один раз.
- В меню Просмотр щелкните Отображение двоичных данных. В разделе Формат диалоговое окно щелкните Byte.
- Доменное имя отображается в качестве строки в правой части диалогового окна Двоичные данные. Доменное имя такое же, как и область Kerberos.
- Найдите HKEY_LOCAL_MACHINE\SECURITY\Policy\PolACDmN ключ реестра.
- В правой области редактора реестра дважды щелкните <No Name> запись : REG_NONE.
- В диалоговом окне Двоичный редактор вклейте значение от PolPrDmN. (Значение от PolPrDmN будет доменное имя NetBIOS).
- Перезапустите контроллер домена.
Метод 6. Сброс пароля учетной записи машины и получение нового билета Kerberos
Остановите службу Центра рассылки ключей Kerberos, а затем установите значение запуска вручную.
Для сброса пароля учетной записи компьютера контроллера домена используйте средство Netdom из средств поддержки Windows 2000 серверов или средств поддержки Windows Server 2003:
Убедитесь, что netdom команда возвращается успешно. Если это не так, команда не работает. Для домена Contoso, где затронутым контроллером домена является DC1, а рабочим контроллером домена — DC2, вы запустите следующую команду из netdom консоли DC1:
Перезапустите затронутый контроллер домена.
Запустите службу Центра рассылки ключей Kerberos, а затем установите параметр запуска автоматическим.
Дополнительные сведения об этой проблеме щелкните следующие номера статей, чтобы просмотреть статьи в базе знаний Майкрософт:
323542 Вы не можете запустить средство Active Directory Users and Computers, так как сервер не работает
Что в журналах системы значится?
Локальные учетки имеются на компьютере
На машине ИП-шник статический
За сегодня в логах винды:
1. Ошибка
Event filter with query "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA "Win32_Processor" AND TargetInstance.LoadPercentage > 99" could not be reactivated in namespace "//./root/CIMV2" because of error 0x80041003. Events cannot be delivered through this filter until the problem is corrected.
Настраиваемые библиотеки динамической компоновки загружаются для каждого приложения. Системный администратор должен просмотреть список библиотек, чтобы проверить, относятся ли они к надежным приложениям.
Все больше нет ошибок и предупреждений
Так я и смотрел логи, когда проблема возникла
Пользователь сегодня сказал, включил компьютер, и ждал когда винда загрузится
подождал минут 10 и перезагрузил компьютер
Так я и смотрел логи, когда проблема возникла
Пользователь сегодня сказал, включил компьютер, и ждал когда винда загрузится
подождал минут 10 и перезагрузил компьютер
Просто Вы не упомянули, что сегодня имели место проблемы. Под локальными учётками логин нормальный?
Так я и смотрел логи, когда проблема возникла
Пользователь сегодня сказал, включил компьютер, и ждал когда винда загрузится
подождал минут 10 и перезагрузил компьютер
Просто Вы не упомянули, что сегодня имели место проблемы. Под локальными учётками логин нормальный?
Windows Registry Editor Version 5.00
Windows Registry Editor Version 5.00
с реестром вообще не предпочитаю связыватся
сделаешь чего нить не так, система потом глючит
с реестром вообще не предпочитаю связыватся
сделаешь чего нить не так, система потом глючит
Эта статья относится к версии Windows, отличающейся от используемой вами. Содержание данной статьи может не относиться к вашей системе.
.
Информация в данной статье относится к следующим продуктам.
PolicyMaker Standard Edition 2.0
PolicyMaker Standard Edition 1.0
Microsoft Windows Server 2003, Standard Edition (32-bit x86)
Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
Microsoft Windows XP Professional
Операционная система Microsoft Windows 2000 Professional
операционная система Microsoft Windows 2000 Server
Microsoft Windows 2000 Advanced Server
Microsoft Windows 2000 Datacenter Server
.
Предупреждение. Неправильное изменение параметров реестра системы с помощью редактора реестра или любым другим путем может послужить причиной возникновения серьезных неполадок, которые могут привести к необходимости переустановки операционной системы. Корпорация Майкрософт не гарантирует устранения этих неполадок. Ответственность за результаты произведенных действий несет пользователь.
Совет неконструктивный. ТС правильно сомневается в целесообразности предлагаемых действий. Боже, сколько правды в глазах государственных шлюх. (с) Ю. Шевчук
Daddy love you (с)
Читайте также: