Аутентификация DCOM не в состоянии использовать Kerberos, возвращается к NTLM
У меня есть веб-сервис, который написан на классическом ASP. В этом веб-сервисе он пытается создать объект VirtualServer.Application на другом сервере через DCOM. Это не с разрешением отказано. Однако у меня есть другой компонент, созданный в том же веб-сервисе на том же удаленном сервере, который создается без проблем. Этот компонент является собственным компонентом.
Веб-сервис вызывается из автономной EXE-программы, которая вызывает его через WinHTTP. Было проверено, что WinHTTP успешно аутентифицируется с помощью Kerberos для веб-службы. Пользователь, прошедший аутентификацию на веб-сервисе, является администратором. Этап аутентификации EXE в веб-сервисе выполнен успешно и с Kerberos.
Я проверил разрешения DCOM на удаленном компьютере с помощью DCOMCNFG. Ограничения по умолчанию позволяют администраторам как локальной, так и удаленной активации, как локального, так и удаленного доступа, а также локального и удаленного запуска. Разрешения компонентов по умолчанию позволяют то же самое. Это было проверено. Разрешения отдельных компонентов для рабочего компонента установлены по умолчанию. Разрешения для отдельных компонентов для компонента VirtualServer.Application также установлены по умолчанию. На основе этих настроек веб-сервис должен иметь возможность создавать экземпляры и получать доступ к компонентам на удаленном компьютере.
Настройка трассировки Wireshark при выполнении обоих тестов, один с рабочим компонентом, а другой с компонентом VirtualServer.Application, демонстрирует интересное поведение. Когда веб-служба создает экземпляр рабочего, пользовательского компонента, я вижу запрос по соединению с преобразователем конечной точки RPCSS, который сначала выполняет последовательность соединений TCP. Затем я вижу, что он выполняет запрос на связывание с соответствующим пакетом безопасности, в данном случае Kerberos. После того как он получает конечную точку для работающего компонента DCOM, он подключается к конечной точке DCOM, снова проходя аутентификацию через Kerberos, и он успешно может создать экземпляр и установить связь.
На отказавшем компоненте VirtualServer.Application я снова вижу, что запрос на связывание с kerberos успешно передается в маппинг конечных точек RPCC. Тем не менее, когда он пытается подключиться к конечной точке в процессе виртуального сервера, он не может подключиться, потому что он только пытается аутентифицироваться с NTLM, что в конечном итоге не удается, потому что веб-сервис не имеет доступа к учетным данным для выполнения хеширования NTLM.
Почему он пытается пройти аутентификацию через NTLM?
Дополнительная информация:
- Оба компонента работают на одном сервере через DCOM
- Оба компонента работают как локальная система на сервере
- Оба компонента являются компонентами Win32 Service
- Оба компонента имеют одинаковые разрешения DCOM для запуска / доступа / активации
- Обе службы Win32 настроены для работы в качестве локальной системы
- Отказано в разрешении - это не проблема разрешений, насколько я могу судить, это проблема аутентификации. В доступе отказано, поскольку аутентификация NTLM используется с пустым именем пользователя вместо делегирования Kerberos
- Ограниченное делегирование настраивается на сервере, на котором размещен веб-сервис.
- Серверу, на котором размещен веб-сервис, разрешено делегировать rpcss/dcom-server-name.
- Серверу, на котором размещен веб-сервис, разрешено делегировать vssvc/dcom-server-name.
- Серверу dcom разрешено делегировать на rpcss / webservice-server.
- SPN, зарегистрированные на сервере dcom, включают в себя rpcss/dcom-server-name и vssvc/dcom-server-name, а также имена SPN, связанные с HOST/dcom-server-name
- SPN, зарегистрированные на веб-сервис-сервере, включают в себя rpcss / webservice-server и SPN, связанные с HOST/webservice-сервером
У кого-нибудь есть идеи, почему попытка создать объект VirtualServer.Application на удаленном сервере откатывается к проверке подлинности NTLM, что приводит к сбою и отказу в разрешении?
Дополнительная информация: Когда следующий код запускается в контексте веб-службы непосредственно через только что разработанный компонент COM, предназначенный только для тестирования, он завершается с ошибкой в указанной строке с отказом в доступе.
COSERVERINFO csi;
csi.dwReserved1=0;
csi.pwszName=L"terahnee.rivin.net";
csi.pAuthInfo=NULL;
csi.dwReserved2=NULL;
hr=CoGetClassObject(CLSID_VirtualServer, CLSCTX_ALL, &csi, IID_IClassFactory, (void **) &pClsFact);
if(FAILED( hr )) goto error1;
// Fails here with HRESULT_FROM_WIN32(ERROR_ACCESS_DENIED)
hr=pClsFact->CreateInstance(NULL, IID_IUnknown, (void **) &pUnk);
if(FAILED( hr )) goto error2;
Я также заметил, что в Wireshark Traces я вижу, что попытка подключиться к компоненту сервисного процесса запрашивает только аутентификацию NTLMSSP, она даже не пытается использовать Kerberos. Это говорит о том, что по какой-то причине веб-служба считает, что не может использовать Kerberos...
1 ответ
Откат аутентификации NTLM является симптомом. Настоящая проблема в том, почему Kerberos терпит неудачу.
Это звучит как классический случай получения уровня олицетворения, недостаточного для выполнения запрошенного действия. При использовании делегирования с Kerberos, если машина или процесс, который олицетворяет себя, не имеет токена "Олицетворение", а вместо этого имеет более низкий токен, такой как "Identity", запрос аутентификации Kerberos для доступа к ресурсам при использовании другого удостоверения завершится неудачей.
Существует четыре типа токенов олицетворения:
анонимное
тождественность
олицетворение
Делегация
"Олицетворение" позволяет олицетворению получать доступ к ресурсам на том же компьютере, где расположен процесс, выполняющий олицетворение. В тех случаях, когда процесс, выполняющий олицетворение, получает доступ к ресурсам на другом компьютере, чем тот, где выполняется олицетворение, требуется токен "Делегирование". Обычно для этого требуется привилегия TCB (действует как часть операционной системы).
Перечисление TokenImpersonationLevel
http://msdn.microsoft.com/en-us/library/system.security.principal.tokenimpersonationlevel%28v=vs.80%29.aspx
Обратите внимание, что для DCOM в Windows XP/Server 2003 уровнем олицетворения по умолчанию является "Identity". Это означает, что процесс может не иметь доступа к ресурсам при олицетворении другой личности. Вы можете поэкспериментировать с конфигурацией безопасности на уровне компьютера или на уровне процесса, чтобы найти то, что работает. Вы можете обнаружить, что вам нужно включить шифрование для подключения к некоторым ресурсам. Настройка одного сервиса так же, как и другого, может не совпадать с яблоками.
Соединение между различными операционными системами
http://msdn.microsoft.com/en-us/library/aa389284%28v=vs.85%29.aspx
Настройка безопасности для всей системы с помощью DCOMCNFG
http://msdn.microsoft.com/en-us/library/ms680051%28v=vs.85%29.aspx
Установка уровня безопасности процесса по умолчанию с использованием C++
http://msdn.microsoft.com/en-us/library/aa393617%28v=vs.85%29.aspx