Ошибка поддержки безопасных каналов windows 7 как исправить

Проблемы безопасных каналов

Доменная инфраструктура Microsoft довольно сложна. Например, Active Directory (AD) использует общепринятым образом определяемую и работающую схему объектов и атрибутов в базе данных, требует сетевого подключения к одноранговым контроллерам домена (DC) для своевременного обновления элементов и корректной настройки конфигурации DNS, а также имеет другие взаимозависимости с сетевой средой

Каждый компьютер, присоединяемый к домену (клиентская рабочая станция, сервер или DC), требует подключения к DC для обеспечения выполнения обязательных требований по обслуживанию в домене AD. Для рабочих станций и серверов необходимо подключение к DC того домена, которому они принадлежат, а также к DC доменов-доверителей. DC одного домена должны иметь связь с DC доменов-доверителей и доверенных доменов. Кэшированные значения, определяющие междоменные соединения, описываются термином «безопасный канал домена». Существует два типа безопасных каналов: между членом домена и DC этого же домена; между DC домена-доверителя и DC доверенного домена.

Значение безопасных каналов

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

Для чего нужен безопасный канал? Напрашивается ответ: «для всего, что связано с доменом». Все службы, связанные с доменом, должны иметь возможность обнаружения DC для отправки запроса. Это верно как для члена домена (например, рабочей станции или рядового сервера), так и для DC. Обеспечение доступности эффективно реагирующего DC — функция безопасного канала. Если с сервером нельзя связаться и отправить запрос, то службы не работают.

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

