Single-Signon-Optionen für Exchange 2010

Wir arbeiten an einem Projekt zur Migration von Mitarbeiter-E-Mails von Unix / Open Source (Kurier-IMAP, Exim, Squirrelmail usw.) nach Exchange 2010 und versuchen, Optionen für die einmalige Anmeldung für Outlook Web Access herauszufinden. Bisher sind alle Optionen, die ich gefunden habe, sehr hässlich und "nicht unterstützbar" und funktionieren möglicherweise einfach nicht mit Forefront.

Wir haben bereits JA-SIG CAS für Token-basiertes Single-Signon und Shibboleth für SAML. Benutzer werden zu einem einfachen internen Portal (eigentlich ein Perl-CGI) geleitet, über das sie sich bei den meisten Dingen anmelden. Wir haben einen HA OpenLDAP-Cluster, der bereits mit einer anderen AD-Domäne synchronisiert ist und mit der AD-Domäne synchronisiert wird, die Exchange verwendet. CAS authentifiziert sich gegen LDAP. Das Portal authentifiziert sich gegen CAS. Shibboleth authentifiziert sich bei CAS, bezieht jedoch zusätzliche Daten aus LDAP. Wir bewegen uns in Richtung einer Authentifizierung von Webdiensten gegen CAS oder Shibboleth. (Die Schüler sind bereits mit SAML / Shibboleth authentifizierten Google Apps for Education)

Mit Squirrelmail haben wir einen schrecklichen Hack von dieser Portalseite, der sich gegen CAS authentifiziert, Ihr ursprüngliches Klartext-Passwort erhält (ja, ich weiß, böse) und Ihnen ein HTTP-Formular mit allen erforderlichen Squirrelmail-Anmeldedaten mit JavaScript vorfüllt onLoad Sachen, um das Formular sofort zu senden.

Es scheint schwierig zu sein, genau herauszufinden, was mit Exchange / OWA möglich ist. "CAS" ist sowohl das Akronym für unseren Single-Signon-Server als auch eine Exchange-Komponente. Nach allem, was ich sagen konnte, gibt es ein Addon für Exchange, das SAML ausführt, aber nur zum Zusammenführen von Dingen wie frei / beschäftigt Kalenderinformationen, nicht zur Authentifizierung von Benutzern. Außerdem kostet es zusätzliches Geld, so dass es keine Möglichkeit gibt, damit zu experimentieren, um zu sehen, ob es dazu gebracht werden kann, das zu tun, was wir wollen.

Unsere Pläne für den Exchange-Cluster beinhalten Forefront Threat Management Gateway (die neue ISA) in der DMZ-Front-End der CAS-Server.

Die eigentliche Frage: Hat es jemand geschafft, Exchange mit CAS (tokenbasiertes Single-Signon) oder SAML authentifizieren zu lassen, oder mit etwas, das ich mit einer solchen Authentifizierung durchführen kann (z. B. mit etwas, das die Authentifizierung von Apache akzeptiert)? Mit Forefront?

Gelingt dies nicht, hat jemand einige Tipps, wie Sie die OWA Forms Based Authentication (FBA) davon überzeugen können, dass wir den Benutzer irgendwie "vorab anmelden" können? (Melden Sie sich als solche an und geben Sie Cookies an den Benutzer zurück oder geben Sie dem Benutzer ein vorab ausgefülltes Formular, das automatisch gesendet wird, wie wir es mit Eichhörnchen tun). Dies ist aus mehreren Gründen die am wenigsten bevorzugte Option, würde aber (kaum) unsere Anforderungen erfüllen. Nach dem, was ich von dem Typ höre, der Forefront implementiert, müssen wir OWA möglicherweise auf die Basisauthentifizierung einstellen und Formulare in Forefront für die Authentifizierung erstellen, sodass dies möglicherweise nicht einmal möglich ist.

Ich habe CasOwa gefunden , aber es erwähnt nur Exchange 2007, sieht irgendwie beängstigend aus, und soweit ich das beurteilen kann, handelt es sich meistens um denselben OWA-FBA-Hack, den ich in Betracht gezogen habe, etwas stärker in den CAS-Server integriert zu sein. Es sah auch nicht so aus, als hätten viele Leute viel Erfolg damit gehabt. Und es funktioniert möglicherweise nicht mit Forefront.

Es gibt auch " CASifying Outlook Web Access 2 ", aber das macht mir auch Angst und beinhaltet das Einrichten einer komplexen Proxy-Konfiguration, die mit größerer Wahrscheinlichkeit kaputt geht. Und wieder sieht es nicht so aus, als würde es mit Forefront funktionieren.

