Error 0x80090304 returned by acquirecredentialshandle stunnel

wraithik	#1 Оставлено : 25 февраля 2022 г. 17:13:22(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 25.02.2022(UTC) Сообщений: 5	Установлен stunnel Содержимое конф-файла Сертификат получен в налоговой, он обезличенный. В логах stunnel 2022.02.25 17:00:31 LOG5[4288:5908]: try to read the client certificate 2022.02.25 17:00:31 LOG7[4288:5908]: open file c:stunnelcert.cer with certificate 2022.02.25 17:00:31 LOG3[4288:5908]: **** Error 0x80090304 returned by AcquireCredentialsHandle 2022.02.25 17:00:31 LOG3[4288:5908]: Credentials complete 2022.02.25 17:00:31 LOG3[4288:5908]: Error creating credentials Сертификат установлен в личное хранилище. КриптоПро 5.0.120. Подскажите что с этим делать.

Александр Лавник	#2 Оставлено : 25 февраля 2022 г. 17:17:09(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 30.06.2016(UTC) Сообщений: 3,205 Сказал «Спасибо»: 53 раз Поблагодарили: 723 раз в 675 постах	Автор: wraithik Установлен stunnel Содержимое конф-файла Сертификат получен в налоговой, он обезличенный. В логах stunnel 2022.02.25 17:00:31 LOG5[4288:5908]: try to read the client certificate 2022.02.25 17:00:31 LOG7[4288:5908]: open file c:stunnelcert.cer with certificate 2022.02.25 17:00:31 LOG3[4288:5908]: **** Error 0x80090304 returned by AcquireCredentialsHandle 2022.02.25 17:00:31 LOG3[4288:5908]: Credentials complete 2022.02.25 17:00:31 LOG3[4288:5908]: Error creating credentials Сертификат установлен в личное хранилище. КриптоПро 5.0.120. Подскажите что с этим делать. Здравствуйте. Сертификат установлен в хранилище «Личное» компьютера (не текущего пользователя) с привязкой к ключевому контейнеру? На ключе не установлен пин-код?
Техническую поддержку оказываем тут Наша база знаний

wraithik	#3 Оставлено : 25 февраля 2022 г. 17:21:17(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 25.02.2022(UTC) Сообщений: 5	Нет. В носитель заходит без пин-кода через протестировать. Как точно проверить что пароля нет или удалить? Отредактировано пользователем 25 февраля 2022 г. 17:26:24(UTC)  | Причина: Не указана

Александр Лавник	#4 Оставлено : 25 февраля 2022 г. 17:30:32(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 30.06.2016(UTC) Сообщений: 3,205 Сказал «Спасибо»: 53 раз Поблагодарили: 723 раз в 675 постах	Автор: wraithik Нет. В носитель заходит без пин-кода через протестировать. Как точно проверить что пароля нет или удалить? Какой ключевой носитель?
Техническую поддержку оказываем тут Наша база знаний

