There are often preconceived ideas around what ADFS provides and whether it is required when you are moving to Office 365.  The below points cover some common conversation that we have with customers.

Number 1: Matching Passwords with on-premises

It is often believed that ADFS is the only way to provide users with the same login and password for Office 365 that they’re using in Active Directory; this is not the case.

Using Directory Sync, you can synchronise the user password hash from Active Directory into Office 365 and provide users with the same password.  Subsequent password changes are synchronised to Office 365 within a couple of minutes of changing in Active Directory.  A password hash is synchronised to Office 365 in a one-way mathematical computation based on the user’s password which is non-reversible to gaining a plain text password.

Number 2: Single Sign-On End User Experience

As previously mentioned, password synchronisation provides users with the same password in Office 365 that they use for Active Directory; this is known as ‘same sign on’.   With ADFS, you can sign into a workstation connected to Active Directory domain without the need to re-enter your password when you connecting to Office 365 services; this is known as ‘single sign on’.  The exception is the Outlook client which does not support single sign-on.  Users are prompted to enter their credentials and can choose to ‘Save My Password’.

Number 3: Infrastructure Required

When you implement ADFS with Office 365, you are passing the password authentication from Office 365 to your on-premises identity platform.  If the ADFS environment becomes unavailable, users are unable to login and will be unable to access Office 365.  With that in mind your ADFS infrastructure needs to be designed with resilience.

Providing ADFS redundancy requires multiple ADFS servers, load balancing and internet link failover.  Choosing to host the ADFS on-premises can require additional hardware and infrastructure.  Alternatively, you could choose to host ADFS in Azure or another data-centre that links into your Active Directory environment.

Number 4: Sign-in Restrictions by location or Working Hours

In order to leverage this ability to restrict access to Office 365, you will require ADFS services or a federated sign on provider.  ADFS provides the ability to restrict access by network location and makes use of the restricted logon hours you can set on accounts within Active Directory.

Number 5: Ongoing Maintenance and Administration

An often forgotten point when installing a new solution is who will maintain the infrastructure going forward.  If you choose to host your ADFS configuration on-premises you need the skills to administer, update and maintain an environment which is providing live sign-on services to Office 365.  An alternative is looking to a third-party provider who can host your federated login infrastructure and remove the admin overhead.

Number 6: Real-time Account Disabling and Auditing

With ADFS in place, a user’s login request is passed to the on-premises Active Directory infrastructure for validation.  As a result, you have the ability to disable accounts on-premises with real-time effect to Office 365 services.  You also have the ability to audit login events centrally within your Active Directory event logs.

Without ADFS in place, an alternative would be waiting for Directory Sync to synchronise the change to Office 365 on its next scheduled sync, typically every 30 minutes, or manually forcing a sync to Office 365.  You could also choose to reset a user’s password which will synchronise to Office 365 within a couple of minutes.

In Summary

If the main driver for implementing ADFS is providing users with matching login details, you may consider AAD Connect with password synchronisation as a better fit.  This provides you with a robust solution that can be changed to ADFS at a later date if required.

Get in contact today at hello@cloudbusiness.com to discuss your requirements and see what the best fit is for you.

Office 365 Groups are a mixture of the services offered as part of Office 365 and they’ve got some great potential.

For small businesses I believe Groups functionality can be harnessed right away as an easy to use planning and collaboration space for teams.For larger businesses, Groups don’t offer the management or governance settings required and things could quickly get out of control. 

What do Office 365 Groups consist of?

1. An area to start conversations

– Inline replies and likes

– An email address for emails to be sent to and from internal/external parties.

2.  A place to collaborate on documents

– Create Office documents in the browser

– Share documents with colleagues

– View documents shared with a group

3. A team calendar

– Quickly invite all team members to a meeting

– Track all team events easily

4. A group notebook

– All team notes in one place

5. Mobile App

– A mobile app with access to all the conversations and files that a user is the member of. For Windows Phone, Android and iPhone – and it’s good!

Office 365 Groups Potential

The potential for Groups could be to replace an Exchange distribution List – benefits mean any user added can see all historical conversations and be able to get up to speed with what is happening in the team.

Groups could also replace SharePoint team sites – It is often the case where users create Team Sites with a single document library on them. Groups could replace these and are perfect for events with a short lifespan.

