Error 0x80090304 returned by initializesecuritycontext

avfly	#1 Оставлено : 9 декабря 2016 г. 18:34:11(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 09.12.2016(UTC) Сообщений: 5 Откуда: Пенза Сказал(а) «Спасибо»: 2 раз	Здравствуйте, мучаюсь уже неделю При входе на zakupki.gov.ru выдает «Невозможно отобразить эту страницу» Установлен КриптоПро CSP 3.6.7777 R4 Результат csptest -tlsc -server zakupki.gov.ru -v Код: csptest -tlsc -server zakupki.gov.ru -v 12 algorithms supported: [0] 0x660e [1] 0x6610 [2] 1.2.840.113549.3.4 (rc4) [3] 1.2.840.113549.3.7 (3des) [4] 1.3.14.3.2.7 (des) [5] 1.2.840.113549.2.5 (md5) [6] 1.3.14.3.2.26 (sha1) [7] 1.2.840.113549.1.1.1 (RSA) [8] 1.2.840.113549.1.9.16.3.5 (ESDH) [9] 0xae06 [10] 1.2.840.10040.4.1 (DSA) [11] 0x2203 Cipher strengths: 40..256 Supported protocols: 0x200a0 Protocol version: 3.1 ClientHello: RecordLayer: TLS, Len: 121 Cipher Suites: (00 81) (00 32) (00 31) (c0 14) (c0 13) (00 35) (00 2f) (c0 0a) (c0 09) (00 38) (00 0a) (00 13) (00 05) (00 04) 126 bytes of handshake data sent 1400 bytes of handshake data received **** Error 0x80090304 returned by InitializeSecurityContext (2) An error occurred in running the program. .WebClient.c:528:Error performing handshake. Error number 0x80090304 (2148074244). Не удается установить связь с локальным администратором безопасности Total: SYS: 0,047 sec USR: 0,000 sec UTC: 0,140 sec [ErrorCode: 0x80090304] На sberbank-ast.ru заходит отлично Криптопро 3.6 переустанавливал раз 5 (с cspclean’ом и перезагрузками) Самое интересное, что когда попробовал поставить Криптопро версии 3.9 с временной лицензией, то начал заходить на Закупки Установленное ПО: Windows 7 Профессиональная SP1 64-bit Internet Explorer 11.0.9600.18449 (версия обновления: 11.0.35 KB3185319) Kaspersky Endpoint Security 10 ViPNet Client 3.2 (11.18212) Dallas Lock 8.0-K Компьютер новый, в домене Заранее спасибо

Максим Коллегин	#2 Оставлено : 9 декабря 2016 г. 19:12:28(UTC)
Статус: Сотрудник Группы: Администраторы Зарегистрирован: 12.12.2007(UTC) Сообщений: 6,255 Откуда: КРИПТО-ПРО Сказал «Спасибо»: 21 раз Поблагодарили: 660 раз в 583 постах	А что мешает использовать CSP 3.9? Еще можно попробовать включить SSL 3.0 в свойтсвах браузера (или -proto 3 в csptest) При работе с VipNet на одном компьютере возможны различные проблемы совместимости.
Знания в базе знаний, поддержка в техподдержке
	WWW
1 пользователь поблагодарил Максим Коллегин за этот пост.	avfly оставлено 10.12.2016(UTC)

avfly	#3 Оставлено : 9 декабря 2016 г. 23:32:48(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 09.12.2016(UTC) Сообщений: 5 Откуда: Пенза Сказал(а) «Спасибо»: 2 раз	Автор: maxdm А что мешает использовать CSP 3.9? Еще можно попробовать включить SSL 3.0 в свойствах браузера (или -proto 3 в csptest) При работе с VipNet на одном компьютере возможны различные проблемы совместимости. Мешает использовать лицензия которая выдана для версии 3.6 и не подходит для версии 3.9)) SSL 3.0 включен, так же как и SSL 2.0 и TLS 1.0, вывод csptest с параметром -proto 3 не изменился(( VipNet в комплекте с Далласом и Каспером поставила организация, которая проводила аттестацию рабочего места. Единственно, что попробую это снять образ и удалить VipNet

basid	#4 Оставлено : 10 декабря 2016 г. 10:40:35(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 21.11.2010(UTC) Сообщений: 935 Сказал(а) «Спасибо»: 6 раз Поблагодарили: 126 раз в 114 постах	Автор: avfly VipNet в комплекте с Далласом и Каспером поставила организация, которая проводила аттестацию рабочего места. Единственно, что попробую это снять образ и удалить VipNet Вполне достаточно выключить поддержку MS Crypto API в настройках безопасности ViPNet-клиента. Если, вдруг, у вас четвёртая версия ViPNet, то там CSP «явно выделен» и нужно изменить состав установленных компонент ViPNet CSP.
1 пользователь поблагодарил basid за этот пост.	avfly оставлено 10.12.2016(UTC)

