Comunicazioni

Accesso a Outlook Web Access con smart card

Victor Akinnagbe and Ted Dressel and Jason Opdycke

Panoramica:

• Autenticazione a due fattori
• Delega vincolata Kerberos
• Configurazione di ISA Server e di Exchange

I dipendenti mobili rappresentano per le organizzazioni IT una delle principali problematiche correlate alla protezione. Gli utenti remoti necessitano di accesso protetto a dati e servizi, ad esempio la posta elettronica. La sfortunata realtà è che, tuttavia, i collegamenti

più deboli della catena di protezione coinvolgono password vulnerabili, malware (ad esempio keystroke logger) e virus sui computer remoti che tentano di accedere alle risorse interne dell'organizzazione.

Un metodo per aumentare la protezione nell'ambiente mobile consiste nel rimuovere uno di questi collegamenti vulnerabili, ovvero le password (anche se l'idea di consentire l'accesso a un account senza una password per l'autenticazione può destare non poca preoccupazione). Una delle principali tecniche utilizzate per eliminare i problemi associati alle password è nota come autenticazione a due fattori (talvolta chiamata autenticazione a più fattori). Anziché basarsi su un singolo metodo, una password, per consentire l'accesso, l'autenticazione a due fattori prevede l'utilizzo di metodi di autenticazione aggiuntivi, tra cui la combinazione di nome utente/password, un dispositivo fisico, come una smart card, o un identificatore biometrico, ad esempio un'impronta digitale.

In un'organizzazione con utenti mobili è necessario in genere aprire il firewall per consentire l'accesso remoto alla rete aziendale. Un firewall standard offre una strategia di riduzione dei rischi di base fornendo l'isolamento a livello di rete tra le reti interne ed esterne (vedere la Figura 1). Per garantire un livello di protezione aggiuntivo, le porte vengono semplicemente chiuse e, se occorre stabilire una comunicazione con un dispositivo sulla rete interna, le porte vengono inoltrate verso la posizione appropriata. Sebbene queste tecniche forniscano una protezione significativa a livello di rete, attualmente la crescente complessità degli attacchi impone la necessità di più livelli di protezione della rete.

