Error 0x80090304 the local security authority cannot be contacted

skull	#1 Оставлено : 10 февраля 2017 г. 17:37:36(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 09.02.2017(UTC) Сообщений: 24 Сказал(а) «Спасибо»: 7 раз	Здравствуйте, прошу оказать помощь с TLS! Сервер работает на CentOS 6.6 x64. Установлен пакет КриптоПро CSP 4.0 КС2. Установлен серверный сертификат с закрытым ключен, корневой сертификат и СОС. В сервере приложений настроен коннектор на порту 8443. Запускаем сервер приложений и проверяем tls-туннель с помощью csptestf. Вот вывод команды /opt/cprocsp/bin/amd64/csptestf -tlsc -server 127.0.0.1 -port 8443 -v -v -v: [root@localhost logs]# /opt/cprocsp/bin/amd64/csptestf -tlsc -server 127.0.0.1 -port 8443 -v -v -v 8 algorithms supported: [0] 1.2.643.2.2.21 (ГОСТ 28147-89) [1] 1.2.643.2.2.3 (ГОСТ Р 34.11/34.10-2001) [2] 1.2.643.7.1.1.2.2 (ГОСТ Р 34.11-2012 256 bit) [3] 0x801f [4] 1.2.643.2.2.20 (ГОСТ Р 34.10-94) [5] 1.2.643.2.2.19 (ГОСТ Р 34.10-2001) [6] 1.2.643.7.1.1.1.1 (ГОСТ Р 34.10-2012) [7] 1.2.643.7.1.1.1.2 (ГОСТ Р 34.10-2012) Cipher strengths: 256..256 Supported protocols: 0x80 dwProtocolMask: 0x800a0aaa Protocol version: 3.3 ClientHello: RecordLayer: TLS, Len: 92 Cipher Suites: (ff 85) (00 81) (00 32) (00 31) 97 bytes of handshake data sent 0000 16 03 01 00 5c 01 00 00:58 03 03 58 52 6a a9 5e …….X..XRj.^ 0010 87 53 b4 16 dd 76 2a 27:22 f8 66 95 03 ad b4 49 .S…v*'».f….I 0020 d2 ec 30 20 85 1f 06 91:03 50 1e 00 00 08 ff 85 ..0 …..P…… 0030 00 81 00 32 00 31 01 00:00 27 ff 01 00 01 00 00 …2.1…’…… 0040 23 00 00 00 00 00 0e 00:0c 00 00 09 31 32 37 2e #………..127. 0050 30 2e 30 2e 31 00 0d 00:08 00 06 ee ee ef ef ed 0.0.1……….. 0060 ed . **** Error 104 reading data from server An error occurred in running the program. /dailybuildsbranches/CSP_4_0/CSPbuild/CSP/samples/csptest/WebClient.c:578:Error performing handshake. Error number 0x80090304 (2148074244). The Local Security Authority cannot be contacted An error occurred in running the program. /dailybuildsbranches/CSP_4_0/CSPbuild/CSP/samples/csptest/WebClient.c:2818:Socket shutdown() Error number 0x80090304 (2148074244). The Local Security Authority cannot be contacted Total: SYS: 0,030 sec USR: 0,090 sec UTC: 0,160 sec [ErrorCode: 0x80090304] При запуске сервер приложений формирует лог tls.log. А после попытки загрузить страничку https://localhost:8443/ в этот же лог вываливается дамп (во вложении tls.log (5kb) загружен 13 раз(а).). Страница в браузере при этом не открывается. Подскажите, в чем может быть ошибка, где искать ее причину?

Максим Коллегин	#2 Оставлено : 10 февраля 2017 г. 23:12:03(UTC)
Статус: Сотрудник Группы: Администраторы Зарегистрирован: 12.12.2007(UTC) Сообщений: 6,255 Откуда: КРИПТО-ПРО Сказал «Спасибо»: 21 раз Поблагодарили: 660 раз в 583 постах	А что за сервер, можно поподробнее?
Знания в базе знаний, поддержка в техподдержке
	WWW

