locked
ADFS3/AD to CAS/Shibboleth/OpenLDAP authentication for accounts not in OpenLDAP RRS feed

  • Question

  • We have integrated ADFS 3 with Shibbeleth which uses CAS as it's authentication module which points to OpenLDAP as its authentication source. We have an IDMS that creates accounts in both AD and OpenLDAP. ADFS3 is federated with Office 365. This setup is not production yet as we had a problem with mailboxes that were not created through the IDMS. Say Shared Mailboxes and such. So since these accounts are not in OpenLDAP and only in AD we can't login to them since ADFS hands off the authentication to Shibboleth which points at CAS which points at OpenLDAP. Another problem is that CAS/Shibboleth/OpenLDAP are hosted on AWS off campus. So we can't just point CAS at AD as that would create a campus dependency which we were trying to get away from.

    So the question is how do we setup ADFS 3 to switch back to it's authentication mechanism for these set of accounts?

    Also we are using an F5 Load Balancer in front of the ADFS 3 servers which is injecting a cookie that tells ADFS to choose Shibboleth for it's authentication source. So the users don't see the Home Realm Discovery page. We want them to only see the customized CAS auth page and login and get into Office 365. Which for most users would be via our CAS enabled Portal so they would just click the button for Office 365 and their in. No secondary authentication required like it is now with ADFS 2.1 that we have in production now.

    Tuesday, August 2, 2016 9:06 PM

All replies

  • When ADFS has more than one Claim Provider Trust (and it is your case, you have AD - the default, and Shib), you will be prompted to chose where you are coming from (aka Home Realm Discovery - HRD). This is where the user will choose where it is coming from.

    You have bypassed this with F5 injecting cookie (with also implies that you are ending the tunnel at the F5 level, which by the way break device authentication or any kind of user's certificate based auth -which you obviously do not use as of now). When in fact, you can bypass the HRP at the ADFS level in two ways:

    • Associate a default Claim Provider Trust for one specific Relying Party Trust
    • Configure ADFS to always redirect the user to AD for auth if the user is connected locally (so if the user is coming through a WAP server, it will be prompted to chose the claim provider -aka IdP-, if it is connected internally directly on the ADFS server, then Windows SSO -eventually, since you can actually configure the authentication policy you want).

    These options are described in the Home Realm Discovery section of the following page: https://technet.microsoft.com/en-us/library/dn280950(v=ws.11).aspx (there is another way to customize HRD with UPN but I don't think this is relevant in your situation).

    You cannot redirect a user based on group membership at the HRD level since the session is not authenticated yet (so ADFS doesn't know about the user yet). You could play with Agent String and inject some custom JavaScript based on that but that would imply that you create custom JavaScript, tweak the User Agent string of the browser of the users using Office 365 (which imply that you manage those devices) and disable your HRD bypass on F5.

    You could also configure the Azure AD Relying Party trust (the one used by Office 365) to always use ADFS for IdP but it will conflict with the F5 here I guess. You could also use Shib and trust Azure AD directly... As a classic SAML2 IdP. BUt you loose functionality on Office 365 (note that Shib isn't in the list of officially supported IdP though):

    You can also consider ADFS for Windows Server 2016 (currently TP5). It has the ability to use LDAP v3 compliant directories for IdP, in that case you will not need Shib anymore: https://technet.microsoft.com/windows-server-docs/identity/ad-fs/operations/configure-ad-fs-to-authenticate-users-stored-in-ldap-directories


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Wednesday, August 3, 2016 2:11 PM