avfly	#5 Оставлено : 10 декабря 2016 г. 16:28:00(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 09.12.2016(UTC) Сообщений: 5 Откуда: Пенза Сказал(а) «Спасибо»: 2 раз	Автор: basid Автор: avfly VipNet в комплекте с Далласом и Каспером поставила организация, которая проводила аттестацию рабочего места. Единственно, что попробую это снять образ и удалить VipNet Вполне достаточно выключить поддержку MS Crypto API в настройках безопасности ViPNet-клиента. Если, вдруг, у вас четвёртая версия ViPNet, то там CSP «явно выделен» и нужно изменить состав установленных компонент ViPNet CSP. Поддержка работы VipNet CSP через MS CryptoAPI — была выключена Снял образ и удалил VipNet, затем переустановил КриптоПро 3.6.7777 и все прекрасно заработало Написал еще в поддержку ИнфоТеКС по VipNet’у, но они скорее всего ничего толкового не скажут( Так что, поставлю КриптоПро 3.9 с временной лицензией и буду трясти начальство после НГ на постоянку. Всем огромное спасибо. Тему можно закрывать Отредактировано пользователем 10 декабря 2016 г. 16:31:35(UTC)  | Причина: Не указана

Андрей Писарев	#6 Оставлено : 10 декабря 2016 г. 17:07:23(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 26.07.2011(UTC) Сообщений: 11,753 Сказал «Спасибо»: 451 раз Поблагодарили: 1840 раз в 1423 постах	Если возможно — попробуйте такую конфигурацию: КриптоПРО 4.0R2 + ViPNet 4.2
Техническую поддержку оказываем тут Наша база знаний
	WWW

avfly	#7 Оставлено : 10 декабря 2016 г. 17:15:28(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 09.12.2016(UTC) Сообщений: 5 Откуда: Пенза Сказал(а) «Спасибо»: 2 раз	Автор: Андрей * Если возможно — попробуйте такую конфигурацию: КриптоПРО 4.0R2 + ViPNet 4.2 Может на досуге и попробую ради интереса, но в данной ситуации мне смысла нет переходить еще и на ViPNet 4.2. Хочу попробовать поставить КриптоПРО 4.0R2 + ViPNet 3.2 и посмотреть что будет. О результатах отпишусь.

Андрей Писарев	#8 Оставлено : 10 декабря 2016 г. 21:22:59(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 26.07.2011(UTC) Сообщений: 11,753 Сказал «Спасибо»: 451 раз Поблагодарили: 1840 раз в 1423 постах	Автор: avfly Автор: Андрей * Если возможно — попробуйте такую конфигурацию: КриптоПРО 4.0R2 + ViPNet 4.2 Может на досуге и попробую ради интереса, но в данной ситуации мне смысла нет переходить еще и на ViPNet 4.2. Хочу попробовать поставить КриптоПРО 4.0R2 + ViPNet 3.2 и посмотреть что будет. О результатах отпишусь. Лучше забыть о ViPNet 3.х. 4.2 лучше по совместимости.
Техническую поддержку оказываем тут Наша база знаний
	WWW

avfly	#9 Оставлено : 12 декабря 2016 г. 16:55:03(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 09.12.2016(UTC) Сообщений: 5 Откуда: Пенза Сказал(а) «Спасибо»: 2 раз	Проблема решилась! Нужно было в ветке HKLMSYSTEMCurrentControlSetControlLsaSecurity Packages удалить параметр Schannel и после перезагрузки все заработало.

funt1k	#10 Оставлено : 13 июля 2018 г. 13:35:05(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 04.12.2012(UTC) Сообщений: 90 Сказал(а) «Спасибо»: 4 раз Поблагодарили: 1 раз в 1 постах	точно такая же ошибка только уже к 4.0 (самая новая 9944) после удаления параметра schannel вообще на все сайты перестает заходить по сертификату

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

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

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

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

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

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

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

Common Windows Security Errors

Description of Security Errors 80090302, 8009030D, 8009030E, 80090304, 80090308, 80090325, 80090326, 80090327, 80090331, 8009035D, 8009030F, 80090321

Date Entered: 06/10/2015 Last Updated: 04/09/2018

Errors

0x80090302

Possible Solutions

This can be done on any of the components that support SSL by using the SSLEnabledProtocols configuration setting. As an example setting the Icharge component to use TLS 1.2 would look like this

Please note the documentation linked above is specifically for the current .NET Editions. For other editions or older versions please reference the help file included with the product.

0x8009030D

Possible Solutions

Using OpenSSL, the certificate can be converted with the command:

openssl pkcs12 -export -passout pass:»» -in cert_key_pem.txt -out cert_key_out.pfx -name «My Certificate»

Then change the SSLCertStoreType to PFXFile in your code, before setting the SSLCertSubject.

0x8009030E

Possible Solutions

0x80090304

This error may to be related to Windows rejecting weak security. Microsoft KB 3061518 explains the issue. To summarize the article, simply set the ClientMinKeyBitLength DWORD value at the following location to 00000200 .

After a restart, if this corrects the issue, then it is an indication that the server’s certificate uses a DHE Key length that is too small and should be updated.

0x80090308

Possible Causes

0x80090325

The SSL client certificate specified in the request was not accepted by the server. During the SSL handshake the issuer certificates of the SSL client certificate are not included. In Linux the OpenSSLCADir configuration setting must be set to the directory where the hash files exist so the chain is included. In Windows the issuer certs must be in the Personal store. In Java, the issuer certificates are read from the PEM file.

0x80090326

Possible Solutions

0x80090327

This usually means that the server requires SSL client authentication and a new certificate is specified. Check the SSLStatus Event for details.

0x80090331

Most commonly, especially with Windows XP/Windows Server 2003, the client is probably old and doesn’t support the newer ciphers required by the server. Here is a list of ciphers supported in XP.

0x8009035D

Possible Solutions

