MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Exchange OWA Anmeldung und Logout

Diese Seite beschreibt, wie Sie auf ihrem Exchange Server die Anmeldung per Formular mit der Anmeldung per Kerberos kombinieren können und beim Einsatz einen Reverse Proxy eine Logout-Funktion einbinden können.

Abmelden in OWA

Neben dem Zugriff per Outlook oder mobilen Geräten ist ein Browser eine leistungsfähige Option das eigene Postfach mit Mails, Terminen und Kontakten zu nutzen. In Exchange Online ist es z.B. für die "F1/E1-Pläne" sogar der bevorzugte Weg, das Postfach zu nutzen, da MAPI/HTTP und die Outlook Lizenz hier nicht enthalten ist. Die Authentifizierung am Postfach ist mit Exchange OnPremises über mehrere Wege möglich:

  • Form Based  (Default)
    Beim Zugriff auf https://<fqdn des service/owa" bekommen Sie einen Willkommensschirm und können ihren Benutzernamen und Kennwort eingeben. Exchange prüft diese Daten gegen die Domain Controller und stellt dann ein Cookie für die folgenden Zugriffe aus. Es gibt einen Logout-Button, der das Cookie löscht und damit nachfolgende Zugriffe aber auch ein "Zurück" im Browser verhindert.
  • Windows Integrierte Anmeldung (WIA)
    Wer ein "Single SignOn" erreichen und damit die erneute Eingabe von Kennworten reduzieren möchte, kann Exchange auf "Integrierte Authentifizierung" umstellen. Das Formular verschwindet und Exchange bietet die klassischen Anmeldeverfahren an. Auch hier gibt es einen "Logout"-Button, der allerdings nur zum Schließen aller Browserfenster auffordert. Ein "Logout" gibt es nicht und macht auch keinen Sinn, denn der Browser würde sich ja immer wieder direkt per NTLM/Kerberos automatisch neu anmelden
  • OAUTH/SAML.
    Über die Konfiguration von Hybrid Modern Authentication (HMA) können Sie die Anmeldung an Exchange OnPremises über SAML-Tickets von Entra ID steuern und so z.B. MFA und Conditional Access einbinden. Mit passender Konfiguration ist hier ein SSO als auch ein Logout möglich.

Das sind bislang aber alles die Anmeldungen direkt an Exchange. Es gibt aber noch die Funktion, dass ein anderer Service vor Exchange eine Authentifizierung durchführt und die so erhaltenen Anmeldedaten an Exchange weiterreicht.

  • PreAuth mit Kennwort und FormBased
    Wen das vorgelagerte System das Kennwort des Anwender in einem Formular abfragt, um es dann mit einer lokalen Datenbank, LDAP oder RADIUS prüft, dann kann der Services sich an Exchange im Backend wieder mit dem Kennwort anmelden. Der Reverse Proxy "sendet" die Anmeldedaten per "FORM-POST" an Exchange, als wenn der Anwender die Werte selbst eingegeben und abgesendet hätte. Für Exchange ist es eine klassische Anmeldung per Formular samt Abmeldefunktion
  • PreAuth mit Kerberos, NTLM, SAML
    Wenn sich der Client am Reverse Proxy ohne Klartextkennwort anmeldet, kann der Reverse Proxy auch kein Exchange Formular mit Kenwort ausfüllen. Die einzige Option für eine direkt Anmeldung ohne erneute Eingabe des Kennworts ist Kerberos Constraint Delegation. Für Exchange ist es eine "Kerberos-Anmeldung" und ein Logout wird angeboten aber verweist nur darauf, alle Browser-Fenster zu schliessen.

Als Tabelle sieht das dann wie folgt aus:

Authentiizierung Client Login Logout Beschreibung

Form

Domain Joined

Eingabe im Formular

Möglich

Default Einstellung von Exchange und Abmeldung ist möglich

Form

Nicht Domainmitglied

