In questo articolo impareremo come configurare le porte RPC statiche per i servizi Accesso client RPC, Rubrica di Exchange e Accesso alle cartelle pubbliche in Exchange 2010.
Immaginiamo di avere un'organizzazione complessa che esegue Exchange Server 2010 SP1 (o versioni successive) che dispone anche di . I server CAS si trovano in genere su una rete separata da firewall dalle reti da cui gli utenti dovrebbero accedere (reti di Outlook). La connessione del client Outlook al server CAS avviene tramite RPC, il che significa che è attiva livello di reteè possibile utilizzare qualsiasi porta nell'intervallo di porte libere. Non è un segreto che dentro Server Windows 2008 e 2008 R2 utilizzano 49152-65535 come intervallo di porte dinamico per le connessioni RPC (precedente Versioni Windows Il server utilizzava porte RPC nell'intervallo 1025-65535).
Per evitare che i firewall diventino un "setaccio", è opportuno restringere l'intervallo di porte RPC utilizzate, idealmente rendendole statiche su ciascun server Accesso client nell'array Accesso client. Inoltre, l'utilizzo di porte RPC statiche consente di ridurre il consumo di memoria sui bilanciamenti del carico (in particolare HLB) e di semplificarne la configurazione (non è necessario specificare intervalli di porte di grandi dimensioni).
In Exchange 2010, il servizio Accesso client RPC e il servizio Rubrica di Exchange possono essere impostati su porte statiche. Outlook comunica con questi servizi tramite l'interfaccia MAPI.
Porta statica per il servizio Accesso client RPC di Exchange 2010
Il servizio virtuale Accesso client RPC di Exchange 2010 è associato al servizio Accesso client RPC a cui si connettono i client MAPI di Outlook in Exchange 2010. Quando un client Outlook si connette a Exchange, su un server Accesso client Exchange 2010, il servizio Accesso client RPC utilizza la porta TCP Endpoint Mapper (TCP/135) e una porta casuale dall'intervallo di porte dinamiche RPC (6005-59530) per le chiamate in entrata connessioni
Per impostare una porta statica per il servizio Accesso client RPC in Exchange 2010, è necessario aprire la sezione nell'editor del registro:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC
Crea una nuova chiave denominata ParametriSistema, all'interno del quale creare un parametro di tipo REG_DWORD Con nome Porta TCP/IP. L'impostazione Porta TCP/IP specifica una porta statica per il servizio Accesso client RPC. La documentazione Microsoft consiglia di scegliere una porta nell'intervallo 59531 - 60554 e di utilizzare questo valore su tutti i server CAS (abbiamo specificato la porta 59532, ovviamente, non dovrebbe essere utilizzata da nessun altro software).
Dopo l'assegnazione delle porte statiche, è necessario riavviare il servizio Accesso client RPC di Microsoft Exchange affinché le modifiche abbiano effetto.
Servizio di riavvio MSExchangeRPC
Porta statica per il servizio Rubrica di Exchange 2010
Prima di SP1, Exchange 2010 utilizzava un file di configurazione speciale per impostare la porta statica del servizio Rubrica di Exchange 2010 Microsoft.exchange.rubrica.servizio.exe.config. Dopo il rilascio di Exchange 2010 SP1, è possibile impostare la porta statica di questo servizio tramite il registro. Per fare ciò, apri l'editor del registro e vai al ramo:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeAB\Parameters
Crea un nuovo parametro RpcTcpPort(di tipo REG_SZ) e assegnargli il numero di porta che si desidera correggere per il servizio Rubrica di Exchange. Si consiglia di utilizzare qualsiasi porta libera nell'intervallo 59531-60554 e quindi utilizzarla su tutti i server Accesso client di Exchange 2010 nel dominio. Imposteremo RpcTcpPort=59533
Successivamente, è necessario riavviare il servizio Rubrica di Microsoft Exchange
Servizio di riavvio MSExchangeAB
Importante: Quando si esegue la migrazione da Exchange 2010 RTM a SP1, questa chiave deve essere impostata manualmente, non viene ereditata automaticamente.
Impostazione di una porta statica per la connessione alle cartelle condivise
È possibile accedere alle cartelle pubbliche da un client Outlook direttamente tramite il servizio Accesso client RPC su un server con ruolo Cassetta postale. Questa impostazione deve essere eseguito su tutti i server con ruolo Mailbox che contengono il database cartelle condivise(simile ai server CAS). Apri l'editor del registro e vai al ramo
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC
Crea una nuova chiave denominata ParametriSistema, all'interno del quale creare un parametro di tipo REG_DWORD denominato Porta TCP/IP. Impostare il suo valore: Porta TCP/IP = 59532.
Dopo aver impostato la porta della cartella pubblica in modo statico, è necessario riavviare il servizio Accesso client RPC di Microsoft Exchange su ciascun server di cassette postali.
Verificare l'utilizzo della porta statica tra Outlook ed Exchange 2010
Dopo aver apportato le modifiche, verificare che Outlook si connetta alle porte RPC statiche specificate. Per fare ciò, sul computer client, riavvia Outlook, quindi in riga di comando eseguire il comando:
Netstat -na
Applicabile a: Exchange Server 2010 SP1
Sezione ultima modifica: 2011-04-22
Questa sezione fornisce informazioni su porte, autenticazione e crittografia per tutti i percorsi dati utilizzati in Microsoft Exchange Server 2010. La sezione "Note" dopo ogni tabella chiarisce o definisce i metodi di autenticazione o crittografia non standard.
Server di trasporto
In Exchange 2010, esistono due ruoli del server che eseguono le funzioni di trasporto dei messaggi: un server Trasporto Hub e un server Trasporto Edge.
La tabella seguente fornisce informazioni su porte, autenticazione e crittografia del percorso dati tra questi server di trasporto e altri server e servizi di Exchange 2010.
Percorsi dati per i server di trasporto
| Percorso dati | Porte richieste | Supporto per la crittografia | |||
|---|---|---|---|---|---|
|
Tra due server Trasporto Hub |
Sì, con TLS (Transport Layer Security) |
||||
|
Da un server Trasporto Hub a un server Trasporto Edge |
fiducia diretta |
fiducia diretta |
Sì, utilizzando TLS |
||
|
Da un server Trasporto Edge a un server Trasporto Hub |
fiducia diretta |
fiducia diretta |
Sì, utilizzando TLS |
||
|
Tra due server Trasporto Edge |
Anonimo, autenticazione del certificato |
Anonimo, con certificato |
Sì, utilizzando TLS |
||
|
Dal server cassette postali tramite il servizio di spedizione Posta Microsoft Scambio |
NTLM. Se il ruolo del server Trasporto Hub e il ruolo del server Cassette postali sono in esecuzione sullo stesso server, viene utilizzato il protocollo Kerberos. |
Sì, utilizzando la crittografia RPC |
|||
|
Da un server Trasporto Hub a un server Cassette postali tramite MAPI |
NTLM. Se il ruolo del server Trasporto Hub e il ruolo del server Cassette postali sono installati sullo stesso server, viene utilizzato il protocollo Kerberos. |
Sì, utilizzando la crittografia RPC |
|||
|
Sì, utilizzando TLS |
|||||
|
Servizio Microsoft Exchange EdgeSync da un server Trasporto Hub a un server Trasporto Edge |
Sì, utilizzando LDAP su SSL (LDAPS) |
||||
|
Accedi ad Active Directory da un server Hub Transport |
|||||
|
Accesso ad Active Directory Rights Management Service (AD RMS) da un server Trasporto Hub |
Sì, con SSL |
||||
|
Client SMTP a un server Trasporto Hub (ad esempio, utenti finali che utilizzano Windows Live Mail) |
Sì, utilizzando TLS |
Note per i server di trasporto
- Tutto il traffico tra i server Trasporto Hub viene crittografato utilizzando Transport Layer Security (TLS) e i certificati autofirmati installati dal programma di installazione di Exchange 2010.
- Tutto il traffico tra i server Trasporto Edge e Trasporto Hub viene autenticato e crittografato. Mutual TLS viene utilizzato come meccanismo di autenticazione e crittografia. Invece della convalida X.509, Exchange 2010 utilizza fiducia diretta. Attendibilità diretta significa che la presenza di un certificato in Active Directory Services o Active Directory Lightweight Directory Services (AD LDS) verifica l'autenticità del certificato. Il servizio directory di Active Directory è considerato un meccanismo di archiviazione attendibile. Quando si utilizza l'attendibilità diretta, non importa se viene utilizzato un certificato autofirmato o un certificato firmato da una CA. Quando si sottoscrive un server Trasporto Edge a un'organizzazione di Exchange, la sottoscrizione Edge pubblica il certificato del server Trasporto Edge nel servizio directory di Active Directory in modo che i server Trasporto Hub possano verificarlo. Il servizio Microsoft Exchange EdgeSync aggiunge un set di certificati del server Trasporto Hub ad Active Directory Lightweight Directory Services (AD LDS) in modo che il server Trasporto Edge possa convalidarli.
- EdgeSync utilizza una connessione LDAP protetta da un server Trasporto Hub ai server Trasporto Edge sottoscritti sulla porta TCP 50636. Active Directory Lightweight Directory Services è in ascolto anche sulla porta TCP 50389. Le connessioni a questa porta non utilizzano SSL. È possibile utilizzare le utilità LDAP per connettersi a questa porta e controllare i dati di AD LDS.
- Per impostazione predefinita, il traffico tra i server Trasporto Edge che si trovano in due organizzazioni diverse è crittografato. Il programma di installazione di Exchange 2010 crea un certificato autofirmato e abilita TLS per impostazione predefinita. Ciò consente a qualsiasi sistema di invio di crittografare una sessione SMTP in entrata su Exchange. Per impostazione predefinita, Exchange 2010 tenta inoltre di utilizzare TLS per tutte le connessioni remote.
- I metodi di autenticazione per il traffico tra i server Trasporto Hub ei server Cassette postali sono diversi quando i ruoli del server Trasporto Hub e Cassette postali sono installati sullo stesso computer. Il trasferimento di posta locale utilizza l'autenticazione Kerberos. Il trasferimento di posta remoto utilizza l'autenticazione NTLM.
- Exchange 2010 supporta anche la protezione del dominio. Domain Security è un set di funzionalità di Exchange 2010 e Microsoft Outlook 2010 che fornisce un'alternativa a basso costo a S/MIME e ad altre soluzioni di protezione della messaggistica Internet. La sicurezza del dominio fornisce un modo per gestire percorsi di comunicazione sicuri tra i domini su Internet. Una volta configurati questi percorsi protetti, i messaggi inviati correttamente tramite essi da un mittente autenticato vengono visualizzati dagli utenti di Outlook e Outlook Web Access come messaggi "protetti a livello di dominio". Per ulteriori informazioni, vedere Panoramica sulla sicurezza del dominio.
- Molti agenti possono essere eseguiti sia sui server Trasporto Hub che sui server Trasporto Edge. Tipicamente, agenti di protezione posta indesiderata utilizzare le informazioni computer locale su cui vengono eseguiti. Quindi, l'interazione con computer remoti. L'eccezione è il filtro destinatario. Il filtro destinatario richiede una chiamata AD LDS o Active Directory. Si consiglia di eseguire il filtro dei destinatari su un server Trasporto Edge. In questo caso, la directory di AD LDS si trova nello stesso computer in cui è installato il ruolo del server Trasporto Edge, quindi non è necessaria alcuna connessione remota. Se il filtro destinatario è installato e configurato su un server Trasporto Hub, è necessario l'accesso al servizio directory di Active Directory.
- L'agente di analisi del protocollo viene utilizzato dalla funzionalità Reputazione mittente in Exchange 2010. Questo agente si connette anche a vari server proxy esterni per determinare i percorsi dei messaggi in entrata per le connessioni sospette.
- Tutte le altre funzionalità anti-spam utilizzano dati raccolti, archiviati e disponibili solo sul computer locale. In genere, dati come l'elenco combinato di mittenti attendibili oi dati del destinatario per il filtro destinatario vengono inviati alla directory di AD LDS locale utilizzando il servizio Microsoft Exchange EdgeSync.
- Gli agenti Information Rights Management (IRM) sui server Hub Transport si connettono ai server Active Directory Rights Management Services (AD RMS) nell'organizzazione. Active Directory Rights Management Service (AD RMS) è un servizio Web che consigliamo di proteggere con SSL. Le connessioni ai server AD RMS vengono effettuate tramite HTTPS e vengono autenticate tramite Kerberos o NTLM, a seconda della configurazione del server AD RMS.
- Le regole di registro, le regole di trasporto e le regole di classificazione dei messaggi vengono archiviate in Active Directory e sono accessibili dall'agente di registrazione e dall'agente delle regole di trasporto sui server Trasporto Hub.
Server di cassette postali
Sui server Cassette postali, l'utilizzo dell'autenticazione NTLM o Kerberos dipende dal contesto utente o dal processo in cui è in esecuzione l'utente del livello di logica aziendale di Exchange. In questo contesto, i consumatori sono tutte le applicazioni oi processi che utilizzano il livello della logica aziendale di Exchange. Di conseguenza, nella colonna Autenticazione predefinita tabelle Percorsi dati per i server Cassette postali molte righe hanno un valore NTLM/Kerberos.
Il livello della logica aziendale di Exchange viene utilizzato per accedere e interagire con l'archivio di Exchange. Il livello della logica aziendale di Exchange viene richiamato anche dall'archivio di Exchange per interagire con applicazioni e processi esterni.
Quando un consumer del livello di logica aziendale di Exchange viene eseguito nel contesto del sistema locale, il metodo di autenticazione del consumer per l'accesso all'archivio di Exchange è sempre Kerberos. Viene utilizzato il metodo di autenticazione Kerberos perché il destinatario deve essere autenticato utilizzando account computer "Sistema locale" e richiede un trust bidirezionale con autenticazione.
Se il destinatario del livello di logica aziendale di Exchange non è in esecuzione nel contesto del sistema locale, il metodo di autenticazione è NTLM. Ad esempio, quando un amministratore esegue un cmdlet di Exchange Management Shell che utilizza il livello di logica aziendale di Exchange, viene utilizzata l'autenticazione NTLM.
Il traffico RPC è sempre crittografato.
La tabella seguente fornisce informazioni su porte, autenticazione e crittografia del percorso dati per i server Cassette postali.
Percorsi dati per i server Cassette postali
Percorso dati Porte richieste Autenticazione predefinita Metodo di autenticazione supportato Supporto per la crittografia Crittografia dei dati per impostazione predefinita 389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (Accesso rete RPC)
Sì, utilizzando la crittografia Kerberos
Accesso amministrativo remoto (registro remoto)
Sì, utilizzando IPsec
Accesso amministrativo remoto (SMB, file)
Sì, utilizzando IPsec
Servizio Web di disponibilità (accesso alla casella di posta del client)
Sì, utilizzando la crittografia RPC
Raggruppamento
Sì, utilizzando la crittografia RPC
Tra i server Accesso client (Exchange ActiveSync)
80/TCP, 443/TCP (SSL)
Kerberos, autenticazione del certificato
Sì, utilizzando HTTPS
Sì, utilizzando un certificato autofirmato
Tra server Accesso client (Outlook Web Access)
80/TCP, 443/TCP (HTTPS)
Sì, con SSL
Dal server Accesso client al server Accesso client (servizi Web Exchange)
Sì, con SSL
Dal server Accesso client al server Accesso client (POP3)
Sì, con SSL
Dal server Accesso client al server Accesso client (IMAP4)
Sì, con SSL
Da Office Communications Server al server Accesso client (quando è abilitata l'integrazione di Office Communications Server e Outlook Web App)
5075-5077/TCP (IN), 5061/TCP (OUT)
mTLS (richiesto)
mTLS (richiesto)
Sì, con SSL
Note per i server Accesso client
Server sistema unificato messaggistica
I gateway IP e i PBX IP supportano solo l'autenticazione del certificato, che utilizza l'autenticazione Mutual TLS per crittografare il traffico SIP e l'autenticazione basata sull'indirizzo IP per le connessioni SIP o TCP. I gateway IP non supportano l'autenticazione NTLM e Kerberos. Pertanto, quando si utilizza l'autenticazione basata sull'indirizzo IP, il meccanismo di autenticazione per le connessioni non crittografate (TCP) utilizza gli indirizzi IP delle connessioni. Se utilizzata nella messaggistica unificata, l'autenticazione basata su IP controlla se l'indirizzo IP specificato è autorizzato a connettersi. L'indirizzo IP è configurato sul gateway IP o IP PBX.
I gateway IP e i PBX IP supportano Mutual TLS per crittografare il traffico SIP. Dopo aver importato ed esportato correttamente i certificati attendibili necessari, il gateway IP o IP PBX richiederà un certificato dal server Messaggistica unificata e quindi 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 consente a entrambi i dispositivi di comunicare in modo sicuro utilizzando Mutual TLS.
La seguente tabella fornisce informazioni su porta, autenticazione e crittografia per i percorsi dati tra i server Messaggistica unificata e altri server.
Percorsi dati per i server di messaggistica unificata
Percorso dati Porte richieste Autenticazione predefinita Metodo di autenticazione supportato Supporto per la crittografia Crittografia dei dati per impostazione predefinita Accesso ad Active Directory
389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (Accesso rete RPC)
Sì, utilizzando la crittografia Kerberos
Dial-in di messaggistica unificata (IP PBX/gateway VoIP)
5060/TCP, 5065/TCP, 5067/TCP (in modalità non protetta), 5061/TCP, 5066/TCP, 5068/TCP (in modalità protetta), intervallo di porte dinamico 16000-17000/TCP (gestione), UDP dinamico porte della gamma 1024-65535/UDP (RTP)
Per indirizzo IP
Per indirizzo IP, MTLS
Sì, utilizzando SIP/TLS, SRTP
Servizio Web di messaggistica unificata
80/TCP, 443/TCP (SSL)
Autenticazione integrata di Windows (negoziazione)
Sì, con SSL
Da un server Messaggistica unificata a un server Accesso client
5075, 5076, 5077 (TCP)
Autenticazione integrata di Windows (negoziazione)
Di base, Digest, NTLM, Negozia (Kerberos)
Sì, con SSL
Dal server UM al server Accesso client (riproduzione sul telefono)
RPC dinamico
Sì, utilizzando la crittografia RPC
Da un server Messaggistica unificata a un server Trasporto Hub
Sì, utilizzando TLS
Da un server Messaggistica unificata a un server Cassette postali
Sì, utilizzando la crittografia RPC
Note per i server di messaggistica unificata
- Quando si crea un oggetto gateway IP di messaggistica unificata in Active Directory, è necessario definire l'indirizzo IP del gateway IP fisico o IP PBX. Quando si determina l'indirizzo IP dell'oggetto gateway IP di messaggistica unificata, l'indirizzo IP viene aggiunto all'elenco di gateway IP o PBX IP validi (noti anche come partecipanti alla sessione SIP) con cui il server Messaggistica unificata è autorizzato a comunicare. Dopo aver creato un gateway IP di messaggistica unificata, è possibile associarlo a un dial plan di messaggistica unificata. La mappatura di un gateway IP di messaggistica unificata a un dial plan consente ai server di messaggistica unificata mappati a un dial plan di utilizzare l'autenticazione basata sull'indirizzo 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 avrà esito negativo ei server di messaggistica unificata non accetteranno connessioni dall'indirizzo IP di tale gateway IP. Inoltre, se si implementa Mutual TLS, un gateway IP o IP PBX e server di messaggistica unificata, il gateway IP di messaggistica unificata deve essere configurato per l'utilizzo di un nome di dominio completo (FQDN). Dopo aver configurato un gateway IP di messaggistica unificata utilizzando il nome di dominio completo, è necessario aggiungere anche un record host per il gateway alla zona di ricerca DNS diretta.
- In Exchange 2010, il server Messaggistica unificata può comunicare sulla porta 5060/TCP (non protetta) o sulla porta 5061/TCP (protetta) e può essere configurato per utilizzare entrambe le porte.
Per ulteriori informazioni, vedere Informazioni sulla sicurezza VoIP di messaggistica unificata e Informazioni su protocolli, porte e servizi nella messaggistica unificata.
Regole Firewall di Windows creato dal programma di installazione di Exchange 2010
Windows Firewall con sicurezza avanzata è un firewall stateful basato su computer 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 in ciascun ruolo del server. Pertanto, non è più necessario utilizzare SCW per configurare queste impostazioni. Per ulteriori informazioni su Windows Firewall con sicurezza avanzata, vedere Windows Firewall con sicurezza avanzata e IPsec.
La tabella seguente elenca le regole di Windows Firewall, generato dal programma Installazioni di Exchange, incluse le porte aperte su ogni ruolo del server. È possibile visualizzare queste regole utilizzando lo snap-in MMC Windows Firewall con sicurezza avanzata.
Nome regola Ruoli del server Porta Programma MSExchangeADTopology - RPC (TCP in entrata)
RPC dinamico
Bin\MSExchangeADTopologyService.exe
MSExchangeMonitoring - RPC (TCP in entrata)
Server Accesso client, server Trasporto Hub, server Trasporto Edge, server Messaggistica unificata
RPC dinamico
Bin\Microsoft.Exchange.Management.Monitoring.exe
MSExchangeServiceHost - RPC (TCP in entrata)
RPC dinamico
Bin\Microsoft.Exchange.ServiceHost.exe
MSExchangeServiceHost - RPCEPMap (TCP in ingresso)
Bin\Microsoft.Exchange.Service.Host
MSExchangeRPCEPMap (GFW) (TCP in entrata)
MSExchangeRPC (GFW) (TCP in entrata)
Server Accesso client, server Trasporto Hub, server Cassette postali, server Messaggistica unificata
RPC dinamico
MSExchange - IMAP4 (GFW) (TCP in entrata)
Server di accesso client
MSExchangeIMAP4 (TCP in entrata)
Server di accesso client
ClientAccess\PopImap\Microsoft.Exchange.Imap4Service.exe
MSExchange - POP3 (FGW) (TCP in entrata)
Server di accesso client
MSExchange - POP3 (TCP in entrata)
Server di accesso client
ClientAccess\PopImap\Microsoft.Exchange.Pop3Service.exe
MSExchange - OWA (GFW) (TCP in entrata)
Server di accesso client
5075, 5076, 5077 (TCP)
MSExchangeOWAAppPool (ingresso TCP)
Server di accesso client
5075, 5076, 5077 (TCP)
inetsrv\w3wp.exe
MSExchangeAB RPC (TCP in entrata)
Server di accesso client
RPC dinamico
MSExchangeAB-RPCEPMap (ingresso TCP)
Server di accesso client
Bin\Microsoft.Exchange.AddressBook.Service.exe
MSExchangeAB-RpcHttp (ingresso TCP)
Server di accesso client
6002, 6004 (TCP)
Bin\Microsoft.Exchange.AddressBook.Service.exe
RpcHttpLBS (TCP in entrata)
Server di accesso client
RPC dinamico
System32\Svchost.exe
MSExchangeRPC - RPC (TCP in entrata)
RPC dinamico
MSExchangeRPC - PRCEPMap (TCP in entrata)
Server di accesso client, server di cassette postali
Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeRPC (TCP in entrata)
Server di accesso client, server di cassette postali
Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeMailboxReplication (GFW) (TCP in entrata)
Server di accesso client
MSExchangeMailboxReplication (TCP in entrata)
Server di accesso client
Bin\MSExchangeMailboxReplication.exe
MSExchangeIS - RPC (TCP in entrata)
Server di posta
RPC dinamico
MSExchangeIS RPCEPMap (TCP in entrata)
Server di posta
MSExchangeIS (GFW) (TCP in entrata)
Server di posta
6001, 6002, 6003, 6004 (TCP)
MSExchangeIS (TCP in entrata)
Server di posta
Assistenti MSExchangeMailbox - RPC (TCP in entrata)
Server di posta
RPC dinamico
Assistenti MSExchangeMailbox - RPCEPMap (TCP in entrata)
Server di posta
Bin\MSExchangeMailboxAssistants.exe
MSExchangeMailSubmission - RPC (TCP in entrata)
Server di posta
RPC dinamico
MSExchangeMailSubmission - RPCEPMap (TCP in entrata)
Server di posta
Bin\MSExchangeMailSubmission.exe
MSExchangeMigration - RPC (TCP in entrata)
Server di posta
RPC dinamico
Bin\MSExchangeMigration.exe
MSExchangeMigration - RPCEPMap (TCP in entrata)
Server di posta
Bin\MSExchangeMigration.exe
MSExchangerepl - copia log (TCP in entrata)
Server di posta
Bin\MSExchangeRepl.exe
MSExchangerepl - RPC (TCP in entrata)
Server di posta
RPC dinamico
Bin\MSExchangeRepl.exe
MSExchangerepl - RPC-EPMap (ingresso TCP)
Server di posta
Bin\MSExchangeRepl.exe
MSExchangeSearch - RPC (TCP in entrata)
Server di posta
RPC dinamico
Bin\Microsoft.Exchange.Search.ExSearch.exe
MSExchangeThrottling - RPC (TCP in entrata)
Server di posta
RPC dinamico
Bin\MSExchangeThrottling.exe
MSExchangeThrottling - RPCEPMap (TCP in entrata)
Server di posta
Bin\MSExchangeThrottling.exe
MSFTED - RPC (TCP in entrata)
Server di posta
RPC dinamico
MSFTED - RPCEPMap (ingresso TCP)
Server di posta
MSExchangeEdgeSync - RPC (TCP in entrata)
Server Trasporto Hub
RPC dinamico
MSExchangeEdgeSync RPCEPMap (TCP in entrata)
Server Trasporto Hub
Bin\Microsoft.Exchange.EdgeSyncSvc.exe
MSExchangeTransportWorker - RPC (TCP in entrata)
Server Trasporto Hub
RPC dinamico
Bin\edgetransport.exe
MSExchangeTransportWorker - RPCEPMap (TCP in entrata)
Server Trasporto Hub
Bin\edgetransport.exe
MSExchangeTransportWorker (GFW) (TCP in entrata)
Server Trasporto Hub
MSExchangeTransportWorker (TCP in entrata)
Server Trasporto Hub
Bin\edgetransport.exe
MSExchangeTransportLogSearch - RPC (TCP in entrata)
RPC dinamico
MSExchangeTransportLogSearch - RPCEPMap (TCP in entrata)
Server Trasporto Hub, server Trasporto Edge, server Cassette postali
Bin\MSExchangeTransportLogSearch.exe
SESWorker (GFW) (ingresso TCP)
Server di messaggistica unificata
SESWorker (TCP in entrata)
Server di messaggistica unificata
Messaggistica unificata\SESWorker.exe
UMService (GFW) (TCP in entrata)
Server di messaggistica unificata
UMService (TCP in entrata)
Server di messaggistica unificata
Bin\UMService.exe
UMWorkerProcess (GFW) (TCP in entrata)
Server di messaggistica unificata
5065, 5066, 5067, 5068
UMWorkerProcess (TCP in entrata)
Server di messaggistica unificata
5065, 5066, 5067, 5068
Bin\UMWorkerProcess.exe
UMWorkerProcess - RPC (TCP in entrata)
Server di messaggistica unificata
RPC dinamico
Bin\UMWorkerProcess.exe
Note sulle regole di Windows Firewall create dal programma di installazione di Exchange 2010
- Sui server con IIS installato, Windows apre le porte HTTP (porta 80, TCP) e HTTPS (porta 443, TCP). Il programma di installazione di Exchange 2010 non apre queste porte. Pertanto, queste porte non sono elencate nella tabella precedente.
- In Windows Server 2008 e Windows Server 2008 R2, Windows Firewall con sicurezza avanzata consente di specificare un processo o un servizio per il quale è aperta una porta. Questo è più sicuro perché la porta può essere utilizzata solo dal processo o dal servizio specificato nella regola. Il programma di installazione di Exchange crea regole firewall con il nome del processo specificato. In alcuni casi, per motivi di compatibilità, viene creata anche una regola aggiuntiva che non è limitata a questo processo. Puoi disabilitare o rimuovere le regole non limitate al processo e mantenere le corrispondenti regole limitate al processo se il tuo attuale ambiente di distribuzione le supporta. Le regole non limitate ai processi possono essere distinte dalla parola (GFW) in nome della regola.
- Molti servizi di Exchange utilizzano chiamate di procedura remota (RPC) per comunicare. I processi del server che utilizzano chiamate di procedura remota si connettono al mapping di endpoint RPC per ottenere endpoint dinamici e registrarli nel database del mapping di endpoint. I client RPC interagiscono con il mapping degli endpoint RPC per determinare gli endpoint utilizzati dal processo del server. Per impostazione predefinita, RPC Endpoint Mapper è in ascolto sulla porta 135 (TCP). Quando si configura Windows Firewall per un processo che utilizza chiamate di procedura remota, il programma di installazione di Exchange 2010 crea due regole firewall per tale processo. Una regola consente la comunicazione con il mapper di endpoint RPC e la seconda regola consente la comunicazione con un endpoint assegnato dinamicamente. Per ulteriori informazioni sulle chiamate di procedura remota, vedere l'articolo. Per ulteriori informazioni sulla creazione di regole di Windows Firewall per la chiamata di procedura remota dinamica, vedere l'articolo.
Per ulteriori informazioni, vedere l'articolo della Microsoft Knowledge Base 179442
www.microsoft.com
Articolo Servizio di trasporto front-end di Exchange 2013è il primo di una serie di articoli che illustrano il funzionamento dei servizi di trasporto di Exchange Server 2013. Questo articolo si concentrerà su Servizio di trasporto front-end sui server Accesso client.
Nella versione 2013 del server Exchange, ci sono stati cambiamenti abbastanza forti nell'architettura e ora ci sono solo due ruoli principali: il server delle cassette postali (Mailbox Server o MBX in breve) e il server di accesso client (Client Access Server - CAS). Distinto è il ruolo del server Trasporto Edge. Servizio Trasporto front-end di Exchange 2013 situato sui server CAS e funge da proxy.
Questo è il primo articolo di una serie su come funzionano i servizi della pipeline di trasporto di Exchange 2013, ma ecco l'elenco completo:
Oltre ad articoli sulla gestione della registrazione di questi servizi:
Non dimenticare la documentazione ufficiale.
Puoi trovare ulteriori informazioni sulla configurazione e l'amministrazione di Exchange 2013 sul mio blog nell'articolo sull'argomento principale -.
Si dà il caso che ora ci siano alcuni servizi di trasporto in Exchange 2013 che hanno nomi simili ma sono fondamentalmente diversi nello scopo e nel modo in cui funzionano. Ecco tutti questi servizi:
- Servizio di trasporto front-end sui server Accesso client (il nome visualizzato è Microsoft Exchange FrontEnd Transport, abbreviato in MSExchangeFrontEndTransport);
- Servizio di trasporto sui server Cassette postali (il nome visualizzato è Microsoft Exchange Transport, abbreviato in MSExchangeTransport);
- Servizio di trasporto delle cassette postali sui server delle cassette postali (In realtà include due servizi: Recapito del trasporto delle cassette postali di Microsoft Exchange e Invio del trasporto delle cassette postali di Microsoft Exchange, nomi abbreviati, rispettivamente MSExchangeDelivery e MSExchangeSubmission);
- Servizio di trasporto sui server Trasporto Edge (il nome visualizzato è Microsoft Exchange Transport, abbreviato in MSExchangeTransport).
Allo stesso tempo, solo il secondo e il quarto servizio svolgono funzionalità comparabili, il resto differisce sostanzialmente. Insieme, formano tutti la pipeline di trasporto, che è il cuore del server di posta.
trasportatore di trasporto
In generale, la pipeline di trasporto si presenta così:
Nel contesto di questo articolo, siamo interessati alla parte superiore dell'illustrazione, che mostra il Client Access Server:
C'è una sfumatura in questo schema. Il fatto è che, per impostazione predefinita, i server MBX possono inviare in modo indipendente la posta attraverso la porta 25 SMTP. Per garantire che un connettore di invio invii sempre la posta a Internet tramite i server Accesso client, è necessario impostare in modo esplicito il parametro del connettore di invio su FrontendProxy abilitato nel significato $vero(o nell'EAC selezionare la casella Proxy tramite il server Accesso client nelle proprietà del connettore di invio). È da questa configurazione che costruirò in futuro.
Di seguito cercherò di fare un po' di chiarezza sul principio di funzionamento. Server Exchange 2013 con il ruolo CAS.
Principio di funzionamento
Trasporto frontale(nella terminologia Microsoft - Servizio di trasporto front-end) non elabora il contenuto dei messaggi, non utilizza una coda di messaggi e non interagisce con il servizio di trasporto delle cassette postali. In altre parole, i server Exchange 2013 con solo il ruolo CAS non archiviano i dati in modo permanente (utilizzando un database) o temporaneamente (in una coda di elaborazione dei messaggi).
Tuttavia, il servizio di trasporto front-end ha i propri agenti di trasporto (vedere la figura - Agenti di protocollo). Gli agenti consentono di estendere la funzionalità di un server di posta Exchange aggiungendo codice personalizzato alla logica di elaborazione dei messaggi. Gli agenti vengono richiamati quando si verificano eventi SMTP. Questi eventi, a loro volta, vengono generati in una fase o nell'altra dell'elaborazione dei messaggi quando passano attraverso la pipeline di trasporto. Vale la pena notare che la maggior parte degli agenti presenti per impostazione predefinita sono nascosti o le loro impostazioni non possono essere controllate. La funzionalità degli agenti sui server CAS è piuttosto limitata ed è completamente presente solo per i ruoli MBX ed Edge.
Invia e ricevi connettori
Sul diagramma (vedi sopra) Servizio di trasporto front-end indichiamo il server di accesso client su ogni ingresso e collegamento in uscita porta corrispondente, risultando nella seguente rappresentazione:
Un connettore di ricezione separato è responsabile dell'ascolto delle connessioni su ciascuna porta indicata nel diagramma, di cui tre parti vengono create per impostazione predefinita quando viene installato il ruolo CAS:
Oltre ai connettori visibili e accessibili all'amministratore, esistono anche connettori di invio di sistema nascosti:
- Connettore di invio interno proxy in entrata (SMTP 25/2525 in )
- Connettore di invio proxy client (SMTP ricevuto sulla porta 587 in Servizio di trasporto sui server di cassette postali alla porta 465)
A proposito, il primo connettore nella versione russa di Exchange Server 2013 avrà il nome Connettore di invio interno per l'ingresso. conn. server proxy, e secondo - Connettore di invio proxy client. Questo è per ogni evenienza, in modo da non cadere in uno stato di torpore al primo incontro con questi connettori.
Di conseguenza, otteniamo la seguente tabella completa:
| Nome | Scopo | Porta | Direzione |
| Frontend predefinito |
Ricezione | 25 | Da server esterni |
| Frontend proxy in uscita |
Ricezione | 717 | Dai server MBX |
| Frontend cliente |
Ricezione | 587 | Da client esterni, connessione sicura |
| Connettore di invio proxy client | Invio | 465 | Ai server MBX |
| Connettore di invio interno proxy in entrata | Invio | 25/2525 | Ai server MBX. Solo connessioni accettate sulla porta 587 |
| Connettore di invio creato manualmente | Invio | 25 | A server esterni |
Trasferiamo i nomi dei connettori nel diagramma Servizio di trasporto front-end.
Exchange Server e firewallFirewall (firewall) per server di posta (Exchange Server), porte di server di posta, server di posta front-end e back-end, Server virtuali SMTP, POP3, IMAP4
Come ogni computer connesso a Internet, il computer che ospita il server di posta deve essere protetto con un firewall. Allo stesso tempo, le opzioni per l'installazione di un server di posta in termini di configurazione di rete possono essere molto diverse:
· L'opzione più semplice è installare un server di posta su un computer che funge anche da proxy/firewall, quindi aprire le porte necessarie sull'interfaccia rivolta verso Internet. In genere, questo schema viene utilizzato nelle piccole organizzazioni;
Un'altra opzione è installare il server di posta in rete locale e configurarlo per funzionare tramite un server proxy. Per fare ciò, puoi associare l'ip pubblico al server di posta e passarlo attraverso un proxy o utilizzare gli strumenti di mappatura delle porte sul server proxy. Molti server proxy dispongono di procedure guidate speciali o regole predefinite per l'organizzazione di tale soluzione (ad esempio, in ISA Server). Questa opzione è utilizzata nella maggior parte delle organizzazioni.
· Un'altra possibilità fondamentale è quella di creare una DMZ e collocare al suo interno Exchange Server front-end (tale possibilità è comparsa dalla versione 2000) o SMTP Relay basato su un altro Exchange Server o, ad esempio, sendmail su *nix. Solitamente utilizzato nelle reti di grandi organizzazioni.
In ogni caso, il server di posta deve garantire la comunicazione almeno sulla porta TCP 25 (SMTP) e sulla porta UDP 53 (DNS). Altre porte che potrebbero essere richieste da Exchange Server a seconda della configurazione di rete (tutte TCP):
80 HTTP - per accedere all'interfaccia Web (OWA)
· 88 Protocollo di autenticazione Kerberos - se viene utilizzata l'autenticazione Kerberos (raro);
· Connettore 102 MTA .X .400 su TCP /IP (se il connettore X .400 viene utilizzato per la comunicazione tra gruppi di routing);
· 110 Post Office Protocol 3 (POP 3) - per l'accesso client;
· 119 Network News Transfer Protocol (NNTP) - se vengono utilizzati i newsgroup;
135 Comunicazione client/server Amministrazione Exchange RPC - porta RPC standard per l'amministrazione remota di Exchange mezzi standard gestore di sistema;
· 143 Protocollo di accesso ai messaggi Internet (IMAP) - per l'accesso dei clienti;
· 389 LDAP - per accedere al servizio directory;
· 443 HTTP (Secure Sockets Layer (SSL)) (e inferiori) - gli stessi protocolli protetti da SSL.
563 NNTP (SSL)
636LDAP (SSL)
993 IMAP4 (SSL)
995 POP3 (SSL)
· 3268 e 3269 - richieste al server di catalogo globale (ricerca in Active Directory e controllo dell'appartenenza ai gruppi universali).
Non ha senso chiudere l'interfaccia di Exchange Server rivolta all'interno dell'organizzazione con un firewall: verrà utilizzata per interagire con controller di dominio, utilità di amministrazione, sistemi Prenota copia e così via. Per un'interfaccia esposta a Internet, si consiglia di lasciare le porte 53 (se Exchange risolverà autonomamente i nomi host e non inoltrerà le richieste a server locale DNS) e 25. Molto spesso i clienti hanno la necessità di accedere alle proprie caselle di posta dall'esterno (da casa, durante un viaggio di lavoro, ecc.). La soluzione migliore in questa situazione è configurare OWA (l'interfaccia Web per l'accesso a Exchange Server, che è installato per impostazione predefinita, disponibile su http://nome_server/exchange) per lavorare su SSL e consentire l'accesso solo sulla porta 443. Oltre a la risoluzione dei problemi con l'autenticazione sicura e la crittografia dei messaggi risolve automaticamente il problema con l'inoltro SMTP (ne parleremo più avanti) e la situazione in cui un utente scarica accidentalmente un file funzionante e-mail su cui inviare le cartelle del client computer di casa, e poi al lavoro non riesce a trovare questi messaggi (per non parlare del fatto che l'archiviazione della posta di lavoro a casa è una violazione della sicurezza).
Una nuova funzionalità introdotta in Exchange Server. dalla versione 2000, la possibilità di utilizzare più server virtuali SMTP e POP3 con diverse impostazioni di sicurezza. Ad esempio, il server SMTP che comunica con Internet può essere configurato per una maggiore sicurezza e rigide restrizioni di consegna, mentre il server SMTP utilizzato dagli utenti all'interno dell'organizzazione può essere configurato per le massime prestazioni e facilità d'uso.
È inoltre necessario menzionare una certa confusione nella terminologia: molto spesso i firewall per Exchange sono chiamati sistemi di filtraggio dei messaggi, che verranno discussi di seguito.
[Questo articolo è un documento preliminare ed è soggetto a modifiche nelle versioni future. Le sezioni vuote sono incluse come segnaposto. Se desideri scrivere una recensione, ci piacerebbe riceverla. Inviacelo via e-mail [e-mail protetta]]
Applicabile a: Exchange Server 2016
Informazioni sulle porte di rete utilizzate da Exchange 2016 per l'accesso client e il flusso di posta.
Questo argomento fornisce informazioni sulle porte di rete utilizzate da Microsoft Exchange Server 2016 per comunicare con client di posta elettronica, server di posta Internet e altri servizi che si trovano all'esterno dell'organizzazione di Exchange locale. Prima di iniziare, considera le seguenti regole di base.
Non supportiamo la limitazione o la modifica del traffico di rete tra server Exchange interni, tra server Exchange interni e server Lync o Skype for Business interni o tra server Exchange interni e controller di dominio Active Directory interni in nessuno dei tipi di topologia. Se si utilizzano firewall o dispositivi di rete che possono limitare o modificare questo traffico di rete, è necessario impostare regole per consentire comunicazioni libere e senza restrizioni tra questi server (regole che consentono il traffico di rete da e verso qualsiasi porta, comprese le porte RPC casuali e qualsiasi protocollo). , che non cambia un solo bit).
I server Trasporto Edge si trovano quasi sempre nella rete perimetrale, pertanto il traffico di rete tra il server Trasporto Edge e Internet e tra il server Trasporto Edge e l'organizzazione di Exchange interna dovrebbe essere limitato. Queste porte di rete sono descritte in questa sezione.
È necessario limitare il traffico di rete tra client e servizi esterni e l'organizzazione interna di Exchange. È inoltre possibile limitare il traffico tra client interni e server Exchange interni. Queste porte di rete sono descritte in questa sezione.
Contenuto
Porte di rete necessarie per client e servizi
Porte di rete necessarie per il flusso di posta (nessun server Trasporto Edge)
Porte di rete necessarie per il flusso di posta con i server Trasporto Edge
Porte di rete necessarie per le distribuzioni ibride
Porte di rete necessarie per la messaggistica unificata
Le porte di rete necessarie ai client di posta elettronica per accedere alle cassette postali e ad altri servizi nell'organizzazione di Exchange sono descritte in diagramma successivo e nella tavola.
Appunti.
La destinazione di questi client e servizi sono i servizi Accesso client sul server Cassette postali. In Exchange 2016, Servizi di accesso client (esterni) e servizi interni vengono installati insieme sullo stesso server Cassette postali. Consulta la sezione per maggiori informazioni.
Sebbene il diagramma mostri client e servizi da Internet, i concetti sono gli stessi per i client interni (ad esempio, i client in una foresta di account che accedono ai server di Exchange in una foresta di risorse). Analogamente, nella tabella non è presente alcuna colonna Origine perché l'origine può essere qualsiasi posizione esterna all'organizzazione di Exchange (ad esempio, Internet o una foresta di account).
I server Trasporto Edge non partecipano al traffico di rete associato a questi client e servizi.
| Scopo | Porti | Appunti |
|---|---|---|
Le connessioni Web crittografate vengono utilizzate dai seguenti client e servizi. Servizio di rilevamento automatico Scambia Activesync Servizi Web di Exchange (EWS) Distribuzione di rubriche offline Outlook via Internet (RPC su HTTP) MAPI Outlook su HTTP Prospettive sul web | 443/TCP (HTTPS) | Riferimento EWS per lo scambio |
Le connessioni Web non crittografate vengono utilizzate dai seguenti client e servizi. Pubblica il tuo calendario sul web Outlook sul Web (reindirizzamento alla porta 443/TCP) Autodiscovery (fallback quando la porta 443/TCP non è disponibile) | 80/TCP (HTTP) | Quando possibile, ti consigliamo di utilizzare connessioni Web crittografate sulla porta 443/TCP per proteggere le credenziali e altri dati. Tuttavia, alcuni servizi devono essere configurati per l'utilizzo di connessioni Web non crittografate sulla porta 80/TCP ai servizi Accesso client sui server Cassette postali. Per ulteriori informazioni su questi client e servizi, vedere i seguenti articoli. |
client IMAP4 | 143/TCP (IMAP), 993/TCP (IMAP sicuro) | IMAP4 è disabilitato per impostazione predefinita. Consulta la sezione per maggiori informazioni. Il servizio IMAP4 nei servizi Accesso client sul server Cassette postali inoltra le connessioni al servizio IMAP4 interno sul server Cassette postali. |
Clienti POP3 | 110/TCP (POP3), 995/TCP (POP3 sicuro) | Per impostazione predefinita, il protocollo POP3 è disabilitato. Consulta la sezione per maggiori informazioni. Il servizio POP3 nei servizi Accesso client sul server Cassette postali inoltra le connessioni al servizio POP3 interno sul server Cassette postali. |
Client SMTP (con autenticazione) | 587/TCP (SMTP autenticato) | Il connettore di ricezione predefinito è "Client Frontend Nota. Se disponi di client di posta elettronica che possono inviare solo messaggi SMTP autenticati sulla porta 25, puoi modificare il valore di binding di questo connettore di ricezione in modo che ascolti anche i messaggi SMTP autenticati sulla porta 25. |
All'inizio
Porte di rete necessarie per il flusso di posta
Posta in uscita
25/TCP (SMTP)
Server di posta
Internet (tutti)
Per impostazione predefinita, Exchange non crea connettori di invio che consentono di inviare posta a Internet. È necessario creare manualmente i connettori di invio. Consulta la sezione per maggiori informazioni.
Posta in uscita (se inviata tramite un servizio di trasporto esterno)
25/TCP (SMTP)
Server di posta
Internet (tutti)
La posta in uscita viene inviata tramite il servizio di trasporto esterno solo se l'impostazione del connettore di invio è abilitata Proxy tramite il server Accesso client in EAC o il parametro -FrontEndProxyEnabled $true in Exchange Management Shell.
In questo caso, il connettore di ricezione predefinito "Outbound Proxy Frontend
Server DNS per la risoluzione del nome dell'hop successivo della posta (non mostrato)
53/UDP, 53/TCP (DNS)
Server di posta
Server DNS
All'inizio
Un server Trasporto Edge sottoscritto installato nella rete perimetrale influisce sul flusso di posta nei seguenti modi:
La posta proveniente da un server Trasporto Edge Exchange 2016 o Exchange 2013 entra prima nel servizio di trasporto esterno e quindi viene instradata al servizio di trasporto sul server cassette postali di Exchange 2016.
La posta da un server Trasporto Edge di Exchange 2010 va sempre direttamente al servizio di trasporto su un server Cassette postali di Exchange 2016.
La posta in uscita dall'organizzazione di Exchange non passa mai attraverso il servizio di trasporto esterno sui server Cassette postali. Reindirizza sempre dal servizio di trasporto sul server Cassette postali del sito Active Directory sottoscritto al server Trasporto Edge (indipendentemente dalla versione di Exchange sul server Trasporto Edge).
La posta in arrivo viene reindirizzata dal server Trasporto Edge al server Cassette postali del sito Active Directory sottoscritto. Ciò significa quanto segue:
Le porte di rete necessarie per il flusso di posta nelle organizzazioni di Exchange con server Trasporto Edge sono descritte nel diagramma e nella tabella seguenti.
| Scopo | Porti | Fonte | Scopo | Appunti |
|---|---|---|---|---|
Posta in arrivo: da Internet a un server Trasporto Edge | 25/TCP (SMTP) | Internet (tutti) | Il connettore di ricezione predefinito denominato Connettore di ricezione interno predefinito <имя пограничного транспортного сервера> " sul server Trasporto Edge ascolta la posta SMTP anonima sulla porta 25. |
|
Posta in entrata: dal server Trasporto Edge all'organizzazione interna di Exchange | 25/TCP (SMTP) | Server Trasporto Edge | Il connettore di invio predefinito denominato "EdgeSync - Inbound to Connettore di ricezione predefinito "Front-end predefinito |
|
Posta in uscita: da un'organizzazione Exchange interna a un server Trasporto Edge | 25/TCP (SMTP) | Server di cassette postali in un sito di Active Directory sottoscritto | La posta in uscita ignora sempre il servizio di trasporto esterno sui server Cassette postali. La posta viene inoltrata dal servizio di trasporto su qualsiasi server Cassette postali in un sito Active Directory sottoscritto a un server Trasporto Edge utilizzando un connettore di invio intra-organizzativo implicito e invisibile che instrada automaticamente la posta tra i server Exchange nella stessa organizzazione. Connettore di ricezione interno predefinito |
|
Posta in uscita: dal server Trasporto Edge a Internet | 25/TCP (SMTP) | Server Trasporto Edge | Internet (tutti) | Il connettore di invio predefinito denominato "EdgeSync - with <имя сайта Active Directory> a Internet" inoltra la posta in uscita sulla porta 25 dal server Trasporto Edge a Internet. |
Sincronizzazione EdgeSync | 50636/TCP (LDAP sicuro) | Server di cassette postali nel sito di Active Directory sottoscritto che partecipano alla sincronizzazione EdgeSync | Server Trasporto Edge | Se un server Trasporto Edge è sottoscritto a un sito di Active Directory, tutti i server Cassette postali attualmente presenti nel sito partecipano alla sincronizzazione EdgeSync. Tuttavia, se in un secondo momento aggiungi più server Cassette postali, questi non parteciperanno automaticamente alla sincronizzazione di EdgeSync. |
Server DNS per la risoluzione del nome dell'hop successivo (non mostrato) | 53/UDP, 53/TCP (DNS) | Server Trasporto Edge | Server DNS | Vedere Risoluzione dei nomi. |
Reputazione mittente Rilevamento Open Proxy (non mostrato) | vedere le note | Server Trasporto Edge | Internet | Per impostazione predefinita, l'agente di analisi del protocollo utilizza l'individuazione del proxy aperto come una delle condizioni per il calcolo del livello di reputazione del server di messaggistica di origine. Vedere l'articolo per ulteriori informazioni. Le seguenti porte TCP vengono utilizzate per controllare i server di messaggistica di origine per un server proxy aperto: Inoltre, se l'organizzazione utilizza un server proxy per controllare il traffico Internet in uscita, è necessario determinare il nome del server proxy, il tipo e la porta TCP necessari per accedere a Internet e rilevare un server proxy aperto. Puoi anche disabilitare il rilevamento del proxy aperto. Consulta la sezione per maggiori informazioni. |
All'inizio
Risoluzione del nome
Risoluzione del nome
La risoluzione della posta dell'hop successivo DNS è una parte fondamentale del flusso di posta in qualsiasi organizzazione di Exchange. I server di Exchange responsabili della ricezione della posta in arrivo o della consegna della posta in uscita devono essere in grado di risolvere i nomi host interni ed esterni per instradare correttamente la posta. Tutti i server Exchange interni devono essere in grado di risolvere i nomi host interni per instradare correttamente la posta. Ci sono molti vari modi sviluppo dell'infrastruttura DNS, ma il risultato importante è garantire una corretta risoluzione dei nomi per l'hop successivo su tutti i server Exchange.