Kommunikation

Anmeldung bei Outlook Web Access mit Smartcards

Victor Akinnagbe and Ted Dressel and Jason Opdycke

Kurz zusammengefasst:

• Zweistufige Authentifizierung
• Eingeschränkte Kerberos-Delegierung
• ISA Server- und Exchange-Konfiguration

Mobile Mitarbeiter stellen für IT-Unternehmen eine außergewöhnliche Sicherheitsherausforderung dar. Remotebenutzer benötigen sicheren Zugriff auf Daten und Dienste wie z. B. E-Mail. Die bedauerliche Realität ist jedoch, dass zu den

schwächsten Gliedern in der Sicherheitskette unsichere Kennwörter, Malware (z. B. Protokollierung der Tastatureingabe) und Viren auf den Remotecomputern gehören, die auf die internen Ressourcen Ihrer Organisation zugreifen.

Eine Möglichkeit, die Sicherheit in dieser mobilen Umgebung zu erhöhen, besteht in der Beseitigung eines dieser schwächsten Glieder: der Kennwörter (obwohl der Gedanke, den Zugriff auf ein Konto ohne Authentifizierungskennwort zu ermöglichen, beunruhigend erscheinen mag). Ein Hauptverfahren zur Beseitigung der Probleme im Zusammenhang mit Kennwörtern ist die zweistufige Authentifizierung, manchmal auch mehrstufige Authentifizierung genannt. Statt sich für den Zugriff auf eine einzige Methode, also ein Kennwort zu verlassen, setzt die zweistufige Authentifizierung die Verwendung zusätzlicher Authentifizierungsmethoden durch, einschließlich einer Kombination aus Benutzernamen und Kennwort, eines physischen Geräts wie eine Smartcard oder einer biometrischen Kennung wie ein Fingerabdruck.

Für Remotebenutzer müssen Sie in der Regel die Firewall ein wenig öffnen, um den Remotezugriff auf das Unternehmensnetzwerk zu ermöglichen. Eine Standardfirewall bietet grundlegende Risikominderung, indem sie auf Netzwerkebene das interne und das externe Netzwerk voneinander trennt (siehe Abbildung 1). Für zusätzliche Sicherheit werden Ports einfach gesperrt, und wenn Kommunikation mit einem Gerät auf dem internen Netzwerk erforderlich ist, werden die Ports dann zum richtigen Ort weitergeleitet. Diese Verfahren bieten auf Netzwerkebene beträchtlichen Schutz. Inzwischen aber sind mehrere Schichten von Netzwerksicherheit notwendig, da die Angriffe immer raffinierter werden.

Abbildung 1** Standardfirewall mit blockierten oder weitergeleiteten Ports **(Klicken Sie zum Vergrößern auf das Bild)

Da die von mobilen Mitarbeitern am häufigsten verwendeten Unternehmensdienste wohl E-Mail und Messaging sind, ist es wichtiger denn je, dass Sie Ihre Exchange-Infrastruktur sicher konfigurieren. Eine Möglichkeit, mobilen Mitarbeitern sichere Dienste bereitzustellen, ist es, Benutzern den Zugriff auf E-Mails über Outlook® Web Access (OWA) zu ermöglichen. Ein weiterer entscheidender Schritt besteht in der Bereitstellung einer sichereren zweistufigen Authentifizierung für OWA über Smartcards. In diesem Artikel werden die Konfigurations- und Setupprobleme näher beleuchtet, über die Sie bei einer Bereitstellung von smartcardaktiviertem OWA informiert sein sollten.

Besser als eine Firewall

