Outlook Webzugriff

Der Outlook Webzugriff bietet jedem handelsüblichen, halbwegs aktuellen Browser einen Zugriff auf den kompletten Informationsspeicher von Exchange 2000 per HTML. Wenn der Browser moderne Techniken (DHTLM, WebDAV etc.) unterstützt, steigt die Funktionalität weiter an. Bei geeigneter Anbindung des Exchange Servers können Sie mit jedem Browser in der Welt auf ihr Postfach und andere Informationen im Speicher zugreifen. Lesen Sie auch die Hinweise auf MSXFAQ - Frontend Backend Konstellation.

Detailbeschreibungen je Version :

Zusätzlich hat Lee Derbyshire zwei weitere OWA-Zugriffe entwickelt (kostenpflichtig) die aber aufgrund der Funktionsweise hier herein passen und auf OWA für PDA beschrieben sind. Die Freeware OWANotify erlaubt ihnen sogar unter Windows ein kleines Taskicon, um ihren Posteingang zu überwachen.

OWA und Internet

Um Outlook Web Access aus dem Internet zu nutzen, müssen Sie natürlich OWA aus dem Internet erreichbar machen. Und es ist sicher nicht gut, einen Windows Server ganz schutzlost direkt mit einer offiziellen IP-Adresse an mit dem Internet zu verbinden. Auch wenn Windows Server und Exchange mit jeder Version immer sicherer wird, sollte ein gewisser Schutz entsprechend den Firmenanforderungen gewährleistet sein. Dazu zählt natürlich immer ein sicheres öfter geändertes Kennwort und eine zwingende Verschlüsselung per SSL. Auch eine Überwachung auf versuchte Einbrüche und Kennwort-Versuche sollte dazu gehören. Die eigentliche Anbindung trenne ich gerne in drei Stufen auf, von der natürlich die höchste Stufe erreicht werden sollte. Sie sollten zumindest die Risiken und Einschränkungen der schwächeren Ausbaustufen kennen.

Welche Absicherung Sie letztlich verwenden ist von ihren persönlichen Vorlieben und Sicherheitsanforderungen abhängig.

Funktionsweise

Der Zugriff auf den Informationsspeicher mit Exchange 2000 unterscheidet sich grundlegend von der Realisation mit Exchange 5.5. Im Gegensatz zu Exchange 5.5, wird hier der Zugriff nicht per ASP-Seiten realisiert, die nur bedingt skalierbar waren und relativ langsam funktionierten oder auch nicht funktionierten.

Der Outlook Webzugriff von Exchange 2000 wird durch eine ISAPI-DLL realisiert, die auf dem lokalen Webserver mit integriert wird. Die Funktion dieser Integration ist außerordentlich wichtig, da viele Programme (auch der Exchange Systemmanager) den Zugriff per HTTP z.B.: zur Verwaltung von Ordner verwenden.

OWA 2000 funktioniert nur direkt auf einem Exchange Server. Eine Trennung  wie bei OWA 5.5 ist hier nicht möglich. Aber nicht jeder möchte, dass der gleiche Rechner, welcher produktiv das firmeninterne System auf Basis von Exchange 2000 betreibt, auch über das Internet erreichbar ist oder extreme Verwendung des Webzugangs das Gesamtsystem ausbremst. Daher ist es möglich, auch den Outlook Webzugriff vom eigentlichen Exchange Server zu verschieben auf so genannte Frontendserver. Dies sind ebenso Exchange Server, die aber keinen eigenen Informationsspeicher betreiben. (Exchange Enterprise notwendig). Dann können mehrere dieser Frontendserver z.B. in einer DMZ (siehe Firewall) betrieben werden und so die Last verteilen und der Backendserver übernimmt nur noch die Speicherhaltung, eventuell abgesichert durch den Betrieb in einem Cluster.

Sichern und Installation

Die Installation ist sehr einfach, denn Sie haben keine Wahl, Exchange 2000 ohne OWA zu installieren. Auf dem Windows 2000 Server muss zur Installation von Exchange 2000 zwingend der NNTP-Dienst, der SMTP-Dienst und der Internet Information Server installiert sein. Selbst bei minimaler Installation wird dann OWA automatisch mit installiert.

Aber sie sollten ihren IIS-Server sichern. Ideal ist es, vor der Exchange Installation den IIS entsprechend zu sichern. Dazu gehören auch die aktuellen Hotfixe und Updates.

