Ошибка аутентификации невозможно проверить подлинность с провайдером идентификации

Весной 2018 года пользователи Windows начали сталкиваться с ошибкой, которая ранее практически не встречалась.

Вскоре выяснилось, что сообщение «Еncryption oracle remediations» возникало при попытке осуществить соединение клиентского ПК с удалённой машиной, и происходило это при следующих обстоятельствах:

Рассмотрим причины возникновения ошибки и как можно исправить ситуацию.

Почему появляется ошибка CredSSP

Итак, мы уже знаем, что на многих версиях Виндовс (серверных вариантов 2016/2012/2008, за исключением 2013, а также клиентских, начиная с 7) без установленных кумулятивных патчей, если вы пытаетесь осуществить соединение с удалённым ПК по RDS/RDP, может возникнуть проблема Remote Desktop connection.

Другими словами, при удалённом подключении к компьютеру во время процедуры проверки подлинности шифрования произошла ошибка CredSSP, причиной которой может быть несовпадение протоколов шифрования. Это происходит потому, что на одной из машин (клиентской или удалённой) не установлены соответствующие обновления, вышедшие после марта 2018 года.

Именно тогда Microsoft начала распространять обновление, направленное на защиту выявленной уязвимости протокола CredSSP, грозящей вероятностью удалённого выполнения кода злоумышленниками. Технические детали проблемы достаточно подробно приведены в бюллетене CVE2018-0886. Спустя два месяца вышло ещё одно обновление, вводившее по умолчанию запрет на возможность клиентской машины Windows связываться с удалённым сервером, если на нём версия протокола CredSSP не была пропатчена мартовским обновлением.

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

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

• для серверной версии 2008 R2 и «семёрки» – KB4103718;
• для WS 2016 – KB4103723;
• для WS 2012 R2 и Windows 8.1 – KB4103725;
• для «десятки» сборки 1803 – KB4103721;
• для Windows 10 сборки 1609 – KB4103723;
• для «десятки» сборки 1703 – KB4103731;
• для W10 build 1709 — KB4103727.

В указанном перечне указаны номера обновлений, вышедших в мае 2018 года, в настоящее время необходимо устанавливать более свежие пакеты накопительных (их ещё называют кумулятивными) обновлений. Выполнить эту операцию можно несколькими способами. Например, обратившись к службе Windows Update, базирующейся на серверах разработчика, или с использованием локального сервера WSUS. Наконец, вручную скачать необходимые заплатки безопасности можно через Microsoft Update Catalog (это каталог обновлений Виндовс).