skull	#3 Оставлено : 13 февраля 2017 г. 9:40:40(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 09.02.2017(UTC) Сообщений: 24 Сказал(а) «Спасибо»: 7 раз	Виртуалка на VMWare. Развернута для тестирования совместимости ПО с CSP 4.0. CentOS 6.6 с ядром 2.6.32-573.7.2.el6.x86_64. Какие сведения нужны ? Отредактировано пользователем 13 февраля 2017 г. 9:41:26(UTC)  | Причина: Не указана

Максим Коллегин	#4 Оставлено : 13 февраля 2017 г. 15:22:48(UTC)
Статус: Сотрудник Группы: Администраторы Зарегистрирован: 12.12.2007(UTC) Сообщений: 6,255 Откуда: КРИПТО-ПРО Сказал «Спасибо»: 21 раз Поблагодарили: 660 раз в 583 постах	Интересует именно TLS-сервер. Чей это лог?
Знания в базе знаний, поддержка в техподдержке
	WWW

skull	#5 Оставлено : 16 февраля 2017 г. 11:55:58(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 09.02.2017(UTC) Сообщений: 24 Сказал(а) «Спасибо»: 7 раз	TLS-сервер работает под Apache Tomcat 7. Лог формирует наша имплементация TLS на JAVA. Выяснили кстати, что дамп в tls.log это лишь результат логирования в режиме DEBUG, это не ошибка. Проверили работу TLS-сервера под Apache Tomcat 7 на двух других серверах с CSP 4.0 и CSP 3.6. На них TLS заработал, ура! На проблемном сервере по прежнему нет… На нём же попробовали настроить TLS с помощью stunnel с использованием того же сертификата. tls не поднялся… Вот конфиг: pid = /opt/cprocsp/sbin/amd64/stunnel_serv.pid output = /opt/cprocsp/sbin/amd64/stunnel_serv.log socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 debug = 7 [https] accept = 80 connect = 443 cert = /home/tech2017.cer verify = 0 Вот и формируемый лог: 2017.02.16 11:36:09 LOG5[19908:140508684384096]: stunnel 4.18 on x86_64-unknown-linux-gnu 2017.02.16 11:36:09 LOG5[19908:140508684384096]: Threading:PTHREAD Sockets:POLL,IPv6 Auth:LIBWRAP 2017.02.16 11:36:09 LOG6[19908:140508684384096]: file ulimit = 10240 (can be changed with ‘ulimit -n’) 2017.02.16 11:36:09 LOG6[19908:140508684384096]: poll() used — no FD_SETSIZE limit for file descriptors 2017.02.16 11:36:09 LOG5[19908:140508684384096]: 0 clients allowed 2017.02.16 11:36:09 LOG7[19908:140508684384096]: FD 5 in non-blocking mode 2017.02.16 11:36:09 LOG7[19908:140508684384096]: FD 6 in non-blocking mode 2017.02.16 11:36:09 LOG7[19908:140508684384096]: FD 8 in non-blocking mode 2017.02.16 11:36:09 LOG7[19908:140508684384096]: SO_REUSEADDR option set on accept socket 2017.02.16 11:36:09 LOG7[19908:140508684384096]: https bound to 0.0.0.0:80 2017.02.16 11:36:09 LOG7[19909:140508684384096]: Created pid file /opt/cprocsp/sbin/amd64/stunnel_serv.pid 2017.02.16 11:36:09 LOG7[19909:140508684384096]: open file /home/tech2017.cer with certificate 2017.02.16 11:36:09 LOG5[19909:140508684384096]: CertFindCertificateInStore not find certificate in LOCAL_MACHINE store. Looking at CURRENT_USER 2017.02.16 11:36:09 LOG3[19909:140508684384096]: **** Error 0x80090304 returned by AcquireCredentialsHandle 2017.02.16 11:36:09 LOG3[19909:140508684384096]: Error creating credentials 2017.02.16 11:36:09 LOG7[19909:140508684384096]: removing pid file /opt/cprocsp/sbin/amd64/stunnel_serv.pid В логе ошибка с тем же кодом, что и при проверке TLS-соединения с помощью csptestf (см. первое сообщение в теме). Код ошибки 0x80090304. Ключи установлены в хранилище пользователя root с привязкой к файлу сертификата. Помогите разобраться в чем проблема…