wraithik	#5 Оставлено : 25 февраля 2022 г. 17:41:03(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 25.02.2022(UTC) Сообщений: 5	Проверка завершена успешно ошибок не обнаружено Контейнер закрытого ключа пользователя Имя b051432a-d2df-4eed-8cd7-123feaa3a393 Уникальное имя SCARDrutoken_lt_3f5461a4A00AF21 FQCN \.Aktiv Rutoken lite 0b051432a-d2df-4eed-8cd7-123feaa3a393 Проверка целостности контейнера успешно Ключ обмена доступен длина ключа 512 бит экспорт открытого ключа успешно вычисление открытого ключа успешно импорт открытого ключа успешно подпись успешно проверка успешно создание ключа обмена успешно экспорт ключа запрещен алгоритм ГОСТ Р 34.10-2012 DH 256 бит ГОСТ Р 34.10 256 бит, параметры обмена по умолчанию ГОСТ Р 34.11-2012 256 бит ГОСТ 28147-89, параметры шифрования ТК26 Z сертификат в контейнере соответствует закрытому ключу имя сертификата ООО «ГРИФОН» субъект ИНН ЮЛ=6154096952, ОГРН=1056154061754, E=grifon_jurwelir@mail.ru, C=RU, S=61 Ростовская область, L=Таганрог, STREET=»ул. Поляковское шоссе, д. 17″, O=»ООО «»ГРИФОН»»», OU=615401001, CN=»ООО «»ГРИФОН»»» поставщик E=uc@nalog.ru, ОГРН=1047707030513, ИНН=007707329152, C=RU, S=77 Москва, L=г. Москва, STREET=»ул. Неглинная, д. 23″, OU=УЦ ЮЛ, O=Федеральная налоговая служба, CN=Федеральная налоговая служба действителен с 25 февраля 2022 г. 12:32:50 действителен по 25 мая 2023 г. 12:42:50 ключ действителен с 25 февраля 2022 г. 12:32:50 ключ действителен по 25 мая 2023 г. 12:32:50 серийный номер 7714 A000 47AE 739B 4C8E 244E 3E2D 4903 сертификат в хранилище My субъект ИНН ЮЛ=6154096952, ОГРН=1056154061754, E=grifon_jurwelir@mail.ru, C=RU, S=61 Ростовская область, L=Таганрог, STREET=»ул. Поляковское шоссе, д. 17″, O=»ООО «»ГРИФОН»»», OU=615401001, CN=»ООО «»ГРИФОН»»» cсылка на закрытый ключ SCARDrutoken_lt_3f5461a4A00AF21; Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider#80; dwFlags: 0x00000000; dwKeySpec: AT_KEYEXCHANGE#1 AddressBook субъект ИНН ЮЛ=6154096952, ОГРН=1056154061754, E=grifon_jurwelir@mail.ru, C=RU, S=61 Ростовская область, L=Таганрог, STREET=»ул. Поляковское шоссе, д. 17″, O=»ООО «»ГРИФОН»»», OU=615401001, CN=»ООО «»ГРИФОН»»» cсылка на закрытый ключ отсутствует cрок действия закрытого ключа 25 мая 2023 г. 12:32:50 использование ключа обмена разрешено до окончания срока действия закрытого ключа. Ключ подписи отсутствует Симметричный ключ отсутствует Загрузка ключей успешно Версия контейнера 2 Значение ControlKeyTimeValidity 1 Режим работы CSP библиотека Расширения контейнера некритическое Расширение контейнера КриптоПро CSP. Срок действия ключа обмена действителен по 25 мая 2023 г. 12:55:03

Александр Лавник	#6 Оставлено : 25 февраля 2022 г. 17:47:07(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 30.06.2016(UTC) Сообщений: 3,205 Сказал «Спасибо»: 53 раз Поблагодарили: 723 раз в 675 постах	В Рутокен Lite по умолчанию пин-код «12345678». Попробуйте добавить строку: Код: pincode =12345678 в секцию [https] конфигурационного файла stunnel, после этого перезапустите службу stunnel и проверьте.
Техническую поддержку оказываем тут Наша база знаний

wraithik	#7 Оставлено : 25 февраля 2022 г. 19:04:44(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 25.02.2022(UTC) Сообщений: 5	Добавил пин. Теперь в логах: 2022.02.25 19:02:36 LOG5[5492:4976]: try to read the client certificate 2022.02.25 19:02:36 LOG7[5492:4976]: open file c:stunnelcert.cer with certificate 2022.02.25 19:02:36 LOG5[5492:4976]: pincode option is present. Call CryptSetProvParam 2022.02.25 19:02:36 LOG3[5492:4976]: CryptAcquireCertificatePrivateKey failed. Error = 0x8009001a 2022.02.25 19:02:36 LOG3[5492:4976]: Error creating credentials 2022.02.25 19:02:36 LOG5[5492:4976]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket 2022.02.25 19:02:36 LOG7[5492:4976]: free Buffers 2022.02.25 19:02:36 LOG5[5492:4976]: incomp_mess = 0, extra_data = 0 2022.02.25 19:02:36 LOG7[5492:4976]: https finished (0 left)

wraithik	#8 Оставлено : 28 февраля 2022 г. 11:14:32(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 25.02.2022(UTC) Сообщений: 5	Добрый день. Ваш специалист может подключится по удаленке и помочь решить вопрос?