0x8009030F or 0x80090321

These errors are known to occur on Windows 8.1 and Windows Server 2012 R2 when using TLS 1.2 and one of the following cipher suites:

• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

The aforementioned versions of Windows have a bug in their internal security implementations which, under very specific circumstances, can produce either the 0x80090321 (SEC_E_BUFFER_TOO_SMALL) error or the 0x8009030F (SEC_E_MESSAGE_ALTERED) error.

Due to the nature of the issue, we cannot provide a direct fix. However, you can work around these errors by doing one of the following things:

• Use our internal security API by passing the string «UseInternalSecurityAPI=True» to the Config() method. Our internal security API does not rely on the Windows security APIs, so it is not affected by the bug.
• Disable the two cipher suites mentioned above
• Disable support for TLS 1.2
• Upgrade your machine to a newer version of Windows

Источник

Веб — сервис интеграции

Уважаемый участник рынка ДМДК!

Инструкция по работе с интеграционным сервисом
размещена в разделе «Для бизнеса».

Доброго времени суток!
Установил обезличенный сертификат.
в SOAP пытаюсь установить соединение, но выдаёт ошибку сертификата:
2021.11.26 11:32:48 LOG5[5972:1472]: stunnel 4.18 on x86-pc-unknown
2021.11.26 11:32:48 LOG5[5972:1472]: Threading:WIN32 Sockets:SELECT,IPv6
2021.11.26 11:32:48 LOG5[5972:1472]: No limit detected for the number of clients
2021.11.26 11:32:48 LOG7[5972:1472]: FD 356 in non-blocking mode
2021.11.26 11:32:48 LOG7[5972:1472]: SO_REUSEADDR option set on accept socket
2021.11.26 11:32:48 LOG7[5972:1472]: https bound to 127.0.0.1:1500
2021.11.26 11:33:21 LOG7[5972:1472]: https accepted FD=360 from 127.0.0.1:54054
2021.11.26 11:33:21 LOG7[5972:1472]: Creating a new thread
2021.11.26 11:33:21 LOG7[5972:1472]: New thread created
2021.11.26 11:33:21 LOG7[5972:8548]: client start
2021.11.26 11:33:21 LOG7[5972:8548]: https started
2021.11.26 11:33:21 LOG7[5972:8548]: FD 360 in non-blocking mode
2021.11.26 11:33:21 LOG7[5972:8548]: TCP_NODELAY option set on local socket
2021.11.26 11:33:21 LOG5[5972:8548]: https connected from 127.0.0.1:54054
2021.11.26 11:33:21 LOG7[5972:8548]: FD 428 in non-blocking mode
2021.11.26 11:33:21 LOG7[5972:8548]: https connecting
2021.11.26 11:33:21 LOG7[5972:8548]: connect_wait: waiting 10 seconds
2021.11.26 11:33:21 LOG7[5972:8548]: connect_wait: connected
2021.11.26 11:33:21 LOG7[5972:8548]: Remote FD=428 initialized
2021.11.26 11:33:21 LOG7[5972:8548]: TCP_NODELAY option set on remote socket
2021.11.26 11:33:21 LOG7[5972:8548]: start SSPI connect
2021.11.26 11:33:21 LOG5[5972:8548]: try to read the client certificate
2021.11.26 11:33:21 LOG7[5972:8548]: open file c:stunnelclicer.cer with certificate
2021.11.26 11:33:21 LOG5[5972:8548]: CertFindCertificateInStore not find client certificate in store CURRENT_USER. Looking at LOCAL_MACHINE
2021.11.26 11:33:21 LOG3[5972:8548]: Error 0x80092004 returned by CertFindCertificateInStore

кто-то сталкивался с таким?
буду благодарен за помощь!

Источник

Stunnel error 0x8009035d returned by initializesecuritycontext 2

Добрый день! Уважаемые читатели и гости IT портала Pyatilistnik.org. В прошлый раз мы с вами устраняли ошибку подключения «Код ошибки 0x907. Расширенный код ошибки 0x0». В сегодняшней статье мы рассмотрим еще одну ошибку RDP, которая не дает людям любые подключения «Произошла неустранимая ошибка при обращении к закрытому ключу учетных данных TLS server. Код ошибки, возвращенный модулем шифрования: ошибка 0x8009030D. Внутреннее состояние ошибки«. Данную проблему я стал получать массово в декабре 2022. Давайте покажу куда нужно смотреть.

Описание ошибки 0x8009030D

У меня есть RDS ферма состоящая из 50 RDSH хостов, в какой-то момент люди начали массово на двух хостах получать ошибку «An internal error has occurred». Я долго искал проблему, и таки отыскал ее.

Ей оказалась ошибка появляющаяся каждый раз при попытке подключения ID Schannel 36870:

Вот так это массово выглядит.

В 99% случаев у вас просто не хватает прав на доступ к нужному SSL сертификату, который используется при RDP сессии.

Устранение ошибки ID 36870

Как я и писал ранее, чтобы убрать ошибку 0x907, я на всех участниках RDS ферму, установил нормальный Wildcard сертификат. Все стало нормально. Но, то что теперь я стал получать ошибку с кодом 0x8009030D, стало означать, с проблемой прав доступа к файлу. То есть у учетной записи NETWORK SERVICE отсутствуют разрешения на файл в C:ProgramDataMicrosoftCryptoRSAMachineKey.

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