Viele dieser Aktionen werden mittlerweile von IISLOCKDOWN selbst durchgeführt. Interessant kann es auch sein, die Default Webseite komplett zu löschen oder auf eine interne Netzwerkkarte zu verbinden und die OWA-Seite zum Internet als eigene exklusive Webseite zu betreiben. Dann werden auch spätere Installation, die in der "Default Seite" Änderungen vornehmen nur intern exponiert

Konfiguration

Zu konfigurieren gibt es beim OWA2000 fast nichts. Im Gegensatz zum OWA 5.5 können sie keine ASP-Seiten mehr verändern. Allenfalls einige Icons können Sie gefahrlos ihrem eigenen Geschmack anpassen, um damit das Gesamtaussehen ihres OWA-Zugang etwas anzupassen.

Weitere Anpassungen können Sie gerne versuchen. Es empfiehlt sich immer eine Kopie des Originals zurückzuhalten und die Änderungen auf mehreren Browsern zu testen.

Webbasierte Administration

Seit Mai 2004 gibt es sogar eine webbasierte Administration für OWA

Erweiterte Nutzung

Eigentlich gibt es nicht viel hierzu zu sagen. erinnern sie sich immer daran, dass sie jedes Objekt, jede Ansicht, jeden Ordner direkt als URL adressieren können. Es steht ihnen nun frei, in ihrer eigenen Intranetseite, z.B. eine eigene Frameseite aufzusetzen, und in einem der Fenster einen passenden Ordner einzublenden.

Durch die direkte Authentifizierung über den IE gelten als Zugriffsrechte die gleichen Rechte, die der Anwender mit Outlook im LAN hat. Kniffliger wird es erst, wenn der lokale PC nicht der Domäne oder einer vertrauten Domäne angehört oder wie Windows 9x oder älter nichts von Domänen versteht. Dann muss der Anwender sich manuell anmelden.

Sie sollten aufpassen, wenn Sie später die IP-Adresse des Servers ändern oder weitere Webseiten installieren, damit der Zugriff auf die Virtuellen Verzeichnisse möglich bleibt. Ansonsten werden Sie auch mit der Administration ihre Probleme bekommen. OWA nutzt den Hostnamen samt Domäne, welche Sie mit übermitteln. Achten Sie daher darauf, dass beim Zugriff auf den einfachen Servernamen auch die virtuelle Webseite erreicht wird, in der die Exchange Verzeichnisse existieren. Wenn der Server über weitere IP-Adressen und Aliasnamen (CNAME) im DNS mehrere virtuelle Webseiten betreibt, dann sollte der eigentliche Hostname auf der Default Webseite verbleiben. So sollten nach jedem Schritt bei der IIS Konfiguration die Funktion von OWA aber auch des Exchange Systemmanagers im Hinblick auf die Verwaltung z.B. öffentlicher Ordner kontrollieren.

OWA und hohe Sicherheit

Immer wieder kommt die Frage, wie "sicher" OWA eigentlich ist. Gibt es High Security Konzepte für OWA? Wie sichern sich wirklich kritische Bereiche, z.B. Forschung und Entwicklung, Banken und andere.

Klar ist, dass hierbei zum einen das System selbst gesichert werden muss aber auch die Anmeldung zu betrachten ist. In vielen Umfeldern ist der Zugang mit Benutzername und Kennwort nicht ausreichend sicher. Solche Daten können Abgefangen oder veruntreut werden. Bei "hochsicheren" Umgebungen ist es daher hilfreich, mehr als nur Username/Kennwort zu machen.

Client Zertifikate sind aber auch kein idealer Weg, weil diese kaum jemand "mitnimmt" und auf Internetsystemen das nichts bringt. Da helfen dann auch keine USB-Keys etc. Hier ist dann RSA und andere gefragt, d.h. die kleinen Chipkarten/Dongles, die alle 20 Sekunden einen anderen "Einmalkennwort" generieren. Den kann man in die IIS Anmeldung mit einbeziehen, oder über den Reverse-Proxy vorschalten. das machte ich bei "kritischen" Kunden, d.h. der User geht per OWA auf "ihren" Server und die Checkpoint fängt den Zugriff ab und leitet den Anwender erst mal auf eine Anmeldeseite über den ACE Server weiter. Der User meldet sich also mit Username und Token an und erst dann lässt die Firewall diesen User auf ganz bestimmte Dienste zu.

Frontend/Backend ist kein Aspekt der Sicherheit, sondern eine Funktion, wenn man mehrere Backendserver hat und diese alle unter "einem" Namen veröffentlichen will. Es erlaubt einiges aber FE/BE ist nicht sicherer als ein BE alleine. Es sei denn man nutzt den FE und macht ihn sicherer durch weniger Dienste und einen zugestopften IIS, den Backend kann/will man ja vielleicht nicht wirklich "zustopfen"

