Modello delle autorizzazioni per il trasporto di Exchange 2007

Articolo
08/07/2014

Si applica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Ultima modifica dell'argomento: 2007-08-27

In questo argomento vengono fornite informazioni dettagliate sul modello delle autorizzazioni per il trasporto di Microsoft Exchange Server 2007. In Microsoft Exchange Server 2007 per trasporto si intende il processo di trasferimento dei messaggi da un server a un altro. Quando i messaggi vengono trasferiti tra un server Cassette postali e un server Trasporto Hub, viene utilizzato il protocollo MAPI. Quando i messaggi vengono inviati e ricevuti tra server Trasporto Hub, viene utilizzato il protocollo SMTP. Ciascuna sessione di comunicazione tra server può avere uno stadio di autenticazione facoltativo. Le richieste di connessione possono richiedere controlli delle autorizzazioni.

L'autenticazione è il processo che tenta di identificare il mittente di un messaggio. Se l'autenticazione non viene eseguita oppure non viene completata correttamente, l'identità del mittente è anonima. L'autorizzazione è il processo che determina se consentire all'utente, al programma o al dispositivo che sta tentando di stabilire il collegamento di accedere ad alcuni dati, funzionalità o servizi. Tale accesso dipende dall'azione richiesta. Il processo di autenticazione verifica l'identità. Il processo di autorizzazione determina il livello di accesso garantito.

In Exchange 2007, i protocolli SMTP e MAPI vengono forniti dal servizio Trasporto di Microsoft Exchange. Nelle sessioni che utilizzano il protocollo SMTP o MAPI, il servizio Trasporto di Microsoft Exchange utilizza il modello di autorizzazione di Microsoft Windows per gestire le autorizzazioni per una sessione. Nel trasporto di Exchange 2007, l'autorizzazione determina l'accettazione di diversi verbi di protocollo o eventi. Ad esempio, viene verificato che le autorizzazioni consentano al mittente di inoltrare un messaggio da un determinato indirizzo di posta elettronica o di creare messaggi di una determinata dimensione. Durante le conversazioni di protocollo MAPI e SMTP, in Exchange 2007 può essere eseguita l'autenticazione della sessione. Una volta autenticata la sessione, i gruppi di autorizzazione disponibili per la sessione possono cambiare a causa dell'autenticazione. In tal modo, è possibile elaborare in modo diverso i messaggi anonimi provenienti da Internet e i messaggi inoltrati da utenti autenticati nell'organizzazione di Exchange in virtù dei diversi gruppi di autorizzazione forniti dall'autenticazione.

Il comportamento predefinito per il trasporto in un ruolo del server Trasporto Edge è diverso dal comportamento predefinito in un ruolo del server Trasporto Hub. La differenza non è dovuta a una variazione del codice. Questa differenza è invece dovuta a una diversa serie predefinita di autorizzazioni per ciascun ruolo. I server Exchange che fanno parte della stessa foresta di Active Directory dispongono di una relazione trust. In base a tale relazione trust, le autorizzazioni predefinite configurate durante l'installazione abilitano il flusso di posta protetta nella foresta.

Ciascuna sessione autenticata presenta un token di accesso che elenca l'identificativo di protezione per ciascun gruppo a cui appartiene l'identità di protezione che esegue l'autenticazione. Nella Figura 1 sono illustrate le relazioni tra i membri del gruppo elencati nel token di accesso e le autorizzazioni assegnate a tali gruppi per l'oggetto a cui si accede.

Figura 1 Componenti di autorizzazione per il trasporto in Exchange 2007

Componenti dell'autorizzazione del trasporto di Exchange

La differenza tra le sessioni autenticate e messaggi autenticati

Il punto fondamentale del modello di trasporto di Exchange 2007 è la differenza tra le sessioni di trasporto autenticate e i messaggi autenticati. Un messaggio può contenere dei metadati che indicano se si tratta di un messaggio autenticato o anonimo. Quando un server autentica un altro server, può inviare un messaggio e contrassegnarlo con dei metadati che indicano se il messaggio è autenticato o anonimo. Il server ricevente determina se il contrassegno autenticato è attendibile. Se il server ricevente considera attendibile il mittente, il contrassegno autenticato viene lasciato inalterato. Se il server ricevente non considera attendibile il mittente, sovrascriverà il contrassegno autenticato del server mittente e aggiungerà al messaggio dei metadati che indicano che il messaggio è anonimo. In un'organizzazione di Exchange, il flusso di posta interno end-to-end si verifica tra due server che considerano attendibile il contrassegno del messaggio autenticato. Un server Trasporto Edge che riceve messaggi da Internet non considera attendibile il contrassegno autenticato di server anonimi in Internet. Pertanto, il server Trasporto Edge contrassegna ciascun messaggio con dei metadati che indicano che il messaggio è anonimo prima di inviarlo a un server Trasporto Hub su una connessione autenticata.

Funzionamento dell'autenticazione del trasporto del messaggio e del processo di autorizzazione

In Exchange 2007, per l'autenticazione di una sessione SMTP sono disponibili i seguenti meccanismi di base:

È possibile utilizzare un account e una password Windows in una sessione MAPI. In alternativa, è possibile utilizzare l'estensione AUTH di SMTP. Inoltre, è possibile utilizzare l'autenticazione password di testo normale, l'autenticazione NTLM e l'autenticazione Kerberos.
È possibile utilizzare un certificato X.509 tramite l'estensione STARTTLS di SMTP. In questo scenario, il server fornisce un certificato come parte della negoziazione TLS (Transport Layer Security). Se necessario, anche il client fornisce un certificato.
È inoltre possibile utilizzare un meccanismo di autenticazione esterno. L'autenticazione esterna utilizza un meccanismo che non fa parte di Exchange, ad esempio una rete protetta fisicamente o il protocollo IPsec. Questo metodo viene utilizzato quando le comunicazioni vengono stabilite tramite route IP identificate su connettori di invio e di ricezione dedicati.