Eingabe im Formular

Möglich

Default Einstellung von Exchange und Abmeldung ist möglich

WIA

Domain Joined

Automatische Anmeldung

 Nicht möglich

Wenn Sie OWA/ECP auf integrierte Anmeldung umstellen, dann wird ein kompatibler Browser den Anwender direkt anmelden. Eine Abmeldung ist nicht möglich, da der Browser mich ja immer wieder anmelden kann.

WIA

Nicht Domainmitglied

Eingabe im Browser Dialog

alle Browserfenster schließen

Wenn der Client kein Kerberos-Ticket bekommt oder NTLM-SSO ausführen kann, dann muss der Anwender die Anmeldedaten im Browser-Dialog eingeben. Eine Abmeldung geht nur, wenn er den Browser komplett beendet, was im Internet-Cafe nicht sicher möglich ist-

OAUTH

Egal

Automatische Anmeldung möglich

?

Über Hybrid Modern Authentication (HMA) können Sie die Anmeldung über Entra ID leiten. Für Exchange ist es eine Anmeldung mittels SAML-Token (Authentifizierung) und ohne Formular.

Hier stehen noch Tests aus

ReverseProxy mit Formular

Egal

Eingabe im Formular

Möglich

Wenn ein Reverse Proxy eine Authentifizierung in der Art anfordert, das der Reverse Proxy weiterhin das Exchange Anmeldeformular ausfüllt, dann gibt es auch weiterhin den Abmeldebutton.

ReverseProxy mit KCD

Egal

Eingabe im Formular

Nicht Möglich*

In der Standardeinstellung löst ein Druck auf "Logout" keine Aktion an, die ein Reverse Proxy als Abmelden erkennen und darauf reagieren kann.

Sie können und sollten diese Verhalten aber ändern

Das Problem ist der letzte Fall, bei dem sich ein Anwender am Reverse Proxy mit Anmeldedaten und optional sogar MFA anmeldet und in OWA die Abmeldeoption sieht aber nicht sicher nutzen kann. Exchange sieht nämlich eine "Integrierte Anmeldung" und zeigt dann nur den Dialog zum Schließen aller Browser-Fenster.

OWA/ECP Funktion

Wenn Sie Exchange 2016/2019/SE installieren, dann wird OWA und ECP per Default über "Formular" abgesichert. Das ist gut, da sich damit ein Benutzer beim Zugriff auf den Exchange Server explizit per Benutzername und Kennwort anmelden muss und die Session mittels "Abmeldebutton" auch wieder verlassen werden kann. Intern wäre es aber auch nett, wenn Anwender ohne Formulareingabe einfach mit den Anmeldedaten des Clients per Kerberos oder notfalls auch NTLM anmelden kann. Die Funktion ist möglich, wenn Sie die Konfiguration anpassen. Die Standardkonfiguration ist:

[PS] C:\>Get-OwaVirtualDirectory | fl name,*auth*

Name                          : owa (Default Web Site)
ClientAuthCleanupLevel        : High
InternalAuthenticationMethods : {Basic, Fba}
BasicAuthentication           : True
WindowsAuthentication         : False
DigestAuthentication          : False
FormsAuthentication           : True
LiveIdAuthentication          : False
AdfsAuthentication            : False
OAuthAuthentication           : False
ExternalAuthenticationMethods : {Fba}

Sie sehen gut, dass die ExternalAuthenticationMethods : {Fba} von extern nur FBA zulässt aber intern theoretisch auch noch Basic möglich wäre. Beides eignet sich aber nicht für eine "Automatische Anmeldung". Die erforderliche Einstellung dazu "Windows Authentication : False" ist nicht aktiv. Das sehen sie auch im IISAdmin:

