Компьютеры не авторизуются на контроллере домена в сайте

Восстановление доверительных отношений в домене

Бывает такая ситуация, что компьютер не может пройти проверку подлинности в домене. Вот несколько примеров:

• После переустановки ОС на рабочей станции машина не может пройти проверку подлинности даже с использованием того же имени компьютера. Поскольку в процессе новой установки ОС генерируется SID-идентификатор и компьютер не знает пароль учетной записи объекта компьютера в домене, он не принадлежит к домену и не может пройти проверку подлинности в домене.
• Компьютер полностью восстановлен из резервной копии и не может пройти проверку подлинности. Возможно, после архивации объект компьютера изменил свой пароль в домене. Компьютеры изменяют свои пароли каждые 30 дней, а структура Active Directory помнит текущий и предыдущий пароль. Если была восстановлена резервная копия компьютера с давно устаревшим паролем, компьютер не сможет пройти проверку подлинности.
• Секрет LSA компьютера давно не синхронизировался с паролем, известным домену. Т.е. компьютер не забыл пароль — просто этот пароль не соответствует реальному паролю в домене. В таком случае компьютер не может пройти проверку подлинности и безопасный канал не будет создан.

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

• Сообщения при входе в домен указывают, что компьютеру не удалось установить связь с контроллером домена, отсутствует учетная запись компьютера, введен неправильный пароль учетной записи компьютера или потеряно доверие (безопасная связь) между компьютером и доменом.
• Сообщения или события в журнале событий, указывающие аналогичные ошибки или предполагающие неполадки паролей, доверительных отношений, безопасных каналов либо связи с доменом или контроллером домена. Одна из таких ошибок — отказ проверки подлинности с кодом ошибки 3210 в журнале событий компьютера.
• Учетная запись компьютера в Active Directory отсутствует.

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

Поэтому необходимо сделать так :

Открыть оснастку Active Directory, выбрать «Пользователи и компьютеры», щелкнуть объект компьютера правой кнопкой мыши и применить команду «Переустановить учетную запись». После этого компьютер следует заново присоединить к домену и перезагрузиться.

Чтобы перезагрузка после сброса безопасного канала не требовалось, нужно использовать либо команду Netdom, либо Nltest.

C помощью учетной записи, относящейся к локальной группе «Администраторы»:

netdom reset Имя_машины /domain Имя_домена /Usero Имя_пользователя /Passwordo

Компьютеры не авторизуются на контроллере домена в сайте

Проблема такая: есть роутер на линуксе, его установил провайдер, 2 сетевухи — одна от него, другая в свич 10.10.12.254. Я могу прописывать там IP-шники своих машин для досупа в ИНЕТ, локалка состоит из 13 машин + контроллер домена и 6 машин не в домене, с теми что не в домене проблем нет — ИНЕТ работает нормально и загружаются нормально, а вот с теми что в домене проблемы — грузятся(авторизуются) долго, минут 5 не зависимо включился комп или уже кто то работал. Проблема возникла после того когда провайдер поменял у себя адресацию и я в своей локалке поменял IP-шники с 192.168.0.Х на 10.10.12.Х раньше прописывал адрес шлюза(192.168.0.254), DNS основной(192.168.0.33 IP-шник контроллера домена) и дополнительный (192.168.0.254 IP-шник роутера), сейчас адрес шлюза(10.10.12.254), DNS основной(10.10.12.254 IP-шник роутера) и дополнительный (10.10.12.33 IP-шник контроллера домена) думал может так долго изза объязательного профиля (man), но если под пользователем который не имеет оного — картина та же :quest: если поменять местами IP-шник роутера и IP-шник контроллера то авторизация быстро (секунд 15-20) но нет ИНЕТа 🙁

вот файлы журналов событий, там есть с рабочего и с сервера http://ifolder.ru/14147885

посоветуйте что может быть и как вылечить

может проблемы не будет если поднять на 2003, но вот не знаю потянет ли машина (duron 1.6 + 512 -8 int video)

Забегая вперёд скажу, что zss прав.
может проблемы не будет если поднять на 2003А сейчас домен на чём тогда?
Если хочешь показывать провайдеру и своим соседям, висящим на том же роутере, свою локалку — пожалуйста. Обычно всё же создают свой шлюз, который можно контролировать самостоятельно. И локалку сажают за него.
Попробуй с любого клиента разрешить имя сервера в IP?
nslookup имя_сервера
Почему ты видишь такой странный ответ? А кто знает правильный? Только твой сервер. Ты его спросил? Нет, ты полез к провайдеру зачем-то.
Практическая проблемка маленькая, но за ней чёрный провал в теории. Учи матчасть.

