Configurare un proxy per Microsoft Exchange con Apache


Home Page | Commenti | Articoli | Faq | Documenti | Ricerca | Archivio | Storie dalla Sala Macchine | Contribuire | Login/Register

La sua missione e' di installare un server Exchange nella LAN aziendale ed avere l'interfaccia WEB (pomposamente chiamata Outlook Web Access) disponibile su Internet via https, senza dover installare il server direttamente nella DMZ e senza usare ISA Server che costa una paccata di soldi.

Non e' che sembra una cosa proprio impossibile.. almeno all'inizio...

Cio' che ho scoperto quasi subito e' che quella chiavica di Exchange ritorna al client (browser) solo ed unicamente URL assoluti. Cioe' del tipo http://indirizzoipdelserver/... cosa che non va' per niente bene se si vuole usare un proxy per connettersi al server.

La prima cosa da fare e' avere ben chiari tutti i nomi dei server coinvolti.

Stabiliamo quindi:
192.168.1.100 e' il server Exchange (LAN) chiamato exchange.mylan.loc
10.0.0.80 e' il proxy Apache (DMZ) chiamato proxy.mydomain.com ed accessibile da Internet con indirizzo x.y.z.k.

Il proxy sara' disponibile dall'esterno mediante un nome canonico (FQDN) del tipo webmail.mydomain.com. E' importante avere il nome ben chiaro e registrare il DNS, in modo che un ping webmail.mydomain.com venga risolto correttamente come x.y.z.k.

NOTA: I nomi e gli indirizzi IP qui' riportati sono, ovviamente, degli esempi, non usate sul serio webmail.mydomain.com per il vostro server, usate un nome reale ed i vostri indirizzi IP. Ricordatevi che se dovete registrare il nome nel DNS dovrete richiederlo a chi vi gestisce il DNS e la propagazione ci impieghera' un paio di giorni.

La configurazione di Exchange e' il primo passo, per avere HTTPS attivo su exchange e' necessario creare un certificato o creare una richiesta ed avere una Authority che firmi il certificato.

La cosa importantissima in questo caso e' che il common name del certificato deve essere webmail.mydomain.com. Questo nome e' quello che viene ritornato da Exchange al client per ogni pagina Web, quindi se il nome non e' quello giusto niente funzionera'.

Una volta che Exchange e' configurato in modo decente potete verificarne il funzionamento aggiungendo l'indirizzo IP interno del server ed il nome nel file C:\WINNT\System32\drivers\etc\hosts ed aprendo un browser su https://webmail.mydomain.com. Dovreste vedere la pagina di login di Exchange.

Sulla barra dell'indirizzo dovreste vedere qualche cosa del tipo https://webmail.mydomain.com/....url=https://webmail.mydomain.com

