Riferimento porta di rete di Exchange

Articolo
03/03/2017

Si applica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Ultima modifica dell'argomento: 2016-11-28

Questo argomento fornisce informazioni su porte, autenticazione e crittografia per tutti i percorsi di dati utilizzati da MicrosoftExchange Server 2010. La sezione “Note” di ciascuna tabella chiarifica o definisce metodi non standard di autenticazione o crittografia.

Server di trasporto

Exchange 2010 include due ruoli del server che eseguono la funzionalità di trasporto dei messaggi: i server Trasporto Hub e i server Trasporto Edge.

Nella seguente tabella vengono fornite informazioni sulle porte, sull'autenticazione e sulla crittografia dei percorsi dei dati tra questi server di trasporto e altri server e servizi di Exchange 2010.

Percorsi dei dati tra i server di trasporto

Percorso dati	Porte richieste	Autenticazione predefinita	Autenticazione supportata	È supportata la crittografia?	I dati sono crittografati per impostazione predefinita?
Da server Trasporto Hub a server Trasporto Hub	25/TCP (SMTP)	Kerberos	Kerberos	Sì, utilizzando TLS (Transport Layer Security)	Sì
Da server Trasporto Hub a server Trasporto Edge	25/TCP (SMTP)	Trust diretto	Trust diretto	Sì, utilizzando TLS	Sì
Da server Trasporto Edge a server Trasporto Hub	25/TCP (SMTP)	Trust diretto	Trust diretto	Sì, utilizzando TLS	Sì
Da server Trasporto Edge a server Trasporto Edge	25/TCP (SMTP)	Anonima, certificato	Anonima, certificato	Sì, utilizzando TLS	Sì
Da server Cassette postali a server Trasporto Hub tramite il servizio di invio posta di Microsoft Exchange	135/TCP (RPC)	NTLM. Se i ruoli del server Trasporto Hub e Cassette postali si trovano sullo stesso server, viene utilizzato Kerberos.	NTLM/Kerberos	Sì, utilizzando la crittografia RPC	Sì
Da server Trasporto Hub a server di cassette postali tramite MAPI	135/TCP (RPC)	NTLM. Se i ruoli del server Trasporto Hub e Cassette postali si trovano sullo stesso server, viene utilizzato Kerberos.	NTLM/Kerberos	Sì, utilizzando la crittografia RPC	Sì
Da server di messaggistica unificata a server Trasporto Hub	25/TCP (SMTP)	Kerberos	Kerberos	Sì, utilizzando TLS	Sì
Microsoft Servizio EdgeSync di Exchange da server Trasporto Hub a server Trasporto Edge	50636/TCP (SSL)	Di base	Di base	Sì, utilizzando LDAP su SSL (LDAPS)	Sì
Accesso ad Active Directory da server Trasporto Hub	389/TCP/UDP (LDAP), 3268/TCP (catalogo globale LDAP), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (Accesso rete RPC)	Kerberos	Kerberos	Sì, utilizzando la crittografia Kerberos	Sì
Accesso ai servizi AD RMS (Active Directory Rights Management Services) da server Trasporto Hub	443/TCP (HTTPS)	NTLM/Kerberos	NTLM/Kerberos	Sì, utilizzando SSL	Sì*
Da client SMTP a server Trasporto Hub (ad esempio utenti finali che utilizzano Windows Live Mail)	587 (SMTP) 25/TCP (SMTP)	NTLM/Kerberos	NTLM/Kerberos	Sì, utilizzando TLS	Sì

Note sui server di trasporto

Tutto il traffico tra i server Trasporto Hub viene crittografato tramite TLS con certificati autofirmati installati dal programma di installazione di Exchange 2010.

Nota