Александр Лавник	#9 Оставлено : 28 февраля 2022 г. 22:59:07(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 30.06.2016(UTC) Сообщений: 3,205 Сказал «Спасибо»: 53 раз Поблагодарили: 723 раз в 675 постах	Автор: wraithik Добрый день. Ваш специалист может подключится по удаленке и помочь решить вопрос? Здравствуйте. Если вопрос еще актуален, то напишите в ЛС — согласуем время подключения.
Техническую поддержку оказываем тут Наша база знаний

Дмитрий Масленников	#10 Оставлено : 17 марта 2022 г. 12:17:53(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 17.03.2022(UTC) Сообщений: 1	Добрый день. аналогичную ошибку выводит. вам удалось решить вопрос??

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

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

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

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

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

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

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

0x80090304 Интеграция DMDK с КриптоПро и Stunnel

There are many posts online listing many different possible causes for these errors, so it’s not possible for this article to encompass all the solutions. These are just solutions to common causes for these errors. If the suggestions listed here don’t work for you, please email support at support@nsoftware.com

Ошибка 87 – говорит о том, что у нас на Windows 7 не выполняется команды

Для этого требуется установить исправление KB2966583 в моем случае это помогло.

Вторая ошибка связана с работой RDP на Windows 7 при которой нельзя подключится к Windows 10.

Уровень безопасности сервера обнаружил ошибку (0x80090304) в потоке протокола

Для этого потребуется установить 2 исправления KB2592687 и KB2574819-v2-x86 мне опять же помогло, все обновления скачанные с Microsoft прилагаются во вложении. Возможно данный алгоритм можно применить и к Windows 7 x64

Последнее редактирование: 28 Июль 2021

Есть крипто про 4. Необходимо установить stunnel. Интернет пишет, что он входит в комплект установки. Но там ничего подобного не видно.
Или он всё-таки устанавливается отдельно? Тогда, где его взять?

1 – 24.11.21 – 11:28

2 – 24.11.21 – 11:37

3 – 24.11.21 – 11:40

(2) И?
На скриншоте как раз ссылки под винду и написано что в линуксе это встроено

4 – 24.11.21 – 12:04

(3)Ну да. А оно с 4-й версие крипто про работать будет? И файлик подозрительно мелкий всего 89кб.

5 – 24.11.21 – 12:05

(4) ты лучше скажи для чего собрался туннель делать

6 – 24.11.21 – 12:06

7 – 24.11.21 – 12:28

8 – 24.11.21 – 12:29

9 – 24.11.21 – 16:17

(7)(8)Не читал. Пока тестовый контур пробую запустить. Благодарю за помощь.

10 – 09.02.22 – 23:13

Здравствуйте. Всё сделал по инструкции. Выдаёт ошибку:

Не удалось запустить службу Stunnel Service на Локальный компьютер
Ошибка 1069: Служба не запущена из-за ошибки входа в систему.

11 – 09.02.22 – 23:34

(10) Служба от кого запускается?

12 – 09.02.22 – 23:39

13 – 09.02.22 – 23:52

Эта ошибка была без пароля. Поставил пароль, Ошибка 1067: Процесс был неожиданно завершён

14 – 10.02.22 – 00:03

(13)Попробуйте переустановить службу.

15 – 10.02.22 – 00:26

Уже выкладывал тут кусок из инструкции от ювелирсофта

Это обязательное условие!

У меня все заработало 🙂

16 – 10.02.22 – 01:35

(15)Есть нормальный хостинг картинок?)

17 – 10.02.22 – 06:25

(13) У вас журналирование настроено? В настройках stunnel.conf проверьте опцию “output” — это путь к лог-файлу. Посмотрите, что там в журнале, выложите сюда вывод.

18 – 10.02.22 – 07:08

Вопрос как решился с сертификатом? У нас 3 раз бубен и третий раз разный.

19 – 10.02.22 – 08:13

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

20 – 10.02.22 – 08:58