Se "webmail.mydomain.com" non compare due volte sulla barra ed invece compare qualche altra cosa (l'indirizzo IP del server per esempio), c'e' qualche problema nella configurazione di Exchange e dovrete risolverlo.

NON domandatemi come si crea/richiede un certificato per Exchange, leggete la documentazione disponibile sul sito Microsoft.

In Apache e' necessario avere sia HTTPS che il mod_proxy attivo.

Per configurare Apache per HTTPS e' necessario compilare o aggiungere il modulo mod_ssl. Anche qui' e' meglio se il certificato lo create con lo stesso nome canonico. In questo modo non ci saranno stranezze quando sara' passato al client remoto.

Per informazioni su come compilare/installare mod_ssl vedete la corrispondente documentazione di Apache.

mod_proxy non comporta grossi problemi.

La configurazione di Apache e' alquanto semplice: in httpd.conf basta individuare la parte relativa ad https ed aggiungere 3 righe per il proxy:

<VirtualHost _default_:443>
ServerName webmail.mydomain.com
ProxyPass               /       https://webmail.mydomain.com/
ProxyPassReverse        /       https://webmail.mydomain.com/
...altre configurazioni per SSL come da default...

Una volta fatto questo manca solo un dettaglio: aggiungere in /etc/hosts un riferimento a webmail.mydomain.com che risolva nell'indirizzo IP del server Exchange nella rete interna:

192.168.1.100	webmail.mydomain.com

Avviate Apache con il supporto SSL e verificate che, dal proxy Apache possiate fare un ping webmail.mydomain.com e ricevere una risposta dal server interno (192.168.1.100). Probabilmente dovrete configurare il vostro firewall per consentire l'HTTPS dal proxy al server.

A questo punto, se avete fatto tutto giusto dovreste potervi collegare al vostro proxy usando https://webmail.mydomain.com e vedere la pagina di login di Exchange.

Questo vi consente di leggere le e-mail tramite Web da Internet passando attraverso un Proxy e non "espondendo" direttamente il server.

Per quanto riguarda pero' l'invio e/o la ricezione della posta dovrete o consentire al server di inviare e-mail direttamente all'esterno o configurare un relay.

Dopo una serie di messaggi con Scott Lowe su alt.apache.configuration, Scott se ne' uscito con una soluzione alternativa, che ha il vantaggio di non richiedere https su Exchange stesso.

<VirtualHost *:443>
    ServerAdmin webmaster@domain.com
    ServerName webmail.domain.com
    RequestHeader set Front-End-Https "On"
    ProxyRequests Off
    ProxyPreserveHost On
    SSLEngine On
    SSLRequireSSL
    ...altre direttive SSL...

    <Location /exchange>
        ProxyPass http://192.168.1.100/exchange
        ProxyPassReverse http://192.168.1.100/exchange
    </Location>

    <Location /exchweb>
        ProxyPass http://192.168.1.100/exchweb
        ProxyPassReverse http://192.168.1.100/exchweb
    </Location>

    <Location /public>
        ProxyPass http://192.168.1.100/public
        ProxyPassReverse http://192.168.1.100/public
   </Location>

</VirtualHost>

Come si vede si utilizzano 3 "location" che redirigono sulle tre 'directories' di Exchange, senza uno specifico 'virtualhost' che redirige tutto. Sul server Exchange e' necessario aggiungere una linea nell'HOSTS file per associare webmail.domain.com con l'ip del server Exchange stesso.

La direttiva RequestHeader e' la chiave del problema, questa istruisce Exchange ad usare 'https:' invece di 'http' in ogni link delle sue pagine. La ProxyPreserveHost consente di sostituire il FQDN del proxy con quello del server Exchange.

Nota: non ho provato questa soluzione io stesso, quindi se non funziona lamentatevi con Scott e non con me.

Gabriele di Geronimo mi segnala questo problema:

Molto semplicemente internet Explorer al momento di autenticare l'utente sull'OWA chiede effettivamente il nome utente e la password ma appena dai l'OK ti risponde con un errore 404 di page not found o con internal server error (NB questo problema non si presenta invece con altri browser non Microsoft maledetto zio Bill!!!).

Cmq sia ravanando nel proxy e nel server exchange pare che il problema sia stranamente l' opzione di autenticazione integrata Windows su IIS lato server a livello della directory virtuale exchange, disabilitandola infatti IE decide che puo' entrare nell'OWA senza problemi passando attraverso apache.

Ora dato che apache non restituisce problemi al momento della connessione del client e che anche IIS non registra niente di strano esattamente non ho molte idee sul perche' con IE (e solo con IE) si presenti il problema, io ci sono arrivato solo per deduzione dato che sulla home page in ssl ci arrivavo ma quando cercavo di fare il login IE mi spernacchiava allegramente in faccia.


I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

Nessun messaggio this document does not accept new posts

Precedente Successivo

Davide Bianchi, lavora come Unix/Linux System Administrator presso una societa' di "sicurezza informatica" (aka: $networkgestapo) di Haarlem. Contatti: mail: davide AT onlyforfun.net , Jabber: davideyeahsure AT gmail.com,

Volete contribuire? Leggete come!.
 
 

Il presente sito e' frutto del sudore della mia fronte (e delle mie dita), se siete interessati a ripubblicare uno degli articoli, documenti o qualunque altra cosa presente in questo sito per cortesia datemene comunicazione (o all'autore dell'articolo se non sono io), cosi' il giorno che faccio delle aggiunte potro' avvisarvi e magari mandarvi il testo aggiornato.


Questo sito era composto con VIM, ora e' composto con VIM ed il famosissimo CMS FdT.

Questo sito non e' ottimizzato per la visione con nessun browser particolare, ne' richiede l'uso di font particolari o risoluzioni speciali. Siete liberi di vederlo come vi pare e piace, o come disse qualcuno: "Finalmente uno dei POCHI siti che ancora funzionano con IE5 dentro Windows 3.1".

Web Interoperability Pleadge Support This Project
Powered By Gort