Исправить Мы не можем подписать вас с этими учетными данными, потому что ваш домен недоступен
Пользователи, использующие системы в организациях, системы, которые должны быть присоединены к домену, подключены к сети компании и связаны общей групповой политикой, часто сообщают об ошибке:
Мы не можем подписать вас с этими учетными данными, потому что ваш домен недоступен. Убедитесь, что ваше устройство подключено к сети вашей организации, и повторите попытку. Если вы ранее входили в систему на этом устройстве с другими учетными данными, вы можете войти в систему с этими учетными данными.
При чтении этой ошибки первая мысль, которая приходит в голову, заключается в том, что система не присоединена к правильному домену, и нам нужно будет войти в систему как администратор и выполнить необходимое. Однако это случается редко. Скорее, большинство пользователей смогли войти в свою систему задолго до того, как получили эту ошибку, поэтому не должно быть, чтобы система внезапно отсоединилась от домена.
Мы могли бы последовательно попробовать следующие решения, чтобы устранить проблему:
Решение 1. Перезагрузите систему без подключения к сети.
Чтобы прочитать статус связи системы с организацией, система должна быть подключена к сети. Однако менее известен тот факт, что нам фактически не нужно входить в систему, чтобы подключить ее к Интернету. Если для какой-либо сети установлено значение по умолчанию, система подключится к сети до того, как достигнет экрана блокировки. Чтобы изолировать эту проблему, нам потребуется отключить сеть и перезагрузить систему.
1] Вы можете увидеть значок подключения к сети в правом нижнем углу экрана. Оттуда отключитесь от сети.
2] Если это невозможно, попробуйте вручную отключить источники сетевого подключения (например, отключите кабель Ethernet или выключите маршрутизатор WiFi).
3] Перезагрузите систему и проверьте, помогает ли она на этот раз.
Если это не сработает, войдите в систему как администратор, чтобы выполнить дальнейшие действия по устранению неполадок.
Решение 2] Удалите пользователя из защищенной группы пользователей.
Защищенной группой пользователей управляет ИТ-группа организации или вообще администратор сервера группы управляемых систем. Если пользователь добавлен в эту группу, он может столкнуться с проблемами при обычном входе в систему, особенно если добавление произошло недавно. Иногда он меняет связанный домен (это случилось со мной дважды). Таким образом, нам нужно будет связаться с командой, контролирующей разрешения в активном каталоге, чтобы внести соответствующие изменения.
Решение 3] Использование оснастки политики безопасности
3] На правой панели найдите политику Интерактивный вход в систему: количество предыдущих входов в систему для кеширования (в случае, если контроллер домена недоступен) и дважды щелкните его, чтобы изменить его значение. Измените значение «Не кэшировать вход в систему» на 0.
Решение 4] Измените адрес DNS-сервера.
3] Дважды щелкните Интернет-протокол версии 4, чтобы открыть его свойства.
4] Установите переключатель в положение «Использовать следующий адрес DNS-сервера».
5] Введите следующие значения:
Предпочтительный DNS-адрес: 8.8.8.8
Альтернативный DNS-адрес: 8.8.4.4
6] Нажмите ОК, чтобы сохранить настройки и перезагрузить систему.
Решение 6. Удалите поврежденный профиль из редактора реестра.
1. Найдите regedit в окне поиска Windows 10 и откройте редактор реестра.
2. Прежде чем продолжить, просто сделайте резервную копию редактора реестра, выбрав « Файл»> «Экспорт» в редакторе реестра.
3. Теперь перейдите в следующее место в редакторе реестра.
HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ ProfileList
Вход в систему при недоступности контроллера домена
При входе на компьютер с доменной учетной записью пользователь вводит свои учетные данные, которые передаются на ближайший контроллер домена для проверки подлинности. Если в сетевом окружении отсутствуют доступные контроллеры домена, то учетные данные проверить некому и в систему пользователь войти не сможет.
Чтобы избежать подобной ситуации, после успешного входа в систему учетные данные пользователя сохраняются в кэш на локальном компьютере. Это позволяет войти в систему с доменными учетными данными и получить доступ к ресурсам локального компьютера даже при отсутствии подключения к домену.
Примечание. Если быть точным, то кэшируются не сами учетные данные (логин и пароль), а результат их проверки. Еще точнее система хранит хэш пароля, модифицированный при помощи соли (salt), которая в свою очередь, генерируется на основе имени пользователя. Кэшированные данные хранятся в разделе реестра HKLM\SECURITY\Cache, доступ к которому имеет только система.
За возможность кэширования отвечает параметр реестра CashedLogonsCount, находящийся в разделе HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon. Этот параметр определяет количество уникальных пользователей, чьи учетные данные сохраняются локально. По умолчанию значение параметра равно 10, что означает следующее: учетные данные сохраняются для последних 10 пользователей, заходивших в систему, а при входе на компьютер одиннадцатого пользователя учетные данные первого пользователя будут перезаписаны.
Управлять значением CashedLogonsCount можно централизованно, с помощью групповых политик. Для этого необходимо создать новый GPO (или открыть существующий), перейти в раздел Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options и найти параметр Interactive logon: Number of previous logons to cache (in case domain controller is not available).
По умолчанию данный параметр не определен (Not Defined), соответственно на всех компьютерах используется дефолтное значение. Для его изменения надо включить параметр и указать необходимое значение в пределах от 0 до 50. Значение, равное 0, означает запрет на кэширование учетных данных, соответственно при этом значении вход в систему при недоступности контроллера домена невозможен.
Поскольку теоретически при наличии физического доступа к компьютеру у злоумышленника есть возможность воспользоваться сохраненными учетными данными, то для повышения безопасности рекомендуется отключать локальное кэширование. Исключение могут составить пользователи мобильных устройств (ноутбуков, планшетов и т.п.), которые пользуются устройствами как на работе, так и вне ее. Для таких пользователей количество кэшированных входов можно задать в пределах 1-2. Этого вполне достаточно для работы.
И в завершение пара важных моментов:
• Для того, чтобы учетные данные были закешированы необходимо, чтобы пользователь хотя-бы раз зашел на компьютер под своей доменной учетной записью при доступном контроллере домена. • Довольно часто параметр CashedLogonsCount трактуют как количество входов в систему при отсутствии доступа к домену. Это не так, и если учетные данные пользователя закешированы локально, то он сможет заходить в систему неограниченное количество раз.
Вы не можете войти в систему с этими учетными данными так как ваш домен недоступен
Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору результаты dcdiag и netdiag покажите
Всего записей: 7 | Зарегистр. 13-03-2007 | Отправлено:15:19 14-03-2007
HellBoy78RUS
Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору + антивирусом прогнать было бы не плохо
Всего записей: 6 | Зарегистр. 27-12-2006 | Отправлено:17:48 14-03-2007
Wizzard_ua
Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору С антивирусом все нормально (nod32 со свежими обновлениями) винда практически свежая. Самое удивительное, что до какого-то момента входил в домен нормально, и тут ни с того ни с сего перестало входить. Есть случаи что под определенным логином входить не хочет, а под админом например входит в домен. dcdiag и netdiag запускать на контроллере домена или на «пострадавшем» компьютере?
Вот что мне показал ipconfig /all на «пострадавшем» компе Настройка протокола IP для Windows
Testing server: Default-First-Site-Name\SWETLANA Starting test: Replications . SWETLANA passed test Replications Starting test: NCSecDesc . SWETLANA passed test NCSecDesc Starting test: NetLogons . SWETLANA passed test NetLogons Starting test: Advertising . SWETLANA passed test Advertising Starting test: KnowsOfRoleHolders . SWETLANA passed test KnowsOfRoleHolders Starting test: RidManager . SWETLANA passed test RidManager Starting test: MachineAccount . SWETLANA passed test MachineAccount Starting test: Services Dnscache Service is stopped on [SWETLANA] RPCLOCATOR Service is stopped on [SWETLANA] TrkWks Service is stopped on [SWETLANA] TrkSvr Service is stopped on [SWETLANA] . SWETLANA failed test Services Starting test: ObjectsReplicated . SWETLANA passed test ObjectsReplicated Starting test: frssysvol There are errors after the SYSVOL has been shared. The SYSVOL can prevent the AD from starting. . SWETLANA passed test frssysvol Starting test: kccevent . SWETLANA passed test kccevent Starting test: systemlog An Error Event occured. EventID: 0x000016AD Time Generated: 03/15/2007 12:02:26 Event String: The session setup from the computer An Error Event occured. EventID: 0x40000004 Time Generated: 03/15/2007 12:02:49 Event String: The kerberos client received a An Error Event occured. EventID: 0x40000004 Time Generated: 03/15/2007 12:40:23 Event String: The kerberos client received a An Error Event occured. EventID: 0x40000004 Time Generated: 03/15/2007 12:40:25 Event String: The kerberos client received a An Error Event occured. EventID: 0x40000004 Time Generated: 03/15/2007 12:44:25 Event String: The kerberos client received a An Error Event occured. EventID: 0x40000004 Time Generated: 03/15/2007 12:44:25 Event String: The kerberos client received a . SWETLANA failed test systemlog
Running enterprise tests on : company.donbass Starting test: Intersite . company.donbass passed test Intersite Starting test: FsmoCheck . company.donbass passed test FsmoCheck
Per interface results:
Adapter : Local Area Connection
List of NetBt transports currently bound to the browser NetBT_Tcpip_ <3EDB97EC-ADB0-4111-A814-7BEB99014848> The browser is bound to 1 NetBt transport.
Note: run «netsh ipsec dynamic show /?» for more detailed information
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору active directory=> computers=> удали тут комп с который в домен невходит, по идее должно помочь )
Всего записей: 27 | Зарегистр. 14-12-2006 | Отправлено:16:02 15-03-2007
vovanj7
Silver Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору есть домен-контроллер W2000 server. подключаю пользователей, все прекрасно работает, но при попытке пользователями открыть како-то документ word или exel, он в начале пытается что-то доустановить себе, потом ругается, что нет дистрибутива(хотя диск я ему даю тот с которого он инсталился), затем ругается на какие-то файлы и все документ не открывается. Если же я переутанавливаю поверх существующего офиса новый, когда машина уже в домене, то потом все работает прекрасно. В чем может быть проблема? и как все это решить без переустановки Оффиса у каждого(приблизительно 150 Пк).
Такие проблемы наблюдаются со всеми оффисами(2000,2003,ХР проф, ХР для малого бизнеса), только 97 работает нормально.
P.S. у пользователей Windows XP prof SP1,SP2, Windows 2000 prof и как правило стоит office ХР для малого бизнеса
Добавлено: другой диск я пробовал, шлейф тоже менял. СD-Rom рабочий 100%(подключал у себя)
Всего записей: 3378 | Зарегистр. 07-09-2006 | Отправлено:18:45 27-03-2007
viberua
Еще ругается по поводу Kerberos key : The kerberos client received a KRB_AP_ERR_MODIFIED error from the server %1. The target name used was %3. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (%2), and the client realm. Please contact your system administrator.
Структура сети следующая: Главный сервер с ГК запасной сервер в этом же помещении и еще один удаленный сервер который включен через WAN. Вся маршрутизация между удаленным и этими серваками работает через BSD gateway. В принципе все работает нормально связь и маршрутизация стабильная.
NSLOOKUP показывает все записи DNS имен правильно
repadmin /showreps выдает следующее сообщение Default-First-Site-Name\SWETLANA DC Options: IS_GC Site Options: (none) DC object GUID: d715976c-9ff1-4d9f-ae6e-5c01a03f2ca3 DC invocationID: d715976c-9ff1-4d9f-ae6e-5c01a03f2ca3
DC=domain,DC=com Default-First-Site-Name\DELTA via RPC DC object GUID: aa3ddd32-1879-4f22-886a-b7643c8ad429 Last attempt @ 2007-04-19 10:53:37 failed, result 8606 (0x219e): Can’t retrieve message string 8606 (0x219e), error 1815. 360 consecutive failure(s). Last success @ 2007-04-04 14:51:00.
CN=Configuration,DC=domain,DC=com Default-First-Site-Name\DELTA via RPC DC object GUID: aa3ddd32-1879-4f22-886a-b7643c8ad429 Last attempt @ 2007-04-19 10:53:37 was successful.
CN=Schema,CN=Configuration,DC=domain,DC=com Default-First-Site-Name\DELTA via RPC DC object GUID: aa3ddd32-1879-4f22-886a-b7643c8ad429 Last attempt @ 2007-04-19 10:53:37 was successful.
DC=DomainDnsZones,DC=domain,DC=com Default-First-Site-Name\DELTA via RPC DC object GUID: aa3ddd32-1879-4f22-886a-b7643c8ad429 Last attempt @ 2007-04-19 10:53:37 was successful.
DC=ForestDnsZones,DC=domain,DC=com Default-First-Site-Name\DELTA via RPC DC object GUID: aa3ddd32-1879-4f22-886a-b7643c8ad429 Last attempt @ 2007-04-19 10:53:37 was successful.
Naming Context: DC=domain,DC=com Source: Default-First-Site-Name\LANLORD ******* WARNING: KCC could not add this REPLICA LINK due to error.
Naming Context: CN=Schema,CN=Configuration,DC=domain,DC=com Source: Default-First-Site-Name\LANLORD ******* WARNING: KCC could not add this REPLICA LINK due to error.
Naming Context: CN=Configuration,DC=domain,DC=com Source: Default-First-Site-Name\LANLORD ******* WARNING: KCC could not add this REPLICA LINK due to error.