Il server di trasporto di invio può eseguire l'autenticazione del server di trasporto ricevente prima di inviare il messaggio. Una volta autenticato il mittente, il server di trasporto ricevente applica le autorizzazioni garantite a quel mittente al token di accesso alla sessione.

In Exchange 2007, i connettori di invio e di ricezione gestiscono il flusso di posta. I connettori dispongono di un elenco di controllo di accesso discrezionale (DACL, Discretionary Access Control List) che consente di definire le autorizzazioni associate alla posta elettronica in uscita e in arrivo. Le autorizzazioni sui connettori di ricezione sono le più importanti. L'elenco DACL del connettore di ricezione determina le autorizzazioni del mittente per i messaggi inoltrati tramite il connettore di ricezione. Una volta stabilita una sessione SMTP per un connettore di ricezione, la sessione viene avviata con un token di accesso anonimo per quella sessione. Con la successiva autenticazione corretta il token di accesso viene modificato. Se una sessione non viene autenticata, i gruppi di autorizzazione nel token di accesso restano inalterati. Se una sessione viene autenticata, vengono garantite le autorizzazioni assegnate al singolo account o ruolo e le autorizzazioni assegnate a eventuali gruppi di protezione a cui appartiene l'account.

Il grafico di flusso nella Figura 2 illustra l'utilizzo dell'autenticazione e delle autorizzazioni in una sessione SMTP di un server di trasporto di Exchange 2007.

Figura 2 Il processo di autenticazione e autorizzazione di una sessione SMTP

Diagramma di flusso con processo di autenticazione della sessione SMTP

Configurazioni dell'autenticazione

I meccanismi di autenticazione configurati per un connettore di ricezione determinano i meccanismi di autenticazione disponibili per le sessioni che inoltrano messaggi al connettore di ricezione. Il meccanismo di autenticazione configurato per un connettore di invio determina quali meccanismi di autenticazione saranno utilizzati dal connettore di invio per autenticare uno SmartHost.

Autenticazione per i connettori di ricezione

È possibile configurare più meccanismi di autenticazione in un connettore di ricezione. Per un connettore di ricezione, l'impostazione dell'autenticazione determina la serie di meccanismi di autenticazione abilitati dal server per autenticare le sessioni che inoltrano messaggi al server. Il server mittente determina il meccanismo di autenticazione che viene utilizzato.

Nella Tabella 1 vengono elencati i meccanismi di autenticazione che è possibile configurare in un connettore di ricezione. Per configurare il meccanismo di autenticazione del connettore di ricezione, utilizzare la scheda Autenticazione delle proprietà del connettore di ricezione in Exchange Management Console o il parametro AuthMechanism nel cmdlet Set-ReceiveConnector in Exchange Management Shell.

Tabella 1 Meccanismi di autenticazione per i connettori di ricezione

Meccanismo di autenticazione	Descrizione
Nessuno	Non sono disponibili opzioni di autenticazione.
TLS (Transport Layer Security)	Il connettore consente ai client di utilizzare STARTTLS.
Autenticazione di Windows integrata	Il connettore consente ai client di utilizzare AUTH NTLM GSSAPI. GSSAPI abilita i client a negoziare NTLM o Kerberos.
Autenticazione di base	Il connettore consente ai client di utilizzare AUTH LOGIN. Il nome utente e la password vengono ricevuti come testo non crittografato dal client. Questo meccanismo richiede un account Windows per convalidare le credenziali.
Autenticazione di base tramite TLS	Si tratta del modificatore del criterio per l'autenticazione di base. Il connettore consente al client di utilizzare AUTH LOGIN solo dopo che il client ha negoziato TLS. Questo meccanismo richiede anche che TLS sia impostato come il meccanismo di autenticazione.
Autenticazione di Exchange Server	Il connettore consente di utilizzare EXPS GSSAPI ai server Exchange su cui sono in esecuzione versioni precedenti di Exchange Server e X-ANONYMOUSTLS ai clienti per i server Exchange 2007.
Protetto esternamente (ad esempio con IPsec)	Questa opzione considera tutte le connessioni come provenienti da un altro server autorevole.

Autenticazione per i connettori di invio SmartHost

Per un connettore di invio, l'impostazione SmartHostAuthMechanism determina il modo in cui il server mittente autentica lo SmartHost di destinazione. L'impostazione SmartHostAuthMechanism può avere un solo valore. Se è configurato un parametro SmartHostAuthMechanism, è necessario che l'autenticazione venga completata con esisto positivo prima di poter inviare messaggi di posta. Se il meccanismo di autenticazione utilizzato dal server mittente di Exchange 2007 non viene fornito da SmartHost, il server non invierà i messaggi di posta elettronica e la sessione sarà terminata. Se il meccanismo di autenticazione utilizzato dal server mittente di Exchange 2007 viene fornito, ma l'esito dell'autenticazione non è positivo, il server non invierà i messaggi di posta elettronica e la sessione sarà terminata.