Максим Коллегин	#6 Оставлено : 17 февраля 2017 г. 9:29:47(UTC)
Статус: Сотрудник Группы: Администраторы Зарегистрирован: 12.12.2007(UTC) Сообщений: 6,255 Откуда: КРИПТО-ПРО Сказал «Спасибо»: 21 раз Поблагодарили: 660 раз в 583 постах	Скорее всего не открывается контейнер при создании мандата. Где находится контейнер? Пароль не на него не установлен?
Знания в базе знаний, поддержка в техподдержке
	WWW

skull	#7 Оставлено : 17 февраля 2017 г. 10:11:27(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 09.02.2017(UTC) Сообщений: 24 Сказал(а) «Спасибо»: 7 раз	Контейнер размещен в /var/opt/cprocsp/keys/root/. Пароль на него установлен стандартный 12345678. Сертификат установлен в хранилище пользователя root.

Максим Коллегин	#8 Оставлено : 21 февраля 2017 г. 10:19:57(UTC)
Статус: Сотрудник Группы: Администраторы Зарегистрирован: 12.12.2007(UTC) Сообщений: 6,255 Откуда: КРИПТО-ПРО Сказал «Спасибо»: 21 раз Поблагодарили: 660 раз в 583 постах	Попробуйте сделать контейнер без пароля.
Знания в базе знаний, поддержка в техподдержке
	WWW

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

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

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

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

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

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

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

This error appears when users try to login to other computers via a remote desktop connection. The problem prevents them from connecting and it displays the “The Local Security Authority Cannot be Contacted” error message. The problem often appears after an update has been installed on either the client or the host PC and it causes plenty of problems on many different versions of Windows.

The Local Security Authority Cannot be Contacted

There have been many unofficial fixes for the problem which were created by the users who had the same unfortunate experience. We have gathered the working methods in this article so make sure you follow it in order to resolve the problem.

What Causes “The Local Security Authority Cannot be Contacted” Error on Windows?

Pinpointing the correct cause for the problem is one of the most important steps when it comes to resolving one. That is why we have created a list of possible causes for the problem so make sure you check it out below:

• DNS addresses may be wrongly configured – If this is indeed the case, try using the DNS addresses provided by Google or OpenDNS
• Remote Desktop connections may be disabled by default on either the host or the client PC – Make sure you turn the option on to connect properly without errors.
• IP and DNS address conflicts – Running a certain command may help you resolve the problem

Solution 1: Change Your DNS Address

The problem is often caused by a faulty DNS setup which is simply not accepted by the host or its service. The problem can be resolved easily by changing your default DNS settings to use the ones provided by OpenDNS or Google. This can be done easily in Control Panel so make sure you follow the steps below carefully.

1. Use the Windows + R key combo which should immediately open the Run dialog box where you should type ‘ncpa.cpl’ in the bar and click OK in order to open the Internet Connection Settings item in Control Panel.
2. The same process can also be done by manually opening Control Panel. Switch the View by setting at the top right section of the window to Category and click on Network and Internet at the top. Click the Network and Sharing Center button in order to open it. Try to locate the Change adapter settings button at the left menu and click on it.

Change adapter settings

1. Now that the Internet Connection window is open using any method above, double-click on your active network adapter and click on the Properties button below if you have admin permissions.
2. Locate the Internet Protocol Version 4 (TCP/IPv4) item on the list. Click on it in order to select it and click the Properties button below.

Internet Protocol Version 4 – Properties

1. Stay in the General tab and switch the radio button in the Properties window to “Use the following DNS server addresses” if it was set to something else.
2. Set Preferred DNS server to be 8.8.8.8 and the Alternate DNS server to be 8.8.4.4

Setting the DNS address to Google DNS or OpenDNS

