Mini-OWA

Alle Skripte sind Muster ohne jede Gewährleistung oder Funktionsgarantie. für Schäden bin ich nicht verantwortlich. Achten Sie auf Zeilenumbrüche bei der Übernahme.

Mittlerweile gibt es eine sehr viel leistunfähigere aus ASP.NET 2.0 basierende Version, die als Reverse Proxy die Navigation lädt, verändert und an den Client gibt. Diese ist aber aufgrund der komplexeren Installation und Konfiguration nicht zum Download verfügbar.

Exchange 5.5 erlaubte schon den Zugriff per Browser auf das Postfach (Siehe Outlook Webaccess Exchange 5.5) aber erst Exchange 2000 und noch mehr Exchange 2003 erlauben die direkte Erreichbarkeit von Inhalten im Speicher über einen Browser mit sprechenden URLs.

Nur die universeller Erreichbarkeit aller Inhalte ist für einige Firmen auch ein echtes Problem. Sehr oft werden in Ordnern mit eigenen Formularen und entsprechendem Code umfangreiche Anpassungen vorgenommen, die bei einem Zugriff per Browser umgangen und damit beschädigt werden können. Also muss es möglich sein, den Zugriff per Browser entsprechend zu kontrollieren oder anzupassen.

Bei Exchange 5.5 konnten Sie die ASP-Seiten anpassen, was aber auch sehr fehleranfällig war. Bei Exchange 2000 und 2003 sind der Anpassung jedoch Grenzen gesetzt, da die Funktion als ISAPI-Filter in einer DLL implementiert ist. Zwar it es über Schlüssel in der Registrierung möglich, OWA etwas anzupassen, aber damit wird im wesentlichen nur links in der Navigation das ein oder andere Feature ausgeblendet. Anwender, die die URL können, können weiterhin die Funktion nutzen. Dies kann z.B.: nur mit einer Firewall oder einem Filter wie MOD_Rewrite verhindert werden.

Auf der anderen Seite "gefällt" OWA vielleicht nicht jedermann und man möchte den Anwendern nicht nur per MOD_Rewrite den Zugriff auf einige Pfade verbieten, sondern auch die Oberfläche entsprechend anpassen. Und dazu habe ich mal ein "Mini-OWA" gestrickt, welches ganz einfach zeigt, was man heute in wenigen Stunden realisieren kann.

Aufgabenstellung

Nehmen wir mal an, ein Kunde möchte für seine Mitarbeiter einen "abgespeckten" Zugriff auf das Postfach erlauben aber keine weiteren Zusatzfunktionen von OWA. Dann kann man mit MOD_Rewrite die URLs sperren aber nicht die grafische Oberfläche anpassen. Also muss eine eigene Weboberfläche her, die die Links dem Anwender nett präsentiert und z.B. in einem anderen Fenster dann die Inhalte anzeigt.

Frisch ans Werk habe ich eine Frameseite entworfen, die ihrerseits zwei weitere Seiten nachlädt. Die rechte Seite enthält erst einmal nur eine Seite mit Bild während die linke Seite eine ASP-Seite lädt, die abhängig vom Benutzer nun die entsprechenden Links anbietet.

In der Frameseite sieht dies dann wie folgt aus:

Der Einsatz von ASP ist notwendig, da hier z.B.: "Posteingang" steht und diese Seite entsprechend dynamisch den Link auf http://exchangeserver/exchange/XXXXXX/Posteingang setzen muss, wobei XXXXXX durch den korrekten Text für dieses Postfach ersetzt werden muss. Dies sieht man auch am Link in der Fußzeile. Denkbar sind hier später natürlich noch viel weitergehende Anpassungen abhängig von Gruppenzugehörigkeiten.

Code

Das ganze steht und fällt natürlich mit dem Code in der ASP-Seite für das linke Framefenster. Im IIS muss natürlich konfiguriert sein, dass nur ein authentifizierter Zugriff (Basic mit SSL oder integriert) möglich ist. Dann läuft auch das ASP-Script mit den Credentials des Benutzers und kann auf dessen Informationen zugreifen.

