, , , , ,

Office 365 Email Signature Management with Mail Flow Rules [Part 2: Apply the Rule]

We covered the reasons why you should include an email signature, and what information you should include in the previous post. However, Office 365 Email signature management is made possible with the application of mail flow rules. This enables the functionality to append email signatures at the server side, meaning that you get consistently applied signatures no matter what device you’re sending from. This enables company-wide standardisation and brand consistency.

You will need:

  1. Office 365 Email Signature
  2. Admin access to exchange mail flow rules
  3. A signature/disclaimer encoded in html/css, with no more than 5000 characters (If you would like to know how to create one, read this post and follow the instructions.)

Step 1: Accessing Mail Flow Rules

  1. In the top left corner, open apps, and hit Admin.

How to access email signature mail flow rules in Office 365.

2. Then navigate to the Exchange admin centre.

How to access mail flow rules in Office 365.

3. Navigate to rules within the mail flow section.

How to access mail flow rules in Office 365.

Hit the plus icon and then create a new rule in the dropdown menu.

Office 365 Email Signature.

Office 365 Email Signature.

A new window will open with several options.

Step 2: Creating a Mail Flow rule for the Office 365 Email Signature

The new window that just opened should look like the following:

Office 365 Email Signature

Office 365 Email Signature

Let’s go through the options in order.

    1. Firstly you will be asked to name this rule. It’s good practice to keep things organised. I suggest calling it something like “disclaimer” or “signature”.
    2. The next section is the “apply this rule if…” which is the section that controls what conditions need to exist for a signature to be appended. Select your preferred combination or, to cover all emails sent from within your organisation, select “The sender… is internal”.
    3. The next section, “do the following” asks you to select an action. You should select append a disclaimer, whereupon you should click on enter text, then paste in your html code.

The key part of this is the coded signature itself. An Office 365 email signature needs to be simple and lightweight as email clients are notorious for resizing and squashing email signatures. For more information on how to create a signature click here.

  1. Next is a checkbox that asks “Audit this rule with severity level”. It’s up to you if you check this or not. The implication is that if checked, the rule will appear in reports and message traces. For more information click here.
  2. Next it asks you to choose a mode for this rule. Select the radio button marked enforce. This option controls whether the rule will appear in message traces, which helps if you’re troubleshooting.
  3. Click save.

Your new rule should appear within the list. You may need to promote or demote the priority of the rule using the arrow buttons, in case your signature rule conflicts with another rule.

Rules sometimes take a few minutes to propagate but eventually you will start to see a signature or disclaimer applied to your emails.

Step 3: Add Exceptions to the rule

You may want your signature to apply only in certain situations or for certain users. Mail flow rules are flexible. There are a range of conditions and exceptions you can use to tailor the rule so that it applies only when you want it to.

To prevent a stack of identical signatures at the bottom of your emails, you can insert an exception. Choose a unique word or phrase within your email signature. For example, your company registration number or part of the address. Edit your rule to include an exception, select “the subject or body matches…” and then enter a unique phrase included within your signature.

By doing this, the rule knows that a signature has already been applied before, so it doesn’t apply it every time a new email is sent.

If some staff need to be excepted from having a signature on their emails. Add an exception for the sender and add the individuals or groups you want excluded from the rule.

, , , , , , , , ,

Cyber Security: Office 365 as 802.1X RADIUS Password Authentication

Cyber security is critical. Secure your wireless network via 802.1X RADIUS using Office 365 with Azure AD for password authentication delegation with directory sync. Implement 802.1x RADIUS on almost any access point in minutes and for free.

If you purchase new, or renew existing, Office 365 licences:

SAVE AT LEAST 5%

This includes Exchange Online, SharePoint Online, Skype for Business, OneDrive for Business and the entire suite of Office 365 pricing.

Cyber Security Office 365 and 802.1X RADIUS

Security is paramount for any business, especially given the rise in cyber attacks, data thefts and major network breaches. I won’t list the major names, as that’s been done, but you can read the Cyber Security Breaches Survey 2016.  Much of that research was aimed at larger organisations, even though it’s far easier for enterprise-level companies to secure their resources. But what about the rest of us, Startups, Micro-Businesses and Small to Medium sized organisations?
We ourselves use Foxpass for network access control and cyber security, and have deployed this service for our customers. Foxpass has a mission to foster better identity management in the workplace, whilst being easy to deploy and cost effective to acquire. It’s a service organisations of any size will be able to use to get the exact same level of infrastructure security that large enterprises enjoy.

