In che modo l'autenticazione DCOM viene confrontata con l'autenticazione / l'autenticazione basata su RPC?

Il confronto tra DCOM e RPC è simile al confronto tra HTTP e TCP.

Infatti, DCOM utilizza effettivamente RPC come meccanismo di trasporto, quando è necessario inviare le richieste DCOM tramite la rete.
RPC, come protocollo di trasporto, non ha meccanismi di autenticazione incorporati; DCOM ha l'autenticazione come parte del protocollo.

Quindi, per Windows 2000, quando la suite completa di DCOM non era già disponibile, la CA utilizzava il protocollo di trasporto esistente, RPC, ma doveva sviluppare un protocollo applicativo personalizzato su di esso, per implementare cose come autenticazione e autorizzazione .
Per Windows 2003, con DCOM pre-sviluppato, pre-compilato, pre-testato e pre-distribuito disponibili, potevano semplicemente utilizzare il meccanismo di autenticazione e autorizzazione già presente.

Ecco perché puoi avere lo screenshot della configurazione delle autorizzazioni DCOM (è integrato nel sistema operativo), ma non RPC (questo non esiste come parte del protocollo).
Inoltre, poiché DCOM può utilizzare Kerberos come meccanismo di autenticazione, puoi avere cose come la rappresentazione limitata che consente impersonation for authenticating requesters e compares the client token against an access control list (ACL) , invece dell'applicazione (CA) che deve personalizzare il proprio.

Why would software implementation choose DCOM over RPC?

Perché è disponibile.

Quindi la prima domanda è come DCOM sia diverso da RPC, in termini di Autenticazione e Autorizzazione.

Non lo è. DCOM è basato su RPC e utilizza i meccanismi di autenticazione sottostanti. DCOM è solo un'estensione orientata agli oggetti di RPC. L'analogia andrebbe da C a C ++.

(Puoi vedere questo nel debugger se interrompi una chiamata DCOM in arrivo. Il tuo codice viene chiamato da una DLL stub solitamente OLEAUT32.dll che viene chiamata dal codice DCOM che viene chiamato dal codice RPC).

Per quanto riguarda l'articolo che citi, penso che stiano dicendo due cose e le confondano.

1. La nuova API dei servizi di certificazione viene esposta da un DCOM, anziché come una API rpc piatta.
2. Poiché utilizza DCOM, puoi configurare le autorizzazioni dell'oggetto DCOM per aggiungere un ulteriore controllo di sicurezza.

Non penso che questa sia una scelta deliberata di design, è più un effetto collaterale del passaggio all'api DCOM, che a mia volta sono sicuro che è stato motivato rendendo l'API più facile da usare e gestire.

the CA can immediately process the request, as long as the user has the appropriate enrollment permissions on the template and if the CAs configuration is set to autoenroll

Quindi, per impedire a qualcuno di iscriversi, il modo corretto è quello di non concedere loro le autorizzazioni di iscrizione sul modello . Altrimenti potrebbero ancora iscriversi usando l'API RPC che esiste ancora e funziona .

Ho avuto una domanda simile sull'autenticazione DCOM / RPC. Dopo aver studiato per diversi giorni, ho ottenuto la conclusione:

1. Sebbene DCOM / RPC sostengano di supportare diverse autenticazioni meccanismo, ma ironicamente, DCOM / RPC non hanno fornito alcun inline finestra di accesso (come mostrato quando si accede alla cartella condivisa del server). L'infrastruttura client DCOM / RPC non ha fornito alcun modo comune per memorizzare esternamente le impostazioni di autenticazione (come Windows Credential Store), ciò è molto scomodo.
2. Se l'utente del client è connesso come un utente di dominio e il server è anche nel dominio o l'utente / password del client sono validi anche nell'account locale del server db, l'identità verrà utilizzata per impostazione predefinita.
3. Quando DCOM / RPC utilizza Named Pipe come trasporto, è costruito su SMB protocollo (porta 445), il client deve prima autenticare eseguendo il comando "net use" \\ SERVER / utente: USER "quindi inserisci la password" o inserisci \\ SERVER in explorer per accedere al server, altrimenti semplicemente "Accesso negato".
4. Quando DCOM / RCP utilizza il trasporto TCP (porta 135), il client deve impostare utente / password ... in COAUTHINFO di DCOM CoGetClassObject o RPC_AUTH_IDENTITY_HANDLE di RpcBindingSetAuthInfo di RPC, altrimenti trattato come "ANONYMOUS LOGON" sul lato server, ma molto probabilmente, causa "Accesso negato" a causa delle impostazioni ACL predefinite di DCOMCNFG.
5. Il metodo di autenticazione del componente DCOM e le impostazioni ACL possono essere controllato dall'utilità esterna DCOMCNFG, a livello macchina o a livello di componente, in qualsiasi momento. Ma il componente RPC non può, invece, possono essere definiti solo quando si crea il componente RPC.
6. Le impostazioni ACL del componente DCOM possono essere ulteriormente rafforzate utilizzando "Imposta limiti" nell'utilità DCOMCNFG, "Imposta limiti" consente di utilizzare il controllo massimo possibili autorizzazioni forzate per ciascun componente DCOM.