Рассмотрим типовой мультидоменный сценарий. Предположим, что пользователь из домена A регистрируется в системе на компьютере B в домене B. Регистрация пользователя обрабатывается в соответствии с групповой политикой, и на DC домена А по протоколу LDAP посылается запрос с тем, чтобы определить, какая политика применима к пользователю А. Как компьютер B, принадлежащий домену B, узнает, куда отправлять сетевой трафик, чтобы выяснить применяемую политику домена А? Это возможно благодаря тому, что сведения о сетевом расположении домена и DC постоянно обновляются. Актуальность информации поддерживается службой NetLogon на каждом компьютере, присоединенном к домену Windows. NetLogon постоянно формирует список доступных DC и доменов (при наличии отношений доверия). На экране 1 приведен фрагмент журнала отладки NetLogon, иллюстрирующий этот непрерывный процесс. Вы можете просмотреть журнал отладки NetLogon на своем компьютере, следуя инструкциям, приведенным в статье Microsoft «Enabling debug logging for the NetLogon service» (http://support.microsoft.com/kb/109626).

Экран 1. Фрагмент журнала отладки NetLogon

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

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

Выявление проблемы безопасного канала

Лучший способ обнаружить проблему безопасного канала – задействовать функцию I_NetLogonControl2. I_NetlogonControl2 – это одна из функций, используемых службой NetLogon (она есть на любом компьютере с Windows любой версии) для поддержания сведений о доступных доменах и DC.

В распоряжении администратора есть три простых инструмента для вызова этой функции и быстрого получения информации о возможности подключения к определенному домену и DC: NLTest, PowerShell и WMI.

NLTest.exe. Утилита NLTest.exe была выпущена в комплекте средств поддержки Windows 2000 и Windows Server 2003 и включена по умолчанию в большинство более новых версий Windows. Параметр sc_verify вызывает I_NetlogonControl2, и вам остается указать проблемный домен.

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

PowerShell. В PowerShell 2.0 добавлена команда PowerShell Test-ComputerSecureChannel, которая также вызывает I_NetLogonControl2, но обеспечивает минимум информации, возвращая ответ True, если безопасный канал домена исправен, а DC доступен, либо, в противном случае, ответ False.

Подобно NLTest.exe, команда Test-ComputerSecureChannel может применяться и для исправления ошибки с использованием ключа Repair.

WMI. С помощью класса win32_ntdomain инструментарий управления Windows (WMI) позволяет запросить все домены, о которых знает компьютер. WMI полезен в случаях, когда на тестируемом компьютере нельзя рассчитывать на средства PowerShell. Заметим, что в приведенном ниже примере (где Win32_NTDomain вызывается через команду PowerShell Get-WMIObject с использованием псевдонима GWMI) в качестве ответа возвращается только локальный домен, но может быть возвращен любой домен, связанный с локальным доменом отношениями доверия.

Заметим, что состояние OK в этом примере соответствует ответу True или False, возвращаемому командой Test-ComputerSecureChannel, и указывает на работоспособность или неработоспособность безопасного канала.

Устранение проблемы безопасного канала

Пользователям, обращающимся в службу поддержки Microsoft, высылается дополнительный пакет сбора данных. Вместо собственной команды PowerShell Test-ComputerSecureChannel в пакете используется WMI-класс Win32_NTDomain (вызываемый из PowerShell), что позволяет запускать тест даже на более старых операционных системах, таких как Windows XP и Windows 2003. Для иллюстрации применения теста ниже приведены два примера сценариев, которые можно самостоятельно запустить в окне PowerShell, см. листинг 1 и листинг 2.

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

Экран 2. Результаты работы первого сценария

Для выявления любой проблемы создается тест как сценарий PowerShell (файл. ps1), а к возвращаемому состоянию добавляется условный оператор ‘if’. Можно также указать имя домена, как показано в примере, показанном в Листинге 2.

В практике диагностики Microsoft этот сценарий превращен в простую функцию, которую можно использовать повторно.

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

Листинг 1. Сценарий проверки безопасного канала

Листинг 2. Усовершенствованный сценарий проверки

Источник

Сообщения об ошибках (WinHTTP. h)

Значения ошибок, имена которых начинаются с «ERROR _ WinHTTP _ «, относятся к функциям WinHTTP. функции WinHTTP также возвращают Windows сообщения об ошибках, если это уместно.

Ошибка _ _ службы автоматического _ прокси-сервера WinHTTP _ _

Ошибка _ _ при автообнаружении WinHTTP _

Ошибка _ WinHTTP _ неверный _ _ Скрипт автоматического прокси _

Произошла ошибка при исполнении кода скрипта в файле автоматической настройки прокси-сервера (PAC).

Ошибка _ WinHTTP _ не удается _ вызвать _ после _ открытия

Ошибка _ WinHTTP _ не удается _ вызвать _ после _ отправки

Ошибка _ WinHTTP _ не может _ вызвать _ перед _ открытием

Ошибка _ WinHTTP _ не может _ вызвать _ перед _ отправкой

Ошибка _ WinHTTP _ не удается _ подключиться

Возвращается при сбое соединения с сервером.

Ошибка _ _ _ требуется сертификат проверки подлинности клиента WinHTTP _ _

Windows Server 2003 с пакетом обновления 1 и Windows XP с пакетом обновления 2 (SP2): Эта ошибка не поддерживается.

Ошибка _ WinHTTP _ _ сертификат клиента _ без _ доступа _ закрытый _ ключ

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

Windows Server 2003 с пакетом обновления 1 и Windows XP с пакетом обновления 2 (SP2): Эта ошибка не поддерживается.

Ошибка _ WinHTTP _ _ сертификат клиента _ без _ закрытого _ ключа

Контекст для SSL-сертификата клиента не связан с закрытым ключом. Сертификат клиента мог быть импортирован на компьютер без закрытого ключа.

Windows Server 2003 с пакетом обновления 1 и Windows XP с пакетом обновления 2 (SP2): Эта ошибка не поддерживается.

Ошибка _ при _ _ _ _ переполнении размера заголовка фрагментированной кодировки WinHTTP _

Возвращается функцией WinHttpReceiveResponse при обнаружении условия переполнения в процессе синтаксического анализа фрагментированной кодировки.

Ошибка _ _ _ требуется сертификат проверки подлинности клиента WinHTTP _ _

Windows Server 2003 с пакетом обновления 1 и Windows XP с пакетом обновления 2 (SP2): Эта ошибка не поддерживается.

Ошибка _ _ подключения WinHTTP _

Подключение к серверу было сброшено или прервано, или обнаружен несовместимый протокол SSL. Например, служба WinHTTP версии 5,1 не поддерживает SSL2, если только клиент явно не включит ее.

_заголовок ошибки _ WinHTTP _ уже _ существует

Устаревшие больше не используется.

Ошибка _ при _ _ превышении числа заголовков WinHTTP _

Ошибка _ _ _ не _ найдена заголовок WinHTTP

Не удается найти запрошенный заголовок.

Ошибка _ _ _ переполнения размера заголовка WinHTTP _

Ошибка _ WinHTTP _ неправильное _ состояние обработчика _

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

Ошибка _ WinHTTP _ неверный _ тип обработчика _

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

Ошибка _ _ внутренней _ ошибки WinHTTP

Произошла внутренняя ошибка.

Ошибка _ WinHTTP _ Недопустимый _ параметр

Ошибка _ WinHTTP _ Недопустимый _ _ запрос запроса

Устаревшие больше не используется.

Ошибка _ WinHTTP _ Недопустимый _ _ ответ сервера

Не удается выполнить синтаксический анализ ответа сервера.

Ошибка _ WinHTTP _ Недопустимый _ URL-адрес

URL-адрес является недопустимым.

Ошибка _ _ при попытке входа WinHTTP _

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

Ошибка _ _ имя WinHTTP _ не _ разрешено

Не удается разрешить имя сервера.

Ошибка _ WinHTTP _ не _ инициализирована

Устаревшие больше не используется.

Ошибка _ _ операции WinHTTP _ отменена

Операция была отменена, как правило, из-за того, что обработчик, на котором был запущен запрос, был закрыт до завершения операции.

Невозможно задать запрошенный параметр, выполняется только запрос.

Ошибка _ WinHTTP _ вне _ _ дескрипторов

Устаревшие больше не используется.

Ошибка _ _ при перенаправлении WinHTTP _

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

Ошибка _ _ запроса повторной отправки WinHTTP _

Сбой функции WinHTTP. Нужная функция может быть выполнена повторно с тем же маркером запроса.

Ошибка _ _ _ переполнения очистки ответа WinHTTP _

Возвращается, когда входящий ответ превышает ограничение внутреннего размера WinHTTP.

Ошибка _ _ при выполнении скрипта WinHTTP _ _

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

Ошибка _ WinHTTP _ _ _ _ Недопустимый CN Secure CERT

Возвращается, если различающееся имя сертификата не соответствует переданному значению (что эквивалентно ошибке » _ _ CN _ без _ сопоставления» сертификата E ).

Ошибка _ _ _ _ Недопустимая дата безопасного сертификата WinHTTP _

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

Ошибка _ _ _ _ _ при попытке установить безопасный сертификат WinHTTP

Указывает, что отзыв не может быть проверен, так как сервер отзыва был отключен (что эквивалентно шифрованию _ _ отзыва _ E).

Ошибка _ при _ _ отзыве безопасного сертификата WinHTTP _

Указывает, что сертификат был отозван (эквивалентно шифрованию _ E _ REVOKE).

Ошибка _ при _ _ _ неправильном _ использовании безопасного сертификата WinHTTP

Указывает, что сертификат недействителен для запрошенного использования (аналогично _ _ неправильному _ использованию CERT E).

Ошибка _ при _ _ ошибке безопасного канала WinHTTP _

Указывает, что при возникновении ошибки в защищенном канале (эквиваленты кодам ошибок, которые начинаются с «с _ E _ » и «сек _ I», _ перечисленные в файле заголовка Winerror. h).

Ошибка _ _ безопасного _ сбоя WinHTTP

В сертификате SSL (SSL), отправленном сервером, обнаружена одна или несколько ошибок. Чтобы определить тип обнаруженной ошибки, проверьте _ состояние обратного вызова WinHTTP на _ _ _ наличие уведомления о сбое в функции обратного вызова состояния. Дополнительные сведения см. в разделе _ _ обратный вызов состояния WinHTTP.

Ошибка _ WinHTTP _ безопасный _ Недопустимый _ ЦС

Указывает, что цепочка сертификатов была обработана, но была прервана в корневом сертификате, который не является доверенным для поставщика доверия (эквивалентно CERT _ E _ унтрустедрут).

Ошибка _ WinHTTP _ безопасный _ Недопустимый _ сертификат

Указывает, что сертификат является недопустимым (аналогично таким ошибкам, как _ _ роль CERT e, CERT _ e _ пасленконст, CERT _ e _ Critical, CERT _ e _, CERT _ e _ иссуерчаининг, CERT _ e _ неправильный формат и _ _ цепочка сертификатов e).

Ошибка _ при _ завершении работы WinHTTP

Поддержка функции WinHTTP завершается или выгружается.

Ошибка _ при _ истечении времени ожидания WinHTTP

Истекло время ожидания запроса.

эта ошибка может быть возвращена в результате истечения времени ожидания TCP/IP независимо от значений времени ожидания, заданных в Windows служб HTTP.

Ошибка _ WinHTTP _ не _ удалось _ скачать _ Скрипт

Не удается скачать файл PAC. Например, сервер, на который ссылается URL-адрес PAC, может быть недоступен, или сервер вернул ответ 404 не найден.

Ошибка _ _ необработанного _ типа скрипта WinHTTP _

Тип скрипта не поддерживается.

Ошибка _ WinHTTP _ Нераспознанная _ схема

В URL-адресе указана схема, отличная от «http:» или «https:».

Ошибка _ не _ хватает _ памяти

Недостаточно памяти для завершения запрошенной операции.

Заголовок: Объявлено в файле Winerror. h

Ошибка _ недостаточного _ буфера

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

Заголовок: Объявлено в файле Winerror. h

Ошибка _ недопустимого _ маркера

Маркер, переданный в интерфейс прикладного программирования (API), был либо недействительным, либо закрытым.

Заголовок: Объявлено в файле Winerror. h

Ошибка _ больше _ нет _ файлов

Больше файлов не найдено.

Заголовок: Объявлено в файле Winerror. h

Ошибка _ больше _ нет _ элементов

Больше элементов не найдено.

Заголовок: Объявлено в файле Winerror. h

Ошибка _ не _ поддерживается

Необходимый стек протокола не загружен, и приложение не может запустить WinSock.

Заголовок: Объявлено в файле Winerror. h

сведения о Windows XP и Windows 2000 см. в разделе требования к времени выполнения на начальной странице WinHttp.

Источник

Управление изменениями в подключениях безопасного канала Netlogon, связанными с CVE-2020-1472

Сводка

Удаленный протокол Netlogon (другое название — MS-NRPC) — это интерфейс RPC, используемый только устройствами, подключенными к домену. MS-NRPC включает метод проверки подлинности и метод создания безопасного канала Netlogon. Эти обновления внедряют определенное поведение клиента Netlogon для применения безопасного удаленного вызова процедур (RPC) с помощью безопасного канала Netlogon между компьютерами участников и контроллерами домена (DC) Active Directory (AD).

Это обновление для системы безопасности устраняет уязвимость, принудительно внедряя безопасный RPC при использовании безопасного канала Netlogon в поэтапном выпуске, описанном в разделе Сроки выпуска обновлений для устранения уязвимости Netlogon CVE-2020-1472. Чтобы обеспечить защиту леса AD, все DC должны быть обновлены, так как они будут применять безопасный RPC с безопасным каналом Netlogon. Сюда относятся контроллеры домена только для чтения (RODC).

Дополнительные сведения об уязвимости см. в статье CVE-2020-1472.

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

Примечание. Шаг 1 по установке обновлений за 11 августа 2020 г. или более поздней версии поможет устранить проблему безопасности, связанную с CVE-2020-1472, в доменах Active Directory и отношениях доверия между ними, а также на устройствах Windows. Чтобы минимизировать риск возникновения проблемы безопасности для сторонних устройств, необходимо выполнить все указанные действия.

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

ОБНОВЛЕНИЕ контроллеров домена (обновление за 11 августа 2020 г. или более поздней версии).

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

ИСПРАВЛЕНИЕ несоответствующих устройств, использующих уязвимые соединения.

ВКЛЮЧЕНИЕ режима применения политик для исправления CVE-2020-1472 в своей среде.

Примечание. Если вы используете Windows Server 2008 R2 с пакетом обновления 1 (SP1), для успешной установки обновления, устраняющего эту проблему, требуется лицензия на расширенные обновления безопасности (ESU). Дополнительные сведения о программе расширенных обновлений безопасности см. в статье Вопросы и ответы по жизненному циклу: расширенные обновления безопасности.

Сроки выпуска обновлений для устранения уязвимости Netlogon CVE-2020-1472

Обновления будут выпущены в два этапа: начальный этап — обновления, выпущенные 11 августа 2020 г. и позже, и этап применения политик — обновления, выпущенные 9 февраля 2022 г. и позже.

Этап начального развертывания начинается с обновлений, выпущенных 11 августа 2020 г., и продолжается с последующими обновлениями до этапа применения политик. Эти и последующие обновления изменяют протокол Netlogon для защиты устройств с Windows по умолчанию, регистрируют события обнаружения несоответствующих устройств и добавляют возможность включения защиты для всех устройств, подключенных к домену, с явными исключениями. Этот выпуск:

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

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

Внедряет использование безопасного RPC для всех контроллеров доменов (DC) Windows и других контроллеров доменов.

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

Раздел реестра FullSecureChannelProtection для включения режима применения политик DC во всех учетных записях компьютеров (этап применения политик обновит DC до режима применения политик DC).

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

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

Выпуск за 9 февраля 2022 г. знаменует переход на этап применения политик. Теперь DC будут находиться в режиме применения политик независимо от значения раздела реестра режима применения политик. Для этого на всех устройствах с Windows и других устройствах требуется использовать безопасный RPC с безопасным каналом Netlogon или явным образом разрешить учетную запись, добавив исключение для несоответствующих устройств. Этот выпуск:

Внедряет использование безопасного RPC для учетных записей компьютеров на устройствах без Windows, если отсутствует разрешение от групповой политики «Контроллер домена: разрешить уязвимые подключения безопасного канала Netlogon».

Запись журнала для события с кодом 5829 будет удалена. Так как все уязвимые подключения запрещаются, в журнале системных событий теперь будут отображаться только события с кодом 5827 и 5828.

Руководство по развертыванию: развертывание обновлений и обеспечение соответствия

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

Развертывание обновлений за 11 августа 2020 г.

Разверните обновления за 11 августа для всех соответствующих контроллеров домена (DC) в лесу, включая контроллеры домена только для чтения (RODC). После развертывания этого обновления исправленные DC:

Начнут применять безопасный RPC во всех учетных записях устройств с Windows, учетных записях доверия и всех DC.

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

Регистрируют события с кодами 5830 и 5831 в журнале системных событий, если подключения разрешены групповой политикой «Контроллер домена: разрешить уязвимые подключения безопасного канала Netlogon».

Регистрируют событие с кодом 5829 в журнале системных событий, когда разрешается уязвимое подключение безопасного канала Netlogon. Эти события следует исправить до настройки режима применения политик DC или до начала этапа применения политик 9 февраля 2022 г.

Обнаружение несоответствующих устройств с помощью события с кодом 5829

После применения к DC обновлений за 11 августа 2020 г. в журналах событий DC могут собираться события, чтобы определить, какие устройства в вашей среде используют уязвимые подключения безопасного канала Netlogon (называемые в этой статье несоответствующими устройствами). Отслеживайте исправленные DC для событий с кодом 5829. Эти события будут содержать важные сведения для определения несоответствующих устройств.

Чтобы отслеживать события, используйте доступные программы мониторинга событий или сценарий для отслеживания своих DC. Пример сценария, который можно адаптировать к своей среде, см. в разделе Сценарий для отслеживания кодов событий, связанных с обновлениями Netlogon для CVE-2020-1472

Шаг 2b. ИСПРАВЛЕНИЕ

Исправление событий с кодами 5827 и 5828

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

Убедитесь, что на устройстве используется поддерживаемая версия Windows.

Полностью обновите устройство.

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

Рекомендация. Обратитесь к изготовителю устройства (OEM) или поставщику программного обеспечения, чтобы получить поддержку для безопасного RPC с безопасным каналом Netlogon

Если несоответствующий DC поддерживает безопасный RPC с безопасным каналом Netlogon, включите безопасный RPC на DC.

Если несоответствующий DC в настоящее время НЕ поддерживает безопасный RPC, обратитесь к изготовителю устройства (OEM) или поставщику программного обеспечения, чтобы получить обновление, поддерживающее безопасный RPC с безопасным каналом Netlogon.

Прекратите использование несоответствующего DC.

Уязвимость. Если несоответствующий DC не может обеспечить поддержку безопасного RPC с безопасным каналом Netlogon до перевода DC в режим применения политик, добавьте DC с помощью групповой политики «Контроллер домена: разрешить уязвимые подключения безопасного канала Netlogon», описанной ниже.

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

Исправление события с кодом 5829

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

Способы исправления несоответствующих устройств:

Рекомендация. Обратитесь к изготовителю устройства (OEM) или поставщику программного обеспечения, чтобы получить поддержку для безопасного RPC с безопасным каналом Netlogon:

Если несоответствующее устройство поддерживает безопасный RPC с безопасным каналом Netlogon, включите безопасный RPC на устройстве.

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

Прекратите использование несоответствующего устройства.

Уязвимость. Если несоответствующее устройство не может обеспечить поддержку безопасного RPC с безопасным каналом Netlogon до перевода DC в режим применения политик, добавьте устройство с помощью групповой политики «Контроллер домена: разрешить уязвимые подключения безопасного канала Netlogon», описанной ниже.

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

Разрешение уязвимых подключений из сторонних устройств

Используйте групповую политику «Контроллер домена: разрешить уязвимые подключения безопасного канала Netlogon», чтобы добавить несоответствующие учетные записи. Это следует рассматривать только в качестве краткосрочного решения, пока несоответствующие устройства не будут исправлены, как описано выше. Примечание. Разрешение уязвимых подключений для несоответствующих устройств следует предоставлять с осторожностью, учитывая неизвестное влияние на безопасность.

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

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

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

Добавьте группу безопасности, созданную специально для использования с этой групповой политикой, в дескриптор безопасности с параметром «Разрешить». Примечание. Параметр «Запретить» соответствует поведению без добавления учетной записи, то есть учетным записям будет запрещено создавать уязвимые безопасные каналы Netlogon.

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

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

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

После исправления всех несоответствующих устройств вы можете перевести свои DC в режим применения политик (см. следующий раздел).

Шаг 3a. ВКЛЮЧЕНИЕ

Переход в режим применения политик до этапа применения политик в феврале 2022 г.

После исправления всех несоответствующих устройств путем включения безопасного RPC или разрешения уязвимых подключений с помощью групповой политики «Контроллер домена: разрешить уязвимые подключения безопасного канала Netlogon» присвойте разделу реестра FullSecureChannelProtection значение 1.

Примечание. Если вы используете групповую политику «Контроллер домена: разрешить уязвимые подключения безопасного канала Netlogon» убедитесь в репликации и применении групповой политики ко всем DC до настройки раздела реестра FullSecureChannelProtection.

После развертывания раздела реестра FullSecureChannelProtection контроллеры домена (DC) будут находиться в режиме применения политик. Этот параметр требует, чтобы все устройства, использующие безопасный канал Netlogon, отвечали одному из следующих условий:

Использование безопасного RPC.

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

Шаг 3b. Этап применения политик

Развертывание обновлений за 9 февраля 2022 г.

Развертывание обновлений, выпущенных 9 февраля 2022 г. и позднее, включит режим применения политик DC. Режим применения политик DC — это состояние, при котором все подключения Netlogon должны использовать безопасный RPC или учетная запись должна быть добавлена в групповую политику «Контроллер домена: разрешить уязвимые подключения безопасного канала Netlogon». В этот момент раздел реестра FullSecureChannelProtection больше не нужен и больше не будет поддерживаться.

Групповая политика «Контроллер домена: разрешить уязвимые подключения безопасного канала Netlogon»

Рекомендуется использовать группы безопасности в групповой политике, чтобы участие реплицировались в рамках обычной репликации AD. Это позволит избежать частого обновления групповой политики и задержек репликации.

Путь политики и имя параметра

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

Имя параметра: «Контроллер домена: разрешить уязвимые подключения безопасного канала Netlogon»

Требуется перезагрузка? Нет

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

Эту политику следует применить ко всем контроллерам домена в лесу, включив политику в OU контроллеров домена.

При настройке списка «Создание уязвимых подключений» (список разрешений):

Разрешить. Контроллер домена позволит определенным группам и учетным записям использовать безопасный канал Netlogon без безопасного RPC.

Запретить. Этот параметр соответствует поведению по умолчанию. Контроллер домена потребует, чтобы определенные группы и учетные записи использовали безопасный канал Netlogon с безопасным RPC.

Предупреждение. Включение этой политики предоставит доступ к вашим устройствам, подключенным к домену, и к вашему лесу Active Directory, что может подвергнуть их риску. Эту политику следует использовать в качестве временной меры для сторонних устройств при развертывании обновлений. После обновления стороннего устройства для поддержки использования безопасного RPC с безопасными каналами Netlogon следует удалить учетную запись из списка «Создание уязвимых подключений». Дополнительные сведения о риске настройки учетных записей с разрешением уязвимых подключений безопасного канала Netlogon см. на странице https://go.microsoft.com/fwlink/?linkid=2133485.

По умолчанию: Эта политика не настроена. Никакие компьютеры и учетные записи доверия не исключаются явным образом из обязательного применения безопасного RPC с подключениями безопасного канала Netlogon.

Эта политика поддерживается в Windows Server 2008 R2 с пакетом обновления 1 (SP1) и более поздних версиях.

Ошибки в журнале событий Windows, связанные с CVE-2020-1472

Существует три категории событий.

1. События, регистрируемые при отказе в подключении из-за попыток уязвимого подключения безопасного канала Netlogon:

Ошибка 5827 (учетные записи компьютеров)

Ошибка 5828 (учетные записи доверия)

2. События, регистрируемые при разрешении подключения, так как учетная запись была добавлена в групповую политику «Контроллер домена: разрешить уязвимые подключения безопасного канала Netlogon»:

Предупреждение 5830 (учетные записи компьютеров)

Предупреждение 5831 (учетные записи доверия)

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

Предупреждение 5829 (учетные записи компьютеров)

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

Источник

Обновлено 28.11.2022

Добрый день! Уважаемые читатели и гости IT портала Pyatilistnik.org. В прошлый раз мы с вами решали проблему, когда у нас тормозил Directum на терминальной ферме. В сегодняшней ситуации я опять вернусь к данному программному обеспечению и покажу, что мне удалось раскопать в ситуации, что при попытке создать договорной документ и выбрать его из конструктора документов, я получаю предупреждение «Ошибка поддержки безопасных каналов«. Давайте смотреть в чем дело и что можно поменять, чтобы все заработало.

Устранение ошибки поддержки безопасных каналов

Данную проблему я поймал в Directum на своей RDS-ферме. Стало увеличиваться количество обращений со стороны пользователей, что они при попытке создания договорного документа стали видеть ошибку:

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

• 1️⃣В интернете все копипастят друг у друга, что в данной ситуации помогает включение TLS, но я проверил и правки в реестре не дают ничего, тем более у меня уже они были активированы, я с этим еще сталкивался, когда получал ошибку «Unable to resolve package source» при установке модуля PowerShell.
• 2️⃣Далее если у вас есть антивирусное решение, то я вам советую его отключить на время, пока будите производить тестирование. Антивирус Касперского тут так же был ни причем
• 3️⃣Далее, что я обычно проверяю, это не производилась ли установка нового софта или обновлений Windows. Обязательно выведите список установленных программ и посмотрите, нет ли там чего-то нового. Бывает ситуация, что некоторые программы могут конфликтовать при совместном использовании, например очень частая ситуация с КриптоПРО, старыми версиями. Если она есть, то попробуйте ее удалить.
• 4️⃣Проверьте не было ли установки новых обновлений, это можно посмотреть в истории параметров Windows или в оснастке appwiz.cpl.

В результате на Windows Server прилетело KB5018411 на клиентские Windows 10 и Windows 11 прилетело kb5018410, что в итоге делать, на текущий момент просто удалять и ждать новых обновлений от Microsoft.

Чтобы удалить KB5018411  я воспользуюсь командной строкой и утилитой wusa. Введите:

У вас выскочит окно с подтверждением удаления данного обновления. Нажмите ок, начнется процесс.

Так же вы можете сделать, и тихое удаление добавим ключи: /quiet /norestart

После этого мой Directum заработал, посмотрю что будет со следующими обновлениями, может Mixrosoft пофиксит это.

Обновление 28.11.2022

Как и ожидалось, данная ошибка была устранена установкой ноябрьских обновлений KB5019964. С вами был Иван Семин, автор и создатель IT проекта Pyatilistnik.org.

Исправить ошибку Microsoft Store 0x80072F7D

Если после открытия приложения Microsoft Store вы получаете код ошибки 0x80072F7D, то этот пост может помочь вам с некоторыми простыми исправлениями. Этот код ошибки может возникать, когда есть проблема, связанная с вашим Интернет-соединением или сетевым подключением, или по какой-либо другой причине.

Сообщение об ошибке выглядит так:

Проверьте ваше соединение. Microsoft Store должен быть в сети. Похоже, это не так.

Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)

