7 votes

freiheit avatar

Options Single-Signon pour Exchange 2010

Demandé el 21 de Juillet, 2010
Quand la question a-t-elle été
6471 affichage
Nombre de visites la question a
3 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Nous travaillons sur un projet visant à migrer le courrier électronique des employés d'Unix/open-source (courier IMAP, exim, squirrelmail, etc) vers Exchange 2010, et nous essayons de trouver des options pour le single-signon pour Outlook Web Access. Jusqu'à présent, toutes les options que j'ai trouvées sont très laides et "non supportables", et peuvent tout simplement ne pas fonctionner avec Forefront.

Nous avons déjà JA-SIG CAS pour le single-signon à base de jetons et Shibboleth pour SAML. Les utilisateurs sont dirigés vers un portail interne simple (un CGI Perl, en fait) qu'ils utilisent pour se connecter à la plupart des choses. Nous avons un cluster HA OpenLDAP qui est déjà synchronisé avec un autre domaine AD et qui sera synchronisé avec le domaine AD qu'utilisera Exchange. CAS s'authentifie par rapport à LDAP. Le portail s'authentifie par rapport à CAS. Shibboleth s'authentifie auprès de CAS mais tire des données supplémentaires de LDAP. Nous nous dirigeons vers une authentification des services Web par rapport à CAS ou Shibboleth. (Les étudiants sont déjà sur Google Apps for Education authentifié par SAML/Shibboleth).

Avec Squirrelmail, nous avons un horrible hack lié à cette page de portail qui s'authentifie par rapport au CAS, récupère votre mot de passe original en clair (oui, je sais, c'est mal), et vous donne un formulaire HTTP pré-rempli avec tous les détails de connexion nécessaires à Squirrelmail avec des trucs javaScript onLoad pour soumettre immédiatement le formulaire.

Il semble difficile de savoir exactement ce qui est possible avec Exchange/OWA. "CAS" est à la fois l'acronyme de notre serveur unique et un composant d'Exchange. D'après ce que j'ai pu voir, il existe un module complémentaire pour Exchange qui permet d'utiliser SAML, mais uniquement pour fédérer des éléments tels que les informations de calendrier (libre/occupé), et non pour authentifier les utilisateurs. De plus, il coûte plus cher et il n'y a aucun moyen de l'expérimenter pour voir si on peut l'amener à faire ce que nous voulons.

Nos plans pour le cluster Exchange impliquent Forefront Threat Management Gateway (le nouveau ISA) dans la zone démilitarisée (DMZ) pour les serveurs CAS.

Donc, la vraie question : Quelqu'un a-t-il réussi à faire en sorte qu'Exchange s'authentifie avec CAS (token-based single-signon) ou SAML, ou avec quelque chose que je peux raisonnablement faire s'authentifier avec l'un d'entre eux (comme n'importe quoi qui acceptera l'authentification d'Apache) ? Avec Forefront ?

Si ce n'est pas le cas, quelqu'un a-t-il des conseils pour convaincre OWA Forms Based Authentication (FBA) de nous laisser en quelque sorte "pré-connecter" l'utilisateur (se connecter en tant que tel et renvoyer des cookies à l'utilisateur, ou donner à l'utilisateur un formulaire pré-rempli qui se soumet automatiquement comme nous le faisons avec Squirrelmail). C'est l'option la moins appréciée pour un certain nombre de raisons, mais elle répondrait (tout juste) à nos besoins. D'après ce que m'a dit le responsable de l'implémentation de Forefront, nous devrons peut-être configurer OWA avec une authentification de base et utiliser des formulaires dans Forefront pour l'authentification, il est donc possible que ce ne soit pas possible.

J'ai trouvé CasOwa Mais il ne mentionne qu'Exchange 2007, il a l'air plutôt effrayant et, d'après ce que je peux voir, il s'agit essentiellement du même hack OWA FBA que j'avais envisagé, légèrement plus intégré au serveur CAS. Il ne semble pas non plus que beaucoup de personnes aient eu beaucoup de succès avec lui. Et il se peut qu'il ne fonctionne pas avec Forefront.

Il y a aussi " CASifying Outlook Web Access 2 "Mais cette solution me fait également peur et implique la mise en place d'une configuration proxy complexe, ce qui semble plus susceptible de se briser. Et, encore une fois, il ne semble pas que cela puisse fonctionner avec Forefront.

Est-ce que je rate quelque chose avec Exchange SAML (OWA Federated whatchamacallit) où il est possible de configurer l'authentification des utilisateurs et pas seulement l'autorisation d'accès libre/occupé ?

Demandé el 21 de Juillet, 2010 par freiheit

Réponses

Trop de publicités?

4voto

freiheit avatar
freiheit Points 14144

Nous avons décidé que la combinaison de l'ajout de "ClearPass" à CAS et de la modification de la configuration d'Exchange allait être trop difficile à maintenir, de sorte que notre solution finale est quelque chose comme la solution Squirrelmail que nous n'aimions pas.

C'est-à-dire que nous envoyons du HTML comme ceci à l'utilisateur ( $something signifie généralement une variable déjà correctement échappée) à partir d'un bouton sur lequel ils appuient dans notre portail interne. Il s'agit de la version où forefront fait simplement un passage direct :

<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>

Cela provient principalement de la copie du formulaire de connexion et de la transformation de tous les champs en champs cachés, mais vous devez modifier l'URL de l'action de la manière suivante /owa/auth.owa a /owa/auth/owaauth.dll .

Nous avons également essayé de demander à forefront de procéder à l'authentification auprès d'OWA, voici le formulaire correspondant (l'élément <body onLoad=...> et le reste est fondamentalement le même) :

<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>
Répondu el 21 de Janvier, 2011 par freiheit (14144 Points )

1voto

lotirthos227 avatar
lotirthos227 Points 145

La solution de Bill Thompson sur github est bon, et figure en bonne place dans (ma) présentation à la conférence Jasig sur l'extension ClearPass CAS. Enregistrement intitulé ClearPass - Une extension de CAS permettant la reproduction des justificatifs d'identité. sur Vimeo.

Répondu el 12 de Janvier, 2011 par lotirthos227 (145 Points )

0voto

Utilisateur non enregistré avatar
Utilisateur non enregistré Points 0

J'utilise l'authentification unique CAS pour Exchange 2007.

Dans le serveur CAS MS Exchange IIS, ajouter un nouveau répertoire virtuel a index.aspx .

En utilisant le lien 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/"

Changez owaauth.dll pour cet index.aspx.

Index.aspx va - recevoir l'utilisateur et le mot de passe du CAS via le flux de connexion du CAS - sauvegarde de l'utilisateur, du mot de passe crypté dans la variable Application Lorsque l'utilisateur est authentifié avec succès par le CAS

Dans login.aspx sur MS Exchange OWA, configurez pour naviguer vers votre index.aspx archivo.

Ceci vérifie la connexion avec le CAS si elle n'est pas redirigée vers le formulaire de connexion du CAS.

Lorsque l'utilisateur s'authentifie avec le CAS, il soumet l'utilisateur et le mot de passe à votre fichier d'index et le sauvegarde en mémoire.

Lorsque le navigateur redirige vers index.aspx, il vérifie que l'utilisateur a été authentifié par le CAS, obtient le nom d'utilisateur du CAS, obtient le mot de passe de la mémoire de l'application et authentifie l'utilisateur avec owaauth.dll et enregistre le cookie dans le navigateur du client.

Après cela, il redirige le navigateur vers OWA.

Répondu el 22 de Juillet, 2010 par Utilisateur non enregistré (0 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X