Tag Archives: federation

Implementing Active Directory Federation Services step-by-step part II

In the previous blog (Implementing Active Directory Federation Services step-by-Step) I have showed you how to install and configure Active Directory Federation Services (ADFS) in your internal network and DMZ, capable of handling Office 365 authentication request. In this blog I’ll show you how to configure Office 365 and how to test it.

Federated Domains

In a typical managed domain, the user accounts and password hashes are synchronized to Azure Active Directory. Office 365 uses Domain Controllers in Azure AD to authenticate the users and grant them access to the resources in the cloud.

In a federated domain, the user accesses the Office 365, but access is denied, and the request is redirected to Azure Active Directory. There, the home realm (the user’s domain) is discovered and the request is redirected to the ADFS server based on the home realm. If my user account is j.wesselius@exchangelabs.nl, my home realm is exchangelabs.nl and the request is redirected to the federation server that was created earlier, and that was used to configure the domain in Azure Active Directory.

I did a session on this at IT Dev Connections in 2017 (in San Francisco), the following is one animated slide that can be downloaded which shows the flow between a client, Office 365, Azure AD and the on-premises ADFS and Domain Controller:

ADFS Federation Flow

To get this working, the domain in Azure Active Directory needs to be converted to a federated domain so that Azure AD knows any authentication request needs to be redirected to the on-premises ADFS environment.

When adding a domain to Azure Active Directory it is automatically created as a managed domain. As said before, authentication takes places against Domain Controllers in Azure AD. You can check a domain using the Get-MsolDomain -DomainName exchangelabs.nl PowerShell command as shown in the following screenshot:

Get-MsolDomain

To convert this to a federated domain, start a PowerShell command (with elevated privileges) and enter the following commands:

[PS] C:\> Connect-MsolService

[PS] C:\> Set-MsolADFSContext -Computer ams-adfs01.labs.local

[PS] C:\> Convert-MsolDomainToFederated -DomainName Exchangelabs.nl

Note. Use the FQDN of the local first ADFS server with the Set-MsolADFSContext command, not the federation URL

This will connect the existing on-premises infrastructure to Azure AD, and convert the domain to a federated domain. Now, when checking the domain in Azure AD using the same command as before you’ll see it now is a federated domain:

Set-MsolAdfsContext Exchangelabs

In in the ADFS Management Console you’ll a new Relying Party Trust (RPT) for use with Office 365:

ADFS Relying Party Trust

To get more into detail in Azure AD about the federation settings, you can use the Get-MsolDomainFederationSettings command which shows more information:

Get-MsolDomainFederationSettings

Clearly visible are the Logon, Issuer and LogOffUri, which point to our on-premises ADFS implementation. Even more information can be retrieved using the Get-MsolFederationProperty command as shown in the following screenshot:

Get-MsolFederationProperty

To test the new configuration, navigate to the Microsoft Online Portal and login using an account with the domain we just configured, i.e. j.wesselius@exchangelabs.nl:

Microsoft Online Portal

When selecting this account, Azure AD determines the home realm (exchangelabs.nl) and redirect to the on-premises URL as found in the federation settings in Azure AD. You’ll see this happen on the fly in your browser:

Taking you to your organizations sign-in page

And a few seconds later we are redirected to our on-premises ADFS environment:

ADFS Federation Sign-in page

Clearly visible is the Federation Service display Name which was configured with the first ADFS server in the previous blogpost.

Enter your password, and how wonder, MFA is still working as well (which was a pleasant surprise for me 😊):

ADFS Exchangelabs MFA