Код объявления: 0x80072F7D.

Ошибка Microsoft Store 0x80072F7D

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

1. Проверьте ваше интернет-соединение
2. Запустите средство устранения неполадок сети
3. Запустите средство устранения неполадок подключения к Интернету
4. Запустите средство устранения неполадок приложений Магазина Windows
5. Временно отключите программное обеспечение безопасности.

1]Проверьте подключение к Интернету

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

После этого выйдите из Windows 10 и войдите снова. Теперь откройте приложение Microsoft Store и посмотрите, исчезла ли ваша проблема.

Кроме того, вы также можете переключиться на другое подключение к Интернету, а затем открыть приложение Microsoft Store, чтобы узнать, работает ли ваше подключение нормально или проблема связана с самим подключением к Интернету.

2]Запустите средство устранения неполадок сети

Если подключение к Интернету работает нормально, следует запустить средство устранения неполадок сети. Это встроенная функция Windows 10, которая помогает диагностировать и устранять сетевые проблемы. Вот шаги:

1. Откройте приложение настроек Windows 10 с помощью Win + I горячая клавиша
2. Щелкните категорию Сеть и Интернет.
3. Прокрутите страницу вниз
4. Нажмите на средство устранения неполадок сети.
5. Выберите сетевой адаптер для диагностики
6. Нажмите кнопку «Далее».