In Exchange 2010, TLS può essere disabilitato sui server Trasporto Hub per la comunicazione SMTP interna con altri server Trasporto Hub nella stessa organizzazione di Exchange. Tuttavia, si sconsiglia di farlo a meno che non sia assolutamente necessario. Per ulteriori informazioni, vedere Disabilitazione TLS tra i siti Active Directory per supportare l'ottimizzazione WAN.
Tutto il traffico tra i server Trasporto Edge e Trasporto Hub viene autenticato e crittografato. MTLS (Mutual TLS) è il meccanismo sottostante per l'autenticazione e la crittografia. Anziché utilizzare la convalida X.509, in Exchange 2010 i certificati vengono autenticati tramite trust diretto. Trust diretto significa che la presenza del certificato in Active Directory o in AD LDS (Active Directory Lightweight Directory Services) funge da convalida per il certificato. Active Directory è considerato un meccanismo di archiviazione attendibile. Quando viene utilizzato il trust diretto, è irrilevante che il certificato sia autofirmato o firmato da un'Autorità di certificazione. Quando si sottoscrive un server Trasporto Edge in un'organizzazione di Exchange, la sottoscrizione Edge pubblica il certificato del server Trasporto Edge in Active Directory affinché i server Trasporto Hub possano eseguire la convalida. Il servizio EdgeSync di Microsoft Exchange aggiorna AD LDS con l'insieme di certificati del server Trasporto Hub affinché il server Trasporto Edge possa eseguire la convalida.
EdgeSync utilizza una connessione LDAP protetta dal server Trasporto Hub ai server Trasporto Edge sottoscritti sulla porta TCP 50636. I servizi AD LDS eseguono anche l'ascolto sulla porta TCP 50389. Le connessioni a questa porta non utilizzano SSL. È possibile utilizzare i programmi di utilità LDAP per connettersi alla porta e controllare i dati di AD LDS.
Per impostazione predefinita, il traffico tra i server Trasporto Edge di due organizzazioni diverse viene crittografato. Nel programma di installazione di Exchange 2010 viene creato un certificato autofirmato e TLS è abilitato per impostazione predefinita. In questo modo qualsiasi sistema di invio può crittografare la sessione SMTP in ingresso in Exchange. Inoltre per impostazione predefinita, Exchange 2010 tenta di applicare TLS a tutte le connessioni remote.
I metodi di autenticazione del traffico tra i server Trasporto Hub e i server di cassette postali cambiano quando i ruoli dei rispettivi server sono installati nello stesso computer. Quando l'invio di posta è locale, viene utilizzata l'autenticazione Kerberos. Quando l'invio di posta è remoto, viene utilizzata l'autenticazione NTLM.
Exchange 2010 supporta anche la protezione del dominio. La protezione del dominio fa riferimento alle funzionalità in Exchange 2010 e Microsoft Outlook 2010 che forniscono un'alternativa a basso costo rispetto a S/MIME o ad altre soluzioni di protezione a livello dei messaggi su Internet. La protezione del dominio mette a disposizione un metodo per gestire percorsi dei messaggi protetti tra i domini su Internet. Dopo aver configurato questi percorsi dei messaggi protetti, i messaggi che hanno seguito con successo il percorso protetto e che provengono da un mittente autenticato appaiono come "Dominio protetto" agli utenti di Outlook e Outlook Web Access. Per ulteriori informazioni, vedere Informazioni sulla protezione del dominio.
Sui server Trasporto Hub e Trasporto Edge è possibile eseguire diversi agenti. In genere, gli agenti di protezione dalla posta indesiderata si basano sulle informazioni locali presenti nel computer in cui vengono eseguiti. Pertanto, sono richieste poche comunicazioni con i computer remoti. I filtri destinatario rappresentano l'eccezione. I filtri destinatario richiedono l'esecuzione di chiamate ai servizi AD LDS o Active Directory. La procedura ottimale prevede di eseguire i filtri destinatario sul server Trasporto Edge. In questo caso, la directory AD LDS è sullo stesso computer del server Trasporto Edge. Pertanto, non è necessaria alcuna comunicazione remota. Una volta installato e configurato nel server Trasporto Hub, il filtro destinatario esegue l'accesso ad Active Directory.
La funzionalità Reputazione mittente in Exchange 2010 utilizza l'agente Analisi protocollo. Per determinare i percorsi dei messaggi in ingresso provenienti da connessioni sospette, questo agente effettua inoltre diverse connessioni ai server proxy esterni.
Tutte le altre funzionalità anti-spam utilizzano dati, quali l'aggregazione dell'elenco indirizzi attendibili e i dati del destinatario per il filtro destinatari. Questi dati vengono raccolti, archiviati e utilizzati solo sul computer locale. Frequentemente, i dati vengono inseriti nella directory AD LDS locale tramite il servizio MicrosoftExchange EdgeSync.
Gli agenti IRM (Information Rights Management) sui server Trasporto Hub effettuano connessioni ai server AD RMS (Active Directory Rights Management Services) nell'organizzazione. AD RMS è un servizio Web protetto tramite SSL (secondo la procedura consigliata). La comunicazione con i server AD RMS avviene tramite HTTPS, mentre per l'autenticazione viene utilizzato Kerberos o NTLM, a seconda della configurazione del server AD RMS.
Le regole del journal, le regole di trasporto e le classificazioni dei messaggi sono archiviate in Active Directory e possono essere utilizzate dall'agente di journaling e dall'agente Regole di trasporto sui server Trasporto Hub.

Server di cassette postali

Se utilizzare le autenticazioni NTLM o Kerberos per server di cassette postali dipende da quale consumer del livello della regola business di Exchange l'utente o il contesto del processo sono in esecuzione. In questo contesto, il consumer è un'applicazione o un processo che utilizza il livello della regola business di Exchange. Di conseguenza, molte voci nella colonna Autenticazione predefinita della tabella Percorsi dei dati tra i server di cassette postali sono elencati come NTLM/Kerberos.