В частности, для поиска обновлений для своего компьютера, на котором установлена «десятка» сборки 1803, за май 2020 года поисковый запрос должен иметь следующий вид: windows 10 1803 5/*/2020.

Способы решения проблемы

Существует два пути выхода из сложившейся ситуации. Как нетрудно догадаться, один из них – удаление обновлений безопасности на клиентском компьютере, установленных после марта 2018 года. Разумеется, такой шаг считается весьма рискованным и настоятельно не рекомендуется, поскольку имеются другие варианты решения проблемы. Но он – самый простой в исполнении, и его можно использовать для однократной попытки доступа к удалённой машине.

А теперь рассмотрим альтернативные «правильные» варианты исправления ошибки, возникающей при проверке подлинности CredSSP.

Один из них – отключить (одноразово) процедуру проверку версии CredSSP на удалённом ПК во время попытки соединения по RDP. В этом случае вы остаётесь защищёнными, патчи остаются установленными, риск есть только во время сеанса связи.

Алгоритм действий:

Выключение политики EncryptionOracleRemediation позволит вашему компьютеру подключаться даже к непропатченным удалённым ПК и серверам без наличия свежих обновлений безопасности.

ВНИМАНИЕ. Напомним, что такой способ устранения в Windows ошибки несовпадения шифрования CredSSP не рекомендуется для постоянного применения. Лучше сообщите администратору удалённой машины о проблеме несоответствия протоколов шифрования для установки соответствующих обновлений.

Рассмотрим, как работает политика EOR. Она имеет три уровня защиты от уязвимостей протокола CredSSP при отсутствии патчей:

1. Force Updated Clients – базовый уровень защиты, полный запрет подключения со стороны удалённой машины на подключение клиентских ПК без установленных обновлений. Как правило, эту политику активируют после полного обновления в рамках всей инфраструктуры сети, то есть после установки свежих обновлений на все связанные сетью рабочие станции, включая серверы, к которым осуществляется удалённое подключение.
2. Mitigated – этот уровень защиты блокирует любые попытки подключения к серверам, на которых протокол CredSSP не пропатчен. При этом все остальные службы, работающие по CredSSP, не затрагиваются.
3. Vulnerable – зашита минимального уровня, снимающая запрет на удалённый доступ к RDP машине при наличии уязвимой версии CredSSP.

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

Для этого вводим в консоль «Выполнить» строку:

REG ADD HKMLSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2

Эту процедуру можно применить ко всем рабочим станциям, используя доменную GPO (консольный запуск – gpmc.msc), а можно применить скрипт PowerShell (чтобы получить перечень рабочих станций, принадлежащих данному домену, можно воспользоваться командлетом Get-ADComputer, входящим в состав RSAT-AD-PowerShell) следующего содержания:

Import-Module ActiveDirectory
$PSs = (Get-ADComputer -Filter *).DNSHostName
Foreach ($computer in $PCs) {
Invoke-Command -ComputerName $computer -ScriptBlock {
REG ADD HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2
}
}

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

Если вы хотите исправить ошибку шифрования CredSSP на Виндовс XP/Server 2003, которые в настоящее время уже не поддерживаются, но в силу определённых обстоятельств вами используются, необходимо все эти машины пропатчить Embedded POSReady 2009.

ВАЖНО. После успешной попытки связаться с сервером, установки на нём кумулятивных патчей и перезагрузки сервера обязательно выполните обратные преобразования в политике клиентской машины, выставив значение в политике ForceUpdatedClients в стоявшее там по умолчанию или заменив значение ключа AllowEncryptionsOracle с 2 на исходный 0. Таким образом, вы снова защитите свой компьютер от уязвимостей, присущих для непропатченного RDP соединения, произведя исправление шифрования CredSSP.

Мы не упомянули ещё об одном сценарии возникновения ошибочного сообщения «Еncryption oracle remediation» – когда с удалённым сервером всё в порядке, а непропатченным оказывается клиентский компьютер. Она будет возникать, если на удалённой машине активирована политика, блокирующая попытки установления связи с непропатченными клиентскими ПК.

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

gwmi win32_quickfixengineering |sort installed on -desk

Если дата достаточно старая (необязательно до марта 2018 года), установите самое свежее кумулятивное обновление для вашей версии Windows.

Обновлено 25.11.2019

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org, в прошлый раз мы с вами чинили HDD с поврежденной файловой системой и состоянием RAW уверен, что вам удалось это сделать. Сегодня я в очередной раз переведу наш вектор траблшутера в сторону терминальных столов, а именно мы рассмотрим ситуацию, что когда вы пытаетесь  подключиться к удаленному серверу по RDP протоколу, а у вас после ввода логина и пароля, выскакивает ошибка, что вы не прошли проверку подлинности и причиной ошибки может быть исправление шифрования CredSSP. Давайте разбираться, что за зверь, этот CredSSP и как вам получить доступ к вашему серверу.

Как выглядит ошибка credssp

Перед тем, как я покажу вам известные мне методы ее устранения, я бы как обычно хотел подробно описать ситуацию. Вчера при попытке подключиться к своему рабочему компьютеру, работающему на Windows 10 1709, с терминального стола, входящего в RDS ферму на Windows Server 2012 R2, я получил ошибку после ввода логина и пароля:

Ну и конечно в русском исполнении:

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

Получается двоякая ситуация, что RDP как бы работает, но вот по какой-то причине ваши учетные данные на принимающей стороне не соответствуют, каким-то критериям, давайте разбираться, что это за зверь CredSSP.

Назначение CredSSP

Что такое CredSSP — это Win32 API, используемый системами Microsoft Windows для выполнения различных операций, связанных с безопасностью, таких как аутентификация. SSPI функционирует, как общий интерфейс для нескольких поставщиков поддержки безопасности (SSP). Поставщик поддержки безопасности — это библиотека динамической компоновки (DLL), которая делает один или несколько пакетов безопасности доступными для приложений.

CredSSP позволяет приложению делегировать учетные данные пользователя от клиента целевому серверу для удаленной аутентификации. CredSSP предоставляет зашифрованный канал протокола безопасности транспортного уровня . Клиент проходит проверку подлинности по зашифрованному каналу с использованием протокола SPNEGO (Simple and Protected Negotiate) с Microsoft Kerberos или Microsoft NTLM.

После проверки подлинности клиента и сервера клиент передает учетные данные пользователя на сервер. Учетные данные дважды шифруются с использованием ключей сеанса SPNEGO и TLS. CredSSP поддерживает вход в систему на основе пароля, а также вход в систему с использованием смарт-карт на основе X.509 и PKINIT.

Подробнее на Microsoft https://docs.microsoft.com/en-us/windows/desktop/secauthn/credential-security-support-provider

Windows SSP

Следующие поставщики общих служб устанавливаются вместе с Windows:

• NTLM (Представлено в Windows NT 3.51 ) (msv1_0.dll) — обеспечивает проверку подлинности NTLM с запросом/ответом для клиент-серверных доменов до Windows 2000 и для не доменной аутентификации (SMB /CIFS).
• Kerberos (Представлен в Windows 2000 и обновлен в Windows Vista для поддержки AES ) (kerberos.dll). Предпочтителен для взаимной аутентификации клиент-серверного домена в Windows 2000 и более поздних версиях. 
• Согласование (введено в Windows 2000) (secur32.dll) — выбирает Kerberos и, если не доступно, протокол NTLM. SSP обеспечивает возможность единого входа , иногда называемую встроенной аутентификацией Windows (особенно в контексте IIS). В Windows 7 и более поздних версиях представлен NEGOExts, в котором согласовывается использование установленных пользовательских SSP, которые поддерживаются на клиенте и сервере для аутентификации.
• Безопасный канал (он же SChannel) — Представлен в Windows 2000 и обновлен в Windows Vista и выше для поддержки более надежного шифрования AES и ECC. Этот поставщик использует записи SSL/TLS для шифрования полезных данных. (Schannel.dll)
• PCT (устарел) реализация Microsoft TLS/SSL — криптография SSP с открытым ключом, которая обеспечивает шифрование и безопасную связь для аутентификации клиентов и серверов через Интернет. Обновлено в Windows 7 для поддержки TLS 1.2.
• Digest SSP (Представлено в Windows XP ) (wdigest.dll) — Обеспечивает проверку подлинности HTTP и SASL на основе запросов/ответов между системами Windows и не-Windows, где Kerberos недоступен.
• Учетные данные (CredSSP) (Представлено в Windows Vista и доступно в Windows XP с пакетом обновления 3 (SP3)) (credssp.dll) — обеспечивает SSO и проверку подлинности на уровне сети для служб удаленных рабочих столов.
• Аутентификация с распределенным паролем (DPA) — (Представлено в Windows 2000) (msapsspc.dll) — Обеспечивает аутентификацию через Интернет с использованием цифровых сертификатов.
• Криптография с открытым ключом «пользователь-пользователь» (PKU2U) (представлена ​​в Windows 7 ) (pku2u.dll) — обеспечивает одноранговую аутентификацию с использованием цифровых сертификатов между системами, которые не являются частью домена.

Подробнее на https://en.wikipedia.org/wiki/Security_Support_Provider_Interface

Причины ошибки шифрования CredSSP

В марте 2018 года, компания Microsoft выпустила обновление безопасности для устранения уязвимостей для протокола поставщика поддержки безопасности учетных данных (CredSSP) под именем CVE-2018–0886 (https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018), используемого подключениями по протоколу удаленного рабочего стола (RDP) для клиентов Windows и Windows Server. Как только пользователи и системные администраторы произвели установку апдейтов, то по всему миру начались массовые жалобы, что люди не могут подключаться по протоколу RDP к серверам, компьютерам, получая ошибку, что причиной ошибки может быть шифрование CredSSP.

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

Уязвимость в протоколе Credential Security Support Provider (CredSSP — провайдер поддержки безопасности учетных данных) допускала удаленный запуск произвольного кода на уязвимой системе и 8 мая 2018 г. Microsoft изменила уровень безопасности подключения с Vulnerable на Mitigated и начались проблемы подключения к удаленному рабочему столу по RDP. Ранее вы могли удаленно подключаться с обновленной машины к машинам без обновления безопасности, так сказать в мягком режиме. Однако с последним обновлением, Microsoft усилила безопасность, и вы больше не можете подключаться к компьютерам без обновления закрывающего брешь CVE-2018–0886.

Под раздачу попали буквально все, клиентские ОС Windows 7, Windows 8.1, Windows 10 с которых были попытки подключиться к RDS ферме или RemoteApp приложениям работающим на Windows Server 2008 R2 и выше. Если бы вы читали ветки обсуждений в эти дни, то вы бы поняли все негодование людей, особенно с запада.

Варианты исправления ошибки CredSSP

На самом деле вариантов много, есть правильные, есть и временные и обходные, которые нужно сделать быстро, чтобы хоть как-то работало, так как бизнес может в этот момент простаивать и терять деньги.

• Вы можете удалить новое обновление безопасности, самый плохой вариант, но в ответственные моменты, иногда используется, чтобы перенести работы на вечер или ночь
• Если нужно быстро получить доступ к серверу и избежать проверку подлинности credssp, то я вам советую отключить на принимающем подключении сервере галку NLA (Network Level Authentication) в русском варианте «Разрешить подключение только с компьютеров, на которых работает удаленный рабочий стол  с проверкой подлинности на уровне сети»
• То же быстрый метод и на массовое применение, это использование групповой политики, которая изменит шифрование Oracle Remediation
• Ну и самый правильный метод, это установка обновлений на все ваши системы

Отключаем credssp в Windows через NLA

Данный метод выхода из ситуации я бы рассматривал, как быстрое, временное решение, до того, как вы установите обновления безопасности. Чтобы разрешить удаленное подключение к серверу и избегать ситуации, что произошла ошибка при проверке подлинности credssp, сделайте вот что. Откройте свойства моего компьютера, попав в систему, так же можно нажать одновременно WIN+Pause Breake или как вариант в командной строке ввести control /name Microsoft.System. В окне «Система» находим пункт меню «Настройка удаленного доступа»

Снимите галку «Разрешить подключение только с компьютеров, на которых работает удаленный рабочий стол  с проверкой подлинности на уровне сети»

После этого вы легко сможете подключиться к данному компьютеру или серверу, но как быть что вы не можете туда попасть и снять эту галку, тут нам на помощь придет реестр Windows. Вы можете удаленно создать нужные ключи реестра, которые отключат галку NLA или политику CredSSP. Для этого вы можете пойти двумя путями:

1. Использовать сетевой реестр Windows
2. Использовать удаленное управление компьютером, например PsExec.exe, я вам с помощью него уже показывал, как открывать порты в брандмауэре, удаленно.

Давайте попробуем через удаленный реестр, для этого открываем Regedit, через окно «Выполнить».

Из меню «Файл» выберите пункт «Подключить сетевой реестр», далее найдите нужный вам сервер.

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

Тут вам необходимо создать REG_DWORD ключ с именем AllowEncryptionOracle и значением 2. В данном варианте политика CredSSP выставит Уязвимый уровень — это самый низкий уровень защиты. Это позволит вам подключаться к серверам удаленно, используя RDP. Однако это подвергнет серверы атакам.

Или можно так же отключить NLA, для этого найдите ветку реестра:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl Terminal ServerWinStationsRDP-Tcp

Найдите там ключ SecurityLayer и выставите ему значение 0, чтобы деактивировать Network Level Authentication.

Теперь то же самое вы можете выполнить и через PsExec.exe, выставив для CredSSP минимальный уровень защиты или же отключить NLA, для этого находясь в cmd в режиме администратора введите команду:

w10-cl01 — это имя компьютера.

Далее имея запущенный сеанс cmd для удаленного компьютера, выполните команду:

REG ADD HKLMSoftwareMicrosoftWindows CurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2 (0 вернет все как было)

Аналогично можно сделать и для отключения Network Level Authentication, команда будет такой:

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

Отключаем шифрование credssp через GPO

Если у вас большая инфраструктура, в которой сотни компьютеров и сотни серверов, то вы можете до установки нужных обновлений в вечернее время, временно отключить новый уровень шифрования CredSSP и убрать ошибку «Удаленный компьютер имя. Причиной ошибки может быть исправление шифрования CredSSP». Для этого мы можем воспользоваться всеми плюсами доменной инфраструктуры Active Directory. Тут два варианта, вы можете создать массовую политику для распространения ее на нужные OU или если у вас требование для одного или двух локальных компьютеров, то на них можно запустить локальный редактор групповых политик, тем самым внеся изменения только на них.

Напоминаю, что оснастку управление групповой политикой вы можете найти на контроллере домена или компьютере с установленным пакетом RSAT, открыть ее можно через команду в окне «Выполнить» gpmc.msc. Если нужно открыть локальный редактор групповых политик, то в окне «Выполнить» введите gpedit.msc.

Вам необходимо перейти в ветку:

Конфигурация компьютера — Административные шаблоны — Система — Передача учетных данных — Исправление уязвимости шифрующего оракула (Computer Configuration — Administrative Templates — System — Credentials Delegation — Encryption Oracle Remediation

Открываем настройку «Исправление уязвимости шифрующего оракула (Encryption Oracle Remediation)». Включаем политику, у вас активируется опция «Уровень защиты», на выбор будет три варианта:

• Принудительно применять обновленные клиенты (Force Updated Clients) — она будет стоять по умолчанию из-за максимального уровня защиты, вам данную опцию нужно сменить. Это так сказать максимально безопасный уровень взаимодействия клиент, он должен быть в идеале, после установки обновлений на все сервера и компьютеры.
• Оставить уязвимость (Vulnerable) – клиенты могут подключаться на уязвимые машины.
• Уменьшить риск (Mitigated) – клиенты не могут подключаться к уязвимым серверам, но серверы могут принимать уязвимые клиенты.

Выбираем на время пункт «Оставить уязвимость (Vulnerable)». Сохраняем настройки.

После чего вам нужно обновить политику, для этого откройте командную строку и введите gpupdate /force. Если у вас не доменный компьютер, да и еще Windows 10 Home, которая не имеет встроенного локального редактора политик, то вам как я описывал выше, нужно производить правку реестра

REG ADD HKLMSoftwareMicrosoftWindows CurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2 (0 вернет все как было)

На просторах интернета ходит скрипт PowerShell, который поможет включить данную политику на всех компьютерах в Active Directory

Import-Module ActiveDirectory
$PSs = (Get-ADComputer -Filter *).DNSHostName
Foreach ($computer in $PCs) {
Invoke-Command -ComputerName $computer -ScriptBlock {
REG ADD HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2
}
}

Самый правильный метод, это установка обновлений

Когда вам удалось везде подключиться и подошло время обслуживания ваших серверов, быстренько производим установку обновлений закрывающих брешь (CVE-2018-0886 | CredSSP Remote Code Execution Vulnerability).

https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2018-0886

Раньше были вот такие KB, но они со временем могут меняться свой номер, поэтому пройдите по ссылке выше, так будет надежнее.

• Windows Server 2012 R2 / Windows 8: KB4103715
• Windows Server 2008 R2 / Windows 7: KB4103712
• Windows Server 2016 / Windows 10 1607 — KB4103723
• Windows Server 2016 / Windows 10 1703 — KB4103731
• Windows Server 2016 / Windows 10 1709 — KB4103727
• Windows Server 2016 / Windows 10 1803 — KB4103721

На этом у меня все, надеюсь, что вы разобрались в работе CredSSP и научились ей управлять. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

Ошибка при подключении по RDP (Исправление шифрования CredSSP)

13 марта Microsoft опубликовал описание уязвимости CVE-2018-0886 в протоколе проверки подлинности CredSSP, который в частности используется при подключении по RDP к терминальным серверам. Позже Microsoft опубликовал, что будет блокировать подключения к необновлённым серверам, где присутствует данная уязвимость. В связи с чем многие заказчики столкнулись с проблемами подключения по RDP.

В частности, в Windows 7 можно увидеть ошибку: «Произошла ошибка проверки подлинности. Указанная функция не поддерживается»

В Windows 10 ошибка расписана более подробно, в частности сказано «Причиной ошибки может быть исправление шифрования CredSSP»:

Для обхода ошибки со стороны клиента многие советуют отключить групповую политику, путём установки значения Encryption Oracle Remediation в Vulnerable:
с помощью gpedit.msc в Конфигурация компьютера / Административные шаблоны / Система / Передача учётных данных, слева выбрать «Исправление уязвимости шифрующего оракула» (забавный конечно перевод), в настройках поставить «Включено» и выбрать «Оставить уязвимость».

или через реестр (т.к., например, в Windows Home нет команды gpedit.msc):

REG ADD HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2

НО! Так делать не нужно! Т.к. таким образом вы оставляете уязвимость и риски перехвата вашего трафика и пр. конфиденциальные данные, включая пароли. Единственный случай, когда это может быть необходимо, это когда у вас вообще нет другой возможности подключиться к удалённому серверу, кроме как по RDP, чтобы установить обновления (хотя у любого облачного провайдера должна быть возможность подключения к консоли сервера). Сразу после установки обновлений, политики нужно вернуть в исходное состояние.

Если доступ к удалённому серверу есть, то ещё, как временная мера, можно отключить требование NLA (Network Level Authentication), и сервер перестанет использовать CredSSP. Для этого достаточно в Свойствах системы, на вкладке удалённые подключения снять соответствующую галку «Разрешить подключения только с компьютеров, на которых работает удалённый рабочий стол с проверкой подлинности на уровне сети»:

Но, это тоже неправильный подход.

Правильный подход — это всего-лишь установить нужные обновления на операционную систему, закрывающие уязвимость CVE-2018-0886 в CredSSP, причём, как серверную, куда вы подключаетесь, так и клиентскую, с которой вы подключаетесь.

Источник

Произошла ошибка проверки подлинности RDP

Некоторые пользователи, которые подключаются через удаленный доступ RDP в Windows 10/7, получают ошибку «Произошла ошибка проверки подлинности. Указанная функция не поддерживается» может быть комментарий, что «Причиной ошибки может быть исправление шифрования CredSPP«. Большинство пользователей столкнулись с этой ошибкой после обновления системы Windows 10/7. Дело в том, что Microsoft выпустила микро-патч для удаления уязвимости в RDP. По этому CredSPP должен быть обновлен на обоих ПК и всех устройствах, к которым вы пытаетесь подключиться удаленно. Другие сообщили, что в групповых политик сбросились значения. И лично я столкнулся с этой проблемой, и решил её редактированием реестра. Разберем основные решения, чтобы исправить ошибку проверки подлинности при подключении удаленного доступа RDP.

1. Снять ограничения

В большинстве случаев нужно всего-лишь снять галочку на проверку подлинности. Нажмите сочетание кнопок на клавиатуре Win+R и введите sysdm.cpl, чтобы открыть свойства системы. Перейдите во вкладку «Удаленный доступ«, ниже установите «Разрешить удаленные подключения к этому компьютеру» и снимите галочку «Разрешить подключения только с компьютеров, на которых работает проверка подлинности«.

2. Обновление Windows 10/7 и обновление CredSPP

Во первых, обновите все свои устройства в «Центре обновления Windows«, которые подключаются через удаленный доступ. Во вторых, проверьте специальные патчи обновления, которые устраняли уязвимость в RDP, их можно посмотреть на официальном сайте Microsoft CVE-2018-0886, и обновите свои Windows 10/7, Server, RT, LTSB для всех ПК. Тем самым вы обновите CredSPP.

3. Групповые политики

Нажмите Win + R и введите gpedit.msc, чтобы открыть редактор групповых политик. В политиках перейдите «Конфигурация компьютера» > «Административные шаблоны» > «Система» > «Передача учетных данных» > справа найдите «Защита от атак с использованием криптографического оракула» (Oracle Remediation) и нажмите по этой политике два раза мышкой, чтобы открыть свойства.

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

• Запустите теперь командную строку от имени администратора и введите gpupdate /force , чтобы обновить политики и применения вступили в силу. Проверьте устранена ли ошибка проверки подлинности RDP, если нет, то перезагрузите ПК.

4. Редактор реестра

Нажмите Win + R и введите regedit, чтобы открыть редактор реестра. В реестре перейдите по пути:

• HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters
• Справа дважды щелкните по AllowEncryptionOracle и поставьте значение 2.
• Перезагрузите ПК и надеюсь, что проблема с проверки подлинности RDP при подключении удаленного доступа решена.

Если вы не делали способ 2, то у вас не будет папки CredSSPParameters . Проделайте способ 2 или создайте вручную папку CredSSP с подпапкой Parameters и ключом AllowEncryptionOracle со значением 2.

Источник

Непредвиденная ошибка при проверке подлинности провайдером идентификации что это

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org, в прошлый раз мы с вами чинили HDD с поврежденной файловой системой и состоянием RAW уверен, что вам удалось это сделать. Сегодня я в очередной раз переведу наш вектор траблшутера в сторону терминальных столов, а именно мы рассмотрим ситуацию, что когда вы пытаетесь подключиться к удаленному серверу по RDP протоколу, а у вас после ввода логина и пароля, выскакивает ошибка, что вы не прошли проверку подлинности и причиной ошибки может быть исправление шифрования CredSSP. Давайте разбираться, что за зверь, этот CredSSP и как вам получить доступ к вашему серверу.

Как выглядит ошибка credssp

Перед тем, как я покажу вам известные мне методы ее устранения, я бы как обычно хотел подробно описать ситуацию. Вчера при попытке подключиться к своему рабочему компьютеру, работающему на Windows 10 1709, с терминального стола, входящего в RDS ферму на Windows Server 2012 R2, я получил ошибку после ввода логина и пароля:

Ну и конечно в русском исполнении:

Получается двоякая ситуация, что RDP как бы работает, но вот по какой-то причине ваши учетные данные на принимающей стороне не соответствуют, каким-то критериям, давайте разбираться, что это за зверь CredSSP.

Назначение CredSSP

Что такое CredSSP — это Win32 API, используемый системами Microsoft Windows для выполнения различных операций, связанных с безопасностью, таких как аутентификация. SSPI функционирует, как общий интерфейс для нескольких поставщиков поддержки безопасности (SSP). Поставщик поддержки безопасности — это библиотека динамической компоновки (DLL), которая делает один или несколько пакетов безопасности доступными для приложений.

C redSSP позволяет приложению делегировать учетные данные пользователя от клиента целевому серверу для удаленной аутентификации. CredSSP предоставляет зашифрованный канал протокола безопасности транспортного уровня . Клиент проходит проверку подлинности по зашифрованному каналу с использованием протокола SPNEGO (Simple and Protected Negotiate) с Microsoft Kerberos или Microsoft NTLM.

После проверки подлинности клиента и сервера клиент передает учетные данные пользователя на сервер. Учетные данные дважды шифруются с использованием ключей сеанса SPNEGO и TLS. CredSSP поддерживает вход в систему на основе пароля, а также вход в систему с использованием смарт-карт на основе X.509 и PKINIT.

Windows SSP

Следующие поставщики общих служб устанавливаются вместе с Windows:

• NTLM (Представлено в Windows NT 3.51 ) (msv1_0.dll) — обеспечивает проверку подлинности NTLM с запросом/ответом для клиент-серверных доменов до Windows 2000 и для не доменной аутентификации (SMB /CIFS).
• Kerberos (Представлен в Windows 2000 и обновлен в Windows Vista для поддержки AES ) (kerberos.dll). Предпочтителен для взаимной аутентификации клиент-серверного домена в Windows 2000 и более поздних версиях.
• Согласование (введено в Windows 2000) (secur32.dll) — выбирает Kerberos и, если не доступно, протокол NTLM. SSP обеспечивает возможность единого входа , иногда называемую встроенной аутентификацией Windows (особенно в контексте IIS). В Windows 7 и более поздних версиях представлен NEGOExts, в котором согласовывается использование установленных пользовательских SSP, которые поддерживаются на клиенте и сервере для аутентификации.
• Безопасный канал (он же SChannel) — Представлен в Windows 2000 и обновлен в Windows Vista и выше для поддержки более надежного шифрования AES и ECC. Этот поставщик использует записи SSL/TLS для шифрования полезных данных. (Schannel.dll)
• PCT (устарел) реализация Microsoft TLS/SSL — криптография SSP с открытым ключом, которая обеспечивает шифрование и безопасную связь для аутентификации клиентов и серверов через Интернет. Обновлено в Windows 7 для поддержки TLS 1.2.
• Digest SSP (Представлено в Windows XP ) (wdigest.dll) — Обеспечивает проверку подлинности HTTP и SASL на основе запросов/ответов между системами Windows и не-Windows, где Kerberos недоступен.
• Учетные данные (CredSSP) (Представлено в Windows Vista и доступно в Windows XP с пакетом обновления 3 (SP3)) (credssp.dll) — обеспечивает SSO и проверку подлинности на уровне сети для служб удаленных рабочих столов.
• Аутентификация с распределенным паролем (DPA) — (Представлено в Windows 2000) (msapsspc.dll) — Обеспечивает аутентификацию через Интернет с использованием цифровых сертификатов.
• Криптография с открытым ключом «пользователь-пользователь» (PKU2U) (представлена ​​в Windows 7 ) (pku2u.dll) — обеспечивает одноранговую аутентификацию с использованием цифровых сертификатов между системами, которые не являются частью домена.

Причины ошибки шифрования CredSSP

В марте 2018 года, компания Microsoft выпустила обновление безопасности для устранения уязвимостей для протокола поставщика поддержки безопасности учетных данных (CredSSP) под именем CVE-2018–0886 (https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018), используемого подключениями по протоколу удаленного рабочего стола (RDP) для клиентов Windows и Windows Server. Как только пользователи и системные администраторы произвели установку апдейтов, то по всему миру начались массовые жалобы, что люди не могут подключаться по протоколу RDP к серверам, компьютерам, получая ошибку, что причиной ошибки может быть шифрование CredSSP.

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

Под раздачу попали буквально все, клиентские ОС Windows 7, Windows 8.1, Windows 10 с которых были попытки подключиться к RDS ферме или RemoteApp приложениям работающим на Windows Server 2008 R2 и выше. Если бы вы читали ветки обсуждений в эти дни, то вы бы поняли все негодование людей, особенно с запада.

Варианты исправления ошибки CredSSP

На самом деле вариантов много, есть правильные, есть и временные и обходные, которые нужно сделать быстро, чтобы хоть как-то работало, так как бизнес может в этот момент простаивать и терять деньги.

• Вы можете удалить новое обновление безопасности, самый плохой вариант, но в ответственные моменты, иногда используется, чтобы перенести работы на вечер или ночь
• Если нужно быстро получить доступ к серверу и избежать проверку подлинности credssp, то я вам советую отключить на принимающем подключении сервере галку NLA (Network Level Authentication) в русском варианте «Разрешить подключение только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети»
• То же быстрый метод и на массовое применение, это использование групповой политики, которая изменит шифрование Oracle Remediation
• Ну и самый правильный метод , это установка обновлений на все ваши системы

Отключаем credssp в Windows через NLA

Данный метод выхода из ситуации я бы рассматривал, как быстрое, временное решение, до того, как вы установите обновления безопасности. Чтобы разрешить удаленное подключение к серверу и избегать ситуации, что произошла ошибка при проверке подлинности credssp, сделайте вот что. Откройте свойства моего компьютера, попав в систему, так же можно нажать одновременно WIN+Pause Breake или как вариант в командной строке ввести control /name Microsoft.System. В окне «Система» находим пункт меню «Настройка удаленного доступа»

Снимите галку «Разрешить подключение только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети»

После этого вы легко сможете подключиться к данному компьютеру или серверу, но как быть что вы не можете туда попасть и снять эту галку, тут нам на помощь придет реестр Windows. Вы можете удаленно создать нужные ключи реестра, которые отключат галку NLA или политику CredSSP. Для этого вы можете пойти двумя путями:

1. Использовать сетевой реестр Windows
2. Использовать удаленное управление компьютером, например PsExec.exe, я вам с помощью него уже показывал, как открывать порты в брандмауэре, удаленно.

Давайте попробуем через удаленный реестр, для этого открываем Regedit, через окно «Выполнить».

Из меню «Файл» выберите пункт «Подключить сетевой реестр», далее найдите нужный вам сервер.

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

Тут вам необходимо создать REG_DWORD ключ с именем AllowEncryptionOracle и значением 2. В данном варианте политика CredSSP выставит Уязвимый уровень — это самый низкий уровень защиты. Это позволит вам подключаться к серверам удаленно, используя RDP. Однако это подвергнет серверы атакам.

Или можно так же отключить NLA, для этого найдите ветку реестра:

Найдите там ключ SecurityLayer и выставите ему значение , чтобы деактивировать Network Level Authentication.

Теперь то же самое вы можете выполнить и через PsExec.exe, выставив для CredSSP минимальный уровень защиты или же отключить NLA, для этого находясь в cmd в режиме администратора введите команду:

w10-cl01 — это имя компьютера.

Далее имея запущенный сеанс cmd для удаленного компьютера, выполните команду:

Аналогично можно сделать и для отключения Network Level Authentication, команда будет такой:

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

Отключаем шифрование credssp через GPO

Если у вас большая инфраструктура, в которой сотни компьютеров и сотни серверов, то вы можете до установки нужных обновлений в вечернее время, временно отключить новый уровень шифрования CredSSP и убрать ошибку «Удаленный компьютер имя. Причиной ошибки может быть исправление шифрования CredSSP». Для этого мы можем воспользоваться всеми плюсами доменной инфраструктуры Active Directory. Тут два варианта, вы можете создать массовую политику для распространения ее на нужные OU или если у вас требование для одного или двух локальных компьютеров, то на них можно запустить локальный редактор групповых политик, тем самым внеся изменения только на них.

Напоминаю, что оснастку управление групповой политикой вы можете найти на контроллере домена или компьютере с установленным пакетом RSAT, открыть ее можно через команду в окне «Выполнить» gpmc.msc. Если нужно открыть локальный редактор групповых политик, то в окне «Выполнить» введите gpedit.msc.

Вам необходимо перейти в ветку:

Открываем настройку «Исправление уязвимости шифрующего оракула (Encryption Oracle Remediation)». Включаем политику, у вас активируется опция «Уровень защиты», на выбор будет три варианта:

• Принудительно применять обновленные клиенты (Force Updated Clients) — она будет стоять по умолчанию из-за максимального уровня защиты, вам данную опцию нужно сменить. Это так сказать максимально безопасный уровень взаимодействия клиент, он должен быть в идеале, после установки обновлений на все сервера и компьютеры.
• Оставить уязвимость (Vulnerable) – клиенты могут подключаться на уязвимые машины.
• Уменьшить риск (Mitigated) – клиенты не могут подключаться к уязвимым серверам, но серверы могут принимать уязвимые клиенты.

Выбираем на время пункт «Оставить уязвимость (Vulnerable)». Сохраняем настройки.

После чего вам нужно обновить политику, для этого откройте командную строку и введите gpupdate /force. Если у вас не доменный компьютер, да и еще Windows 10 Home, которая не имеет встроенного локального редактора политик, то вам как я описывал выше, нужно производить правку реестра

На просторах интернета ходит скрипт PowerShell, который поможет включить данную политику на всех компьютерах в Active Directory

Import-Module ActiveDirectory
$PSs = (Get-ADComputer -Filter *).DNSHostName
Foreach ($computer in $PCs) <
Invoke-Command -ComputerName $computer -ScriptBlock <
REG ADD HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2
>
>

Самый правильный метод, это установка обновлений

Когда вам удалось везде подключиться и подошло время обслуживания ваших серверов, быстренько производим установку обновлений закрывающих брешь (CVE-2018-0886 | CredSSP Remote Code Execution Vulnerability).

Раньше были вот такие KB, но они со временем могут меняться свой номер, поэтому пройдите по ссылке выше, так будет надежнее.

• Windows Server 2012 R2 / Windows 8: KB4103715
• Windows Server 2008 R2 / Windows 7: KB4103712
• Windows Server 2016 / Windows 10 1607 — KB4103723
• Windows Server 2016 / Windows 10 1703 — KB4103731
• Windows Server 2016 / Windows 10 1709 — KB4103727
• Windows Server 2016 / Windows 10 1803 — KB4103721

Источник

Ошибка: сбой проверки подлинности Kerberos

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

Эта ошибка возникает, когда монитор удаленной отладки Visual Studio выполняется от имени учетной записи локальной системы (LocalSystem) или учетной записи сетевой службы (NetworkService). Работая под одной из этих учетных записей, удаленный отладчик должен установить соединение с аутентификацией на основе Kerberos, чтобы иметь возможность возвращать данные главному компьютеру отладчика Visual Studio.

Проверка подлинности Kerberos невозможна при следующих условиях:

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

Служба Kerberos на контроллере домена была отключена.

Если аутентификация на основе Kerberos недоступна, следует сменить учетную запись, от имени которой выполняется монитор удаленной отладки Visual Studio. Инструкции см. в статье Ошибка: службе удаленного отладчика Visual Studio не удается подключиться к этому компьютеру.

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

Для проверки того, что DNS на целевом компьютере правильно распознает имя главного компьютера:

На целевом компьютере войдите в меню Пуск и выберите в меню Стандартные пункт Командная строка.

В окне командной строки введите:

В первой строке ответа ping будет выведено полное имя компьютера и IP-адрес, возвращаемый службой DNS для указанного компьютера.

Источник

Проблемы с проверкой подлинности Kerberos, когда пользователь принадлежит к многим группам

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

Применяется к: Windows 10 — все выпуски, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 327825

Симптомы

Дополнительные сведения о контексте ошибки см. в ссылке HTTP 400 Bad Request (Запросзагона слишком долго) ответов на запросы HTTP.

В аналогичных условиях Windows проверки подлинности NTLM работает, как и ожидалось. Проблема проверки подлинности Kerberos может возникнуть только при анализе Windows поведения. Однако в таких сценариях Windows не удастся обновить параметры групповой политики.

Такое поведение происходит в любой из поддерживаемых в настоящее время Windows версиях. Сведения о поддерживаемых версиях Windows см. в Windows.

Причина

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

В рамках службы проверки подлинности ExchangeWindows создает маркер для представления пользователя для целей авторизации. Этот маркер (также называемый контекстом авторизации) включает идентификаторы безопасности (SID) пользователя и siD-коды всех групп, к которой принадлежит пользователь. Он также включает все SID-данные, хранимые в атрибуте учетной sIDHistory записи пользователя. Kerberos хранит этот маркер в структуре данных сертификата атрибута привилегий (PAC) в билете Kerberos Ticket-Getting (TGT). Начиная с Windows Server 2012, Kerberos также сохраняет маркер в структуре данных Active Directory Claims (Dynamic Access Control) в билете Kerberos. Если пользователь является членом большого количества групп, и если существует много утверждений для пользователя или используемого устройства, эти поля могут занимать много пробелов в билете.

Маркер имеет фиксированный максимальный размер MaxTokenSize (). Транспортные протоколы, такие как удаленный вызов процедуры (RPC) и HTTP, зависят от значения при выделении буферов MaxTokenSize для операций проверки подлинности. MaxTokenSize имеет следующее значение по умолчанию в зависимости от версии Windows, которая создает маркер:

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

Другие факторы также влияют на максимальное число групп. Например, УАИ для глобальных и локальных доменных групп имеют меньшие требования к пространству. Windows Server 2012 и более поздние версии добавляют сведения о претензиях в билет Kerberos, а также сжимаются SID-данные ресурсов. Обе функции изменяют требования к пространству.

Решение

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

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

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

Дополнительные сведения об определении нового значения см. в разделе Вычисление максимального размера маркера MaxTokenSize в этой статье.

Например, рассмотрим пользователя, используюшего веб-приложение, которое опирается на SQL Server клиента. В рамках процесса проверки подлинности клиент SQL Server передает маркер пользователя в SQL Server базу данных. В этом случае необходимо настроить запись реестра на каждом MaxTokenSize из следующих компьютеров:

В Windows Server 2012 (и более поздних версиях) Windows можно войти в журнал события (Event ID 31), если размер маркера преодолеет определенный порог. Чтобы включить такое поведение, необходимо настроить параметр групповой политики Конфигурация компьютераАдминистративные шаблоныSystemKDCWarning для больших билетов Kerberos.

Вычисление максимального размера маркера

TokenSize = 1200 + 40d + 8s

Для Windows Server 2012 (и более поздних версий) эта формула определяет свои компоненты следующим образом:

Windows Сервер 2008 R2 и более ранние версии используют ту же формулу. Тем не менее, в этих версиях число членов группы домена и локальной группы является частью значения d, а не значения s.

Если у вас есть значение 0x0000FFFF (64K), вы можете быть в состоянии буферить примерно MaxTokenSize 1600 D-класса SID или примерно 8000 S-class SIDs. Однако на значение, которое можно безопасно использовать, влияет ряд других факторов, в том числе MaxTokenSize следующие:

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

Если у вас несколько трастов, настройте эти траста для фильтрации siD-систем. Эта конфигурация снижает влияние размера билета Kerberos.

Если вы используете Windows Server 2012 или более поздний вариант, на требования к пространству SID также влияют следующие факторы:

В 2019 г. Корпорация Майкрософт отправила обновления в Windows, которые изменили конфигурацию неподготовленного делегирования для Kerberos на отключенную. Дополнительные сведения см. в статью Updates to TGT delegation across incoming trusts in Windows Server.

Так как сжатие SID ресурсов широко используется и неконтентированное делегированное число неограниченно, 48000 или больше должны стать достаточными для MaxTokenSize всех сценариев.

Известные проблемы, влияющие на MaxTokenSize

Для большинства реализаций должно быть достаточно значения в MaxTokenSize 48 000 bytes. Это значение по умолчанию в Windows Server 2012 и более поздних версиях. Однако, если вы решите использовать большее значение, просмотрите известные проблемы в этом разделе.

Ограничение размера в 1010 групповых SID для маркера доступа к LSA

Эта проблема аналогична тому, что пользователь, у которого слишком много членов группы, не может проверить подлинность, но расчеты и условия, которые регулируют проблему, отличаются. Например, пользователь может столкнуться с этой проблемой при использовании проверки подлинности Kerberos или Windows проверки подлинности NTLM. Дополнительные сведения см. в статью Ведение журнала учетной записи пользователя, в которую входит более 1010групп, на компьютере на Windows сервере.

Известная проблема при использовании значений MaxTokenSize более 48 000

Для смягчения вектора атаки на службу internet Information Server (IIS) использует ограниченный размер буфера http-запроса в 64 КБ. Билет Kerberos, который является частью http-запроса, закодирован как Base64 (6 битов, расширенный до 8 битов). Таким образом, билет Kerberos использует 133 процента от первоначального размера. Поэтому, если максимальный размер буфера в IIS составляет 64 КБ, билет Kerberos может использовать 48 000 битов.

Если задать запись реестра значению, которое превышает 48000 bytes, и буферное пространство используется для siDs, может возникнуть ошибка MaxTokenSize IIS. Однако если вы установите запись реестра до 48 000 бит и используете пространство для SID-файлов и утверждений, возникает ошибка MaxTokenSize Kerberos.

Известные проблемы при использовании значений MaxTokenSize больше 65 535

Мы также определили, что протокол IKE IPSEC не позволяет BLOB-адресу безопасности быть больше 66 536 битов, и он также не будет иметь значения, когда задавалось большее MaxTokenSize значение.

Источник

Ошибка «Неподтверченный etype» при доступе к ресурсу в надежном домене

Применяется к: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 4492348

Симптомы

Компьютер в детском домене леса Службы домена Active Directory (AD DS) не может получить доступ к службе, которая находится в другом домене в одном лесу. При запуске сетевого следа на сообщениях на клиентском компьютере и с клиентского компьютера этот след содержит следующие сообщения Kerberos:

На контроллере домена детского домена viewer событий записи следующую запись события 14:

Причина

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

Типы шифрования Kerberos

Шифрование RC4 считается менее безопасным, чем более новые типы шифрования, AES128-CTS-HMAC-SHA1-96 и AES256-CTS-HMAC-SHA1-96. Руководства по безопасности, такие как руководство по технической реализации Windows 10 безопасности, предоставляют инструкции по повышению безопасности компьютера, настроив его на использование только шифрования AES128 и/или AES256 (см. типы шифрования Kerberos, чтобы предотвратить использование наборов шифрования DES и RC4).

Такой клиент может продолжать подключаться к службам в собственном домене, которые используют шифрование AES128 или AES256. Однако другие факторы могут помешать клиенту подключиться к аналогичным службам в другом доверяемом домене, даже если эти службы также используют шифрование AES128 или AES256.

На очень высоком уровне контроллер домена (DC) отвечает за управление запросами доступа в собственном домене. В рамках процесса проверки подлинности Kerberos dc проверяет, что клиент и служба могут использовать один и тот же тип шифрования Kerberos. Однако, когда клиент запрашивает доступ к службе в другом доверяемом домене, dc клиента должен «передать» клиенту dc в домен службы. Когда dc создает билет на передачу, вместо сравнения типов шифрования клиента и службы, он сравнивает типы шифрования клиента и доверия.

Проблема возникает из-за конфигурации самого доверия. В Active Directory объект домена имеет связанные доверенные объекты домена (TDOs), которые представляют каждый домен, которому он доверяет. Атрибуты TDO описывают отношения доверия, включая типы шифрования Kerberos, поддерживаемые доверием. Связь по умолчанию между детским доменом и родительским доменом — это двунаружное транзитное доверие, которое поддерживает тип шифрования RC4. Оба родительского и детского домена имеют TDOs, которые описывают эту связь, в том числе тип шифрования.

Проверка подлинности NTLM

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

Решение

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

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

Метод 1. Настройка доверия для поддержки шифрования AES128 и AES 256 в дополнение к шифрованию RC4

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

Чтобы настроить тип доверия шифрования Kerberos, откройте окно командной подсказки на домене DC в доверенного домена и введите следующую команду:

В этой команде представлено полностью квалифицированное доменное имя (FQDN) доверяемого домена.

В примере, в котором находится корневой домен (где находится служба) и это детский домен (где находится клиент), откройте окно командной подсказки на dc и введите следующую contoso.com child.contoso.com contoso.com команду:

После завершения этой команды dc может успешно создать переходный билет, который клиент может использовать для child.contoso.com достижения contoso.com dc.

Так как связь между двумя доменами является двунастройным транзитным доверием, настройте другую сторону доверия, открыв окно Командная подсказка на dc и введите child.contoso.com следующую команду:

Дополнительные сведения о средстве ksetup см. в ksetup.

Метод 2. Настройка клиента для поддержки шифрования RC4 в дополнение к шифрованию AES128 и AES256

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

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

Метод 3. Настройка доверия для поддержки шифрования AES128 и AES 256 вместо шифрования RC4

Этот метод напоминает метод 1 в том, что вы настраивает атрибуты доверия.

В случае Windows лесных трастов обе стороны доверия поддерживают AES. Поэтому все запросы на билеты в трастах используют AES. Однако сторонний клиент Kerberos, который проверяет билет на реферал, может уведомить вас о том, что в билете используется тип шифрования, который клиент не поддерживает. Чтобы позволить такому клиенту и далее проверять билет, обнови его в поддержку AES.

При использовании этого метода настройте доверие с помощью оснастки Active Directory Domains and Trusts MMC. Чтобы использовать этот метод, выполните следующие действия:

В доменах Active Directory и Trusts перейдите к надежному объекту домена (в contoso.com примере). Щелкните правой кнопкой мыши объект, выберите свойства и выберите трасты.

В поле Домены, которые доверяют этому домену (входящие трасты), выберите доверчивый домен (в child.domain.com примере).

Выберите свойства, выберите другой домен поддерживает шифрование Kerberos AES, а затем выберите ОК.

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

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

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

На вкладке Trusts нажмите кнопку ОК.

Перейдите к объекту домена для доверяемой области ( child.contoso.com ).

Дополнительная информация

Дополнительные сведения о TDOs см. в следующих статьях:

Дополнительные сведения о типах шифрования Kerberos см. в следующих статьях:

Источник

Ошибка проверки подлинности kerberos windows server 2019

Добрый день уважаемые читатели, не так давно у меня на работе была задача по настройке групп доступности SQL на Windows кластере, там клиентам сделали красивый веб-инструментарий, все замечательно, теперь клиент ждет следующего развития ситуации, а именно настройка и внедрение механизма Single Sign-On (SSO) или по русски единая точка аутентификация, мы с вами уже с ней знакомились при настройке Vmware vCenter Server. Данный механизм работает на протоколе шифрования kerberos, о котором мы и поговорим. Мы рассмотрим как происходит проверка подлинности kerberos в Active Directory, так как понимание принципов работы, поможет вам в реализации единой точки аутентификации.

Идентификация и доступ в Active Directory

Доменные службы Active Directory (Active Directory Domain Services, AD DS ) обеспечивают идентификацию и доступ (Identity and Access, IDA ) для корпоративных сетей. Давайте посмотрим каким требованиям и критериям должна соответствовать структура IDA:

Протокол аутентификации kerberos

Именно за счет провайдеров Security Support Provider (SSP) сделан механизм аутентификации. Операционная система Windows уже имеет встроенные модули, но никто не мешает программистам, взять и написать свой и подключить его к SSPI

Протокол аутентификации kerberos пришел на смену устаревшему и уже с точки зрения не безопасному, протоколу NTLM, он был основным до Windows 2000. Протокол Kerberos всегда используется в построении механизмов Single Sign-On. В его основе лежит такой принцип, что если двум участникам известен некий ключ и у них есть возможность подтвердить это, то они смогут однозначно идентифицировать друг друга.

Междоменный ключ (inter-realm key). Этот ключ обеспечивает междоменную аутентификацию и используется для обеспечения доверительных отношений в среде Aсtive Directory.

Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos — Key Distribution Center (KDC, центр распределения ключей). TGT шифруется при помощи ключа, общего для служб KDC, то есть клиент не может прочитать информацию из своего билета. Этот билет используется клиентом для получения других билетов.

Сам Ticket-Granting Service состоит из двух вещей, первая это копия сессионного ключа и информация о клиенте. Все эти данные зашифрованы ключом, общим между сервисом к которому идет обращение и KDC. Это означает, что пользователь не сможет посмотреть эти данные, а вот служба или сервер к которому идет обращение да.

Еще очень важным моментом, является тот фактор, что служба KDC, должна точно знать к какому именно сервису идет обращение и каким ключом шифрования производить обработку. Для этого есть такой механизм, как Service Principal Names, по сути это уникальный идентификатор службы, который будет прописан в вашей базе Active Directory. Из требований к нему, он должен быть уникален в рамках леса. Каждая служба, которая будет использовать Kerberos, должна иметь зарегистрированный SPN. Без правильно настроенного идентификатора протокол для этой службы или сервера работать не будет.

Сам SPN будет хранится в атрибуте Service-Principal-Name, у той учетной записи к которой он привязан и под которым стартует служба. Таким образом, SPN связывает воедино все части процесса. Клиент знает, к какой службе он хочет получить доступ. И при запросе ключа он строит строку SPN, к примеру, при помощи функции DsMakeSpn. Сервер KDC, получив эти данные, может найти учетную запись, под которой стартует эта служба, и, используя ключ этой учетной записи из Active Directory, создать билет доступа к службе и зашифровать его этим ключом.

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

Детальная проверка kerberos от начала логирования

Давайте еще в картинках я расскажу более детально как происходит проверка подлинности kerberos, от момента ввода пароля пользователем. И так:

Источник

Ошибка проверки подлинности kerberos windows server 2019

Этот форум закрыт. Спасибо за участие!

Спрашивающий

Общие обсуждения

Имеется хост-система Windows 10 и установленная на VMware Windows Server 2008 r2 Core. Серверной версии присвоен ip-адрес. С помощью Диспетчера серверов Windows 10 пытаюсь подключиться по ip для удаленного управления, но выдается «Ошибка проверки подлинности Kerberos». Какие действия предпринять?

Все ответы

Сразу оговорюсь, что в делах администрирования я совсем новичок.

Расхождения во времени нет, везде стоит правильное. winrm включен на Windows Server. Какие логи нужно посмотреть? Спасибо.

В RSAT ведь и входит Диспетчер серверов, насколько я понимаю? Проблема была изначально, у меня просто появилась задача подключиться к серверу через этот диспетчер.

Через Управление компьютером > Подключиться к другому компьютеру возникает «Ошибка (5). Отказано в доступе».

Хм, команды dcdiag и repadmin /showrepl не проходят на сервере. Видимо, нужно что-то доустанавливать?

Хм, команды dcdiag и repadmin /showrepl не проходят на сервере. Видимо, нужно что-то доустанавливать?

Эти команды необходимо выполнить на DC а не на рядовом сервере, зайдите на DC локально и выполните и выложите вывод команд

Я не волшебник, я только учусь MCP, MCTS, CCNA. Если Вам помог чей-либо ответ, пожалуйста, не забывайте жать на кнопку «Предложить как ответ» или «Проголосовать за полезное сообщение». Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции работодателя. Вся информация предоставляется как есть без каких-либо гарантий. Блог IT Инженера, Twitter.

Хм, команды dcdiag и repadmin /showrepl не проходят на сервере. Видимо, нужно что-то доустанавливать?

Эти команды необходимо выполнить на DC а не на рядовом сервере, зайдите на DC локально и выполните и выложите вывод команд

У вас dc виртуальный или физический сервер?

Тогда будем пытаться делать вывод из имеющейся информации. Из того, что приведено, подозрительны две вещи:

Они должны быть зарегистрированы на MY-PC

Источник

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

Что такое аутентификация

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

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

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

Причины возникновения ошибки

Итак, возникла ошибка аутентификации при подключении к WiFi на Андроид, что делать мы разберём в следующем разделе. Сейчас выясним причины появления такой ошибки.

• Самая распространённая причина, которая актуальна для 80% случаев, — неверно введённый пароль для подключения. Чтобы не нагружать сеть и исключить подключение к ней сторонних устройств пользователь устанавливает пароль. Для того чтобы подключиться клиент должен выбрать нужную сеть и ввести ключ. В идеале он должен состоять не менее чем из 8 символов и содержать в себе только цифры. В этом случае ниже вероятность ошибиться, так как ввод пароля чувствителен не только к раскладке, но и к регистру букв.
• Вторая распространённая причина – несоответствие выбранного типа шифрования. В этом случае устройство просто не поддерживает установленный в настройках маршрутизатора тип, поэтому аутентификация не может пройти успешно.

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

Ошибка аутентификации при подключении к WiFi на Андроид, что делать?

И вот мы перешли к основной части нашей статьи. Ошибка аутентификации при подключении к WiFi на Андроид, что делать? как уже было описано выше проблема может носить разный характер, а соответственно и подходить к её решению следует с разных сторон. Мы разберёмся как исправить ошибку в системе Андроид, а также выясним, как действовать, если необходимо изменить настройки маршрутизатора.

Решение проблемы со стороны Андроида

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

1. Активируйте модуль WiFi на планшете или телефоне и дождитесь пока гаджет найдёт всё доступные подключения.
2. Среди предложенных вариантов выберите ту сеть, к которой Андроид не может подключиться.
3. Нажмите на неё и удерживайте до появления контекстного меню.
4. Выберите пункт «Удалить сеть» или «Забыть сеть», в зависимости от модели гаджета и версии прошивки. Не беспокойтесь, она всё так же будет появляться в списке доступных для подключения, просто, устройство удалит все данные об этой точке доступа и позволит произвести подключение с нуля.
5. Затем вновь запустите сканер доступных подключений и найдите среди предложенных доступных вариантов нужную сеть.
6. Чуть ниже формы для ввода пароля поставьте галочку на пункте «Показать пароль». В некоторых смартфонах и планшетах эта команда представлена значком в виде глаза, в зависимости открыт он или нет определяется видимость символов.
7. Внимательно введите ключ для подключения. Уточнить пароль можно в веб-интерфейсе настроек роутера.

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

Корректировка настроек маршрутизатора

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

Чтобы внести изменения в настройку маршрутизатора, необходимо организовать подключение. Сделать это можно и по WiFi, но надёжнее, если для этого будет использоваться специальный кабель. Подключаться для внесения корректировок можно с компьютера или ноутбука. Для того чтобы попасть в веб-интерфейс достаточно открыть браузер и прописать Ip-адрес нужной точки доступа. Уточнить последний можно на самом роутере, коробке от маршрутизатора или панели управления доступными сетями.

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

Перейдите в расширенные настройки роутера и в разделе WiFi откройте настройки безопасности. В разделе «Сетевая аутентификация» прописан текущий тип аутентификации или шифрования, который может не поддерживать Андроид. Если ваш роутер поддерживает миксованную систему шифрования (с пометкой mixed), то это будет идеальным вариантом выбора. Если такого параметра нет, то стоит экспериментальным методом выбрать тот тип шифрования, который понятен вашему устройству. Для этого выберите один из вариантов, сохраните изменения, перезагрузите маршрутизатор и предпримите попытку подключения. Возможно, описанное действие придётся повторить несколько раз, чтобы устранить первоначальную проблему.

Мы разобрали почему возникает ошибка аутентификации при подключении к WiFi на Андроид, что делать, если это произошло. Пишите в комментариях, как вы избавились от ошибки, а также если у вас возникнут проблемы, попытаемся их решить. Делитесь статьёй в социальных сетях и оставайтесь с нами.

Ошибка аутентификации при подключении к WiFi – одна из самых распространённых проблем, которая связана с неполадкой подключения устройства к маршрутизатору (роутеру). Рассмотрим подробнее саму ошибку и что делать, если она возникает.

Почему возникает данная неполадка?

Ошибка аутентификации возникает, когда маршрутизатор и устройство (подключаемый абонент) не могут идентифицировать друг друга по ряду причин. Основной показатель такой проблемы – при подключении с сетью пишет «Сохранено, не подключено» или просто «Сохранено».

Данная неполадка часто возникает, как на устройствах под управлением операционной системой «Андроид», так и на обычных персональных компьютерах и ноутбуках. Рассмотрим детальнее все возможные способы устранения неполадки. Следуйте инструкциям и советам, чтобы настроить корректное подключение с интернетом.

Проверка пароля

Часто пользователь не может подключится к сети, потому что пароль введен неверно. Из-за того, что окно доступа по умолчанию скрывает введенные символы пароля, пользователь может ошибиться и ввести один из символов неверно. Поставьте галочку в чекбоксе «Показывать пароль», чтобы видеть все символы, которые вы вводите. На компьютерах под управлением ОС «Виндоус» удерживайте клавишу, расположенную справа в текстовом поле, чтобы увидеть символы введенного пароля доступа к маршрутизатору.

Просмотр символов введенного пользователем пароля для проверки их правильности

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

Чтобы это сделать, следуйте нижеприведенной инструкции:

• Зайдите с помощью вашего персонального компьютера или ноутбука в любой из браузеров;
• Введите локальный адрес маршрутизатора в адресной строчке. Посмотреть адрес снизу роутера или в руководстве к нему. Если вы не нашли данных о локальном хосте, воспользуйтесь возможностями командной строчки. Включите окно «Выполнить». В текстовом поле введите «cmd» (без кавычек). Нажмите Ввод. В отрывшемся консольном диалоговом окне впишите текст «ipconfig» (без кавычек) и нажмите Ввод. Найдите пункт «основной шлюз» и в колонке напротив посмотрите адрес – это и есть локальный идентификатор маршрутизатора в сети;

Просмотр идентификатора основного шлюза через командную строчку персонального компьютера пользователя

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

Главное окно настроек маршрутизатора, вкладка расширенных настроек роутера

• В текстовом поле ключа шифрования можно в открытом доступе узнать, какой ключ шифрования использует роутер;

Просмотр ключа доступа к маршрутизатору

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

Проверка соединения роутера

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

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

Наглядная схема правильного подключения роутера и пользовательского персонального компьютера к сети провайдера

Переустановка драйверного ПО сетевого адаптера компьютера

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

• Включите окно диспетчера устройств системы. Для этого кликните правой кнопочкой мыши на кнопке «Пуск» и выберите пункт «Диспетчер устройств»;

Процесс подключения диспетчера устройств

• Найдите среди всех устройств вкладку с сетевыми адаптерами и разверните ее;

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

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

Обновление драйверов сетевого адаптера маршрутизатора на компьютере пользователя

Перепрошивка маршрутизатора

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

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

Перепрошивка через меню настроек

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

Настройка шифрования роутера и устройства

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

Чтобы устранить неполадку, следуйте инструкции:

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

Просмотр используемого роутером алгоритма шифрования данных

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

Таким образом можно быстро решить проблему с идентификацией компьютера при попытке подключения к маршрутизатору.

Тематические видеоролики:

Источник

Почему возникает ошибка аутентификации

Существует несколько типичных сценариев, при которых ваш Андроид может выдать ошибку подключения к Wi-Fi. Вот они в порядке популярности:

Ошибка при вводе пароля

Это самая распространенная, но при этом легко устранимая проблема. Опечатки при вводе кода доступа случаются очень часто из-за:

• неудобной мелкой мобильной клавиатуры
• невнимательности при вводе символов и регистра букв
• путаницы заглавной буквы O и цифры 0 и пр.

Неподходящие сетевые настройки

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

Неверные настройки маршрутизатора

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

Как видите, у всех проблем есть решение, и вот что нужно делать.

Шаг 1: Проверяем пароль для подключения

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

Для начала проверьте актуальность пароля. Для этого зайдите в настройки маршрутизатора. Если такого доступа нет, то еще раз уточните, как выглядит правильный пароль у администратора или владельца сети Wi-Fi.

Теперь, когда у вас есть точный код доступа, действуйте так:

1. Откройте настройки смартфона, затем раздел «Подключения» и подраздел «Wi-Fi».
2. Найдите ту сеть Wi-Fi, к которой не получается подключиться, щелкните на пиктограмму шестеренки напротив имени сети (в некоторых ОС нужно удерживать нажатой строку с именем сети) и щелкните на кнопку «Забыть». Это действие стирает данные о подключении к этой сети, но не удаляет ее из списка возможных подключений.
3. Теперь вы можете заново подключиться к Wi-Fi. Выбрав необходимую сеть в списке доступных. При вводе пароля кликните на перечеркнутое изображение глаза напротив поля для пароля, чтобы вы смогли видеть символы, которые вы вводите, и не ошибиться вновь.

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

1. Зайдите в браузер и введите в адресной строке IP-адрес вашего маршрутизатора, например: 192.168.0.1

Этот адрес может меняться в зависимости от вашего IP. Узнать точный адрес можно с помощью командной строки. На клавиатуре компьютера одновременно зажмите Win + R, затем введите команду cmd и кликните ОК, теперь введите ipconfig и нажмите Enter. В строке «Основной шлюз» будут указан нужный вам IP-адрес роутера.

1. В появившемся окне введите логин и пароль для входа в управление настройками роутера. Если пользователь не менял настройки под себя, то логин – admin, а пароль также – admin.
2. В левом вертикальном меню найдите строку «Беспроводное соединение». Кликните на нее, а в раскрывшемся подменю выберите «Безопасность». В этом блоке будут указан пароль для подключения.

Шаг 2: Сбрасываем все подключения

Для этого достаточно перезагрузить телефон. При включении Android заново будет подключаться к сети Wi-Fi и ошибки, возможно, удастся избежать.

Другой вариант активизировать переподключение к сети – это установка режима «В самолете». В режиме полета все подключения деактивируется, но, когда вы вновь вернетесь в обычный режим, телефон автоматически будет пытаться обновить подключение к сети Wi-Fi. Как правило, быстрый доступ к «Авиарежиму» есть в панели уведомлений. Смахните экран от верхнего края вниз, чтобы раскрыть все доступные функции, а затем включите полетный режим. Не отключайте его минимум в течение 30 секунд, чтобы телефон успел сбросить соединение с сетью.

Шаг 3: Сбрасываем все настройки сети

Иногда ошибка закрадывается в настройки сети, из-за этого предыдущий шаг может не принести разрешения проблемы. Тогда мы советуем сбросить все сетевые настройки. Для этого:

1. Откройте «Настройки», затем «Общие настройки» — «Сброс», и наконец «Сброс параметров сети».
2. На экране высветится предупреждение, что это действие сбросит не только подключения Wi-Fi, но также Мобильные данные и Bluetooth. Чтобы согласиться с этим действием, кликните на кнопку «Сброс настроек».
3. Вновь установите подключение к Wi-Fi.

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

Шаг 4: Настраиваем статичный IP-адрес

Порой ошибка аутентификации может возникнуть из-за неподходящих настроек IP. Их нужно проверить, а при необходимости изменить.

1. Для начала вам нужно узнать, какой шлюз использует ваш маршрутизатор. Мы в «Шаге №1» уже рассказывали, как это сделать. Но есть еще один вариант – найти эту информацию на корпусе роутера. Правда не все производители указывают ее. IP-адрес маршрутизатора должен выглядеть примерно так: 192.168.0.1

1. Теперь откройте в своем телефоне «Настройки» — «Подключения» — «Wi-Fi» — «Имя сети Wi-Fi».
2. В настройках к проблемному подключению раскройте блок «Дополнительно», а затем тапните на строку «Параметры IP». У вас появится два варианта: DHCP и Статический. Выберите второй вариант.
3. Перед вами развернуться поля, которые вы должны заполнить следующим образом:

1. Сохраните обновленные настройки и заново подключитесь к Сети.

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

Шаг 5: Исправляем настройки маршрутизатора

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

Если же это действие не помогло, то вам нужно изменить настройки шифрования в админпанели. Как войти в нее мы уже рассказывали в Шаге №1. Далее шаги будут несколько различаться из-за того, что производители маршрутизаторов разрабатывают для своих продуктов индивидуальный дизайн интерфейса. Но общая схема действий будет выглядеть так:

1. Откройте «Беспроводной режим», а затем «Защита беспроводного соединения».
2. На экране появятся настройки защиты. Помимо пароля для подключения к сети, здесь нужно установить тип шифрования. Не стоит отключать защиту, так как этим могут воспользоваться мошенники. Но с настройками шифрования WPA/WPA2 придется повозиться, выбирая то сочетание, которое не мешает аутентификации. Как правило, это выглядит так:

WPA/WPA2 – Personal

Версия: WPA2 – PSK

Шифрование: AES

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