Semen_Se |
|
|
Статус: Новичок Группы: Участники
|
Доброго времени суток! Настраиваю интеграцию с ГИИС ДМДК, сделал все как в инструкции. Служба запускается, но связи нет и в логах следующее: Пробовал и х64, и win32 — результата нет В один момент решил скачать и запустить stunnel_msspi.exe — первый раз вышло окно с логом [server down], Сейчас я уже совсем в растерянности и не могу понять при каких условиях вообще связь появляется. (пока писал пост, решил проверить и запустил stunnel_msspi.exe двойным кликом — запустился зеленым в трее, Как сделать, чтобы stunnel стабильно работал автоматически, без танцев и костылей? |
 |
|
|
two_oceans |
|
|
Статус: Эксперт Группы: Участники Сказал(а) «Спасибо»: 110 раз |
Добрый день. Цитата: E_NO_CREDENTIALS: 0x8009030e Цитата: Как сделать, чтобы stunnel стабильно работал автоматически, без танцев и костылей? Полагаю, проблема в отсутствии прав пользователя, под которым запускается служба, на контейнер или в отсутствии сертификата в хранилище компьютера. Вкратце, если служба запускается под локальной системой, то хранить контейнер в реестре не выйдет. Как самый простой вариант, можно изменить пользователя, под которым запускается служба, на текущего (из-под которого работает запуск двойным кликом). Однако использование текущего пользователя для служб не рекомендовано из-за риска повредить реестр при внезапной остановке службы. Еще может быть не установлен криптопровайдер уровня ядра, он нужен для доступа к ключам гост из служб. Попробуйте «изменить» установку Криптопро CSP и проверить, что этот компонент установлен. Рекомендовано такое: скопировать контейнер вместо Реестра на другой считыватель (флешка/токен/несистемный раздел диска/Директория); установить сертификат в хранилище компьютера со ссылкой на контейнер компьютера (это можно сделать, перезапустив панель управления КриптоПро в режиме администратора и выбрав переключатель «компьютера»). Далее дать права на него через остнастку сертификаты (локальный компьютер — хранилище Личное — правой кнопкой мыши по нужному сертификату — все задачи — управление закрытыми ключами — дать нужному пользователю (системе, например) полные права). После этого служба сможет найти ключ и использовать его. Двойным же кликом Вы запускаете от текущего пользователя для которого сертификат и контейнер установлены и доступны — значок зеленый. Если на компьютере не требуется работа тоннеля когда никто не залогинен, то можно убрать службу, а ярлык на stunnel_msspi.exe закинуть в автозагрузку. По поводу «не всегда запускается» дело возможно в том, что служба и приложение используют один конфиг и слушают один порт (ну 1С же настроен на конкретный порт). С этим есть ограничение сокетов в Windows — 2 процесса не смогут слушать один и тот же адрес:порт, один из них завершается с ошибкой, что порт уже занят. Следовательно, хороший шанс что порт займет служба (не имеющая доступа к ключу), а завершится приложение (если stunnel_msspi вообще автозапускается) (который имеет доступ к ключу) и ничего работать не будет. Нужно из разнести на разные порты или оставить что-то одно. Отредактировано пользователем 10 марта 2022 г. 1:54:58(UTC) |
|
|
|
| Пользователи, просматривающие эту тему |
|
Guest |
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
dubinin.nik |
|
|
Статус: Новичок Группы: Участники Сказал(а) «Спасибо»: 2 раз |
Прошу помощи! Настраиваю интеграцию с ГИИС ДМДК! Сделал все как по инструкции по «ОПИСАНИЕ ИНТЕГРАЦИОННОГО СЕРВИСА». В конфиг файле Цитата: output=c:stunnelstunnel.log Настроил как сервис от нового пользователя, все пароли сохранил — все супер. После танцев с бубном сервис стартует автоматом и работает. В лог все пишется. А вот дальше начинается самое интересное. Все общение с туннелем заканчивается на уровне хендшейка и дальше тишина.. Вот пример лог файла: Цитата: 2022.01.27 11:08:37 LOG5[21404:7348]: stunnel 4.18 on x86-pc-unknown При попытке протестировать согласно документации через SoapUI — при создании нового проекта выдается ошибка Цитата: Error loading [http://127.0.0.1:1500/ws/v1/exchange.wsdl]: java.lang.Exception: Failed to load url; http://127.0.0.1:1500/ws/v1/exchange.wsdl, 0 При попытке запустить тестирование интеграции через 1С Розница — Ювелирный магазин от 1С Рарус — Интеграция с ГИИС ДМДК — при нажатии Проверить подключение — 1С зависает. Помогите господа разработчики! Отредактировано пользователем 27 января 2022 г. 12:37:37(UTC) |
 |
|
|
two_oceans |
|
|
Статус: Эксперт Группы: Участники Сказал(а) «Спасибо»: 110 раз |
Добрый день. Если совсем в идеале также слушать на портах 80 и 443 (если они у Вас свободны и соединение одно), но для wsdl скорее всего не понадобится до такого доходить. Дело в том, что сейчас очень много ГИС, которые через один внешний ip предоставляют доступ к разным внутренним ресурсам. Для выбора ресурса используется строка Host из http запроса, а иногда также и порт. Когда Вы в браузере (SoapUI, 1С) указываете 127.0.0.1 это значение идет в строку Host из http запроса и шлюзовой сервер на той стороне оказывается в ступоре куда Вы хотите подключиться. |
|
|
|
|
|
dubinin.nik
оставлено 17.05.2022(UTC) |
1 пользователь поблагодарил two_oceans за этот пост.|
al1111 |
|
|
Статус: Новичок Группы: Участники
|
Подскажите пожалуйста аналогичная проблемма вот только у нас в сертификате output=c:stunnelstunnel.log Как быть? |
|
|
|
|
two_oceans |
|
|
Статус: Эксперт Группы: Участники Сказал(а) «Спасибо»: 110 раз |
Автор: al1111 Подскажите пожалуйста аналогичная проблемма вот только у нас в сертификате Как быть? Что-то вы вообще странное творите: прочитайте еще раз внимательнее. Цитата: Полное доменное имя (если неизвестно) можно взять из сертификата сервера. 1) Зачем Вы ориентируетесь на свой сертификат клиента с CN = ООО»Рога копыта». Каким он боком относится к серверу? Аналогия — шли по улице, сертификат лежит и думаете «а не вписать ли его в конфиг»? Если точнее, то имеется ввиду сертификат удаленного сервера, к которому соединяетесь stunnel ом, то есть сервера, указанного в строке connect. Имя не обязательно в CN, может быть в Альтернативных именах владельца. Вот только в конфиге в строке connect написан IP адрес, а вам нужно найти имя этого сервера. Это можно сделать либо через DNS командой типа nslookup 19.130.209.195.in-addr.arpa (цифры из IP в обратном порядке) либо посмотрев сертификат, который при коннекте на 195.209.130.19:443 предоставляет сервер. В DNS ГИС частенько ничего не регистрируют (первая команда дает non-existent domain), потому проще смотреть сертификат. Сохранить сертификат удаленного сервера можно утилитой csptest в командной строке Код: Здесь уже учтено: адрес сервера, адрес wsdl, wsdl не сохраняется, указан сертификат клиента, выводятся подробные данные, не проверяется цепочка сертификатов клиента и сервера, сертификат сервера сохраняется в файл d:195_209_130_19.p7b. Цепочка сервера не проверяется, потому что, как оказалось, он выдан тестовым сервером КриптоПро, а добавлять тестовый УЦ в доверенные не очень разумно. Имя оказалось типа *.goznak.ru, то есть желательно вместо звездочки еще что-то подобрать. Для примера я возьму стандартное www, но возможно больше подойдет dmdk. Перед этим стоит еще 20211217 и пробел — такое имя проверку не пройдет. хотя возможно такой ответ на мой сертификат, а Вам ответит сервер что-то более квалифицированное. 2) 127.0.0.1 dacha-ПК тоже не вариант, удаленный сервер не знает про такое имя. Код: в hosts Код: в 1с/browser/soapui тестируете адрес Код: WSDL у меня браузер получил, значит имя www.goznak.ru допустимо, но дальше нежданчик в WSDL: Код: То есть для корректной работы soapui stunnel должен слушать на 80 порту, а не на 1500. Отредактировано пользователем 10 февраля 2022 г. 8:23:53(UTC) |
|
|
|
|
basid |
|
|
Статус: Активный участник Группы: Участники Сказал(а) «Спасибо»: 6 раз |
Автор: two_oceans Вот только в конфиге в строке connect написан IP адрес, а вам нужно найти имя этого сервера. В системе разрешения доменных имён прямая и обратная зоны — две разные зоны. P.S. |
|
|
|
|
two_oceans |
|
|
Статус: Эксперт Группы: Участники Сказал(а) «Спасибо»: 110 раз |
Автор: basid В системе разрешения доменных имён прямая и обратная зоны — две разные зоны. Соглашусь частично, что разные и связи нет. Однако все же мне кажется не обошлось без бииип местных провайдеров (забивающих фейковые имена типа 1.2.3.xsdl.my-super-provider.ru) и сисадминов ведомств, (которым нормально купить домен, но ненормально зарегистрировать его PTR в обратных зонах dns провайдера). Автор: basid P.S. nslookup достаточно «интеллектуален», чтобы вернуть имя по IP-адресу. Вот это Вы мне точно америку открыли. Почему-то пока я вручную не сменю тип запроса на PTR он мне возвращает тоже что я написал (8.8.8.8.in-addr.arpa) даже хотя запись есть. Сменю — покажет dns.google. Так что укажите, пожалуйста, ОС на которой он отрастил-таки интеллект. |
|
|
|
|
basid |
|
|
Статус: Активный участник Группы: Участники Сказал(а) «Спасибо»: 6 раз |
Код: Windows 7. Как оно было на NT4 и Windows 2000 — уже не помню, но на XP/2003 — работало точно также. |
|
|
|
|
basid |
|
|
Статус: Активный участник Группы: Участники Сказал(а) «Спасибо»: 6 раз |
Автор: two_oceans Однако все же мне кажется не обошлось без бииип местных провайдеров (забивающих фейковые имена типа 1.2.3.xsdl.my-super-provider.ru) Это никакие не фейки. |
|
|
|
|
dubinin.nik |
|
|
Статус: Новичок Группы: Участники Сказал(а) «Спасибо»: 2 раз |
Автор: two_oceans Добрый день. Если совсем в идеале также слушать на портах 80 и 443 (если они у Вас свободны и соединение одно), но для wsdl скорее всего не понадобится до такого доходить. Дело в том, что сейчас очень много ГИС, которые через один внешний ip предоставляют доступ к разным внутренним ресурсам. Для выбора ресурса используется строка Host из http запроса, а иногда также и порт. Когда Вы в браузере (SoapUI, 1С) указываете 127.0.0.1 это значение идет в строку Host из http запроса и шлюзовой сервер на той стороне оказывается в ступоре куда Вы хотите подключиться. в общем проблема у меня все таки не в адресах и хостсах. SoapUI как по айпи 127.0.0.1:1500 так и по доменному имени после прописания в хостс — ломится и выдает один и тот же лог. Проблема с сертификатом. Дело в том, что я уже даже сертификат новый в налоговой получил, установил в систему и экспортировал в clicer.cer И все равно ошибка одна и та же 022.05.17 11:26:21 LOG7[10208:17556]: https connecting до сих пор в ступоре |
|
|
|
|
dubinin.nik |
|
|
Статус: Новичок Группы: Участники Сказал(а) «Спасибо»: 2 раз |
Помогло решение описанное в посте https://www.cryptopro.ru…&m=133280#post133280 А именно, я сделал все по новому вот так: 1) Проверил, что служба STunnel запускается от имени системы. Тут важен шаг 2 и 3, т.к. как я понял при экспорте сертификата в нем указывается ссылка на конт. закр. ключа. |
|
|
|
| Пользователи, просматривающие эту тему |
|
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.
Источник
Содержание
- Stunnel error 0x8009030e authenticating server credentials
- Причины ошибки 0x8009030E
- Если у вас SCVMM
- Мигрируем через Powershell
- Веб — сервис интеграции
- Stunnel error 0x8009030e authenticating server credentials
- Вопрос
- Stunnel error 0x8009030e authenticating server credentials
- Question
- Answers
- Common Windows Security Errors
- Description of Security Errors 80090302, 8009030D, 8009030E, 80090304, 80090308, 80090325, 80090326, 80090327, 80090331, 8009035D, 8009030F, 80090321
- Errors
- 0x80090302
- Possible Solutions
- 0x8009030D
- Possible Solutions
- 0x8009030E
- Possible Solutions
- 0x80090304
- 0x80090308
- Possible Causes
- 0x80090325
- 0x80090326
- Possible Solutions
- 0x80090327
- 0x80090331
- 0x8009035D
- Possible Solutions
- 0x8009030F or 0x80090321
Stunnel error 0x8009030e authenticating server credentials
Всем привет сегодня разберем, как решается ошибка 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)
Источник
Stunnel error 0x8009030e authenticating server credentials
Вопрос
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.
Источник
Stunnel error 0x8009030e authenticating server credentials
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:
Источник
Common Windows Security Errors
Description of Security Errors 80090302, 8009030D, 8009030E, 80090304, 80090308, 80090325, 80090326, 80090327, 80090331, 8009035D, 8009030F, 80090321
Date Entered: 06/10/2015 Last Updated: 04/09/2018
Errors
0x80090302
Possible Solutions
This can be done on any of the components that support SSL by using the SSLEnabledProtocols configuration setting. As an example setting the Icharge component to use TLS 1.2 would look like this
Please note the documentation linked above is specifically for the current .NET Editions. For other editions or older versions please reference the help file included with the product.
0x8009030D
Possible Solutions
Using OpenSSL, the certificate can be converted with the command:
openssl pkcs12 -export -passout pass:»» -in cert_key_pem.txt -out cert_key_out.pfx -name «My Certificate»
Then change the SSLCertStoreType to PFXFile in your code, before setting the SSLCertSubject.
0x8009030E
Possible Solutions
0x80090304
- This error may to be related to Windows rejecting weak security. Microsoft KB 3061518 explains the issue. To summarize the article, simply set the ClientMinKeyBitLength DWORD value at the following location to 00000200 .
After a restart, if this corrects the issue, then it is an indication that the server’s certificate uses a DHE Key length that is too small and should be updated.
0x80090308
Possible Causes
0x80090325
The SSL client certificate specified in the request was not accepted by the server. During the SSL handshake the issuer certificates of the SSL client certificate are not included. In Linux the OpenSSLCADir configuration setting must be set to the directory where the hash files exist so the chain is included. In Windows the issuer certs must be in the Personal store. In Java, the issuer certificates are read from the PEM file.
0x80090326
Possible Solutions
0x80090327
This usually means that the server requires SSL client authentication and a new certificate is specified. Check the SSLStatus Event for details.
0x80090331
Most commonly, especially with Windows XP/Windows Server 2003, the client is probably old and doesn’t support the newer ciphers required by the server. Here is a list of ciphers supported in XP.
0x8009035D
Possible Solutions
0x8009030F or 0x80090321
These errors are known to occur on Windows 8.1 and Windows Server 2012 R2 when using TLS 1.2 and one of the following cipher suites:
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
The aforementioned versions of Windows have a bug in their internal security implementations which, under very specific circumstances, can produce either the 0x80090321 (SEC_E_BUFFER_TOO_SMALL) error or the 0x8009030F (SEC_E_MESSAGE_ALTERED) error.
Due to the nature of the issue, we cannot provide a direct fix. However, you can work around these errors by doing one of the following things:
- Use our internal security API by passing the string «UseInternalSecurityAPI=True» to the Config() method. Our internal security API does not rely on the Windows security APIs, so it is not affected by the bug.
- Disable the two cipher suites mentioned above
- Disable support for TLS 1.2
- Upgrade your machine to a newer version of Windows
Источник
With a hint from RbMm, I then found this article:
https://www.codeproject.com/articles/125124/how-to-use-certificate-from-disk-with-microsoft-cr
The short answer is that CryptAcquireCertificatePrivateKey() needed to be used when loading a PFX from a file, and UNISP_NAME_A needed to be passed to AcquireCredentialsHandleA().
For reference, here is the revised code:
HRESULT CTLSPackage::LoadCertContextFromFilePFX (PCWSTR pcwzFile, PCWSTR pcwzPassword, __deref_out PCCERT_CONTEXT* ppctxCert)
{
HRESULT hr;
HANDLE hFile, hSection = NULL;
BOOL (WINAPI* pfnPFXIsPFXBlob)(CRYPT_DATA_BLOB*);
HCERTSTORE (WINAPI* pfnPFXImportCertStore)(CRYPT_DATA_BLOB*, LPCWSTR, DWORD);
PCCERT_CONTEXT (WINAPI* pfnCertFindCertificateInStore)(HCERTSTORE hCertStore, DWORD dwCertEncodingType, DWORD dwFindFlags, DWORD dwFindType, const void* pvFindPara, PCCERT_CONTEXT pPrevCertContext);
BOOL (WINAPI* pfnCryptAcquireCertificatePrivateKey)(PCCERT_CONTEXT pCert, DWORD dwFlags, void* pvReserved, HCRYPTPROV_OR_NCRYPT_KEY_HANDLE *phCryptProvOrNCryptKey, DWORD* pdwKeySpec, BOOL* pfCallerFreeProvOrNCryptKey);
HCRYPTPROV_OR_NCRYPT_KEY_HANDLE hProv;
DWORD dwKeySpec;
BOOL fFreeProv = FALSE;
CRYPT_DATA_BLOB blob; blob.pbData = NULL;
HCERTSTORE hpfxStore = NULL;
hFile = CreateFile(pcwzFile, FILE_READ_DATA, FILE_SHARE_READ, 0, OPEN_EXISTING, 0, 0);
CheckIfGetLastError(INVALID_HANDLE_VALUE == hFile);
blob.cbData = GetFileSize(hFile, NULL);
hSection = CreateFileMapping(hFile, 0, PAGE_READONLY, 0, 0, 0);
CheckIfGetLastError(NULL == hSection);
blob.pbData = reinterpret_cast<PBYTE>(MapViewOfFile(hSection, FILE_MAP_READ, 0, 0, 0));
CheckIfGetLastError(NULL == blob.pbData);
Check(TGetFunction(m_hCrypt32, "PFXIsPFXBlob", &pfnPFXIsPFXBlob));
Check(TGetFunction(m_hCrypt32, "PFXImportCertStore", &pfnPFXImportCertStore));
Check(TGetFunction(m_hCrypt32, "CertFindCertificateInStore", &pfnCertFindCertificateInStore));
Check(TGetFunction(m_hCrypt32, "CryptAcquireCertificatePrivateKey", &pfnCryptAcquireCertificatePrivateKey));
CheckIf(!pfnPFXIsPFXBlob(&blob), HRESULT_FROM_WIN32(ERROR_BAD_FORMAT));
hpfxStore = pfnPFXImportCertStore(&blob, pcwzPassword, 0);
if(NULL == hpfxStore && pcwzPassword && L'' == *pcwzPassword)
{
hpfxStore = pfnPFXImportCertStore(&blob, NULL, 0);
CheckIf(NULL == hpfxStore, SEC_E_NO_CREDENTIALS);
}
*ppctxCert = pfnCertFindCertificateInStore(hpfxStore, X509_ASN_ENCODING | PKCS_7_ASN_ENCODING, 0, CERT_FIND_ANY, NULL, NULL);
CheckIfGetLastError(NULL == *ppctxCert);
// Acquire the private key and make it available for the later AcquireCredentalsHandle() call.
if(!pfnCryptAcquireCertificatePrivateKey(*ppctxCert, 0, NULL, &hProv, &dwKeySpec, &fFreeProv))
{
DWORD dwError = GetLastError();
FreeCertificateContext(*ppctxCert);
*ppctxCert = NULL;
CheckWin32Error(dwError);
}
Cleanup:
if(fFreeProv)
FreeProvOrNCryptKey(hProv, dwKeySpec);
if(hpfxStore)
{
BOOL (WINAPI* pfnCertCloseStore)(HCERTSTORE, DWORD);
if(SUCCEEDED(TGetFunction(m_hCrypt32, "CertCloseStore", &pfnCertCloseStore)))
pfnCertCloseStore(hpfxStore, 0);
}
if(blob.pbData)
UnmapViewOfFile(blob.pbData);
SafeCloseHandle(hSection);
SafeCloseFileHandle(hFile);
return hr;
}
HRESULT CTLSPackage::AcquireCredentials (__in_opt PCCERT_CONTEXT pCertContext, PCredHandle phCreds)
{
SCHANNEL_CRED SchannelCred;
TimeStamp tsExpiry;
ZeroMemory(&SchannelCred, sizeof(SchannelCred));
SchannelCred.dwVersion = SCHANNEL_CRED_VERSION;
if(pCertContext)
{
SchannelCred.cCreds = 1;
SchannelCred.paCred = &pCertContext;
}
SchannelCred.grbitEnabledProtocols = SP_PROT_SSL3 | SP_PROT_TLS1 | SP_PROT_TLS1_1 | SP_PROT_TLS1_2;
SchannelCred.dwFlags = SCH_USE_STRONG_CRYPTO;
if(!m_fServer)
SchannelCred.dwFlags |= SCH_CRED_NO_DEFAULT_CREDS;
//
// Create an SSPI credential.
//
return m_pSSPI->AcquireCredentialsHandleA(
NULL, // Name of principal
UNISP_NAME_A, // Name of package
m_fServer ? SECPKG_CRED_INBOUND : SECPKG_CRED_OUTBOUND,
NULL, // Pointer to logon ID
&SchannelCred, // Package specific data
NULL, // Pointer to GetKey() func
NULL, // Value to pass to GetKey()
phCreds, // (out) Cred Handle
&tsExpiry); // (out) Lifetime (optional)
}
- Remove From My Forums
-
Question
-
Hi all,
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 successfullyI’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»
You can also
download the screen shot hereHas anybody expierenced this before? Any help is appreciated ! THanks!
Answers
-
*********RESOLVED**********
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:
REQUEST — openssl.exe req -config YOUROWN.cfg -new -keyout private.pem -out request.pem -days 365
CONVERT to PFX — openssl.exe pkcs12 -export -in PROVISIONCERT.pem -inkey private.pem -out FINALPROVCERT.pfx -name «Intel vPro» -password «pass:XXXXXXX»
-
Marked as answer by
Tuesday, May 18, 2010 4:33 PM
-
Marked as answer by
Обновлено 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.
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.