Durch Verwendung von Microsoft® Internet Security and Acceleration (ISA) Server 2006 auf Ihrem Netzwerk lässt sich das sichere Öffnen des Netzwerks für Remotebenutzer vereinfachen. ISA Server 2006 umfasst sicherheitserhöhende Features wie smartcardaktivierte virtuelle private Netzwerke (Virtual Private Network, VPN), LDAP (Lightweight Directory Access Protocol)-Authentifizierung via Active Directory® und eingeschränkte Kerberos-Delegierung. ISA Server unterscheidet sich vielleicht etwas von einer üblichen Firewall. Es werden nämlich mehrere Sicherheitsebenen bereitgestellt, da nicht nur auf Netzwerkebene gearbeitet wird (anstelle von Standardfirewallhardware oder in Verbindung mit dieser), sondern auch zusätzliche Sicherheitsfeatures bereitgestellt werden, die in der Regel in herkömmlichen Firewalls nicht unterstützt werden, z. B. Anwendungsfilter. Sie wollen nicht, dass jemand die HTTP POST-Methode zu einer bestimmten gehosteten Website verwendet? Sie möchten RFC-Konformität von SMTP-Nachrichten erzwingen, bevor diese Ihren Exchange-Server erreichen? Sie möchten verschlüsselte SSL (Secure Sockets Layer)-HTTP-Pakete prüfen, bevor sie ins Netzwerk gelangen? ISA Server kann alle diese Aufgaben und vieles mehr bewältigen, um sicherzustellen, dass nur sauberer, gefilterter Datenverkehr zu Ihrer DMZ oder Ihrem internen Netzwerk weitergeleitet wird.

SSL-Sitzungen stellen für Standardfirewalls ein gewisses Problem dar. Wenn Pakete die Firewall passieren, bleiben sie verschlüsselt, was bedeutet, dass SSL ordnungsgemäß funktioniert. Wenn also eine Anwendung wie OWA mithilfe von SSL durch eine Hardware- oder Softwarefirewall veröffentlicht wird, gibt es außer einer statusbehafteten Paketprüfung wirklich keinerlei sinnvolle Prüfung, die von der Standardfirewall durchgeführt werden kann. Bei bloßem Öffnen und Weiterleiten von Ports kann Angreifern eine große Angriffsfläche zugänglich gemacht werden. Da am Rand des Netzwerks keine wirkliche Prüfung erfolgt, könnten ungeprüfte und nicht authentifizierte Pakete in das interne Netzwerk weitergeleitet werden.

ISA Server 2006 kann als SSL-Endpunkt für HTTP-Clients fungieren und sicherstellen, dass nur authentifizierter Datenverkehr den veröffentlichten Exchange-Server erreicht. ISA Server unterstützt ein nützliches Feature namens „SSL-Bridging“. In der Regel wird ein Paket von einem Client verschlüsselt, der über eine Standard-SSL-Sitzung mit ISA Server kommuniziert. Mit SSL-Bridging kann ISA Server die SSL-Verschlüsselung lokal aufheben, das jetzt unverschlüsselte Paket prüfen, den Benutzer ggf. via Active Directory authentifizieren, das Paket mithilfe von SSL wieder verschlüsseln und das verschlüsselte Paket zum entsprechenden Exchange-Server weiterleiten (siehe Abbildung 2). Mithilfe dieses Verfahrens reduziert SSL-Bridging Angriffe, die in einer SSL-Sitzung versteckt sind und die einer nicht anwendungsorientierten Firewall nur wie verschlüsselte Daten-BLOBs erscheinen würden.

Abbildung 2** ISA Server sichtet den Datenverkehr auf Anwendungsebene. **(Klicken Sie zum Vergrößern auf das Bild)

Vorauthentifizierter Datenverkehr, der den Server erreicht, ist im Zusammenhang mit eingeschränkter Kerberos-Delegierung ein wichtiger Punkt. In einer Standardfirewall werden Ports einfach zum Exchange-Server weitergeleitet, und der Front-End-Server ist selbst für die Durchführung von Authentifizierungsaufgaben gegenüber möglicherweise böswilligen Benutzern verantwortlich. Wenn Authentifizierung erforderlich ist, kann sich ISA Server direkt an Active Directory wenden und die Anmeldeinformationen im Namen des Benutzers anfordern. Wenn der Benutzer erfolgreich authentifiziert ist, leitet ISA Server die Nachricht zum Exchange-Front-End-Server weiter. Der Front-End-Server muss keine zufälligen, unbekannten Benutzeranforderungen mehr authentifizieren und kann ausschließlich zum Senden von Proxyanforderungen zu den Back-End-Servern verwendet werden. ISA Server 2006 kann außerdem eingeschränkte Kerberos-Delegierung verwenden, um zertifikatbasierten Zugriff auf Technologien wie Windows SharePoint Services und Exchange ActiveSync zu ermöglichen.