Figura 1** Firewall standard con porte bloccate o inoltrate **(Fare clic sull'immagine per ingrandirla)

Poiché i servizi aziendali più comuni generalmente utilizzati dai dipendenti mobili sono la posta elettronica e la messaggistica, la configurazione dell'infrastruttura Exchange in modo protetto riveste più che mai un'importanza cruciale. Consentire l'accesso degli utenti alla posta elettronica tramite Outlook® Web Access (OWA) rappresenta una soluzione per fornire servizi protetti ai dipendenti mobili. Un altro metodo chiave consiste nel garantire una autenticazione a due fattori più protetta per OWA tramite smart card. In questo articolo verranno esaminati nel dettaglio i problemi di configurazione e di installazione che è opportuno tenere in considerazione quando si attiva la distribuzione OWA abilitata all'utilizzo di smart card.

Soluzione migliore di un firewall

L'utilizzo di Microsoft® Internet Security and Acceleration (ISA) Server 2006 sulla rete può semplificare l'attività di apertura della rete agli utenti remoti in modo più protetto. ISA Server 2006 include diverse funzionalità per il miglioramento della protezione, quale la rete privata virtuale (VPN) abilitata all'utilizzo di smart card, autenticazione LDAP (Lightweight Directory Access Protocol) ad Active Directory® e delega vincolata Kerberos. ISA Server presenta delle lievi differenze rispetto a un firewall standard. Fornisce più livelli di protezione non solo operando a livello di rete, (questa protezione aggiuntiva viene fornita sia che venga utilizzato in sostituzione che in combinazione con firewall hardware standard), ma anche fornendo funzionalità di protezione aggiuntive non supportate in genere dai firewall tradizionali, come i filtri applicazione. Non si desidera fornire la possibilità di utilizzare il metodo HTTP POST per uno specifico sito Web ospitato? Si desidera forzare la conformità RFC nei messaggi SMTP prima che raggiungano il server Exchange? Si desidera controllare i pacchetti HTTP SSL (Secure Sockets Layer) prima che vengano trasmessi in rete? ISA Server è in grado di gestire tutte queste attività e molto altro per assicurare che venga inoltrato alla rete interna o perimetrale solo traffico filtrato e pulito.

Le sessioni SSL rappresentano in qualche modo un problema per i firewall standard. Mentre passano attraverso il firewall, i pacchetti rimangono crittografati (il che indica che SSL funziona correttamente). Pertanto, se un'applicazione come OWA viene pubblicata attraverso un firewall hardware o software mediante SSL, l'unico tipo di controllo apprezzabile che può essere eseguito dal firewall standard è l'ispezione del contenuto dei pacchetti. Le semplici attività di apertura e inoltro delle porte possono lasciare esposta una significativa area della superficie di attacco. Poiché non viene eseguita alcuna ispezione effettiva al confine della rete, è possibile che vengano instradati verso la rete interna pacchetti non ispezionati e non autenticati.

ISA Server 2006 può fungere da endpoint SSL per i client HTTP, assicurando che solo il traffico autenticato raggiunga il server Exchange pubblicato. ISA Server supporta una funzionalità molto utile denominata bridging SSL. In genere, un pacchetto viene crittografato da un client che sta comunicando tramite una sessione SSL standard con ISA Server. Grazie alla funzionalità bridging SSL, ISA Server è in grado di terminare la crittografia SSL in modalità locale, ispezionare il pacchetto non crittografato, autenticare l'utente ad Active Directory (se necessario), crittografare nuovamente il pacchetto mediante SSL e passare il pacchetto crittografato al server Exchange appropriato (vedere la Figura 2). Utilizzando questa tecnica, bridging SSL consente di ridurre gli attacchi nascosti all'interno di una sessione SSL camuffati in maniera tale da sembrare nient'altro che BLOB crittografati di dati trasmessi a un firewall non compatibile con l'applicazione.

Figura 2** Una vista del traffico a livello di applicazione in ISA Server **(Fare clic sull'immagine per ingrandirla)

Il traffico preautenticato che raggiunge il server è un importante punto da tenere presente quando si parla di delega vincolata Kerberos. In un firewall standard, le porte vengono semplicemente inoltrate al server Exchange e lo stesso server front-end è responsabile per l'esecuzione delle attività di autenticazione per coloro che potrebbero rivelarsi utenti malintenzionati. Quando l'autenticazione è necessaria, ISA Server è in grado di contattare direttamente Active Directory ed effettuare la richiesta di credenziali per conto dell'utente. Se l'utente viene autenticato, ISA Server inoltrerà il messaggio al server front-end Exchange. Il server front-end non deve più eseguire l'autenticazione di richieste casuali di utenti sconosciuti e può essere utilizzato esclusivamente per inviare tramite proxy le richieste ai server back-end. ISA Server 2006 inoltre può utilizzare la delega vincolata Kerberos per consentire l'accesso basato sui certificati a tecnologie come Windows SharePoint Services ed Exchange ActiveSync.

Exchange Server 2003 includeva il supporto per l'autenticazione basata su Kerberos tra i server front-end e back-end per gli account di accesso OWA (per proteggere il traffico di questo client occorre utilizzare il protocollo IPsec). Exchange Server supporta inoltre l'autenticazione Kerberos per i server cassette postali cluster.

Attivazione dell'autenticazione basata su smart card

L'implementazione dell'autenticazione basata su smart card per OWA ha rappresentato una vera e propria sfida. Tuttavia, è stata sviluppata una soluzione basata sulla funzionalità di delega vincolata Kerberos, ora disponibile in ISA Server 2006. La soluzione consente a un utente di inviare le credenziali tramite un certificato per eseguire l'autenticazione a OWA. La delega vincolata Kerberos è un miglioramento che è stato accolto con maggiore entusiasmo rispetto al supporto della delega Kerberos in Windows® 2000, che prevedeva l'utilizzo della delega non vincolata. La funzione vincolata di Kerberos garantisce maggiore protezione e limita il potenziale rischio di attacchi sofisticati che fanno uso della rappresentazione.

Nello scenario abilitato all'utilizzo di smart card, ISA Server 2006 contatta Active Directory per eseguire l'autenticazione dell'utente in quanto l'utente non dispone di accesso instradabile a un centro distribuzione chiavi (KDC, Key Distribution Center) dalla rete esterna. ISA Server rinvia ad Active Directory il mapping tra certificato e utente per l'autenticazione dell'utente e acquisisce i rispettivi ticket Kerberos in base al nome dell'entità utente (UPN, User Principal Name). In questo caso, ISA Server fornisce la funzionalità di delega vincolata Kerberos a un server front-end Exchange tramite i servizi di proxy inverso e di filtro a livello di applicazione. Se la delega viene eseguita senza un proxy inverso, il maggiore rischio di exploit potrebbe influire sull'integrità della rete o del dominio Active Directory.

Exchange Server 2003 e Exchange Server 2007 supportano entrambi l'autenticazione di base e integrata. Per consentire il corretto funzionamento dell'autenticazione basata su smart card a OWA, è necessario tuttavia applicare un aggiornamento software a Exchange Server 2003. Per ulteriori informazioni, vedere l'articolo "Descrizione della nuova funzionalità di Exchange Server 2003 che supporta l'autenticazione basata s smart card a Outlook Web Access". È necessario disporre di un dominio che operi nella modalità funzionale nativa di Windows Server® 2003, tutti i server di Exchange Server 2003 coinvolti devono disporre di SP2 o versione successiva e occorre utilizzare un server ISA Server 2006 che funga da proxy inverso per il sito OWA.

Dopo aver installato l'aggiornamento software e configurato i server ISA ed Exchange, gli utenti possono eseguire l'autenticazione di una sessione OWA mediante l'uso di smart card. Nella Figura 3 viene illustrato il flusso degli eventi necessari per l'autenticazione basata su smart card. Un utente inizia aprendo il sito OWA in Internet Explorer® (1). In effetti, l'utente si connette a ISA Server e gli viene richiesto un certificato anziché un nome utente e una password per avviare la sessione OWA. Il certificato appropriato viene archiviato sulla smart card, per la quale l'utente necessita di un codice PIN.

Figura 3** Autenticazione di OWA con una smart card **(Fare clic sull'immagine per ingrandirla)

La convalida del certificato (2) viene gestita tramite un elenco di revoche di certificati (CRL) o una richiesta del protocollo di stato del certificato in linea (OCSP), in base alla configurazione di ISA Server e di altro software installato. ISA Server effettua una richiesta a un controller di dominio per verificare le credenziali dell'utente. Se la richiesta non riesce, ISA Server presenta una pagina di errore all'utente e nessuna richiesta perverrà al server front-end Exchange.

Dopo che le credenziali sono state verificate, viene generato il ticket Kerberos e la richiesta viene passata al server front-end Exchange mediante l'autenticazione integrata (3). Una volta ricevuta la richiesta, il server front-end Exchange convalida il ticket Kerberos e individua il server cassette postali back-end dell'utente (4).

Il server front-end richiede un ticket Kerberos per il server back-end appropriato tramite la delega vincolata Kerberos e invia tramite proxy la richiesta delle cassette postali al server back-end mediante l'autenticazione integrata (5). La richiesta viene elaborata dal server back-end (6) e i dati delle cassette postali vengono restituiti al server front-end Exchange (7). I dati HTML per la pagina OWA vengono passati a ISA Server (8), che quindi li trasmette di nuovo al computer client (9).

Configurazione dell'ambiente Exchange

L'articolo della Knowledge Base menzionato in precedenza descrive l'aggiornamento software per Exchange Server 2003 e contiene informazioni utili per l'esecuzione del processo di attivazione della delega vincolata Kerberos mediante ISA Server 2006 ed Exchange Server 2003.

L'azione principale che l'aggiornamento software consente è l'automatizzazione del processo di delega vincolata Kerberos dal server front-end Exchange ai rispettivi server back-end. L'aggiornamento non automatizzerà il processo di delega vincolata Kerberos da ISA Server al server front-end in quanto ISA Server non fa parte dell'organizzazione di Exchange. Questa delega dovrà essere attivata manualmente da ciascuna istanza di ISA Server a ciascun server front-end Exchange.

L'aggiornamento software aggiunge una nuova scheda al Gestore di sistema di Exchange (ESM, Exchange System Manager) che consente di designare un server front-end Exchange come KCD-FE (vedere la Figura 4), che consente a sua volta di inserire tale server nella scheda relativa alla delega dei rispettivi server back-end Exchange.

Figura 4** Attivazione della delega vincolata Kerberos **

Anche la nuova interfaccia utente consente di specificare nelle proprietà del gruppo amministrativo le credenziali da utilizzare per la compilazione dell'attributo msDS-AllowedToDelegateTo (A2D2), come illustrato nella Figura 5. Questo è l'attributo responsabile per la delega vincolata Kerberos.

Figura 5** Impostazione dell'account che controlla la delega **

Rispettando il principio del privilegio minimo, è possibile utilizzare un account utente standard e concedere a tale account l'autorità di delegare utenti e computer tramite un oggetto Criteri di gruppo. Dopo che gli è stata concessa questa autorizzazione elevata, l'account può essere utilizzato come account di servizio per automatizzare il processo di delega vincolata Kerberos per il rispettivo gruppo amministrativo.

Accertarsi di eseguire le operazioni appropriate per impedire che un utente malintenzionato possa compromettere l'account del servizio di delega vincolata Kerberos. Anche se l'account non è un amministratore di dominio, l'accesso a tale account potrebbe provocare attacchi sofisticati che possono sfruttare la delega Kerberos. Poiché l'account avrà la capacità di stabilire nuove associazioni Kerberos, è consigliabile utilizzarlo con cautela. Adottare le precauzioni necessarie per garantire la protezione e l'integrità di questo account: una password lunga e complessa, maggiore controllo, tecniche di disabilitazione dell'account e così via.

L'aggiornamento software Exchange consente inoltre di apportare una modifica molto importante all'interfaccia di ESM relativa all'autenticazione integrata. In precedenza, in Exchange Server 2003, quando un server veniva designato come server front-end, l'opzione per l'attivazione dell'autenticazione integrata di Windows per le directory virtuali HTTP (in Server virtuale HTTP) era disattivata (vedere la Figura 6).

Figura 6a** L'aggiornamento consente l'autenticazione integrata **

Figura 6b** L'aggiornamento consente l'autenticazione integrata **

Questo avveniva perché l'autenticazione integrata non era supportata sui server front-end Exchange a causa di problemi tecnici, come il fatto che i server proxy interrompevano le sessioni NTLM, gli utenti che utilizzavano l'autenticazione Kerberos necessitavano di una connessione ad Active Directory e gli utenti Internet in genere non facevano parte del dominio. Queste limitazioni sono state rimosse grazie all'aggiornamento descritto nell'articolo della Knowledge Base menzionato in precedenza. Con l'aggiornamento installato, è possibile accedere semplicemente alla directory virtuale e selezionare la casella per impostare l'autenticazione integrata di Windows come meccanismo per la verifica delle credenziali utente. Una volta selezionata questa casella, viene automaticamente impostato un attributo denominato msexchAuthenticationFlags nell'oggetto directory virtuale in Active Directory (è possibile visualizzarlo utilizzando lo snap-in Adsiedit.msc per Microsoft Management Console).

È possibile che gli utenti che controllano la posta tramite OWA conoscano il nome dei rispettivi server back-end Exchange e si connettono a tali server utilizzando l'autenticazione integrata dalla rete Intranet aziendale. La differenza nell'esperienza dell'utente con l'autenticazione integrata è rappresentata dal fatto che, poiché si è connessi alla rete, non viene richiesto un nome utente e una password in quanto Internet Explorer eseguirà automaticamente l'autenticazione dell'utente al sito Web. Questo rappresenta un enorme vantaggio per gli utenti connessi alla rete aziendale, ma gli utenti esterni e, in particolar modo gli utenti OWA, in genere non sono connessi a un dominio quando accedono dall'esterno della rete a un server front-end Exchange. Questo processo viene illustrato in dettaglio nell'articolo della Knowledge Base "Modalità di autenticazione dei client browser in IIS".

In Exchange Server, l'aggiornamento consente di compilare la scheda relativa alla delega per l'utilizzo dell'attributo A2D2 anziché dell'attributo SPN (Service Principal Name, nome dell'entità servizio) in Active Directory. Se si esamina l'oggetto computer di Exchange utilizzando Adsiedit.msc, si noteranno due attributi distinti: l'attributo A2D2, che corrisponde all'elenco delle deleghe vincolate Kerberos, e l'attributo SPN, che funge da punto di specifica dell'account e punto di individuazione del servizio Kerberos. Sebbene i due attributi interagiscano tra loro per consentire l'attivazione della delega vincolata Kerberos, occorre modificare solo l'attributo A2D2 tramite l'interfaccia grafica.

In Windows l'attributo HOST SPN integrato può essere utilizzato come alias per l'individuazione di altri servizi. Ne consegue che, per consentire il funzionamento della delega vincolata Kerberos per la delega dal server front-end Exchange al server back-end, non è necessario utilizzare setspn.exe. Sebbene sia possibile specificare in modo esplicito HTTP/Nomeserver nell'elenco di attributi SPN, questa soluzione lascia maggiore spazio a errori da parte dell'amministratore e non è necessaria per il funzionamento della delega vincolata Kerberos. La delega vincolata Kerberos prevede la ricerca dell'attributo A2D2 in Active Directory. Quando questo attributo non viene compilato (o viene compilato con il valore SPN errato), la delega vincolata Kerberos non funziona tra i rispettivi server. Su un cluster Exchange, tuttavia, per poter funzionare in modo corretto, l'attributo A2D2 del server front-end deve essere configurato in modo che faccia riferimento all'account del computer nodo cluster.

Come osservato in precedenza, un dominio Windows Server 2003 contenente i server Exchange 2003 deve operare nella modalità funzionale nativa di Windows Server 2003. La delega vincolata Kerberos non può essere utilizzata a meno che non si raggiunga tale livello di funzionalità del dominio. Se il dominio è ancora in modalità mista e si installa l'aggiornamento software di cui si è discusso in precedenza, la delega sembrerà funzionare correttamente ma le registrazioni SPN non riusciranno. La delega vincolata Kerberos è inoltre una funzione di dominio, non una funzione a livello di foresta. questo implica che per Exchange Server 2003, ISA Server e i server front-end e back-end Exchange devono essere membri dello stesso dominio (anche se gli utenti di domini differenti possono comunque eseguire l'autenticazione alla delega vincolata Kerberos). Un'istanza di ISA Server che non è membro di un dominio o che è membro di un dominio differente non funzionerà come parte di questa soluzione.

Configurazione del sito OWA

È consigliabile non utilizzare il servizio Amministratore di IIS per qualsiasi tipo di modifica di autenticazione a OWA. Anche se OWA viene eseguito su IIS e risponderà alle modifiche nella metabase come qualsiasi altro sito Web, Exchange introduce un certo grado di complessità con il processo Directory Services to Metabase (DS2MB). Il processo DS2MB replicherà le modifiche da Active Directory nella metabase di IIS con una procedura unidirezionale che sovrascriverà tutte le modifiche apportate direttamente a IIS. L'impatto di questo processo è che se un amministratore apporta una modifica direttamente alla metabase di IIS (come l'impostazione dell'autenticazione integrata), la soluzione sembrerà funzionare in modo corretto ma smetterà di funzionare non appena viene avviato il successivo ciclo di replica del processo DS2MB.

L'opzione per l'attivazione dell'autenticazione integrata di Windows per le directory virtuali HTTP è stata resa disponibile in ESM in quanto questa applicazione esegue direttamente le modifiche in Active Directory, il che determina la replica delle modifiche nella metabase di IIS. Tenere presente che, sebbene l'arresto del servizio Supervisore sistema determini l'arresto del processo DS2MB, consentendo di apportare modifiche alla metabase di IIS e impedendone la sovrascrittura, è consigliabile non eseguire questa operazione. Al successivo avvio di Supervisore sistema, questo servizio esegue il polling delle modifiche da Active Directory e la soluzione verrà disattivata automaticamente.

Nella scheda relativa alla delega sono contenute le opzioni per Utilizza solo Kerberos e Utilizza un qualsiasi protocollo di autenticazione. Basandosi sulla semplice logica, si dovrebbe selezionare Utilizza solo Kerberos in quanto la soluzione in questione utilizza la delega vincolata Kerberos; tuttavia, questa è una delle numerose situazioni IT in cui la logica comune non è applicabile. Al contrario, è consigliabile selezionare l'opzione Utilizza un qualsiasi protocollo di autenticazione (come illustrato nella Figura 7) in quanto la richiesta non perviene come richiesta Kerberos ma come richiesta HTTP con un certificato corrispondente mappato a un account Active Directory.

Figura 7** Correzione delle impostazioni di autenticazione per le smart card **

In questo caso, ISA Server richiede il certificato PKI dell'utente mediante SSL. Poiché la richiesta in arrivo non è un ticket Kerberos, è necessario eseguire una transizione per consentire il corretto funzionamento della delega vincolata Kerberos. Pertanto, l'impostazione dell'opzione Utilizza solo Kerberos interromperà la catena di comunicazione in ISA Server. Tenere presente, tuttavia, che l'opzione Utilizza solo Kerberos funziona per la delega dal server front-end Exchange al server back-end in quanto il server front-end prevede la ricezione solo dei ticket Kerberos inviati da ISA Server.

Le directory virtuali \Exchange e \Public sono le uniche posizioni che devono contenere informazioni sulle cartelle pubbliche e sugli utenti privati. La configurazione SSL in Exchange non rappresenta una novità per la delega vincolata Kerberos o l'autenticazione a due fattori, ma una conseguenza dell'attivazione SSL standard in OWA con credenziali di autenticazione di base. È consigliabile seguire i metodi documentati per attivare SSL in OWA, in quanto l'attivazione non corretta di SSL può determinare il malfunzionamento di OWA oltre a causare problemi con ESM.

Dettagli di configurazione aggiuntivi

Quando si implementa questa soluzione, è molto più semplice eseguire la distribuzione di ISA Server e di Exchange seguendo la procedura standard. Non inserire l'intera soluzione di delega vincolata Kerberos con tutte le impostazioni configurate (soprattutto se in precedenza ISA Server non era incluso nella distribuzione). Questo può complicare il processo di risoluzione dei problemi in caso di errore di un componente o nel caso in cui una fase del processo non dovesse riuscire. È molto più semplice distribuire ISA Server ed Exchange seguendo la procedura standard (con nome utente e password ma senza l'autenticazione basata su form), assicurarsi che l'installazione funzioni in modo corretto ed eseguire la transizione alla delega vincolata Kerberos e all'autenticazione basata sui certificati.

In genere, l'autenticazione basata su form non può essere utilizzata con un client OWA abilitato all'utilizzo di smart card. L'autenticazione basata su form indica che un utente ha un nome utente e una password da inviare tramite il modulo di Outlook standard. Tuttavia, con l'autenticazione a due fattori basata su smart card, l'utente avrà solo una smart card e non una password. Pertanto, l'autenticazione basata su form non prevede alcun metodo per accettare o inviare solo il certificato per l'autenticazione. L'utilizzo dell'autenticazione basata su form in qualsiasi punto della catena, ad esempio su un server front-end dietro ISA Server, impedirà il corretto funzionamento della configurazione del client OWA abilitato all'utilizzo di smart card. Se si attiva l'autenticazione basata su form, la directory virtuale di Exchange verrà impostata forzatamente sull'autenticazione di base e, di conseguenza, anche la metabase di IIS verrà impostata sull'autenticazione di base.

In uno scenario che prevede una combinazione di utenti che dispongono sia di nome utente/password che di smart card, è possibile attivare l'autenticazione fallback sul listener Web ISA e, quando un utente preme ESC dopo che gli sono state richieste le credenziali basate sui certificati, gli verranno richieste anche le credenziali standard basate su nome utente/password anche se l'autenticazione integrata è attivata dietro ISA Server sul server Exchange. Inoltre, ISA Server può causare il timeout della sessione SSL in modo analogo alle funzioni di autenticazione basata su form.

Conclusioni

Il supporto delle smart card per l'autenticazione a OWA rappresenta una funzionalità aggiuntiva di Exchange Server 2003 ed Exchange Server 2007 accolta con grande entusiasmo. Grazie alla possibilità di accedere a OWA mediante un certificato, gli utenti non devono più preoccuparsi di ricordare password lunghe e complesse e gli amministratori ora hanno a disposizione uno strumento efficace contro keystroke logger e altre forme di malware che possono individuare le credenziali utente da un sistema infetto. Per ulteriori informazioni, vedere le l'intestazione laterale "Risorse".

La corretta configurazione di ISA Server per l'autenticazione a due fattori con smart card consente di migliorare ulteriormente la protezione globale mediante l'applicazione di filtri a livello di applicazione sull'applicazione OWA pubblicata. Inoltre, ISA Server 2006 dispone del supporto integrato per la pubblicazione di Exchange Server 2003 e di Exchange Server 2007 tramite le semplici procedure guidate di pubblicazione e, pertanto, ISA Server resta un investimento ottimale per le organizzazioni che eseguono la transizione a Exchange Server 2007.

Risorse

• Come condividere i file rimossi dalla funzionalità di filtro "Safe HTML" in Outlook Web Access per Exchange Server 2003
• Risoluzione dei problemi relativi alla delega Kerberos
• Servizio di aggiornamento della metabase
• Autenticazione in ISA Server 2006
• Delega vincolata e transizione del protocollo Kerberos
• TechNet Webcast: implementazione dell'autenticazione a più fattori tramite smart card

Victor Akinnagbe ricopre il ruolo di Premier Field Engineer nella sede di Microsoft nell'area di Washington D.C. Il principale centro di interesse della sua attività è rappresentato da questioni relative a protezione, infrastruttura e messaggistica.

Ted Dressel ricopre il ruolo di consulente nella sede di Microsoft nell'area di Washington D.C. Il principale centro di interesse della sua attività è rappresentato da questioni relative a protezione e infrastruttura.

Jason Opdycke ricopre il ruolo di Premier Field Engineer nella sede di Microsoft nell'area di Charlotte. Le sue principali aree di interesse sono la protezione e l'infrastruttura.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.