Для того чтобы понять, что происходит я вам советую скачать утилиту из пакета Sysinernals под названием Process Monitor.

• ✅Далее делаем себе фильтр по событию 36870, чтобы мониторить его появление

• ✅И запускаем Procmon.exe или Procmon64.exe, чтобы спарсить текущие события. Как только событие появилось, вам нужно остановить захват (CTRL+E) и сохранить этот лог в CSV файл.

Далее вам нужно поискать события подобные этому:

Как видно, учетная запись NETWORK SERVICE не смогла прочитать ключ eed523a12125737e6733ccef353672ce_02129252-b210-4f5d-a8a1-2febf0b00564.

Как предоставить права на сертификат

• ✅Нажмите сочетание клавиш Win+R и вызовите оснастку mmc.

Далее Вам нужно нажать CTR:+M. Найдите оснастку «Сертификаты» и переместите ее вправо. Там выберите пункт «Учетной записи компьютера«.

Кажем, что это будет локальный компьютер, но можно сделать и удаленного, если нет доступа по RDP.

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

Далее в открывшемся ACL вам нужно дать права чтения для NETWORK SERVICE.

• ✅Второй метод, это использовать утилиту командной строки:

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

На этом у меня все. Ошибку я устранил, уровень защищенности сохранил. С вами был Иван Сёмин, автор и создатель IT портала Pyatilistnik.org.

Сброс разрешения для папки MachineKeys

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

icacls C:ProgramDataMicrosoftCryptoRSAMachineKeys /t /c > c:tempBeforeScript_permissions.txt

takeown /f «C:ProgramDataMicrosoftCryptoRSAMachineKeys» /a /r

icacls C:ProgramDataMicrosoftCryptoRSAMachineKeys /t /c /grant «NT AUTHORITYSystem:(F)»

icacls C:ProgramDataMicrosoftCryptoRSAMachineKeys /t /c /grant «NT AUTHORITYNETWORK SERVICE:(R)»

icacls C:ProgramDataMicrosoftCryptoRSAMachineKeys /t /c /grant «BUILTINAdministrators:(F)»

icacls C:ProgramDataMicrosoftCryptoRSAMachineKeys /t /c > c:tempAfterScript_permissions.txt

Где хранится самоподписный сертификат в реестре

Это больше для себя, где лежит отпечаток сертификата:

Источник

Stunnel error 0x8009035d returned by initializesecuritycontext 2

Важное замечание: Если ОС Windows используется в качестве клиента КриптоПро HSM 2.0 и ключ доступа к HSM записан на смарткарте или токене, то не рекомендуется подключение к этой ОС Windows по RDP, поскольку локально подключенные к компьютеру с ОС Windows считыватели смарткарт/токенов не будут доступны в RDP-сессии.

Диагностика соединения с HSM 2.0
диагностика с помощью telnet или netcat
доступ к web-странице Администратора:
telnet 443
доступ к каналу К2:
telnet 1501
где это IP адрес HSM 2.0
Причина возможного сбоя: HSM в состоянии Inactive, сетевая проблема или не настроены правила FireWall на HSM 2.0
примечание: на ОС Astra Linux Smolensk 1.5 — 1.6 по умолчанию не установлены пакеты telnet и netcat (можно установить с диска разработчика Astra Linux)
Пример использования:
telnet 192.168.26.2 1501
nc -v 192.168.26.2 1501
1. проверка провайдера
   windows : start /b csptest -enum -provider «Crypto-Pro GOST R 34.10-2012 HSM CSP» -provtype 80 -info для треевого провайдера, для сервисного необходимо в -provider указывать «Crypto-Pro GOST R 34.10-2012 HSM Svc CSP»
   *nix : /opt/cprocsp/bin/АРХИТЕКТУРА/csptestf -enum -provider «Crypto-Pro GOST R 34.10-2012 HSM CSP» -provtype 80 -info
   должно вернуться [ErrorCode: 0x00000000], иначе см п.2-3