После этого он запустит процесс диагностики сети, проверит проблемы в конфигурации сетевого адаптера и т. Д. И предоставит вам исправления. Это может сработать.

3]Запустите средство устранения неполадок подключения к Интернету.

Если проблема связана с подключением к Интернету, Windows 10 предоставляет средство устранения неполадок с подключением к Интернету, которое может пригодиться и устранить ошибку 0x80072F7D для Microsoft Store. Следуй этим шагам:

1. нажимать Win + I горячая клавиша, чтобы открыть приложение «Настройки»
2. Щелкните категорию «Обновление и безопасность».
3. Нажмите на страницу устранения неполадок, как показано на левой боковой панели.
4. Выберите параметр Дополнительные средства устранения неполадок.
5. Нажмите на опцию подключения к Интернету
6. Нажмите кнопку «Запустить средство устранения неполадок».

После этого он автоматически проверит проблемы и предоставит исправления.

4]Запустите средство устранения неполадок приложений Магазина Windows.

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

1. нажимать Win + I горячая клавиша, чтобы открыть приложение «Настройки»
2. Выберите категорию «Обновление и безопасность».
3. Нажмите на страницу устранения неполадок, доступную слева.
4. Используйте параметр Дополнительные средства устранения неполадок, доступный в правой части
5. Нажмите на опцию Windows Store Apps.
6. Нажмите кнопку «Запустить средство устранения неполадок».