In Exchange Server 2003 war die Unterstützung für Kerberos-basierte Authentifizierung zwischen Front-End- und Back-End-Servern für Anmeldungen bei OWA enthalten. (Sie verwenden doch sicher IPSec, um den Clientdatenverkehr zu schützen?) Exchange Server unterstützt auch die Kerberos-Authentifizierung gegenüber Postfachclusterservern.

Aktivieren der Smartcardauthentifizierung

Es war eine Herausforderung, smartcardbasierte Authentifizierung für OWA zu implementieren. Es wurde jedoch auf Grundlage des jetzt in ISA Server 2006 verfügbaren Features der eingeschränkten Kerberos-Delegierung eine Lösung entwickelt. Die Lösung ermöglicht es einem Benutzer, Anmeldeinformationen über ein Zertifikat zu übermitteln, um sich erfolgreich bei OWA zu authentifizieren. Eingeschränkte Kerberos-Delegierung bringt eine willkommene Verbesserung gegenüber der Unterstützung von Kerberos-Delegierung in Windows® 2000, die uneingeschränkte Delegierung verwendete. Die eingeschränkte Funktion von Kerberos ist sicherer und begrenzt das potenzielle Risiko durch raffinierte Angriffe mithilfe eines Identitätswechsels.

Im smartcardaktivierten Szenario wendet sich ISA Server 2006 an Active Directory, um den Benutzer zu authentifizieren, da der Benutzer vom externen Netzwerk aus keinen routbaren Zugriff auf ein Schlüsselverteilungscenter (Key Distribution Center, KDC) hat. ISA Server verweist auf die Zuordnung zwischen Zertifikat und Benutzer in Active Directory, um den Benutzer zu authentifizieren, und holt dann auf Grundlage des Benutzerprinzipalnamens (User Principal Name, UPN) die entsprechenden Kerberos-Tickets ein. In diesem Fall stellt ISA Server die Funktionalität der eingeschränkten Kerberos-Delegierung über Filterungsdienste auf Anwendungsebene und Reverseproxydienste an einen Exchange-Front-End-Server bereit. Wenn eine Delegierung ohne Reverseproxy versucht wird, könnte die erhöhte Gefahr von Sicherheitslücken die Integrität des Netzwerks oder der Active Directory-Domäne beeinträchtigen.

Sowohl Exchange Server 2003 als auch Exchange Server 2007 ermöglichen Standard- und integrierte Authentifizierung. Sie müssen jedoch eine Softwareaktualisierung von Exchange Server 2003 bereitstellen, damit die smartcardbasierte Authentifizierung gegenüber OWA funktioniert. (Weitere Informationen finden Sie im Artikel Beschreibung des neuen Features in Exchange Server 2003, das Smartcardauthentifizierung bei Outlook Web Access unterstützt.) Sie müssen eine Domäne im einheitlichen Funktionsmodus von Windows Server® 2003 besitzen, auf allen beteiligten Exchange Server 2003-Servern muss SP2 oder höher installiert sein, und Sie benötigen einen ISA Server 2006-Server, der als Reverseproxy für die OWA-Site fungiert.

Nach der Installation des Softwareupdates und der Konfiguration der ISA- und Exchange-Server können Benutzer eine OWA-Sitzung mithilfe von Smartcards authentifizieren. Abbildung 3 zeigt den Ereignisablauf, der für die Smartcardauthentifizierung erforderlich ist. Ein Benutzer beginnt durch Öffnen der OWA-Site in Internet Explorer® (1). Tatsächlich stellt der Benutzer eine Verbindung zu ISA Server her und wird zur Eingabe eines Zertifikats anstelle eines Benutzernamens und Kennworts aufgefordert, um die OWA-Sitzung zu beginnen. Das entsprechende Zertifikat ist auf der Smartcard gespeichert, für die der Benutzer eine PIN braucht.

