Обновлено 27.08.2022
Добрый день! Уважаемые читатели IT блога Pyatilistnik.org, в прошлый раз мы с вами разобрали за, что отвечает библиотека vcruntime140.dll и на сколько она важна для работы многих программ. Сегодня я хочу вам рассказать, об интересном случае, когда специализированный софт может не получить доступ к удаленному компьютеры по RPC протоколу из-за новых политик безопасности DCOM. В логах будет фигурировать событие об ошибке DCOM ID 10036 «политика уровня проверки подлинности на стороне сервера не разрешает пользователю». Давайте смотреть в чем дело.
❌Описание ошибки DCOM ID 10036 (EOleException)
Обратился ко мне мой коллега с просьбой показать ему, как отправлять сообщение всем пользователям терминального хоста. Я предложил ему бесплатную утилиту Terminal Services Manager и подумал, что задача выполнена, но не тут то было. Коллега сказал, что у него не подключается к RDSH хосту и высвечивается ошибка доступа. Я решил так же проверить данную ситуацию.
Запустив Terminal Services Manager, в логе я увидел вот такую ошибку подключения:
Сразу отмечу, что права на удаленный сервер у меня были и сетевая доступность присутствовала. Первым делом я полез на сам сервер, куда не удавалось произвести подключение. В логах системы я обнаружил массовую ошибку:
ID 10036: Политика уровня проверки подлинности на стороне сервера не разрешает пользователю ROOTsem SID (S-1-5-21-551888299-3078463796-123456789-46162) с адреса 10.11.11.210 для активации DCOM-сервера. Повысьте уровень проверки подлинности активации, чтобы RPC_C_AUTHN_LEVEL_PKT_INTEGRITY в клиентском приложении. («The server-side authentication level policy does not allow the user ROOTsem SID (S-1-5-21-551888299-3078463796-123456789-46162) from address 10.11.11.210 to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.»)
Давайте выяснять в чем дело и как это можно обойти.
⚙️Причина ошибки DCOM ID 10036
Первое, что я стал изучать, что такое RPC_C_AUTHN_LEVEL_PKT_INTEGRITY. В итоге я наткнулся на статью Microsoft о константах уровня аутентификации.
Константы уровня аутентификации представляют собой уровни аутентификации, передаваемые различным функциям времени выполнения. Эти уровни перечислены в порядке возрастания аутентификации. Каждый новый уровень добавляет к аутентификации, обеспечиваемой предыдущим уровнем. Если библиотека времени выполнения RPC не поддерживает указанный уровень, она автоматически обновляется до следующего более высокого поддерживаемого уровня.
В итоге есть вот такой список констант:
- RPC_C_AUTHN_LEVEL_DEFAULT — Использует уровень проверки подлинности по умолчанию для указанной службы проверки подлинности.
- RPC_C_AUTHN_LEVEL_NONE — Не выполняет аутентификацию.
- RPC_C_AUTHN_LEVEL_CONNECT — Аутентифицируется только тогда, когда клиент устанавливает связь с сервером.
- RPC_C_AUTHN_LEVEL_CALL — Выполняет аутентификацию только в начале каждого вызова удаленной процедуры, когда сервер получает запрос. Не применяется к удаленным вызовам процедур, выполненным с использованием последовательностей протоколов на основе соединения (тех, которые начинаются с префикса «ncacn»). Если последовательность протокола в дескрипторе привязки представляет собой последовательность протокола на основе соединения, и вы указываете этот уровень, эта процедура вместо этого использует константу RPC_C_AUTHN_LEVEL_PKT.
- RPC_C_AUTHN_LEVEL_PKT — Аутентифицирует только то, что все полученные данные получены от ожидаемого клиента. Не проверяет сами данные.
- RPC_C_AUTHN_LEVEL_PKT_INTEGRITY — Аутентифицирует и проверяет, что никакие данные, передаваемые между клиентом и сервером, не были изменены.
- RPC_C_AUTHN_LEVEL_PKT_PRIVACY — Включает все предыдущие уровни и гарантирует, что данные в открытом виде могут быть видны только отправителю и получателю. В локальном случае это предполагает использование безопасного канала. В удаленном случае это включает шифрование значения аргумента каждого удаленного вызова процедуры.
Теперь стало понятно, за что отвечает RPC_C_AUTHN_LEVEL_PKT_INTEGRITY и видимо Microsoft, ужесточила какую-то политику безопасности, я стал изучать вопрос дальше. Поиск ошибки DCOM ID 10036 привел меня ну обсуждение нового обновления KB5004442, которое как я выяснил и вызывает эту ситуацию.
KB5004442 призвана усилить защиту DCOM объектов. Удаленный протокол модели распределенных компонентов (DCOM) — это протокол для предоставления объектов приложений с помощью удаленных вызовов процедур (RPC). DCOM используется для связи между программными компонентами сетевых устройств. Многие из нас на самом деле не понимают этого, и мы не можем диагностировать ошибки DCOM в наших журналах событий, которые, по-видимому, не оказывают серьезного влияния на наши сети. Эта технология представляет собой протокол для предоставления объектов приложения с помощью удаленных вызовов процедур (RPC).
RPC являются ключевой частью Windows. RPC — это клиент-серверный протокол, который разработчики приложений могут использовать для вызова процедур на локальном или удаленном узле в сети. Детали подключения и сортировка данных выполняются за кулисами на уровне RPC, что дает разработчикам средства для прямого подключения клиентских приложений к удаленному компьютеру. Это позволяет разработчикам не беспокоиться о знании деталей того, как данные передаются между двумя машинами и как вызываются процедуры.
С обновлениями безопасности от 14 июня 2022 г. RPC_C_AUTHN_LEVEL_PKT_INTEGRITY на серверах DCOM теперь включен по умолчанию. Клиент, которому это необходимо, может отключить его с помощью раздела реестра RequireIntegrityActivationAuthenticationLevel.
Согласно бюллетеню, злоумышленник сначала воспользуется уязвимостью, предложив клиенту DCOM каким-либо образом подключиться к специально созданному серверу, как правило, отправив пользователю фишинговое электронное письмо, чтобы завладеть системой. Затем злоумышленник использует эту информацию для доступа к серверу DCOM, а затем скомпрометирует его. Патч исправляет и усиливает аутентификацию, используемую между клиентами и серверами DCOM.
Я проверил RDSH хосты и действительно там прилетело данное обновление. Microsoft пока полностью не закрутило данную политику безопасности и ее еще можно обойти, но самое правильное, это доделать приложение, чтобы оно при обращении к серверу и запросе данных выполняло все требования вендора. На текущий момент есть вот такой график внедрения:
- 8 июня 2021 г. — Изменения защиты отключены по умолчанию, но с возможностью включить их с помощью ключа реестра.
- 14 июня 2022 г. — Защитные изменения включены по умолчанию, но с возможностью отключить их с помощью ключа реестра.
- 14 марта 2023 г. — Усиление изменений включено по умолчанию, отключить их невозможно. К этому моменту вы должны решить все проблемы совместимости с усиливающими изменениями и приложениями в вашей среде.
Еще список обновлений несущих данное изменение: Windows Server 2022 — KB5005619, KB5005568. Windows 10, version 2004, Windows 10, version 20H2, Windows 10, version 21H1 — KB5005101. Windows Server 2019, Windows 10, version 1809 — KB5005102. Windows Server 2016, Windows 10, version 1607 — KB5005573. Windows Server 2012 R2 and Windows 8.1 — KB5006714. Данный список всегда меняется, так что смотрите в каталоге центра обновлений, что чем заменяется (https://www.catalog.update.microsoft.com/).
Так же помимо события ID 10036, есть еще два:
ID 10037: «Приложение %1 с PID %2 запрашивает активацию CLSID %3 на компьютере %4 с явно заданным уровнем аутентификации %5. Минимальный уровень аутентификации активации, требуемый DCOM, — 5 (RPC_C_AUTHN_LEVEL_PKT_INTEGRITY). Чтобы повысить уровень аутентификации активации, пожалуйста, обратитесь к поставщику приложения». («Application %1 with PID %2 is requesting to activate CLSID %3 on computer %4 with explicitly set authentication level at %5. The lowest activation authentication level required by DCOM is 5(RPC_C_AUTHN_LEVEL_PKT_INTEGRITY). To raise the activation authentication level, please contact the application vendor.»)
ID 10038: «Приложение %1 с PID %2 запрашивает активацию CLSID %3 на компьютере %4 с уровнем аутентификации активации по умолчанию %5. Минимальный уровень аутентификации активации, требуемый DCOM, — 5 (RPC_C_AUTHN_LEVEL_PKT_INTEGRITY). Чтобы повысить уровень аутентификации активации, пожалуйста, обратитесь к поставщику приложения». («Application %1 with PID %2 is requesting to activate CLSID %3 on computer %4 with default activation authentication level at %5. The lowest activation authentication level required by DCOM is 5(RPC_C_AUTHN_LEVEL_PKT_INTEGRITY). To raise the activation authentication level, please contact the application vendor.»)
- %1 — путь к приложению
- %2 — PID приложения
- %3 — CLSID класса COM, который приложение запрашивает для активации
- %4 — имя компьютера
- %5 — значение уровня аутентификации
💡Как устранить ошибку ID 10036
Первое, что вы должны сделать, это установить все доступные обновления, как на стороне сервера, куда идет подключение, так и на стороне системы откуда идет подключение. Напоминаю, что последнего можно найти в тексте ошибки:
ID 10036: Политика уровня проверки подлинности на стороне сервера не разрешает пользователю ROOTsem SID (S-1-5-21-551888299-3078463796-123456789-46162) с адреса 10.11.11.210 для активации DCOM-сервера. Повысьте уровень проверки подлинности активации, чтобы RPC_C_AUTHN_LEVEL_PKT_INTEGRITY в клиентском приложении.
Тут IP-адрес откуда идет подключение 10.11.11.210, там и нужно установить все возможные обновления безопасности.
Как только я обновился, ошибка EOleException ушла и мой Terminal Services Manager успешно подключился к серверу.
Если по каким, то причинам ваше приложение не заработало, а вам нужно, то есть лазейка до 2023 года в виде ключа реестра, который вы должны добавить на сервере, куда вы пытаетесь производить подключение. Запустите реестр Windows и перейдите в раздел:
HKEY_LOCAL_MACHINESOFTWARE MicrosoftOleAppCompat
И создайте там ключ реестра с типом REG_DWORD (32-бита) с именем RequireIntegrityActivationAuthenticationLevel.
- RequireIntegrityActivationAuthenticationLevel = 0x00000000 выключает политику
- RequireIntegrityActivationAuthenticationLevel = 0x00000001 включает политику
не забываем после создания ключа в реестре Windows произвести перезагрузку сервера
Если и данный метод вам не помог, то как крайняя мера может быть, это удаление обновления. Посмотрите список установленных обновлений командой:
После чего просто прочитайте инструкцию, как это сделать. Надеюсь, что вам оказалась полезна данная статья, и вы устранили ошибку EOleException. Если остались вопросы, то пишите их в комментариях. С вами был Иван Сёмин, автор и создатель IT портала Pyatilistnik.org.
Дополнительные ссылки
- https://docs.microsoft.com/en-us/windows/win32/rpc/authentication-level-constants
- https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c
- https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26414
Ошибка DistributedCOM с кодом события 10016 в Windows 11/10 — одна из самых известных проблем с которой пользователи сталкиваются в системном журнале. Эта ошибка запускается, когда определенные процессы не содержат прав доступа к компонентам DCOM, которые упоминаются в журналах событий. Это ограничивает безупречную работу компьютера, что в конечном итоге раздражает пользователей. Система сразу же забивает «Просмотрщик событий» тысячами сообщений с показам событий.
В ходе расследования выясняется, что при попытке запустить сервер DCOM с помощью приложения у вас нет никаких прав на это, и вы получите приведенную ниже ошибку в средстве просмотра событий: «Параметры разрешений для конкретного приложения не дают разрешения Локальной Активации для приложения COM-сервера«.
Перед тем, как приступить к исправлению, создайте точку восстановления системы.
Исправление кода события 10016 Ошибки DistributedCOM
Это самый быстрый и простой способ, чтобы исправить ошибку DistributedCOM с кодом события 10016, но менее надежный.
Нажмите Win+R и введите regedit, чтобы запустить редактор реестра. В реестре перейдите по пути:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftOle
- Удалите следующие значения (некоторых может не быть): DefaultAccessPermission, DefaultLaunchPermission, MachineAccessRestriction, MachineLaunchRestriction.
Перезагрузите ПК и проверьте, появляется ли ошибка. Если да, то следуем ниже большому способу из 3 пунктов, где мы зададим привилегии для определенного DCOM.
Проверка процесса
1. Прежде всего должны отсортировать процесс или службу, связанную с кодом ошибки 10016. Далее вы найдете описание ошибки чуть ниже во вкладке «общие» или «подробности». Из описания скопируйте CLSID. Он может выглядеть как {D63B10C5… .
2. Отроем теперь редактор реестра. Нажмите сочетание кнопок Win+R и введите regedit.
3. В редакторе реестра выделите «Компьютер» одним нажатием мышки и нажмите «Правка» > «Найти«.
- Введите в поле поиска свой CLSID ключ, который типа {D63B10C5… . Поставьте галочку искать только «имена разделов».
- Вам выдаст ключ в правой стороне, выделите его мышкой один раз.
- В правом поле у вас будет ключ «По умолчанию» со значением RuntimeBroker. Запомните это значение оно нам пригодится в дальнейшим.
Следующая задача — запустить сценарий, чтобы внести некоторые изменения в раздел разрешений, найденных в службах компонентов для этой службы.
Открытие сервисов компонентов
Наберите в поиске windows «Службы компонентов«, нажмите правой кнопкой мыши и выберите запустить от имени администратора.
Перейдите по следующему пути Службы компонентов > Компьютеры > Мой компьютер > Настройка DCOM > и найдите в списке RuntimeBroker.
В некоторых случаях может быть два файла с этим именем. Вам нужно выяснить, какой файл несет ответственность за ошибку, что ниже мы и сделаем.
- Нажмите по очереди на двух файлов с именем RuntimeBroker правой кнопкой мыши выберите «Свойства«.
- Во вкладке «Общие» у вас будет «Код приложения» запомните его на двух файлах RuntimeBroker.
- Сравните код с ошибкой в «Журнале событий». APPID в журнале с ошибкой, должен соответствовать коду приложения в файле RuntimeBroker.
Исправление разрешений
Наконец, когда вы удостоверились, что это именно тот файл выдает ошибку, то проделайте следующие шаги:
- Нажмите в свойствах RuntimeBroker вкладку «Безопасность«.
- Кнопка «настроить» должна быть активной.
- Проделайте ниже шаги чтобы активировать настройки. (Не Запуск сценария PowerShell).
Запуск сценария PowerShell активирует эту кнопку настройки с помощью команды, но я рекомендую воспользоваться этим способом, если у вас не получилось все по порядку. Пропустите этот шаг «Запуск сценария PowerShell», если что потом вернетесь к нему.
Запуск сценария PowerShell
Чтобы обойти эту ошибку, вам нужно отредактировать некоторые разрешения в разделе «Служба компонентов» ключа RuntimeBroker. Прежде чем перейти к модификации, вам нужно запустить скрипт, который поможет вам изменить разрешения. Дальше поймете зачем мы это делали.
1. Нажмите сочетание кнопок Win+X и выберите Windows PowerShell (администратор).
2. Загрузите файл с кодом ниже. Разархивируйте скаченный архив, в нем содержится текстовый файл с кодом.
3. Вставьте скаченный скрипт с файла в командную строку PowerShell.
- 1-2. Скопируйте «Код приложения» в службах и компонентах, компонента RuntimeBroker.
- 3. Откройте редактор реестра, нажмите «правка» > «найти» и вставьте код приложения, который до этого скопировали. Нажмите правой кнопкой мыши на найденным ключе в реестре и выберите «Разрешения«.
- 4. далее в окне нажмите «Дополнительно«.
- В окне сверху «Владелец» нажмите «Изменить«.
- В следующим окне нажмите внизу «Дополнительно«.
- Нажмите справа «Поиск» и ниже со списка выберите «Администраторы«.
- Теперь переходим обратно в компоненты к свойству файла RuntimeBroker и мы видим, что теперь кнопка «настроить» стала интерактивной.
- Выскочит предупреждающее окно нажмите Удалить, если вам не мог код сценария powerShell.
- Нажмите Отмена, если вам помог код сценария powerShell.
- Нажмите Изменить напротив кнопки «настроить» в графе «разрешения на запуск и активацию».
Добавим группы система и local service.
- В окне, где имеются учетные записи нажмите «Добавить«.
- Ниже кнопка «Дополнительно«.
- Нажмите «Поиск» с боку.
- Найдите локальную службу LOCAL SERVICE и нажмите OK.
Аналогичным способом, что описан выше добавьте «Система«.
Теперь у вас появились две группы система и local service, нажмите на каждую из них и поставьте галочки в пунктах «Локальный запуск» и «Локальная активация».
Перезагрузите компьютер, ноутбук и код события 10016 Ошибка DistributedCOM должен пропасть.
Смотрите еще:
- DISM ошибка 87 в командной строке Windows
- Ошибка 0x8000ffff при восстановлении системы Windows 10
- Как исправить Ошибку 0xc1900101 0x20004 при установке Windows 10
- Как исправить ошибки обновлений Windows 10
- Как узнать IP-адрес компьютера с помощью PowerShell Windows
[ Telegram | Поддержать ]
Kurt Buff
unread,
Nov 3, 2021, 12:09:47 AM11/3/21
to ntsys…@googlegroups.com
All,
I’m seeing tons of these on our SW Orion box (also on our SEIM product that harvests event logs). Orion and our two SEIM products (one for log collection and one for vulnerability management) run on 2016 and 2019 boxes. The monitored machines are a mix of 2012r2, 2016 and 2019.
Log Name: System
Source: Microsoft-Windows-DistributedCOM
Date: 10/28/2021 9:18:35 PM
Event ID: 10028
Task Category: None
Level: Error
Keywords: Classic
User: SYSTEM
Computer: ORION.example.com
Description:
DCOM was unable to communicate with the computer
10.x.x.20 using any of the configured protocols;
requested by PID ad40
(C:Program Files (x86)Common FilesSolarWinds
JobEngine.v2SWJobEngineWorker2x64.exe).
I’m also seeing tons of these on our monitored systems, which seem to correlate with the above.
Log Name: System
Source: Microsoft-Windows-DistributedCOM
Date: 11/2/2021 11:48:34 AM
Event ID: 10036
Task Category: None
Level: Error
Keywords: Classic
User: EXAMPLEOrionProbe
Computer: server1.example.com
Description:
The server-side authentication level policy does
not allow the user EXAMPLEOrionProbe SID
(S-1-5-21-207515869-1525690680-377547397-11618)
from address 10.x.x.40 to activate DCOM server.
Please raise the activation authentication
level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.
This seems to be the culprit:
https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c
It looks as if opening up the «Component Services» app (comexp.msc) and making a change to the Default Properties tab to Default Authentication Level might fix it. Has anyone here run across this, and found a GPO configuration that can make this change?
Thanks,
Kurt
Kevin Lundy
unread,
Nov 3, 2021, 12:57:53 AM11/3/21
to ntsys…@googlegroups.com
No idea of the solution, but I can confirm similar logs with Orion. I have basically ignored the entries since the WMI polling does work. Are you using a trusted domain account for Orion?
Kurt Buff
unread,
Nov 3, 2021, 1:18:20 AM11/3/21
to ntsys…@googlegroups.com
The guy that set this up configured a DA account for Orion and the SEIM products. Madness. It’s on my project list for next year to restructure all three to use different tiered accounts — using the older MSFT 3 tier account model (DA, servers, workstations).
Kurt
James Iversen
unread,
Nov 3, 2021, 6:00:52 PM11/3/21
to ntsys…@googlegroups.com
Erno, Cynthia M (ITS)
unread,
Nov 3, 2021, 6:09:41 PM11/3/21
to ntsys…@googlegroups.com
ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails.
Join us on Facebook at
www.facebook.com/NYCMInsurance.
***CONFIDENTIALITY NOTICE***
This email and any attachments to it are confidential and intended solely for the individual or entity to whom it is addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you have received this email in error, please contact
the sender by reply email and destroy all copies of the original message.
—
You received this message because you are subscribed to the Google Groups «ntsysadmin» group.
To unsubscribe from this group and stop receiving emails from it, send an email to
ntsysadmin+…@googlegroups.com.
paul.ra…@gmail.com
unread,
Nov 3, 2021, 6:15:02 PM11/3/21
to ntsys…@googlegroups.com
Hi Kurt
I’ve seen this where the monitoring server and the monitored server are not patched to the same level (October patches in particular) – my guess would be the monitored servers have been patched but the monitoring (Orion) server hasn’t.
Paul.
Kurt Buff
unread,
Nov 3, 2021, 7:12:04 PM11/3/21
to ntsys…@googlegroups.com
Agreed, but in this case it was my immediate predecessor in the IT Security role, so that’s doubleplusunngood.
Kurt
Kurt Buff
unread,
Nov 3, 2021, 9:32:10 PM11/3/21
to ntsys…@googlegroups.com
AFAICT (and I’m the patching guy as part of my security role), all servers are fully patched.
I’ve been going to the machines under my control (which doesn’t include the Orion box), navigating to My Computer and changing the «Default Options» tab to set «packet integrity» instead of «connect’ . That seems to be helping, but this really should be settable by GPO.
Kurt