Теперь средство устранения неполадок будет анализировать различные вещи, например, изменилось ли местоположение временных интернет-файлов, проверять ключи реестра приложений и т. Д. И предоставлять возможные исправления. Это может помочь вам разобраться с ошибкой Microsoft 0x80072F7D.

5]Временно отключите программное обеспечение безопасности.

Возможно, установленное вами программное обеспечение безопасности мешает вашему подключению к Интернету или настройке сетевого адаптера, из-за чего вы получаете ошибку Microsoft Store 0x80072F7D. Итак, попробуйте временно отключить такое программное обеспечение, а затем проверьте, работает ли приложение Microsoft Store нормально или нет.

Надеюсь, что-то сработает для вас.

.

Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)

Источник

Error code 0x80072f7d ошибка поддержки безопасных каналов

1. Дом
2. Исправлять
3. Ошибка 0x80072f7d на windows 10 [исправлено экспертами]

Ошибка 0x80072f7d на windows 10 [исправлено экспертами]

Оглавление:

Видео: How To Make Windows 10 Fix Itself No Special Software Needed 2023

Видео: How To Make Windows 10 Fix Itself No Special Software Needed 2023

Ряд пользователей сообщили, что видели код ошибки 0x80072f7d при попытке получить доступ к Магазину Microsoft на своем ПК с Windows 10.

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