Nella Tabella 2 vengono elencati i meccanismi di autenticazione che è possibile configurare in un connettore di invio. Per configurare il meccanismo di autenticazione del connettore di invio, utilizzare la finestra di dialogo Configura autenticazione SmartHost nella scheda Rete delle proprietà del connettore di invio in Exchange Management Console oppure il parametro SmartHostAuthMechanism con il cmdlet Set-SendConnector in Exchange Management Shell.

Tabella 2 Meccanismo di autenticazione per i connettori SmartHost

Meccanismo di autenticazione	Descrizione
Nessuno	L'accesso anonimo è consentito.
Autenticazione di base	Il connettore deve utilizzare AUTH LOGIN. Verrà richiesto il nome utente e la password. L'autenticazione di base invia le credenziali come testo non crittografato. Tutti gli SmartHost con cui questo connettore di invio sta eseguendo l'autenticazione devono accettare lo stesso nome utente e la stessa password. Se anche il parametro RequireTLS è impostato su `$True`, il connettore deve utilizzare TLS prima di inoltrare le credenziali; tuttavia, non viene eseguita alcuna verifica del certificato del server.
Autenticazione di base con TLS	Si tratta del modificatore del criterio per l'autenticazione di base. Richiede che il connettore utilizzi TLS prima di provare AUTH. Inoltre, richiede che il server mittente esegua la convalida del certificato X.509 del server ricevente. La convalida del certificato comprende il controllo dell'elenco di revoche di certificati (CRL, Certificate Revocation List) e dell'identità del server in base all'elenco degli SmartHost configurati nel connettore prima di provare AUTH. Uno dei nomi di dominio completi (Fully Qualified Domain Name, FQDN) elencato come SmartHost deve essere presente nel certificato del server per eseguire correttamente la verifica del nome. Quindi, se il nome del dominio completo dello SmartHost punta a un record MX, il nome del dominio completo dello SmartHost elencato deve essere presente nel certificato.
Autenticazione di Exchange Server	Il connettore deve utilizzare EXPS GSSAPI per i server Exchange su cui sono in esecuzione versioni precedenti di Exchange Server o X-ANONYMOUSTLS per i server Exchange 2007.
Protetto esternamente (ad esempio con IPsec)	La connessione di rete viene protetta utilizzando un metodo esterno al server Exchange.

Transport Layer Security

Il protocollo TLS è descritto in RFC 2246. Il TLS utilizza i certificati X.509. Questi certificati sono moduli di credenziali elettroniche. Il TLS può essere utilizzato nel modo descritto di seguito:

Solo per la riservatezza.
Per l'autenticazione del server con riservatezza quando il certificato del server è convalidato.
Per l'autenticazione reciproca con riservatezza quando sono convalidati sia il certificato del server che il certificato del client.

Durante la conversazione del protocollo SMTP, il client emette il comando SMTP STARTTLS per richiedere la negoziazione di TLS per la sessione corrente. Il client riceve un certificato X.509 dal server come parte della negoziazione del protocollo TLS. Il criterio di autenticazione del client quindi determina se il certificato del server ricevente deve essere convalidato e se altri criteri devono essere applicati al certificato, come la corrispondenza dei nomi.

Una parte facoltativa della negoziazione del TLS consente al server ricevente di richiedere anche un certificato dal server mittente. Se il server mittente invia un certificato al server ricevente, il criterio locale sul server ricevente determina il modo in cui il certificato viene convalidato e le autorizzazioni garantite al server mittente in base all'autenticazione.

Quando TLS viene utilizzato per l'autenticazione del server, viene convalidato solo il certificato del server ricevente. Se TLS viene utilizzato per l'autenticazione reciproca, devono essere convalidati sia il certificato del server mittente sia il certificato del server ricevente.

Quando TLS viene configurato su un connettore di ricezione di Exchange 2007, il server deve disporre di un certificato X.509. Tale certificato può essere un certificato autofirmato oppure un certificato firmato da un'Autorità di certificazione (Certification Authority, CA). Il server Exchange cerca il certificato nell'archivio locale che corrisponde al nome del dominio completo del connettore. Il server mittente seleziona il tipo di utilizzo del protocollo TLS. Quando Exchange utilizza TLS solo per la riservatezza, il client Exchange non convalida il certificato. Ad esempio, quando Exchange utilizza TLS tra i server Trasporto Hub utilizzando Kerberos tramite il protocollo TLS, stabilisce un canale riservato tra i server e non esegue alcuna convalida sul certificato. L'autenticazione tra i server viene eseguita utilizzando Kerberos al termine delle operazioni del protocollo TLS.

Quando è richiesta l'autenticazione TLS, Exchange deve convalidare il certificato. Esistono due modi in cui Exchange convalida il certificato trust diretto o convalida X.509. Quando il TLS viene utilizzato per la comunicazione dal server Trasporto Edge al server Trasporto Hub, Exchange utilizza il meccanismo del trust diretto per convalidare il certificato.

In tal caso, viene utilizzato un archivio attendibile, come Active Directory o ADAM (Active Directory Application Mode). Utilizzando il trust diretto, inoltre, la presenza del certificato nell'archivio determina la convalida del certificato. 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 pubblica il certificato del server Trasporto Edge in Active Directory affinché i server Trasporto Hub possano eseguire la convalida. Il servizio Microsoft Exchange Edgesync aggiorna ADAM con la serie di certificati del server Trasporto Hub affinché il server Trasporto Edge possa eseguire la convalida.

L'altro metodo di convalida dei certificati utilizzato da Exchange è la convalida X.509. Per utilizzare la convalida X.509, il certificato deve essere firmato da un'Autorità di certificazione. In Exchange la convalida X.509 viene utilizzata per autenticare gli SmartHost oppure quando si utilizza la protezione del dominio. La protezione del dominio verrà illustrata nella sezione seguente.