1. Keep the “Validate settings upon exit” option checked and click OK in order to apply the changes immediately. Check to see if the same problem still appears!

Solution 2: Enable Remote Connections in Group Policy Editor

Sometimes the Group Policy on the client computer is preventing the remote Desktop connection completely. This can be changed quite easily in Group Policy Editor if you are running any version of Windows besides Windows Home. Follow the steps below in order to enable remote connections in Group Policy Editor.

1. Use the Windows Key + R key combination (tap the keys simultaneously) to open the Run dialog box. Enter “gpedit.msc” in the Run dialog box, and press the OK button in order to open the Local Group Policy Editor tool. On Windows 10, you can try simply type Group Policy Editor in the Start menu and click the top result.

Running Group Policy Editor

1. On the left navigation pane of Local Group Policy Editor, under Computer Configuration, double click on Administrative Templates, and navigate to the Windows Components>> Remote Desktop Services >> Remote Desktop Session Host >> Connections.
   

   Allow users to connect remotely by using Remote Desktop Services

2. Select the Connections folder by left-clicking on it and check out its right side section.
3. Double click on the “Allow users to connect remotely by using Remote Desktop Services” policy and check the radio button next to the “Enabled” option.

Enabling the policy

1. Apply the changes you have made before exiting. The changes won’t be applied until you restart.
2. Finally, reboot the computer to save the changes and check to see if you are still being targeted with the error.

Solution 3: Allow the Connection inside System Properties

The most common cause for the problem is the fact that remote access is, in one way or another, blocked on either the host or the client PC. This time, the problem may be with the host PC which may not be accepting connections from other PCs or the ones with another version of Remote Desktop running. Follow the steps below in order to fix this.

1. Right-click either on My Computer/This PC depending on the version of Windows you have installed on your computer and choose the Properties
2. After that, locate the Change settings button at the left side of the Properties window, under Computer name, domain, and workgroup settings, and click on it.

Change settings button in This PC >> Properties

1. In the Remote tab of System properties, check under Remote Desktop and click the radio button next to Allow remote connections to this computer. Also, uncheck the box next to the Allow connections only from computers running Remote Desktop with Network Level Authentication (recommended).

Allow remote connections to this computer

1. Apply the changes you have made and check to see if the problem still appears.

Solution 4: Run a Helpful Command on the Host

This method is quite popular for its simplicity and plenty of people use it in order to fix most things related to connectivity issues. The funny thing is that it works and users have commented saying that this is the only step it took to resolve the problem. Try it out now!

1. Search for “Command Prompt” by typing it right in the Start menu or by pressing the search button right next to it. Right-click the first entry which will pop up as a search result and select the “Run as administrator” option from the context menu.
2. Additionally, you can also use the Windows Logo Key + R key combination in order to bring up the Run dialog box. Type in “cmd” in the dialog box which appears and use the Ctrl + Shift + Enter key combination for administrative Command Prompt.

Running Command Prompt

1. Type in the following command in the window and make sure you press Enter after typing it out. Wait for the “Operation completed successfully” message or something similar to know that the method worked.

1. Try to reset the connection and check to see if the error still appears.

Solution 5: Set to Allow Connections from All Versions

Microsoft released an update to Windows 10 and Windows server to fix certain vulnerabilities and didn’t end up releasing one for Windows 7. Therefore, Windows 7 users were stuck on a different version. Therefore, you have to set up the connection in such a way that it allows connecting from any and all versions of Remote Desktop. However, keep in mind that this is much less secure than the latter option.

Источник

Error 0x80090304 the local security authority cannot be contacted

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

Asked by:

Question

We have an application that accesses a SQL server and we are experiencing very slow performance of the application and it also sometimes just doesn’t return any information. I understand that this is not a great deal of information regarding the application but it is all I have available at the moment (I am trying to get more details from developers).

The users of the application are located in separate domain to the domain the SQL server is a member of (different subnets etc). There is a one way external trust between the domain of the SQL server and the domain the users of the application reside in.

We think this error we see in the logs of the SQL server may be related.

