Opções de logon único para o Exchange 2010

Question

Estamos trabalhando em um projeto para migrar emails de funcionários do Unix / open-source (correio IMAP, exim, squirrelmail, etc) para o Exchange 2010 e tentando descobrir opções de conexão única para o Outlook Web Access. Até agora, todas as opções que encontrei são muito feias e "insuportáveis" e podem simplesmente não funcionar com o Forefront.

Já temos JA-SIG CAS para conexão única baseada em token e Shibboleth para SAML. Os usuários são direcionados para um portal interno simples (um Perl CGI, na verdade) que eles usam para entrar na maioria das coisas. Temos um cluster HA OpenLDAP que já está sincronizado com outro domínio do AD e será sincronizado com o domínio do AD que o Exchange usará. CAS autentica contra o LDAP. O portal autentica contra o CAS. O Shibboleth autentica com o CAS, mas extrai dados adicionais do LDAP. Estamos indo na direção de autenticar os serviços da Web contra o CAS ou o Shibboleth. (Os alunos já estão usando o Google Apps for Education autenticado pelo SAML / Shibboleth)

Com o Squirrelmail, temos um hack horrível vinculado a essa página do portal que autentica o CAS, obtém sua senha em texto original (sim, eu sei, mal) e fornece um formulário HTTP preenchido com todo o login necessário do squirrelmail detalhes com o material javaScript onLoad para enviar imediatamente o formulário.

Tentar descobrir exatamente o que é possível com o Exchange / OWA parece ser difícil. "CAS" é o acrônimo para nosso servidor de conexão única e um componente do Exchange. Pelo que eu pude dizer, há um addon para o Exchange que faz SAML, mas apenas para federar coisas como informações de calendário de disponibilidade, não autenticando usuários. Além disso, custa dinheiro adicional, então não há como experimentá-lo para ver se ele pode ser persuadido a fazer o que queremos.

Nossos planos para o cluster do Exchange envolvem o Forefront Threat Management Gateway (o novo ISA) na DMZ front-ending dos servidores CAS.

Então, a verdadeira questão: alguém conseguiu fazer com que o Exchange autenticasse com CAS (conexão única baseada em token) ou SAML, ou com algo que eu possa razoavelmente fazer autenticar com um desses (como qualquer coisa que aceite o apache? autenticação)? Com o Forefront?

Se isso falhar, alguém tem algumas dicas sobre como convencer a Autenticação Baseada em Formulários do OWA (FBA) a nos permitir de alguma forma "fazer o login prévio" do usuário? (faça login como eles e devolva os cookies para o usuário, ou forneça ao usuário um formulário pré-preenchido que seja enviado automaticamente, como fazemos com o squirrelmail). Esta é a opção menos preferida por vários motivos, mas satisfaz nossos requisitos. Pelo que ouvi do responsável pela implementação do Forefront, talvez tenhamos que definir o OWA como autenticação básica e fazer formulários no Forefront para autenticação, por isso é possível que isso não seja possível.

Eu encontrei CasOwa , mas ele menciona apenas o Exchange 2007, parece meio assustador e o mais perto que eu posso dizer é basicamente o mesmo hack OWA FBA que eu estava considerando um pouco mais integrado com o servidor CAS. Também não parecia que muitas pessoas tinham tido muito sucesso com isso. E isso pode não funcionar com o Forefront.

Há também " CASifying Outlook Web Access 2 ", mas esse me assusta também, e envolve a configuração de uma configuração de proxy complexa, que parece mais provável de quebrar. E, novamente, não parece que funcionaria com o Forefront.

Estou faltando alguma coisa com o SAML do Exchange (OWA Whatchamacallit Federated), onde é possível configurar a autenticação do usuário e não apenas a autorização de acesso livre / ocupado?

    

Answer 1

Decidimos que a combinação de adicionar "ClearPass" ao CAS e modificar a configuração do Exchange seria muito difícil de manter, então nossa solução final é algo como a solução squirrelmail que não gostamos.

Ou seja, enviamos HTML assim para o usuário ( $something geralmente significa uma variável que já escapou corretamente) de um botão que eles pressionam em nosso portal interno. Esta é a versão em que a vanguarda está simplesmente fazendo um passe direto:

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

Principalmente, isso é de copiar o formulário de login e transformar tudo em campos ocultos, mas é necessário alterar o URL da ação de /owa/auth.owa para /owa/auth/owaauth.dll .

Também tentamos ter prioridade na autenticação do OWA, eis o formulário para isso (o <body onLoad=...> e o resto é basicamente o mesmo):

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

    

Answer 2

A solução de Bill Thompson no github é boa, e apresenta destaque na apresentação da conferência (my) Jasig sobre a extensão ClearPass CAS. Gravação com direito a ClearPass - A Extensão CAS Permitindo Repetição de Credenciais no Vimeo.

    

Answer 3

Eu uso o logon único do CAS para o Exchange 2007.

No MS Exchange IIS CAS Server, adicionar novo diretório virtual tem index.aspx .

Usando o link link .

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

Altere owaauth.dll para este índice.aspx.

Index.aspx será - receber usuário, passar do CAS através do fluxo de login do CAS - salvar usuário, passar criptografado na variável Application Quando o usuário autenticado for bem sucedido pelo CAS

Em login.aspx no MS Exchange OWA, configure para navegar até o arquivo index.aspx .

Isso verifica o login no CAS se não for redirecionado para o formulário de login do CAS.

Quando o usuário autenticado com o CAS, ele enviará o usuário e passará para o seu arquivo de índice e será salvo na memória.

Quando o navegador redireciona para index.aspx, ele verifica se o usuário foi autenticado pelo CAS, obtém o nome de usuário do CAS, obtém a senha da memória do aplicativo e autentica o usuário com owaauth.dll e salva o cookie no navegador do cliente.

Depois disso, ele redireciona o navegador para o OWA.