Как исправить ошибку Microsoft Store с кодом 0x80072f7d?

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

1. Щелкните правой кнопкой мыши значок подключения к Интернету на панели задач -> выберите Устранение неполадок.

Подождите, пока завершится процесс проверки вашего соединения, а затем выберите подходящие параметры из средства устранения неполадок.

Попытайтесь увидеть, решило ли это вашу проблему.

2. Сбросьте ваш магазин Microsoft

1. Нажмите клавиши Win + R на клавиатуре, чтобы открыть окно «Выполнить».
2. Внутри окна Run -> введите wsreset.exe -> нажмите Enter.

Дождитесь завершения процесса и перезагрузите компьютер.

Попробуйте снова открыть магазин Microsoft.

Если проблема не устранена, следуйте следующему способу.

3. Измените настройки ПК на вашем компьютере.

1. Нажмите клавиши Win + I на клавиатуре, чтобы запустить настройки Windows.
2. Выберите опцию « Сеть и Интернет».

Нажмите на опцию Центр управления сетями и общим доступом в нижней части экрана.

Нажмите на Свойства обозревателя.

Перейдите на вкладку « Дополнительно » -> в разделе « Настройки » -> установите флажок « Использовать TLS 1.2» -> нажмите « ОК».

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

Приложения Microsoft Store не обновляются? Вот быстрый и легкий способ попробовать!

4. Очистить файлы cookie и кэш из Microsoft Edge

1. Откройте Microsoft Edge -> выберите три точки, расположенные в правой верхней части экрана -> выберите « Настройки» в раскрывающемся меню.

Нажмите кнопку Выбрать, что очистить.

Установите флажки рядом с историей просмотра, файлами cookie и сохраненными данными веб-сайта, а также кэшированными данными и файлами -> нажмите кнопку « Очистить».

Закройте браузер и перезагрузите компьютер.

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

5. Переустановите приложение Магазина Windows

1. Нажмите клавиши Win + X на клавиатуре -> выберите Приложения и компоненты.

Прокрутите вниз и найдите приложение Microsoft Store -> выберите его -> нажмите Дополнительные параметры.

В меню « Дополнительные параметры» прокрутите вниз -> нажмите кнопку «Сброс».

Это запустит процесс удаления и переустановки приложения Windows Store.

Дождитесь завершения процесса, а затем проверьте, решена ли проблема.

Мы рассмотрели некоторые из лучших методов устранения ошибок 0x80072f7d, относящихся к приложению Microsoft Store в Windows 10. Пожалуйста, внимательно следуйте этим шагам, чтобы избежать возникновения других проблем.

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

ЧИТАЙТЕ ТАКЖЕ:

• VPN блокирует приложения Магазина Windows
• Вскоре вы сможете покупать игры Microsoft Store в Steam
• Как исправить ошибку Windows Store 0x8004e108 в Windows 10

Ошибка страницы драйвера в освобожденном специальном пуле Ошибка в Windows 10 [исправлено экспертами]

DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL и другие ошибки Blue Screen of Death могут вызвать много проблем на вашем компьютере. Эти ошибки обычно вызваны определенным программным обеспечением или неисправным оборудованием, и поскольку они могут вызвать очень много проблем, сегодня мы собираемся показать вам, как исправить эту ошибку в Windows 10. Как исправить ошибку DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL BSoD…

Ошибка System_pte_misuse в Windows 10 [исправлено экспертами]

SYSTEM_PTE_MISUSE Ошибка Blue Screen of Death может вызвать много проблем, но эту ошибку можно легко исправить, заменив неисправную оперативную память или разогнав ее.

Ошибка обновления Windows 10 0x80d06802 [исправлено экспертами]

Если ошибка обновления Windows 10 0x80d06802 продолжает препятствовать обновлению, запустите средство устранения неполадок Центра обновления Windows, сбросьте службы или перерегистрируйте файлы DLL.

Источник

Ошибка Windows 0x80072F7D — как исправить

Решено: ошибка Windows 0x80072F7D