«SSPI handshake failed with error code 0x80090304, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. The Local Security Authority cannot be contacted [CLIENT: 10.133.21.73]»

After following a troubleshooting guide for the above error part of the guide states to verify the SQL server is using Kerberos authentication. After running a query the SQL server seems to be using NTLM. I don’t know whether this would cause this issue or not.

Any help or insight that anyone could provide, even if it just gets me started, would be very useful.

Источник

Error 0x80090304 the local security authority cannot be contacted

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

Asked by:

Question

We have an application that accesses a SQL server and we are experiencing very slow performance of the application and it also sometimes just doesn’t return any information. I understand that this is not a great deal of information regarding the application but it is all I have available at the moment (I am trying to get more details from developers).

The users of the application are located in separate domain to the domain the SQL server is a member of (different subnets etc). There is a one way external trust between the domain of the SQL server and the domain the users of the application reside in.

We think this error we see in the logs of the SQL server may be related.

«SSPI handshake failed with error code 0x80090304, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. The Local Security Authority cannot be contacted [CLIENT: 10.133.21.73]»

After following a troubleshooting guide for the above error part of the guide states to verify the SQL server is using Kerberos authentication. After running a query the SQL server seems to be using NTLM. I don’t know whether this would cause this issue or not.

Any help or insight that anyone could provide, even if it just gets me started, would be very useful.

Источник

Error 0x80090304 the local security authority cannot be contacted

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

Asked by:

Question

It’s interesting that I have searched for days now, and still can not find an answer to this. Hopefully someone can look over what I have and recommend a solution.

The situation:
There is a VPN tunnel that connects the various locations. I have a user that connects to the corporate network via VPN, and uses RDP to connect to their workstation in a different location than the entry point. User receives the following error when trying to use RDP:

Authentication error has occurred.
The Local Security Authority cannot be contacted.
Remote computer xxx.xxx.xxx.xxx
This could be due to an expired password .
Please update your password if it has expired.

If I am physically within the network, but attempt to RDP to any of the workstations on the other side of the tunnel, I receive the same error.

I am able to successfully RDP into any system on my side of the tunnel, and RDP into a server on the other side of the tunnel. If I were to connect to the remote server and RDP into any workstation that resides within that network, I receive the following error:

An authentication error has occurred (Code: 0x80090304)
Remote computer: xxx.xxx.xxx.xxx

What I have tried:

• Error code 0x80090304 is linked to error SEC_E_INTERNAL_ERROR. The Microsoft Hotfix for this error returned a message stating that it did not apply to this system. The server is x64 and the hotfix was for an x64 system. This error message also seems to be link to the error in the workstations Event Viewer TermDD Event ID 56
• In the Terminal Services Configurations settings on that server, the Security Layer is correctly set to RDP Security Layer and «Allow connections only form computers running Remote Desktop with Network Level Authentication» is unchecked in the System Properties under the Remote tab.
• In the registry, HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control > Terminal Server > WinStations > RDP-Tcp the UserAuthentication value was changed it to 1 and system was restarted to apply registry changes.
• GPO already disables Network Level Authentication.
• — Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment
  «Access this computer from the network» is set to correctly
• Also tried logging in with the following schemes with no success:
  .
• Even with firewall disabled, RDP attempts to remote workstation were unsuccessful
• RDP connecting to workstations using domain admin credentials or users credentials.
• Users credentials was reset, user does not have to log in to change password and password is set to never expire.

Is there anything else that could cause this issue that I should check?

Источник