1. на страничке не работают пункты меню и отображается строка вида:
   -1 -1 0 0 0 0 0 0 false false false
   Причина:
   Используется браузер отличный от Internet Explorer или в IP адрес HSM 2.0 не добавлен в «Доверенные узлы» и в «Просмотр в режиме совместимости» браузера Internet Explorer

   Источник

   Исправление: ошибка проверки подлинности «0x80090304» при попытке установления сеанса протокола удаленного рабочего СТОЛА на устройстве под управлением Windows Embedded Compact 7

   Симптомы

   Рассмотрим следующий сценарий:

   Имеется устройство на базе Windows Embedded Compact 7.

   У вас есть раздел реестра SendLMResponse, задать следующим образом:

   Расположение в реестре: HKEY_LOCAL_MACHINECommSecurityProvidersNTLM
   Имя DWORD: SendLMResponse
   Значение DWORD: 00000001

   При попытке установить сеанс с сервером, на котором запущен Windows Server 2008 и имеет параметры безопасности по умолчанию протокол удаленного рабочего стола (RDP).

   В этом случае устройство на базе Windows Embedded Compact 7 не удается установить сеанс RDP, и сообщение об ошибке проверки подлинности 0x80090304.

   Решение

   Сведения об обновлении программного обеспечения

   Обновление поддерживаемого программного обеспечения от корпорации Майкрософт как Обновления Windows Embedded Compact 7 месяц май 2013. В разделе «Сведения о файле» имя файла пакета включает тип процессора.

   Примечание. Это Windows Embedded Compact 7 ежемесячное обновление доступно для загрузки на следующий веб-узел центра загрузки корпорации Майкрософт:

   Предварительные условия

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

   Необходимость перезагрузки

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

   В меню Построение выберите пункт Очистить решениеи выберите команду Построить решение.

   В меню Построение выберите команду Перестроить решение.

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

   Сведения о замене обновлений

   Это обновление не заменяет других обновлений.

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

   Файлы, включенные в данный пакет обновления

   Источник

   Error 0x80090304 returned by initializesecuritycontext

   This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

   

   Answered by:

   

   Question

   

   

   I have a couple of HP dc7800 computers with Intel’s AMT/vPro that I’d like to provision with SCCM 2012. The installed firmware version is 3.2.10 which is a supported version according to the documentation [1]. Provisioning of newer clients (5.2.x upwards) is successful, so I can rule out all the usual suspects like the provisioning certificate from GoDaddy, our internal CA, DHCP options, etc. Provisioning with SCCM 2007 of both 3.2.x and 5.x AMT devices is also still successful.

   The amtopmgr.log repeatedly shows the following entries:

   After some investigation with Wireshark, I’ve found out that SCCM tries connect with TLSv1 to the AMT device. The response from the device is immediately an SSL alert (internal error). Using OpenSSL, I could connect to the device if I explicitly told it to use SSLv3. This leads me to believe that the 3.2.x firmware cannot handle TLSv1 correctly and SCCM never tries to connect with SSLv3 after a failure.

   So the question is: How can I get SCCM 2012 to provision these devices?

   Источник

   Error 0x80090304 returned by initializesecuritycontext

   Нужна Ваша помощь..

   1. Requesting and Installing the AMT Provisioning Certificate from an Internal CA

   (сертификат установлен на Primary Site SCCM)

   2. Preparing the Web Server Certificates for AMT-Based Computers
   http://technet.microsoft.com/en-us/library/dd252737.aspx#BKMK_AMTwebserver2008

   3.Хэш корневого сертификата, внутреннего цетра сертификации добавил на AMT станцию (version, 7.1)

   4. Добавил роли сервера Enrollment point, Out of band service point

   Также задал AMT Provisionin and Discovery accounts (пароль, который задан на пк с AMT)

   Добавил пк в коллекцию, включил Enable provisionin for AMT-based computers

   Запустил Discover AMT status

   В результате статус «Not Supported»

   В лог файле amtopmgr.log

   oobmgmt.log

   Есть ошибкы в статусе компонента SMS_AMT_OPERATION_MANAGER:

   А также появляеться ошибка:

   Вчера, после перегрузки Primary Site статус изменился на «Detected»

   В лог файле amtopmgr.log:

   Но опять изменился на «Not Supported»..

   Можете подсказать что делать..

   Ответы

   

   

   Все ответы

   

   

   Подключил другой комп PC-AMT2 (AMT v. 5.2.0)

   Обнулил BIOS, задал только пароль и хеш сертификата.

   После discovery статус «Detected»

   В лог файле amtopmgr.log :

   DoWSManDiscovery failed with user name: admin. — AMT Provisionin and Discovery accounts (пароль, который задан на пк с AMT)

   Почему оно ругается на пароль.

   

   

   Может проблема с AMT Provisioning Certificate

   правильно задано Идентификатор объекта: 2.16.840.1.113741.1.2.3 ??

   

   

   На DHCP3 задано опции:

   option domain-name
   option domain-name-servers

   

   

   А вы коллекцию создали, создали запрос для обнаруженных компьютеров, разрешили для этой коллекции Out-of-band? В созданный OU обнаруженные компьютеры попадают?

   Vladimir Zelenov | http://systemcenter4all.wordpress.com

   

   

   А вы коллекцию создали, создали запрос для обнаруженных компьютеров, разрешили для этой коллекции Out-of-band? В созданный OU обнаруженные компьютеры попадают?

   Vladimir Zelenov | http://systemcenter4all.wordpress.com

   Добавил пк в коллекцию, включил Enable provisionin for AMT-based computers
   Запустил Discover AMT status

   В OU Out of Band Management Controllers компьютеры попадают.

   

   

   Волнуют эти две ошибки:

   Когда перейти в браузере по https://10.10.10.11:16993 Ошибка:

   Аутентификация на основе сертификата завершилась со сбоем
   Этот сервер требует сертификат для аутентификации и не принял сертификат, отправленный браузером. Срок действия вашего сертификата, возможно, истек, или сервер не доверяет издателю. Можно повторить попытку, используя другой сертификат (при его наличии), или получить допустимый сертификат.
   Ошибка 117 (net::ERR_BAD_SSL_CLIENT_AUTH_CERT): Недопустимый сертификат SSL для аутентификации клиента.

   Задал AMT Provisionin and Discovery accounts (пароль, который задан на пк с AMT)

   

   

   Вы выдираете строки из лога, вполне возможно, что всё нормально. Лучше выложите на скайдрайв лог целиком.

   Vladimir Zelenov | http://systemcenter4all.wordpress.com

   

   

   Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется «как есть» без каких-либо гарантий

   

   

   Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется «как есть» без каких-либо гарантий

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

   

   

   Вы выдираете строки из лога, вполне возможно, что всё нормально. Лучше выложите на скайдрайв лог целиком.

   Vladimir Zelenov | http://systemcenter4all.wordpress.com

   Лог amtopmgr.log загрузил:

   На компьютере прописан хеш сертификата, размер ключа 2048Bits

   

   

   

   

   На сервере Out of band service point

   Так и должно быть? На сервере должен быть открыт порт 9971? Firewall — отключен.

   

   

   

   

   Vladimir Zelenov | http://systemcenter4all.wordpress.com

   

   

   На сервере Out of band service point

   Так и должно быть? На сервере должен быть открыт порт 9971? Firewall — отключен.

   Port TCP 9971 is no longer used to connect the AMT management controller to the out of band service point to provision computers for AMT.

   Так и должно быть.

   

   

   Честно говоря пока нет мыслей. У меня в текущий момент нет ConfigMgr 2012 с компьютерами AMT. Что-то подсказать пока не могу. Может через неделю что нибудь решится.

   Vladimir Zelenov | http://systemcenter4all.wordpress.com

   

   

   В документации по Configuration Manager 2007 указано:

   Certification Authority Requirements for Out of Band Management

   The certificate deployment requirements for AMT provisioning include the use of automatically approving certificates so that the site server can request and immediately retrieve a certificate for each AMT-based computer that it provisions. To help secure automatic approval, security controls are required to help ensure that only trusted computers request certificates. The use of certificate templates with a Microsoft enterprise certification authority (CA) provides this level of security control by having access level controls on the certificate templates. Although you can automatically approve all certificate requests with a stand-alone Microsoft CA, this solution does not offer any security controls and is not supported with out of band management in Configuration Manager 2007 SP1 and later.

   A Microsoft enterprise CA supports the following versions of certificate templates:

   • Version 1 was introduced with Windows Server 2000 and is supported with all server editions of Windows Server 2003 and Windows Server 2008.
   • Version 2 was introduced with Windows Server 2003 and is supported with the Enterprise and Datacenter Editions of Windows Server 2003 and Windows Server 2008. Version 2 templates are not supported with the Standard Editions of Windows Server 2003 and Windows Server 2008.
   • Version 3 was introduced with Windows Server 2008 and is supported with the Enterprise and Datacenter Editions of Windows Server 2008. However, these certificate templates create certificates that are not compatible with Configuration Manager and must not be used for either out of band management or native mode.

   В документации по ConfigMgr 2012 таких ограничений не нашел. Обязательно использовать только Version 2, или можно Version 3 ?

   Источник

