Компьютер не вводится в домен
Обновлено: 02.07.2024
Сложилась такая проблема:
есть раб.станция WinXP Pro SP2 Ru.
Также есть контроллер домена под управлением Win2003 StandartEdition SP2 Ru.
Началось с того, что раб.машина с сегодня, после включения компа, не смогла подключиться ни к каким сетевым ресурсам - запрашивала логин пароль учетной записи пользователя. постоянно, при каждом действи запрашивает их и не запоминает.
однажды нечто подобное было - решилось выводом из домена и вводом в рабочую группу, затем обратно в домен после перезагрузки.
на этот раз не помогло. После вывода из домена ввести обратно невозможно.
Выдается следующая ошибка:
Опрос проводился для SRV-записи для _ldap._tcp.dc._msdcs.gvs.local
Этим запросом были идентифицированы следующие контроллеры домена:
К возможным причинам этой ошибки относятся:
1. Записи узлов (A), которые сопоставляют имя контроллера домена его IP-адресам утеряны или содержат неправильные адреса.
проверил журнал событий и нашел следующее:
полез на контроллер домена, который одновременно яляется DNS сервером. На нем все что можно проверил, все работает.
Остальные компы все нормально логинятся и работают.
Проверил - взял читый комп установил винду аналогичную данному проблемному компу, задал не существовавшее ранее в домене имя компа и все отлично работает.
IP адреса раздаются DHCP сервером динамически, стоящем на том же контроллере домена.
Далее привожу распечатку с сервера:
Настройка протокола IP для Windows
Имя компьютера . . . . . . . . . : dc01
Основной DNS-суффикс . . . . . . : gvs.local
Тип узла. . . . . . . . . . . . . : гибридный
IP-маршрутизация включена . . . . : нет
WINS-прокси включен . . . . . . . : нет
Порядок просмотра суффиксов DNS . : gvs.local
Подключение по локальной сети - Ethernet адаптер:
Настройка протокола IP для Windows
Имя компьютера . . . . . . . . . : Vasykov_nb
Основной DNS-суффикс . . . . . . :
Тип узла. . . . . . . . . . . . . : гибридный
IP-маршрутизация включена . . . . : нет
WINS-прокси включен . . . . . . . : нет
Local Area Connection - Ethernet адаптер:
Кроме того заметил стремный глюк!
Помогите пожалуйста решить проблему без переустановки винды, если это возможно.
Спасибо Всем!
north_crow
спасибо )
проверил - все нормально установлено - переустанавливал. не помогло
ipmanyak
спасибо!
1- после написанию тут вопроса - поставил на полную проверку каспером. Ничего кроме нескольких легких троянчиков ничего не было. Все вылечил/удалил. Не помогло, та же фигня.
2- я тоже про это начал думать ) но так как никогда этого не делал не знал с чего начать ) Кстати, может быть удаление сетевухи в диспетчере устройств делает тоже самое?
Описание проблемы с вводом в домен
По идее присоединение компьютера к Active Directory это простое действие, но как оказалось даже оно может принести сложности. У меня была старая виртуальная машина на Hyper-V, поступила задача ее переустановить для тестовых служб. По идее старая учетная запись этого компьютера лежала в нужно OU и к ней применялись нужные политики доступа, логично, что я воспользовался механизмом переустановки учетной записи, доступный через правый клик по ней. Это является правильной практикой, которую советует сама Microsoft
После выполнения данной процедуры, можно спокойно присоединять, вашу виртуальную машину с тем же именем, и она попадет в базе Active Directory именно в ту OU, где лежала предшественница. Все вроде круто, но в момент ввода в домен, выскочила ошибка:
"Не удалось изменить DNS-имя основного контроллера домена на "" для этого компьютера. Будет использоваться прежнее имя: contoso.com. Убедитесь, что имя "" является допустимым для текущего домена. Ошибка: При изменении имени узла DNS для объекта невозможно синхронизировать значения имени субъекта службы"
Обычно такая ошибка выскакивает, когда были разорваны доверительные отношения или компьютер давно не проходил аутентификацию на контроллере домена, но это не наш случай, мы то только, что добавились в него.
Причины ошибки "Не удалось изменить DNS-имя основного контроллера домена"
Рассмотрим причины, по которым ваш компьютер не может пройти аутентификацию на DC и не содержится в его базе.
- Остались хвосты от предыдущей учетной записи с тем же именем
- Проблема в отключенном NetBIOS в TCP/IP
- Режет пакеты Firewall
- На контроллере закрыт UDP-порт 137
- Отсутствует PTR запись на dns имя этой учетной записи компьютера
Чистим старые хвосты в Active Directory
Сразу хочу отметить, что данный способ у меня отработал сразу. Я полностью удалил учетную запись компьютера, с которым были проблемы. После чего снова добавил нужный сервер в домен, и он уже не выдавал ошибку "Не удалось изменить DNS-имя основного контроллера домена на "" для этого компьютера". Учетная запись появилась в привычном контейнере "Computers"
Убедитесь, что включен NetBIOS через TCP/IP
Нажмите WIN+R и введите ncpa.cpl, у вас откроется окно "Панель управления\Все элементы панели управления\Сетевые подключения". Выберите ваш сетевой интерфейс, который смотрит в туже сеть, что и DC его аутентифицирующий. Перейдите в свойства сетевого интерфейса, выберите "Протокол Интернета версии 4 (TCP/IPv4)", далее кнопка "Дополнительно". На вкладке WINS, вам необходимо выбрать пункт "Включить NetBIOS" через TCP/IPv4 и сохранить настройки.
Так же на вкладке DNS, вы можете прописать дополнительные DNS суффиксы (полное имя домена), нажмите ок.
В принципе этого достаточно, чтобы избавится от ошибки ""Не удалось изменить DNS-имя основного контроллера домена на "" для этого компьютера. Будет использоваться прежнее имя: contoso.com. Убедитесь, что имя "" является допустимым для текущего домена. Ошибка: При изменении имени узла DNS для объекта невозможно синхронизировать значения имени субъекта службы""
Если вам не помогли манипуляции, то ставьте варшарк и смотрите трафик и доступность портов, не блокирует ли у вас то-то.
Я начинающий сис.админ.Мучаюсь второй день..Как решить проблему?
Решение найдено.Как оказалось,в настройках VM у сервера был прописан подключение через узел,а у всех остальных ПК через мост,поменял у всех на узел,все заработало.Всем спасибо. С сетью у вас трэш какой-то.На AD нету шлюза (как у вас там что-то маршрутизируется?), dhcp другой на win 7, разные подсети, на xp возможно вообще dhcp клиент отключен (либо ещё по какой-то причине не получает адрес). Возможно сами компы не вводятся в домен т.к. нет доступа до днс сервера.
Я предполагаю, что вы начудили с настройкой сети виртуальных машин.
Пытался настроить сервер 2012 в VM и подключить 2 ПК,но что то пошло не так.
плз, подробнее о схеме сети:
- все ли компы виртуальные?
- если нет, имеется ли роутер в физической сети? его ip и ip машины хоста гипервизора VM в студию плз
- на виртуальных машинах NAT или Bridge? upd надо Bridge точнее надо плясать от цели и подробностей конфигурации. для виртуального макета может и как раз virt only /upd (но это далеко не все.. остальное зависит от подробностей по всем пунктам)
но самое главное:
- если контроллер на VM, то где клиенты?
- каковы настройки VM в части сети?
.. и это только начало разговора, врядли короткого Все компы виртуальные.На XP мост,на 7 NAT. На сервере стоит только для узла. Сейчас ставлю 2003 сервер и так же настраиваю как и 2012,посмотрю что изменится.Где посмотреть настройки VM в части сети?
там же где и настройки сетей вообще + включать голову
варианты:
- если сеть изолированная, для начала, все машинки "хост онли"
- но контроллер любит правильную настройку сети ДО активации АД. по сему надо понять что есть маршрутизация? что есть сети/подсети? кто в вирте будет шлюзом? простейший вариант, это сначала создать макет шлюз и клиент. две ВМ, где одна роутит (2 интерфейса, бридж и хост, при чем с фиксированными адресами, для АД), вторая через него видит инет. потом на шлюзе уже поднять АД
На первый взгляд имеются проблемы с правами доступа. Однако учетная запись, под которой производится операция, входит в группу доменных администраторов и никаких ограничений на ввод компьютеров в домен для нее быть не может.
Поэтому читаем текст ошибки подробнее и видим, что проблема с доступом не к домену, а к локальным ресурсам сервера, в частности к веткам реестра. На локальном сервере у нас права локального администратора, но получается, что их недостаточно.
Для проверки запускаем оснастку управления локальными групповыми политиками (Win+R -> gpegit.msc). Переходим в раздел Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignments (Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Локальные политики\Назначение прав пользователя) и видим, что значения некоторых параметров выглядят не совсем корректно.
Вместо имен пользователей и групп в них располагаются непонятные наборы символов, смутно напоминающие 🙂 идентификаторы безопасности (SID).
Для сравнения откроем оснастку на другом, заведомо исправном сервере. Вот так должны видеть корректные настройки.
Для успешного ввода в домен необходимо добавить группу Administrators в параметр Back up files and directories (Архивация файлов и каталогов)
и в параметр Restore files and directories (Восстановление файлов и каталогов).
После внесения изменений в обязательном порядке перезагружаемся и еще раз пробуем ввести компьютер в домен. На сей раз успешно.
Как выяснилось позднее, настройки безопасности были повреждены при подготовке шаблона, точнее при обработке операционной системы утилитой sysprep. Сбой произошел потому, что подготавливаемая машина была членом домена. И хотя все данные о членстве в домене sysprep успешно очистил, при этом слегка побились и локальные настройки. Вот так.
Читайте также: