Ошибка поддержки безопасных каналов криптопро

.

Каждый компьютер, присоединяемый к домену (клиентская рабочая станция, сервер или DC), требует подключения к DC для обеспечения выполнения обязательных требований по обслуживанию в домене AD. Для рабочих станций и серверов необходимо подключение к DC того домена, которому они принадлежат, а также к DC доменов-доверителей. DC одного домена должны иметь связь с DC доменов-доверителей и доверенных доменов. Кэшированные значения, определяющие междоменные соединения, описываются термином «безопасный канал домена». Существует два типа безопасных каналов: между членом домена и DC этого же домена; между DC домена-доверителя и DC доверенного домена.

Значение безопасных каналов

Почему нужно заботиться об исправности безопасного канала? Дело в том, что все службы, связанные с доменом, в той или иной степени используют безопасный канал. Нет доступа к групповой политике? Недоступен сетевой ресурс? Не удается зарегистрироваться в домене? Во всех этих случаях следует проверить работу безопасного канала. Конечно, подобные неисправности могут быть вызваны и другими причинами, но лишь немногие из них сложнее в диагностике и более широко распространены, чем проблемы безопасного канала.

Для чего нужен безопасный канал? Напрашивается ответ: «для всего, что связано с доменом». Все службы, связанные с доменом, должны иметь возможность обнаружения DC для отправки запроса. Это верно как для члена домена (например, рабочей станции или рядового сервера), так и для DC. Обеспечение доступности эффективно реагирующего DC — функция безопасного канала. Если с сервером нельзя связаться и отправить запрос, то службы не работают.

В частности, пользователь, подключающийся к сайту SharePoint, настроенному на работу с Kerberos, должен запросить билет Kerberos, предъявляемый серверу SharePoint для авторизации. Компьютер пользователя просматривает кэшированные данные о безопасном канале домена (кэш, обслуживаемый службой NetLogon), определяя целевой DC для отправки запроса на билет Kerberos. Если по какой-либо причине DC не отвечает, то запрос на билет не формируется, и аутентификация с использованием Kerberos при подключении к SharePoint не работает. В зависимости от архитектуры SharePoint, результатом может быть отказ в доступе к сайту – и все из-за проблемы безопасного канала.

