If you are using an Office 365 ProPlus version prior to 1808, along with Windows 10 1703 or later, you may have an issue where Office applications do not use SSO to sign in, and after users enter their email address, they then have to enter their username and password again in the ADFS login form. This is due to issues with Web Account Manager (WAM), which is used for authentication instead Azure Active Directory Authentication Library (ADAL) with Office 365 ProPlus on recent versions of Windows. Other issues we have seen include:
Being unable to obtain a license for Office at all, and Office going into reduced functionality mode, especially if you are using Shared Computer Activation
Activation issues after changing password or UPN
Repeated requests to enter passwords
Showing users a screen asking if they want to add the account to Windows
Fortunately, there is a fix for this, which is listed in a Microsoft article, which lists several symptoms but doesn’t specifically mention SSO issues.
Firstly, if you are running a Windows 10 build later than 1703, you will be using ADAL. So firstly, make sure you have this enabled in your ADFS infrastructure.
Enable ADAL Enable WS-Trust 1.3 for Desktop Client SSO ADAL
In your ADFS console, check the following endpoint shows enabled (/adfs/services/trust/13/windowstransport):
If not, run the following PowerShell command on your ADFS server to enable the endpoint for WS-Trust 1.3:
Windows Rights Management Client
Now, restart ADFS:
net stop adfssrv
net start adfssrv
Note that you could also add individual browsers instead of Mozilla/5.0 in case you wanted some browsers supported and not others. For example you might use Firefox for Global Admin users connecting to Office 365, so they can be signed into the Windows with one account, and use an Admin account to login to Office 365 using Firefox. So you could use something like this:
Administering Office 365 requires special consideration in order to ensure that your service is both manageable and secure. Optimal configuration requires a balance between security, usability, and availability, so all of these need to be considered when planning a strategy. However, the following is a general set of guidelines that can be applied to most deployments, whether they are federated or cloud only.
Create separate ‘Admin’ accounts for IT staff which are cloud accounts (using .onmicrosoft.com), don’t assign internal user accounts admin roles. When your domain is federated, these accounts will still work if there is any issue with ADFS.
Enable MFA for all Office 365 Admin accounts.
Set the password policy for cloud accounts so that it at least matches your on-premises password policy. Even if your domain is federated via ADFS, the password policy will apply to cloud only admin accounts. Note that you can only enforce password age and length, not complexity. If your on-premises policy is not particularly secure, set the policy to at least 10 characters long, and advise your admin users to use a mixture of capital and lower case letters, numbers and special characters. This won’t affect internal users, since the password policy is enforced by Active Directory.
Don’t assign admin accounts a license. It is not generally required, and this will prevent a mailbox being created and the accounts appearing in the GAL, which could cause confusion. However, there are some instances where a license may be required for Exchange or Intune admin functions which can make this problematic, in which case assign a license only when required.
Limited the number of Admin accounts, we generally recommend less than 5 in order to minimise attack surface.
Use the principle of ‘least privilege’, use roles other than global admin e.g. Exchange Online Administrator, or helpdesk administrator where possible.
Avoids Admin users having to use 2FA to sign in to Office on their desktops, which can be especially annoying if you are using Shared Computer Activation. Although this could be avoided using a conditional access policy.
It is more secure, the user is not signed in with a global admin account all the time.
The admin accounts can be used to resolve any issues with ADFS, which can prevent internal users from signing in.
Sometimes there may be no internal users who require admin access, if the tenant is managed by a third party. So using this strategy will work in any situation.
There are however drawbacks to this approach
In order to administer Office 365, IT staff will need to use InPrivate or incognito browser mode, and connect to Office 365 with their 2FA. This is an inconvenience.
The external accounts are available from the internet, which is not always the case with ADFS. This is mitigated through strong passwords and MFA.
You need to make sure that Admin accounts are disabled when users leave, this is often overlooked. This requires robust leavers process for IT staff.
You may find that when you run the Exchange Hybrid Configuration Wizard that it does not run. If you launch it from Exchange Admin Center, or from the Exchange Online Admin Center, it may just flash up and do nothing.
The solution is to change the file association for .application files to Internet Explorer. However, if you try in the Control Panel, you will find that this is impossible:
The solution is to do this using good old Windows Explorer.
Check you are viewing file extensions in Windows Explorer (View > File name extensions)
Right click in your Documents folder or somewhere, create a new file called test.application
Right click on it and choose Properties, and change the application to Internet Explorer
Click Settings > Services & add-ins > Microsoft Teams
Under Settings by user/license type, drop the list down and choose Guest
Then set the switch to On
Enable users to add guests in Azure AD
You also need to change this setting to enable users to invite guests if you have not set this up already. The alternative to this is adding guests as an Admin into Azure AD, after which they can be added by Team owners.
Bear in mind that this affects other services in Office 365 / Azure.
If you integrate your Enterprise applications with Azure AD, you may want allow your users to invite external users in a secure manner, without enabling guest access to any other resources, or having to involve admins every time a guest needs to be added.
Microsoft document how to allow your users to manage guest access here:
So there are 2 ways to do this, either you let Admins add your B2B users, or you can let your own users do this. This article focuses on the latter, enabling your users to add guests, whilst doing so in a secure manner. The Microsoft article above does not discuss how to securely enable guest access in the first place, so this is the focus of this post.
Note that if you just want to control access to Teams, SharePoint, OneDrive and Office 365 groups, all of these are controlled separately and you don’t need to do follow this first section. See the end of this post for more detail.
Securing guest access to applications
As already mentioned, Admins can add guests to the directory, so if you want complete control of guest access then do not turn on the settings below. Once an admin has added a guest, users can then invite the guests to various resources as required.
Steps to allow Guests to invite users to specific applications are documented here, I am going to assume you have done this:
However, these steps are not enough on their own, once you have allowed users to manage access to an individual application, you need to follow the steps below to complete the process. Note that these settings are tenant wide, so will also apply to other applications, and the domain restrictions will also apply to Teams or SharePoint, so bear that in mind before you start restricting guests to specific domains.
Guest invitation settings
If you want to allow collaboration without requiring the intervention of Admins, and want to enable guest access outside of Teams or SharePoint e.g. to B2B applications that you have integrated with Azure AD, you need to enable users to invite guests at the Tenant level:
Click User Settings, and then Manage external collaboration settings:
Set Members can invite to Yes (you should generally set Guests can invite as No)
Now this is rather open by default, so we can then restrict the types of guests as follows:
Setting Collaboration restrictions
Now, choose how restrictive you want to be by setting the collaboration restrictions to one of the options:
Allow invitations to be sent to any domain
Deny invitations to the specified domain
Allow invitations only to the specified domain
If you need users to be able to invite guests, you can use a whitelist to ensure that they can only invite users at from domains of your choosing. So you could add in the domains of your partners here, to ensure that users can collaborate with your partners, but not other external users.
If possible, use the last option and enter the domains of your partners. Note that this will also affect other areas e.g. SharePoint and Teams, so you should add the domains of all of your partners here. Note that this setting will prevent even an Admin from adding a guest from an unauthorised domain directly to Azure AD, but if this is required you could briefly add a domain to the list.
Users can then add guests using the Access Panel at myapps.microsoft.com, but only the domains which are allowed.
Putting it all together
Now users can invite guests to the app that they have been assigned as an owner:
If another domain is tried, they will get an error:
This will also apply to Teams:
Restrict access to the Azure AD portal
Go to portal.azure.com
Click Users under Manage
Click User Settings
Under Administration porta, click Yes – Restrict access to Azure AD administration portal
If you do this then users will be unable to use Azure AD from the portal:
Other guest settings
If you only need to enable Guest access for Teams collaboration, you just need to go to portal.office.com, then Settings > Services & add-ins > Microsoft Teams > Settings by user/license type
SharePoint and OneDrive guest access is also controlled separately in the SharePoint Admin center:
Office 365 Groups
You may want to turn off the following switches under Admin Center > Home > Services & add-ins > Office 365 Groups:
Let group members outside the organization access group content
Let group owners add people outside the organization to groups
If your on-premises Exchange organization is running Exchange 2007 or Exchange 2003, and if you want to connect your organization to Office 365 and your Exchange Online organization, you must install at least one on-premises Exchange 2013 or Exchange 2010 Service Pack 3 (SP3) server. This server is used for hybrid deployment connectivity that seamlessly connects your on-premises Exchange and ExchangeOnline organizations.
To avoid the additional cost of an Exchange 2013 or Exchange 2010 SP3 server license, you may qualify for a free Hybrid Edition product keyfor Exchange 2013 or Exchange 2010 SP3.
Obtain a Hybrid Edition product key
You can request a Hybrid Edition product key if all the following conditions apply to you:
You have an existing, non-trial, Office 365 subscription.
You currently do not have a licensed Exchange 2013 or Exchange 2010 SP3 server in your on-premises organization.
You will not host any on-premises mailboxes on the Exchange 2013 or Exchange 2010 SP3 server on which you apply the HybridEdition product key.
Office 365 can enable new ways of collaborating with suppliers and business partners. However, it is important to understand the security implications of this, and you will probably want to lock this down initially.
By default, any user can invite external third parties into your Office 365 tenant, where they may have access your sensitive data. So in order to secure your data and applications, you should change the default settings.
External Collaboration Settings
By default, normal users can invite guest to Azure AD. So Members can invite should be turned off, and you should also turn off Guests can invite.
Note that users can still invite guests if an Admin has added them to Azure AD already. So if an Admin has added guests to Azure AD directly, they could then be added to any app by any user, so this should be avoided. To change the collaboration settings:
Point to the app, select the ellipses (…), and then select Manage app.
B2B Guest Inviter role
There is also a Guest Invitier role, however you generally don’t want to use this, since this will effectively allow them to invite anyone to anything the same as an Admin (as it says above, Admin and users in the guest inviter role can invite).
A simple way for your users to manage distribution list membership with hybrid Office 365 environments with Active Directory on-premises, Azure AD Connect synced to Azure AD and Exchange Online.
With Exchange on-premises, users may be used to managing Distribution Lists (DLs), using Outlook to open the DL and edit the group membership that they are the owners of. However, once you move to Exchange Online, these can no longer be managed using Outlook, since the DL is synced from your on-premises AD, and cannot be edited in Azure AD. So, the DL has to be managed in your on-premises AD. Your help desk can do this with Exchange Admin tools, however, it is not very convenient for users to have to call the help desk every time that they want to edit DL membership.
Both mailbox creation and deletion failure scenarios heavily involve verifying the current recipient type values across all directories – especially in a directory synchronised environment. For example; if a user is listed on-prem as a remote mailbox with a cloud archive, then you should expect EXO to have a primary and an archive mailbox for this user. If it doesn’t, then troubleshoot for a synchronisation failure somewhere between on-prem and EXO.
The three attributes you will be dealing with are the following, and there are many possible values for each:
RemoteRecipientType (in PowerShell)
Note: You should only see the above value populated if the customer has a directory sync’d environment, and they either migrated a mailbox to the cloud or if they used new-remotemailbox to provision a cloud mailbox.