Wie ist das mit Daten, die auf einem Client im Internetcafe zurückbleiben? Schreibt der IE lokal Daten die jemand anderes weiter verwenden könnte? Im Prinzip cachen Browser Daten, damit diese schneller wieder angezeigt werden. Speziell wenn z.B. Bilder mehrfach verwendet werden. Aber OWA liefert die Daten erst mal "non Cachable" aus und zudem sorgt SSL dafür, dass die Daten normal nicht gecached werden. Ich kann in meinem Cache keine Daten meines OWA-Zugiffs finden und ein Proxy beim Provider kann auch nicht viel Cachen, wenn ich SSL einsetzen. Dies ist natürlich sehr anzuraten. Sie sollten aber am Ende den Browser wirklich schließen oder anderweitig die Verbindung abbauen, damit auch die gecachte Anmeldung des Browsers nicht mehr greift und kein fremder Benutzer mit "ZURÜCK" wieder ihre Sitzung aufnimmt.

Damit ist mal eigentlich sehr sicher. Sicherheit ist aber ein Prozess, der permanent kontrolliert und angepasst werden muss. Dazu gehört auch die Überwachung des Zugriffs um Anomalien zu erkennen und stoppen zu können Ebenso müssen Sie natürlich ihre Anwender immer wieder informieren. OWA ist sicher, aber wenn ein Trojaner beim Anwender einfach den kompletten PC fernsteuert, dann ist auch dies kein sicheres System mehr.

OWA und NLBS

Folgender Microsoft Artikel bietet hinweise, wie Sie mehrere Outlook Web Access Server als Frontendserver unter einer IP-Adresse veröffentlichen und damit ein Failover erhalten.

"Der Microsoft Windows-Lastenausgleichsdienste (Windows Load Balancing Service, WLBS) ermöglicht das Ausgleichen von Serverlasten für eingehende Clientverbindungen. Microsoft Outlook Web Access (OWA) kann in Verbindung mit WLBS verwendet werden, um die Verarbeitung des Datenverkehrs von eingehenden Webclientverbindungen auf einem Microsoft Exchange Server-Computer zu verwalten.

Mehrsprachigkeit

Outlook Webzugriff 5.5, 2000 und 2003 sind von Hause aus mehrsprachig installiert. Die Filter-DLL im Webserver erkennt anhand der Sprache des Clients (der Browser), und schaltet dann die Sprache ein. Sie könne auf dem Client die Sprache im Browser ändern.

Sicherheit mit SSL

Der Zugang per OWA ist ein öffentliches Protokoll. HTTP ist ein Standard und ohne besondere Vorkehrungen "Klartext". Dies bedeutet, dass auch ihre Anmeldung im "Klartext" über die Leitung gesendet wird. Dies kann natürlich nicht ihr Ziel sein. Daher sollten Sie umgehend die Verschlüsselung per SSL auf dem Webserver aktivieren.

Der Einsatz von SSL löst auch das Problem mit vielen Proxy Servern. Da Proxy Server kein SSL cachen können (wäre ja sinnlos) wird es meist 1:1 durchgeschleust. Damit fallen all die Fehler nicht auf, bei denen ein Proxy die neuen Funktionen (WebDAV) nicht versteht.

Passwort ändern

Der OWA 2000 bringt im Gegensatz zum OWA von Exchange 5.5 keine eigenen Routinen mehr mit, um Kennworte zu ändern. Statt dessen baut OWA auf die Existenz der URL https://servername/IISADMPWD auf. Diese Skript sind bei der Installation von Windows 2000 Server auf dem Server vorhanden, aber nicht eingerichtet. Siehe IISADMPWD.

OWA 2007/2010 bringen schon eine eigene Funktion mit, um ein Kennwort zu ändern. Dies funktioniert aber nur, wenn Sie sich noch an OWA anmelden können. Wenn ihr Kennwort schon abgelaufen ist oder Sie das Kennwort bei der Erstanmeldung ändern müssen, dann benötigen Sie weiterhin IISADMPWD. Siehe auch

What you need to know about the OWA Change Password feature of Exchange Server 2007
http://msexchangeteam.com/archive/2008/12/09/450238.aspx

Fehler bei der Anmeldung

Oft scheint alles zu gehen, aber nur der Administrator kann OWA nutzen. Letztlich liegt das eher an Problemen mit der Anmeldung am OWA durch mangelnde Rechte oder falsche Konfiguration.