zss,
PLAstic,
в том то и дело когда ставлю первым IP-шник свой в DNS — авторизация отличная, а вот Инета тогда нету.
роутер только мой и на нем только моя локалка.

ЗЫ счас на 2000 домен стоит

Конечно нету. Мы сейчас дадим тебе халявный ответ, что надо настраивать форвардинг DNS-запросов на роутер, а потом кто в режиме аврала тебе поможет? Полное незнание теории кто закрывать будет?
Лучше день потерять, чтоб за час долететь (с) М/ф «Крылья, ноги и хвосты». Садись и читай книги про DNS.
Ещё одна цитата хорошая: благодаря таким специалистам как ты, у меня такая высокая зарплата. Спасибо.

PLAstic, да читал я про форвардинг. правда туго как то :(. НО как тогда объяснить что раньше все работало как часики (в первом посте написал как было) и тогд аникакого форвардинга не было, это я счас уже о нем прочитал, может не правильно понимаю: надо прописать в своем DNS-е IP-шник роутера?

посоветуйте книгу, пожалуйста

надо прописать в своем DNS-е IP-шник роутера?НЕТ! Надо сказать ему «чувак, когда ты не знаешь, что это за имя, лезь на роутер». Если ты хочешь повысить собственный уровень знаний, набери на яндексе «настройка форвардинга DNS (http://yandex.ru/yandsearch?text=%ED%E0%F1%F2%F0%EE%E9%EA%E0+%F4%EE %F0%E2%E0%F0%E4%E8%ED%E3%E0+DNS&lr=1)».

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

есть цитата «. если хочешь помочь новичку — сделай вместе с ним. » без обид

надо настраивать форвардинг DNS-запросов на роутер
да читал я про форвардинг. правда туго как тоЭто показывает лень. Лень разбираться, дайте мне готовый ответ. Какое желание помогать при виде лени? В любой области.

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

Это показывает лень. Лень разбираться, дайте мне готовый ответ. Какое желание помогать при виде лени? В любой области.

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

не лень, а простая банальная нехватка времени. а домен поднял что б был порядок, а сейчас вот столкнулся с проблемой и решу ее, уже нашел ХОРОШУЮ(надо будет заказать гдет обумажный оригинал — намного лучше) книгу в електронном варианте, а по поводу форвардинга — если завтра не успею настроить (прочитал и в принципе ничего сложного.. но есть пока нехватка опыта) то буду в воскресенье копаться. по ходу вопрос. если конешно можно: в имени домена насколько критично одно имя без суффикса (не помню термин)?

а по поводу лени — время ответа думаю скажет само за себя 🙂 а по поводу разбиаться — решение надо «на вчера» а время будет только в воскресенье

насколько критично одно имя без суффиксаCтавь точку в конце. Вторая часть имени есть, но пустая.
Опять же, если домен уровня 2003, то его можно переименовать. Средства переименования доменов Active Directory в Windows Server 2003. (http://technet.microsoft.com/ru-ru/windowsserver/bb405948.aspx)
Ты мог бы указать второй DNS-сервер в настройках клиентов, но с форвардингом чуток быстрее. Твой DNS будет самостоятельно запрашивать новые имена и кешировать запросы. Клиентам не придётся ждать ответа от первого DNS-сервера, мол «я не знаю такого имени».

Ты мог бы указать второй DNS-сервер в настройках клиентов, но с форвардингом чуток быстрее. Твой DNS будет самостоятельно запрашивать новые имена и кешировать запросы. Клиентам не придётся ждать ответа от первого DNS-сервера, мол «я не знаю такого имени».

вот именно, что так не работает ИНЕТ и не пойму почему, про кеширование тоже читал, и самое главное что так и было: первый — контроллер, второй роутер, а после смены IP-шников перестало работать, никакие настройки не менял.

это я просто попробовать то прописал первым роутер, а вторым контроллер — то долго авторизуется. но ИНЕТ есть

и еще спросить: 512 мозгов хватит для работы КД на 2003 (счас 2000), я знаю минимальные системные требования (256) но просто из практики как будет работать если он будет только как контроллер домена и все, ничего больше на нем не будет из приложений, кроме антивируса

uglubka, на контроллере домена ставь форвардинг на реальный адрес DNS провайдера (можно посмотреть в настройках роутера), при этом шлюз по умолчанию должен быть роутер (10.10.12.254), тогда запросы пройдут. На компьютерах домена ставь DNS только основной на контроллер (10.10.12.33) и шлюз на роутер (10.10.12.254).

Компьютеры не авторизуются на контроллере домена в сайте

Сообщения: 226
Благодарности: 4

Добрый вечер.
Продолжаю экспериментировать с Server 2012 в виртуальной среде.

Имеется сконфигурированный по умолчанию контроллер домена и введенный в этот домен Windows 7.

Cenmm проблемы:
При выключенном контроллере домена, на клиент с Windows 7 можно без проблем залогиниться от любого пользователя домена. Даже под пользователем который ранее не заходил на клиент Windows 7.

Я так понимаю, Windows 7 каким то образом закешировал структуру Active Directory. Как же так получилось?
Насколько я помню, в предыдущих версиях Active Directory на базе Server 2008/R2 такого не было. И при недоступности службы Active Directory, авторизоваться в системе было нельзя.

Заходим на сервер когда отсутствует связь с сервером

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

В WIndows за кэширование отвечает параметр реестра CashedLogonsCount, найти его можно по пути

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

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

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

Я для примера хочу ее распространить на весь домен, а по умолчанию в AD создается Default Domain Policy политика, правым кликом по ней и выбираем изменить.

Переходим в раздел

Конфигурация компьютера > Политики > Конфигурация Windows > Параметры безопасности > Локальные политики > Параметры безопасности

Тут вам нужно найти параметр Интерактивный вход в систему: количество предыдущих подключений к кэшу, по сути это и есть CashedLogonsCount, Сам параметр можно задать от 0 до 50. Если выставите 0, то полностью запретите локальное кэширование, это правильно с точки зрения безопасности. но не даст вам войти на компьютер при отсутствии доступа к контроллеру и покажет вам отсутствуют серверы которые могли бы обработать запрос.

В английской версии это

Computer ConfigurationPoliciesWindows SettingsSecurity SettingsLocal PoliciesSecurity Options и найти параметр Interactive logon: Number of previous logons to cache (in case domain controller is not available)

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

Компьютеры не авторизуются на контроллере домена в сайте

Как добавить пользователя или группу пользователей на контроллер домена/ AD? Многие ответят- Да очень просто, зайти в «Диспетчер сервера- Конфигурация- Локальные пользователи- Пользователи удаленного рабочего стола» и добавить необходимого пользователя или группу пользователей. И будут НЕ ПРАВЫ поскольку на контролере домена отсутствует группа Локальные пользователи. По умолчанию только Доменный администраторы имеют терминальный доступ на контролер домена.

НЕ КОНТРОЛЛЕР ДОМЕНА	КОНТРОЛЛЕР ДОМЕН

Как же это обойти? Да очень просто, с помощью групповых политик. Создаем или изменяем политику для контроллера домена. Для этого заходим в групповые политики «Пуск-Администрирование- Управление групповой политикой»/ «Start- (Programs)-Administrative Tools- Group Police Management». В данном примере я создаю новую политику Terminal access to users on AD. Нажимем на ней правой кнопкой мыши –«Изменить»/ «Edit». Заходим «Конфигурация компьютера- Политики -Конфигурация Windows — Параметры безопасности — Локальные политики — Назначение прав пользователя» в параметре «Разрешить вход в систему через службу удаленных рабочих столов» / «Computer Configuration- Policies- Windows Settings- Security Setting- Local Policies-User Rights Assignment » в параметре «Allow log on through Remote Desktop Services» добавляем пользователя/ группу пользователей которым необходим терминальный доступ на котроллер домена.

После того как создана политика необходимо добавить этого же пользователя/ группу пользователей в терминальный доступ на контроллере домена. Нажимаем правой кнопкой мыши на ярлыке «Мой компьютер» выбираем «Свойства- Удавленное подключение» / «Properties- Remote Setting».

Далее указываем необходимого пользователя/ группу пользователей и нажимаем «ОК».

После всех этих шагов пользователь/ группа пользователей будут иметь терминальный доступ на контроллер домена/ AD.

Командлет PowerShell 3.0

В отличие от утилиты Netdom, PowerShell 3.0 входит в состав системы начиная с Windows 8 / Server 2012, для более старых систем его можно установить вручную, поддерживаются Windows 7, Server 2008 и Server 2008 R2. В качестве зависимости требуется Net Framework не ниже 4.0.

Точно также войдите на системе, для которой нужно восстановить доверительные отношения, локальным администратором, запустите консоль PowerShell и выполните команду:

• Server — имя любого контроллера домена
• Credential — имя домена / учетной записи администратора домена

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

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

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