Il livello della logica business di Exchange viene utilizzato per accedere e comunicare con l'archivio di Exchange. Inoltre, questo livello di Exchange viene richiamato dall'archivio di Exchange per comunicare con applicazioni e processi esterni.

Se il consumer del livello della logica business di Exchange viene eseguito come sistema locale, il metodo di autenticazione dal consumer all'archivio di Exchange sarà sempre Kerberos. Viene utilizzato Kerberos poiché il consumer deve essere autenticato tramite l'account di sistema locale del computer e in presenza di un trust autenticato bidirezionale.

Se il consumer del livello della logica business di Exchange non viene eseguito come sistema locale, viene utilizzato il metodo di autenticazione NTLM. Ad esempio, quando viene eseguito un cmdlet di Exchange Management Shell che utilizza il livello della logica di business di Exchange, viene utilizzata l'autenticazione NTLM.

Il traffico RPC viene sempre crittografato.

Nella tabella seguente vengono fornite informazioni sulle porte, sull'autenticazione e sulla crittografia dei percorsi dei dati tra i server Cassette postali.

Percorsi dei dati tra i server di cassette postali

Percorso dati	Porte richieste	Autenticazione predefinita	Autenticazione supportata	È supportata la crittografia?	I dati sono crittografati per impostazione predefinita?
Accesso ad Active Directory	389/TCP/UDP (LDAP), 3268/TCP (catalogo globale LDAP), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (Accesso rete RPC)	Kerberos	Kerberos	Sì, utilizzando la crittografia Kerberos	Sì
Accesso amministrativo remoto (Registro di sistema remoto)	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Sì, utilizzando IPsec	No
Accesso amministrativo remoto (SMB/file)	445/TCP (SMB)	NTLM/Kerberos	NTLM/Kerberos	Sì, utilizzando IPsec	No
Servizio Web Disponibilità (Accesso client a cassette postali)	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Sì, utilizzando la crittografia RPC	Sì
Clustering	135/TCP (RPC) Vedere Note sui server di cassette postali dopo la tabella.	NTLM/Kerberos	NTLM/Kerberos	Sì, utilizzando IPsec	No
Indicizzazione del contenuto	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Sì, utilizzando la crittografia RPC	Sì
Log shipping	64327 (personalizzabile)	NTLM/Kerberos	NTLM/Kerberos	Sì	No
Seeding	64327 (personalizzabile)	NTLM/Kerberos	NTLM/Kerberos	Sì	No
Backup del servizio Copia Shadow del volume (VSS)	Blocco dei messaggi locali (SMB)	NTLM/Kerberos	NTLM/Kerberos	No	No
Assistenti cassette postali	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	No	No
Accesso MAPI	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Sì, utilizzando la crittografia RPC	Sì
Accesso al servizio Microsoft Exchange Active Directory Topology	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Sì, utilizzando la crittografia RPC	Sì
Accesso legacy al servizio Supervisore sistema di Microsoft Exchange (ascolto delle richieste)	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	No	No
Accesso legacy al servizio Supervisore sistema di Microsoft Exchange in Active Directory	389/TCP/UDP (LDAP), 3268/TCP (catalogo globale LDAP), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (Accesso rete RPC)	Kerberos	Kerberos	Sì, utilizzando la crittografia Kerberos	Sì
Accesso legacy al servizio Supervisore sistema di Microsoft Exchange (come client MAPI)	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Sì, utilizzando la crittografia RPC	Sì
Accesso della Rubrica offline ad Active Directory	135/TCP (RPC)	Kerberos	Kerberos	Sì, utilizzando la crittografia RPC	Sì
Accesso RPC al Servizio aggiornamento destinatari	135/TCP (RPC)	Kerberos	Kerberos	Sì, utilizzando la crittografia RPC	Sì
Aggiornamento destinatari in Active Directory	389/TCP/UDP (LDAP), 3268/TCP (catalogo globale LDAP), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (Accesso rete RPC)	Kerberos	Kerberos	Sì, utilizzando la crittografia Kerberos	Sì

Note sui server di cassette postali

Il percorso dei dati di clustering indicato nella precedente tabella utilizza RPC dinamico su TCP per comunicare l'attività e lo stato del cluster tra i diversi nodi cluster. Per la comunicazione tra i nodi cluster, il Servizio cluster (ClusSvc.exe) utilizza anche la porta UDP/3343 e le porte TCP con numero elevato assegnate in modo casuale.
Per le comunicazioni tra nodi cluster viene utilizzata la porta UDP (User Datagram Protocol) 3343. A intervalli periodici ogni nodo cluster scambia datagrammi UDP unicast sequenziali con gli altri nodi presenti nel cluster. Lo scopo dello scambio è quello di verificare l'esecuzione corretta di tutti i nodi e anche di monitorare l'integrità dei collegamenti di rete.
La porta 64327/TCP è la porta predefinita utilizzata per il log shipping. Gli amministratori possono specificare una porta diversa per il log shipping.
Per l'autenticazione HTTP in cui è indicata l'opzione di negoziazione, viene eseguito prima un tentativo con Kerberos, quindi con NTLM.