Die Funktion "Formbased" ist im IISAdmin gar nicht zu sehen, da diese eine Funktion des Exchange Code ist. Exchange sieht die eingehende Anfragen über eine FilterDLL und entscheidet unabhängig von dein Einstellungen im IIS, ob er die Authentifizierung an den IIS übergibt oder selbst ein Formular anzeigt

Die Frage ist nun, woran Exchange dies festmacht, wer ein Formular bekommt und wer nicht. Exchange versucht wohl zu erkennen, ob der Client ein Browser ist und sucht dazu im Header "User-Agent" des Request nach dem String "Mozilla". Microsoft schreibt dazu:

Exchange 2013 ships with Integrated Windows auth enabled on the OWA and ECP virtual directories as well as Forms based auth. So, if you choose NTLM delegation, or KCD, from TMG/UAG to Exchange, it just works. And because OWA is smart enough to determine the machine connecting to it is a browser and not another Exchange Server, the second scenario just works out of the box too. Clients get FBA, but proxy still works. Genius.
Quelle: Quelle: Configuring Multiple OWA/ECP Virtual Directories on the Exchange 2013 Client Access Server Role | Microsoft Community Hub
https://techcommunity.microsoft.com/blog/exchange/configuring-multiple-owaecp-virtual-directories-on-the-exchange-2013-client-acce/611217

Allerdings habe ich je nach Exchange und Client unterschiedliche Reaktionen erhalten. Es könnte sein, dass Exchange eine andere Information im Header auswertet, die TMG/UAG-spezifisch war. Beide Produkte sind ja schon lange aus dem Support. Das ist daher kein "sicheres Verfahren", auf dem man aufsetzen kann. Auf EWS ist z.B. "Windows Authentication" aktiv während auf "Microsoft-Server-ActiveSync" nur die Anmeldung per "Basic" möglich ist.

Optionen

Wenn wir nun aber die Herausforderung haben, dass wir OWA sowohl er "Formular" als auch per Kerberos/NTLM anbieten wollen, dann gibt es verschiedene Wege.

  • Mehrere Exchange Server
    Sie können natürlich mehrere Exchange Server mit unterschiedlicher Anmeldung installieren und über getrennte Hostnamen einmal die Anmeldung per Formular anfordern und über den anderen Namen die "integrierte Anmeldung" erlauben. Mehrere Server kosten aber Hardware/VMs, Ressourcen, Lizenzen und müssen gepflegt werden
  • Mehrere virtuelle Verzeichnisse
    Eine Alternative ist dann der betrieb mehrere Webseiten auf dem Exchange Server. In der Standard-Einstellung konfiguriert das Exchange Setup die "Default Webseite" als Frontend-Service, welche die Authentifizierung übernimmt, den Homeserver für das Postfach ermittelt und dann die Anfrage per HTTPS an den Backend-Service weiter gibt. Der Backend-Server ist eine eigene IIS-Instanz, die von Anwender normalerweise nicht angesprochen wird.

    Die Backendseite können Sie als Anwender natürlich ansprechen, aber sie müssten dann zuerst ermitteln, auf welchem Server ihr Postfach gerade aktiv ist. Das ist kein Weg. Aber niemand hindert uns daran, eine dritte "Frontend"-Webseite anzulegen, die eine andere Anmeldung erlaubt
  • Kerberos mit Loadbalancer
    Sie können natürlich die Anmeldung an einem Formular auch "vorziehen", z.B. indem der Client auf einem Loadbalancer oder Reverse Proxy zugreift, der zuerst einmal eine Authentifizierung anfordert, mit der er dann im Auftrag des Anwender mittels Kerberos - Constraint Delegation auf den Exchange Server per "Integrierter Anmeldung" zugreift. Dann ändern Sie auf dem Exchange Server die Konfiguration der Anmeldung auf /OWA und /ECP einfach von "Formbased" auf "Windows Authentifizierung. Dieser Weg ist eine Option, wie Sie beim Zugriff aus dem Internet den internen Exchange Server besser gegen Kennwort-Angriffe und Überlastung schützen können.
  • Hybrid Modern Authentication (HMA)
    Zuletzt könnten Sie die Anmeldung auf "Bearer" umstellen, d.h. alle Clients, die OAUTH/SAML können und dies durch den Header "Authentication:Bearer" mitteilen, bekommen von ihrem Exchange Server die Umleitung z.B.: zum Entra ID Anmeldeserver, der dann die eigentlich Anmeldung vornimmt. Die Anmeldung an Entra ID können Sie dann z.B. Anhand des Standorts steuern.