You may hit a problem when trying to provision the vPro giving you the logs below in the “C:Program FilesMicrosoft Configuration ManagerLogsamtopmgr.log”.

>>>>>>>>>>>>>>>Provision task begin<<<<<<<<<<<<<<<    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
AMT Provision Worker: Wakes up to process instruction files    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    1020 (0x03FC)
Provision target is indicated with SMS resource id. (MachineId = 3 SIBER1_USER12.INTANBK.local)    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
AMT Provision Worker: Wait 20 seconds…    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    1020 (0x03FC)
Start to send a basic machine property creation request to FDM. (MachineId = 3)    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
AMT Provision Worker: Wakes up to process instruction files    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    1020 (0x03FC)
AMT Provision Worker: Wait 20 seconds…    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    1020 (0x03FC)
CStateMsgReporter::DeliverMessages – Queued message: TT=1201 TIDT=0 TID=’Fill Machine Property’ SID=1 MUF=0 PCNT=5, P1=’SIBER1_USER12′ P2=’89130000BFF59769BE24FE3D5C9EFE8CA4ED52E174D505ED49B9898DFE7710DB693A9CF178289D6DBA3E8DF1140000004200000048000000036600000000000080F20C247D2E8DD87A9E3D27CB55024D423AE263B22BD7FA742CDC9B10ED65242CC910BA0D3F471CDFA92CEE12D0277684A473F32BFECC47CCD464D7FD733DEFB7B45C3D44B7CE972E2A’ P3=’SIBER1_USER12.INTANBK.local’ P4=’admin’ P5=’F66656326507D0F050EA3DEC64C0F331A9DC758F’    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
CStateMsgReporter::DeliverMessages – Created state message file: C:Program FilesMicrosoft Configuration Managerinboxesauthstatesys.boxincoming6ok985qv.SMX    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
Warning: Currently we don’t support mutual auth. Change to TLS server auth mode.    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
The provision mode for device SIBER1_USER12.INTANBK.local is 1.    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
Attempting to establish connection with target device using SOAP.    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
Found matched certificate hash in current memory of provisioning certificate    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
Create provisionHelper with (Hash: 9D70092A4BB7EC5065A769EE2C67324132B8FF40)    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
Set credential on provisionHelper…    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
Try to use provisioning account to connect target machine SIBER1_USER12.INTANBK.local…    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
Error 0x80090304 returned by InitializeSecurityContext during follow up TLS handshaking with server.    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
**** Error 0x17fb95c returned by ApplyControlToken    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
Fail to connect and get core version of machine SIBER1_USER12.INTANBK.local using provisioning account #0.    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
Try to use default factory account to connect target machine SIBER1_USER12.INTANBK.local…    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
Error 0x80090304 returned by InitializeSecurityContext during follow up TLS handshaking with server.    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
**** Error 0x17fb95c returned by ApplyControlToken    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
Fail to connect and get core version of machine SIBER1_USER12.INTANBK.local using default factory account.    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
Try to use provisioned account (random generated password) to connect target machine SIBER1_USER12.INTANBK.local…    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
Error 0x80090304 returned by InitializeSecurityContext during follow up TLS handshaking with server.    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
**** Error 0x17fb95c returned by ApplyControlToken    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
Fail to connect and get core version of machine SIBER1_USER12.INTANBK.local using provisioned account (random generated password).    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
Error: Device internal error. Check Schannel, provision certificate, network configuration, device. (MachineId = 3)    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)
Error: Can NOT establish connection with target device. (MachineId = 3)    SMS_AMT_OPERATION_MANAGER    20/3/2009 3:24:24 PM    576 (0x0240)