adminman	#1 Оставлено : 21 января 2022 г. 5:41:26(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 20.01.2022(UTC) Сообщений: 2 Откуда: Новосибирск	Помогите, пожалуйста, разобраться с проблемой. Есть код на .net5.0, который вычитывает сертификат и устанавливает безопасное соединение с сайтом Equifax. Код работает на серверах под управлением Windows Server 2016(2019) с установленными на них Крипто-Про версий 5.0.12000КС1, 5.0.11455КС1, 4.0.9842 (версии разные так как серверы настраивались в разное время). Для работы этого кода Крипто-Про не нужен, он установлен на серверах совсем для других вещей. Всё это работало на протяжении примерно двух лет. Последний факт корректной работы — 10 января 2022 года. После этого при попытке соединения с сайтом начали получать ошибку (отличается в зависимости от версии): Крипто-Про 4.0.9842 Код: Unhandled exception. System.AggregateException: One or more errors occurred. (The SSL connection could not be established, see inner exception.) ---> System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception. ---> System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception. ---> System.ComponentModel.Win32Exception (0x80090304): The Local Security Authority cannot be contacted В логах Windows та же самая ошибка с источником .NET Runtime Крипто-Про 5.0.11455КС1 Код: Unhandled exception. System.AggregateException: One or more errors occurred. (The SSL connection could not be established, see inner exception.) ---> System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception. ---> System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception. ---> System.ComponentModel.Win32Exception (0x80090304): The Local Security Authority cannot be contacted В логах Windows та же самая ошибка с источником .NET Runtime, а также ошибка 308 с источником cpssp Код: CryptoPro TLS. Error %2 importing public key: %1 Крипто-Про 5.0.12000КС1 Код: Unhandled exception. System.AggregateException: One or more errors occurred. (The SSL connection could not be established, see inner exception.) ---> System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception. ---> System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception. ---> System.ComponentModel.Win32Exception (0x80090320): The credentials supplied were not complete, and could not be verified. The context could not be initialized. В логах Windows та же самая ошибка с источником .NET Runtime, а также ошибка 307 с источником ssp Код: CryptoPro TLS. Error 0x80090320 in TLS protocol: The credentials supplied were not complete, and could not be verified. The context could not be initialized. Права доступа к закрытому ключу выданы. Хотя, если удалить Крипто-Про, то всё работает хорошо вне зависимости от выставленных прав доступа к ключу. Но удалять Крипто-Про не вариант, так как он нужен для других целей. Предположения: проблема в обновлениях Windows так как ошибку наблюдаем при попытке соединиться с тестовым сервером Equifax из нашей же тестовой среды (10 января все тесты работали), а наша боевая среда связывается с боевым же сервером Equifax нормально, то, возможно, проблема в тестовом сервере Equifax. Пока жду ответа буду проверять предположения.

adminman	#2 Оставлено : 15 марта 2022 г. 5:54:42(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 20.01.2022(UTC) Сообщений: 2 Откуда: Новосибирск	Разобрался. Тестовый сервер Equifax возвращал другие наборы шифрования, которые он поддерживает. Они собираются переходить на использование ГОСТ, поэтому активировали его на тестовом сервере. В итоге имеем такую картину: * в ответе сервера присутствуют алгоритмы шифрования ГОСТ * на хосте, откуда уходил запрос, установлена Крипто-Про * Крипто-Про вынуждает приложение использовать ГОСТ, так как сервер ответил, что поддерживает его * для использования ГОСТ нужен дополнительный сертификат, который, естественно, не установлен * приложение валится, так как не может найти сертификат и установить безопасное соединение Тему можно закрывать. Отредактировано пользователем 15 марта 2022 г. 5:56:55(UTC)  | Причина: Не указана

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

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

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

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

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

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

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

We have an application that accesses a SQL server and we  are experiencing very slow performance of the application and it also sometimes just doesn’t return any information. I understand that this is not a great deal of information regarding the application
but it is all I have available at the moment (I am trying to get more details from developers).

The users of the application are located in separate domain to the domain the SQL server is a member of (different subnets etc). There is a one way external trust between the domain of the SQL server and the domain the users of the application reside in.

We think this error we see in the logs of the SQL server may be related.

«SSPI handshake failed with error code 0x80090304, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. The Local
Security Authority cannot be contacted   [CLIENT: 10.133.21.73]»

After following a troubleshooting guide for the above error part of the guide states to verify the SQL server is using Kerberos authentication. After running a query the SQL server seems to be using NTLM. I don’t know whether this would cause this issue
or not.

Any help or insight that anyone could provide, even if it just gets me started, would be very useful.

Kind regards

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:

   Источник