Protezione del dominio

La protezione del dominio si riferisce alla serie di funzionalità di Exchange 2007 e Microsoft Office Outlook che rappresenta un'alternativa relativamente economica a S/MIME o altre soluzioni di protezione a livello del messaggio. Lo scopo della protezione del dominio è di fornire agli amministratori un modo per gestire i percorsi dei messaggi protetti su Internet con partner aziendali. Una volta configurati i percorsi per messaggi protetti, i messaggi che attraversano tali percorsi da un mittente autenticato senza errori vengono visualizzati come protetti dal dominio nell'interfaccia di Outlook e di Outlook Web Access.

Un connettore di invio verifica che il dominio di destinazione sia incluso nell'elenco di domini mittenti configurati per la protezione del dominio se si verificano le seguenti condizioni:

Il connettore di invio è configurato per inoltrare i messaggi tramite i record di risorse DNS MX.
Il connettore di invio è configurato come dominio protetto.

Se il dominio di destinazione si trova nell'elenco, il server di trasporto attiva l'autenticazione TLS reciproca quando invia messaggi di posta elettronica al dominio.

Il server ricevente risponde con un comando SMTP QUIT se si verificano le seguenti condizioni:

Exchange non può negoziare TLS
La convalida del certificato del server o la verifica degli elenchi CRL non viene eseguita correttamente.

Il messaggio viene messo in coda sul server mittente. È in corso un nuovo tentativo di connessione della coda. Questo comportamento si verifica anche quando il controllo del nome non ottiene esito positivo.

Se il connettore di ricezione è protetto nel dominio, il server di trasporto controlla la posta ricevuta. Quindi il server di trasporto applica l'autenticazione TLS reciproca se il mittente si trova nell'elenco dei domini destinatari configurati per la protezione del dominio. Se tutti i controlli ottengono esito positivo, il messaggio ricevuto è contrassegnato come protetto dal dominio. Se il mittente non può negoziare TLS, oppure se la convalida del certificato del server o la verifica dell'elenco CRL non ottengono esito positivo, il server di trasporto rifiuta il messaggio utilizzando il comando REJECT del protocollo SMTP. Anche se il controllo del nome non ottiene esito positivo viene eseguito il comando REJECT del protocollo SMTP. Quindi, il server Exchange invia un messaggio con un errore SMTP temporaneo (4xx) al server mittente. Ciò significa che il server mittente dovrà riprovare in seguito. Questo comportamento evita che errori transitori causati da errori di verifica dell'elenco CRL temporanei provochino un immediato rapporto di mancato recapito al mittente. L'errore causa solo un ritardo nel recapito del messaggio.

Per ulteriori informazioni, vedere Gestione della protezione del dominio.

Autenticazione protetta esternamente

È possibile selezionare l'opzione di autenticazione per la protezione esterna se si è sicuri che la connessione di rete tra server sia affidabile. Tale connessione può essere un'associazione IPsec o una rete privata virtuale. In alternativa, i server possono risiedere in una rete controllata fisicamente e affidabile. Questa configurazione può essere utile nei seguenti casi:

Si stabilisce un flusso di posta tra un server di trasporto Exchange 2007 e una versione precedente di Exchange Server oppure qualsiasi altro server SMTP.
Non si desidera utilizzare l'autenticazione di base.

I connettori di Exchange configurati come protetti esternamente devono utilizzare i connettori di invio e i connettori di ricezione dedicati perché si presume che tutte le connessioni ai connettori siano protette. Pertanto, i connettori di invio configurati come protetti esternamente devono utilizzare uno SmartHost per inoltrare i messaggi. Inoltre, gli indirizzi IP degli SmartHost di destinazione devono essere configurati sul connettore. I connettori di ricezione configurati come protetti esternamente devono disporre di RemoteIPRanges impostato sull'intervallo di indirizzi IP dei server mittenti. TLS può anche essere combinato con l'opzione di autenticazione di protezione esterna per aggiungere riservatezza della sessione. A tale scopo, in Exchange Management Shell impostare il parametro RequireTLS nei connettori su $True.

Autorizzazione

Durante il trasporto dei messaggi, l'autorizzazione è il processo che determina se un'azione richiesta, ad esempio l'invio di posta, è consentita in una sessione SMTP.

Autorizzazioni di trasporto di Exchange 2007

I server di trasporto di Exchange 2007 utilizzano il modello di autorizzazione di Windows per consentire a una sessione SMTP di determinare se il mittente è autorizzato a inoltrare messaggi a uno specifico connettore, a uno specifico destinatario e come uno specifico mittente, ad esempio. Una sessione SMTP riceve una serie iniziale di autorizzazioni (anonime). Una volta autenticata la sessione, è disponibile per la sessione un numero maggiore di autorizzazioni. In tal modo, la serie di azioni autorizzate per la sessione cambia.

Nel modello di autorizzazioni di Windows, le autorizzazioni vengono concesse tramite l'interazione del controllo di accesso che confronta il token di accesso con gli elenchi di controllo di accesso (ACL). Nel token di accesso sono elencate le identità di protezione. Un'identità di protezione può essere un account utente, un account computer o un gruppo di protezione. A ciascuna identità di protezione è associato un SID. A ciascuna sessione è assegnato un token di accesso. Gli ACL sono definiti nell'oggetto connettore in Active Directory o in ADAM. Un elenco DACL contiene una serie di voci di controllo dell'accesso (Access Control Entries, ACE). Ciascuna voce ACE può concedere o negare l'autorizzazione a un'identità di protezione. Quando il server di trasporto verifica se è stata concessa un'autorizzazione alla sessione, ad esempio l'inoltro di messaggi di posta elettronica, chiama un'API di controllo dell'accesso di Windows e fornisce il token di accesso alla sessione e l'elenco DACL del connettore come parametro insieme all'autorizzazione richiesta.