Ошибка 0x80072F7D связана с Магазином Windows, и вот методы, которые помогут вам исправить ошибку и без проблем использовать Магазин Windows.

У этой конкретной ошибки есть несколько причин. Ниже приведены исправления для ошибки Windows 0x80072F7D.

Исправление №1 Первое, что вам нужно попробовать, — это запустить приложение Windows Troubleshooter. Откройте «Панель управления» и введите «Устранение неполадок» в поле поиска в правом верхнем углу.

В результатах поиска нажмите «Устранение неполадок», затем нажмите «Программа», а затем нажмите «Средство устранения неполадок совместимости программ».

Появится новое окно, и вам нужно нажать «Дополнительно» и установить флажок «Применить ремонт автоматически». Нажмите «Далее» и следуйте инструкциям.

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

Исправление №2 . Если устранение неполадок не помогло, вам необходимо выполнить сброс Магазина Windows. Нажмите «Windows + R», введите «Wsreset.exe» в появившемся окне и нажмите «Ввод».

Перезагрузите компьютер, и Магазин Windows будет сброшен, вы не должны получать ошибку Windows 0x80072F7D.

Если это не помогло, вы можете выполнить сброс Магазина Windows другим способом. Нажмите «Windows + X», «Приложения и компоненты», найдите и выберите нужные в «Microsoft Store», нажмите «Дополнительно», прокрутите вниз и нажмите «Сброс». Перезагрузите систему, и ошибка исчезнет.

Исправление №3 . Если описанные выше исправления не помогли вам, попробуйте изменить настройки Интернета. Нажмите «Win + I», Сеть и настройки, Центр управления сетями и общим доступом.

Щелкните «Свойства обозревателя», «Дополнительно», установите флажок «Использовать TLS 1.2» в разделе «Настройки».

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

Исправление №4 . Если ошибка Windows 0x80072F7D все еще вас беспокоит, то пора очистить файлы cookie и кеш, и вот как это сделать.

Откройте Microsoft Edge, нажмите на три точки в правом верхнем углу, настройки, нажмите «Выберите, что очистить».

Установите флажки для истории просмотров, файлов cookie и сохраненных данных веб-сайтов, а также для кэшированных данных и файлов.

Теперь нажмите кнопку «Очистить», перезагрузите компьютер, и ошибка будет исправлена.

Это все, что касается исправлений для ошибки Windows 0x80072F7D. Если вы сталкиваетесь с другими распространенными ошибками в Windows, посетите наш центр гайдов, в котором описаны наиболее часто встречающиеся ошибки и проблемы с ПК.

Источник

YuryL	#1 Отправлено: : 6 февраля 2014 г. 16:06:29(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 06.02.2014(UTC) Сообщений: 5 Откуда: Kirov	Доброго времени суток! На Windows 7 установлено следующее ПО КриптоПро: Версия ядра — 3.6.5364 KC1 Версия продукта — 3.6.7491 В реестр импортирован личный сертификат, через оснастку установлен в хранилище сертификатов. Далее js-скриптом пытаемся осуществить запрос к контент-провайдеру: Код: function start() { var strRequest = "SomeRequestHere"; WScript.Echo("Sending request..."); strResult = doRequest(strRequest); WScript.Echo(strResult); WScript.Echo("Done!"); } function doRequest(sReqBody) { var HTTPREQUEST_PROXYSETTING_DEFAULT = 0; var HTTPREQUEST_PROXYSETTING_DIRECT = 1; var HTTPREQUEST_PROXYSETTING_PROXY = 2; var strResult; try { // Create the WinHTTPRequest ActiveX Object. var WinHttpReq = new ActiveXObject("WinHttp.WinHttpRequest.5.1"); //Set Proxy Server if necessary WinHttpReq.SetProxy( HTTPREQUEST_PROXYSETTING_PROXY, "proxy.server.ru:3128", "*.e-i.ru"); //Create an HTTP request WinHttpReq.Open("POST", "https://www.rb-ei.com/cpuEnquiry.asp", true); //Select a client certificate //CN = Иванов Иван Иванович WinHttpReq.SetClientCertificate("CURRENT_USER\My\Иванов Иван Иванович"); WScript.Echo("Certificate is: " + "CURRENT_USER\My\Иванов Иван Иванович"); WinHttpReq.SetRequestHeader("Content-Type","application/x-www-form-urlencoded; Charset=windows-1251"); // Send the HTTP request WinHttpReq.Send(sReqBody); WinHttpReq.WaitForResponse(); WScript.Echo("Request status: " + WinHttpReq.StatusText); strResult = WinHttpReq.ResponseText; WScript.Echo(strResult); } catch (objError) { var err = objError + "n"; err += "WinHTTP returned error: " + (objError.number & 0xFFFF).toString() + "nn"; err += objError.description; WScript.Echo(err); } //Return the response text return strResult; } //Start the script start(); В ответ получаю ошибку: WinHTTP returned error: 12157. Ошибка поддержки безопасных каналов Причем заход через IE по адресу https://www.rb-ei.com/cpuEnquiry.asp успешен. Тот же пример через WinHTTPна любой другой адрес по https, не использующий криптопро также успешен. Служба поддержки контент-провайдера помочь не может, переадресовала на вас для решения вопроса.

YuryL	#2 Оставлено : 6 февраля 2014 г. 16:40:33(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 06.02.2014(UTC) Сообщений: 5 Откуда: Kirov	Дополню. Данная проблема проявляется только на ресурсах, которые требуют авторизацию на сертификатах. Если протестировать на ресурсе без авторизации, но использующих SSL на ГОСТах (пример https://icrs.nbki.ru/main/), то все ок.

Vladislav Osmanov	#3 Оставлено : 6 февраля 2014 г. 18:18:11(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 19.08.2009(UTC) Сообщений: 8 Поблагодарили: 4 раз в 4 постах	Юрий, добрый вечер. Судя по всему, это не совсем js, как Вы пишите, а Windows Script. Как он у вас выполняется? Попробуйте использовать подключение через XMLHttpRequest с исполнением кода в браузере Internet Explorer. Примерный код: Код: var request = new XMLHttpRequest(); request.open("GET", "https://www.rb-ei.com/cpuEnquiry.asp", false); request.setRequestHeader("Content-Type", "application/x-www-form-urlencoded; Charset=windows-1251"); request.send(sReqBody); if (request.readyState == 4) { if (request.status == 200) { //Success var svcResponse = request.responseText; } else { //Failure } } Браузер сам предложит Вам выбрать клиентский сертификат.
	WWW

