Our office has switched almost entirely from Windows to Mac OS X, and our local server is due for replacement. We use Active Directory basically just for user authentication. We're considering replacing the current Windows Server with a Mac Mini running OS X Server. I don't yet know much about Open Directory, but is it possible for it to proxy authentication requests against a SAML v2 Identity Provider? I ask because we do quite a bit of work in a management system that is capable of acting as a SAML 2 IdP and we have set up Google Apps to authenticate against it. It would be extremely helpful to be able to authenticate local network resources against it as well.
Ldap – Open Directory and SAML Identity Provider
ldapmac-osx-serveropendirectorysingle-sign-on
Related Solutions
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>
Short answer: No. However, like @Nathan-C described, you can stand up the required services using Azure Iaas (either DC+DirSync+ADFS or DC+Dircync w/pwd sync) in order to achieve single sign-on between your your Office365 apps and your on-prem apps. You would need to deploy a VPN link between Azure and your local network.
Azure AD is NOT "regular" Active Directory.
Best Answer
Open Directory has an LDAP backend so you would use something like simplesamlphp with LDAP to get what you want.
However, some big caveats.
If you’re happy with your Windows Server experience there are very few compelling reason to switch to OS X and Open Directory. Apple has put a lot of work into making OS X a good Active Directory client. For a broad overview see their whitepapers on the topic:
Mountain Lion http://training.apple.com/pdf/wp_integrating_active_directory_ml.pdf
Mavericks http://training.apple.com/pdf/wp_integrating_active_directory_mav.pdf
Migrating from one directory system to another one is a big project and AD has superior vendor support from Microsoft. I say this as a system administrator who has used both products extensively. Every version of Open Directory I’ve deployed has had a significant bug sooner or later. The last one I encountered was a bug in Mountain Lion Server's LDAP authenticaton that caused the server to crash every ~24 hours when under normal load. The workaround was a script that restarted the service every hour. The real fix didn’t come until Mavericks was released. Apple never acknowledged the bug in any release notes, nor did normal AppleCare. To get any help (in this case, acknowledgement of the bug and that our workaround was the correct workaround) came from enterprise AppleCare.
If you really want to migrate to an Apple server then the enterprise support contract is mandatory. You can get more information on it here:
http://www.apple.com/support/products/enterprise/ossupport.html
Hope that helps.