Autenticazione e protezione di RPC su HTTP

 

Ultima modifica dell'argomento: 2005-05-18

I vantaggi di autenticazione e protezione dell'utilizzo di RPC su HTTP sono i seguenti:

• Non è necessario consentire nessun'altra porta Internet oltre a quelle già consentite per Microsoft® Office Outlook® Web Access, Microsoft Exchange ActiveSync® o Outlook Mobile Access.
• È necessario utilizzare Secure Sockets Layer (SSL).
• È necessario che Outlook invii le richieste autenticate.
• Il server proxy RPC e il server di Exchange autenticano le richieste di Outlook che utilizzano RPC su HTTP.
• Non si espone il mapper di endpoint.
• I computer client possono accedere solo ai servizi di Exchange specificati nei server di Exchange specificati.

Autenticazione HTTP

Internet Information Services (IIS) sul server proxy RPC controlla l'autenticazione della sessione HTTP. Quando si configura il server proxy RPC, è necessario impostare la directory virtuale RPC per l'utilizzo dell'autenticazione di base, dell'autenticazione NTLM o di entrambe le autenticazioni. Per la sessione HTTP Outlook può inviare l'autenticazione di base o l'autenticazione NTLM, a seconda di come si è configurato il profilo di Outlook. Il server proxy RPC Internet Server API (ISAPI) non accetta le connessioni autenticate in modo anonimo.

Nota

Quando si utilizza il Gestore di sistema di Exchange in Exchange Server 2003 Service Pack 1 (SP1) per configurare RPC su HTTP, il Gestore di sistema di Exchange configura automaticamente le impostazioni di autenticazione nella directory virtuale RPC.

Nota

L'autenticazione NTLM è nota anche come autenticazione integrata di Windows.

Il meccanismo di autenticazione che si configura nel profilo di Outlook viene utilizzato solo per la sessione HTTP al server proxy RPC. Il meccanismo di autenticazione tra Outlook e il server di Exchange, quando Outlook accede al server di Exchange utilizzando RPC su HTTP, è sempre NTLM. Si consiglia di utilizzare la crittografia SSL per la sessione HTTP al server proxy RPC, soprattutto se si utilizza l'autenticazione di base per la sessione HTTP. Se si utilizza la crittografia SSL, si evita che il nome utente e la password vengano inviati non crittografati. Outlook non consente di utilizzare l'autenticazione di base quando ci si connette al server proxy RPC senza utilizzare la crittografia SSL.

Se si dispone di un firewall che esamina il traffico HTTP e lo modifica in qualsiasi modo, può essere necessario utilizzare l'autenticazione di base invece che l'autenticazione NTLM. L'autenticazione NTLM non riesce se le informazioni di autenticazione non vengono considerate attendibili dal server proxy RPC. Ad esempio, si può avere un firewall che termina la sessione da Internet e che stabilisce una nuova sessione al server proxy RPC invece che passare la sessione HTTPS (SSL) al server di Exchange senza modifiche. Questo processo è noto come proxy inverso o pubblicazione sul Web. È possibile che determinati firewall quale Microsoft Internet Security and Acceleration (ISA) Server 2004 possano eseguire correttamente il proxy inverso o la pubblicazione sul Web della sessione e allo stesso tempo consentire l'autenticazione NTLM.

Nota

ISA Server 2000 non può eseguire il proxy inverso o la pubblicazione sul Web della sessione e allo stesso tempo consentire l'autenticazione NTLM.

L'autenticazione di base non è interessata dal proxy inverso o dalla pubblicazione sul Web e funziona indipendentemente dai firewall. Se si utilizza l'autenticazione di base, è necessario tuttavia digitare il dominio, il nome utente e la password ogni volta che si avvia una sessione di Outlook.

Autenticazione di base e autenticazione NTLM

Nella seguente tabella sono illustrate alcune delle differenze fra l'autenticazione di base e l'autenticazione NTLM.

