Esporta (0) Stampa
Espandi tutto
Argomenti della Guida correlati
Loading
Nessuna risorsa trovata.
Articoli blog correlati
Loading
Nessuna risorsa trovata.
Espandi Riduci a icona

Riferimento porta di rete di Exchange

Exchange 2010
 

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

Ultima modifica dell'argomento: 2012-09-25

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

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)

Da server Trasporto Hub a server Trasporto Edge

25/TCP (SMTP)

Trust diretto

Trust diretto

Sì, utilizzando TLS

Da server Trasporto Edge a server Trasporto Hub

25/TCP (SMTP)

Trust diretto

Trust diretto

Sì, utilizzando TLS

Da server Trasporto Edge a server Trasporto Edge

25/TCP (SMTP)

Anonima, certificato

Anonima, certificato

Sì, utilizzando TLS

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

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

Da server di messaggistica unificata a server Trasporto Hub

25/TCP (SMTP)

Kerberos

Kerberos

Sì, utilizzando TLS

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)

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

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

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

    NotaNota:
    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 Microsoft Exchange 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.

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

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

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

Log shipping

64327 (personalizzabile)

NTLM/Kerberos

NTLM/Kerberos

No

Seeding

64327 (personalizzabile)

NTLM/Kerberos

NTLM/Kerberos

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

Accesso al servizio Microsoft Exchange Active Directory Topology

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Sì, utilizzando la crittografia RPC

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

Accesso legacy al servizio Supervisore sistema di Microsoft Exchange (come client MAPI)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Sì, utilizzando la crittografia RPC

Accesso della Rubrica offline ad Active Directory

135/TCP (RPC)

Kerberos

Kerberos

Sì, utilizzando la crittografia RPC

Accesso RPC al Servizio aggiornamento destinatari

135/TCP (RPC)

Kerberos

Kerberos

Sì, utilizzando la crittografia RPC

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

  • 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.

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

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

Servizio Disponibilità

80/TCP, 443/TCP (SSL)

NTLM/Kerberos

NTLM, Kerberos

Sì, utilizzando HTTPS

Servizio di replica delle cassette postali (MRS) Microsoft

808/TCP

Kerberos/NTLM

Kerberos, NTLM

Sì, utilizzando la crittografia RPC

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

IMAP4

143/TCP (TLS), 993/TCP (SSL)

Di base, Kerberos

Di base, Kerberos

Sì, utilizzando SSL, TLS

Outlook via Internet (in precedenza noto come RPC su HTTP)

80/TCP, 443/TCP (SSL)

Di base

Di base o NTLM

Sì, utilizzando HTTPS

Applicazione Exchange ActiveSync

80/TCP, 443/TCP (SSL)

Di base

Di base, certificato

Sì, utilizzando HTTPS

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

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

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

Da server Accesso client a server Accesso client (Servizi Web Exchange)

443/TCP (HTTPS)

Kerberos

Kerberos

Sì, utilizzando SSL

Da server Accesso client a server Accesso client (POP3)

995 (SSL)

Di base

Di base

Sì, utilizzando SSL

Da server Accesso client a server Accesso client (IMAP4)

993 (SSL)

Di base

Di base

Sì, utilizzando SSL

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

NotaNota:
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.

  • 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 Microsoft Exchange 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.

    NotaNota:
    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

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.

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

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

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

Da server di messaggistica unificata a server Accesso client (Ascolta al telefono)

RPC dinamico

NTLM/Kerberos

NTLM/Kerberos

Sì, utilizzando la crittografia RPC

Da server di messaggistica unificata a server Trasporto Hub

25/TCP (TLS)

Kerberos

Kerberos

Sì, utilizzando TLS

Da server di messaggistica unificata a server di cassette postali

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Sì, utilizzando la crittografia RPC

  • 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.

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

  • 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 (le informazioni potrebbero essere in lingua inglese). 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.

NotaNota:
Non è possibile modificare le regole di Windows Firewall create dal programma di installazione di Exchange 2010 2010. È possibile creare regole personalizzate basate sulle regole predefinite, oppure disabilitarle o eliminarle.

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.
Il documento è risultato utile?
(1500 caratteri rimanenti)
Grazie per i commenti inviati.
Microsoft sta conducendo un sondaggio in linea per comprendere l'opinione degli utenti in merito al sito Web di MSDN. Se si sceglie di partecipare, quando si lascia il sito Web di MSDN verrà visualizzato il sondaggio in linea.

Si desidera partecipare?
Mostra:
© 2014 Microsoft