Mal abgesehen von zusätzlichen Servern für unterschiedliche Anmeldungen haben die anderen Optionen alle schon bei Kunden gesehen und konfiguriert.

Weitere Webseite

Wenn sie keinen Loadbalancer mit PreAuth einsetzen wollen und Hybrid Modern Authentication (HMA) keine Option ist, dann bleibt neben dem aufwändigen Weg über zusätzliche Server nur die Konfiguration einer zusätzlichen Webseite. Über den IISAdmin gehen sie dazu auf die "Sites" und über "Add Website" starten Sie den Assistenten. 

Ich lege in der Regel dazu eine leere Webseite im Verzeichnis "C:\inetpub\wwwroot2" an. Achten Sie bei den Bindungen, dass Sie keine Konflikte mit den bestehenden Webseiten haben. Die Default Webseite lauscht auf 80/443 und die Backend-Webseite auf 81/444. Die Nutzung eines anderen Ports klingt verlockend, aber ist nicht unterstützt:

Microsoft supports using multiple Outlook Web App (OWA) and Exchange Control Panel/Admin Center (ECP) front end virtual directories on a server with the Exchange 2013 Client Access Server role, when each is in its own website and is named ‘OWA’ and ‘ECP’.  Each virtual directory must be listening on the standard TCP 443 port for the site.

und

Microsoft supports creating additional OWA/ECP virtual directories in a new IIS Web Site with a new IP address, and using those only for client access purposes. By default that new virtual directories will be FBA enabled, and have no internal or external URL values.
Quelle: Configuring Multiple OWA/ECP Virtual Directories on the Exchange 2013 Client Access Server Role | Microsoft Community Hub
https://techcommunity.microsoft.com/blog/exchange/configuring-multiple-owaecp-virtual-directories-on-the-exchange-2013-client-acce/611217

Sie müssen also entweder eine zusätzliche IP-Adresse vorsehen oder mit Hostheadern arbeiten. Wenn die Webseite dann angelegt wurde, dann kann ich mit der Exchange PowerShellzwei virtuelle Verzeichnisse einrichten und die Anmeldung umstellen:

# Einrichten der virtuellen Verzeichnisse
New-OwaVirtualDirectory -WebSiteName www2
New-EcpVirtualDirectory -WebSiteName www2
Set-OwaVirtualDirectory "owa (www2)" -WindowsAuthentication:$true -FormsAuthentication $false
Set-EcpVirtualDirectory "ecp (www2)" -WindowsAuthentication:$true -FormsAuthentication $false

Die neu eingerichteten Verzeichnisse verweisen auf die gleichen physikalischen Pfade als auch die AppPools wie die OWA/ECP-Einträge der Default Web Seite. Auf dem Blog-Artikel von Microsoft steht, dass man auch den Inhalt von "wwwroot" kopieren und Rechte anpassen sollte. Bei mir hat das aber auch ohne diese Anpassungen funktioniert. Insofern dürften auch die weiteren Hinweise bei einem CU-Update nicht mehr passen. Auf der PowerShell sehe ich dann

In der "ExternalAuthenticationMethod" steht immer noch ein "Fba" drin, aber das hat zumindest bei mir nicht gestört. 