However searching for it on the internet would lead you to a technet site as below to indicate that this error is due to the certificate used is above 2048 bit. Note you may be using a 2048 bit certificate and still get this error. http://technet.microsoft.com/en-us/library/cc161803.aspx

“Configuration Manager Fails to Provision Computers for AMT Because the Root Certification Authority Certificate Has a Key Length of Greater Than 2048 Bits

As listed in Prerequisites for Out of Band Management and documented in Certificate Requirements for Out of Band Management, AMT-based computers cannot support a root certification authority certificate that has a key length of greater than 2048 bits. In this scenario, provisioning will fail with the following errors in the log file <ConfigMgrInstallationPath>LogsAmtproxymgr.log:

Error 0x80090304 returned by InitializeSecurityContext during follow up TLS handshaking with server.

**** Error 0x193b95c returned by ApplyControlToken

Fail to connect and get core version of machine <IP address of computer to provision>

Solution

Use a certification authority that has a root certificate with a key length of 2048 bits or less.”

Further searching lead me to this solution. On the DHCP server ensure that scope option 006 and scope option 015 is populated with the correct information.

Enjoy!!!

I have an application that uses the System.Net.Security.SslStream class to make a secure connection to a server. On Windows 7 and Windows 8/8.1, this works fine. On Windows 10, the call to SslStream.AuthenticateAsClient throws an exception — «AuthenticationException: A call to SSPI failed, see inner exception». The inner exception is «Win32Exception: The Local Security Authority cannot be contacted». This is not specific to one Windows 10 machine.

I thought that it might have something to do with the length of the public key for the server certificate being 512 bits, so I created my own self-signed certificate with a 512 bit public key and tested SslStream.AuthenticateAsClient with it on the Windows 10 machine. This worked fine.

I am trying to figure out what changed in Windows 10 that is causing this to no longer work. Looking at the log generated by System.Net and a capture from Wireshark, I see that the client receives the SERVER HELLO, CERTIFICATE, and SERVER DONE messages, and then the client closes the connection. In the System event log, there is an error logged by SChannel — «A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 40. The Windows SChannel error state is 813.» Apparently TLS error code 40 is a handshake failure, but I have not been able to find anything about SChannel error state 813.

By looking at the SSL handshake in Wireshark, I have found that the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite is being used. When I connected to the test server that I created (which works with a 512 bit public key certificate), the TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA cipher suite is used. Is there an issue with using TLS_RSA_WITH_3DES_EDE_CBC_SHA on Windows 10?

Произошла ошибка проверки подлинности. Указанная функция не поддерживается

После установки обновления KB4103718 на моем компьютере с Windows 7 я не могу удаленно подключится к серверу c Windows Server 2012 R2 через удаленный рабочий стол RDP. После того, как я указываю адрес RDP сервера в окне клиента mstsc.exe и нажимаю «Подключить», появляется ошибка:

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

Указанная функция не поддерживается.
Удаленный компьютер: computername

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

Ответ

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

В своей проблеме вы не одиноки. Данная ошибка может появится в любой операционной системе Windows или Windows Server (не только Windows 7). У пользователей английской версии Windows 10 при попытке подключится к RDP/RDS серверу аналогичная ошибка выглядит так:

The function requested is not supported.

Remote computer: computername

Ошибка RDP “An authentication error has occurred” может появляться и при попытке запуска RemoteApp приложений.

Почему это происходит? Дело в том, что на вашем компьютере установлены актуальные обновления безопасности (выпущенные после мая 2018 года), в которых исправляется серьёзная уязвимость в протоколе CredSSP (Credential Security Support Provider), использующегося для аутентификации на RDP серверах (CVE-2018-0886) (рекомендую познакомится со статьей Ошибка RDP подключения: CredSSP encryption oracle remediation). При этом на стороне RDP / RDS сервера, к которому вы подключаетесь со своего компьютера, эти обновления не установлены и при этом для RDP доступа включен протокол NLA (Network Level Authentication / Проверку подлинности на уровне сети). Протокол NLA использует механизмы CredSSP для пре-аутентификация пользователей через TLS/SSL или Kerberos. Ваш компьютер из-за новых настроек безопасности, которые выставило установленное у вас обновление, просто блокирует подключение к удаленному компьютеру, который использует уязвимую версию CredSSP.

Что можно сделать для исправления эту ошибки и подключиться к вашему RDP серверу?

Отключение NLA для протокола RDP в Windows

Если на стороне RDP сервера, которому вы подключаетесь, включен NLA, это означает что для преаутентификации RDP пользователя используется CredSPP. Отключить Network Level Authentication можно в свойствах системы на вкладке Удаленный доступ (Remote), сняв галку «Разрешить подключения только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети / Allow connection only from computers running Remote Desktop with Network Level Authentication (recommended)» (Windows 10 / Windows 8).