Abbildung 3** Authentifizieren von OWA mit einer Smartcard **(Klicken Sie zum Vergrößern auf das Bild)

Die Zertifikatsüberprüfung (2) erfolgt je nach Konfiguration von ISA Server und anderer installierter Software über eine Anforderung der Zertifikatssperrliste (Certificate Revocation List, CRL) oder des OCSP (Online Certificate Status-Protokoll). ISA Server sendet an einen Domänencontroller (DC) die Anforderung, die Anmeldeinformationen des Benutzers zu überprüfen. Wenn die Anforderung fehlschlägt, stellt ISA Server dem Benutzer eine Fehlerseite bereit, und es gelangt keine Anforderung zum Exchange-Front-End-Server.

Nach Überprüfung der Anmeldeinformationen wird das Kerberos-Ticket generiert und die Anforderung mithilfe integrierter Authentifizierung zum Exchange-Front-End-Server weitergeleitet (3). Wenn der Exchange-Front-End-Server die Anforderung erhält, überprüft er das Kerberos-Ticket und sucht den Back-End-Postfachserver des Benutzers (4).

Der Front-End-Server fordert ein Kerberos-Ticket für den entsprechenden Back-End-Server über eingeschränkte Kerberos-Delegierung an und übergibt die Postfachanforderung mithilfe integrierter Authentifizierung an den Back-End-Server (5). Die Anforderung wird vom Back-End-Server bearbeitet (6) und die Postfachdaten zum Exchange-Front-End-Server zurückgegeben (7). Die HTML-Daten für die OWA-Seite werden dem ISA-Server (8) übergeben, der sie dann an den Clientcomputer (9) zurückgibt.

Konfigurieren der Exchange-Umgebung

Der bereits erwähnte Knowledge Base-Artikel beschreibt die Softwareaktualisierung für Exchange Server 2003 und enthält Anleitungen für den Prozess, mit dem Sie eingeschränkte Kerberos-Delegierung unter Verwendung von ISA Server 2006 und Exchange Server 2003 aktivieren.

Hauptsächlich wird durch das Softwareupdate die Automatisierung des Prozesses der eingeschränkten Kerberos-Delegierung vom Exchange-Front-End-Server zu den jeweiligen Back-End-Servern aktiviert. Durch das Update wird der Prozess der eingeschränkten Kerberos-Delegierung von ISA Server zum Front-End-Server nicht automatisiert, da ISA Server nicht Teil der Exchange-Organisation ist. Diese Delegierung muss manuell von jeder ISA Server-Instanz aus bei jedem Exchange-Front-End-Server aktiviert werden.

Das Softwareupdate fügt im Exchange-System-Manager (ESM) eine neue Registerkarte hinzu, mit der Sie einen Exchange-Front-End-Server als KCD-FE bestimmen können (siehe Abbildung 4), wodurch wiederum ermöglicht wird, dass dieser Server in der Registerkarte „Delegierung“ der jeweiligen Exchange-Back-End-Server aufgefüllt wird.

Abbildung 4** Aktivieren der eingeschränkten Kerberos-Delegierung **

Mit dieser neuen Benutzeroberfläche können Sie in den Eigenschaften der Administratorgruppe angeben, welche Anmeldeinformationen beim Auffüllen des msDS-AllowedToDelegateTo-Attributs (A2D2) zu verwenden sind, wie in Abbildung 5 gezeigt. Dies ist das Attribut, das für die eingeschränkte Kerberos-Delegierung verantwortlich ist.

Abbildung 5** Einstellung des Kontos, das die Delegierung steuert **