Autenticazione di base	Autenticazione NTLM
Il computer client invia il nome utente e la password con il testo in chiaro. Utilizzare sempre SSL quando si utilizza l'autenticazione di base. Outlook non consente di selezionare l'autenticazione di base senza selezionare anche SSL. Anche il server proxy RPC richiede SSL.	Il computer client invia una richiesta di accesso al server. Il server risponde al computer client con un "token" o una richiesta generata casualmente. Il computer client esegue l'hashing della password protetta crittograficamente relativa all'utente correntemente connesso utilizzando la richiesta e invia la risposta risultante al server. Il server riceve la risposta alla richiesta hash e la confronta con la risposta prevista appropriata (il server prende una copia del token originale, che ha generato, ed esegue l'hashing a fronte dell'hash della password utente ricavata dal database degli account utente del server stesso). Se la risposta ricevuta corrisponde alla risposta prevista, l'utente viene autenticato all'host.
L'autenticazione di base funziona con i firewall a proxy inverso.	L'autenticazione NTLM può non funzionare con alcuni firewall a proxy inverso. Se il firewall esamina il traffico e lo modifica, l'autenticazione NTLM può venire invalidata.
L'autenticazione di base richiede all'utente di immettere il dominio, il nome utente e la password.	NTLM può utilizzare le informazioni di accesso correnti del sistema operativo Microsoft Windows®.

Requisiti per RPC su HTTP per utilizzare le informazioni di accesso correnti del sistema operativo Windows

Affinché RPC su HTTP utilizzi le informazioni di accesso correnti del sistema operativo Windows, i seguenti requisiti devono essere soddisfatti:

• L'utente accede al computer client con le credenziali di dominio corrette.
• L'utente seleziona l'autenticazione NTLM nel profilo di Outlook.
• Il firewall consente l'autenticazione NTLM. Ciò si può verificare se il firewall passa semplicemente la sessione SSL al server di Exchange senza modifiche (filtro delle porte) o se il firewall è un firewall avanzato quale ISA Server 2004. ISA Server 2004 può annullare la pubblicazione Web proxy del server di Exchange e tuttavia consentire l'autenticazione NTLM.
• L'utente invia automaticamente le informazioni di autenticazione NTLM con la connessione. Ciò si verifica in presenza di una delle seguenti condizioni:
  • Si configura Outlook per eseguire l'autenticazione reciproca su SSL. Si tratta del metodo consigliato.
  • Il livello LmCompatibilityLevel del computer client è impostato su 2 o 3.

Per ulteriori informazioni sull'impostazione del livello LmCompatibilityLevel, vedere l'articolo 820281 della Microsoft Knowledge Base, "Necessità di specificare le credenziali dell'account di Windows quando ci si connette a Exchange Server 2003 utilizzando la funzionalità RPC su HTTP di Outlook 2003" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=820281).

Autenticazione RPC

Le richieste RPC autenticate dal server di Exchange utilizzano sempre l'autenticazione NTLM.

SSL

Il computer client deve considerare attendibile il certificato utilizzato per SSL. Affinché il computer client consideri attendibile il certificato utilizzato per SSL, le seguenti condizioni devono essere vere:

• Il nome del certificato corrisponde al sito Web a cui si accede.
• Il certificato non è scaduto.
• Il computer client considera attendibile l'autorità di certificazione che ha rilasciato il certificato.

Se si è già configurato correttamente Outlook Web Access, Exchange ActiveSync o altri servizi Web per l'utilizzo del server front-end di Exchange, il certificato soddisfa questi requisiti.

È possibile individuare la directory virtuale RPC utilizzando Microsoft Internet Explorer per verificare che il certificato sia corretto. Se il certificato non è valido, Internet Explorer visualizza un avviso.

Ripartizione del carico di lavoro SSL

La ripartizione del carico di lavoro SSL si verifica quando il firewall davanti al server proxy RPC chiude la sessione SSL e stabilisce una nuova sessione non SSL con il server front-end. Il firewall non stabilisce specificatamente una nuova sessione SSL.

Se si utilizza la ripartizione del carico di lavoro SSL, è necessario impostare una chiave del Registro di sistema che indichi al server proxy RPC che può accettare una sessione non SSL. Per informazioni dettagliate su come impostare la chiave del Registro di sistema, vedere Configurazione del server proxy RPC per la ripartizione del carico di lavoro SSL su un server separato.