Questo processo è identico al processo di determinazione dell'autorizzazione alla lettura di un file. Il token di accesso, l'elenco DACL del file e l'autorizzazione richiesta vengono inoltrati alla stessa API. L'API verifica le singole identità di protezione elencate nel token di accesso in base alla voce ACE nell'elenco DACL per verificare se l'autorizzazione richiesta è stata concessa o negata. Oltre ai SID Windows forniti da Active Directory, ADAM o dal database SAM (Security Accounts Manager) locale in un computer, Exchange 2007 definisce dei SID aggiuntivi. Tali SID rappresentano gruppi logici. Nella Tabella 3 sono elencati i SID definiti da Exchange 2007 per l'utilizzo durante l'autenticazione del trasporto.

Tabella 3 SID di Exchange 2007

Nome visualizzato	SID	Gruppo logico
Server partner	S-1-9-1419165041-1139599005-3936102811-1022490595-10	I domini del mittente e del destinatario sono configurati per la protezione del dominio.
Server Trasporto Hub	S-1-9-1419165041-1139599005-3936102811-1022490595-21	I server Trasporto Hub nella stessa organizzazione di Exchange.
Server Trasporto Edge	S-1-9-1419165041-1139599005-3936102811-1022490595-22	I server Trasporto Edge attendibili.
Server protetti esternamente	S-1-9-1419165041-1139599005-3936102811-1022490595-23	Server di terze parte attendibili che si trovano nello stesso dominio autorevole.
Server Exchange precedenti	S-1-9-1419165041-1139599005-3936102811-1022490595-24	I server Exchange Server 2003 che si trovano nella stessa organizzazione di Exchange.

Autorizzazioni del connettore di ricezione

I connettori di ricezione elaborano le sessioni in arrivo nel server. La sessione può essere stabilita da un mittente autenticato o da un mittente anonimo. Se la sessione viene correttamente autenticata, i SID nel token di accesso della sessione vengono aggiornati. Nella Tabella 4 vengono elencate le autorizzazioni che possono essere concesse a una sessione che si collega a un connettore di ricezione.

Tabella 4 Autorizzazioni per il connettore di ricezione

Autorizzazione	Nome visualizzato	Descrizione
ms-Exch-SMTP-Submit	Inoltra i messaggi al server	Alla sessione deve essere concessa questa autorizzazione altrimenti non potrà inoltrare messaggi a questo connettore di ricezione. Se a una sessione non viene concessa questa autorizzazione, il comando MAIL FROM non avrà esito positivo.
ms-Exch-SMTP-Accept-Any-Recipient	Inoltra i messaggi a qualsiasi destinatario	Questa autorizzazione consente alla sessione di inoltrare i messaggi tramite questo connettore. Se questa autorizzazione non è concessa, vengono accettati da questo connettore solo i messaggi indirizzati ai destinatari nei domini accettati.
ms-Exch-SMTP-Accept-Any-Sender	Accetta qualsiasi mittente	Questa autorizzazione consente alla sessione di evitare il controllo di spoofing dell'indirizzo del mittente.
ms-Exch-SMTP-Accept-Authoritative-Domain-Sender	Accetta il mittente del dominio autorevole	Questa autorizzazione consente alla sessione di evitare un controllo che blocca i messaggi in arrivo da indirizzi di posta elettronica nei domini autorevoli.
ms-Exch-SMTP-Accept-Authentication-Flag	Accetta il flag di autenticazione	Questa autorizzazione consente ai server Exchange su cui sono in esecuzione versioni precedenti di Exchange Server di inoltrare messaggi da mittenti interni. I server Exchange 2007 riconoscono il messaggio come interno.
ms-Exch-Accept-Headers-Routing	Accetta intestazioni di routing	Questa autorizzazione consente alla sessione di inoltrare un messaggio in cui tutte le intestazioni ricevute sono inalterate. Se questa autorizzazione non è concessa, il server rimuove tutte le intestazioni ricevute.
ms-Exch-Accept-Headers-Organization	Accetta le intestazioni dell'organizzazione	Questa autorizzazione consente alla sessione di inoltrare un messaggio in cui tutte le intestazioni dell'organizzazione sono inalterate. Tutte le intestazioni dell'organizzazione iniziano con “X-MS-Exchange-Organization-“. Se questa autorizzazione non è concessa, il server ricevente rimuove tutte le intestazioni dell'organizzazione.
ms-Exch-Accept-Headers-Forest	Accetta le intestazioni della foresta	Questa autorizzazione consente alla sessione di inoltrare un messaggio in cui tutte le intestazioni della foresta sono inalterate. Tutte le intestazioni della foresta iniziano con “X-MS-Exchange-Forest-“. Se questa autorizzazione non è concessa, il server ricevente rimuove tutte le intestazioni della foresta.
ms-Exch-Accept-Exch50	Accetta Exch50	Questa autorizzazione consente alla sessione di inoltrare un messaggio che contiene il comando XEXCH50. Questo comando è obbligatorio per l'interoperabilità con Exchange 2000 Server e Exchange 2003. Il comando XEXCH50 fornisce i dati, ad esempio il livello di probabilità di posta indesiderata per il messaggio.
ms-Exch-Bypass-Message-Size-Limit	Ignora la limitazione della dimensione dei messaggi	Questa autorizzazione consente alla sessione di inoltrare un messaggio che supera il limite della dimensione del messaggio configurato per il connettore.
Ms-Exch-Bypass-Anti-Spam	Ignora la protezione da posta indesiderata	Questa autorizzazione consente alla sessione di evitare il filtro protezione da posta indesiderata.