Entsprechend dem Prinzip der geringsten Rechte können Sie ein Standardbenutzerkonto verwenden und es befähigen, Benutzer und Computer über ein Gruppenrichtlinienobjekt (Group Policy Object, GPO) zu delegieren. Wenn das Konto mit dieser erweiterten Berechtigung ausgestattet ist, kann es als Dienstkonto verwendet werden, um den Prozess der eingeschränkten Kerberos-Delegierung für die jeweilige Administratorgruppe zu automatisieren.

Vergewissern Sie sich, dass Sie die richtigen Schritte ausführen, damit ein böswilliger Benutzer das Dienstkonto der eingeschränkten Kerberos-Delegierung auf keinen Fall gefährden kann. Selbst wenn das Konto kein Domänenadministrator ist, könnte der Zugriff darauf durch Ausnutzung der Kerberos-Delegierung zu raffinierten Angriffen führen. Da über das Konto die Fähigkeit erlangt wird, neue Kerberos-Zuordnungen einzurichten, muss es mit Vorsicht verwendet werden. Ergreifen Sie die notwendigen Vorsichtsmaßnahmen, um die Sicherheit und Integrität dieses Kontos zu gewährleisten: ein langes, komplexes Kennwort, verstärkte Überwachung, Verfahren zur Kontodeaktivierung und so weiter.

Das Exchange-Softwareupdate führt auch zu einer sehr wichtigen Änderung bei der ESM-Schnittstelle hinsichtlich der integrierten Authentifizierung. Früher wurde in Exchange Server 2003 bei der Festlegung eines Servers als Front-End-Server die Option zum Aktivieren der Integrierten Windows-Authentifizierung für virtuelle HTTP-Verzeichnisse (unter HTTP Virtual Server) abgeblendet dargestellt (siehe Abbildung 6).

Abbildung 6a** Das Update aktiviert die integrierte Authentifizierung **

Abbildung 6b** Das Update aktiviert die integrierte Authentifizierung **

Dies war der Fall, weil die integrierte Authentifizierung auf Exchange-Front-End-Servern wegen technischer Probleme nicht unterstützt wurde, z. B. weil diese Proxyserver NTLM-Sitzungen unterbrachen, weil Benutzer, die die Kerberos-Authentifizierung verwendeten, eine Verbindung zu Active Directory brauchten, und weil Internetbenutzer normalerweise nicht zu einer Domäne gehörten. Das im oben genannten Knowledge Base-Artikel beschriebene Update beseitigt diese Einschränkungen. Nach Installieren des Updates können Sie einfach zum virtuellen Verzeichnis wechseln und als Mechanismus zur Überprüfung der Anmeldeinformationen des Benutzers das Feld für die integrierte Windows-Authentifizierung markieren. Wenn dieses Feld markiert ist, legt es für das virtuelle Verzeichnisobjekt in Active Directory ein Attribut namens „msexchAuthenticationFlags“ fest. (Dieses ist über das Adsiedit.msc-Snap-In für Microsoft Management Console sichtbar.)

Benutzer, die E-Mail über OWA überprüfen, kennen möglicherweise den Namen ihrer Exchange-Back-End-Server und können mithilfe integrierter Authentifizierung eine Verbindung zu ihnen herstellen, während sie sich im Unternehmensintranet befinden. Der Unterschied in der Benutzerfreundlichkeit besteht bei integrierter Authentifizierung darin, dass Sie beim Netzwerk angemeldet sind und daher nicht zur Eingabe eines Benutzernamens und Kennworts aufgefordert werden, weil Internet Explorer Sie automatisch bei der Website authentifiziert. Das ist nützlich für Benutzer im Unternehmensnetzwerk, aber externe Benutzer – und OWA-Benutzer sind in der Regel eher extern – sind gewöhnlich nicht bei einer Domäne angemeldet, wenn sie von außerhalb des Netzwerks auf einen Exchange Front-End-Server zugreifen. (Dieser Prozess wird ausführlich im Knowledge Base-Artikel zum Authentifizieren von Browserclients durch IIS erläutert.)