(19)Да конечно всё по инструкции. Всё от одного пользователя. Сертификат сохранен без ключа. Прописан в конфиге. При старте ругается на сертификат. Где то только в консольной версии работает. Где то как служба. ДМДК пишут об обезличенном сертификате, народ утверждает что такие не выдают для ип (проверить не могу). Чем он лучше не говорят. ЮвелирСофт всё молиться на прямые руки сисадмина и просит 14000 за настройку stunnel.

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

   Источник

   Stunnel error 0x80090304 returned by acquirecredentialshandle

   

   Question

   

   

   we have setup in a test environment one configuration manager R2 on windows 2003 SP2 with internal CA authority. We have entered manually the Root CA hash in the MEBx and have disabled the DHCP as we don’t have a separate DHCP server for the test environment. Currently when we try in band provisioning, we receive the following error in the amtopmgr.log on the configuration manager server:
   —————————————————

   Answers

   

   

   we have found the problem. It appears that the problems cames from nested groups. As soon as we allow permissions for the computer account of the configuration manager server, instead of the group we had no problems to make the provisioning.
   The other problem with the client, which we saw in BIOS was the following:

   Machine Type: Invalid
   System Serial Number: Invalid
   UUID: FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF

   We had to update the BIOS with the boot CD image, downloaded from the manufacturer.

   After that everything worked as expected.

   With best Regards
   Kin

   

   

   

   

   yes both Hotfixes are installed.
   KB960804
   KB942841
   But that didn’t solved the problem.

   

   

   we have requested a new provisioning certificate from our internal CA and now the error has been changed:

   ————————————————————————————————————————————-
   Set credential on provisionHelper. SMS_AMT_OPERATION_MANAGER 16.4.2009 16:05:13 812 (0x032C)
   Try to use provisioning account to connect target machine
   . SMS_AMT_OPERATION_MANAGER 16.4.2009 16:05:13 812 (0x032C)
   Error 0x80090304 returned by InitializeSecurityContext during follow up TLS handshaking with server. SMS_AMT_OPERATION_MANAGER 16.4.2009 16:05:13 812 (0x032C)
   **** Error 0x2feb924 returned by ApplyControlToken SMS_AMT_OPERATION_MANAGER 16.4.2009 16:05:13 812 (0x032C)
   Fail to connect and get core version of machine using provisioning account #0.
   SMS_AMT_OPERATION_MANAGER 16.4.2009 16:05:13 812 (0x032C)
   ————————————————————————————————————————————-
   So can anyone help me what can cause this error.

   Thanks in advance.

   

   

   The fact that you’re not using DHCP worries me, because we’ve now updated the docs to say that DHCP is required for both out of band and in-band provisioning, in order to set the domain suffix correctly and create an A record in DNS. See the latest prerequisites topic (http://technet.microsoft.com/en-us/library/cc161785.aspx) where we say:

   For DHCP, ensure that the DHCP scope options include DNS servers (006) and Domain name (015) and that the DHCP server dynamically updates DNS with the computer resource record.

   This clarification came about because of another forum post where they had a very similar error to yours (but earlier version of AMT) — see http://social.technet.microsoft.com/forums/en-US/configmgrgeneral/thread/ba8ded54-9f4b-4425-9768-7b95cd66ac04/. Their issue came down to DHCP/DNS configuration for AMT — so I was wondering, in the log file where it says machine name > . domain suffix > , do you have a DNS record so that this name can be successfully resolved to an IP address?

   This posting is provided “AS IS” with no warranties and confers no rights

   

   

   sorry for the delay in response.
   We have setup the ip addresses and suffix manually, so we have disabled the DHCP server on the MEBx and on the Windows. The DNS server resolves correctly the clients machine, so there is no problem.

   As we can’t reproduce DHCP server in our test environment i ask our PKI team to publish the certificate templates in our real environment. As soon as they publish the templates, we will make the test in the real environment, where we have DHCP server with options 6 and 15 activated and i will let you know if the tests was successfull.

   Thanks for your answer and the links.

   

   

   we have prepared a DHCP server and checked the DNS for the forward (A) and reverse (PTR) DNS records for the client and ConfigMgr site server on a test environment and everything is ok, but the Configuration manager server still can’t made the provisioning.
   >>>>>>>>>>>>>>>Provision task begin machine name > . domain suffix > )
   Found valid basic machine property for machine > Warning: Currently we don’t support mutual auth. Change to TLS server auth mode.
   The provision mode for device machine name > . domain suffix > is 1.
   Attempting to establish connection with target device using SOAP.
   Found matched certificate hash in current memory of provisioning certificate
   Create provisionHelper with (Hash: 9241BCE663AC8F0649349AC8CC34234982EAD)
   Set credential on provisionHelper.
   Try to use provisioning account to connect target machine machine name > . domain suffix >
   Fail to connect and get core version of machine machine name > . domain suffix > using provisioning account #0.
   Try to use default factory account to connect target machine machine name > . domain suffix >
   Fail to connect and get core version of machine machine name > . domain suffix > using default factory account.
   Try to use provisioned account (random generated password) to connect target machine machine name > . domain suffix >
   Fail to connect and get core version of machine machine name > . domain suffix > using provisioned account (random generated password).
   Error: Device internal error. Check Schannel, provision certificate, network configuration, device. (MachineId = 6)
   Error: Can NOT establish connection with target device. (MachineId = 6)
   >>>>>>>>>>>>>>>Provision task end

   

   

   It does sound like you’ve checked everything you can within Configuration Manager — especially if you’ve checked the DNS domain suffix in AMT matches the host computer domain suffix, in addition to checking the DNS records. If you configure DHCP after the network interface has closed, this can introduce a timing issue where the DNS domain suffix doesn’t update in AMT — see this blog post for more details: http://blogs.technet.com/wemd_ua_-_sms_writing_team/archive/2008/12/09/out-of-band-management-requirements-for-in-band-amt-provisioning-and-dhcp.aspx

   There are a couple of suggested reasons for «Error: Device internal error. Check Schannel, provision certificate, network configuration, device» in our troubleshooting docs (http://technet.microsoft.com/en-us/library/cc161803.aspx), which point to the hotfix files being overwritten or DNS/DHCP misconfiguration. However, if you’ve checked these, I recommend you contact Intel for more diagnostics why AMT is rejecting the connection. I’ve just noticed from your original post that you’re running AMT version 4.1.3, and this isn’t one of our supported versions (see http://technet.microsoft.com/en-us/library/cc161963.aspx), so I definitely recommend checking with them in case there are known issues that might be causing this provisioning failure.

   In case you’re not aware of this, Intel have an excellent community forum to help support out of band management in Configuration Manager, and they are very helpful/responsive. When it comes to the nitty-gritty details of what AMT is doing and how to configure it, they are the experts because this is their technology. See the Intel vPro Expert Center: Microsoft vPro Manageability — http://communities.intel.com/community/vproexpert/microsoft-vpro.

   If you do find a resolution with them, can update this post to help other Configuration Manager customers?

   This posting is provided “AS IS” with no warranties and confers no rights

   Источник

   Stunnel error 0x80090304 returned by acquirecredentialshandle

   

   Question

   

   

   I have a SCCM R2 Windows 2008 System that has been functioning great! I have setup AMT in the past successfully however I am having difficulty getting our vPro systems Provisioned on SCCM. At this point, none are provisioned. I have all the required pre-req’s in place and i have installed our external GoDaddy cert successfully as well.

   The server is attempting to provision the systems, but fais with the following error:

   Failed to create SSPI credential with error=0x8009030E by AcquireCredentialsHandle.

   Very little information can be found for this specific error code but from what i could find it points to the SSL cert.

   I created my CSR to GoDaddy using OpenSSL (openssl.exe) and i I rcvd two files from GoDaddy. My Provisioning «.cer» and their Root Chain. I needed the «.cer» to be in «.pfx» (12) format so I used openssl and created a pfx using my private key that accompanied the initial request when i first generated and then sent the information to GoDaddy. and imported the pfx into SCCM successfully

   I’m pretty sure my request was properly formatted (they require 2048 bit now) but i do have my private key so is there a way to attach/import that into the Local Computer Store (where the public key already is) and then export to .pfx to try that?

   I have attached a screen shot of the «Start Task» to «End Task»

   

   Has anybody expierenced this before? Any help is appreciated ! THanks!

   Answers

   

   

   Short Answer — The Root CA Chain needs to be included in the PFX file you use for SCCM / WS Man Trans

   Answer — This was the first time I used OpenSSL binaries to create the cert request to the 3rd party cert provider. Not a problem. It worked and i rcvd two files back. The .CER file and the Certificate Root Chain. Since I used OpenSSL to create the request, i had to use OpenSSL to convert the CER into a PFX using the Private Key i initially created via OpenSLL. Once you convert the CER into a PFX, you need to import all 3 files (CER, Root Chain, and PFX) into the Local Computer Store. Once its imported, you need to Right Click on the Provisiong Cert (PFX) and select export. There will be an option for «Export all certificates in the chain if possible» or something along the lines of that. Once the export is complete, the PFX file you now exported is the PFX file you will use in SCCM and WSMan Trans.

   The problem i had was that I didnt include the cert root chain when converting my CER into PFX using OpenSSL. Once i imported / exported from the Windows Local Computer Store, the gates opened and within 15 min i see them all coming into the AD OU i created and all is well.

   For anyone interested, the commands i used to request and subsquently convert the cer into a PFX are as follows:

   Источник

There are many posts online listing many different possible causes for these errors, so it’s not possible for this article to encompass all the solutions. These are just solutions to common causes for these errors. If the suggestions listed here don’t work for you, please email support at support@nsoftware.com

DISM /Online /Cleanup-image /ScanHealth
DISM /Online /Cleanup-image /RestoreHealth

Креатив

24.11.21 – 11:25

Есть крипто про 4. Необходимо установить stunnel. Интернет пишет, что он входит в комплект установки. Но там ничего подобного не видно.
Или он всё-таки устанавливается отдельно? Тогда, где его взять?

Garykom

1 – 24.11.21 – 11:28

Креатив

2 – 24.11.21 – 11:37

(1)Мне под винду.

Aleksey

3 – 24.11.21 – 11:40

(2) И?
На скриншоте как раз ссылки под винду и написано что в линуксе это встроено

Креатив

4 – 24.11.21 – 12:04

(3)Ну да. А оно с 4-й версие крипто про работать будет? И файлик подозрительно мелкий всего 89кб.

Garykom

5 – 24.11.21 – 12:05

(4) ты лучше скажи для чего собрался туннель делать

Креатив

6 – 24.11.21 – 12:06

(5)ГИИС ДМДК.

Garykom

7 – 24.11.21 – 12:28

Garykom

8 – 24.11.21 – 12:29

Для настройки клиентской станции необходимо:

1. Скачать приложение для создания TLS-туннеля stunnel.x86/x64 с

сайта https://www.cryptopro.ru/products/csp/downloads

2. Сохранить скаченное приложение в каталоге c:stunnel

3. Запустить командную строку от имени администратора и

выполнить c:stunnelstunnel.x64 -install

4. В каталоге c:windowssystem32 создать файл конфигурации

stunnel.conf со следующим содержимым:

output=c:stunnelstunnel.log

Креатив

9 – 24.11.21 – 16:17

(7)(8)Не читал. Пока тестовый контур пробую запустить. Благодарю за помощь.

BobG

10 – 09.02.22 – 23:13

Здравствуйте. Всё сделал по инструкции. Выдаёт ошибку:

Не удалось запустить службу Stunnel Service на Локальный компьютер
Ошибка 1069: Служба не запущена из-за ошибки входа в систему.

arsik

11 – 09.02.22 – 23:34

(10) Служба от кого запускается?

BobG

12 – 09.02.22 – 23:39

От Администратора

BobG

13 – 09.02.22 – 23:52

Эта ошибка была без пароля. Поставил пароль, Ошибка 1067: Процесс был неожиданно завершён

Сергиус

14 – 10.02.22 – 00:03

(13)Попробуйте переустановить службу.

Builder

15 – 10.02.22 – 00:26

Сергиус

16 – 10.02.22 – 01:35

(15)Есть нормальный хостинг картинок?)