Another interesting test is using the Remote Connectivity Analzyer ( (https://aka.ms/exrca) which has a Single Sign-On test. Navigate to the Remote Connectivity Analyzer, click the Office 365 tab and select the Office 365 Single Sign-On test radio button.

Enter username and password, do the verification code test and await the results. You’ll see something similar as the following screenshot:

Remote Connectivity Analyzer Single Sign-On Test

The logon attempt was successful, but more interesting is that you can expand all test steps to see what’s going on under the hood and try to understand how ADFS works.

Summary

In the previous two blogposts I demonstrated how to install and configure ADFS in your on-premises infrastructure. I installed only one ADFS server and one WAP proxy, which is far from a high available environment. Why high available? Without the ADFS server it is no longer possible to logon to any Office 365 service, so a high available infrastructure is a requirement for any ADFS implementation.

But customers are moving to the cloud to decommission their on-premises solutions, and with ADFS we’re building an on-premises solution for authenticating cloud solutions. But for compliancy reasons it might be needed to authenticate against local domain controllers (no passwords in the cloud for example). On the other hand, you can use Pass Through Authentication (PTA, see my blogpost Azure AD Connect Pass-through authentication) for this as well. PTA doesn’t offer as much possibilities as ADFS yet, but it is improving.

Is ADFS future proof? Some people say it isn’t, but as long as I find articles like What’s new in Active Directory Federation Services for Windows Server 2019 on the Microsoft website I don’t see too many issues with that.

More information

Free/busy not working from Exchange Online to Exchange on-premises

Recently users started to complain that free/busy information was not available, more specifically users that had their mailbox in Exchange Online were not able to retrieve availability information from their colleagues or meeting rooms that were still in Exchange 2010 on-premises.

Complaints came from multiple users from multiple countries, there are multiple sites with multiple Exchange 2010 servers with multiple breakout points to the Internet, so the issue was consistent and not really related to only one Exchange 2010 server. And it was only happening cross-premises, and only from Exchange Online to Exchange 2010. From Exchange 2010 to Exchange Online it was working flawlessly, so was between mailboxes in Exchange 2010.

You see this happen often right after configuring an Exchange hybrid configuration with the HCW, but in my case it had been working fine for quite some time, so it had to be related to something we had changed recently. We had WLAN changes (new provider), Windows Update, Exchange 2010 rollup updates, SSL certificates, new Send and Receive Connectors, but nothing that immediately pointed in the right direction. To make things worse, the Remote Connectivity Analyzer (your first stop when troubleshooting) didn’t see any issues, everything worked well. Autodiscover returned the correct information from mailboxes in Exchange Online and Exchange 2010, and the free/busy test in RCA worked well.

Note. A lot of people don’t know this feature, but in the Remote Connectivity Analyzer you can check free/busy in a hybrid environment. Just select the Free/Busy radio button under the Office 365 tab as shown in the following screenshot:

Remote Connectivity Analyzer FreeBusy

My mailbox was in Exchange Online and I also did experience the issue, but at the same time I was able to open the calendar cross-premises. Ok, this is Outlook Anywhere and not Exchange Web Services (which is used for free/busy) but at least it ruled out a firewall issue.

When running the Get-OrganizationRelationship command, I could verify the TargetAutodiscoverEpr property, which was set to the correct Autodiscover URL. Using the TargetSharingEpr property instead of the TargetAutodiscoverEpr property didn’t help.

Get-FederationInformation command with the -DomainName switch… all looks good.
Security on the Virtual Directory? Running these commands often solve unexpected issues:

Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory -WSSecurity $true
Get-WebServicesVirtualDirectory -Server WPGREXC01 | Set-WebServicesVirtualDirectory -WSSecurity $True

Again, no success… Time for deeper troubleshooting. At this moment Microsoft support was already involved as well….

When testing I could see the request entering the Exchange 2010 server in the IIS logs, but the servers returned a 500 Error, so something in the request was causing issues on the Exchange server:


2019-10-14 06:45:06 192.168.25.119 POST /ews/exchange.asmx/WSSecurity – 443 – 52.97.155.157 ASProxy/CrossForest/Directory/https/15.20.2347.020/MailTips – 500 0 0 31


2019-10-14 06:45:33 192.168.25.119 POST /ews/exchange.asmx/WSSecurity – 443 – 52.97.140.165 ASProxy/CrossForest/Directory/https/15.20.2347.020/MailTips – 500 0 0 31


2019-10-14 06:45:51 192.168.25.119 POST /ews/exchange.asmx/WSSecurity – 443 – 52.97.139.125 ASProxy/CrossForest/Directory/https/15.20.2347.020/Freebusy – 500 0 0 15


2019-10-14 06:45:51 192.168.25.119 POST /ews/exchange.asmx/WSSecurity – 443 – 52.97.158.5 ASProxy/CrossForest/Directory/https/15.20.2347.020/MailTips – 500 0 0 31


2019-10-14 06:45:51 192.168.25.119 POST /ews/exchange.asmx/WSSecurity – 443 – 52.97.139.125 ASProxy/CrossForest/Directory/https/15.20.2347.020/MailTips – 500 0 0 31

The next step to try was to recycle the AutodiscoverAppPool and the ExchangeServicesAppPool in the IIS Manager, but unfortunately this didn’t help.
After looking out of the window what might be the issue I had another look at the eventlog on the Exchange server, and found the following certificate warning:

EventID 403 Certificate is expired


Log Name: Application
Source: MSExchange Common
Date: 10/16/2019 9:28:59 AM
Event ID: 403
Task Category: Configuration
Level: Error
Keywords: Classic
User: N/A
Computer: Exchange.contoso.com
Description:
The certificate named ‘791BC6AD9893AA570DF03452B4F8069C8A743C29’ in the Federation Trust ‘Microsoft Federation Gateway’ is expired. Please review the Federation Trust properties and the certificates installed in the certificate store of the server.

This rings a bell. The certificate with the thumbprint mentioned in the error message is not on the Exchange server, but it’s in the Microsoft Federation Gateway. I didn’t see this earlier, but when checking the federation with Get-FederationTrust | FL you can see certificate information, and one certificate expired some time ago. July 2019 to be precise.

You can also run the Test-FederationTrust on the Exchange server. If you ran into this issue, you should see an error message like Failed to validate delegation token in the TokenValidation section.

Fixing this is easy, just run the following command:

Get-FederationTrust | Set-FederationTrust -RefreshMetadata

After running this command it works like a charm.

This only happens in Exchange 2010 (in Exchange 2013 and higher it is fixed automatically), and looking at the support chances are you are not running Exchange 2010 anymore when other certificates are renewed. You can running the command mentioned before on a regular basis, or you can use a scheduled task to perform this automatically on a regular basis.

Schtasks /create /sc Daily /tn FedRefresh /tr “C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
-version 2.0 -command Add-PSSnapIn Microsoft.Exchange.Management.PowerShell.E2010;
$fedTrust = Get-FederationTrust;Set-FederationTrust -Identity $fedTrust.Name -RefreshMetadata” /ru System

So why didn’t we notice this in the first place? The certificate change was announced by Microsoft and other community blogs, but this was summer holiday time. Also lack of resources in IT Staff didn’t help either. Too bad, but in the end it was fixed (with help of Microsoft support 😊)

More information