В Windows 7 эта опция называется по-другому. На вкладке Удаленный доступ нужно выбрать опцию «Разрешить подключения от компьютеров с любой версией удаленного рабочего стола (опасный) / Allow connections from computers running any version of Remote Desktop (less secure)».

Также можно отключить проверку подлинности на уровне сети (NLA) с помощью редактора локальной групповой политики — gpedit.msc (в Windows 10 Home редактор политик gpedit.msc можно запустить так) или с помощью консоли управления доменными политиками – GPMC.msc. Для этого перейдите в разделе Конфигурация компьютера –> Административные шаблоны –> Компоненты Windows –> Службы удаленных рабочих столов – Узел сеансов удаленных рабочих столов –> Безопасность (Computer Configuration –> Administrative Templates –> Windows Components –> Remote Desktop Services – Remote Desktop Session Host –> Security), отключите политику Требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети (Require user authentication for remote connections by using Network Level Authentication).

Также нужно в политике «Требовать использования специального уровня безопасности для удаленных подключений по протоколу RDP» (Require use of specific security layer for remote (RDP) connections) выбрать уровень безопасности (Security Layer) — RDP.

Для применения новых настроек RDP нужно обновить политики (gpupdate /force) или перезагрузить компьютер. После этого вы должны успешно подключиться к удаленному рабочему столу сервера.

Источник

Ошибка При Проверке Подлинности Код 0x80090304 Windows xp

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

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

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

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

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

Вы абсолютно правы в том, что бессмысленно решать проблему удалением обновлений Windows, ведь вы тем самым подвергаете свой компьютер риску эксплуатации различных уязвимостей, которые закрывают патчи в данном обновлении.
Ошибка При Проверке Подлинности Код 0x507 Rdp Windows Xp|ошибка При Проверке Подлинности Код 0x507 Windows Xp|ошибка При Проверке Подлинности Код 0x80090304 xpОшибка RDP «An authentication error has occurred» может появляться и при попытке запуска RemoteApp приложений.

После установки обновления KB4103718 на моем компьютере с Windows 7 я не могу удаленно подключится к серверу через удаленный рабочий стол RDP. После того, как я указываю адрес RDP сервера в окне клиента mstsc.exe и нажимаю «Подключить», появляется ошибка:

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

В своей проблеме вы не одиноки. У пользователей английской версии Windows при попытке подключится к RDP/RDS серверу появляется ошибка:
В Windows 7 эта опция называется по-другому. На вкладке Удаленный доступ нужно выбрать опцию » Разрешить подключения от компьютеров с любой версий удаленного рабочего стола (опасный) / Allow connections from computers running any version of Remote Desktop (less secure)»

Указанная функция не поддерживается.

Отключение NLA для протокола RDP в Windows

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

Для применения настроек RDP нужно обновить политики gpupdate force или перезагрузить компьютер.

Но этот гигант не останавливается на достигнутом и собирается догнать своего прямого конкурента CSTRIX, возможностями которого пользуются уже более 15 лет.

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

Компьютер может не подключаться к удаленному рабочему столу еще по нескольким, банальным причинам:
С выходом Windows Server, появилась возможность устанавливать защиту на сетевом уровне. Но, более поздние версии ОС эту возможность не получили. Теперь, при подключении к такому серверу, удаленный компьютер требует проверки подлинности на уровне сети, которую ПК не поддерживает.

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

Источник

Ошибка при проверке подлинности код 0x80090304 rdp windows xp

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

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

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

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

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

Назначение CredSSP

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

Windows SSP

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

Причины ошибки шифрования 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 в Windows через NLA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Ошибка при проверке подлинности код 0x80090304 rdp windows xp

Администраторам серверов на базе Windows 2008 возможно придется столкнуться со следующей проблемой:

Подключение по rdp протоколу к любимому серверу со станции Windows XP SP3 проваливается со следующей ошибкой:

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

И хотя многообещающая Win7 грозит со временем заменить свою бабушку WinXP, еще годик-другой проблема будет актуальной.

Вот что необходимо предпринять для включения механизма проверки подлинности на сетевом уровне:

Открываем редактор реестра.

Ветка HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa

Открываем параметр Security Packages и ищем там слово tspkg. Если его нет, добавляем к уже существующим параметрам.

Ветка HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProviders

Открываем параметр SecurityProviders и добавляем к уже существующим провайдерам credssp.dll, если таковой отсутствует.

Закрываем редактор реестра.

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

Подключение к удаленному рабочему столу

Ошибка при проверке подлинности(код 0×507)

Если у вас все равно выдает: Ошибка при проверке подлинности(код 0×507)
откройте Internet Explorer, зайдите в меню Справка → О программе. Если в строке «Стойкость шифра» стоит разрядность 0, это значит, что недоступно подключение к защищенным веб-узлам. Необходимо переустановить программу КриптоПро.
Нажмите Пуск — Настройка — Панель управления
Два раза кликните по ярлычку «Установка и удаление программ»
в появившемся окне выберите КриптоПро CSP и нажмите Удалить

Источник

Ошибка при подключении по 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. Для этого достаточно в Свойствах системы, на вкладке удалённые подключения снять соответствующую галку «Разрешить подключения только с компьютеров, на которых работает удалённый рабочий стол с проверкой подлинности на уровне сети»:

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

Источник