Riferimenti per la protezione dei percorsi dei dati
Si applica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Ultima modifica dell'argomento: 2009-06-05
In questo argomento vengono fornite informazioni sulle porte, sull'autenticazione e sulla crittografia di tutti i percorsi dei dati utilizzati da Microsoft Exchange Server 2007. Dopo ogni tabella, nelle sezioni relative alle note, vengono chiariti o definiti i metodi non standard per la crittografia o l'autenticazione.
Server di trasporto
Exchange 2007 include due ruoli del server che eseguono la funzionalità di trasporto dei messaggi: i server Trasporto Hub e 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 tra altri server e servizi di Exchange 2007.
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 (Transport Layer Security [TLS]) |
Kerberos |
Kerberos |
Sì (TLS) |
Sì |
Da server Trasporto Hub a server Trasporto Edge |
25/TCP (TLS) |
Trust diretto |
Trust diretto |
Sì (TLS) |
Sì |
Da server Trasporto Edge a server Trasporto Hub |
25/TCP (TLS) |
Trust diretto |
Trust diretto |
Sì (TLS) |
Sì |
Da server Trasporto Edge a server Trasporto Edge |
25/TCP (TLS), 389/TCP/UDP e 80/TCP (autenticazione certificato) |
Autenticazione anonima e autenticazione certificato |
Autenticazione anonima e autenticazione certificato |
Sì (TLS) |
Sì |
Da server Cassette postali a server Trasporto Hub tramite il Servizio Invio posta di Microsoft Exchange |
135/TCP (RPC) |
NTLM. Se i ruoli del server Trasporto Hub e Cassette postali si trovano nello stesso server, viene utilizzato Kerberos. |
NTLM/Kerberos |
Sì (crittografia RPC) |
Sì |
Da server Trasporto Hub a server Cassette postali tramite MAPI |
135/TCP (RPC) |
NTLM. Se i ruoli del server Trasporto Hub e Cassette postali si trovano nello stesso server, viene utilizzato Kerberos. |
NTLM/Kerberos |
Sì (crittografia RPC) |
Sì |
Da server Messaggistica unificata a server Trasporto Hub |
25/TCP (TLS) |
Kerberos |
Kerberos |
Sì (TLS) |
Sì |
Servizio EdgeSync di Microsoft Exchange |
50636/TCP (SSL) e 50389/TCP (SSL disattivato) |
Autenticazione di base |
Autenticazione di base |
Sì (LDAPS) |
Sì |
Servizio directory di Active Directory Application Mode (ADAM) sul server Trasporto Edge |
50389/TCP (SSL disattivato) |
NTLM/Kerberos |
NTLM/Kerberos |
No |
No |
Accesso al servizio directory di Active Directory dal server Trasporto Hub |
389/TCP/UDP (LDAP), 3268/TCP (catalogo globale LDAP), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS) e 135/TCP (Accesso rete RPC) |
Kerberos |
Kerberos |
Sì (crittografia Kerberos) |
Sì |
Da client SMTP dell'utente finale (ad esempio, Outlook Express) a Trasporto Hub |
25/TCP (TLS), 587 (TLS) |
NTLM/Kerberos |
NTLM/Kerberos |
Sì (TLS) |
Sì |
Note sui server di trasporto
Tutto il traffico tra i server Trasporto Hub viene crittografato tramite TLS con certificati autofirmati installati per impostazione predefinita dal programma di installazione di Exchange 2007. Il traffico tra server Trasporto Hub viene autenticato tramite Kerberos.
Tutto il traffico tra i server Trasporto Edge e Trasporto Hub viene autenticato e crittografato. Il meccanismo sottostante per l'autenticazione e la crittografia è Mutual TLS (MTLS). Anziché utilizzare la convalida X.509, in Exchange 2007 i certificati vengono autenticati tramite trust diretto. Il "trust diretto" implica che il certificato viene convalidato se è presente in Active Directory o ADAM. Active Directory è considerato un meccanismo di archiviazione attendibile. Inoltre, in questi casi è 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 ADAM con la serie di certificati del server Trasporto Hub affinché il server Trasporto Edge possa eseguire la convalida.
Per impostazione predefinita, il traffico tra i server Trasporto Edge di due organizzazioni diverse viene crittografato. Nel programma di installazione di Exchange 2007 viene creato un certificato autofirmato e TLS viene abilitato per impostazione predefinita. Ciò consente a qualsiasi sistema di invio di crittografare la sessione SMTP in ingresso in Microsoft Exchange. Per impostazione predefinita, Exchange 2007 tenta di applicare TLS a tutte le connessioni remote.
I metodi di autenticazione del traffico tra i server Trasporto Hub e i server Cassette postali è diverso quando i ruoli dei rispettivi server sono situati 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 2007 supporta anche la protezione del dominio. La protezione del dominio fa riferimento alla serie di funzionalità in Exchange 2007 e Microsoft Office Outlook 2007 che fornisce un'alternativa a basso costo rispetto a S/MIME o ad altre soluzioni di protezione a livello dei messaggi su Internet. Lo scopo della serie di funzionalità di protezione del dominio consiste nel fornire agli amministratori un modo per gestire percorsi di messaggi protetti tra i domini su Internet. Dopo aver configurato questi percorsi di messaggi protetti, i messaggi che hanno viaggiato con successo lungo il percorso protetto e provenienti da un mittente autenticato appaiono all'utente come "Dominio protetto" nell'interfaccia di Outlook e Outlook Web Access. Per ulteriori informazioni, vedere Pianificazione della protezione del dominio.
Sui server Trasporto Hub e Trasporto Edge è possibile eseguire diversi agenti. In genere, gli agenti protezione posta indesiderata si basano sulle informazioni locali presenti nel computer in cui vengono eseguiti. Pertanto, sono richieste poche comunicazioni con i computer remoti. L'unica eccezione è rappresentata dal filtro destinatario, per il quale sono necessarie chiamate ad ADAM o Active Directory. Si consiglia di eseguire il filtro destinatario sul server Trasporto Edge. In questo caso, la directory ADAM si trova sullo stesso computer del server Trasporto Edge e non è richiesta alcuna comunicazione remota. Una volta installato e configurato nel server Trasporto Hub, il filtro destinatario esegue l'accesso ad Active Directory.
L'agente di analisi protocollo viene utilizzato dalla funzionalità reputazione mittente di Exchange 2007. Per determinare i percorsi dei messaggi in ingresso provenienti da connessioni sospette, questo agente effettua inoltre diverse connessioni ai server proxy esterni.
Per tutte le altre funzionalità di protezione da posta indesiderata vengono utilizzati i dati raccolti, archiviati e disponibili solo sul computer locale. Tali dati, ad esempio quelli relativi all'aggregazione dell'elenco indirizzi attendibili o ai destinatari per il filtro destinatario, vengono inseriti nella directory ADAM locale utilizzando il servizio EdgeSync di Microsoft Exchange.
L'inserimento nel journal e la classificazione dei messaggi vengono eseguiti sui server Trasporto Hub e si basano sui dati di Active Directory.
Server Cassette postali
Nel contesto del ruolo del server Cassette postali, l'utilizzo dell'autenticazione NTLM o Kerberos è basato sul contesto dell'utente o del processo in cui viene eseguito il consumer del livello della regola business di Exchange. In questo contesto, il consumer è un'applicazione o un processo che utilizza il livello della regola business di Exchange. In diverse celle "Autenticazione predefinita" della tabella "Percorsi dei dati tra i server Cassette postali" riportata in questa sezione viene indicata l'autenticazione "NTLM/Kerberos".
Il livello della regola business di Exchange viene utilizzato per accedere e comunicare con l'archivio di Exchange. Inoltre, questo livello viene richiamato dall'archivio di Exchange per comunicare con applicazioni e processi esterni.
Se il consumer del livello della regola 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 regola business di Exchange non viene eseguito come sistema locale, verrà utilizzato il metodo di autenticazione NTLM. Ad esempio, quando un amministratore esegue un cmdlet di Exchange Management Shell che utilizza il livello della regola business di Exchange, viene utilizzata l'autenticazione NTLM.
Il traffico RPC viene sempre crittografato.
Nella seguente tabella 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 Cassette postali
Percorso dati | Porte richieste | Autenticazione predefinita | Autenticazione supportata | È supportata la crittografia? | I dati sono crittografati per impostazione predefinita? |
---|---|---|---|---|---|
Log shipping della replica continua cluster e della replica continua di standby |
445/TCP |
NTLM/Kerberos |
NTLM/Kerberos |
Sì (IPsec) |
No |
Seeding della replica continua cluster e della replica continua di standby |
Porta casuale |
NTLM/Kerberos |
NTLM/Kerberos |
Sì (IPsec) |
No |
Backup del servizio Copia Shadow del volume (VSS, Volume Shadow Copy Service) |
Blocco dei messaggi locali (SMB) |
NTLM/Kerberos |
NTLM/Kerberos |
No |
No |
Backup legacy |
Porta casuale |
NTLM/Kerberos |
NTLM/Kerberos |
Sì (IPsec) |
No |
Clustering |
135 /TCP (RPC). Vedere "Note sui server Cassette postali" dopo la tabella. |
NTLM/Kerberos |
NTLM/Kerberos |
Sì (IPsec) |
No |
Accesso MAPI |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Sì (crittografia RPC) |
Sì |
Assistenti cassette postali |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
No |
No |
Servizio Web Disponibilità (Accesso client a Cassette postali) |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Sì (crittografia RPC) |
Sì |
Accesso di Active Directory |
389/TCP/UDP (LDAP), 3268/TCP (catalogo globale LDAP), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS) e 135/TCP (Accesso rete RPC) |
Kerberos |
Kerberos |
Sì (crittografia Kerberos) |
Sì |
Indicizzazione del contenuto |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Sì (crittografia RPC) |
Sì |
Accesso amministrativo remoto (Registro di sistema remoto) |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Sì (IPsec) |
No |
Accesso amministrativo remoto (SMB/file) |
445/TCP (SMB) |
NTLM/Kerberos |
NTLM/Kerberos |
Sì (IPsec) |
No |
Accesso RPC del Servizio aggiornamento destinatari |
135/TCP (RPC) |
Kerberos |
Kerberos |
Sì (crittografia RPC) |
Sì |
Accesso del servizio Microsoft Exchange Active Directory Topology |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Sì (crittografia RPC) |
Sì |
Accesso legacy del servizio Supervisore sistema di Microsoft Exchange (ascolto delle richieste) |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
No |
No |
Accesso legacy del servizio Supervisore sistema di Microsoft Exchange ad Active Directory |
389/TCP/UDP (LDAP), 3268/TCP (catalogo globale LDAP), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS) e 135/TCP (Accesso rete RPC) |
Kerberos |
Kerberos |
Sì (crittografia Kerberos) |
Sì |
Accesso legacy del servizio Supervisore sistema di Microsoft Exchange (come client MAPI) |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Sì (crittografia RPC) |
Sì |
Accesso della Rubrica fuori rete ad Active Directory |
135/TCP (RPC) |
Kerberos |
Kerberos |
Sì (crittografia RPC) |
Sì |
Aggiornamento destinatari ad Active Directory |
389/TCP/UDP (LDAP), 3268/TCP (catalogo globale LDAP), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS) e 135/TCP (Accesso rete RPC) |
Kerberos |
Kerberos |
Sì (crittografia Kerberos) |
Sì |
DSAccess ad Active Directory |
389/TCP/UDP (LDAP), 3268/TCP (catalogo globale LDAP), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS) e 135/TCP (Accesso rete RPC) |
Kerberos |
Kerberos |
Sì (crittografia Kerberos) |
Sì |
Accesso di Outlook alla Rubrica fuori rete Nota Si applica a Outlook 2003 o versioni precedenti. Questa impostazione si applica anche ai client Office Outlook 2007 se la funzionalità di distribuzione Web per la Rubrica fuori rete non è attivata. |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Sì (crittografia RPC) |
Sì |
WebDAV |
80/TCP e 443/TCP (SSL) |
Autenticazione di base, NTLM e negoziazione |
Autenticazione di base, NTLM e negoziazione |
Sì (HTTPS) |
Sì |
Note sui server Cassette postali
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 nodi cluster viene utilizzata la porta UDP (User Datagram Protocol) 3343. A intervalli periodici ogni nodo cluster scambia diagrammi 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 di monitorare l'integrità dei collegamenti di rete.
Sebbene i client o le applicazioni WebDAV siano in grado di connettersi al server Cassette postali tramite la porta 80/TCP o 443/TCP, nella maggior parte dei casi la connessione viene eseguita al server Accesso client, che successivamente si connette al server Cassette postali tramite la porta 80/TCP o 443/TCP.
Il percorso dei dati del cluster indicato in questa sezione, nella tabella "Percorsi dei dati del server Cassette postali", utilizza l'RPC dinamico (TCP) per comunicare l'attività e lo stato del cluster tra i diversi nodi cluster. Per comunicare tra nodi cluster, il Servizio cluster (ClusSvc.exe) utilizza anche la porta UDP/3343 e le porte TCP con numero elevato assegnate in modo casuale.
Server Accesso client
Se non specificato diversamente, le tecnologie di accesso client, ad esempio Microsoft Office Outlook Web Access, POP3 o IMAP4, sono descritte dall'autenticazione e dalla crittografia dei dati tra l'applicazione client e il server Accesso client.
Nella seguente tabella vengono fornite informazioni sulla porta, 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? |
---|---|---|---|---|---|
Servizio di individuazione automatica |
80/TCP e 443/TCP (SSL) |
Autenticazione di base o integrata di Windows (negoziazione) |
Autenticazione di base, digest, NTLM e negoziazione (Kerberos) |
Sì (HTTPS) |
Sì |
Servizio Disponibilità |
80/TCP e 443/TCP (SSL) |
NTLM/Kerberos |
NTLM e Kerberos |
Sì (HTTPS) |
Sì |
Outlook Web Access |
80/TCP e 443/TCP (SSL) |
Autenticazione basata su moduli |
Autenticazione di base, digest, basata su moduli, NTLM (solo versione 2), Kerberos e certificato |
Sì (HTTPS) |
Sì, tramite certificato autofirmato |
POP3 |
110/TCP (TLS) e 995/TCP (SSL) |
Autenticazione di base, NTLM e Kerberos |
Autenticazione di base, NTLM e Kerberos |
Sì (SSL e TLS) |
Sì |
IMAP4 |
143/TCP (TLS) e 993/TCP (SSL) |
Autenticazione di base, NTLM e Kerberos |
Autenticazione di base, NTLM e Kerberos |
Sì (SSL e TLS) |
Sì |
Outlook via Internet (in precedenza noto come RPC su HTTP) |
80/TCP e 443/TCP (SSL) |
Autenticazione di base |
Autenticazione di base o NTLM |
Sì (HTTPS) |
Sì |
Applicazione Exchange ActiveSync |
80/TCP e 443/TCP (SSL) |
Autenticazione di base |
Autenticazione di base e autenticazione certificato |
Sì (HTTPS) |
Sì |
Da server Accesso client a server Messaggistica unificata |
5060/TCP, 5061/TCP, 5062/TCP e una porta dinamica |
Per indirizzo IP |
Per indirizzo IP |
Sì (Session Initiation Protocol [SIP] su TLS) |
Sì |
Da server Accesso client a server Cassette postali in cui viene eseguita una versione precedente di Exchange Server |
80/TCP e 443/TCP (SSL) |
NTLM/Kerberos |
Negoziazione (Kerberos con fallback su NTLM oppure autenticazione di base), testo normale POP/IMAP |
Sì (IPsec) |
No |
Da server Accesso client a server Cassette postali Exchange 2007 |
RPC. Vedere "Note sui server Accesso client" dopo la tabella. |
Kerberos |
NTLM/Kerberos |
Sì (crittografia RPC) |
Sì |
Da server Accesso client a server Accesso client (Exchange ActiveSync) |
80/TCP e 443/TCP (SSL) |
Kerberos |
Kerberos e certificato |
Sì (HTTPS) |
Sì, tramite certificato autofirmato |
Da server Accesso client a server Accesso client (Outlook Web Access) |
80/TCP e 443/TCP (SSL) |
Kerberos |
Kerberos |
Sì (HTTPS) |
Sì |
WebDAV |
80/TCP e 443/TCP (SSL) |
Autenticazione di base HTTP o autenticazione basata su moduli di Outlook Web Access |
Autenticazione di base e autenticazione basata su moduli di Outlook Web Access |
Sì (HTTPS) |
Sì |
Accesso di Outlook alla Rubrica fuori rete Nota Si applica a Office Outlook 2007 se la funzionalità di distribuzione Web per la Rubrica fuori rete è attivata. |
80/TCP e 443/TCP (SSL) |
NTLM/Kerberos |
NTLM/Kerberos |
Sì (HTTPS) |
No |
Note sui server Accesso client
La comunicazione tra il server Accesso client e il server Cassette postali viene effettuata utilizzando diverse porte. Salvo alcune eccezioni, tali porte sono definite dal servizio RPC (Remote Procedure Call) e non sono fisse. È possibile specificare l'intervallo di porte dinamiche utilizzate dal servizio. Per ulteriori informazioni sulla limitazione di tale intervallo, vedere l'articolo 154596 della Microsoft Knowledge Base, Configurazione dell'allocazione delle porte dinamiche RPC perché funzionino con i firewall.
Importante
Non sono supportate configurazioni in cui un firewall viene aggiunto tra i server Accesso client e i server Cassette postali che si trovano nello stesso sito di Active Directory.
Importante
Non sono supportate configurazioni in cui un server Accesso client viene installato in una rete perimetrale. È necessario che il server Accesso client sia membro di un dominio di Active Directory e che l'account di tale server sia membro del gruppo di protezione Exchange Servers di Active Directory. Il gruppo Exchange Servers di Active Directory dispone dell'accesso in lettura e scrittura a tutti i server Exchange dell'organizzazione in uso. La comunicazione tra il server Accesso client e i server Cassette postali all'interno dell'organizzazione avviene mediante il servizio RPC. A causa di questi requisiti l'installazione di un server Accesso client in una rete perimetrale non è supportata.
Per l'autenticazione HTTP in cui è indicata l'opzione di negoziazione, viene eseguito prima un tentativo con Kerberos, quindi con NTLM.
Per comunicazioni tra un server Accesso client di Exchange 2007 e un server Cassette postali in cui viene eseguito 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 Access per l'utilizzo dell'autenticazione basata su moduli con un certificato attendibile. Affinché i client Exchange ActiveSync possano comunicare tramite il server Accesso client di Exchange 2007 con il server di back-end di Exchange 2003, è necessario abilitare l'autenticazione integrata di Windows sulla directory virtuale Microsoft-Server-ActiveSync nel server di back-end di Exchange 2003. Per utilizzare il Gestore di sistema di Exchange su un server che esegue Exchange 2003 per la gestione dell'autenticazione su una directory virtuale Exchange 2003, è necessario scaricare e installare l'aggiornamento rapido a cui viene fatto riferimento nell'articolo 937301 della Microsoft Knowledge Base, Su un server Exchange 2007 che esegue il ruolo del server Accesso client viene registrato l'ID evento 1036 quando uno o più dispositivi mobili si connettono al server Exchange 2007 per accedere alle cassette postali di un server back-end Exchange 2003.
Server Messaggistica unificata
I gateway IP supportano solo l'autenticazione basata su certificato in cui viene utilizzata l'autenticazione IP e Mutual TLS per le connessioni Session Initiation Protocol (SIP)/TCP. In questi gateway non è supportata l'autenticazione NTLM o 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 viene utilizzata l'autenticazione basata su IP nella messaggistica unificata, il server Messaggistica unificata verifica che l'indirizzo IP sia autorizzato a effettuare la connessione. L'indirizzo IP viene configurato sul gateway IP o IP PBX.
Nella seguente tabella vengono fornite informazioni sulla porta, sull'autenticazione e sulla crittografia dei percorsi dei dati tra i server Messaggistica unificata e altri server.
Percorsi dei dati del server Messaggistica unificata
Percorso dati | Porte richieste | Autenticazione predefinita | Autenticazione supportata | È supportata la crittografia? | I dati sono crittografati per impostazione predefinita? |
---|---|---|---|---|---|
Fax di messaggistica unificata |
5060/TCP, 5061/TCP, 5062/TCP e una porta dinamica |
Per indirizzo IP |
Per indirizzo IP |
SIP su TLS, senza crittografia dei supporti |
Sì per SIP |
Interazione di Unified Messaging Phone (PBX) |
5060/TCP, 5061/TCP, 5062/TCP e una porta dinamica |
Per indirizzo IP |
Per indirizzo IP |
SIP su TLS, senza crittografia dei supporti |
Sì per SIP |
Servizio Web di messaggistica unificata |
80/TCP e 443/TCP (SSL) |
Autenticazione integrata di Windows (negoziazione) |
Autenticazione di base, digest, NTLM e negoziazione (Kerberos) |
Sì (SSL) |
Sì |
Da server Messaggistica unificata a server Trasporto Hub |
25/TCP (SSL) |
Kerberos |
Kerberos |
Sì (TLS) |
Sì |
Da server Messaggistica unificata a server Cassette postali |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Sì (crittografia RPC) |
Sì |
Note sui server 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 validi con cui è autorizzato a comunicare il server Cassette postali. Quando viene creato, il gateway IP di messaggistica unificata viene associato a un dial plan di messaggistica unificata. Ciò consente ai server Messaggistica unificata associati al dial plan di 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 nel server Messaggistica unificata non verranno accettate connessioni dall'indirizzo IP del gateway IP.
Nella versione di produzione originale (RTM) di Exchange 2007, un server Messaggistica unificata è in grado di comunicare sulla porta 5060/TCP (non protetta) oppure sulla porta 5061/TCP (protetta), ma non su entrambe.
Per ulteriori informazioni, vedere Concetti relativi alla protezione VoIP per la messaggistica unificata e Concetti relativi a protocolli, porte e servizi in messaggistica unificata.
Ulteriori informazioni
Per ulteriori informazioni, vedere l'articolo 179442 della Microsoft Knowledge Base, Configurazione di un firewall per domini e trust.