Требуется ли SPN при использовании Kerberos с DCOM?

Question

Я использую DCOM для предоставления различных приложений в сети Windows, используя Kerberos для проверки подлинности. Обычно система работает нормально, но я сталкиваюсь с проблемами доступа к сервису из отдельного (доверенного) домена. В частности, служба не может выполнить обратные вызовы в клиентское приложение, получив сообщение об ошибке «Произошла ошибка конкретного пакета безопасности». Кроме того, если я настраиваю службу специально для проверки подлинности Kerberos (вместо использования SNEGO/negotiate), клиент не может даже позвонить на сервер (снова получая «произошла ошибка конкретного пакета безопасности»).

Путаница заключается в том, что все работает годами без проблем. Однако здесь несколько разных вещей, по сравнению с тем, что мы делали раньше. Во-первых, на серверах работает Windows 2008, которые я ранее не использовал. Кроме того, как отмечалось выше, ошибки возникают только при обращении к службе из учетной записи из отдельного домена, и предыдущее использование никогда не пыталось это сделать.

Теперь на вопрос: я не использую SPN (имя участника службы) для этой службы DCOM, но некоторые из ошибок и журналов событий заставляют меня думать, что это может быть проблемой. Тем не менее, все документы, которые я нашел, неясны в отношении того, правильно ли это или как я настроил SPN, если мне это нужно. Кто-нибудь знает наверняка, является ли SPN тем, что мне здесь не хватает? Если да, можете ли вы указать мне, как это должно быть сделано?

Дополнительная информация:

Для сценария, когда сервер установлен на принудительную аутентификацию Kerberos, включение Extended RPC Debugging дает некоторые дополнительные подсказки. Клиент может успешно подключиться с использованием CoCreateInstanceEx, но вызывает сбой интерфейса службы, как указано выше. В записях ошибок RPC отображается ошибка в местоположении 140, а код ошибки - 0x80090303 («Указанная цель неизвестна или недоступна»), а третий параметр для этой записи - пустая строка. Это указывает на отсутствие SPN в качестве виновника.

Answer 1

Редактировать: Похоже, я ошибаюсь. По крайней мере, один найденный мной сайт утверждает, что DCOM handles SPNs automatically for you (см. Нижнюю часть страницы), и я подтвердил, что клиенты могут успешно подключиться, если они требуют аутентификации Kerberos и используют «host/[computername]» в качестве SPN.

---

Это выглядит как SPN требуется для обслуживания, если явно требуется проверка подлинности Kerberos при вызове CoInitializeSecurity в процессе сервера DCOM. Для меня звонок выглядел так:

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

SOLE_AUTHENTICATION_SERVICE sas; 
sas.dwAuthnSvc = RPC_C_AUTHN_GSS_KERBEROS; 
sas.dwAuthzSvc = RPC_C_AUTHZ_NONE; 
sas.pPrincipalName = L"myservice/mymachine"; 
sas.hr = S_OK; 
CoInitializeSecurity(0, 1, &sas, 0, RPC_C_AUTHN_LEVEL_DEFAULT, 
    RPC_C_IMP_LEVEL_DEFAULT, 0, EOAC_NONE, 0); 

Имя SPN может быть сконфигурирован с помощью setspn, как показано ниже:

setspn -A myservice/mymachine serviceusername 

(см Setspn документацию для подробностей).

К сожалению, это еще не решило мою проблему, но я думаю, что оставшаяся проблема связана с определенной проблемой с тестовыми машинами.

Answer 2

Для чего необходимо, Kerberos по определению требует SPN.Возможно, вы сможете использовать встроенный SPNS (хост /) и различные вкусы, которые подразумевает хост (этот перевод псевдонимов хранится в AD, но на всю жизнь я не могу найти список статей, где это найдено).

Я бы начал с проверки междоменной аутентификации. Это может быть сложно с kerberos. Сначала я включил полный kerberos logging как на клиентском, так и на сервере, и посмотрю, что что-то получилось.

Answer 3

Я столкнулся с этой ошибкой, пытаясь создать экземпляр удаленного COM-объекта. Мы можем столкнуться с этой ошибкой. Если во время вызова CoInitializeSecurity() клиентский уровень олицетворения «Делегат» используется, а служба COM + работает под учетной записью пользователя, которая не имеет разрешения «делегирования» на уровне домена.