Anchorite

17 – 10.02.22 – 06:25

(13) У вас журналирование настроено? В настройках stunnel.conf проверьте опцию “output” — это путь к лог-файлу. Посмотрите, что там в журнале, выложите сюда вывод.

abfm

18 – 10.02.22 – 07:08

Вопрос как решился с сертификатом? У нас 3 раз бубен и третий раз разный.

Кирпич

19 – 10.02.22 – 08:13

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

abfm

20 – 10.02.22 – 08:58

(19)Да конечно всё по инструкции. Всё от одного пользователя. Сертификат сохранен без ключа. Прописан в конфиге. При старте ругается на сертификат. Где то только в консольной версии работает. Где то как служба. ДМДК пишут об обезличенном сертификате, народ утверждает что такие не выдают для ип (проверить не могу). Чем он лучше не говорят. ЮвелирСофт всё молиться на прямые руки сисадмина и просит 14000 за настройку stunnel.

Errors

• 80090302
• 8009030D
• 8009030E
• 80090304
• 80090308
• 80090325
• 80090326
• 80090327
• 80090331
• 8009035D
• 8009030F and 80090321

This error can occur when the component is using an older version of TLS, but the server requires a newer version. For instance if the component is using TLS 1.0, but the server requires TLS 1.2, you can see this error. Older versions of the components may not have the newer protocols enabled by default. In the current versions TLS 1.2 is enabled by default.

