¿Cómo se compara la autenticación DCOM con la autenticación / autenticación basada en RPC?

Comparar DCOM con RPC es muy parecido a comparar HTTP con TCP.

De hecho, DCOM realmente usa RPC como mecanismo de transporte, cuando es necesario enviar las solicitudes DCOM a través de la red.
RPC, como protocolo de transporte, no tiene ningún mecanismo de autenticación incorporado; DCOM tiene autenticación como parte del protocolo.

Entonces, para Windows 2000, cuando el conjunto completo de DCOM no estaba disponible, la CA usó el protocolo de transporte existente, RPC, pero tuvo que desarrollar un protocolo de aplicación personalizado para implementar elementos como la autenticación y la autorización. .
Para Windows 2003, con el DCOM pre-desarrollado, pre-construido, pre-probado y pre-implementado disponible, podrían usar el mecanismo de autenticación y autorización ya existente.

Esta es la razón por la que puede tener la captura de pantalla de la configuración de los permisos DCOM (está integrado en el sistema operativo), pero no RPC (esto no existe como parte del protocolo).
Además, dado que DCOM puede usar Kerberos como su mecanismo de autenticación, puede tener cosas como la suplantación limitada que permite a impersonation for authenticating requesters y compares the client token against an access control list (ACL) , en lugar de que la aplicación (CA) tenga que personalizar su rollo.

  

¿Por qué la implementación de software elegiría DCOM sobre RPC?

Porque está disponible.

Entonces, la primera pregunta es cómo DCOM es diferente de RPC, en términos de autenticación y autorización.

No lo es. DCOM se basa en RPC y utiliza los mecanismos de autenticación subyacentes. DCOM es solo una extensión orientada a objetos para RPC. La analogía iría de C a C ++.

(Puede ver esto en el depurador si interrumpe una llamada entrante de DCOM. Su código se llama desde un archivo de código auxiliar, normalmente OLEAUT32.dll, que se llama desde el código DCOM que se llama desde el código RPC).

En cuanto al artículo que cita, creo que están diciendo dos cosas y las están confundiendo.

1. La nueva API de servicios de certificado está expuesta por un DCOM, en lugar de como una API plana de rpc.
2. Dado que usa DCOM, puede configurar los permisos de los objetos de DCOM para agregar una verificación de seguridad adicional.

No creo que se trate de una elección de diseño deliberada, es más bien un efecto secundario de pasar a la API de DCOM, que a su vez estoy seguro que fue motivado al hacer que la API sea más fácil de usar y administrar.

  

la CA puede procesar la solicitud de inmediato, siempre que el usuario tenga los permisos de inscripción adecuados en la plantilla y si la configuración de la CA está establecida en inscripción automática

Entonces, para evitar que alguien se inscriba, la forma correcta es no otorgarles los permisos de inscripción en la plantilla . De lo contrario, aún podrían inscribirse utilizando la api de RPC que aún existe y funciona .

Tuve una pregunta similar sobre la autenticación DCOM / RPC. Habiendo estudiado durante varios días, llegué a la conclusión:

1. Aunque DCOM / RPC afirman que admiten varias autenticaciones mecanismo, pero, irónicamente, DCOM / RPC no han proporcionado ninguna línea diálogo de inicio de sesión (como se muestra cuando se accede a la carpeta compartida del servidor). La infraestructura del cliente DCOM / RPC no ha proporcionado ninguna forma común de almacenar las configuraciones de autenticación externamente (como el almacén de credenciales de Windows), esto es muy inconveniente.
2. Si el usuario cliente ha iniciado sesión como usuario de dominio y el servidor también está en el dominio o el usuario / contraseña del cliente también son válidos en la base de datos de la cuenta local del servidor, la identidad se utilizará de forma predeterminada.
3. Cuando DCOM / RPC usa Canalización con nombre como transporte, se construye sobre SMB protocolo (puerto 445), el cliente primero debe autenticarse con el comando de ejecución "net use \\ SERVIDOR / usuario: USUARIO "luego ingrese la contraseña" o ingrese \\ SERVIDOR en explorador para iniciar sesión en el servidor, de lo contrario simplemente "Acceso denegado".
4. Cuando DCOM / RCP usa transporte TCP (puerto 135), el cliente debe configurar usuario / contraseña ... en COAUTHINFO de DCOM's CoGetClassObject o RPC_AUTH_IDENTITY_HANDLE de RPC's RpcBindingSetAuthInfo, de lo contrario se trata como "ANONIMO DE INICIO DE SESIÓN" en el lado del servidor, pero lo más probable es que finalmente se genere un "Acceso denegado" debido a la configuración de ACL predeterminada de DCOMCNFG.
5. El método de autenticación del componente DCOM y la configuración de ACL pueden ser controlado por la utilidad externa DCOMCNFG, a nivel de máquina o nivel de componente, en cualquier momento. Pero el componente RPC no puede, en cambio, solo se pueden definir cuando se crea un componente RPC.
6. La configuración de ACL del componente DCOM se puede fortalecer aún más con el uso "Establecer límites" en la utilidad DCOMCNFG, "Establecer límites" permite usar el control máximo permisos posibles a la fuerza para cada componente DCOM.