Autorizzazioni del connettore di invio

I connettori di invio elaborano le sessioni in uscita verso un altro server. La sessione può essere stabilita dal mittente con un ricevente anonimo o autenticato. Se la sessione viene correttamente autenticata, la serie di SID nel token di accesso della sessione viene aggiornata. Le autorizzazioni del connettore di invio determinano i tipi di informazioni dell'intestazione che possono essere inclusi in un messaggio inviato tramite il connettore. I messaggi inviati ad altri server Exchange nell'organizzazione oppure a un'organizzazione Exchange attendibile in uno scenario con più foreste possono di solito inviare tutte le intestazioni. I messaggi inviati tramite Internet o a server SMTP non Exchange non possono contenere tutte le intestazioni. Se le intestazioni sono incluse nel messaggio, la funzionalità di firewall dell'intestazione di Exchange 2007 rimuove tali intestazioni. Nella Tabella 5 vengono elencate le autorizzazioni che possono essere concesse a una sessione che si collega a un connettore di invio.

Tabella 5 Autorizzazioni per il connettore di invio

Autorizzazione	Nome visualizzato	Descrizione
ms-Exch-Send-Exch50	Invia Exch50	Questa autorizzazione consente alla sessione di inviare un messaggio che contiene il comando EXCH50. Se questa autorizzazione non è concessa, il server invia il messaggio ma non include il comando EXCH50.
Ms-Exch-Send-Headers-Routing	Invia le intestazioni di routing	Questa autorizzazione consente alla sessione di inviare un messaggio in cui tutte le intestazioni ricevute sono inalterate. Se questa autorizzazione non è concessa, il server rimuove tutte le intestazioni ricevute.
Ms-Exch-Send-Headers-Organization	Invia le intestazioni dell'organizzazione	Questa autorizzazione consente alla sessione di inviare un messaggio in cui tutte le intestazioni dell'organizzazione sono inalterate. Tutte le intestazioni dell'organizzazione iniziano con “X-MS-Exchange-Organization-“. Se questa autorizzazione non è concessa, il server mittente rimuove tutte le intestazioni dell'organizzazione.
Ms-Exch-Send-Headers-Forest	Invia le intestazioni della foresta	Questa autorizzazione consente alla sessione di inviare un messaggio in cui tutte le intestazioni della foresta sono inalterate. Tutte le intestazioni della foresta iniziano con “X-MS-Exchange-Forest-“. Se questa autorizzazione non è concessa, il server mittente rimuove tutte le intestazioni della foresta.

Gruppi di autorizzazioni

Un gruppo di autorizzazioni è costituito da una serie predefinita di autorizzazioni che possono essere concesse in un connettore di ricezione. I gruppi di autorizzazioni sono disponibili solo per i connettori di ricezione. L'utilizzo dei gruppi di autorizzazioni semplifica la configurazione delle autorizzazioni sui connettori di ricezione. La proprietà PermissionGroups definisce i gruppi o i ruoli che possono inoltrare i messaggi al connettore di ricezione e le autorizzazioni concesse a tali gruppi. La serie di gruppi di autorizzazioni è predefinita in Exchange 2007. Non è quindi possibile creare gruppi di autorizzazioni aggiuntivi. Inoltre, non è possibile modificare i membri del gruppo di autorizzazioni o le autorizzazioni associate.

Nella Tabella 6 sono elencati i gruppi di autorizzazioni, i membri del gruppo di autorizzazioni e le autorizzazioni associate disponibili in Exchange 2007.

Tabella 6 Gruppi di autorizzazioni e autorizzazioni associate del connettore di ricezione

Nome gruppo di autorizzazioni	Identità di protezione	Autorizzazioni concesse ai server Trasporto Edge	Autorizzazioni concesse ai server Trasporto Hub
Anonimo	Utenti anonimi	Inoltra i messaggi al server Accetta tutti i mittenti Accetta le intestazioni di routing	Inoltra i messaggi al server Accetta tutti i mittenti Accetta le intestazioni di routing
ExchangeUsers	Utenti autenticati (gli account noti sono esclusi)	Non disponibile	Inoltra i messaggi al server Accetta tutti i destinatari Ignora il filtro protezione da posta indesiderata
Server di Exchange	Server Exchange 2007	Tutte le autorizzazioni di ricezione	Tutte le autorizzazioni di ricezione
ExchangeLegacyServers	Server Exchange 2003 e Exchange 2000	Non disponibile	Inoltra i messaggi al server Inoltra i messaggi a qualsiasi destinatario Accetta tutti i mittenti Accetta il mittente del dominio autorevole Accetta l'indicatore di autenticazione Accetta le intestazioni di routing Accetta Exch50 Ignora la limitazione della dimensione dei messaggi Ignora il filtro protezione da posta indesiderata
Partner	Account del server partner	Inoltra i messaggi al server Accetta le intestazioni di routing	Inoltra i messaggi al server Accetta le intestazioni di routing

Tipi di utilizzo del connettore

