Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We're working on a project to migrate employee email from Unix/open-source (courier IMAP, exim, squirrelmail, etc) to Exchange 2010, and trying to figure out options for single-signon for Outlook Web Access. So far all the options I've found are very ugly and "unsupportable", and may simply not work with Forefront.

We already have JA-SIG CAS for token-based single-signon and Shibboleth for SAML. Users are directed to a simple in-house portal (a Perl CGI, really) that they use to sign in to most stuff. We have an HA OpenLDAP cluster that's already synchronized against another AD domain and will be synchronized with the AD domain Exchange will be using. CAS authenticates against LDAP. The portal authenticates against CAS. Shibboleth authenticates with CAS but pulls additional data from LDAP. We're moving in the direction of having web services authenticate against CAS or Shibboleth. (Students are already on SAML/Shibboleth authenticated Google Apps for Education)

With Squirrelmail we have a horrible hack linked to from that portal page that authenticates against CAS, gets your original plaintext password (yes, I know, evil), and gives you an HTTP form pre-filled with all the necessary squirrelmail login details with javaScript onLoad stuff to immediately submit the form.

Trying to find out exactly what is possible with Exchange/OWA seems to be difficult. "CAS" is both the acronym for our single-signon server and an Exchange component. From what I've been able to tell there's an addon for Exchange that does SAML, but only for federating things like free/busy calendar info, not authenticating users. Plus it costs additional money so there's no way to experiment with it to see if it can be coaxed into doing what we want.

Our plans for the Exchange cluster involve Forefront Threat Management Gateway (the new ISA) in the DMZ front-ending the CAS servers.

So, the real question: Has anybody managed to make Exchange authenticate with CAS (token-based single-signon) or SAML, or with something I can reasonably likely make authenticate with one of those (such as anything that will accept apache's authentication)? With Forefront?

Failing that, anybody have some tips on convincing OWA Forms Based Authentication (FBA) into letting us somehow "pre-login" the user? (log in as them and pass back cookies to the user, or giving the user a pre-filled form that autosubmits like we do with squirrelmail). This is the least-favorite option for a number of reasons, but it would (just barely) satisfy our requirements. From what I hear from the guy implementing Forefront, we may have to set OWA to basic authentication and do forms in Forefront for authentication, so it's possible this isn't even possible.

I did find CasOwa, but it only mentions Exchange 2007, looks kinda scary, and as near as I can tell is mostly the same OWA FBA hack I was considering slightly more integrated with the CAS server. It also didn't look like many people had had much success with it. And it may not work with Forefront.

There's also "CASifying Outlook Web Access 2", but that one scares me, too, and involves setting up a complex proxy config, which seems more likely to break. And, again, doesn't look like it would work with Forefront.

Am I missing something with Exchange SAML (OWA Federated whatchamacallit) where it is possible to configure to do user authentication and not just free/busy access authorization?

share|improve this question
    
We'll be running into this problem in a month or two! We use CAS on Exch2007 with Forms-based-auth, and it works. –  sysadmin1138 Jul 20 '10 at 23:19

3 Answers 3

Bill Thompson's solution on github is good, and features prominently in (my) Jasig conference presentation on the ClearPass CAS extension. Recording entitled ClearPass - A CAS Extension Allowing Credential Replay on Vimeo.

share|improve this answer
up vote 4 down vote accepted

We decided that the combination of adding "ClearPass" to CAS and modifying the Exchange setup was going to be too hard to maintain, so our final solution is something like the squirrelmail solution that we didn't like.

That is, we send HTML like this to the user ($something generally means an already properly escaped variable) from a button they push in our in-house portal. This is the version where forefront is simply doing a straight pass-thru:

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

Mainly this is from copying the login form and making everything into hidden fields, but you need to change the URL on the action from /owa/auth.owa to /owa/auth/owaauth.dll.

We also tried having forefront do the authentication to OWA, here's the form for that (the <body onLoad=...> and the rest is basically the same):

<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>
share|improve this answer

I use CAS single sign-on for Exchange 2007.

In MS Exchange IIS CAS Server, add new virtual directory has index.aspx.

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

Change owaauth.dll to this index.aspx.

Index.aspx will - receive user, pass from CAS though CAS login flow - save user, pass encrypted in Application variable When user authenticated successful by CAS

In login.aspx on MS Exchange OWA, configure to navigate to your index.aspx file.

This checks login with CAS if not redirected to CAS login form.

When user authenticated with CAS it will submit user and pass to your index file and saved to memory.

When the browser redirects to index.aspx, it checks the user has been authenticated by CAS, get username from CAS, get password from Application memory and authenticate user with owaauth.dll and save cookie to the client browser.

After that it redirects the browser to OWA.

share|improve this answer
    
So are you saying you did this without the intermediate proxy server that's described at that page? –  freiheit Jul 23 '10 at 20:59
    
Any clue if this will work that way with Exchange 2010? –  freiheit Jul 24 '10 at 17:46

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.