У меня есть веб-сервис, написанный на классическом 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?
Дополнительная информация:
У кого-нибудь есть идеи, почему попытка создать объект 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, он даже не пытается использовать керберос. Это говорит о том, что по какой-то причине веб-сервис считает, что не может использовать керберос ...
Резервная проверка подлинности 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 уровень олицетворения по умолчанию - «Идентификация». Это означает, что процесс может не иметь доступа к ресурсам при олицетворении другого удостоверения. Вы можете поэкспериментировать с конфигурацией безопасности на уровне машины или процесса, чтобы найти то, что работает. Вы можете обнаружить, что вам нужно включить шифрование для подключения к некоторым ресурсам. Настройка одной службы так же, как другая, не может быть сравнением яблок и яблок.
Подключение между разными операционными системами
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