Riferimento porta di rete di Exchange

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

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

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

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

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.

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.

Per ulteriori informazioni, vedere l'articolo 179442 della Microsoft Knowledge Base, Configurazione di un firewall per domini e trust.

 ©2010 Microsoft Corporation. Tutti i diritti riservati.