Outlook Web Access- bzw. Outlook Anywhere-Zugriff mittels Squid und Gruppenzugehörigkeit regeln

Dani hat vor einiger Zeit eine Anleitung geschrieben, in der erklärt wird, wie man Squid als Reverse Proxy für den Einsatz mit Exchange/Outlook Web Access/Outlook Anywhere einsetzt. Aufgrund einiger Vorkommnisse in unserem Unternehmen im Umgang mit Outlook Web Access habe ich auf Basis der Anleitung eine Möglichkeit gebaut, mit der anhand der Zugehörigkeit einer Sicherheitsgruppe im Active Directory gesteuert werden kann, wer aus dem Internet auf Outlook Web Access bzw. auch auf Outlook Anywhere zugreifen darf.
Dieses System ist jetzt seit etwa einem Jahr erfolgreich im Einsatz und funktioniert, bis auf die ständig gleichen Anwenderfehler, problemlos.

Visualisiert sieht es wie folgt aus


Diese Anleitung erläutert nur einige nötige Schritte, die von anderen Anleitungen abweicht, um keine Redundanz hineinzubringen. Dazu gehören die Originalanleitung von Dani, die grundlegende Konfiguration eines Exchangeserver sowie die Integration eines Linuxsystems im Active Directory mittels Samba/Winbind.

Damit es funktioniert, müssen aber einige Anpassungen in den Exchange Servern getätigt werden, die die CAS-Rolle installiert haben.

Dazu muss die Authentifizierung von Outlook Web Access, der Exchange-Systemsteuerung und Exchange ActiveSync auf die Standard-Authentifizierung umgestellt werden.

Als Beispiel hab ich mal das entsprechende Tab für Outlook Web Access geöffnet:

Das Feld Anmeldedomäne beinhaltet normal einen Wert, dieser ist hier entfernt worden.

Beachtet bei Exchange ActiveSync auch den Hinweis unten im Tab.

In den Einstellungen der jeweiligen CAS-Server muss man, weil die SSL-Verbindung mehrfach aufgebrochen wird, das SSL-Offloading/die SSL-Verschiebung aktivieren:

Das Feld Externer Hostname muss normal einen Wert beinhalten, dieser ist hier entfernt worden.

Anschließend baut ihr euch zwei Linuxserver anhand von Danis Anleitung. Damit ihr euch nicht zuviel Arbeit macht, könnt ihr das gebaute deb-Paket für beide Server nutzen.

Squid1 entspricht ganz genau Danis Anleitung, nur zeigt der eingetragene cache_peer nicht auf den Exchangeserver sondern auf die IP-Adresse vom internen Squid.

Squid2 entspricht bis auf ein paar Anpassungen in der Konfiguration auch Danis Anleitung, wobei der cache_peer hier auf den Exchangeserver zeigt, aber noch über die Authentifizierung verfügt.

Dazu müsst ihr, nachdem ihr den Squid installieren, aber bevor ihr die Konfiguration des Squid vornehmt, müsst ihr noch einen kleinen Extraschritt machen. Ihr müsst auf diesem Server Samba sowie Winbind installieren und dann diesen Server zum Mitglied des Active Directorys machen. Nutzt dazu bitte eine der Anleitungen, die ihr überall im Internet finden könnt, ich geh einfach mal davon aus, dass ihr wisst, was ihr macht und wie man diese Anleitungen findet.

Die dazugehörige smb.conf sieht so aus:

Wichtig sind die beiden winbind-Zeilen am Ende sowie der darüberstehende Hinweis. Normalerweise wird ein einzelner Backslash bei Windows genutzt, da dieses aber normal das Escapezeichen ist, wie auch bei Samba/Winbind muss dieser selbst escaped werden, daher \\. Der Rest der Konfiguration von Samba entspricht einer normalen AD-Mitgliedschaft eines Linuxsystems.

Jetzt kommt die eigentliche Konfiguration des internen Squids:
Wie ihr seht, entspricht die Konfiguration des internen Squids sehr stark der von Dani.
Der Server lauscht auf der 192.168.0.171:443 und erwartet eine HTTPS-Verbindung, 192.168.0.131 ist der Exchangeserver mit der CAS-Rolle.
Der erste wichtige Teil ist dieser hier:
Damit ermöglicht man dem Squid, eine Standardauthentifizierung gegen das Active Directory auszuführen, die Sicherheitsgruppe, die auf OWA von extern zugreifen darf, wird mittels --require-membership-of="domain\\_owaextern" angegeben.

Sehr wichtig ist auch das login=PASS in der Definition des cache_peers, damit wird nämlich die Authentifizierung transparent an den Exchangeserver weitergeleitet, so dass keine Mehrfachanmeldung nötig ist, dieses war aber auch in der Originalkonfiguration der Fall.

Die letzte Änderung ist bei den ACLs erfolgt.
Und zwar wird hierüber gesteuert, wer was darf. In meinem Fall ist es so, dass die lokalen Netzwerke, also 192.168.0.0/22 und 172.21.0.0/22 immer auf OWA zugreifen dürfen, während alles aus den anderen Netzen nur nach einer Benutzerauthentifizierung zugreifen darf. Aber Achtung, im Regelfall sieht der interne Squid nur die IP-Adresse des Squids in der DMZ, wenn jemand von außerhalb zugreift, daher könnte man diese ACL noch viel feiner einstellen.

Diese ACLs stammen noch aus den Anfängen, als wir intern noch nicht geklärt haben, wie unsere Filialen auf OWA zugreifen sollen. Mittlerweile ist es so, dass die Filialen direkt auf die CAS-Server zugreifen und der Squid nur den Traffic aus dem Internet behandelt. Man könnte also die ACLs vereinfachen, dass überlasse ich aber euch.

Die letzte Zeile der Konfiguration habe ich reingesetzt, um mir das Logging während der Inbetriebnahme zu vereinfachen. Diese Zeile erzeugt dann in der access.log folgende Einträge
Wie ihr seht, sieht man bei der IP immer die IP des Squid1. In den Logs des Squid1 sieht man dagegen immer die öffentliche IP des Benutzers, aber keine Benutzerkennung, da diese hier nicht ausgewertet werden kann.

Es gibt aber ein bekanntes Problem, was ich bisher noch nicht lösen konnte: Outlook Web Access akzeptiert in den neueren Versionen den Slash (/) sowie den Backslash (\) gleichermaßen, obwohl in Active Directory-Umgebungen nur der Backslash zulässig ist. Benutzer kennen normal den Unterschied zwischen Slash und Backslash nicht, so dass die im Regelfall den falschen, also den Slash, nutzen. Damit ist keine Anmeldung über den Squid möglich. Dieser bzw. Winbind als Authentifizierungsdienst erwartet zwangsläufig den Backslash (oder das eingetragene Trennzeichen). Dieses hat bei mir zu sehr viel Verwirrung geführt, weil im internen Netzwerk der Slash grundsätzlich funktioniert.

EDIT: Ich habe gerade nochmal eben einen Test gemacht, die neue Schreibweise, also user@domain.de funktioniert auch problemlos.

Ebenso ist keine Nutzung der formularbasierten Authentifizierung möglich. Per Squid ist es gar nicht möglich, wenn man anhand meiner Anleitung den Zugriff regeln will, für die interne Nutzung müsste man einen extra CAS-Server, der nicht via Squid veröffentlicht wird, einrichten, der die formularbasierte Authentifizierung anbietet.