Als Standard kann sich ein Anwender am OWA2000 nur per NTLM-Autorisierung anmelden. Dummerweise geht die nicht durch Proxy Server hindurch und wird auch von Browsern wie NetScape oder Opera einfach nicht unterstützt. Schade, aber diese Browser unterstützen "Klartext" als Anmeldung. Daher ist diese Möglichkeit auf dem virtuellen Verzeichnis erst freizugeben. Denken Sie aber daran, bald auf SSL umzustellen, da dieses Kennwort ihr Domainkennwort ist und damit OWA als "schwaches Glied" in der Kette ihre Sicherheit reduzieren könnte.

Weiterhin gibt es ein generelles Problem wenn der Exchange 2000 Server zugleich auch Domain Controller ist. Durch die Sicherheitsrichtlinien ist festgelegt, dass sich Anwender nicht auf Domain Controllern anmelden dürfen. Soweit so gut aber es geht trotzdem meistens, nämlich dann, wenn der Anwender einen Internet Explorer 5 oder neuer verwendet und damit WebDAV zum Einsatz kommt. Dann meldet sich der Benutzer eigentlich gar nicht "interaktiv und lokal", sondern greift nur per WebDAV auf die Objekte zu.

Die Anmeldung "auf dem Server" passiert aber immer dann, wenn der Benutzer einen anderen Browser nutzt, weil dann OWA erkennt, dass WebDAV nicht genutzt werden kann und schaltet auf eine andere Steuerung um. Zur Nutzung dieser benötigt der Anwender aber entsprechende Rechte. Ob sie ihm diese geben wollen (er könnte ja dann auch am Server sich anmelden und die Rechte auf Freigaben umgeben) oder nicht, bleibt ihnen überlassen.

Fehler beim Bildaufbau

Meist sind die Fehler, die beim Einsatz des OWA2000 mir gemeldet werden, keine Exchange 200 Fehler, sondern in anderen Ursachen begründet. Die Hitliste führen hier natürlich die Namensauflösung an. Ebenso die Authentifizierung (NTLM oder Basic) und der Einsatz von Proxy Servern. Schalten Sie einfach den Proxy intern aus, wenn Sie den Exchange Server verwalten. Wenn die Administration oder Zugriff dann möglich ist, dann verhindert ihr Proxy oder eine entsprechende Einstellungen die Funktion. Häufige Fehler sind z.B.: dass der Proxy selbst andere DNS-Server (z.B. externe Systeme) nutzt und damit interne Systeme nicht auflösen kann.

Für den Zugriff von extern hilft das natürlich nicht weiter, da sie hier entweder einen Proxy brauchen um überhaupt an den Exchange Server zu kommen oder der Zugangsprovider (Mobilcom etc.) einfach alle Surfer-Daten zwangsweise auf einen Proxy umleiten.

Aber leider unterstützen nicht Proxyserver die HTTP-Protokollfunktionen (HTTP 1.1) oder blockieren diversen Anmeldeverfahren (NTLM). Dann bleibt nur der Weg SSL zu nutzen oder einen anderen Provider oder Port. Wenn Sie im LAN ohne Proxy auf OWA kommen, dann sollten Sie nicht weiter bei Exchange suchen, sondern sich in die Richtung Windows NT, TCP/IP, Namensauflösung, Firewall etc. bewegen.

Oftmals macht ihnen aber auch ihr Client einen Strich durch die Rechnung, wenn er den Zugriff auf den Exchange Server nicht als "Intranet" erkennt, sondern über den Proxy als "Internet" oder "unsicheres LAN" definiert. Dann verhindert der aktuelle IE5.5 gerne die Funktion einige JavaScript-Funktionen, welche über Fenstergrenzen hinweg greifen. Das bemerken Sie z.B. daran, dass die keine öffentlichen Ordner in der Navigation erreichen können. Fügen Sie in diesem Fall z.B. den Exchange Server in die Liste der vertrauenswürdigen Systeme hinzu und starten Sie dann den Internet Explorer neu, dann funktioniert der Zugriff. Das ist natürlich nur eine schnelle Abhilfe und keine firmenweite Lösung. Hier sollten Sie über Richtlinien und ein zentrales Management der Browser nachdenken.

Manchmal kann es aber auch einfach ein Problem der "Frontend/Backend-Konfiguration" sein, die Bereiche "drum herum" kommen überwiegend vom Frontend Server (z.B. alles aus ExchWeb), wären die Inhalte von Frontend beim Backend abgerufen werden. Kann hier des Frontend den Backend nicht richtig auflösen oder machen SSL oder Hostheader einen Strich durch die Rechnung, dann sehen Sie auch keine Inhalte.

