Beveiligen en beperken van toegang tot Office 365 met aangepaste AD FS claimrules

Laatste update 04 juli 2022

Samen met onze klanten zijn we hard aan het werk geweest om toegang tot Office 365 workloads te beveiligen, zoals Exchange Online. In dit specifieke artikel willen we graag onze kennis delen over hoe toegang beperkt kan worden tot Exchange Online, specifieke netwerken en specifieke protocollen.

Eén van onze klanten gebruikte MobileIron voor het beveiligen van mobiele devices en wilde graag deze MDM oplossing integreren met Office 365.

Het lastige aan het beveiligen van toegang tot Exchange Online met MobileIron is dat MobileIron Sentry servers specifieke IP adressen vereisen naar Exchange. Zoals je je wel kunt voorstellen, de altijd veranderende Office 365 Cloud (met al zijn IP adressen) maakt het erg moeilijk om aan deze eis te voldoen. We moesten dus een andere technologie gebruiken, los van MobileIron, voor het beperken van de toegang tot Office 365.

We hebben er voor gekozen om aangepaste claimrules in AD FS te implementeren. De omgeving waar we deze oplossing voor hebben gebouwd was een AD FS 2016 farm. In deze nieuwe versie in AD FS zijn er verschillende veranderingen in hoe aangepaste claimrules worden gemaakt. AD FS 2016 gebruikte standaard Acces Control Policies en met deze policies was het niet mogelijk om zulke aangepaste claimrules te maken. Dus, voordat we gaan beginnen, gaan we eerst uitleggen hoe we in de oude situatie claimrules maakten.

Log in op één van de AD FS servers
Start PowerShell en voer deze commando’s uit
1. $ADFSRpt = Get-AdfsRelyingPartyTrust -Name “Microsoft Office 365 Identity Platform”
2. Set-AdfsRelyingPartyTrust -TargetRelyingParty $ADFSRpt -AccessControlPolicyName $null
3. Set-AdfsRelyingPartyTrust -TargetRelyingParty $ADFSRpt -IssuanceAuthorizationRules $null
4. Set-AdfsRelyingPartyTrust -TargetRelyingParty $ADFSRpt -IssuanceAuthorizationRules ‘@RuleName = “TEMP RULE” exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”%5D) => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”,Value = “true”);’
Open de AD FS Management Console
Navigeer naar “Relying Party Trusts” en selecteert de Office 365 relying party trust.
Klik op “Edit Access Control Policy” in het rechter menu, om het oude menu te vinden om “Issuance Authorization Rules” te configureren
Verwijder NIET de “TEMP RULE’ en sluit het venster niet.

Vanaf hier komt het coole gedeelte, wat eigenlijk gaat om het beperken van specifiek verkeer en protocollen in toegang tot specifieke netwerken, bijvoorbeeld SMTP of EWS verkeer.

Beperken van ActiveSync Protocol

Voeg een nieuwe regel toe
Vul de volgende custom claim in
Deze claim bevat het specifieke IP adres van de MobileIron Sentry server vanuit waar we ActiveSync verkeer naar Office 365 wel accepteren. Alle andere IP adressen worden geweigerd.

exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”%5D)
&& exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value == “Microsoft.Exchange.ActiveSync”])
&& NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip”, Value =~ “b82.125.45.23b”])
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Beperken van IMAP Protocol

Voeg een nieuwe regel toe
Vul de volgende custom claim in
Deze claim bevat het specifieke IP adres van de MobileIron Sentry server vanuit waar we IMAP verkeer naar Office 365 wel accepteren. Alle andere IP adressen worden geweigerd.

exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”%5D)
&& exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value == “Microsoft.Exchange.Imap”])
&& NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip”, Value =~ “b82.125.45.23b”])
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Beperken van SMTP Protocol

Voeg een nieuwe regel toe
Vul de volgende custom claim in
Deze claim bevat het specifieke IP adres van de MobileIron Sentry server vanuit waar we SMTP verkeer naar Office 365 wel accepteren. Alle andere IP adressen worden geweigerd.

exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”%5D)
&& exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value == “Microsoft.Exchange.SMTP”])
&& NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip”, Value =~ “b82.125.45.23b”])
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Beperken van POP Protocol

Voeg een nieuwe regel toe
Vul de volgende custom claim in
Deze claim bevat het specifieke IP adres van de MobileIron Sentry server vanuit waar we POP verkeer naar Office 365 wel accepteren. Alle andere IP adressen worden geweigerd.

exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”%5D)
&& exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value == “Microsoft.Exchange.Pop”])
&& NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip”, Value =~ “b82.125.45.23b”])
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Beperken van EWS Protocol

Voeg een nieuwe regel toe
Vul de volgende custom claim in
Deze claim bevat de publieke IP adres range van het on-premises netwerk vanuit waar we EWS verkeer naar Office 365 wel accepteren. Alle andere IP adressen worden geweigerd. Voor deze claimrule vereisen we ook dat de hybrid Exchange servers EWS verkeer naar Office 365 sturen voor het afleveren van naast elkaar bestaande functionaliteit naar alle gebruikers. Dit voorbeeld staat verkeer toe van de range 82.125.45.1 – 82.125.45.14.

exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”%5D)
&& exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value == “Microsoft.Exchange.SMTP”])
&& NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip”, Value =~ “b82.125.45.([1-9]|1[0-4])b”])
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Nu zou de huidige rule configuratie er als volgt uit moeten zien:

De laatste regel die toegevoegd moet worden is een standaard regel “Sta toegang toe voor alle gebruikers”. Wees er zeker van dat deze regel zich onderaan de lijst bevindt van de lijst met de “Toestaan” actie.

Nu zijn alle gewenste Exchange protocollen tot overal beperkt, behalve de MobileIron Sentry server of de on-premises netwerk range voor wat EWS verkeer om free/busy en ander hybride verkeer naar Exchange on-premises te ondersteunen. Echter, de nieuwe Outlook voor iOS en Android app gebruikt deze traditionele Exchange protocollen niet. Deze nieuwe handige app gebruikt de Graph API voor het ophalen van e-mail en andere resources.

Om toegang te beperken voor onbekende clients naar Exchange Online, met het gebruik van de Outlook voor iOS of Android app, kiezen we er voor om gebruik te maken van Conditional Access voor Azure Active Directory. En het beperken van toegang naar andere netwerken, dan het publieke IP adres van de Sentry server. Om gebruik te maken van deze feature is een Azure Active Directory Premium P1 licentie wel vereist!

Een laatste leuk feitje om deze blogpost mee te eindigen is het feit dat de documentatie geboden door Microsoft op TechNet niet klopt. De technet documentatie voor het beperken van toegang tot Office 365 services, gebaseerd op de locatie van de client noemt een verkeerde HTTP Header voor Imap verkeer. Na veel zoeken en fouten opsporen met Microsoft viel ons oog op een klein detail in de ADFS trace logs die ervoor zorgen dat de oorspronkelijke claimrule voor Imap faalt. We kwamen er achter dat HTTP Headers voor Imap verkeer de waarde Microsoft.Exchange.Imap gebruikt en niet Microsoft.Exchange.PopImap, zoals beschreven in het artikel. Hieronder kan de event worden gevonden, geregistreerd in de AD FS Trace Logs van een Imap client:

Volgende verzoek voor context headers presenteren:

X-MS-Client-Application: Microsoft.Exchange.Imap
X-MS-Client-User-Agent: –
client-request-id: 6338b8c2-c283-4c93-2c00-0080000000c6
X-MS-Endpoint-Absolute-Path: /adfs/services/trust/2005/usernamemixed
X-MS-Forwarded-Client-IP: xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx
X-MS-Proxy: WAP
X-MS-ADFS-Proxy-Client-IP: xxx.xxx.xxx.xxx

Groot applaus voor mijn goede vriend en teamlid Kevin Raap voor het samenwerken aan de claimrules en het vinden van de fout in de Microsoft Technet documentatie.