Restrict Access to Office 365 Exchange Online

Active Directory Federation Services (AD FS) 2.0 provides a way to configure access restriction policies. Office 365 & Exchange Online customers using Single Sign-On (SSO) who require these policies can now use Client Access Policy rules to restrict access based on the location of the computer or device that is making the request and prevent access from the Internet

Part One | Part Two

Restricting access to email and communications services in the cloud from the Internet, in Office 365 & Exchange Online, may at first seem a little counter intuitive, however, it is very sensible. Data loss is minimised. Time and working hours restrictions are adhered to. Personal devices and the compromised security they pose are removed. Compliance and regulatory restrictions, for example for finance or health care sectors, are met. Fundamentally, it ensures the control an organisation requires, whilst meeting the needs of flexibility and reduced costs, that the cloud offers.

Perhaps you want to ensure Outlook users can only use corporate laptops to connect as long as they establish a VPN tunnel to the corporate network? Outlook Web App (OWA) can be used from any machine without restrictions within the corporate network or from a named IP or IP address range? ActiveSync can be used from any device, as long as the device or user has been approved by an administrator, and that device is secured according to the policy regarding passcode length, installed OS etc? Restrict or block access based upon Group Policy membership?

The simple scenario options are:

Scenario Description
Block all external access to Office 365 & Exchange Online
Office 365 access is allowed from all clients on the internal corporate network, but requests from external clients are denied based on the IP address of the external client.
Block all external access to Office 365, except Exchange ActiveSync
Office 365 access is allowed from all clients on the internal corporate network, as well as from any external client devices, such as smart phones, that make use of Exchange ActiveSync. All other external clients, such as those using Outlook, are blocked.
Block all external access to Office 365, except for browser-based applications such as Outlook Web Access or SharePoint Online
Blocks external access to Office 365, except for passive (browser-based) applications such as Outlook Web Access or SharePoint Online.
Block all external access to Office 365 for members of designated Active Directory groups
This scenario is used for testing and validating client access policy deployment. It blocks external access to Office 365 only for members of one or more Active Directory group. It can also be used to provide external access only to members of a group.

If you are a little overwhelmed by PowerShell and expressions there is a useful GUI for PowerShell which builds the expressions for the most common scenarios:

Office 365 & Exchange Online Client Access Policy Builder

In order to enable an external access policy for Office 365 & Exchange Online the following steps are required:

  1. Ensure you have a Windows Server with Active Directory Federation Services version 2.0 (AD FS 2.0) with update Rollup 2, KB2681584.

    After the Update Rollup 2 for Active Directory Federation Services (AD FS) 2.0 package has been installed on all federation servers and federation server proxies, restart the AD FS Windows service.

  2. Follow the video guide here to Set-up AD FS for Office 365 for Single Sign-On.

    a. If you do not have Active Directory Federation Services installed, add ADFS by using the Add Roles and Features Wizard. If you are using Windows Server 2008, you need to download and install ADFS 2.0: Active Directory Federation Services 2.0 RTW. After the installation, use Windows Update to install all applicable updates and reboot as required.

    b. Request a certificate from a third-party CA for the Federation server name as Office 365 needs a trusted certificate on your ADFS server. You need to obtain a certificate from a third-party certification authority (CA). When you customise the certificate request, ensure you add your Federation Server name in to the Common Name field.

    The video only explains how to generate a certificate signing request (CSR). You need to send the CSR file to a third-party CA. Once the CA has returned a signed certificate, follow these steps to import the certificate to your certificate store:

    i. Run Certlm.msc to open the local computer’s certificate store.
    ii. In the navigation pane, Expand Personal, expand Certificate, right click the Certificate folder, and then click Import.

    The Federation Service name is the Internet-facing domain name of your ADFS server. Your Office 365 users will be directed to this domain for authentication, therefore, make sure that you add a public A record for the domain name in your DNS.

    c. To configure ADFS you cannot manually type a name as the Federation Server name. The name is determined by the subject name (Common name) of a certificate in the local computer’s certificate store.

    In ADFS 2.0, the Federation server name is determined by the certificate that binds to “Default Web Site” in Internet Information Services (IIS). You must bind the new certificate to the Default website before you configure ADFS.

    You can use any account as the service account. If the service account password is expires, ADFS will stop working. Therefore, make sure that the password of the account is set to never expire.

    d. Download the Office 365 tools, including Windows Azure Active Directory Module for Windows PowerShell and Azure Active Directory sync appliance. They are available in the Office 365 portal. Go to Active Users, and then click Single sign-on: Set up.

    d. Now you need to add your domain to Office 365 as the first video does not explain how to add and verify your domain to Office 365. For more information about that procedure, see the video below:

    e. You can now connect ADFS to Office 365 by running the following commands in Windows Azure Directory Module for Windows PowerShell. In the Set-MsolADFSContext command, specify the FQDN (Fully Qualified Domain Name) of the ADFS server in your internal domain instead of the Federation server name. In the example below I have used

    Enable-PSRemoting  Connect-MsolService  Set-MsolADFSContext –computer <the FQDN of the ADFS server> Convert-MsolDomainToFederated –domain

    If the command ran successfully, you should see the following: A “Microsoft Office 365 Identify Platform” Relying Party Trust is added to your ADFS server.

    f. Once the ADFS domain is added you need to Synchronise the local Active Directory user accounts to Office 365. If your internal domain or suffix is different from the external domain, you have to add the external domain as an alternative UPN in the local Active Directory. For example, the internal domain name is “serviceteamit.local” but the external domain name is “” So, needs to be added as an alternative UPN suffix. Now you can synchronise the local user accounts to Office 365 by using the Directory Sync Tool.

    If you are using ADFS 2.0, you must change the UPN of the user account from “serviceteamit.local” to “” before you synchronise the accounts to Office 365. If not, the user will not be validated on the ADFS server.

    g. Finally you can now configure the client computer for Single Sign-On. After you add the Federation server name to the local Intranet zone in Internet Explorer, the NTLM authentication is used when users try to authenticate on the ADFS server. Therefore, they are not prompted to enter their credentials.

    Administrators can implement Group Policy settings to configure a Single Sign-On solution on client computers that are joined to the domain.

    If you wish to enable additional services, such as Secure ID or Oracle Identity use the AD FS 2.0 Step-by-Step and How To Guides.

  3. Add five claim rules to the Active Directory Claims Provider trust.

    Continue to Part Two in order to add the rules.

1 reply

Trackbacks & Pingbacks

Comments are closed.