Hinweis: Eine eigene Webseite ist auch eine gute Option, um nur ausgewählte Dienste von Exchange nach Extern erreichbar zu machen. Wer Zugriffe per Outlook nur intern erlauben möchte und extern nur ActiveSync nutzt, kann eine eigene Webseite nur für Microsoft-Server-ActiveSync und ggfls. Autodiscover einrichten und veröffentlichen.

KCD mit mehreren Servern

Wenn Sie "Integrierte Authentifizierung" nutzen, dann müssen Sie die Unterschiede von NTLM und Kerberos verstanden haben, Bei NTLM greifen Sie auf den Server zu, der ihnen eine Startwert (Challenge) sendet, die sie mit dem Hashwert ihres Kennworts verrechnen und zurücksenden. Der Exchange Server sendet das Ergebnis an den Domaincontroller, welcher auch ihren Hashwert des Kennworts hat und dann ein Erfolg oder Fail meldet. Der Servername ist hier unwichtig. Wenn Sie aber Kerberos und insbesondere Kerberos Constraint Delegation nutzen sollen, dann müssen Sie bei einem Server noch nichts machen. Wenn Sie aber mehrere Server unter dem gleichen Namen veröffentlichen, dann hängt es davon ab, ob Sie die Server per DNS Round Robin oder über einen Loadbalancer erreichbar machen. Der Client greift nämlich auf einen Namen, z.B. "webmail.msxfaq.de" zu und einer ihrer Server bietet Kerberos an. Der Client holt sich dann ein Ticket für den Hostnamen und da kann einiges schief gehen:

  • CNAME oder A-Record
    Laut RFC dürfen Sie im DNS einen CNAME nur einmal verwenden. Daher müssen Sie für jeden Exchange Server einen eigenen A-Record mit "webmail.msxfaq.de" und der IP-Adresse anlegen. Der Client bekommt mehrere IP-Adressen, sucht sich eine aus und verbindet sich. Bei einem CNAME würde er den Zielnamen per Kerberos nutzen. Bei einem A-Record aber den virtuellen Namen
  • Fehlendes Konto mit SPN
    Damit der Domain Controller ein Kerberos-Ticket für den Namen "webmail.msxfaq.de" ausstellen kann, muss es genau ein Objekt im Active Directory geben, welches diesen Namen hat. Das bedeutet aber, dass sie ein entsprechendes Benutzer- oder Computerkonto anlegen und konfigurieren müssen. Dazu gibt es bei Exchange das PowerShell-Script "RolloutAlternateCredentials.ps1"
  • Exchange Konfiguration
    Das Skript "RolloutAlternateCredentials.ps1" sorgt ebenfalls dafür, dass das "Geheimnis" auf alle Exchange Server verteilt wird. Erst dann können die Exchange Server das vom Client gesendete Kerberos-Ticket entschlüsseln und überprüfen.
  • Layer 7 - Loadbalancing
    Wenn Sie aber einen Loadbalancer nutzen, der selbst die Authentifizierung macht und dann per Kerberos - Constraint Delegation auf die "Real-Server" zugreift, dann könnten Sie auf das Dienstkonto verzichten. Der Loadbalancer müsste ich einfach ein Kerberos-Ticket für den FQDN des Servers holen. Das gilt aber nur für "Layer-7"-Loadbalancing, wenn die HTTPS-Verbindung aufgebrochen wird.
  • Layer 4 - Loadbalancing
    Wenn der Loadbalancer aber einfach nur die TCP-Connection an einen verfügbaren Server per NAT/ReverseNAT durchreicht, dann erfolgt die Authentifizierung des Clients direkt am Server. Dann müssen Sie wieder das virtuelle Computerkonto einrichten.

Sie sehen schon, dass es je nach Umgebung andere Anforderungen an die Konfiguration gibt.

Abmeldebutton mit Windows Integrated