Possible Solutions

• Enable Supported Protocol Versions

  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.

This error is often seen when using PEM keys, and translates to “The credentials supplied to the package were not recognized”.

Possible Solutions

• Translate the PEM file into a PFX file.

  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.

• Ensure the Network Service account has access to “C:Documents and SettingsAll UsersApplication DataMicrosoftCryptoRSA.”
• If using a certificate from a Windows certificate store verify the certificate was imported wit the “Mark this key as exportable” option checked.
• If you are running the components from IIS, ensure that the Application Pool has Load User Profile set to true.

This error translates to “No credentials are available in the security package”.

Possible Solutions

• When using a certificate for client authentication, ensure the certificate’s private keys are accessible.
  The certificate in the Windows certificate store must contain the corresponding private keys, and be marked as exportable.
• Ensure that the current user and administrators have full access to “C:Documents and SettingsAll UsersApplication DataMicrosoftCryptoRSAMachineKeys”.
• Import the certificates directly into both LOCAL_MACHINEPersonal and ADAMPersonal if ADAM is installed.

This error translates to “The Local Security Authority cannot be contacted “.

• 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.

  HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELKeyExchangeAlgorithmsDiffie-Hellman

  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.

• Additional reasons and solutions for this problem are detailed in Microsoft KB 813550

