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 without SURFconext, the below information helps you configure such a connection. 

This Step-by-Step guide contains several Powershell scripts and explanation for the following steps:

You can use parts of this script 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. In case you already have a domain set up, you can skip this step.

Install ADDS Role and DNS 
########################################### INSTALL ADDS ROLE AND DNS ########################################### 
$ComputerName = "YOUR COMPUTER NAME"
$DomainName = "YOUR DOMAIN NAME"
$DatabasePath = "C:\Windows\NTDS"
$DomainMode = "Win2012R2"
$DomainNetbiosName = "YOUR DOMAIN NETBIOSNAME"
$ForestMode = "Win2012R2"
$Logpath = "C:\Windows\NTDS"
$SysvolPath = "C:\Windows\SYSVOL"

#### Get Windows features to check if the ADDS role is available ####
Get-windowsfeature
 
#### Installing the Active Directory Domain Service ####
Install-windowsfeature AD-Domain-Services
 
#### Import the required modules for the ADDS Deployment ####
Import-Module ADDSDeployment
 
#### Install new Domain Controller in a new Forest ####
Install-ADDSForest -DomainName $DomainName -NoDnsOnNetwork -DatabasePath $DatabasePath -DomainMode $DomainMode -DomainNetbiosName $DomainNetbiosName -ForestMode $ForestMode -LogPath $Logpath -SysvolPath $SysvolPath -CreateDnsDelegation:$false -InstallDns:$true -NoRebootOnCompletion:$false -Force:$true
 
#### Install ADDS Tools ####
Import-Module ServerManager
Add-WindowsFeature RSAT-ADDS-Tools

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.


Create a gMSA and install ADFS Role 
########################################### INSTALL ADFS ROLE ########################################### 
$gMSAName = "gMSA-ADFS"
$DNSHostName = "YOUR ADFS DNS HOSTNAME (EG: adfs.yourdomain.com)" 
$ServPrincName = "host/YOURADFSDNSHOSTNAME (EG: host/adfs.yourdomain.com)"
$Path = "SERVICE ACCOUNT PATH (EG: CN=Managed Service Accounts,DC=yourdomain,DC=com"
 
#### To create a group managed service account, you have to create a KDS Root Key ####
#### Create KDS Root Key (The -10 is only usefull in a testing environment and will ensure immediately effectiveness) ####
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
 
#### Create new Group Managed Service Account
New-ADServiceAccount -Name $gMSAName -DNSHostName $DNSHostName -ServicePrincipalNames $ServPrincName -Path $Path
 
#### Install IIS Role ####
Install-WindowsFeature -name Web-Server -IncludeManagementTools
 
#### Install ADFS Role ####
Install-windowsfeature adfs-federation -IncludeManagementTools

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.
You can find more information on supported topologies.
There is also more information to be found about the express or custom installation of AAD Connect.

When you've finished the AAD Connect tool setup and let it configure your AD FS Farm, you will be able to logon to Office 365 via your AD FS servers.

  • No labels