Category Archives: Azure Active Directory

Considerations for Meeting Multi-Factor Authentication Requirements in Office 365

BACKGROUND

Many organizations have stated policies for requiring multi-factor authentication (a.k.a. “2-step verification”) when accessing sensitive data from outside the corporate network. When moving  to the cloud, you are moving the data outside of your corporate perimeter, and you are also allowing your user to access it outside the same perimeter – both the data and the user lives outside your firewalls. This changes the rules of the game, and the existing service access policy must often be updated to reflect these new parameters.

If not considering the big picture, what cloud and SaaS actually means, and by not considering modern security measures such as Conditional Access or Rights Management Services for protecting content instead of just limiting access, it is easy to implement a too complex solution that lead to low user adoption and basically no usage in the mobile context (which Office 365 is very much about). The added complexity of an “MFA everywhere mindset” can actually give an opposite effect – people finding their own ways to solve the problem through rogue IT solutions based on commercial cloud services. A good rule of thumb when designing the service access solution is that “it should never take more time to get connected to do the work than it takes to actually do the work”.

CONSIDERATIONS

This article presents considerations to take when meeting multi-factor authentication (MFA) requirements during an implementation of Office 365, to avoid introducing a solution that causes revolting end-users and decreased business productivity.

CONSIDERATION #1 – KNOW THE MODERN ALTERNATIVES FOR SECURING CONTENT

While multi-factor authentication is often considered as “the silver bullet” when it comes to service access security measures, it is vital to understand the type of innovation that has been going on for the last 5-10 years, and with that the new kind of services that now are available that can protect the content rather than just limiting the access. Multi-factor authentication comes with a cost of complexity for the end-user, and you often find that for the kind of information most users handle day-to-day – multi-factor authentication is not required if an alternative is put to place instead (and there is a wide array of alternatives). Here is a list of example content protection solutions, part of Office 365 and/or EMS/Azure AD Premium, that could be a replacement for, or supplement to, multi-factor authentication:

  1. Azure AD Identity Protection: This service utilizes machine learning and anomaly reports to both present current risk events in your organization and to automatically act on them. As an example, the service can detect credential theft by analyzing log-on behavior (such as simultaneous logon attempts from different continents of the world) and automatically act to secure the account before data is at risk. It will also detect sign-in attempts from infected devices and suspicious IP-addresses, and even patrol the dark web for credentials that are leaked from your organization. Read about Azure AD Identity Protection here. Azure AD Identity Protection is a part of Azure AD Premium and EMS (where Azure AD Premium is included).
  2. Rights Management Services (RMS): Together with data sensitivity classifications, properly introduced RMS can move the protection from access-centric (i.e. VPN, MFA) to content-centric (encrypted content that keeps data secure even if breach/data loss occurs). Read more here. The standard version of RMS is included in Office 365 E3/E5 and as an add-on license, whilst the Premium version of RMS (RMS Premium) is a part of EMS or can be purchased as a standalone license.
  3. Office 365 Message Encryption (OME): For e-mail, this RMS-based technology can keep e-mail body and attachment secure, even when sending to external recipients. Read more here, and see my post about implementing OME here. Office 365 Message Encryption is part of the standard version of RMS (Office 365 E3/E5 or as an add-on license).
  4. Data Loss Prevention (DLP): This service fills two main purposes – it can prevent data to fall in to the wrong hands and it can help the organization to comply with business regulations, such as HIPAA, SOX, PCI DSS and FISMA. Data Loss Prevention can identify sensitive data in e-mail, SharePoint Sites and in OneDrive for Business and allows you to configure measures to be taken when it is at risk for leakage, such as applying RMS encryption or preventing an e-mail from being sent. Read more about DLP here. DLP is part of Office 365 E3/E5.
  5. Advanced Thread Protection (ATP): An intelligent remedy for zero-day attacks and spear-phishing. ATP is first released for e-mail in Exchange Online, but is expanding to Windows Defender and probably to other Office 365 workloads as well, eventually. ATP opens/executes e-mail attachments in a virtual machine and analyze it before delivering them to the recipient. The analysis will find ransomware such as CryptoLocker, or other types of malicious code that has not yet landed as a signature in the regular signature-based spam filter (Exchange Online Protection). ATP will also do the same type of test for any link that is in the e-mail, to protect the organization from spear-phishing. Read more about ATP for Exchange Online here, and ATP for Windows Defender here. ATP is part of Office 365 E5 or as a standalone license.
  6. Conditional Access: The concept of Conditional Access allows you to set device-based conditions for allowing or blocking access to your organizations data. The most common example of this is to require mobile devices to be enrolled (MDM), or mobile device applications to be registered (MAM), together with a policy enforcement of certain sanity requirements (i.e. PIN-code is enabled, device is not jail-broken or rooted etc.). Together with these policies, you can require multi-factor authentication for registering the device, but not later. This allows you to secure content through multi-factor authentication, but just require the mobile token upon device enrollment/MAM-registration, and then trust your security policies to secure the device. Conditional Access is also what allows you to enable multi-factor authentication for Office 365 services individually (i.e. enabling it for SharePoint Online, OneDrive for Business and Outlook/OWA, but not for ActiveSync or Skype for Business) – without Conditional Access, you have to enable MFA in Office 365 for all services or none. Read more about Conditional Access here and here. Basic functionality for Conditional Access is included in Office 365, while more advanced functionality (such as per-workload MFA) requires Azure AD Premium or EMS (where Azure AD Premium is included).