Why is wireless a cyber security issue?

In many of the companies I talk to, employees, contractors and one time visitors share the same login credentials when it comes to accessing the Internet via wireless. So far so good, however, virtually every startup or small business uses that same wireless access point to connect to internal systems. Be that a file server or individual user computers. In all honesty, I’m by no means an authority on 802.1X Radius, but my opinion is the benefits of using 802.1X RADIUS security with Office 365 and Azure AD for authentication far outweigh the disadvantages.

How hard can it be to hack a WiFi network?

https://null-byte.wonderhowto.com/how-to/hack-wi-fi-get-anyones-wi-fi-password-without-cracking-using-wifiphisher-0165154/


Why should we use 802.1x RADIUS for security?

  1. When a user authenticates to an SSID using 802.1X RADIUS that session is encrypted between the user and the access point.This means that another user connected to the same SSID cannot sniff the traffic and acquire information as they have a unique encryption key for their connection. With a Pre-Shared Key (PSK) network, every device is connected with “shared encryption”, meaning they can all see each other’s traffic.
  2. If you need to remove or disable a specific user or device, 802.1x RADIUS makes this far simpler as you disconnect a single user or device.This means you will not need to change the key for everyone, or all devices, closing the security risk of that user or device joining the network again.
  3. You can assign specific network permissions and policies such as VLAN, firewall, QoS, tunneling, schedules, access control lists.This means everything within a user profile can be dynamically assigned to users based on their identity or groups where users are members. With a Pre-Shared Key, you get a single profile that is shared. Using 802.1X RADIUS, different permissions based on the attribute returned from the RADIUS server are assigned.
  4. With 802.1X RADIUS each user gets a new unique key every time the user authenticates. This key continuously changes while the user is authenticated to the wireless network.This means If it takes a cracker one hour to crack the key, but the key is regenerating every thirty minutes, by the time the cracker has the key it is useless.

Why use Office 365 and Azure Multi-Factor Authentication?

The geo-distributed, high availability design of Azure AD means that you can rely on it for your most critical business needs. With the prevalence of smart phones, tablets, laptops, and PCs, people have far too many different options on how they are going to connect, and stay connected, at any time. Azure Multi-Factor Authentication is an easy to use, scalable, and reliable solution that provides a second method of authentication so your users are always correctly authenticated.
People can access their accounts and applications from anywhere, which means that they can get more work done and serve customers better.

  1. Two-step verification, which requires more than one method of authentication.This means a critical second layer of security is added when a user signs-in. It works by requiring two or more of the following:Something you know, a password for example
    Something you have, typically a trusted device that is not easily duplicated, like a phone
    Something you are, such as biometrics
  2. It’s easy to use with a range of verification methods including text message, phone call, mobile app or email to alternate account.This means, due to the extra protection that comes with Azure Multi-Factor Authentication, users are able to manage their own devices and authenticate in the way they prefer based upon where they are.
  3. Azure Multi-Factor Authentication is simple to set up and use. Once enabled, in many instances it can be set up with just a few simple clicks by the user.This means the burden of implementation is reduced and users are keen to adopt.
  4. Verification with Azure Multi-Factor Authentication is scalable, using the power of the cloud whilst also optionally integrating with your on-premises Active Directory (AD) and custom applications.This means that protection is can be extended to your high-volume, mission-critical services.
  5. Azure Multi-Factor Authentication provides strong authentication using the highest possible industry standards.This means you are not just secure, but also compliant. You can monitor application usage and protect your business from advanced threats with security reporting and monitoring.
  6. With a guaranteed 99.9% Service Level Agreement (SLA) for availability, Azure Multi-Factor Authentication is reliable.This means you will always be able to authenticate. The service is considered unavailable when it is unable to receive or process verification requests for the two-step verification.

In a future post I’ll add some instructions of how to enable 802.1X RADIUS in a wireless network using Foxpass. In order to offer our clients complete peace of mind regarding cyber security, we’re a Silver Productivity Partner with Microsoft. We partner with select providers, such as Foxpass, targeting our customers specific cyber security needs.


With over 20 years of experience, Serviceteam IT design and deliver sophisticated connectivity, communication, continuity, and cloud services, for organisations that need to stay connected 24/7. We take the time to fully understand your current challenges, and provide a solution that gives you a clear understanding of what you are purchasing and the benefits it will bring you.