What’s coming to Office 365 Groups?

• Groups are set to have Office 365 Planner integrated in 2016, enabling task management using the Kanban methodology. Think Trello but tied in to Office, Groups and Delve, and from the screenshots, it looks like a great visual way of working with tasks compared to standard SharePoint lists.
• There will also be Delve pages for each group, showing all the relevant items to Group members and making it quick and easy to see what teams are working on at the time.
• Groups Home Page to view recent, trending and favourite groups.

What I’d like to see in Office 365 Groups

There are also quite a few extras that I’d like to see added to groups so that more customers can also take advantage of them.

• Document management features such as sharing/permission control, approval workflow, alerts, major and minor version control.
• An optional subject line for messages – being able to receive updates to the inbox is great but they need a subject line, especially if sending externally, perhaps these could also have the Group name appended.
• Groups management page turn on/off per user, although this can be done by using mailbox policies, a more ‘support desk friendly’ method would be great.
• Calendar management features – granular permissions for calendar access and management.
• Group closure policy – think SharePoint site policies – to close forgotten sites.
• Tasks sync to outlook – This feature was deprecated from SharePoint Online earlier this year. Will Groups allow task synchronisation to Outlook again?
• Import/export of tasks – for the PMO, this is a key feature.

Find help about on Office 365 groups here and the integration with Office 2016 here.

To check out some of our other new hints and tips have a look at these blogs;

 Outlook 2013 single sign-on  or  Removing External users from Sharepoint Online

The supported User Agent Strings for ADFS 3.0 by default do not support Single Sign-On from Third-Party browsers, i.e. Firefox and Chrome. To enable this functionality you can add additional supported User Agent Strings to the ADFS configuration.

NB – This functionality is also available in ADFS 2.0, although it was not officially supported by Microsoft.

Checking Current Config

To check the currently supported User Agent Strings you should run the following command:

Set-ADFSProperties | Select WIASupportedUserAgents

Adding Support for Chrome & Firefox

Current versions of Chrome and Firefox (at time of writing) can be enabled by adding Mozilla/5.0 to the Supported User Agent Strings. An example of the command used for adding the required User Agent String is as follow:

Set-ADFSProperties -WIASupportedUserAgents @(“MSAuthHost/1.0/In-Domain”, “MSIE 6.0”, “MSIE 7.0”, “MSIE 8.0”, “MSIE 9.0”, “MSIE 10.0”, “Trident/7.0”, “MSIPC”, “Windows Rights Management Client”, “Mozilla/5.0”)

You should add the current list of Supported User Agents to a custom variable and then append the Mozilla/5.0 agent string to ensure that no other functionality will be broken.

User Experience

You should note that when a browser is added to the list of Supported user agents, if the client does not authenticate using Windows Integrated Authentication it will not fall back to Forms-Based authentication, but to Basic as per ADFS 2.0.

The most elegant solution for achieving this behaviour is to inject a custom user agent string into client browsers using Group Policy (therefore setting for all client machines inside the network that will integrate using WIA) and setting the WIASupportedAgents to just that custom string, so they will authenticate using WIA. Those without the User Agent String will fall back to Forms-Based as they are not using a WIA supported agent.

To learn more about ADFS on android read our other blog here

Or to learn more about Office 365 Single sign-on in Outlook read here

Recently Microsoft announced the release of updates to Office 2013 clients and Office 365 to support new authentication flows enabled by the Active Directory Authentication Library (ADAL). Now this article is a little confusing so what does this actually mean?

For a long time Outlook has been the black sheep of the Microsoft client stack in terms of supporting true single sign on with Office 365. Customers have deployed complex ADFS environments seeking the best user experience to find that whilst Lync, Office & passive web browsers benefited with single sign on Outlook would fall back to Basic authentication prompting users for their UPN & password on profile creation or password change. This left some customers wondering why they had deployed ADFS and begged the question why Outlook arguably the most used client application didn’t support single sign on.

Good news the new authentication flows finally resolve this issue and Outlook 2013 will support true single sign on when deployed with ADFS. This update is currently listed as rolling out on the Office 365 roadmap so keep an eye open for these changes being deployed to your tenant soon.