Иван Бахтин |
|
|
Статус: Участник Группы: Участники Сказал(а) «Спасибо»: 5 раз |
Здравствуйте! Установленный сертификат: Настройки stunnel.conf: Вывод log stunnel: Так же хочу сказать, что проверил сертификаты на совпадение (т.е. установленный у меня и передаваемый с сервера ГИС ЖКХ) утилитой /opt/cprocsp/bin/amd64/csptest, сертификаты совпадают. Подскажите, пожалуйста, где я допустил ошибку и как её исправить? |
 |
|
|
two_oceans |
|
|
Статус: Эксперт Группы: Участники Сказал(а) «Спасибо»: 110 раз |
Добрый день. 2) в строке CAFile по идее должен быть не сам сертификат сервера, а список сертификатов УЦ, выдавшего сертификат серверу. В случае тестового УЦ КриптоПро это обычно 2 сертификата от корневого и промежуточного УЦ. Обычно это выглядит как: Код: заголовки могут немного отличаться смотря какая версия stunnel и openssl Отредактировано пользователем 5 апреля 2022 г. 7:27:39(UTC) |
|
|
|
|
|
Иван Бахтин
оставлено 05.04.2022(UTC) |
1 пользователь поблагодарил two_oceans за этот пост.|
Иван Бахтин |
|
|
Статус: Участник Группы: Участники Сказал(а) «Спасибо»: 5 раз |
Автор: two_oceans Добрый день. 2) в строке CAFile по идее должен быть не сам сертификат сервера, а список сертификатов УЦ, выдавшего сертификат серверу. В случае тестового УЦ КриптоПро это обычно 2 сертификата от корневого и промежуточного УЦ. Обычно это выглядит как: Код: заголовки могут немного отличаться смотря какая версия stunnel и openssl Большое спасибо! С verify=0 запросы проходят. Очень надеюсь, что на боевом сервере с verify=2 всё будет работать. |
|
|
|
| Пользователи, просматривающие эту тему |
|
Guest |
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Содержание
- Stunnel error 0x8009030e returned by verifycertchain
- Причины ошибки 0x8009030E
- Если у вас SCVMM
- Мигрируем через Powershell
- Веб — сервис интеграции
- Проблемы при миграции виртуальной машины Hyper-V в Windows Server 2012 R2 (0x8009030E, 0x8009030D и др.)
- Причины ошибок 0x8009030E и 0x8009030D
- Решения:
- Если у вас SCVMM
- Мигрируем через Powershell
- Stunnel error 0x8009030e returned by verifycertchain
- Question
- Answers
- Stunnel error 0x8009030e returned by verifycertchain
- Вопрос
Stunnel error 0x8009030e returned by verifycertchain
Всем привет сегодня разберем, как решается ошибка 0x8009030E при миграции виртуальной машины Hyper-V в Windows Server 2012 R2. Напомню миграция — это перемещение виртуальной машины на другой хост виртуализации, и вот во время этого процесса возникает этот неприятный момент.
Давайте подробнее посмотрим как она выглядит, я про 0x8009030E .
Причины ошибки 0x8009030E
Первая причина у вас не включена динамическая миграция Hyper-V, проверить это можно в свойствах хоста виртуализации.
На вкладке Динамическая миграция, должна стоять галка Включить входящие и исходящие миграции.
Вторая причина у вас не включен Kerberos. Если у вас по CredSSp, не удается мигрировать выставляем тогда Kerberos, для большей безопасности, его мы еще поднастроим.
Так же если вы пытаетесь делать миграцию работающей виртуальной машины, удостоверьтесь, что у вас стоит галка в свойствах виртуалки, на вкладке Процессор (Выполнить перенос на физический компьютер с другой версией процессора). Данная галка нужна если у вас разные процессоры, так как не везде все сервера одинаковые.
Для того чтобы kerberos отработал и вы не получили 0x8009030E при миграции виртуальной машины Hyper-V в Windows Server 2012 R2, делаем следующее. Открываем оснастку Active Directory — Пользователи и компьютеры, ищем там ваши компьютеры Hyper-V и переходим в их свойства. Перехлдим на вкладку Делегирование, выставляем там Доверять компьютеру делегирование указанных служб > Использовать только Kerberos и добавляем туда две службы первая — cifs (для миграции хранилищ), вторая — Microsoft Virtual System Migration Service
Все можно теперь мигрировать спокойно.
Если у вас SCVMM
Если у вас есть scvmm, то проверьте, что в свойствах хоста
Перейдите на вкладку Доступ к узлу и проверьте, что в Учетная запись запуска от имени не пуста, если там ничег онет, то через обор добавьте.
Мигрируем через Powershell
- VMName — Имя виртуальной машины
- Hyper-V-ServerName — Имя сервера, куда вы мигрируете
- VMNameFolder — Имя папки, в которую размещается VM
Думаю было не сложно и вы победили свою ошибку 0x8009030E.
Источник
Веб — сервис интеграции
Уважаемый участник рынка ДМДК!
Инструкция по работе с интеграционным сервисом
размещена в разделе «Для бизнеса».
2022.01.29 15:37:14 LOG7[48488:77600]: Creating a new thread
2022.01.29 15:37:14 LOG7[48488:77600]: New thread created
2022.01.29 15:37:14 LOG7[48488:67800]: client start
2022.01.29 15:37:14 LOG7[48488:67800]: Work_AT started
2022.01.29 15:37:14 LOG7[48488:67800]: FD 336 in non-blocking mode
2022.01.29 15:37:14 LOG7[48488:67800]: TCP_NODELAY option set on local socket
2022.01.29 15:37:14 LOG5[48488:67800]: Work_AT connected from 127.0.0.1:54057
2022.01.29 15:37:14 LOG7[48488:67800]: FD 412 in non-blocking mode
2022.01.29 15:37:14 LOG7[48488:67800]: Work_AT connecting
2022.01.29 15:37:14 LOG7[48488:67800]: connect_wait: waiting 10 seconds
2022.01.29 15:37:14 LOG7[48488:67800]: connect_wait: connected
2022.01.29 15:37:14 LOG7[48488:67800]: Remote FD=412 initialized
2022.01.29 15:37:14 LOG7[48488:67800]: TCP_NODELAY option set on remote socket
2022.01.29 15:37:14 LOG7[48488:67800]: start SSPI connect
2022.01.29 15:37:14 LOG5[48488:67800]: try to read the client certificate
2022.01.29 15:37:14 LOG7[48488:67800]: open file C:stunnelWork_AT.cer with certificate
2022.01.29 15:37:14 LOG3[48488:67800]: **** Error 0x8009030e returned by AcquireCredentialsHandle
2022.01.29 15:37:14 LOG3[48488:67800]: Credentials complete
2022.01.29 15:37:14 LOG3[48488:67800]: Error creating credentials
2022.01.29 15:37:14 LOG5[48488:67800]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
2022.01.29 15:37:14 LOG7[48488:67800]: free Buffers
2022.01.29 15:37:14 LOG5[48488:67800]: incomp_mess = 0, extra_data = 0
2022.01.29 15:37:14 LOG7[48488:67800]: Work_AT finished (0 left)
Источник
Проблемы при миграции виртуальной машины Hyper-V в Windows Server 2012 R2 (0x8009030E, 0x8009030D и др.)
Всем привет сегодня разберем, как решается ошибка 0x8009030E или 0x8009030D при миграции виртуальной машины Hyper-V в Windows Server 2012 R2. Напомню миграция — это перемещение виртуальной машины на другой хост виртуализации, и вот во время этого процесса возникает этот неприятный момент.
Сбой операции миграции виртуальной машины в исходном расположении миграции
Причины ошибок 0x8009030E и 0x8009030D
И та и другая ошибка связаны с тем что нужно входить на каждый сервер для выполнения определенной задачи (через локальный сеанс консоли, сеанс удаленного рабочего стола или удаленный сеанс Windows PowerShell) с сервера с которого осуществляется миграция либо настроить ограниченное делегирование для хостов.
Поскольку каждый раз входить с сервера на сервер неудобно, я опишу как настроить ограниченное делегирование.
Решения:
На вкладке Динамическая миграция, должна стоять галка Включить входящие и исходящие миграции.
Вторая причина у вас не включен Kerberos. Если у вас по CredSSp, не удается мигрировать выставляем тогда Kerberos, для большей безопасности, его мы еще поднастроим.
Так же если вы пытаетесь делать миграцию работающей виртуальной машины, может возникнуть ошибка VMM:
virtual machine … is using processor-specific features not supported on host…
Для решения, удостоверьтесь, что у вас стоит галка в свойствах виртуалки, на вкладке Процессор (Выполнить перенос на физический компьютер с другой версией процессора). Данная галка нужна если у вас разные процессоры, так как не везде все сервера одинаковые.
Если вы выполняете миграцию с рабочей станции, через оснастку Диспетчер Heper-V вы опять словите данную ошибку 0x8009030E или 0x8009030D, так как данную операцию нужно производить с хоста Hyper-V, где лежит тачка подключенного по RDP, но не спешите расстраиваться, мы же не зря настраивали kerberos, делаем ниже инструкции и радуемся жизни
Для того чтобы kerberos отработал и вы не получили ни 0x8009030E, ни 0x8009030D при миграции виртуальной машины Hyper-V в Windows Server 2012 R2, делаем следующее. Открываем оснастку Active Directory — Пользователи и компьютеры, ищем там ваши компьютеры Hyper-V и переходим в их свойства. Переходим на вкладку Делегирование, выставляем там Доверять компьютеру делегирование указанных служб > Использовать только Kerberos и добавляем туда две службы первая — cifs (для миграции хранилищ), вторая — Microsoft Virtual System Migration Service
Все можно теперь мигрировать спокойно.
Если у вас SCVMM
Если у вас есть scvmm, то проверьте, что в свойствах хоста
Перейдите на вкладку Доступ к узлу и проверьте, что в Учетная запись запуска от имени не пуста, если там ничег онет, то через обор добавьте.
Мигрируем через Powershell
- VMName — Имя виртуальной машины
- Hyper-V-ServerName — Имя сервера, куда вы мигрируете
- VMNameFolder — Имя папки, в которую размещается VM
Думаю было не сложно и вы победили свою ошибку 0x8009030E.
Источник
Stunnel error 0x8009030e returned by verifycertchain
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:
Источник
Stunnel error 0x8009030e returned by verifycertchain
Вопрос
I have three servers.
Server A — Windows 2012 data center with Hyper-V role
Server B — Hyper-V 2012 server
Server C — Windows 2012 data center as SMB server
All servers are in the same domain that is a Windows 2003 domain controller. Both server A and B are configured for delegation to each other following the instructions from step by step as this page http://technet.microsoft.com/en-us/library/jj134199.aspx (Configure and Use Live Migration on Non-clustered Virtual Machines). My account is a member of domain admins and is also added into the local administators groups on the both servers.
When I tried to move a virtual machine from server A to server B, I got the following error.
Virtual machine migration operation failed at migration source.
Failed to establish a connection with host ‘serverB’: No credentials are available in the security package (0x8009030E).
The Virtual Machine Management Service failed to authenticate the connection for a Virtual Machine migration at the source host: no suitable credentials available. Make sure the operation is initiated on the source host of the migration, or the source host is configured to use Kerberos for the authentication of migration connections and Constrained Delegation is enabled for the host in Active Directory.
[Expanded Information]
Virtual machine migration operation for ‘share-win7templ-diff1’ failed at migration source ‘serverA’. (Virtual machine ID 250EF943-3A89-4E30-8643-E01563AF3889)
The Virtual Machine Management Service failed to establish a connection for a Virtual Machine migration with host ‘serverB’: No credentials are available in the security package (0x8009030E).
Failed to authenticate the connection at the source host: no suitable credentials available.
Источник
Обновлено 19.06.2017
Всем привет сегодня разберем, как решается ошибка 0x8009030E при миграции виртуальной машины Hyper-V в Windows Server 2012 R2. Напомню миграция — это перемещение виртуальной машины на другой хост виртуализации, и вот во время этого процесса возникает этот неприятный момент.
Давайте подробнее посмотрим как она выглядит, я про 0x8009030E .
Сбой операции миграции виртуальной машины в исходном расположении миграции
Причины ошибки 0x8009030E
Первая причина у вас не включена динамическая миграция Hyper-V, проверить это можно в свойствах хоста виртуализации.
На вкладке Динамическая миграция, должна стоять галка Включить входящие и исходящие миграции.
Вторая причина у вас не включен Kerberos. Если у вас по CredSSp, не удается мигрировать выставляем тогда Kerberos, для большей безопасности, его мы еще поднастроим.
Так же если вы пытаетесь делать миграцию работающей виртуальной машины, удостоверьтесь, что у вас стоит галка в свойствах виртуалки, на вкладке Процессор (Выполнить перенос на физический компьютер с другой версией процессора). Данная галка нужна если у вас разные процессоры, так как не везде все сервера одинаковые.
Если вы выполняете миграцию с рабочей станции, через оснастку Диспетчер Heper-V вы опять словите данную ошибку 0x8009030E, так как данную операцию нужно производить с хоста Hyper-V, где лежит тачка подключенного по RDP, но не спешите расстраиваться, мы же не зря настраивали kerberos, делаем ниже инструкции и радуемся жизни
Для того чтобы kerberos отработал и вы не получили 0x8009030E при миграции виртуальной машины Hyper-V в Windows Server 2012 R2, делаем следующее. Открываем оснастку Active Directory — Пользователи и компьютеры, ищем там ваши компьютеры Hyper-V и переходим в их свойства. Перехлдим на вкладку Делегирование, выставляем там Доверять компьютеру делегирование указанных служб > Использовать только Kerberos и добавляем туда две службы первая — cifs (для миграции хранилищ), вторая — Microsoft Virtual System Migration Service
Все можно теперь мигрировать спокойно.
Если у вас SCVMM
Если у вас есть scvmm, то проверьте, что в свойствах хоста
Перейдите на вкладку Доступ к узлу и проверьте, что в Учетная запись запуска от имени не пуста, если там ничег онет, то через обор добавьте.
Мигрируем через Powershell
Move-VM <VMName> <Hyper-V-Servername> -IncludeStorage -DestinationStoragePath D:Hyper-V<VMNameFolder>
- VMName — Имя виртуальной машины
- Hyper-V-ServerName — Имя сервера, куда вы мигрируете
- VMNameFolder — Имя папки, в которую размещается VM
Думаю было не сложно и вы победили свою ошибку 0x8009030E.
I have put together three similar error types I simulated in my Test laboratory. When you are prompted with the following error when using the invoke-command, the following solutions and explanation below will help you resolve this issue.
Error 1: Below is the command run to install and reboot the TechDArchive
Invoke-Command -ComputerName TechDArchive -Script {ipmo PSWindowsUpdate; Get-WUInstall -AcceptAll -AutoReboot | Out-File C:PSWindowsUpdate.log } -Verbose
Error 2: When you also run the Enter-PSSession to initiate a connection to the remote server the following error above will also be displayed.
Enter-PSSession -ComputerName TechDArchive
Error 3: The invoke-command used to run the script locally or on remote computers. Once remoting is enabled on remote machines, we can run Invoke-Command as shown below to query the WinRM service. But WE are FACED with an ERROR.
Invoke-Command -ComputerName ServerDC -ScriptBlock {Get-Service winrm}
How do we solve this? | Solution: This error is as a result of my login method as you can see in the error message above.
– This issue was as a result of the host machine (Ansibleserver) from where I was trying to connect to. I was logged into the server as a local user with the Administrators account, whereas the remote machine to which I was trying to connect was running as a domain user.
– So, when I switched to the domain user account (Chris) on the host machine, Kerberos started working and the issue got resolved.
As you can see below, the invoke-command is working correctly to get the WinRM service.
Also the invoke-command to have windows updates installed is running executing as well.
Below are the tips to ensure you are able to use the invoke-command.
– Ensure PSRemoting is enabled on the remote device.
– Ensure WinRM is running on the remote device, To determine this, run WinRM using the following command.
– Ensure the computers (servers) are added in the TrustedHosts. Instead of adding an individual host, use the asterisk to all subsequent hosts
For a similar error where the computer account could not be found, see https://techdirectarchive.com/2020/03/25/error-message-winrm-cannot-process-the-request-the-following-error-occurred-while-using-kerberos-authentication-cannot-find-the-computer-serverdc/
I hope you found this blog post helpful. If you have any questions, please let me know in the comment session.
Всем привет сегодня разберем, как решается ошибка 0x8009030E или 0x8009030D при миграции виртуальной машины Hyper-V в Windows Server 2012 R2. Напомню миграция — это перемещение виртуальной машины на другой хост виртуализации, и вот во время этого процесса возникает этот неприятный момент.
Сбой операции миграции виртуальной машины в исходном расположении миграции
И та и другая ошибка связаны с тем что нужно входить на каждый сервер для выполнения определенной задачи (через локальный сеанс консоли, сеанс удаленного рабочего стола или удаленный сеанс Windows PowerShell) с сервера с которого осуществляется миграция либо настроить ограниченное делегирование для хостов.
Поскольку каждый раз входить с сервера на сервер неудобно, я опишу как настроить ограниченное делегирование.
Решения:
На вкладке Динамическая миграция, должна стоять галка Включить входящие и исходящие миграции.
Вторая причина у вас не включен Kerberos. Если у вас по CredSSp, не удается мигрировать выставляем тогда Kerberos, для большей безопасности, его мы еще поднастроим.
Так же если вы пытаетесь делать миграцию работающей виртуальной машины, может возникнуть ошибка VMM:
virtual machine … is using processor-specific features not supported on host…
Для решения, удостоверьтесь, что у вас стоит галка в свойствах виртуалки, на вкладке Процессор (Выполнить перенос на физический компьютер с другой версией процессора). Данная галка нужна если у вас разные процессоры, так как не везде все сервера одинаковые.
Если вы выполняете миграцию с рабочей станции, через оснастку Диспетчер Heper-V вы опять словите данную ошибку 0x8009030E или 0x8009030D, так как данную операцию нужно производить с хоста Hyper-V, где лежит тачка подключенного по RDP, но не спешите расстраиваться, мы же не зря настраивали kerberos, делаем ниже инструкции и радуемся жизни
Для того чтобы kerberos отработал и вы не получили ни 0x8009030E, ни 0x8009030D при миграции виртуальной машины Hyper-V в Windows Server 2012 R2, делаем следующее. Открываем оснастку Active Directory — Пользователи и компьютеры, ищем там ваши компьютеры Hyper-V и переходим в их свойства. Переходим на вкладку Делегирование, выставляем там Доверять компьютеру делегирование указанных служб > Использовать только Kerberos и добавляем туда две службы первая — cifs (для миграции хранилищ), вторая — Microsoft Virtual System Migration Service
Все можно теперь мигрировать спокойно.
Если у вас SCVMM
Если у вас есть scvmm, то проверьте, что в свойствах хоста
Перейдите на вкладку Доступ к узлу и проверьте, что в Учетная запись запуска от имени не пуста, если там ничег онет, то через обор добавьте.
Мигрируем через Powershell
Move-VM <VMName> <Hyper-V-Servername> -IncludeStorage -DestinationStoragePath D:Hyper-V<VMNameFolder>
- VMName — Имя виртуальной машины
- Hyper-V-ServerName — Имя сервера, куда вы мигрируете
- VMNameFolder — Имя папки, в которую размещается VM
Думаю было не сложно и вы победили свою ошибку 0x8009030E.
источник: http://pyatilistnik.org/0x8009030e-hyper-v/
Join @AdmNtsRu on Telegram
Смотрите также:
This answer is not tested as I just start using stunnel, but from documentation I guess:
a) you should drop the verify option, as it is either not complete or not that clear as verifyChain and verifyPeer options and it is obsolete:
verify = LEVEL
verify the peer certificate
This option is obsolete and should be replaced with the verifyChain
and verifyPeer options.
b) verifyChain should check your certificate chain by either using the given in the CAfile or in a file within CApath. For a chain with intermediate certificates all intermediate certificates should be valid against the CA root, that has to be contained in the CA collections (file or path).
c) verifyPeer checks if the certificate itself should be contained in the CAfile or CApath.
Note that actually, without reference to extensions, a root CA certificate is simply just a self-signed certificate, with the CA flag set to yes. Of course such CA certificates are not contained in the set of trusted CAs commonly distributed with browsers or within the operating system. In linux, the CApath, where openssl stores its trusted certificates authorities (/etc/ssl/certs) should do to check against the standard set of trusted certificates. Of course you can add your own CA there too.
The terms /C and /CN are part of the certificates subject, where /C is Country and /CN is the common name. See the output of
openssl x509 -noout -subject </etc/ssl/certs/Deutsche_Telekom_Root_CA_2.pem
subject=C = DE, O = Deutsche Telekom AG, OU = T-TeleSec Trust Center, CN = Deutsche Telekom Root CA 2
as an example. Again: These root certificates are only usefull if you are using verifyChain=yes. If the option is verifyPeer=yes the certificate itself is checked, if you set both to yes, both, the root and the peer certificates, possibly with all intermediates (not checked) will be tested.
From stunnel(8):
cert = CERT_FILE
certificate chain file name
The parameter specifies the file containing certificates used by
stunnel to authenticate itself against the remote client or server.
The file should contain the whole certificate chain starting from
the actual server/client certificate, and ending with the self-
signed root CA certificate. The file must be either in PEM or P12
format.
I guess that the root CA certificates need not to be contained in the chain actually. Most configurations don’t have that, but it should be seen as a good virtue to know the whole chain, so why not add it to the file!
Now we can check if a certificate is valid, but we still don’t know how to check if the certificate really belongs to a peer. The peer might have stolen a valid certificate and tries to use it now.
In stunnel we have now:
checkEmail, to check the DN (distinguished name or directory name) field in the subject or in the Subject Alternative Name (rfc822Name (see RFC280)) extension (X509v3).
checkHost, check for the DNS Name of the certificate. This might be hard to use or unusable for client certificate checks.
checkIP, the IP address of the certificate is checked.
In the manual it reads "Certificates are accepted if no subject checks where specified". I don’t actually understand this, because I think the checkIP, checkHost and checkEmail fields are the "subject checks" and it is hard to specify a checkEmail subject check, while "no subject checks are specified".
I guess they mean «no other subject check». Of course if no subject check at all is specified, the certificate should be good if its valid.
Note that Host and IP from the certificate is checked and there is no word about if it is compared with the Hostname or IP of the peer when the connection is made, as it is done when communicating whith HTTPS servers, where the CN must match the Hostname or the DNS Name in the alternatives or the IP in the alternatives.
All these side cases are untested and they might have skipped some of the documentation.
Also the subject checks are redundant if you use verifyPeer as verifyPeer contains the whole peer certificate with subject and alternatives and so on.
I cannot see that the certificate usage fields is checked somewhere. If it is, this point is missing in the documentation!
I will post an update when I checked all the side cases.
Hi everyone, my name is Tobias Kathein and I’m a Senior Engineer in Microsoft’s Customer Success Unit. Together with my colleagues Victor Zeilinger, Serge Gourraud and Rodrigo Sanchez from Customer Service & Support we’re going to discuss a real-world scenario in which a customer was unable to live migrate Virtual Machines in his newly set up Hyper-V environment.
In our scenario the customer was trying to initiate a Live Migration for a Virtual Machine from a remote system. This is quite a common scenario, that administrators open the Hyper-V Management console on an administrative Remote Desktop Services server and initiate the Live Migration of a VM between two Hyper-V hosts. The customer got doubts whether this is even opposed to work. Just to rule this one out upfront. Yes, it is opposed to work.
The customer was complaining that this isn’t working for him in his environment even though he set up the delegation correctly and enabled Kerberos as authentication protocol for Live Migrations. The issue wasn’t with a particular Virtual Machine, as all, even newly created VMs failed to be moved to another host. No matter if the Hyper-V Management console or the PowerShell Cmdlet Move-VM is used both fail. The error message returned is “No credentials are available in the security package (0x8009030E)”. The full error message including some additional details is shown below.
Even though the red error message in PowerShell looks a little bit fancier, it is the same error message that is returned telling us that there are no suitable credentials available. So, you can be assured the issue is not with the Hyper-V Management console nor with the Move-VM Cmdlet, because neither of them is working.
There are multiple reasons why Live Migrations fail with the message “No Credentials are available in the security package (0x8009030E).”
The most known cause of this issue is the absence a correct Kerberos Constrained Delegation. Either Kerberos Delegation is missing completely or for single services like in this case for CIFS or the Microsoft Virtual System Migration Service. Also don’t mix up the Microsoft Virtual System Migration Service with the Microsoft Virtual Console Service which can happen quite easily when using ADUC to configure Constrained Delegation as you can see below. The default column size doesn’t show what’s what.
Finding out which Kerberos Delegation entries have been configured is a little bit unclear in the ADUC. An easier way to verify all required entries are present is to run the following PowerShell command.
get-adcomputer -Identity [ComputerAccount goes here] -Properties msDS-AllowedToDelegateTo | select -ExpandProperty msDS-AllowedToDelegateToStarting Windows Server 2016 there is the need to select “Use any authentication protocol” when setting up the Kerberos Delegation, instead of “Use Kerberos only”. This is due to some changes made in the operating system that require protocol transition. Protocol transition is only possible if the above-mentioned option is selected. On systems older than Windows Server 2016 selecting “Use Kerberos only” is sufficient. If “Use any authentication protocol” was not selected, Live Migration initiated from remote hosts will fail.
The error message also appears when trying to move a VM and the account that is being used to initiate the Live Migration is member of the Protected Users group. Members of this group automatically have non-configurable protections applied to their accounts. Among other things the user’s credentials are not allowed to be passed along and therefore Live Migration will not work when initiated from a remote system.
Another possibility why Live Migrations fail with this error message is when the user account being used to initiate the Live Migration has the option “Account is sensitive and cannot be delegated” set to enabled. This is sometimes configured to avoid highly privileged accounts to ensure that the credentials of these accounts cannot be forwarded by a trusted application to another computer or service. However, accounts having configured this setting cannot be used to initiate a Live Migration between two Hyper-V from a third machine.
And that’s it. We hope to have shed some light on this topic and the posting was helpful for you. Thanks for reading and never stop live migrating.
Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.