To find out how we can help you, call us on 0121 468 0101use the Contact Us form, or why not drop in and visit us at 49 Frederick Road, Edgbaston, Birmingham, B15 1HN.

We’d love to hear from you!

, , , , , , , , , , , , , , ,

Restrict Access to Office 365 Exchange Online | HowTo | 2 of 2

Part One | Part Two

In Part One we learnt:

  1. Install and update Windows Server with Active Directory Federation Services version 2.0 (AD FS 2.0) with update Rollup 2, KB2681584.

  2. Set-up AD FS for Office 365 for Single Sign-On.

    To continue . . .

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

    Use the following procedure to add a set of claim rules that make the new claim types available to the policy engine. In this step, you will have to add five acceptance transform rules for each of the new request context claim types using the following procedure.  On the Active Directory claims provider trust, create a new acceptance transform rule to pass through each of the new request context claim types.

    a. Select Start, go to Programs, then to Administrative Tools. Click on AD FS 2.0 Management.

    b. In the console tree, under AD FS 2.0\Trust Relationships, click Claims Provider Trusts, right-click Active Directory, and then click Edit Claim Rules.

    c. In the Edit Claim Rules dialog box, select the Acceptance Transform Rules tab, and then click Add Rule to start the Rule wizard.

    d. On the Select Rule Template page, under Claim Rule Template, select Pass Through or Filter an Incoming Claim from the list, and then click Next.

    e. On the Configure Rule page, under Claim Rule Name, type the display name for this rule; in Incoming Claim Type, paste the Issued Claim Type URL, and then select Pass through all claim values. Complete this step for all five Issued Claim Type URLs below:

    Rule Name Issued Claim Type URL
    EQ-Forwarded-client-ip http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip
    EQ-client-application http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application
    EQ-client-user-agent http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent
    EQ-Proxy http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy
    EQ-endpoint-absolute-path http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path


    f. To verify the first rule, EQ-Forwarded-client-ip select it in the list and click Edit Rule, then click View Rule Language. The claim rule language should appear as follows:

    c:[Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip”%5D => issue(claim = c)

    g. Click Finish and in the Edit Claim Rules dialog box, click OK to save the rules.

  4. Create a rule to block all external IP address access to Office 365 & Exchange Online

    If you want to simply block access to Office 365 & Exchange Online from the public Internet you need to carry out the following:

    a. Click Start, point to Programs, point to Administrative Tools, and then click AD FS 2.0 Management.

    b. In the console tree, under AD FS 2.0\Trust Relationships, click Claims Provider Trusts, right-click Active Directory, and then click Edit Claim Rules.

    c. In the Edit Claim Rules dialog box, select the Acceptance Transform Rules tab, and then click Add Rule to start the Rule wizard.

    d. On the Select Rule Template page, under Claim Rule Template, select Pass Through or Filter an Incoming Claim from the list, and then click Next.

    e. On the Configure Rule page, under Claim Rule Name, type the display name for this rule, such as Block Office 365 Exchange Online from the Internet. Under Custom Rule, paste the following claim rule language syntax:

    exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"]) && NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value=~"customer-provided public ip address regex"]) => issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

    customer-provided public ip address regexBuilding the IP address range expression

  5. Update the Microsoft Office 365 Identity Platform relying party trust

    This step allows you to configure what type of clients to block. Below there is a custom block scenario. Block all external access to Office 365, except Exchange ActiveSync and browser-based applications such as Outlook Web Access or SharePoint Online.

    exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”%5D) && 

    The ‘Type’ x-ms-proxy exists. This  means that the claim came through an ADFS Proxy (or other compatible proxy such as Azure).

    NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value==”Microsoft.Exchange.Autodiscover”]) &&

    ClientApplication is RPC or WebServices. The ‘or’ can be used (using the ‘|’ character) syntax to check the value field. The value of this is Microsoft.Exchange.Autodiscover.

    NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value==”Microsoft.Exchange.ActiveSync”]) &&

    ClientApplication is RPC or WebServices. The ‘or’ can be used (using the ‘|’ character) syntax to check the value field. The value of this is Microsoft.Exchange.ActiveSync.

    NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/ls/”])

    The type x-ms-endpoint-absolute-path exists and has a value of for the ls policy. This is the name of the endpoint for _Active_ ADFS Claim.

    NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip”, Value=~”\b192\.168\.1\.([1-9]|[1-9][0-9]|1[0-9][0-9]|2[0-5][0-9])\b|\b255\.255\.255\.255\b”]) &&

    The value for the type x-ms-forwarded-client-ip has a value that DOES NOT MATCH the regular expression “”. The only allowed range is 192.168.1.0 to 192.168.1.255 plus a single address 255.255.255.255.

    i. What is the source of “x-ms-forwarded-client-ip” and what are the values we should expect to see? ii. What is the format of the expression? Building the IP address range expression

    => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);


