Problem: Radius-Authentifizierung bei Exchange-Webclientzugriffen mit ISA 200x SE Im Rahmen eines Kundensupports habe ich mich mit der Radius-Implementation auf einem ISA Server 2004 Standard Edition (SP3) beschäftigt. Ziel der Aufgabe ist es ein sicheres Webpublishing für Exchange HTTP/RPC (aka Outlook- Anywhere bei Exchange 2007) mittels Radius-Authentifizierung zu realisieren. Ein spezieller Kundenwunsch sollte berücksichtigt werden: Auf der Webveröffentlichungsregel sollen ISA-Benutzersätze verwendet werden, die wiederum auf Radius-Gruppen verweisen. Wichtige Information vorab: Dieser Konfigurationswunsch ist meiner Meinung nach nicht möglich! Ebenfalls gegengetestet wurde dieses Szenario von mir mit dem aktuellen ISA Server 2006. Folgende Ausgangssituation ist gegeben (der DC sowie der Domain-PC sind in einer Windows-Domäne, der ISA hingegen ist Mitglied einer Arbeitsgruppe. Zu Testzwecken läuft ebenfalls auf dem DC ein Exchange Server 2003.): Bei dem DC handelt es sich um einen Windows Server 2003 Enterprise Edition Server, dessen Domänenfunktionsebene auf Windows Server 2003 hochgestuft wurde (wichtig, falls später Zugriffe über RAS-Richtlinien gesteuert werden sollen). Auf dem DC werden die IAS-Dienste (RADIUS) nachinstalliert (Windows-Komponenten hinzufügen entfernen / Netzwerkdienste / Internetauthentifizierungsdienst).
Nach der Installation findet sich in der Verwaltung eine neue Verknüpfung für den Internetauthentifizierungsdienst.
Hierbei ist mir in zwei verschiedenen Szenarien aufgefallen, das der IAS nach der Installation nicht gestartet werden konnte: In der Ereignisanzeige wird dies mit einem Socketkonflikt bezeugt (ich schließe hier allerdings nicht aus, dass die Problematik aufgrund meiner VMs entstanden ist und nicht unbedingt woanders reproduzierbar ist):
Nach einem beherzten Neustart der Maschine läuft der IAS einwandfrei und in der IAS-Konsole wird der IAS-Server im AD registriert: Danach wird der ISA-Server als Radius-Client angelegt:
Folgende Einstellungen werden vergeben: Der Clienthersteller wird auf Microsoft gestellt. Die Sicherheit der Implementation steht und fällt mit der Komplexität des zu verwendenden gemeinsamen geheimen Schlüssels. Ebenfalls wird die Checkbox für den Message Authenticator gesetzt.
Final schaut das Ganze in der Konsole so aus: Daraufhin wird eine neue RAS-Richtlinie erstellt:
Eine benutzerdefinierte Richtline wird erstellt, der wiederum ein hübscher Name gegeben wird. Der Richtlinie werden in meinem Beispiel im nächsten Dialog folgende Bedinungen hinzugefügt. Als Authentication-Type wird PAP verwendet, da der ISA dies als einziges beherrscht. Als NAS-IP-Address wird die interne IP des ISAs eingetragen und als letzte Bedingung wird eine Windows-Gruppe hinzugefügt (in diesem Szenario die globale Gruppe radius aus meiner Windows-Domäne firma ):
Dieser Richtlinie wird die RAS-Berechtigung erteilt:
Nun bearbeite ich noch das Einwählprofil: Als Authentifizierung wird PAP eingesetzt:
Als Verschlüsselung wird Keine Verschlüsselung eingesetzt, sicher ist sicher : Die neue RAS-Richtlinie schaut in der Konsole so aus:
Die Benutzerkonten im AD sollten auf der Registerkarte Einwählen wie folgt konfiguriert sein: Natürlich ist für die Zugriff wichtig, dass die Benutzer passend in Gruppen organisiert werden. In diesem Szenario ist das Benutzerkonto test der Gruppe radius zugeordnet:
Nun wechseln wir zu dem ISA 2004 SE Server. Hier wird als Erstes der RADIUS-Server definiert (unter Konfiguration / Allgemein): Gemäß den vorher festgelegten Eigenschaften wird die RADIUS-Server-Anbindung konfiguriert:
Ab diesem Punkt ist die RADIUS-Konfiguration beendet und man sollte nun einwandfrei Firewallrichtlinien in Form von Webproxyclientzugriffs- und Webveröffentlichungsregelwerk erstellen können, die mittels RADIUS authentifiziert werden können. Der Fokus meiner Tests war auf das HTTP/RPC-Veröffentlichungsszenario ausgelegt. Zu Testzwecken habe ich vorher eine OWA-Webveröffentlichung durchgeführt um die passenden Services mit einem Browser gegentesten zu können. Ich möchte hier an dieser Stelle nicht weiter auf die Webveröffentlichungsszenarien eingehen, da diese bereits in anderen Dokumentationen hinreichend dargestellt werden. Kurz und bündig zum Thema OWA: die Webveröffentlichungsregel habe ich mit dem dafür im ISA 2004 (SP3) vorgesehenen Assistenten durchgeführt. SSL-Bridge, Standard-Authentifizierung auf dem Weblistener und einfache Delegierung der Standard-Authentifizierung wurde eingerichtet. Änderungen der Regel, die die Radiusanbindung betreffen sehen wie folgt aus. Es wurde ein neuer Benutzersatz für die RADIUS Authentifizierung angelegt:
Diesem Benutzersatz wurde auf meiner OWA-Veröffentlichungsregel ausschließlich der Zugriff gewährt:
Nicht zu vergessen, die RADIUS-Authentifizierung auf dem Weblistener ermöglichen:
Zugriff via Browser aus Sicht des Internets auf meine Testmaschine mittels Testurl: Nach erfolgreicher Authentifizierung erscheint das bekannte OWA-Interface:
Prima! OWA-Zugriffe via Browser mit RADIUS-Authentifizierung auf dem Weblistener und Standard-Authentifizierungs- Delegierung funktionieren einwandfrei. Nur die in dem Benutzersatz festgelegten Benutzer können sich authentifizieren, der Rest muss leider draußen bleiben. Auf zum Thema HTTP/RPC. Auch hier spare ich mir eine detaillierte Beschreibung der einzelnen Konfigurationsschritte des ISAs bzgl. des Regelwerks. Zur Vorbereitung des Szenarios: RPC-über-HTTP-Proxy wurde auf dem Exchange 2003 installiert. Passende Registry-Hacks auf Exchange und GCs wurden durchgeführt. Auf dem virtuellen Verzeichnis /rpc der passenden Website wurde die Standardauthentifzierung eingeschaltet und der anonyme Zugriff deaktiviert, sowie 128bit SSL verlangt. Ein interner Zugriff funktioniert von dem Domain-PC aus mit Outlook 2003 einwandfrei (serverintra.firma.local ist der interne DC / Exchange): Flux eine neue sichere Webveröffentlichung für den HTTP/RPC-Zugriff erstellt, mit der ausschließlich das Verzeichnis /rpc veröffentlicht wird. Die restlichen Settings (SSL-Bridge, RADIUS auf dem Weblistener, Standard-Authentifzierungs- Delegierung) sind identisch wie bei der OWA-Veröffentlichung. Beim Zugriff aus dem Internet mit Outlook 2003 erscheint die übliche Authentifizierungsmaske:
Die erfolgreiche Authentifizierung wird in der Ereignisanzeige auf dem IAS/DC angezeigt: Aber der Zugriff bleibt trotzdem leider verwehrt, das externe im Internet befindliche Outlook 2003 zeigt nach kurzer Zeit wieder obigen Authentifizierungsdialog an. Auf der HTTP/RPC-Veröffentlichungsregel wird der radius -Benutzersatz entfernt und durch den vordefinierten Benutzersatz Alle Benutzer ersetzt:
Wie vorher auch wird zeigt das externe Outlook 2003 einen Authentifizierungsdialog an (welcher nun direkt von der Exchange-Website angefordert wird): Nach erfolgreicher Authentifizierung TATA funktioniert der Zugriff einwandfrei: Der Zugriff bleibt aber aus Sicht des ISAs leider anonym:
Eine weitere von mir getestete Variante, es wird der Benutzersatz Alle authentifizierten Benutzer verwendet: Reichlich verwundert, aber dennoch nicht völlig verzweifelt findet sich nun folgende authentifizierte Sitzung in der Überwachung wieder: Um versionsspezifische Unterschiede ausschließen zu können wurde der ISA Server 2004 SE durch einen ISA Server 2006 SE ersetzt. Die Grundkonfiguration unterscheidet sich nur marginal. Leider bleibt das Authentifizierungsverhalten identisch. Bezüglich der RADIUS-Integration ändern sich nur folgende Punkte.
Die Weblistener-Konfiguration wurde überarbeitet: Außerdem wurde die Authentifizierungsdelegierung gründlich überarbeitet:
Fazit: Eine HTTP/RPC Veröffentlichung über einen ISA Server 200x Standard Edition kann nur benutzerkontenbasiert gesteuert werden, indem per RAS-Richtlinie den passenden Benutzer(gruppen) die Einwahlberechtigung erteilt wird. Sobald mit Benutzersätzen auf der Veröffentlichungsregel gearbeitet wird, funktioniert der authentifizierte Zugriff im Gegensatz zu OWA-Veröffentlichung leider nicht mehr. Die einzige Ausnahme stellt hier der vordefinierte Benutzersatz Alle authentifizierten Benutzer dar. Sollte es wichtige ergänzende Informationen zu diesem Szenario geben, bitte kurze Email an mich.