It is first when you understand the full palette of service access and content protection technologies available that you can take the right decision whether if, how and for whom Office 365 multi-factor authentication is needed and should be implemented for in your organization. Remember the two sides of the scale – ultimate usability vs. ultimate security.

Azure AD Identity Protection provides modern features to protect your corporate identities.

Azure AD Identity Protection provides modern features to protect your corporate identities.

CONSIDERATION #2 – THE INSIDE/OUTSIDE PARAMETER AND IT’S EFFECT

After looking into the alternatives, the next thing to consider about MFA is the inside/outside parameter. In most cases, MFA is something that should occur outside the corporate network, but not while at your desk inside the office firewall. To achieve this with Office 365, you must define your inside network by providing all public IP-addresses for your internet break-outs (firewalls and web proxies etc.). By providing all public break-out IP-addresses, Azure AD can at the time of authentication see whether you are attempting an authentication from the corporate network or in the mobile context, so that you can avoid bothering your end-users with MFA while at work. This configuration is called Trusted IPs (or contextual IP address whitelisting), and is also fundamental to the Conditional Access technology mentioned in this article.

The big consideration? If you are not using federated identities with ADFS, it requires one of the following licenses: Azure MFA, Azure AD Premium or EMS (that includes Azure AD Premium. If you are not using ADFS and don’t have any of these licenses, enabling MFA means enabling MFA everywhere – both in the office and outside the office. Read more here. If you are using federated identities / ADFS, you can achieve this even without any of the Azure MFA / Azure AD Premium / EMS if you are using claim rules – again see this post by MVP Johan Dahlbom for details. The post also explains the “Skip multi-factor authentication for requests from following range of IP address subnets” option.

These are the settings where you can define the inside and outside of your corporate network. Important as you probably don't want to bother end-users with MFA prompts when working from the office.

These are the settings where you can define the inside and outside of your corporate network. Important as you probably don’t want to bother end-users with MFA prompts when working from the office.

CONSIDERATION #3 – THE IMPORTANCE OF AZURE AD CONDITIONAL ACCESS FOR SAAS

Under Consideration #1 above, you could read about Azure AD Conditional Access for SaaS. Without this service, multi-factor authentication for Office 365 becomes more complicated to implement in large enterprise environments. Without Conditional Access, you can only toggle multi-factor authentication on or off in Office 365 in one generic setting across the full suite, which includes Exchange Active Sync (mobile access to your e-mail and calendar using the built-in Mail apps in Android and iOS etc.). For Active Sync without Azure AD Conditional Access for SaaS (or ADFS claim rules, see below), the user is required to use something called App Passwords, which are secondary passwords that the user must generate per device in the web browser. The enrollment process for App Passwords is fairly complicated for an average user, and often require a lot of support from Service Desk and similar functions. App Passwords used to be required in the rich Office applications as well, but since the Office 2013 SP1 March 2015 update, you can use proper multi-factor authentication within Office (this version requirement for Office is a consideration in itself).

Using App Passwords for Active Sync in enterprise environments is not working very well in practice, which is why we want to avoid that. By using Azure AD Conditional Access for SaaS, we can choose to enable multi-factor authentication, but keep it “disabled” for Active Sync and instead trust device enrollment (MDM) or device registration in the Outlook app (MAM) to secure mobile e-mail access. If you are using federated identities (ADFS), you can also disable MFA for Active Sync by using claim rules in ADFS, which MVP Johan Dahlbom explains very well in this article. The claim rules solution will also work without Azure AD Premium / EMS.

As mentioned under Consideration #1, MFA can be required when doing MDM enrollment, or when accessing data using MAM – however the important thing here is that your end-users don’t have to enroll for App Passwords to be able to use e-mail and calendar on their phone. Note that the Microsoft Outlook app for iOS/Android/Windows 10 Mobile have support for MFA. Read more about Azure AD Conditional Access for SaaS Apps here.

With Azure AD Conditional Access for SaaS, you can configure individual access rules for the different Office 365 workloads. Here is an overview of the settings available for Exchange Online.

With Azure AD Conditional Access for SaaS, you can configure individual access rules for the different Office 365 workloads. Here is an overview of the settings available for Exchange Online.

CONSIDERATION #4 – MOBILE ACCESS TOKENS AND A GLOBAL USER BASE

The final consideration for implementing multi-factor authentication is to reflect your full user base, and how MFA will work for everyone. Here is a list of parameters to reflect:

  1. Data access and user profiles: Before enabling MFA, think about what data different users in different departments actually can access and is working with. Maybe a certain user profile can only access that is not so sensitive that it falls under the MFA requirement, and does not have to be enabled for MFA?
  2. Overall complexity and user profiles: After MFA is enabled for a user, he or she needs to go through an enrollment process. This process is often straight-forward for someone who spends their full day in front of the screen and reads corporate communications on changes to come. However, there are often user profiles who may have a very hard time to enroll for MFA because of lower it-maturity or interest etc. Do not underestimate the different skill levels across your full user base, and involve all user profiles when you pilot the enrollment process.
  3. Users and devices in developing countries: MFA in Azure AD / Office 365 is using mobile phones to deliver the access token to the user (via SMS text, phone call or through the Microsoft Authenticator app). In developing countries, not everyone is having a smart phone (for the Microsoft Authenticator app) or even a mobile or desktop phone (for SMS text or phone calls). If the user does not have a personal phone, Azure AD / Office 365 MFA is not a good fit. Also, in developing countries there are sometimes delays in delivering SMS text messages or even phone calls (I have seen cases with up to 8 hours of delayed delivery on SMS text messages caused by the local telephony service provider) – this factor is very important to take into consideration before enabling MFA for everyone.
  4. Office versions being used: As mentioned under Consideration #3 above, multi-factor authentication requires at least version “Office 2013 SP1 with the March 2015 update” to support proper multi-factor authentication prompts within the Office-applications, and not requiring the obsolete App Password technology. If you have user profiles that are on earlier versions of Office, you might need to do an extensive upgrade effort before you can implement MFA.

CONCLUSION AND GENERAL RECOMMENDATION

As you can see, there are many things to consider before enabling MFA in Office 365. Factors such as what licenses you have, where/who your users are and whether modern alternatives can meet the security requirements must all be taken in to account.

If you are going to enable multi-factor authentication, I strongly recommend you to do it only for the users who can access sensitive information, using Trusted IPs, and configure it to not use App Passwords for Active Sync (through Conditional Access or ADFS Claim Rules). For dealing with “credential theft”, consider Azure AD Identity Protection. As a last recommendation – pilot thoroughly for all your user profiles before introducing MFA globally.

I hope these considerations and recommendations are helpful. For any questions or article feedback, please reach out via Twitter, @JesperStahle.

Guidelines for Office 365 User Provisioning and De-provisioning Processes – The Lost Documentation

BACKGROUND AND PURPOSE

Introducing Office 365 and Azure AD in an Enterprise environment always raises the question around how object provisioning-, de-provisioning- and organizational change-processes will be affected. These are three common concerns and questions that I get from Enterprise customers in the planning phase of an Office 365 onboarding project:

  1. The customer is using an identity management (IDM/IAM) solution for provisioning accounts, and want’s to better understand how Office 365 / Azure AD will affect that landscape.
  2. The customer have special de-provisioning routines for retaining user data (i.e. keeping the mailbox and home folder data etc.), and needs to know how these processes should be updated when Office 365 is introduced.
  3. The customer understands the provisioning and de-provisioning processes, but want’s to automate them as much as possible.

The purpose of this article is to provide guidelines on how to approach this topic. Please note that these guidelines are intended for large Enterprises that seeks a high level of automation in these processes. Small-/medium-sized organizations with a lower number of employee attrition and/or organizational changes per week/month does not always have to implement automation processes for provisioning/de-provisioning/org changes.

As always with the “Lost Documentation” articles, most of this information is available from Microsoft, scattered over various TechNet- and MSDN-articles – this is my attempt to assemble the information in one place, to assist fellow Solution Architects, system administrators and project managers in the journey to Office 365.

PROVISIONING A USER FOR OFFICE 365 – WHAT COULD POSSIBLY GO WRONG?

Implementing user provisioning processes in Office 365 is generally very easy and straight-forward. Many often think that if you have complex provisioning processes in place today, you will have a hard time make it work for Azure AD / Office 365. This is almost never the truth, as the provisioning processes for Azure AD / Office 365 is “put on top” of what you already have. You kan keep provisioning users based on data from your HR system, and assign them roles based on data in a payroll system, or whatever it is that you are doing – as long as the user is created in Active Directory – it will be provisioned in Azure AD / Office 365 through a separate appliance-like synchronization engine (AAD Connect) without you having to change anything in the current provisioning routines. However, some processes will require updates – i.e mailbox provisioning in Exchange – and you will also be required to assign an Office 365 license to your users before they can use any of the services. The higher ambition you have for automation around these processes, the more challenging this topic will be for you – simply because automation is handled differently by every customer so there is no general answer to how it is achieved.

Below is guidelines for approaching provisioning automation, which can help you update your own routines and processes.

GUIDELINE #1: KNOW YOUR USER PROFILES BETTER THAN EVER BEFORE

The nature of SaaS: Office 365 is a subscription-based service, sold and consumed in a SaaS-model. Each user has assigned services in Microsoft’s data-center, with associated SLAs. A fundamental aspect of this delivery model is that each user must have an assigned license to be able to consume the service. A challenge for large Enterprise customers is that they are used to the traditional ways of purchasing Microsoft licenses (not services), which required a yearly inventory (“true-up”) of how many users were having Office applications, Exchange mailboxes, Skype for Business/Lync profiles, access to SharePoint etc. – and all you had to do as a customer was to share this updated figure with Microsoft – pay accordingly – and continue to use the services.

There have never before been any “enforcement method” that makes Office, Exchange, Skype for Business or SharePoint stop working if you are using more licenses that you have accounted for in your “true-up” – everything has just worked and it has been very much up to your own customer loyalty to make sure that you actually have payed for every user that you have provided with Microsoft software – such as Exchange mailboxes, Office applications, Skype for Business/Lync profiles and access to SharePoint Sites. And of course, this would include all your employees, but also any external user, like consultants getting Exchange mailboxes so that they could send and receive e-mail with your domain.

Don’t under-estimate the task: With Office 365 in place, the reality is changed. Users that are not assigned a license does not get access to any services (can’t activate the Office applications, no mailbox access in Exchange Online, no OneDrive for Business, no access to SharePoint Sites etc.). There is no “grace period” – you will need to have the right number of licenses reserved from your Enterprise Agreement through the VLSC Portal, and these licenses need to be assigned to a user (activated on that user’s account – read more later in this article) in order for that user to be able to use the services. This fact will require you to both know exactly how many users you are providing with Office 365 services, and if you are providing more than one license plan (SKU), i.e you have purchased a mix of E1, E3, E5 and K plans – you will need to know exactly what individuals should be mapped to exactly what license plan.

The task of mapping each user to a user profile (license SKU) is often extremely under-estimated. It is important to understand the consequences of not having the user profile mapping completed before commencing the Office 365 onboarding project. The consequence includes:

  1. The onboarding project will be stalled, as licenses will either run out, or the technical team doing the onboarding will at a certain point in time need to know what licenses to assign for each user, as all users are onboarded.
  2. The business case for moving to Office 365 will be impacted. Let’s say you invested in 50 000 E3 licenses, because that was the amount of Office ProPlus licenses you bought in the traditional license model. As it then turns out, you were actually providing these services for 55 000 users, you just had not calculated for all the external people who you have provided with IT-tools. This would mean an additional cost of 10% over your initial Office 365 investment.
  3. Users would get insufficient or wrong services assigned. Imagine if you assign E1 licenses to a department of 5000 users where you deploy Office 365 ProPlus – no one would be able to activate their Office applications, and your support organization would have to take the hit. Another consequence of getting the wrong services assigned is that you pay an extreme over-price for a user getting more services than he or she ever would actually use.

So before you dig deeper into the technology around provisioning, it is recommended that you map each and every user account in your organization to a user profile, which also translates to a license SKU.

Clean-up: Also note that accounts (i.e. Active Directory users with or without Exchange mailboxes) that are not actively used cannot be provisioned without an active license, which means that if you have licenses for 50 000 users, but you have 60 000 mailboxes in Exchange, where 5000 are Shared Mailboxes and Equipment/Room Mailboxes (these are free in Office 365 / Exchange Online), you have an overhead of 5000 user mailboxes which will need to either be removed or to acquire a license. Cleaning up your Active Directory and Exchange Server from inactive user objects and mailboxes before Office 365 onboarding is as important as the user profiling work itself.

GUIDELINE #2: UNDERSTAND IDENTITY/USER PROVISIONING AND LICENSING

Identity Bridge: The recommended way for Enterprise customers to provision users, groups and contact objects in Azure AD / Office 365 is by extending your on-premises Active Directory to the cloud through an appliance-like synchronization tool called Azure AD Connect (AAD Connect). The tool was previously known as DirSync and AADSync, and there was also a standalone FIM / MIM Management Agent – all these three still works, but future development will only be done in AAD Connect, which makes that the best choice for every organization today, regardless of complexity and identity landscape in general. Hand-in-hand with identity synchronization for provisioning and administration, a security token service (like ADFS) is usually implemented to provide single sign-on to Office 365 – this however has actually nothing to do with provisioning, why it will not be mentioned more in the article.

Sync: With AAD Connect in place, the on-premises Active Directory will be replicated to the Azure AD / Office 365 every 30 minutes. All your users, groups and contact objects will be provisioned in Azure AD / Office 365, but no Office 365 services are assigned to any users until you assign a licenses yourself as an admin. AAD Connect makes sure that you keep administrating your identities the same way you are today, and that you won’t have to maintain multiple identities (on the ground and in the cloud). It also makes sure that what ever identity provisioning routines you have in place today will continue to work as before, as long as they provision identities in Active Directory, AAD Connect will do the rest on top of what you already have.

Beware of 3rd-party or self-made sync: It is not recommended to replace AAD Connect with a 3rd party or self-developed synchronization / provisioning script (i.e. PowerShell / REST API provisioning). The main reason is that it will not be supported for all complex scenarios (such as Exchange Hybrid Configuration, attribute write-back scenarios, etc.). There is a AAD Federation Compatibility List (previously known as the “Works With Office 365 Identity Program”) that lists 3rd party STS services compatibility towards federation with Azure AD / Office 365 – found here – however, not many are reading the top note on the page that says that the solutions listed are only tested for federation scenarios – synchronization and multi-factor authentication scenarios provided by 3rd party vendors are not supported by Microsoft.

Synced users needs licenses: When AAD Connect is in place and is replicating your Active Directory data to Azure AD / Office 365, you will need to license users in order to activate them for Office 365 service – such as being able to active Office 365 ProPlus or read content from SharePoint Online. Assigning licenses can be done manually via the Office 365 Admin Portal, but if you want to automate this for Office 365 licenses, you have to create your own solution as of now. The recommendation is to implement a PowerShell-script that assigns licenses based on Active Directory attributes or Security Group membership. This script can run as a Scheduled Task, for example on the same server that hosts AAD Connect. A good place to look if you want to automate user licensing with PowerShell is at this post by Office 365 MVP Johan Dahlbom (and in this post he explains how to do it with Azure Automation).

Two things before you sync: It is recommended that you inspect your Active Directory for directory quality errors before you automate your identity provisioning and administration with AAD Connect. Use the IdFix tool to run the inspection and then remediate all errors found. It is also recommended that you change your users UPN-names to match their primary SMTP-addresses before you sync. You don’t have to change the samAccountName, so users can keep logging in to Windows etc. the same way as before. The main reason to why you should change UPN-names to match SMTP-addresses is that users should know what username to use when accessing Office 365 in the mobile context (it has to be in the UPN-format). If you have contemplated Alternate Login ID as the solution for this, beware of the limitations (great article here by Joe Palarchio) – I generally do not recommend using it.

GUIDELINE #3: UNDERSTAND MAILBOX PROVISIONING – DURING AND AFTER COEXISTENCE

With our user profiling, AD/Exchange clean-up, identity bridge and automated licensing in place, we are ready to look at process updates required for provisioning Exchange mailboxes.

Different ways depending on if you do hybrid or not: If you have established an Exchange Hybrid Configuration, you will provision mailboxes as an administrative task much like you have done before, until the last Exchange Server and the hybrid configuration is fully decommissioned. If you are not in a hybrid configuration, you will provision mailboxes simply by assigning a license for Exchange Online to one of your users. Let’s break down the rationales and guidelines:

As long as you are in an Exchange Hybrid Configuration with at least one Exchange Server still running on-premises, you can provision new mailboxes directly in Exchange Online by creating new “Remote Mailboxes”. A Remote Mailbox is a mailbox in Exchange Online that you can see and manage from your Exchange Server administration tools. You can of course create Remote Mailboxes from your Exchange administration tools (GUI), but for automation purposes it is recommended to use PowerShell. For updating your mailbox provisioning routines to create remote mailboxes in Exchange Online while you still have Exchange Server on-premises, study and use the PowerShell cmdlets for provisioning new Remote Mailboxes. Here are some examples:

To create a new Remote Mailbox for an Active Directory Mail User that you have provisioned on-premises, synced to Azure AD and assigned an Office 365 license (the most common scenario), run the following command in the Exchange Management Shell:

Enable-RemoteMailbox -Identity <UPN-name> -RemoteRoutingAddress <USERALIAS>@<TENANTNAME>.mail.onmicrosoft.com

To create a new user in the on-premises AD and a new Remote Mailbox that will be enabled when the new user is synced by AAD Connect (a fairly common scenario), run the following command in the Exchange Management Shell, and then license the user:

New-RemoteMailbox -UserPrincipalName user@domain.com -Name “Display Name” -OnPremisesOrganizationalUnit OU=Users,DC=addsdomain,DC=com -Password (ConvertTo-SecureString -AsPlainText “Pa$$word” -Force)

To create a new Shared Mailbox directly in Azure AD / Exchange Online as a Cloud ID (without any corresponding AD-user on-premises), run the following command in PowerShell, after connecting to Exchange Online:

New-Mailbox -Shared -Name <UPN-name> -PrimarySmtpAddress <User>@<DOMAIN>.com

(If you want the Shared-/Room-/Equipment Mailboxes to be represented in the on-premises AD, you will need to provision them as User Mailboxes first and convert them to shared mailboxes afterwards and remove the licenses – Shared-/Room-/Equipment mailboxes does not require a license once they are provisioned as such).

If you are not in an Exchange Hybrid Configuration, you provision mailboxes simply by assigning users with the correct attributes and an Office 365 license (that includes Exchange Online). The attributes that must be populated before you sync and license the users are: proxyAddresses (should include all necessary SMTP- and SIP-addresses), mail (should be populated with the primary SMTP-address), UPN (should preferably match the primary SMTP-address), Display Name (as you want it to appear in the Global Address List). The same process goes for Distribution Groups – you provision them in the on-premises AD with these attributes (minus UPN) populated, and then let AAD Connect synchronize them to Azure AD / Exchange Online.

About administration of Exchange Online: When AD synchronization with AAD Connect is enabled, most attributes are owned by AD on-premises, and you will therefore not be able to fully administer Exchange Online from the web-based administration portal (Exchange Control Panel). Some Exchange-attributes (such as proxyAddresses) simply must be administered in the on-premises AD and be synchronized to Azure AD / Exchange Online for the change to have effect. Because of this, it is worth noting that if you are decommission all Exchange Servers on-premises, you might need to build in more Exchange administration to your IDM / IAM provisioning and self-service tools than what you had before. End-users that administer Distribution Groups in Outlook are also affected, as this will for the same reasons stop working after the users mailbox is moved to Exchange Online – self-service tools for Distribution Group/List management will be required.

GUIDELINE #4: UNDERSTAND SKYPE FOR BUSINESS (LYNC) ONLINE PROVISIONING

Skype for Business Online (formerly known as Lync Online) provisioning works in the following way:

  1. If you have Lync Server or Skype for Business Server on-premises, and have users provisioned there with active SIP-profiles, and you are using AAD Connect so sync your AD on-premises to Azure AD / Office 365, no provisioning will occur in Office 365 for the SIP-enabled users, regardless if you license these users for Skype for Business Online in Office 365.
  2. If you license SIP-enabled users for Skype for Business Online, and then remove the SIP-profile from Lync-/Skype for Business Server on-premises, users will be provisioned for Skype for Business Online at the next AAD Connect sync cycle (often referred to as a “cut-over move”).
  3. If you are leveraging a Lync-/Skype for Business hybrid configuration, users must be licensed for Skype for Business Online, and you can then move users from the on-premises pool to the online pool. When all users are moved, you can for the purpose of provisioning decide to keep or remove the on-premises Lync-/Skype for Business Server environment, and select another provisioning method from this list of guidelines.
  4. If you are not having Lync-/Skype for Business Server on-premises, you provision users for Skype for Business Online simply by assigning them an Office 365 license (with Skype for Business Online included). It is recommended that you in this case populate the proxyAddresses attribute in the on-premises AD with a SIP:-address that matches the primary SMTP address.

GUIDELINE #5: UPDATE YOUR PROCESSES FOR DE-PROVISIONING USERS

There are many different aspects of user de-provisioning, including return of licenses, removing permissions, store/hold user data, etc. By understanding the fundamentals of how Azure AD / Office 365 de-provisioning works, you will be able to update your current processes to work with Office 365. Here are the fundamentals you should know about:

  1. If you are disabling a user in the on-premises AD, you are disabling the user in Azure AD / Office 365, but the license is still active.
  2. If you are deleting a user from the on-premises AD, you are deleting the user in Azure AD / Office 365. When this happens, all data is soft-deleted for 30 days and the license is returned to the license pool. If you restore the user within these 30 days (restore the user in the on-premises AD and sync the user again), all data will be kept. If you don’t restore the user within 30 days, and have not applied any rules for data Hold, the data is lost.
  3. If you remove the license from a user in Office 365 (for example if you move the user to a OU for de-provisioned users, disable the account and strip it from it’s group memberships as your de-commissioning routine in the on-premises AD), all data is soft-deleted for 30 days. If you re-assign the license to the user within the 30 days, and have not applied any rules for data Hold, all data will be kept. If you don’t re-assign the license within 30 days, the data is lost.
  4. If the user is licensed when it is deleted and the Manager field is populated for that user in AD, the Manager will be notified and given access to the users OneDrive for Business site for 30 days through the Access Delegation mechanism, explained here. If you remove the license before actually deleting the user, the Access Delegation process will not be triggered.
  5. There are different ways to keep the data for more than 30 days after you have removed the license from a user. The general recommendation is to use the Hold capabilities, administered from the Office 365 Protection Center.

GUIDELINE #6: UPDATE YOUR PROCESSES FOR ORGANIZATIONAL CHANGES

When users go through a department change, country transfer or other forms of organizational change, there are often identity-related processes that goes with it. In Azure AD / Office 365, it is much like with the provisioning; you can keep doing what you did before and let AAD Connect handle all the provisioning aspects in Azure AD / Office 365 for you. There is however one concern regarding the UPN attribute that you should be aware of. Here are the fundamental guidelines for organizational changes:

  1. If the organizational change is resulting in attribute updates, or even changes of Organizational Units, in the on-premises AD – let AD Connect take care of updating this in Azure AD / Office 365 for you through the regular synchronization cycle.
  2. Beware of delays that can occur, such as generation of the Offline Address book used in Outlook that can make updates in the Global Address List need a day to show up to all users, or back-end replication to SharePoint Online to let all organizational attributes show the correct values.
  3. If the organizational change requires a change of the UPN-name and the user is licensed, you will need to manually give it a push in Azure AD in order for it to change, AAD Connect can not change UPN-names in Azure AD / Office 365 for licensed users. To manually fix the UPN-name for the licensed user, follow the steps outlined in Scenario 2 in this article. A summary of the steps: change the UPN-name in the on-premises AD, let AAD Connect run a sync cycle, then connect PowerShell to your Azure AD tenant and run this command in PowerShell:

Set-MsolUserPrincipalName -UserPrincipalName [CurrentUPN] -NewUserPrincipalName [NewUPN]

SUMMARY AND DISCLAIMER

All guidelines presented here are based on my field experience and are made available for your own interpretation to assist in updating provisioning/de-provisioning routines in the move to Office 365. I hope you will benefit from these guidelines, and that you will give me suggestions for more topics that would make this article more complete. I am always listening to feedback on Twitter. Thank you for reading.

Autodiscover and rich Outlook configuration fails but SSO for OWA/Lync/Portal works (“The AD FS 2.0 Windows Service service failed to start due to the following error: The service did not respond to the start or control request in a timely fashion.” ExRCA: “A network error occurred while communicating with the remote host. “) – CRL check in ADFS is failing

BACKGROUND

The following works:

  • You have successfully deployed ADFS and Single Sign-on  with Office 365
  • You can successfully log on to the Office 365 Portal, Outlook Web App and the rich Lync client using SSO (Active Directory credentials) both from the inside and outside (through ADFS Proxy)
  • You have added the correct CNAME for the Autodiscover service in the public and internal DNS zone for you custom domain
  • You can successfully access the ADFS metadata from the outside by opening https://sts.domain.com/adfs/services/trust/mex in the web browser – it displays content. (sts.domain.com is the URL to your ADFS Proxy)

The following does not work:

  • When attempting to configure an ActiveSync device with Autodiscover (entering e-mail address and AD-password), the configuration fails and the device asks for server name.
  • When attempting to configure your rich Outlook client, the configuration fails and repeatedly ask for username and password during Autodiscover configuration
  • ExRCA (http://testexchangeconnectivity.com) tests for Autodiscover fails with the following error:
    Testing TCP port 443 on host autodiscover.domain.com to ensure it’s listening and open.
      The specified port is either blocked, not listening, or not producing the expected response
    Additional Details
      A network error occurred while communicating with the remote host.

CAUSE

As SSO with the Office 365 portal, Outlook Web App and the rich Lync Client works, as well as accessing the ADFS Metadata, you will probably not think that this issue is ADFS related, but rather related to a back-end error of sort in the Exchange Online service. However, looking in to the ADFS configuration, you may find event 7000 with the following explanation:

The AD FS 2.0 Windows Service service failed to start due to the following error: The service did not respond to the start or control request in a timely fashion.

This is related to why Autodiscover, ActiveSync and the rich Outlook client configuration will not work.

If you investigate the network traffic while attempting to start the ADFS Service, you might find that the service is attempting to do a CRL check for the certificates. This fails, which causes the service start to time out – leaving you with an ADFS service that works good for Office 365 portal, OWA and Lync – but not Autodiscover, ActiveSync and rich Outlook.

This may occur if:

  1. The ADFS servers can’t access the Internet for CRL lookups
  2. You are attempting to use web Proxy for the CRL lookups, but the Proxy configuration is faulty (bad IE Connections settings or missing connectivity between ADFS servers and the web Proxy itself)

The failing CRL check will not reveal itself in the event log, you can however see it by monitoring the network traffic.

RESOLUTION

First, verify that the ADFS Service account have Log on as a Service and Log on as a batch job rights. (The behavior can occur if this is missing as well). Then, follow one of the solutions below to remediate the problem with CRL verification access from the ADFS servers.

Solution 1 – Fix the CRL Access:

  1. Verify that you have proper web Proxy (IE Connections) settings on the ADFS servers. Verify that you can access the Internet, or needed Internet hosts for CRL checks in your Environment.
  2. Start the service and see that it comes online properly.

Solution 2 – Turn off Automatic Root Certificates Update:

  1. Open gpedit.msc (Start\Run)
  2. Navigate to Computer Configuration \ Administrative Templates \ System \ Internet Communication \ Internet Communication
  3. Open Turn off Automatic Root Certificates Update and set it to Enabled
  4. Start the service and see that it comes online properly.

Note: Solution 2 is here described for the local Group Policy which applies if you are using Security Baseline configuration on the server. If an Active Directory GPO is controlling this setting, you need to set this in the AD GPO.

 

After applying Solution 1 or 2 above, and verifying the Log on as a service and Log on as a batch job rights for the ADFS Service Account, Autodiscover and rich Outlook configuration will work.

DirSync Installation Fails Product: Microsoft Online Services Sign-in Assistant — Newer version already installed.

BACKGROUND

When installing DirSync, the installation fails without a very good explenation. After investigating the MSI logs and the Event Viewer, you find the following statement:

DirSync Installation Fails Product: Microsoft Online Services Sign-in Assistant — Newer version already installed.

The scenario where I have seen this is where a machine is used for DirSync where the Windows Azure Active Directory (WAAD) PowerShell Module have been installed. To be able to run the WAAD PowerShell module and connect it to Office 365, you need to install the Online Services Sign-in Assistant (SIA). That leads you to Microsoft Download Center that provides the SIA, currently in version 2.1. Already have WAAD Module in Place Before deploying DirSync is normal if you are using one of your ADFS STS Machines as DirSync server as well (which is a common scenario).

CAUSE

The problem is that the DirSync.exe installer has the SIA embedded, but with an OLDER version! When trying to install DirSync, it wants to deploy SQL Express, install a stripped version of ILM/MIIS and of course – deploy SIA. This FAILS because you already have a newer version.

RESOLUTION

Go to the Control Panel\Add Remove Programs and Features and remove your Sign In Assistant. Then deploy DirSync again. It will work perfectly and install the embedded version of SIA. You can later upgrade to SIA 2.1 (or later) again if you like – no worries.

Connect-MsolService : Unable to authenticate your credentials. (Wrong WebServiceUrl value in Registry)

When trying to connect to MSOLService by running Connect-MsolService , you get this message:

Unable to authenticate your credentials. Make sure that your user name is in the format: <username>@<domain>. If this issue persists, contact Support.

You have tried the obvious things like re-installing the Sign-in assistant, configured microsoftonline.com in your Proxy accordingly and verifying the credentials by logging on to the Admin portal etc. Maybe you even followed all the steps in KB2494043. Everything seems fine, but still you get this error message about credentials in the wrong format etc.

There is one more thing to do. Try the following:

  1. Fire up the Registry Editor
  2. Navigate yourself to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSOnlinePowerShell\Path
  3. Investigate the Key called WebServiceUrl – it might contain a misspelling! I have seen microsoftonline.com been thrown around to onlinemicrosoft
  4. Verify that the value is https://provisioningapi.microsoftonline.com/provisioningwebservice.svc
  5. Re-start PowerShell.exe and try connecting again.

I have seen this issue in the field, after installing Windows Azure Active Directory PowerShell cmdlets on the same machine as DirSync is running. It is obvious a misspelling caused by human error.