Рассмотрим типовой мультидоменный сценарий. Предположим, что пользователь из домена A регистрируется в системе на компьютере B в домене B. Регистрация пользователя обрабатывается в соответствии с групповой политикой, и на DC домена А по протоколу LDAP посылается запрос с тем, чтобы определить, какая политика применима к пользователю А. Как компьютер B, принадлежащий домену B, узнает, куда отправлять сетевой трафик, чтобы выяснить применяемую политику домена А? Это возможно благодаря тому, что сведения о сетевом расположении домена и DC постоянно обновляются. Актуальность информации поддерживается службой NetLogon на каждом компьютере, присоединенном к домену Windows. NetLogon постоянно формирует список доступных DC и доменов (при наличии отношений доверия). На экране 1 приведен фрагмент журнала отладки NetLogon, иллюстрирующий этот непрерывный процесс. Вы можете просмотреть журнал отладки NetLogon на своем компьютере, следуя инструкциям, приведенным в статье Microsoft «Enabling debug logging for the NetLogon service» (http://support.microsoft.com/kb/109626).

Экран 1. Фрагмент журнала отладки NetLogon

На верхнем уровне проблемы безопасного канала могут быть сведены к неполадкам сетевого подключения. Если проблемы с подключением носят перемежающийся характер, то все службы работают тогда, когда работает сеть. Постоянные проблемы подключения порождают ситуацию неисправного безопасного канала, что, в свою очередь, приводит к несовпадению общего секрета между компьютером и AD, в результате чего компьютер перестает быть доверенным. Совокупный эффект заключается в том, что никто не может войти в домен и получить доступ к доменным ресурсам.

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

Выявление проблемы безопасного канала

Лучший способ обнаружить проблему безопасного канала – задействовать функцию I_NetLogonControl2. I_NetlogonControl2 – это одна из функций, используемых службой NetLogon (она есть на любом компьютере с Windows любой версии) для поддержания сведений о доступных доменах и DC.

В распоряжении администратора есть три простых инструмента для вызова этой функции и быстрого получения информации о возможности подключения к определенному домену и DC: NLTest, PowerShell и WMI.

NLTest.exe. Утилита NLTest.exe была выпущена в комплекте средств поддержки Windows 2000 и Windows Server 2003 и включена по умолчанию в большинство более новых версий Windows. Параметр sc_verify вызывает I_NetlogonControl2, и вам остается указать проблемный домен.

C:>nltest /sc_verify:americas
Flags: b0 HAS_IP HAS_TIMESERV
Trusted DC Name DD3-AM-DC-03.americas.fabrikam.com
Trusted DC Connection Status Status = 0 0x0 NERR_Success
Trust Verification Status = 0 0x0 NERR_Success
The command completed successfully

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

PowerShell. В PowerShell 2.0 добавлена команда PowerShell Test-ComputerSecureChannel, которая также вызывает I_NetLogonControl2, но обеспечивает минимум информации, возвращая ответ True, если безопасный канал домена исправен, а DC доступен, либо, в противном случае, ответ False.

PS C:> Test-ComputerSecureChannel
True

Подобно NLTest.exe, команда Test-ComputerSecureChannel может применяться и для исправления ошибки с использованием ключа Repair.

WMI. С помощью класса win32_ntdomain инструментарий управления Windows (WMI) позволяет запросить все домены, о которых знает компьютер. WMI полезен в случаях, когда на тестируемом компьютере нельзя рассчитывать на средства PowerShell. Заметим, что в приведенном ниже примере (где Win32_NTDomain вызывается через команду PowerShell Get-WMIObject с использованием псевдонима GWMI) в качестве ответа возвращается только локальный домен, но может быть возвращен любой домен, связанный с локальным доменом отношениями доверия.

PS C:> gwmi win32_ntdomain
ClientSiteName: TX
DcSiteName: TX
Description: AMERICAS
DnsForestName: americas.fabrikam.com
DomainControllerAddress: 
DomainControllerName: DD3-AM-DC-03
DomainName: AMERICAS
Roles:
Status: OK

Заметим, что состояние OK в этом примере соответствует ответу True или False, возвращаемому командой Test-ComputerSecureChannel, и указывает на работоспособность или неработоспособность безопасного канала.

Устранение проблемы безопасного канала

Пользователям, обращающимся в службу поддержки Microsoft, высылается дополнительный пакет сбора данных. Вместо собственной команды PowerShell Test-ComputerSecureChannel в пакете используется WMI-класс Win32_NTDomain (вызываемый из PowerShell), что позволяет запускать тест даже на более старых операционных системах, таких как Windows XP и Windows 2003. Для иллюстрации применения теста ниже приведены два примера сценариев, которые можно самостоятельно запустить в окне PowerShell, см. листинг 1 и листинг 2.

В первом примере выполняется сбор информации о безопасном канале текущего домена, а также основных сведений о лесе. На экране 2 приведены результаты.

Экран 2. Результаты работы первого сценария

Для выявления любой проблемы создается тест как сценарий PowerShell (файл. ps1), а к возвращаемому состоянию добавляется условный оператор ‘if’. Можно также указать имя домена, как показано в примере, показанном в Листинге 2.

В практике диагностики Microsoft этот сценарий превращен в простую функцию, которую можно использовать повторно.

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

PowerShell
Get-Date >> $OutputFileName
$ComputerName = Get-WmiObject -Class Win32_ComputerSystem
$OutputFileName = Join-Path $Pwd.Path ($ComputerName.Name + «_Secure Channels.txt»)
$domain = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
«This computers domain information is:» >> $OutputFileName
$domain >> $OutputFileName
«This computers secure channel information is:» >> $OutputFileName
gwmi Win32_NTDomain >> $OutputFileName

PowerShell
$Domain = «americas»
function SecureChannelCheck
{
#Function to give a simple «good» or «bad» result for secure channel health.
#Accepts a flat domain name--not entire FQDN--as input.
#To run as a script, not a function, just replace $DomainName with $env:userdomain.
param ($DomainName)
$v = «select * from win32_ntdomain where domainname = '» + $DomainName + «'»
$v2 = get-wmiobject -query $v
if ($v2.Status -eq «OK")
{Write-Host»The domain secure channel is OK.«}
elseif (($v2 -eq $null) -or ($v2 -ne»OK«))
{Write-Host»The domain secure channel has problems."}
}
SecureChannelCheck($Domain)

andreykochegura	#1 Оставлено : 5 февраля 2020 г. 14:38:51(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 05.09.2019(UTC) Сообщений: 5 Откуда: спб	Здравствуйте, возникает ошибка при попытке установить защищенное соединение с ГИС ЖКХ с помощью stunnel Цитата: Status code: -2147352567 Source: WinHttp.WinHttpRequest Description: Ошибка поддержки безопасных каналов Stunnel 5.0.14413.0 КриптоПро SCP 5.0.11455 КС1 Stunnel работает в режиме службы под пользователем Соединение настраиваю на виртуальной машине Windows Server 2019 Доступ к закрытой части ключа на флешке с помощью утилиты AnywhereUSB Прокси сервер отключен Конфиг stunnel.conf Лог stunnel

Дмитрий Пичулин	#2 Оставлено : 5 февраля 2020 г. 14:43:46(UTC)
Статус: Сотрудник Группы: Администраторы Зарегистрирован: 16.09.2010(UTC) Сообщений: 1,368 Откуда: КРИПТО-ПРО Сказал(а) «Спасибо»: 31 раз Поблагодарили: 320 раз в 261 постах	Автор: andreykochegura Здравствуйте, возникает ошибка при попытке установить защищенное соединение с ГИС ЖКХ с помощью stunnel Цитата: Status code: -2147352567 Source: WinHttp.WinHttpRequest Description: Ошибка поддержки безопасных каналов Stunnel 5.0.14413.0 КриптоПро SCP 5.0.11455 КС1 Stunnel работает в режиме службы под пользователем Соединение настраиваю на виртуальной машине Windows Server 2019 Доступ к закрытой части ключа на флешке с помощью утилиты AnywhereUSB Прокси сервер отключен Ошибок в работе stunnel не видно, похоже ошибка в запросах которые вы отправляете через stunnel.
Знания в базе знаний, поддержка в техподдержке
	WWW

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

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

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

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

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

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

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

Обновлено 28.11.2022

Добрый день! Уважаемые читатели и гости IT портала Pyatilistnik.org. В прошлый раз мы с вами решали проблему, когда у нас тормозил Directum на терминальной ферме. В сегодняшней ситуации я опять вернусь к данному программному обеспечению и покажу, что мне удалось раскопать в ситуации, что при попытке создать договорной документ и выбрать его из конструктора документов, я получаю предупреждение «Ошибка поддержки безопасных каналов«. Давайте смотреть в чем дело и что можно поменять, чтобы все заработало.

Устранение ошибки поддержки безопасных каналов

Данную проблему я поймал в Directum на своей RDS-ферме. Стало увеличиваться количество обращений со стороны пользователей, что они при попытке создания договорного документа стали видеть ошибку:

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

• 1️⃣В интернете все копипастят друг у друга, что в данной ситуации помогает включение TLS, но я проверил и правки в реестре не дают ничего, тем более у меня уже они были активированы, я с этим еще сталкивался, когда получал ошибку «Unable to resolve package source» при установке модуля PowerShell.
• 2️⃣Далее если у вас есть антивирусное решение, то я вам советую его отключить на время, пока будите производить тестирование. Антивирус Касперского тут так же был ни причем
• 3️⃣Далее, что я обычно проверяю, это не производилась ли установка нового софта или обновлений Windows. Обязательно выведите список установленных программ и посмотрите, нет ли там чего-то нового. Бывает ситуация, что некоторые программы могут конфликтовать при совместном использовании, например очень частая ситуация с КриптоПРО, старыми версиями. Если она есть, то попробуйте ее удалить.
• 4️⃣Проверьте не было ли установки новых обновлений, это можно посмотреть в истории параметров Windows или в оснастке appwiz.cpl.

В результате на Windows Server прилетело KB5018411 на клиентские Windows 10 и Windows 11 прилетело kb5018410, что в итоге делать, на текущий момент просто удалять и ждать новых обновлений от Microsoft.

Чтобы удалить KB5018411  я воспользуюсь командной строкой и утилитой wusa. Введите:

У вас выскочит окно с подтверждением удаления данного обновления. Нажмите ок, начнется процесс.

Так же вы можете сделать, и тихое удаление добавим ключи: /quiet /norestart

После этого мой Directum заработал, посмотрю что будет со следующими обновлениями, может Mixrosoft пофиксит это.

Обновление 28.11.2022

Как и ожидалось, данная ошибка была устранена установкой ноябрьских обновлений KB5019964. С вами был Иван Семин, автор и создатель IT проекта Pyatilistnik.org.