In Exchange Server füllt das Update die Registerkarte „Delegierung“ so auf, dass in Active Directory das A2D2-Attribut anstelle des SPN-Attributs (Service Principal Name, Dienstprinzipalname) verwendet wird. Wenn Sie sich mithilfe von Adsiedit.msc das Exchange-Computerobjekt ansehen, erkennen Sie zwei verschiedene Attribute: Das A2D2-Attribut, das die Liste der eingeschränkten Kerberos-Delegierung ist, und das SPN-Attribut, das als Kerberos-Locator und Spezifikationspunkt für das Konto dient. Es trifft zwar zu, dass beide Attribute zusammenwirken, um die eingeschränkte Kerberos-Delegierung zu ermöglichen, aber Sie dürfen über die grafische Oberfläche nur das A2D2-Attribut verändern.

Windows kann den integrierten HOST-SPN als Alias verwenden, um andere Dienste zu suchen. Es ist also nicht erforderlich, setspn.exe zu verwenden, damit die eingeschränkte Kerberos-Delegierung für die Delegierung von Exchange-Front-End zu -Back-End funktioniert. (Obwohl die explizite Angabe von HTTP/Servername in der SPN-Attributliste mit dieser Lösung funktioniert, verursacht sie für den Administrator ein höheres Fehlerrisiko und ist für das Funktionieren der eingeschränkten Kerberos-Delegierung nicht erforderlich.) Die eingeschränkte Kerberos-Delegierung sucht das A2D2-Attribut in Active Directory. Wenn dieses Attribut nicht (oder mit dem falschen SPN-Wert) aufgefüllt ist, funktioniert die eingeschränkte Kerberos-Delegierung zwischen den jeweiligen Servern nicht. Auf einem Exchange-Cluster jedoch muss das A2D2-Attribut vom Front-End-Server nur auf das Computerkonto des Clusterknotens verweisen, um ordnungsgemäß zu funktionieren.

Wie bereits erwähnt, muss eine Windows Server 2003-Domäne, die die Exchange 2003-Server enthält, sich im einheitlichen Funktionsmodus von Windows Server 2003 befinden. Die eingeschränkte Kerberos-Delegierung kann erst verwendet werden, wenn diese Stufe der Domänenfunktionalität vorhanden ist. Wenn sich Ihre Domäne nach wie vor im gemischten Modus befindet und Sie das bereits erörterte Softwareupdate installieren, scheint es zu funktionieren. Die SPN-Registrierungen schlagen jedoch in Wirklichkeit fehl. Weiterhin ist die eingeschränkte Kerberos-Delegierung eine Domänenfunktion, keine Funktion auf Gesamtstrukturebene. Das bedeutet, dass Exchange Server 2003 ISA Server und die Exchange-Front-End- und -Back-End-Server Mitglieder derselben Domäne sein müssen, obwohl sich Benutzer von verschiedenen Domänen trotzdem bei der eingeschränkten Kerberos-Delegierung authentifizieren können. Eine ISA Server-Instanz, die Mitglied keiner Domäne oder Mitglied einer anderen Domäne ist, funktioniert nicht als Teil dieser Lösung.

Konfigurieren der OWA-Site

IIS Admin darf auf keinen Fall für Änderungen an der Authentifizierung bei OWA verwendet werden. Obwohl OWA unter IIS ausgeführt wird und wie jede andere Website auf Änderungen in der Metabasis reagiert, erhöht Exchange mit dem DS2MB-Prozess (Directory Services to Metabase) ein wenig die Komplexität. Der DS2MB-Prozess repliziert Änderungen von Active Directory zur IIS-Metabasis in einem Einbahnprozess, der etwaige direkt an IIS vorgenommene Änderungen überschreibt. Wenn ein Administrator daher damit beginnt, Änderungen direkt an der IIS-Metabasis vorzunehmen (z. B. das Einstellen der integrierten Authentifizierung), funktioniert die Lösung scheinbar, führt jedoch bei Beginn des nächsten DS2MB-Replikationszyklus zum Abbruch.