Server Accesso client

Se non è specificato diversamente, le tecnologie di accesso client, ad esempio Outlook Web App, POP3 o IMAP4, sono descritte dall'autenticazione e dalla crittografia tra l'applicazione client e il server Accesso client.

Nella seguente tabella vengono fornite informazioni sulle porte, sull'autenticazione e sulla crittografia dei percorsi dei dati tra i server Accesso client e altri server e client.

Percorsi dei dati del server Accesso client

Percorso dati	Porte richieste	Autenticazione predefinita	Autenticazione supportata	È supportata la crittografia?	I dati sono crittografati per impostazione predefinita?
Accesso ad Active Directory	389/TCP/UDP (LDAP), 3268/TCP (catalogo globale LDAP), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (Accesso rete RPC)	Kerberos	Kerberos	Sì, utilizzando la crittografia Kerberos	Sì
Servizio di individuazione automatica	80/TCP, 443/TCP (SSL)	Autenticazione di base o integrata di Windows (negoziazione)	Di base, digest, NTLM e negoziazione (Kerberos)	Sì, utilizzando HTTPS	Sì
Servizio Disponibilità	80/TCP, 443/TCP (SSL)	NTLM/Kerberos	NTLM, Kerberos	Sì, utilizzando HTTPS	Sì
Servizio di replica delle cassette postali (MRS) Microsoft	808/TCP	Kerberos/NTLM	Kerberos, NTLM	Sì, utilizzando la crittografia RPC	Sì
Accesso di Outlook alla Rubrica offline	80/TCP, 443/TCP (SSL)	NTLM/Kerberos	NTLM/Kerberos	Sì, utilizzando HTTPS	No
Outlook Web App	80/TCP, 443/TCP (SSL)	Autenticazione basata su moduli	Di base, digest, basata su moduli, NTLM (solo versione 2), Kerberos e certificato	Sì, utilizzando HTTPS	Sì, utilizzando un certificato autofirmato
POP3	110/TCP (TLS), 995/TCP (SSL)	Di base, Kerberos	Di base, Kerberos	Sì, utilizzando SSL, TLS	Sì
IMAP4	143/TCP (TLS), 993/TCP (SSL)	Di base, Kerberos	Di base, Kerberos	Sì, utilizzando SSL, TLS	Sì
Outlook via Internet (in precedenza noto come RPC su HTTP)	80/TCP, 443/TCP (SSL)	Di base	Di base o NTLM	Sì, utilizzando HTTPS	Sì
Applicazione Exchange ActiveSync	80/TCP, 443/TCP (SSL)	Di base	Di base, certificato	Sì, utilizzando HTTPS	Sì
Da server Accesso client a server di messaggistica unificata	5060/TCP, 5061/TCP, 5062/TCP, una porta dinamica	Per indirizzo IP	Per indirizzo IP	Sì, utilizzando SIP (Session Initiation Protocol) su TLS	Sì
Da server Accesso client a server di cassette postali in cui viene eseguita una versione precedente di Exchange Server	80/TCP, 443/TCP (SSL)	NTLM/Kerberos	Negoziazione (Kerberos con fallback su NTLM oppure autenticazione di base facoltativa), testo normale POP/IMAP	Sì, utilizzando IPsec	No
Dal server Accesso client a server di cassette postali di Exchange 2010	RPC. vedere Note sui server Accesso client.	Kerberos	NTLM/Kerberos	Sì, utilizzando la crittografia RPC	Sì
Da server Accesso client a server Accesso client (Exchange ActiveSync)	80/TCP, 443/TCP (SSL)	Kerberos	Kerberos, certificato	Sì, utilizzando HTTPS	Sì, utilizzando un certificato autofirmato
Da server Accesso client a server Accesso client (Outlook Web Access)	80/TCP, 443/TCP (HTTPS)	Kerberos	Kerberos	Sì, utilizzando SSL	Sì
Da server Accesso client a server Accesso client (Servizi Web Exchange)	443/TCP (HTTPS)	Kerberos	Kerberos	Sì, utilizzando SSL	Sì
Da server Accesso client a server Accesso client (POP3)	995 (SSL)	Di base	Di base	Sì, utilizzando SSL	Sì
Da server Accesso client a server Accesso client (IMAP4)	993 (SSL)	Di base	Di base	Sì, utilizzando SSL	Sì
Accesso di Office Communications Server al server Accesso client (se l'integrazione di Office Communications Server e Outlook Web App è abilitata)	5075-5077/TCP (IN), 5061/TCP (OUT)	mTLS (obbligatorio)	mTLS (obbligatorio)	Sì, utilizzando SSL	Sì

Nota

L'autenticazione Windows integrata (NTLM) non è supportata per la connettività client POP3 o IMAP4. Per ulteriori informazioni, vedere le sezioni "Funzionalità di accesso client" in Funzionalità sospese.

Note sui server Accesso client

In Exchange 2010, i client MAPI, ad esempio Microsoft Outlook, si connettono ai server Accesso client.
I server Accesso client utilizzano molte porte per comunicare con i server di cassette postali. Con alcune eccezioni, tali porte sono determinate dal servizio RPC e non sono fisse.
Per l'autenticazione HTTP in cui è indicata l'opzione di negoziazione, viene eseguito prima un tentativo con Kerberos, quindi con NTLM.
Per le comunicazioni tra un server Accesso client di Exchange 2010 e un server Cassette postali in cui viene eseguito MicrosoftExchange Server 2003, si consiglia di utilizzare Kerberos e di disabilitare l'autenticazione NTLM e l'autenticazione di base. Inoltre, si consiglia di configurare Outlook Web App per l'utilizzo dell'autenticazione basata su moduli con un certificato attendibile. Affinché i client di Exchange ActiveSync possano comunicare tramite il server Accesso client di Exchange 2010 con il server di back-end di Exchange 2003, è necessario che l'autenticazione integrata di Windows sia abilitata nella directory virtuale Microsoft-Server-ActiveSync sul server di back-end di Exchange 2003. Per utilizzare Gestore di sistema di Exchange su un server Exchange 2003 al fine di gestire l'autenticazione in una directory virtuale di Exchange 2003, scaricare e installare l'aggiornamento rapido a cui viene fatto riferimento nell'articolo 937031 della Microsoft Knowledge Base relativo allaregistrazione dell'ID evento 1036 su un server Exchange 2007 che esegue il ruolo CAS quando i dispositivi mobili si connettono al server Exchange 2007 per accedere alle cassette postali su un server di back-end Exchange 2003.

Nota

Anche se l'articolo della Knowledge Base è specifico per MicrosoftExchange Server 2007, può essere applicato anche a Exchange 2010.
Quando un server Accesso client esegue il proxy delle richieste POP3 verso un altro server Accesso client, la comunicazione avviene tramite la porta 995/TCP. Ciò vale indipendentemente dal fatto che il client richiedente la connessione utilizzi il POP3 e richieda il TLS (sulla porta 110/TCP) oppure si connetta tramite la porta 995/TCP con crittografia SSL. Analogamente, per le connessioni IMAP4, il server richiedente utilizza la porta 993/TCP per eseguire il proxy delle richieste, indipendentemente dal fatto che il client richiedente la connessione utilizzi IMAP4 e richieda il TLS (sulla porta 443/TCP) oppure si connetta tramite la porta 995 utilizzando IMAP4 con crittografia SSL

Connettività al server Accesso client

Oltre ad avere un server Accesso client in ogni sito di Active Directory che contiene un server Cassette postali, è importante evitare di limitare il traffico fra i server Exchange. Verificare che tutte le porte definite utilizzate da Exchange siano aperte in entrambe le direzioni, tra tutti i server di origine e destinazione. L'installazione di un firewall tra i server Exchange oppure tra un server Cassette postali o server Accesso client di Exchange 2010 e Active Directory non è supportata. È tuttavia possibile installare un dispositivo di rete, purché non limiti il traffico e tutte le porte disponibili siano aperte tra i vari server Exchange e Active Directory.

Server di messaggistica unificata

I gateway IP e gli IP PBX supportano solo l'autenticazione basata su certificato in cui vengono utilizzati MTLS per la crittografia del traffico SIP e l'autenticazione IP per le connessioni SIP/TCP. I gateway IP non supportano né l'autenticazione NTLM né l'autenticazione Kerberos. Pertanto, quando si utilizza l'autenticazione basata su IP, vengono utilizzati gli indirizzi IP di connessione per fornire il meccanismo di autenticazione delle connessioni (TCP) non crittografate. Quando si utilizza l'autenticazione basata su IP nella messaggistica unificata, il server di messaggistica unificata verifica che l'indirizzo IP sia autorizzato a effettuare la connessione. L'indirizzo IP viene configurato sul gateway IP o IP PBX.

I gateway IP e IP PBX supportano MTLS per la crittografia del traffico SIP. Dopo aver importato ed esportato correttamente i certificati attendibili richiesti, il gateway IP o IP PBX richiederà un certificato dal server di messaggistica unificata, quindi quest'ultimo richiederà un certificato dal gateway IP o IP PBX. Lo scambio di certificati attendibili tra il gateway IP o IP PBX e il server di messaggistica unificata abilita la comunicazione tra il gateway IP/IP PBX e il server di messaggistica unificata mediante una connessione crittografata con MTLS.

Nella seguente tabella vengono fornite informazioni sulla porta, sull'autenticazione e sulla crittografia dei percorsi dei dati tra i server di messaggistica unificata e altri server.

Percorsi dei dati del server di messaggistica unificata

Percorso dati	Porte richieste	Autenticazione predefinita	Autenticazione supportata	È supportata la crittografia?	I dati sono crittografati per impostazione predefinita?
Accesso ad Active Directory	389/TCP/UDP (LDAP), 3268/TCP (catalogo globale LDAP), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (Accesso rete RPC)	Kerberos	Kerberos	Sì, utilizzando la crittografia Kerberos	Sì
Interazione telefonica di messaggistica unificata (IP PBX/gateway VoIP)	5060/TCP, 5065/TCP, 5067/TCP (non protetto), 5061/TCP, 5066/TCP, 5068/TCP (protetto), una porta dinamica nell'intervallo 16000-17000/TCP (controllo), porte UDP dinamiche nell'intervallo 1024-65535/UDP (RTP)	Per indirizzo IP	Per indirizzo IP, MTLS	Sì, utilizzando SIP/TLS, SRTP	No
Servizio Web di messaggistica unificata	80/TCP, 443/TCP (SSL)	Autenticazione integrata di Windows (negoziazione)	Di base, digest, NTLM e negoziazione (Kerberos)	Sì, utilizzando SSL	Sì
Da server di messaggistica unificata a server Accesso client	5075, 5076, 5077 (TCP)	Autenticazione integrata di Windows (negoziazione)	Di base, digest, NTLM e negoziazione (Kerberos)	Sì, utilizzando SSL	Sì
Da server di messaggistica unificata a server Accesso client (Ascolta al telefono)	RPC dinamico	NTLM/Kerberos	NTLM/Kerberos	Sì, utilizzando la crittografia RPC	Sì
Da server di messaggistica unificata a server Trasporto Hub	25/TCP (TLS)	Kerberos	Kerberos	Sì, utilizzando TLS	Sì
Da server di messaggistica unificata a server di cassette postali	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Sì, utilizzando la crittografia RPC	Sì

Note sui server di messaggistica unificata

Quando viene creato un oggetto gateway IP di messaggistica unificata in Active Directory, è necessario definire l'indirizzo IP del gateway IP fisico o IP PBX (Private Branch eXchange). Una volta definito sull'oggetto gateway IP di messaggistica unificata, l'indirizzo IP viene aggiunto a un elenco di gateway IP o IP PBX validi (detti anche peer SIP) con cui il server di messaggistica unificata è autorizzato a comunicare. Una volta creato il gateway IP di messaggistica unificata, è possibile associarlo a un dial plan di messaggistica unificata. In questo modo i server di messaggistica unificata associati al dial plan possono utilizzare l'autenticazione basata su IP per comunicare con il gateway IP. Se il gateway IP di messaggistica unificata non è stato creato o configurato per utilizzare l'indirizzo IP corretto, l'autenticazione non verrà completata e i server di messaggistica unificata non accetteranno connessioni dall'indirizzo IP del gateway IP. Inoltre, quando si implementano MTLS, gateway IP o IP PBX e server di messaggistica unificata, il gateway IP di messaggistica unificata deve essere configurato per utilizzare il nome di dominio completo (FQDN). Dopo aver configurato il gateway IP di messaggistica unificata con un nome di dominio completo, è necessario aggiungere un record host per il gateway IP di messaggistica unificata alla zona di ricerca diretta DNS.
In Exchange 2010, un server di messaggistica unificata può comunicare sulla porta 5060/TCP (non protetta) o sulla porta 5061/TCP (protetta) e può essere configurato per utilizzare entrambe.

Per ulteriori informazioni, vedere Informazioni sulle protezione VoIP per la Messaggistica unificata e Concetti relativi a protocolli, porte e servizi in messaggistica unificata.

Regole di Windows Firewall create dal programma di installazione di Exchange 2010

Windows Firewall con protezione avanzata è un firewall con stato basato su host che filtra il traffico in entrata e in uscita in base alle regole del firewall. Il programma di installazione di Exchange 2010 crea regole di Windows Firewall per aprire le porte necessarie per la comunicazione tra server e client su ciascun ruolo del server. Di conseguenza, non è più necessario utilizzare Configurazione guidata impostazioni di sicurezza per configurare queste impostazioni. Per ulteriori informazioni su Windows Firewall con protezione avanzata, vedere Windows Firewall with Advanced Security and IPsec (le informazioni potrebbero essere in inglese).

In questa tabella sono elencate le regole di Windows Firewall create dal programma di installazione di Exchange e le porte aperte su ciascun ruolo del server. È possibile visualizzare queste regole utilizzando lo snap-in di MMC Windows Firewall con protezione avanzata.

Nome della regola	Ruoli del server	Porta	Programma
MSExchangeADTopology - RPC (TCP-In)	Accesso client, Trasporto Hub, Cassette postali, Messaggistica unificata	RPC dinamico	Bin\MSExchangeADTopologyService.exe
MSExchangeMonitoring - RPC (TCP-In)	Accesso client, Trasporto Hub, Trasporto Edge, Messaggistica unificata	RPC dinamico	Bin\Microsoft.Exchange.Management.Monitoring.exe
MSExchangeServiceHost - RPC (TCP-In)	Tutti i ruoli	RPC dinamico	Bin\Microsoft.Exchange.ServiceHost.exe
MSExchangeServiceHost - RPCEPMap (TCP-In)	Tutti i ruoli	RPC-EPMap	Bin\Microsoft.Exchange.Service.Host
MSExchangeRPCEPMap (GFW) (TCP-In)	Tutti i ruoli	RPC-EPMap	Qualsiasi
MSExchangeRPC (GFW) (TCP-In)	Accesso client, Trasporto Hub, Cassette postali, Messaggistica unificata	RPC dinamico	Qualsiasi
MSExchange - IMAP4 (GFW) (TCP-In)	Accesso client	143, 993 (TCP)	Tutte
MSExchangeIMAP4 (TCP-In)	Accesso client	143, 993 (TCP)	ClientAccess\PopImap\Microsoft.Exchange.Imap4Service.exe
MSExchange - POP3 (FGW) (TCP-In)	Accesso client	110, 995 (TCP)	Tutte
MSExchange - POP3 (TCP-In)	Accesso client	110, 995 (TCP)	ClientAccess\PopImap\Microsoft.Exchange.Pop3Service.exe
MSExchange - OWA (GFW) (TCP-In)	Accesso client	5075, 5076, 5077 (TCP)	Tutte
MSExchangeOWAAppPool (TCP-In)	Accesso client	5075, 5076, 5077 (TCP)	Inetsrv\w3wp.exe
MSExchangeAB-RPC (TCP-In)	Accesso client	RPC dinamico	Bin\Microsoft.Exchange.AddressBook.Service.exe
MSExchangeAB-RPCEPMap (TCP-In)	Accesso client	RPC-EPMap	Bin\Microsoft.Exchange.AddressBook.Service.exe
MSExchangeAB-RpcHttp (TCP-In)	Accesso client	6002, 6004 (TCP)	Bin\Microsoft.Exchange.AddressBook.Service.exe
RpcHttpLBS (TCP-In)	Accesso client	RPC dinamico	System32\Svchost.exe
MSExchangeRPC - RPC (TCP-In)	Accesso client, Cassette postali	RPC dinamico	Bin\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeRPC - PRCEPMap (TCP-In)	Accesso client, Cassette postali	RPC-EPMap	Bin\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeRPC (TCP-In)	Accesso client, Cassette postali	6001 (TCP)	Bin\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeMailboxReplication (GFW) (TCP-In)	Accesso client	808 (TCP)	Qualsiasi
MSExchangeMailboxReplication (TCP-In)	Accesso client	808 (TCP)	Bin\MSExchangeMailboxReplication.exe
MSExchangeIS - RPC (TCP-In)	Cassette postali	RPC dinamico	Bin\Store.exe
MSExchangeIS RPCEPMap (TCP-In)	Cassette postali	RPC-EPMap	Bin\Store.exe
MSExchangeIS (GFW) (TCP-In)	Cassette postali	6001, 6002, 6003, 6004 (TCP)	Qualsiasi
MSExchangeIS (TCP-In)	Cassette postali	6001 (TCP)	Bin\Store.exe
MSExchangeMailboxAssistants - RPC (TCP-In)	Cassette postali	RPC dinamico	Bin\MSExchangeMailboxAssistants.exe
MSExchangeMailboxAssistants - RPCEPMap (TCP-In)	Cassette postali	RPC-EPMap	Bin\MSExchangeMailboxAssistants.exe
MSExchangeMailSubmission - RPC (TCP-In)	Cassette postali	RPC dinamico	Bin\MSExchangeMailSubmission.exe
MSExchangeMailSubmission - RPCEPMap (TCP-In)	Cassette postali	RPC-EPMap	Bin\MSExchangeMailSubmission.exe
MSExchangeMigration - RPC (TCP-In)	Cassette postali	RPC dinamico	Bin\MSExchangeMigration.exe
MSExchangeMigration - RPCEPMap (TCP-In)	Cassette postali	RPC-EPMap	Bin\MSExchangeMigration.exe
MSExchangerepl - Log Copier (TCP-In)	Cassette postali	64327 (TCP)	Bin\MSExchangeRepl.exe
MSExchangerepl - RPC (TCP-In)	Cassette postali	RPC dinamico	Bin\MSExchangeRepl.exe
MSExchangerepl - RPC-EPMap (TCP-In)	Cassette postali	RPC-EPMap	Bin\MSExchangeRepl.exe
MSExchangeSearch - RPC (TCP-In)	Cassette postali	RPC dinamico	Bin\Microsoft.Exchange.Search.ExSearch.exe
MSExchangeThrottling - RPC (TCP-In)	Cassette postali	RPC dinamico	Bin\MSExchangeThrottling.exe
MSExchangeThrottling - RPCEPMap (TCP-In)	Cassette postali	RPC-EPMap	Bin\MSExchangeThrottling.exe
MSFTED - RPC (TCP-In)	Cassette postali	RPC dinamico	Bin\MSFTED.exe
MSFTED - RPCEPMap (TCP-In)	Cassette postali	RPC-EPMap	Bin\MSFTED.exe
MSExchangeEdgeSync - RPC (TCP-In)	Trasporto Hub	RPC dinamico	Bin\Microsoft.Exchange.EdgeSyncSvc.exe
MSExchangeEdgeSync - RPCEPMap (TCP-In)	Trasporto Hub	RPC-EPMap	Bin\Microsoft.Exchange.EdgeSyncSvc.exe
MSExchangeTransportWorker - RPC (TCP-In)	Trasporto Hub	RPC dinamico	Bin\edgetransport.exe
MSExchangeTransportWorker - RPCEPMap (TCP-In)	Trasporto Hub	RPC-EPMap	Bin\edgetransport.exe
MSExchangeTransportWorker (GFW) (TCP-In)	Trasporto Hub	25, 587 (TCP)	Qualsiasi
MSExchangeTransportWorker (TCP-In)	Trasporto Hub	25, 587 (TCP)	Bin\edgetransport.exe
MSExchangeTransportLogSearch - RPC (TCP-In)	Trasporto Hub, Trasporto Edge, Cassette postali	RPC dinamico	Bin\MSExchangeTransportLogSearch.exe
MSExchangeTransportLogSearch - RPCEPMap (TCP-In)	Trasporto Hub, Trasporto Edge, Cassette postali	RPC-EPMap	Bin\MSExchangeTransportLogSearch.exe
SESWorker (GFW) (TCP-In)	Messaggistica unificata	Qualsiasi	Qualsiasi
SESWorker (TCP-In)	Messaggistica unificata	Qualsiasi	UnifiedMessaging\SESWorker.exe
UMService (GFW) (TCP-In)	Messaggistica unificata	5060, 5061	Qualsiasi
UMService (TCP-In)	Messaggistica unificata	5060, 5061	Bin\UMService.exe
UMWorkerProcess (GFW) (TCP-In)	Messaggistica unificata	5065, 5066, 5067, 5068	Qualsiasi
UMWorkerProcess (TCP-In)	Messaggistica unificata	5065, 5066, 5067, 5068	Bin\UMWorkerProcess.exe
UMWorkerProcess - RPC (TCP-In)	Messaggistica unificata	RPC dinamico	Bin\UMWorkerProcess.exe

Note sulle regole di Windows Firewall create dal programma di installazione di Exchange 2010

Sui server in cui è installato Internet Information Services (IIS), Windows apre le porte HTTP (porta 80, TCP) e HTTPS (porta 443, TCP). Il programma di installazione di Exchange 2010 non apre queste porte. Di conseguenza, queste porte non sono inserite nella tabella precedente.
In Windows Server 2008 e Windows Server 2008 R2, Windows Firewall con protezione avanzata consente di specificare il processo o il servizio per cui viene aperta una porta. Questa procedura è più sicura, perché limita l'uso della porta al processo o al servizio specificato nella regola. Il programma di installazione di Exchange crea le regole del firewall con il nome del processo specificato. In alcuni casi, viene creata anche una regola aggiuntiva non limitata al processo per ragioni di compatibilità. È possibile disabilitare o rimuovere le regole non limitate ai processi e mantenere le corrispondenti regole limitate ai processi, se la distribuzione supporta questa scelta. Le regole non limitate ai processi sono indicate dalla parola (GFW) nel nome della regola.
Molti servizi di Exchange utilizzano chiamate di procedure remote (RPC) per la comunicazione. I processi server che utilizzano le chiamate RPC contattano il mapper di endpoint RPC per ricevere endpoint dinamici e registrarli nel database del mapper di endpoint. I client RPC contattano il mapper di endpoint RPC per determinare gli endpoint utilizzati dal processo del server. Per impostazione predefinita, il mapper di endpoint RPC è in ascolto sulla porta 135 (TCP). Durante la configurazione di Windows Firewall per un processo che utilizza le chiamate RPC, il programma di installazione di Exchange 2010 crea due regole del firewall per il processo. Una regola consente la comunicazione con il mapper di endpoint RPC, l'altra consente la comunicazione con l'endpoint assegnato in modo dinamico. Per ulteriori informazioni sulle chiamate RPC, vedere Funzionamento di RPC. Per ulteriori informazioni sulla creazione di regole di Windows Firewall per le chiamate RPC dinamiche, vedere Passaggio 4: consentire il traffico di rete in entrata che utilizza RPC dinamico.