Hierzu zählt auch, dass der Zugriff auf "/EXCHWEB" per Default "anonym" erfolgt. Wenn sich, warum auch immer, aber das Kennwort der IUSR-Kontos auf dem lokalen PC nicht mehr mit dem im IIS hinterlegten Kennwort übereinstimmt, dann ist der Effekt ebenfalls vorhanden, da der Client keine Javascripte und Icons laden kann.

Einfacher Test: Surfen sie auf

http://ihr.exchange.name/exchweb/img/form-find-animated.gif

Der Zugriff sollte ohne Anmeldung möglich sein und ihnen die animierte Lupe anzeigen. Ansonsten ist entweder ""anonymous" nicht aktiviert, die NTFS-Rechte auf dem Verzeichnis (z.B. C:\Programme\Exchsrvr\exchweb\img\form-find-animated.gif)verändert oder der lokale User "IUSR_servername" kann sich nicht anmelden.

showiispasswords.vbs.txt
VBScript zum Ausgehen der IIS-Kennworte in der Metabase. Diese können dann auf den lokalen Benutzern gesetzt werden

Eine kleinere Version des Skripts gibt es auch noch:

Option Explicit
Dim objIIS, strMessage
 
Set objIIS = GetObject ("IIS://localhost/w3svc")
WScript.Echo "anonymous credentials in the metabase are:"
WScript.Echo "AnonymousUserName = " & objIIS.Get("AnonymousUserName")
WScript.Echo "AnonymousUserPass = " & objIIS.Get("AnonymousUserPass")
Set objIIS = Nothing

Alternativ können Sie auch im IISLOG sehen, dass die Zugriffe auf /EXCHWEB/* fehlschlagen.

OWA mit SSL und Umleitung

Oftmals ist es zu aufwendig für Anwender die URL komplett einzugeben. Dann bietet sich ein Alias im Internet an, so dass der Zugriff z.B.: über http://owa.firma.de möglich ist. Dazu muss auf diesem Webserver dann eine Default-Seite liegen, die den Anwender direkt umleitet.

z.B. eine Datei mit folgendem Inhalt

<html>
<head>
<meta HTTP-EQUIV="Pragma" CONTENT="no-cache">
<meta HTTP-EQUIV="Expires" CONTENT="now">
<meta http-equiv="refresh" content="0; URL=/exchange">
<title>OWA Umleitung</title>
</head>
<body>
Moment bitte, Sie werden umgeleitet
</body>

Denkbar ist hier natürlich auch eine Umleitung auf HTTPS. Ähnliche Umleitungen sind aber auch mit dem IIS direkt konfigurierbar oder die 403.4-Fehlerseite (SSL-required) wird entsprechend zu einer Umleitung. Damit wird ein SSL-Zwang für den Anwender gar nicht groß sichtbar.

OWA2003 und SharePoint Team Services

Outlook Web Access ist im Prinzip sehr robust, aber beim Einsatz auf Windows 2003 Server sind Anpassungen notwendig, damit auch mit den mittlerweile verfügbaren Team Services die Funktion gewährleistet ist.

Auch wer den Microsoft Software Update Service (SUS) installiert, wird feststellen, dass SUS mit dem Programm IISLOCKDOWN und URLSCAN (IISLOCKD) einige Funktionen des IIS deaktiviert und damit Outlook Web Access außer Funktion setzt.

OWA Anpassungen

Microsoft Outlook Web Access kann in gewissen Grenzen an die eigenen Bedürfnisse und Layoutwünsche angepasst werden. Während OWA 5.5 fast nur aus ASP-Seiten besteht und damit fast in jeder Hinsicht angepasst werden kann, so besteht der OWA von Exchange 2000 und Exchange 2003 aus einem ISAPI-Filter, der nicht zu verändern ist und einigen Dateien, die im virtuellen Verzeichnis "ExchWev"  (meist auf Programme\Exchsrvr\Exchweb) liegen und angepasst werden kann. So lassen sich zumindest die Icons und die Farben (über Style Sheets, CSS) anpassen. Allerdings sollten Sie dabei einige Randbedingungen beachten

Einige weitere Hinweise zum Anpassen von OWA finden sie auf den jeweiligen Detailseiten:

OWA Erweiterungen durch Dritthersteller

Auch wenn OWA mit jeder neuen Version und Service Packs von Exchange immer leistungsfähiger und besser wird, so bleibt immer noch viel Platz für Dritthersteller, die OWA erweitern.

Keywords: OWA SSL