Wenn Sie sich mittels "Integrierter Windowsanmeldung" an Outlook Web Access ihres OnPremises-Servers anmelden, dann finden Sie zwar oben auch einen "Abmelde"-Button, aber er funktioniert nur eingeschränkt. OWA meldet danach, dass Sie alle Browser-Fenster schließen sollen. Aber selbst wenn Sie dies tun und danach den Browser wieder starten, sind sie doch direkt wieder im Postfach des Benutzers angemeldet.

Das ist so und das muss auch so sein. So funktioniert nun mal die "Integrierte Anmeldung".

Damit scheidet diese Konfiguration für einen Zugriff aus dem Internet natürlich aus. Auf sehr vielen Computern in Internet-Cafes können Sie den Browser gar nicht schließen. Daher sollten Sie ohne weitere Vorkehrungen den Zugriff per Windows Authentifizierung nur intern von Domainmitgliedern zulassen, auf denen die Anwender sich sicher anmelden und abmelden. Bei einer Anmeldung mit "Form Based" Authentifizierung funktioniert die Abmeldung, da sich hier nicht der Browser selbst anmelden, sondern nur der Anwender in der Webseite (Formular) und Exchange als Ergebnis mit Cookies arbeitet, die beim Klick auf "Logout" auch einfach zerstört werden können.

AbmeldeURL mit KCD

Die folgende Beschreibung ist nur relevant, wenn Sie sich über einen Reverse Proxy mit Kerberos Constraint Delegation an OWA anmelden, z.B. beim Einsatz eine Preauthentication mit Kerberos, NTLM, Entra ID oder ADFS anfordert und ihr Reverse Proxy nicht das Kennwort im Klartext hat und diese damit nicht im Exchange OWA Anmeldeformular eingeben kann.

Wenn Sie einen Layer-7 Loadbalancer oder Reverse Proxy nutzen, der die Anmeldung von extern übernimmt, dann wäre ein HTTP-Request wünschenswert, anhand der Reverse Proxy erkennt, dass der Anwender ein "Logout" ausgelöst hat. Ich habe daher den "Logout-Button im Debugger mitlaufen lassen und sie sehen, dass sie nichts sehen. Beim Druck auf den "Abmelde-Button" kommt einfach ein Fenster aber es findet kein Request statt. 

Im Sourcecode der HTML-Seite lässt sich das Menü einfach identifizieren:

Da ist zwar keine URL dahinter, aber irgendwo muss ein Handler sein, der auf das "Klicken" den Dialog anzeigt. Natürlich könnte ich nun die Exchange Installationsdateien nach dem Code durchsuchen und einfach einen Anchor auf eine URL setzen, die der Client über den Reverse Proxy wieder aufruft und vom Reverse Proxy als "Logout-Anforderung" erkannt wird. Diese Funktion ist in vielen Produkten enthalten. Exemplarisch hier die Konfiguration bei einem Kemp mit ESP

Wenn der Client die URL "<fqdn des Server>/owa/logoff.owa" aufruft, dann ist das für den Reverse Proxy das Signal, die Sitzung zu zerstören. Der Exchange Server wird schon irgendwann merken, dass die Verbindung nicht mehr genutzt wird. Diese Einstellung muss ich in Exchange aktivieren.

Version  Trick

Bis Exchange 2016 CU8 

Früher konnten Sie über die web.config und den Schalter "LogonSettings.SignOutKind" die OWA-Seite dazu bringen, selbst mit Windows integrierter Anmeldung einen Logout-Button anzubieten, der zwar keinen Logout macht aber eine URL aufruft, die vom Reverse Proxy erkannt werden kann.

REM funktioniert nur bis Exchange 20196 CU8
notepad %ExchangeInstallPath%\ClientAccess\OWA\web.config
<!– Disable logout page temporarily until UX is updated –>
<add key=”LogonSettings.SignOutKind” value=”LegacyLogOff” />

Allerdings ist der Abschnitt in aktuellen Exchange 2016/2019 Servern nicht mehr vorhanden und ich habe keine andere "offizielle" Option gefunden.

 

