¿Se requiere un SPN cuando se usa Kerberos con DCOM?

Question

Estoy usando DCOM para proporcionar varios servicios de aplicación en una red de Windows, usando Kerberos para manejar la autenticación. El sistema normalmente funciona bien, pero me encuentro con problemas para acceder al servicio desde un dominio separado (de confianza). En particular, el servicio no puede realizar devoluciones de llamada a la aplicación del cliente, recibiendo el error & Quot; Se produjo un error específico del paquete de seguridad & Quot ;. Además, si modifico el servicio para que requiera específicamente la autenticación Kerberos (en lugar de usar SNEGO / negociar), el cliente ni siquiera puede llamar al servidor (nuevamente recibe & "; Se produjo un error específico del paquete de seguridad &"; ).

Lo confuso es que las cosas han estado funcionando durante años sin problemas. Sin embargo, algunas cosas son diferentes aquí, en comparación con lo que hemos hecho antes. Por un lado, los servidores involucrados ejecutan Windows 2008, que no he usado anteriormente. Además, como se señaló anteriormente, los errores solo ocurren cuando se accede al servicio desde una cuenta desde un dominio separado, y el uso anterior nunca ha intentado esto.

Ahora a la pregunta: no estoy usando un SPN (nombre principal del servicio) para este servicio DCOM, pero algunos de los errores y registros de eventos me hacen pensar que ese podría ser el problema. Sin embargo, todos los documentos que he encontrado no tienen claro si esto es correcto o cómo configuraría el SPN si lo necesito. ¿Alguien sabe con certeza si un SPN es lo que me falta aquí? Si es así, ¿puede indicarme cómo se debe hacer esto?

Detalles adicionales:

Para el escenario en el que el servidor está configurado para forzar la autenticación Kerberos, active Depuración de RPC ampliada proporciona algunas pistas adicionales. El cliente puede conectarse con éxito usando CoCreateInstanceEx, pero las llamadas en la interfaz de servicio fallan como se indicó anteriormente. Los registros de error de RPC muestran un error en la ubicación 140, y el código de error es 0x80090303 (& Quot; El objetivo especificado es desconocido o inalcanzable & Quot;), y el tercer parámetro para ese registro es una cadena vacía. Esto apunta a un SPN faltante como el culpable.

Answer 1

Editar : Parece que puedo estar algo equivocado sobre esto. Al menos un sitio web que encontré indica que DCOM maneja los SPN automáticamente para usted (consulte la parte inferior de la página) y confirmó que los clientes pueden conectarse con éxito si exigen la autenticación Kerberos y usan " host / [computername] " como el SPN.

---

Parece que se requiere un SPN para el servicio, si requiere explícitamente la autenticación Kerberos al llamar a CoInitializeSecurity en el proceso del servidor DCOM. Para mí, la llamada se veía así:

Advertencia: no copie este código directamente sin asegurarse de que los valores sean adecuados para sus necesidades de seguridad.

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 );

El SPN se puede configurar usando setspn , como demostrado a continuación:

setspn -A myservice/mymachine serviceusername

(vea los documentos de setspn para más detalles).

Desafortunadamente, esto todavía no resolvió mi problema, pero creo que el problema restante está relacionado con algún problema específico con las máquinas de prueba.

Answer 2

Por lo que vale, Kerberos, por definición, requiere SPN. Es posible que pueda utilizar el SPNS incorporado (host /) y los diversos sabores que implica el host (esta traducción de alias se almacena en el AD, pero por mi vida, parece que no puedo encontrar la lista de artículos donde esto se encuentra).

Comenzaría mirando la autenticación entre dominios: puede ser complicado con kerberos. Primero activaría el registro de Kerberos completo tanto en el cliente como en el servidor para ver si eso aparece cualquier cosa.

Answer 3

Me he encontrado con este error al intentar crear una instancia del objeto COM remoto. Podemos enfrentar este error si & Quot; Delegate & Quot; El cliente usa el nivel de suplantación durante la llamada a CoInitializeSecurity (), y el servicio COM + se ejecuta bajo una cuenta de usuario que no tiene " delegación " permiso a nivel de dominio.