This page provides analysis related to enabling Office ProPlus Device Based Activation.
This topic has had some discussion on the ms-tech mailing list. Scott Norton, MSCA service owner, opened REQ1216482 about this topic, but let the request close without response.
There are variety of ways to get and license Microsoft Office. At the UW, the two most common are:
- Office via Microsoft Volume License available as part of the UW Campus agreement
- Office 365 ProPlus via Office 365 available as part of the UW Campus agreement
To be clear, there are several other options, including Office versions for mobile platforms.
There are a variety of names folks use to describe these two most common Microsoft Office clients. These include “Click to Run” (#2), “Fat client” (#1), and others.
These two common Microsoft Office options differ in some key ways. Here’s a table that shows a few key differences:
|License activation||Must apply MAK or KMS to activate license||Must have an appropriate license applied to your Azure AD user object|
|Licensing approach||By computer||By user|
|Method of install||MSI based installer||Click to run based installer|
|Feature availability||Features show up months or more after introduced||Features introduced immediately on a continual basis|
|Interoperability with O365||Limited support from Microsoft, ends 2020||Full support from Microsoft|
You can not mix #1 & #2 on the same computer.
Choosing a preferred Office version and method of activation
At face value, #2 appears superior to #1, and Microsoft certainly recommends it as the best option.
The one downside to #2 is the method of license activation. Users are limited to 5 install activations.
There are many shared computers at the UW. With #2, there is an option to do “shared activation” on a shared computer which does not count against the 5 limit, but the reality of that option is user annoyance. In more detail, this option means that the first time a user uses Office on that computer, they are presented with an interactive dialog where they must enter their UW user account and assuming the computer can connect to Microsoft, they can use Office. If they continue to use that computer over continuing days or the computer is offline, they will need to go through that same interactive dialog process.
There is one other license activation option for #2 which Microsoft calls “device user based activation”. At this time, this option is only available to the Education sector. Conceptually, this option is effectively activating the license by device. As such, it is not subject to the 5 per user install limit. It also does not have the interactive dialog user annoyance. So this is a great option for the UW. But before we jump all in on this option, there are a number of details behind the scenes which are critical to consider.
While conceptually “device user based activation” is device based, in reality it is still user based. In other words, if you use this option for a given computer, the end result is that a special purpose new Azure AD user object is created and an appropriate license is assigned to that special purpose AAD user object. If all of the existing users of #2 were to switch to this activation method, this would mean ~100K new Azure AD users in our tenant. Note that these special-purpose users would never go away, they’d only ever increase. There are a variety of implications here.
So while there is a clearly preferred method, there is a problem to solve …
How to enable Office ProPlus Device User Based Activation in a supported way.
Via additional discussion within the Azure AD Change Advisory Board, the following 4 issues were raised:
- The Microsoft solution seems to provide a single point to compromise many AAD tenants and the permissions required are very broad
- The Microsoft solution is missing any lifecycle management; device users are created but never removed.
- Where do the SKUs come from?
- Do we need to protect the key needed to setup device based activation?
To enable this solution, Microsoft requires a couple things:
- to create an Azure AD application identity for a special Microsoft-run application that implements the license activation details
- to grant that AAD app sufficient admin permissions to do that work (note: this set of permissions falls into a category we consider risky)
- to specify which domain within your AAD tenant the device user objects will be created in
For setup, these are the parameters we must work within. Obviously, if we want to use this solution we must accept the first two requirements. The last requirement is the sole place where we have any real decision within setup.
The AAD user objects created differ from more normal AAD users in our tenant in a couple ways:
- they aren’t created by Azure AD Connect
- because they are not synchronized from our on-premises AD, they have no inherent lifecycle management tied to computer objects there
- their name is in the format “device-<hostname>”
For a variety of reasons, it seems best to segregate these “device users” in a separate domain with no other purpose, perhaps called deviceusers.washington.edu.
Beyond setup, we will have an evergrowing set of AAD users in our tenant, some number of which are unnecessary beyond some point in time. There isn’t really a scalable or fool-proof way for us to gracefully remove those AAD user objects. We might ask customers to let us know, but that doesn’t scale and many
won’t bother. Since there is no automated removal, nor a graceful way for us to remove them, we are left with two general options:
- agree to accept this problem as potential technical debt
- remove objects via an automated process based on some proxy criteria, such as age of the object–and accept unintended impacts as technical debt
It is worth noting that one unintended benefit of these AAD user objects is that our allowed/free number of Azure AD B2B users is increased.
Not putting any lifecycle deprovisioning in place when implementing a new solution is a repeated mistake that often never gets revisited. It is better to put in a less-aggressive deprovisioning solution than no deprovisioning solution at all.
Since we have no real-life experience with these device user objects, there may be criteria we can use which makes more sense and limits the impact.
With respect to the 4 specific concerns noted above, in discussion with Microsoft, we have determined the following:
- Here are the security protections:
- We had heard rumors this solution was run by the Education team, not the Office team: not true. This has gone through the full Microsoft operational release hardening & support cycle. This solution is currently only offered to the Education sector.
- To get at the underlying web app, pre-auth is required: user auth + tenant id + office pro-plus key (where all three of these must align). This limits attacks.
- The web app only can create device users and add license SKU, so if it was compromised that’s the scope of impact—you could then just deactivate the key
- Each tenant has its own separate web site/server.
- The client doesn’t get an oauth token, only the web app does
- The AAD application itself is within Microsoft’s high security tenant, like other multi-tenant MS apps like gallery apps & the admin portals
- There are a variety of security hardening and monitoring protections in place, several of which are designed/configured specific to this application’s expected use
- Microsoft didn’t consider this in its design. They also didn’t realize the complicated environments present at universities which make it so that we can’t easily do this either. They now have a feature request to add lifecycle based on lack of activity for some period of time.
- These are the same Office ProPlus SKUs currently in use. You just need enough to cover both user AND device user based activations. Microsoft gives 1 million without any question and will authorize additional bundles of 1 million, if requested.
- Microsoft isn’t too worried about this; if a key is compromised/abused, they’ll turn it off, and you can switch to another. You can have multiple keys in play at the same time. This may be appropriate if you have discrete sets of devices which have different risk levels associated with communication/sharing of that key.
The following steps are recommended:
- we allow setup of Office ProPlus device user based activation in the UW Azure AD tenant
- we segregate device users to a dedicated domain in our tenant, perhaps called deviceusers.washington.edu
- on a recurring basis, we agree to delete any device user which matches a criteria we determine later
- we give ourselves 3 months to analyze what criteria would be best, defaulting to created more than 5 years ago, if nothing better presents itself
The above recommendation was approved by the Azure AD Change Advisory Board in late 2017. Microsoft Infrastructure then installed the required Azure AD application/service principal with required permissions. Microsoft Collaborative Applications is pondering how to proceed with implementation.