Danach 

Für neuere Exchange Versionen habe ich den Trick über "SignOutKind" nicht mehr gefunden. Dafür einen anderen Weg.

REM funktioniert nur bis Exchange 20196 CU8
notepad %ExchangeInstallPath%\ClientAccess\OWA\prem\15.2.1748.37\scripts\microsoft.owa.core.models.js 

Addieren Sie einfach den folgenden Text an das Ende der Datei. 

$(document).ready(function(){ $('._ho2_2').click(function () {
   $('body > div:last-child ._abs_c div[role=menu] > div > div:last-child > button').on('click', function () {
window.location.href= './logoff.owa' }) }) });

Ein IISReset ist nicht nötig. Allerdings müssen die Clients den aktuellen Code natürlich erst laden, d.h. Caching, ProxyServer etc. können die Wirkung verzögern. Bei mir ein ein "F5"-Reload im Browser gereicht.

Achtung: Bei einem Update von Exchange wird die Änderung vermutlich wieder überschrieben 

Option: IFRAME

Ganz losgelöst von Exchange könnte natürlich der Loadbalancer/Reverse Proxy die OWA-Seite in ein IFRAME o.ä. einbinden und einen Logout-Button außerhalb des IFRAME anzeigen. Die Funktion wäre gänzlich von Exchange unabhängig.

Option HTML-Rewriting

Der von Exchange gelieferte HTML-Code mit JavaScript ist vom Reverse Proxy problemlos lesbar. Der Reverse Proxy könnte ja einfach nach dem Tag 'autoid="_ho2_2"' suchen und das "Abmelden" um ein HREF zur Abmelde-URL ergänzen. Diese Umsetzung wäre weitgehend von Exchange unabhängig.

Beim Klick auf "Logout" wurde dann die URL "logoff.owa" aufgerufen, die dann einen Redirect gestartet hat.

Diese URL kann ein Reverse Proxy sehen und die Session zerstören.

Auf dem Exchange Server ist die Session natürlich nicht weggeräumt und wenn ich im Browser von intern ein "Zurück" klicke oder die Url <fqdn>/owa eingebe, dann bin ich wieder im Postfach. Wenn ich aber über einen Reverse Proxy zugreife, dann sollte dieser eine Neuanmeldung anfordern.

Eine andere Option wäre natürlich, wenn der Reversy Proxy die OWA-Seite in einem eigenen IFRAME mit Logout-Funktion in der Hauptseite einbindet oder selbst seinen "Logout-Link" in die HTTP-Datei einbindet.

Einschätzung

Ein explizites Logout einer OWA-Sitzung ist mit Exchange OnPremises nur vorgesehen, wenn Sie sich per "Formularbasierter Anmeldung" an Exchange authentifizieren. Das geht nur, wenn sie dem Anwender selbst das Formular ausfüllen lassen oder ein eingesetzter Reverse Proxy die Anmelddaten im Klartext abfragt und seinerseits dann im Formular "eintippt". Wenn Sie Exchange hingegen auf "Integrierte Anmeldung" umstellen, damit sie z.B. mittels "Kerberos Constraint Delegation" eine Anmeldung durchführen können, dann liefert Exchange einen Code aus, der beim Druck auf "Abmelden" nur einen Warnhinweis anzeigt aber keine Aktion ausführt.

Wenn Sie in dem Fall ein "Logout" auf dem vorgelagerten Reverse Proxy erzwingen wollen, dann müssen Sie den Code entsprechend anpassen.

Ich verstehe nicht, warum Exchange bei der Nutzung von OWA mit integrierter Authentifizierung beim Klick auf "Abmelden" nicht einfach auf die "Logout.owa"-URL verweist, die dann den Hinweise gibt. Oder irgendwie einen anderen HTTP-Request auslöst, anhand dessen der Reverse Proxy oder Load Balancer die Session löschen kann.

Weitere Links