YuryL	#4 Оставлено : 6 февраля 2014 г. 18:58:19(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 06.02.2014(UTC) Сообщений: 5 Откуда: Kirov	Автор: Vladislav Osmanov Юрий, добрый вечер. Судя по всему, это не совсем js, как Вы пишите, а Windows Script. Как он у вас выполняется? Попробуйте использовать подключение через XMLHttpRequest с исполнением кода в браузере Internet Explorer. Примерный код: Код: var request = new XMLHttpRequest(); request.open("GET", "https://www.rb-ei.com/cpuEnquiry.asp", false); request.setRequestHeader("Content-Type", "application/x-www-form-urlencoded; Charset=windows-1251"); request.send(sReqBody); if (request.readyState == 4) { if (request.status == 200) { //Success var svcResponse = request.responseText; } else { //Failure } } Браузер сам предложит Вам выбрать клиентский сертификат. Владислав, спасибо за ответ! Извиняюсь, конечно же WScript. Путем множества экспериментов пришел к такой зависимости: Если запустить данный скрипт из под Администратора (повышение привилегий), то запрос все таки проходит. Такое ощущение что без повышения прав компонент не может получить клиентский сертификат методом WinHttpReq.SetClientCertificate. И попутно появилась вторая проблема. Никак не могу использовать компонент для проверки ЭЦП: Код: function doVerify(strMessage) { try { var SignedData = new ActiveXObject("CAPICOM.SignedData"); SignedData.Verify( strMessage, false, 0); return SignedData.Content; } catch (objError) { var err = objError + "n"; err += "CAPICOM returned error: " + (objError.number & 0xFFFF).toString() + "nn"; err += objError.description; WScript.Echo(err); } } Ругается что компонент не найден. Устанавливал по инструкции с вашего сайта. У меня Windows 7 x64. Неужели под эту ОС нет возможности использовать данный компонент?

Максим Коллегин	#5 Оставлено : 6 февраля 2014 г. 19:01:45(UTC)
Статус: Сотрудник Группы: Администраторы Зарегистрирован: 12.12.2007(UTC) Сообщений: 6,254 Откуда: КРИПТО-ПРО Сказал «Спасибо»: 21 раз Поблагодарили: 658 раз в 582 постах	в 64-х битах нет CAPIcom, на аналогичный интерфейс предоставляет наш browser плагин. Отредактировано пользователем 6 февраля 2014 г. 19:02:26(UTC)  | Причина: Не указана
Знания в базе знаний, поддержка в техподдержке
	WWW

Андрей Писарев	#6 Оставлено : 6 февраля 2014 г. 23:35:35(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 26.07.2011(UTC) Сообщений: 11,750 Сказал «Спасибо»: 451 раз Поблагодарили: 1840 раз в 1423 постах	Автор: YuryL Ругается что компонент не найден. Устанавливал по инструкции с вашего сайта. У меня Windows 7 x64. Неужели под эту ОС нет возможности использовать данный компонент? И браузер IE используется х64?
Техническую поддержку оказываем тут Наша база знаний
	WWW

YuryL	#7 Оставлено : 7 февраля 2014 г. 10:21:48(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 06.02.2014(UTC) Сообщений: 5 Откуда: Kirov	Автор: Андрей * Автор: YuryL Ругается что компонент не найден. Устанавливал по инструкции с вашего сайта. У меня Windows 7 x64. Неужели под эту ОС нет возможности использовать данный компонент? И браузер IE используется х64? Андрей, я использую данные компоненты не в браузере, а в автономных скриптах. Т.е. фактически вызываются они console-mode.

YuryL	#8 Оставлено : 7 февраля 2014 г. 11:39:15(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 06.02.2014(UTC) Сообщений: 5 Откуда: Kirov	Автор: maxdm в 64-х битах нет CAPIcom, на аналогичный интерфейс предоставляет наш browser плагин. Пробую использовать ваш плагин. Контент-провайдер возвращает мне документ подписанные ЭЦП в кодировке BASE64. Сертификат отправителя с открытым ключом для ЭЦП я импортировал в хранилище сертификатов. Пробую снять ЭЦП так: Код: function doVerify(strSignedMessage) { var CADESCOM_CADES_X_LONG_TYPE_1 = 0x5d; try { var SignedData = new ActiveXObject("CAdESCOM.CadesSignedData"); SignedData.Verify( strSignedMessage, false, 0); return SignedData.Content; } catch (objError) { var err = objError + "n"; err += "CAdESCOM returned error: " + (objError.number & 0xFFFF).toString() + "nn"; err += objError.description; WScript.Echo(err); } } Данный код возвращает исключение: 4111 (Криптографическое сообщение не содержит всех запрошенных атрибутов). Что я делаю не так?

Пользователи, просматривающие эту тему

Guest (2)

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.

Откуда отправляешь? это не какое-то старое … которое с сертификатами не дружит?
Решил погуглить… так и есть

Как оказалось, далеко не все знают, что причина этих ошибок кроется в обновлении протокола шифрования на стороне сайта. Сейчас повсеместно начинает использоваться протокол TLS версии 1.2, поддержка которого в 1С полноценно начата с релиза 8.3.9

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

Но часто мне попадаются обработки работы с сайтом, которые используют средства Windows: объекты класса «WinHTTP.WinHTTPRequest.5.1» или «MSXML2.ServerXMLHTTP.6.0» и т.п. В этом случае необходимо активировать поддержку протокола TLS 1.2 в самой Windows.

Для этого достаточно внести в реестр следующие записи, после чего перезагрузить Windows:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2]

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Client]
«DisabledByDefault»=dword:00000000
«Enabled»=dword:00000001

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Server]
«DisabledByDefault»=dword:00000000
«Enabled»=dword:00000001

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsWinHttp]
«DefaultSecureProtocols»=dword:00000800

[HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionInternet SettingsWinHttp]
«DefaultSecureProtocols»=dword:00000800

Небольшое замечание к двум последним параметрам. В указанном коде указано значение 00000800 — это значение активирует протокол TLS 1.2 по умолчанию. Если необходимо использовать TLS 1.1 то значение необходимо заменить на 00000200, а если оба протокола, то на 00000A00.