With over 20 years of experience, Serviceteam IT design and deliver sophisticated connectivitycommunicationcontinuity, and cloud services, for organisations that need to stay connected 24/7. We take the time to fully understand your current challenges, and provide a solution that gives you a clear understanding of what you are purchasing and the benefits it will bring you.

To find out how we can help you, call us on 0121 468 0101use the Contact Us form, or why not drop in and visit us at 49 Frederick Road, Edgbaston, Birmingham, B15 1HN.

We’d love to hear from you!

, , , , , , , , , , , , , , ,

Restrict Access to Office 365 Exchange Online: Limiting by Network, IP, Client, Group or Policy | HowTo | 1 of 2

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

If you purchase new, or renew existing, Office 365 licences:

SAVE AT LEAST 5%

This includes Exchange Online, SharePoint Online, Skype for Business, OneDrive for Business and the entire suite of Office 365 pricing.

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 adfs.serviceteamit.co.uk.

    Enable-PSRemoting  Connect-MsolService  Set-MsolADFSContext –computer <the FQDN of the ADFS server> Convert-MsolDomainToFederated –domain adfs.serviceteamit.co.uk

    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 “serviceteamit.co.uk.” So, serviceteamit.co.uk 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 “serviceteamit.co.uk” 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.

With over 20 years of experience, Serviceteam IT design and deliver sophisticated connectivitycommunicationcontinuity, and cloud services, for organisations that need to stay connected 24/7. We take the time to fully understand your current challenges, and provide a solution that gives you a clear understanding of what you are purchasing and the benefits it will bring you.

To find out how we can help you, call us on 0121 468 0101use the Contact Us form, or why not drop in and visit us at 49 Frederick Road, Edgbaston, Birmingham, B15 1HN.

We’d love to hear from you!

, , , , , , , , , , , , , , , ,

Office 365 SSO Security Guidance: Single sign-on and remote access

Office 365 SSO: The secure configuration of this cloud-hosted service aligns with government’s guidance on implementing the Cloud Security Principles. You can find out more regarding implementation of Federation in order to Restrict Access to Office 365.

1. What is Office 365 SSO (Single Sign-On)?

A Microsoft Online user usually signs in using the username and password associated with their Microsoft account. This process can be simplified with O365 by using Office 365 SSO, which allows a user to log in to O365 using their existing enterprise username and password. Office 365 SSO login may happen automatically, although this depends on how the enterprise and its devices are configured.

Office 365 SSO Single Sign-On

2. Microsoft Office 365 and SSO

O365 can be integrated with an existing on-premise Active Directory (AD) either by:

  • synchronising user credentials to the cloud or
  • implementing SSO using identity federation

Both options require account synchronisation between AD and the cloud, effectively copying user account and group data into Windows Azure Active Directory (Azure AD). Directory synchronisation is an ongoing relationship between the on-premise and cloud directories, implemented using the Directory Sync tool or with Azure AD Connect. Filters can be applied so only specified accounts in named organisational units or with certain user object attributes are synced.

O365 supports the implementation of SSO using identity federation which can be enforced once directory synchronisation is correctly established. In this configuration, the user authenticates to the enterprise instead of signing in to the O365 web app. This means there is no requirement to store enterprise passwords in the cloud, while also supporting multi-factor authentication such as a device identity or smartcard.

3. Synchronisation recommendations

CESG recommends implementing full identity federation rather than synchronising passwords into the cloud. Where possible, authentication should be made directly against the enterprise domain, connecting to it over a VPN when working remotely. This ensures there is no requirement to expose an authentication service directly to the Internet; a direct connection carries additional risk to the enterprise domain.