Die Option zum Aktivieren der integrierten Windows-Authentifizierung für virtuelle HTTP-Verzeichnisse wurde in ESM zur Verfügung gestellt, weil ESM die Bearbeitungen direkt an Active Directory vornimmt und die Änderungen anschließend zur IIS-Metabasis repliziert werden. Bedenken Sie, dass ein Beenden des Systemaufsichtsdiensts auch den DS2MB-Prozess beendet und dass Sie dadurch die Möglichkeit erhalten, Änderungen an der IIS-Metabasis vorzunehmen, ohne dass diese überschrieben werden. Dies ist jedoch nicht ratsam. Beim nächsten Start der Systemaufsicht fragt diese die Änderungen von Active Directory ab, und die Lösung wird dann automatisch deaktiviert.

Die Registerkarte Delegierung zeigt die Optionen „Nur Kerberos verwenden“ und „Beliebiges Authentifizierungsprotokoll verwenden“. Es erscheint logisch, „Nur Kerberos verwenden“ auszuwählen, da die Lösung, mit der wir uns befassen, die eingeschränkte Kerberos-Delegierung verwendet. Aber hier liegt eine der vielen IT-Situationen vor, in denen gewöhnliche Logik nicht gilt. Sie müssen stattdessen die Option „Beliebiges Authentifizierungsprotokoll verwenden“ auswählen (siehe Abbildung 7), da die Anforderung nicht als Kerberos-Anforderung eingeht, sondern als HTTP-Anforderung mit einem entsprechenden Zertifikat, das einem Active Directory-Konto zugeordnet ist.

Abbildung 7** Richtige Authentifizierungseinstellungen für Smartcards **

In diesem Fall fordert ISA Server über SSL das PKI-Zertifikat des Benutzers an. Die eingehende Anforderung ist kein Kerberos-Ticket, sodass ein Übergang erforderlich ist, damit die eingeschränkte Kerberos-Delegierung ordnungsgemäß funktioniert. Aus diesem Grund unterbricht die Einstellung „Nur Kerberos verwenden“ die Kommunikationskette bei ISA Server. Beachten Sie jedoch, dass die Option „Nur Kerberos verwenden“ bei der Delegierung vom Exchange-Front-End- zum Back-End-Server funktioniert, da der Front-End-Server nur Kerberos-Tickets von ISA Server erhält.

Die virtuellen Verzeichnisse \Exchange und \Public sind die einzigen Orte, die Ordnerinformationen privater Benutzer und öffentliche Ordnerinformationen enthalten dürfen. Die SSL-Konfiguration in Exchange ist für eingeschränkte Kerberos-Delegierung oder zweistufige Authentifizierung nichts Neues, sondern ein Übertrag von standardmäßiger SSL-Aktivierung von OWA mit standardmäßigen Authentifizierungsanmeldeinformationen. Befolgen Sie die dokumentierten Verfahren zum Aktivieren von SSL auf OWA, denn falsches Erzwingen von SSL kann OWA unterbrechen und außerdem Probleme mit ESM verursachen.

Zusätzliche Konfigurationsdetails

Das Implementieren dieser Lösung wird erheblich erleichtert, wenn ISA Server und Exchange zunächst in der Standardweise bereitgestellt werden. Stürzen Sie sich nicht gleich in die gesamte eingeschränkte Kerberos-Delegierungslösung mit allen konfigurierten Einstellungen, besonders, wenn ISA Server vorher nicht Teil Ihrer Bereitstellung war. Dies kann den Problembehandlungsprozess erschweren, falls eine Komponente oder ein Schritt im Prozess fehlschlagen sollte. Es ist viel leichter, ISA Server und Exchange in der Standardweise bereitzustellen (mit Benutzernamen und Kennwort, aber ohne formularbasierte Authentifizierung), sich zu vergewissern, dass die Installation funktioniert, und dann zu eingeschränkter Kerberos-Delegierung und Zertifikatauthentifizierung überzugehen.