Das Script wertet dazu den Anmeldenamen des aktuellen Benutzers aus.

strlogonUser = Request.ServerVariables("LOGON_User")

Und holt sich dann über das NameTranslation-Object daran den distinguished Name des Objekts. Darauf erfolgt ein LDAP-Bind um die Proxy Addressen auszulesen und daraus letztlich den URL-Bestandteil xxxx in http://servername/Exchange/xxxx/Posteingang zu ermitteln und in die Links zu schreiben.

Natürlich kann der linke Teil noch viel "hübscher" gemacht werden.

Aktuell scheint die Lösung nur mit dem Internet Explorer zu funktionieren. Ein Zugriff per Firefox ergibt warum auch immer ein "Permission denied" wenn das Script per "NameTranslation" versucht, den DN ausfindig zu machen.

Download und Installation

Ich stelle den Code hier einfach ohne weitere Beschreibungen bereit. Sie sollten entsprechende Kenntnisse in der Konfiguration des IIS und der Anpassung von ASP-Code haben. Eine Schritt für Schritt Anleitung habe ich nicht gebaut Dieses Beispiel soll demonstriere, wie man mit wenig eigenem Aufwand Lösungen schaffen kann.

miniowa.zip

Kopieren Sie nach dem Download die Dateien einfach in ein leeres Verzeichnis unter wwwroot oder binden Sie dieses im IIS als virtuelles Verzeichnis ein. Stellen Sie dann die Eigenschaften des Verzeichnisses so ein, dass die Ausführung von Scripts erlaubt ist und KEIN anonyme Anmeldung nicht möglich ist.

Beim IIS5 habe ich die Erfahrung gemacht, dass die Default Domain ein "\" sein muss, wenn sich Anwender mit dem UPN-Namen anmelden wollen:

Pflegen Sie in der menu.asp dann noch die beiden Konstanten für den Servernamen und die Default Domäne.

const OWASERVER = "http://srv01"
const strdefaultSMTPdomain = "msxfaq.de"

Der Servername wird zur BIldung der URL der Hyperlinks genutzt während die Domäne benötigt wird, um den OWA-Pfad anhand der Proxyadressen zu bestimmen (Siehe auch OWA URL)

Weiterentwicklung

  • Eine viel bessere Lösung zeigt z.B. Lee Derbyshire mit OWA für PDA auf, welches als ASP-Seite seinerseits die Inhalte per WinHTTP vom Exchange Server holt und entsprechend umgestaltet an den Client weiter gibt. Solch eine Lösung ist natürlich die Kür.
  • Aber man könnte analog einen Art "Reverse Proxy" konstruieren, welcher die Anfragen des Clients annimmt und analog zu einen Proxy von intern holt und die Daten entsprechend "anpasst", z.B. URLs umschreibt oder filtert. So könnte auch ein Eingriff auf der "rechten" Seite von Mini-OWA möglich werden.
  • Formbased Authentication
    Die seit Exchange 2003 verfügbare Anmeldung mittels Formular ist hier natürlich nicht implementiert. Wird Exchange 2003 mit FBA genutzt, dann erscheint beim ersten Klick auf einen Link im linken Fenster rechts eben die Formularanmeldung von Exchange. Folgeklicks funktionieren dann aber problemlos, da der Cookie erhalten bleibt. Aber technisch könnte auch noch diese Anmeldung integriert werden.
    Natürlich wäre auch eine eigene formularbasierte Vorschaltseite eine schöne Erweiterung

Denken Sie aber daran, dass dieses "MiniOWA" nur eine kleine Oberfläche zum vollwertigen OWA ist und ein Anwender natürlich auch diese Oberfläche umgehen und direkt OWA nutzen kann. Es ist (noch) kein Reverse Proxy, durch den alle Daten durchgeleitet werden, sondern nur eine Frameseite die links etwas intelligent ist.

Weitere Links