This error translates to “The token supplied to the function is invalid “.

Possible Causes

• The server is using a certificate with an outdated signature algorithm. See this MSDN Article
• The server doesn’t expect SSL over this port.
  Set the SSLStartMode property to sslExplicit.
• FileZilla and other FTP servers require a PROT P command to be sent for the data connection when using implicit SSL.
  Set the UseProtWhenImplicit configuration setting to True.
• The server returns a large number of CA’s in the handshake.

Also see this Knowledge Base article about this error: SSL: Error During Handshake: 80090308

This error translatest to “The certificate chain was issued by an authority that is not trusted.”

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.

This error translates to “The message received was unexpected or badly formatted.”

Possible Solutions

• This error may also happen if the server and client don’t posses a common supported cipher suite. This can be the case if you’re connecting from Windows XP to a site that has recent/strict security requirements. Here is a list of ciphers supported in XP. Setting UseInternalSecurityAPI to true may help with this error as it supports many newer protocols not supported on older systems.
• Client authentication is required. Ensure that you are loading the certificate correctly.
• The server does not support the SSL Client Hello version being used. Set the SSLEnabledProtocols configuration setting to an appropriate value.
• The server does not support SSL session re-use. You can disable this by setting the ReuseSSLSession and/or ReuseSSLSessionInDI configuration setting to false.
• The server returns SSL handshake packets larger than 16K. This is a CryptoAPI limitation.

In ThreeDSecure, this error is typically related to a problem with client authentication.

This error translates to “An unknown error occurred while processing the certificate.”

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

This error translates to “The client and server cannot communicate, because they do not possess a common algorithm”.

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.

This error translates to “One or more of the parameters passed to the function was invalid.”

Possible Solutions

• Similar to 80090304, 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.

• The below Windows updates have been known to cause the issue:
  • KB3172605
  • KB3175024
  • KB3177186
  • KB3184122
  • KB3185911
• Additional reasons and solutions for this problem are detailed in Microsoft KB 813550

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

We appreciate your feedback.  If you have any questions, comments, or
suggestions about this entry please contact our support team at
kb@nsoftware.com.

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

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

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

Источник

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

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

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

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

После того, как я удалил обновление 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 и нажимаю «Подключить», появляется ошибка:

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

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

В своей проблеме вы не одиноки. У пользователей английской версии 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

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