In der Regel kann formularbasierte Authentifizierung nicht mit smartcardaktiviertem OWA verwendet werden. Formularbasierte Authentifizierung zeigt an, dass ein Benutzer einen Benutzernamen und ein Kennwort hat, die über das standardmäßige Outlook-Formular übermittelt werden. Bei smartcardbasierter zweistufiger Authentifizierung hingegen verfügt der Benutzer nur über eine Smartcard und kein Kennwort. Folglich verfügt formularbasierte Authentifizierung über kein Mittel, um lediglich das Authentifizierungszertifikat anzunehmen oder zu übermitteln. Das Verwenden formularbasierter Authentifizierung an einem beliebigen Punkt in der Kette (z. B. auf einem Front-End-Server hinter ISA Server) unterbricht die smartcardaktivierte OWA-Konfiguration. Wenn Sie formularbasierte Authentifizierung aktivieren, wird das virtuelle Exchange-Verzeichnis zwangsweise auf Standardauthentifizierung eingestellt, und folglich wird auch die IIS-Metabasis auf Standardauthentifizierung eingestellt.

Wenn manche Ihrer Benutzer sowohl über Benutzernamen/Kennwörter als auch Smartcards verfügen, können Sie auf dem ISA-Weblistener die Fallbackauthentifizierung aktivieren. Wenn dann ein Benutzer auf die Schaltfläche „ESC“ klickt, nachdem er zur Eingabe zertifikatbasierter Anmeldeinformationen aufgefordert wurde, wird er zur Eingabe der Standardanmeldeinformationen Benutzername/Kennwort aufgefordert, auch wenn hinter ISA Server auf dem Exchange-Server die integrierte Authentifizierung aktiviert ist. Außerdem kann ISA Server die SSL-Sitzung auf ganz ähnliche Weise beenden, wie dies bei formularbasierter Authentifizierung der Fall ist.

Schlussbemerkung

Smartcardunterstützung zur Authentifizierung bei OWA ist eine willkommene Ergänzung sowohl für Exchange Server 2003 als auch für Exchange Server 2007. Dank der Möglichkeit, sich über ein Zertifikat bei OWA anzumelden, brauchen sich Benutzer keine Sorgen mehr darum zu machen, wie sie sich lange und komplexe Kennwörter merken können, und Administratoren haben jetzt ein wirksames Tool gegen Protokollierung der Tastatureingabe und andere Arten von Malware, durch die Benutzeranmeldeinformationen von einem infizierten System aus ausspioniert werden. Weitere Informationen finden Sie in der Randleiste „Ressourcen“.

Die richtige Konfiguration von ISA Server für die zweistufige Authentifizierung mit Smartcards erhöht die Gesamtsicherheit noch stärker, wenn die veröffentlichte OWA-Anwendung einer Filterung auf Anwendungsebene unterzogen wird. Darüber hinaus verfügt ISA Server 2006 über integrierte Unterstützung für das Veröffentlichen von Exchange Server 2003 und Exchange Server 2007 anhand der einfach zu verwendenden Veröffentlichungsassistenten. Daher ist ISA Server nach wie vor eine gute Investition für Unternehmen, die auf Exchange Server 2007 umstellen.

Ressourcen

• Freigabe von Dateien, die von der Filterfunktion „Safe HTML“ in Outlook Web Access für Exchange Server 2003 entfernt werden
• Problembehandlung bei Kerberos-Delegierung
• Metabasis-Aktualisierungsdienst
• Authentifizierung in ISA Server 2006
• Kerberos-Protokolltransfer und eingeschränkte Kerberos-Delegierung
• TechNet-Webcast: Implementieren mehrstufiger Authentifizierung mithilfe von Smartcards

Victor Akinnagbe arbeitet als Premier Field Engineer bei Microsoft im Raum Washington, D.C. Er befasst sich hauptsächlich mit Sicherheit, Infrastruktur und Messaging.

Ted Dressel arbeitet als Berater bei Microsoft im Raum Washington, D.C. Er befasst sich hauptsächlich mit Sicherheit, Infrastruktur und Messaging.

Jason Opdycke arbeitet als Premier Field Engineer bei Microsoft in der Gegend von Charlotte. Seine Hauptgebiete sind Sicherheit und Infrastruktur.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.