Enterprises implementing a cloud-first deployment may have already chosen to synchronise enterprise accounts and passwords into the cloud. In this case, an enterprise can take advantage of Azure AD services such as self-service password resets, Windows Azure Multi-Factor Authentication and integration options available with third party web apps adopting Microsoft Identity Manager.

Once user accounts have been synchronised to O365, an administrator will need to assign licenses to those users. While this is not automatically done using Directory Sync or Azure AD Connect, it can be scripted with PowerShell.

4. Office 365 SSO compatibility

Automatic SSO is supported in all O365 services accessed through the O365 portal, as well as Microsoft Office desktop apps installed on domain-joined devices. Office 365 SSO is also available on the Mobile Office platform for devices that support Workplace Join. Users of devices that are either unsupported or not enrolled in the enterprise will be able to log in to O365 using their enterprise username and password, unless O365 is configured to only allow connections from known and trusted devices.

5. SSO implementation requirements

An SSO implementation for O365 currently requires AD with a compatible Security Token Service (STS), also known as an Identity Provider (IdP). Microsoft currently supports Active Directory Federation Service (ADFS), Shibboleth IdP and other tested third party IdPs as an STS. It may be necessary to alter AD and ADFS configurations to meet the requirements defined by user identities and domain naming.

From a user perspective, SSO works by pointing them at an IdP which they authenticate against using a username and password. The browser then passes a security token toO365, allowing the user to log on to the service.

  • For users on a domain-joined or workplace-joined device, this login will be seamless once the device is unlocked.
  • For users on other device types, including those not connected to the enterprise network, they will authenticate against an enterprise authentication proxy using their username and password.

6. Web access

Public cloud services such as O365 are designed to be accessed from any device with an Internet connection. Some enterprises prefer to only allow their information to be accessed from authorised devices, whether these are enterprise managed or personal devices that meet a required security specification.

If you wish to restrict access to enterprise data to a subset of devices, one solution is to implement procedural controls for End User Devices (EUDs) which allow users to only log into O365 from certain devices. This can be achieved either through Mobile Device Management, Intune or through Group Policy with ADFS. Additional policy and security control can be achieved through private VLANs, removing the complexity of managing outbound requests via the Internet from trusted locations, such as fixed office sites or data centre locations.

7. Restricting access to known devices

There is no specific feature in O365 designed to restrict access to the service by network location or device, through mechanisms such as IP range restrictions or forcing user certificate-based authentication. If ADFS is used as an IdP, it may be configured to require that devices come from known IP addresses. However, it is possible to configure SSO so that only devices that are connected to the enterprise network can authenticate, using any IdP:

Office 365 SSO ADFS

With SSO configured as shown above, EUDs can only log in to O365 when they can see the IdP. This ensures that only devices that are connected directly to the enterprise network and those approved to connect using a VPN will be able to log in to O365. Once a user has logged in, the VPN can be dropped since the EUD will maintain the session with a web browser cookie, held until the user logs out. There should be an exception created in the VPN aggregator for managing latency-sensitive applications, such as Lync and Skype, in order to sustain a high level of usability.

SSO can also be configured to work with online IdPs. All approved EUDs should be provisioned with a non-exportable client certificate that identifies the user as a member of the enterprise. This certificate should be hardware-backed on supported devices. TheIdP is required to only accept authentication from devices that have this certificate. The logon could also identify the unique user using the certificate, streamlining the logon.

Permissions can be applied to some data held in O365 so that it is only accessible by certain managed devices, or groups of specified devices. This is enabled primarily for devices enrolled in AD or Azure AD, through the Workplace Join or Domain Join mechanisms.

8. Shared devices

O365 sets non-persistent session cookies once a user has successfully logged in, whether or not SSO is being used. If the SSO implementation provides persistent session management, CESG recommend that users should be advised to manually log out of both O365 and their IdP. This will ensure that the cookie is deleted and in doing so separate user sessions on shared devices. It cannot be assumed that O365 will delete the SSO cookie set by the IdP.

9. References

In addition to the web pages referenced in the list of URLs below, Microsoft provides documentation to support SSO deployments including a troubleshooting guide:

See also CESG’s deployment security considerations for Microsoft Office 365: Administrator Good Practice in addition to documentation on End User Devices Security and Configuration Guidance.

If you have any questions or need a little more in-depth help please get in touch.

Source: https://www.ncsc.gov.uk/guidance/microsoft-office-365-security-guidance-single-sign-and-remote-access