You can federate your local identity store with the Office 365 environment. The main reason to use federated authentication is so users only fill out their password in trusted environments. This blog highlights what makes a secure login. When using federated authentication, which Microsoft calls 'modern authentication', you can either do this with SURFconext or directly with the Microsoft cloud. Federated authentication is limited by the possibilities of the underlying protocols. Both Microsoft federated login and SURFconext use those protocols. From a functional point it makes no difference whether you federate through SURFconext or using Microsoft federated authentication.
Note that even though users will authenticate using the SAML 2.0 protocol, all your Office 365 users need to be created (provisioned) in Azure AD, in order for 'Office 365' to recognise users that want to login. The tool that is being used to sync your domain users with the Azure AD is called AAD Connect.
When deciding whether to use SURFconext when you choose for federated login, keep in mind: when you contact Microsoft support to troubleshoot issues, it's likely they don't know SURFconext and SAML, and they might assume your problem is related to SURFconext. You could be told to check with the SURFconext team. Troubleshooting in a complex environment with large companies sometimes is complex enough, so it might help when the complete connection is Microsoft-only .
For institutions opting for federated authentication via SURFconext, the below information helps you configure such a connection.
This Step-by-Step guide contains several Powershell scripts and explanations for the following steps:
You can use parts of the scripts or run every step on the servers you want to configure. Be aware that every step has its own variables where you will have to set your own configuration options.
Step 1: Install the ADDS Role and DNS on your server(s)
***In case you already have a domain set up, you may skip this step and continue with step 2***
To use the AAD Connect tool and sync your users between your (on-premise) domain and the Azure AD, you would need a domain and a domain controller. This Powershell script, will install the ADDS role and DNS.
Step 2: Create a Group Managed Service Account and install ADFS Role
***In case you already have AD FS set up, you may skip this step and continue with step 3***
To be able to federate through ADFS, you would need to install the ADFS role. Also you will need a service account for ADFS. We used a Group Managed Account. Check this blog for more information about Group Managed Service Accounts.
We used a scenario without an ADFS Proxy (WAP), but you could add an ADFS proxy to this setup.
Step 3: Run and finish the AAD Connect tool setup before you continue
You will need to have a working AAD Connect configuration before continuing with the next steps. In case you don't have a working AAD Connect setup, please follow the instructions in the setup guide below.
This guide contains the configuration steps that we used and it is a working configuration for our reference topology. Of course there are many other configurations possible, so please choose the configuration, needed for your topology.
You can download the AAD Connect tool here.
You can find more information on supported topologies on this page.
There is also more information to be found about the express or custom installation of AAD Connect.
Step 4: Create the mandatory claims descriptions for SURFconext
***In case you already have a SURFconext connection, you may skip this step and continue with step 5***
In this step you will create the (mandatory) claims descriptions for SURFconext
Step 5: Create the SURFconext Relying Party Trust with the mandatory claims rules
***In case you already have a SURFconext connection, you may skip this step and continue with step 6***
In this step you will create (mandatory) claims rules. There are claims rules that are mandatory for SURFconext, but also claims rules that are mandatory for the use of Azure AD.
One of the attributes that will have to be provided, is the ImmutableID. This claims rule is included in the text file below. You can find more information about AD FS claims and Azure AD on this site.
Also needed is an attribute containing the user's mail address. Azure AD expects this attribute to have the name IDPEmail. However, when your Identity Provider already discloses the standard SURFconext attribute urn:mace:dir:attribute-def:mail, its value is automatically mapped to the IDPEMail attribute by SURFconext. When you are using this page for your configuration, you won't have to add a separate claims rule for IDPEmail.
You can download the required claim issuance rules file for the $ClaimIssuanceFile parameter here: ClaimIssuanceRules.txt
Step 6: Configure the SURFconext Federation
In this step, you will configure the SURFconext Federation for Office 365. You will have to send your metadata URL to SURFconext, so they can configure it. This metadata URL usually looks like this: https://adfs.yourdomain.nl/FederationMetadata/2007-06/FederationMetadata.xml .
You will receive a passive logon URI from SURFconext, that you will have to use for the $sso parameter in the script below. You can find the certificate key on this page, that you will need for the $crt parameter in the script below.
Regarding the value for '$idp = "YOUR FEDERATION SERVICE IDENTIFIER URL"':
- is the URL that is configured in AD FS. You can find this at the following location: Start -> Administrative Tools -> AD FS Management .
- right click on Service in the AD FS management console and click Edit Federation Service Provider
- Use the value from Federation Service Identifier URL:
Regarding the value for '$sso = "THE PASSIVE LOGON URI YOU RECEIVED FROM SURFCONEXT"':
- That value is included in the SAML metadata. If you don't know how to retrieve it, you can request SURF via an email to support@surfconext.nl in which you explain what you're doing and you would like to receive the 'instellings-specifieke SSO-locatie'.
- A sample value looks like "https://engine.surfconext.nl/authentication/idp/single-sign-on/key:20181213/377be5f3a9544971303163432419360" (fictitious value)
Step 7: Set Modern authentication on Exchange Online to be able to use rich clients
When your users are using Microsoft Outlook or other rich clients, you will have to enable modern authentication. This can be done with the script below.
Debugging and helpful tools
To check if you send the required claims to SURFconext, you can use this debug tool.
Overview
Community Forums
Content Tools
1 Comment
Pieter van der Meulen
Very useful info this. I used it to setup a new ADSF for testing with SURFconext (1 DC server and a separate ADFS server). A few questions and remarks on this procedure:
@Step 2:
Add-KdsRootKeyandNew-ADServiceAccountrequire domain admin accountInstall-WindowsFeature-nameWeb-Server-IncludeManagementTools"? ADFS 3.0 does not require IiS anymore as ADFS < 3.0 did.@Step3: Full disclosure: I skipped this step
@Step4: Brilliant! That saves a lot of clicking.
@Step5:
Add-ADFSRelyingPartyTrust" does not have an option named "-AccessControlPolicyName". To allow users to authenticate using ADFS I had to add a Rule under "Issuance Authorization Rules" to permit users to login:=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");Not required, but "more correct" IMO is to add a NameID claim that sets a transient NameID in the Subject under "Issuance Transform Rules":
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:transient");