Quando si crea un nuovo connettore, è possibile specificare un tipo di utilizzo del connettore. Il tipo di utilizzo determina le impostazioni predefinite per il connettore. Inoltre, sono inclusi i SID autenticati, le autorizzazioni assegnate a tali SID e il meccanismo di autenticazione.

Nella Tabella 7 vengono elencati i tipi di utilizzo disponibili per un connettore di ricezione. Quando si seleziona un tipo di utilizzo per un connettore di ricezione, i gruppi di autorizzazioni vengono automaticamente assegnati al connettore. È inoltre configurato un meccanismo di autenticazione predefinito.

Tabella 7 Tipi di utilizzo del connettore di ricezione

Tipo di utilizzo	Gruppi di autorizzazioni predefiniti	Meccanismo di autenticazione predefinito
Client	ExchangeUsers	TLS. BasicAuthPlusTLS.
Custom	Nessuno	Nessuna.
Internal	ExchangeServers ExchangeLegacyServers	Autenticazione di Exchange Server.
Internet	AnonymousUsers Partner	Nessuna autenticazione oppure protezione esterna.
Partner	Partner	Non applicabile. Questo tipo di utilizzo viene selezionato quando si stabilisce l'autenticazione TLS reciproca con un dominio remoto.

Nella Tabella 8 vengono elencati i tipi di utilizzo disponibili per un connettore di invio. Quando si seleziona un tipo di utilizzo per un connettore di invio, le autorizzazioni vengono automaticamente assegnate ai SID. È inoltre configurato un meccanismo di autenticazione predefinito.

Tabella 8 Tipi di utilizzo del connettore di invio

Tipo di utilizzo	Autorizzazioni predefinite	Identità di protezione	Meccanismo di autenticazione predefinito per gli SmartHost
Custom	Nessuno	Nessuno	Nessuno
Internal	Invia le intestazioni dell'organizzazione Invia Exch50 Invia le intestazioni di routing Invia le intestazioni della foresta	Server Trasporto Hub Server Trasporto Edge Gruppo di protezione dei server Exchange Server protetti esternamente Gruppo di protezione interoperativo precedente Exchange Server testa di ponte Exchange 2003 e Exchange 2000	Autenticazione di Exchange Server.
Internet	Invia le intestazioni di routing	Account utente anonimo	Nessuna.
Partner	Invia le intestazioni di routing	Server partner	Non applicabile. Questo tipo di utilizzo viene selezionato quando si stabilisce l'autenticazione TLS reciproca con un dominio remoto.

Se si seleziona il tipo di utilizzo personalizzato per un connettore di invio o di ricezione, è necessario configurare manualmente il metodo di autenticazione e i SID autorizzati e assegnare le autorizzazioni a tali SID. Se non si specifica un tipo di utilizzo, viene selezionato il tipo personalizzato di utilizzo del connettore.

Impostazione delle autorizzazioni utilizzando lo script Enable-CrossForestConnector

Lo script Enable-CrossForestConnector.ps1 consente di semplificare la configurazione delle autorizzazioni nei connettori con più foreste. Questo script assegna le autorizzazioni in modo simile ai gruppi di autorizzazioni. Una serie definita di autorizzazioni viene assegnata a un connettore di invio o a un connettore di ricezione. È possibile modificare questa serie di autorizzazioni come necessario in base allo scenario della connessione modificando il contenuto dello script Enable-CrossForestConnector.ps1. Per ulteriori informazioni, vedere Configurazione di connettori tra più foreste.

Impostazione delle autorizzazioni utilizzando il cmdlet Add-AdPermission

Il cmdlet Add-AdPermission in Exchange Management Shell è un cmdlet globale utilizzato per assegnare autorizzazioni ad oggetti memorizzati in Active Directory. È possibile utilizzare il cmdlet Add-AdPermission per garantire singole autorizzazioni a un connettore di invio o a un connettore di ricezione. Il cmdlet Add-AdPermission non viene normalmente utilizzato per gestire le autorizzazioni di trasporto. Tuttavia, deve essere utilizzato per configurare le autorizzazioni nei seguenti scenari:

Stabilire un flusso di posta in uno scenario con più foreste.
Accettare la posta elettronica anonima proveniente da Internet da un mittente in un dominio autorevole.

Le autorizzazioni di trasporto di Exchange 2007 fanno parte della serie di diritti estesi che possono essere assegnati utilizzando questo cmdlet. Nella seguente procedura viene illustrato come utilizzare il cmdlet Add-AdPermission per impostare le autorizzazioni nel connettore di ricezione di un server Trasporto Hub per consentire alle sessioni anonime di inoltrare messaggi:

Impostazione delle autorizzazioni in un connettore di ricezione con Exchange Management Shell

Eseguire il comando riportato di seguito:

Add-AdPermission -Identity "Default Hub1" -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights ms-Exch-SMTP-Submit,ms-Exch-SMTP-Accept-Any-Recipient,ms-Exch-Bypass-Anti-Spam

È possibile utilizzare il cmdlet Get-AdPermission per visualizzare l'elenco DACL per un connettore di invio o per un connettore di ricezione. Eseguire uno dei comandi riportati di seguito per richiamare le autorizzazioni assegnate a un connettore di ricezione e per visualizzare i risultati in una tabella formattata:

Visualizzazione delle autorizzazioni estese in un connettore di ricezione con Exchange Management Shell

Eseguire uno dei comandi riportati di seguito:

Get-AdPermission -Identity "Default ServerName" | format-table -view User
Get-AdPermission -Identity "Default ServerName" | format-table -view Identity