Vermisse ich etwas mit Exchange SAML (OWA Federated whatchamacallit), bei dem es möglich ist, die Benutzerauthentifizierung und nicht nur die Berechtigung für den freien / geschäftigen Zugriff zu konfigurieren?

Wir haben beschlossen, dass die Kombination aus dem Hinzufügen von "ClearPass" zu CAS und dem Ändern des Exchange-Setups zu schwierig zu warten ist. Daher ist unsere endgültige Lösung so etwas wie die Squirrelmail-Lösung, die uns nicht gefallen hat.

Das heißt, wir senden HTML-Code wie diesen an den Benutzer (im $somethingAllgemeinen bedeutet dies eine bereits ordnungsgemäß maskierte Variable) über eine Schaltfläche, die er in unserem internen Portal drückt. Dies ist die Version, in der vorderste Front einfach einen geraden Durchgang macht:

<html>
<body onLoad="javascript:document.forms[0].submit()">
<noscript>
 <h1>Redirecting you to $title</h1>
 <p>If you are not taken to $title within 15 seconds,<br />
    please click the button below:</p>
 </noscript>
 <form method="POST"
       action="https://$exchangehost/owa/auth/owaauth.dll" 
       name="logonForm" 
       enctype="application/x-www-form-urlencoded" autocomplete="off">
   <input type="hidden" name="destination" value="https://$exchangehost/OWA/" />
   <input type="hidden" name="flags" value="0" />
   <input type="hidden" name="forcedownlevel" value="0" />
   <input type="hidden" name="trusted" value="0" />
   <input type="hidden" name="username" value="$uid" />
   <input type="hidden" name="password" value="$password" />
   <input type="hidden" name="isUtf8" value="1" />
   <noscript>
     <input type="submit" value="$title" />
   </noscript>
 </form>
 </body>
 </html>

Dies geschieht hauptsächlich, indem das Anmeldeformular kopiert und alles in ausgeblendete Felder umgewandelt wird. Sie müssen jedoch die URL für die Aktion von /owa/auth.owanach ändern /owa/auth/owaauth.dll.

Wir haben auch versucht, die Authentifizierung bei OWA von vornherein durchführen zu lassen. Hier ist das Formular dafür (das <body onLoad=...>und der Rest ist im Grunde das gleiche):

<form method="post" action="https://$exchangehost/CookieAuth.dll?Logon">
  <input type="hidden" name="curl" value="Z2FowaZ2F" />
  <input type="hidden" name="flags" value="0" />
  <input type="forcedownlevel" value="0" />
  <input type="formdir" value="1" />
  <input type="rdoPblc" value="1" />
  <input type="username" value="$domain\$uid" />
  <input type="password" value="$password" />
</form>

Die Lösung von Bill Thompson für Github ist gut und spielt eine wichtige Rolle in (meiner) Jasig-Konferenzpräsentation zur ClearPass CAS-Erweiterung. Aufnahme mit dem Titel ClearPass - Eine CAS-Erweiterung, die die Wiedergabe von Anmeldeinformationen auf Vimeo ermöglicht.

Ich verwende CAS Single Sign-On für Exchange 2007.

Fügen Sie in MS Exchange IIS CAS Server ein neues virtuelles Verzeichnis hinzu index.aspx.

Verwenden Sie den Link https://wiki.jasig.org/display/CAS/CASifying+Outlook+Web+Access+2 .

bean id="OWAConnection"
   p:host="real-owa-server"
   p:port="443"
   p:scheme="https"
   p:owaauth="/exchweb/bin/auth/owaauth.dll"
   p:owalogon="/exchweb/bin/auth/owalogon.asp"
   p:trusted="4"
   p:flags="4"
   p:destination="/exchange/"

Ändern Sie owaauth.dll in diese index.aspx.

Index.aspx wird - Benutzer empfangen, vom CAS über den CAS-Anmeldefluss übergeben - Benutzer speichern, in Anwendungsvariable verschlüsselt übergeben Wenn der Benutzer von CAS erfolgreich authentifiziert wurde

Konfigurieren Sie in login.aspx unter MS Exchange OWA die Navigation zu Ihrer index.aspxDatei.

Dies überprüft die Anmeldung mit CAS, wenn sie nicht zum CAS-Anmeldeformular umgeleitet wird.

Wenn sich der Benutzer bei CAS authentifiziert, wird der Benutzer gesendet und an Ihre Indexdatei übergeben und im Speicher gespeichert.

Wenn der Browser zu index.aspx umleitet, überprüft er, ob der Benutzer von CAS authentifiziert wurde, erhält den Benutzernamen von CAS, ruft das Kennwort aus dem Anwendungsspeicher ab und authentifiziert den Benutzer mit owaauth.dllund speichert das Cookie im Client-Browser.

Danach wird der Browser zu OWA umgeleitet.