È possibile utilizzare il cmdlet Remove-AdPermission per rimuovere tutte le autorizzazioni assegnate precedentemente.

Per ulteriori informazioni su come impostare, visualizzare e rimuovere le autorizzazioni con Exchange Management Shell, vedere i seguenti argomenti:

Impostazione delle autorizzazioni con ADSI Edit

Active Directory Service Interfaces (ADSI) Edit è una Microsoft Management Console fornita con gli Strumenti di supporto di Windows. ADSI Edit viene utilizzato come editor di basso livello per modificare le proprietà degli oggetti Active Directory o ADAM non esposti in altre interfacce di gestione. ADSI Edit deve essere utilizzato solo da amministratori esperti.

ADSI Edit consente di visualizzare e modificare gli ACL per i connettori di invio e i connettori di ricezione. Una volta aperto ADSI Edit, è necessario individuare l'oggetto connettore. I connettori di Exchange 2007 sono memorizzati nella partizione di configurazione del servizio directory. I connettori di invio sono memorizzati come oggetti nel contenitore delle connessioni. I connettori di ricezione sono memorizzati come oggetti figli nel server di trasporto Exchange 2007.

Per modificare le autorizzazioni di un connettore di ricezione con ADSI Edit:

Individuare il connettore di ricezione dal seguente percorso:

CN=Configuration\CN=Services\CN=Microsoft Exchange\CN=<Organizzazione>\CN=Administrative Groups\CN=Exchange Administrative Group (FYDIBOHF23SPDLT)\CN=Servers\CN=<Nome server>\CN=Protocols\CN=SMTP Receive Connectors
Selezionare un connettore di ricezione dal riquadro dei risultati. Fare clic con il pulsante destro del mouse e scegliere Proprietà.
Scegliere la scheda Protezione. Viene visualizzata la seguente schermata:
Fare clic su Aggiungi per selezionare l'utente o il gruppo a cui concedere le autorizzazioni oppure selezionare una voce di Nome utente o gruppo esistente.
Scegliere le autorizzazioni da assegnare all'account e selezionare la casella di controllo nella colonna Consenti.

Per modificare le autorizzazioni di un connettore di invio con ADSI Edit:

Individuare il connettore di invio dal seguente percorso:

CN=Configuration\CN=Services\CN=Microsoft Exchange\CN=<Organizzazione>\CN=Administrative Groups\CN=Exchange Administrative Group(FYDIBOHF23SPDLT)\CN=Routing Groups\CN=Routing Group (DWBGZMFD01QNBJR)\CN=Connections
Selezionare un connettore di invio dal riquadro dei risultati. Fare clic con il pulsante destro del mouse e scegliere Proprietà.
Scegliere la scheda Protezione. Viene visualizzata la seguente schermata:
Fare clic su Aggiungi per selezionare l'utente o il gruppo a cui concedere le autorizzazioni oppure selezionare una voce di Nome utente o gruppo esistente.
Scegliere le autorizzazioni da assegnare all'account e selezionare la casella di controllo nella colonna Consenti.

Risoluzione dei problemi

Durante la conversazione del protocollo, il server SMTP può rifiutare alcuni comandi a causa della mancanza di autorizzazioni. Nella Tabella 9 sono elencati i messaggi di rifiuto del protocollo più comuni e la configurazione dell'autorizzazione che causa l'errore.

Tabella 9 Messaggi comuni di rifiuto del protocollo e relative cause

Risposta del server SMTP	Causa
530 5.7.1 Client non autenticato	Il mittente specificato nel campo MAIL FROM del protocollo SMTP non dispone dell'autorizzazione per inoltrare a questo server. È necessario concedere al mittente l'autorizzazione ms-Exch-SMTP-Submit.
535 5.7.3 Autenticazione non eseguita	Durante la fase AUTH della conversazione del protocollo SMTP, le credenziali fornite non erano corrette oppure l'utente autenticato non dispone dell'autorizzazione per inoltrare a questo server.
550 5.7.1 Il client non dispone dell'autorizzazione per inoltrare a questo server	Il mittente specificato nel campo MAIL FROM della conversazione del protocollo SMTP era autenticato ma non dispone dell'autorizzazione per inoltrare a questo server.
550 5.7.1 Il client non dispone dell'autorizzazione per eseguire l'invio come mittente corrente	Il mittente specificato nel campo MAIL FROM della conversazione del protocollo SMTP è un indirizzo in un dominio autorevole. Tuttavia, la sessione non dispone dell'autorizzazione ms-Exch-SMTP-Accept-Authoritative-Domain-Sender. Questa situazione si verifica se un messaggio è stato inoltrato tramite Internet a un server Trasporto Edge da un indirizzo mittente per il quale l'organizzazione di Exchange è autorevole.
550 5.7.1 Il client non dispone dell'autorizzazione per eseguire l'invio a nome dell'indirizzo mittente	L'utente autenticato non dispone dell'autorizzazione per inoltrare un messaggio a nome del mittente specificato nell'intestazione del messaggio. Inoltre, la sessione non dispone dell'autorizzazione ms-Exch-SMTP-Accept-Any-Sender.
550 5.7.1. Impossibile inoltrare	Il dominio del destinatario a cui è indirizzato il messaggio non fa parte di nessuno dei domini accettati definiti per questa organizzazione. Inoltre, la sessione non dispone dell'autorizzazione ms-Exch-SMTP-Accept-Any-Recipient.

Ulteriori informazioni

Per ulteriori informazioni, vedere i seguenti argomenti: