This fall I started working on a new customer project related to procurement and management of Microsoft online licenses.
When we started to discuss about the topic in more detail, the team and I quickly realized there was quite some different understanding about what licenses are and how all the components of it should be named. Naturally there were non-technicians involved as well, which retained their focus on the contractual and procurement parts. The management and departments had their feature-driven request concert defined as well, using yet another way to describe things and from different angles. Even though I’ve been working in that area for years, I was surprised how hard it was to explain this to my new stakeholders.
When we were looking into Microsoft documentation, reading through community blogs and stuff, we didn’t get any clear answer that would really give us an absolute definition what Microsoft online licenses really were, and how we could properly explain it to everyone inside and outside the team. It seemed extremely challenging to get a common understanding of the terminology. This didn’t help for our research about the effective work we had to begin with.
Have you ever had a conversation about what licenses one should buy to receive a particular feature in Office 365? Did you receive a question about what license would give you the best value? Did you get a task to help with cost optimisation? Have you ever tried to explain the differences between Office 365 Enterprise license packages, Enterprise Mobility & Security license packages, product names like Azure Active Directory, product licenses like Azure Active Directory Premium (Plan 1), service plans like Microsoft Azure Multi-Factor Authentication, or service features like Azure AD Privileged Identity Management? Sometimes product licenses and service plans are even named the same (Oh hello, Azure Active Directory Premium Plan 1!). And as if that wasn’t enough, Microsoft marketing is very good at promoting new features of existing services even as a completely new product. Not to forget about rebranding products regularly. Then there is the Azure Cloud Computing area as well – very easy to mix up stuff that is only partially related to the Microsoft 365 world. By the way when do you talk about Microsoft 365, and when about Office 365? What is all this E1, E3, E5 – or was it Enterprise E1, Enterprise E3, Enterprise E5? And where is E2 and E4?
Sounds familiar or did you even get confused yourself by now? Can you explain the connections, differences and similarities for a product, a license, a subscription, a package, a service, a plan, a feature, or a function? Don’t worry, you’re not alone. (And sorry for the rant).
The Microsoft world has become so complex to understand (and to keep up with), it is for a good reason some people do this as their full-time job. While I might not answer all questions here in every detail, I will try to give you some orientation to understand the relations so you know when to use which word correctly.
First, you have to understand there is always two main aspects around Microsoft online licenses:
Much of the terminology begins making sense when you remember that licenses are a way for Microsoft to control access to its online services for customers. This may sound far too simple, but in fact this is rarely in mind when talking about licenses. There were days when you maintained a piece of paper (called a product license) and that would simply legally qualify to use a product. Then shortly after there was the invention of a license product code that you had to enter into the application on a computer to prove that you had properly bought it from the manufacturer. Next, the application actually validated the product code online to restrict parallel installations. And so on and so on.
Especially for people outside of sales or for non-native speakers of English, this conscious link is frequently missing. Hint: I am not a native english speaker myself nor am I a sales person, so some aspects might be more than obvious to those who are.
While the distribution aspect is totally non-technical, the actual activation is almost only technical. Moreover, from R&D perspective, distribution comes after. When the product is there, this turns into the opposite because first you shall go to your distributor to purchase a license, then get access to the product. Again too simple, right?
The trick is to work out the overlaps of technical and non-technical aspects, to perceive how a service manifests as a selling product, and to remember how marketing and distribution work. To me, there is additionally some devil in the detail about the differences between products, services, and features (function is just a synonym that might be interchangeable.).
Let’s start to explain the origin of everything: The online service itself.
Logically, one or many features are part of a service. People familiar with IT service management (aka ITSM) remember this as they do a similar thing when they define their (internal) IT service. The difference is that for internal IT, they often are combining different pre-existing products (often from different vendors) into a single IT service in order to have a single entity to manage. Technically you could also describe this as system integration.
Being a service provider for their own products, Microsoft does the same thing when developing new features and making them available to their customers:
Features of a service are combined into at least one service plan. A plan represents a set of features to be available to the user in a specific online service. This means the service plan is actually part of the user authorization process to access and use certain features within a service. It also means that during development of a feature, access management is already taken into consideration on a quite granular level (well, let’s ignore all the burden of the legacy on-premises world that still sits deep into some products whose names shall be unspoken aloud…).
Note: You should not mix up the words service plan and license plan because it is not the same. Sharing some lessons learned, it is a clever idea to imagine there is no such thing like a license plan. When you use it, most people will not know right away to which level of the whole licensing story you are referring to. Simply minimize such misunderstandings. The term license is completely irrelevant here and will be explained later. Whenever you talk about a plan, it should essentially refer to a service plan which is basically about activation of a service with a specific set of features to an end user. It is not about how you get such service plan available into your tenant or about license compliance.
Multiple service plans
Depending on how Microsoft wants to make money or promotion, not all features will be put into the same service plan. There could be a basic service plan consisting only 3 of 10 available features. Then there might be a premium service plan, consisting the 3 features of the basic service plan and adding 4 additional cool features. Maybe there is still 3 superior premium features left so those are again being added to another service plan to represent the full feature set of the service. In rare cases there might also be a technical or security reason to have separate service plans. For example, it might be the only way for the customer itself to control end user access because the service lacks some advanced access control (e.g. it is unable to validate for correct group membership of a user.).
There is a typical pattern that Microsoft frequently uses to distinguish such expanding service plans by simply adding Plan 1, Plan 2, Plan 3 (and so on) to the end of the service plan name.
An imaginary example:
SERVICE NAME
│
└─── SERVICE NAME Plan 1
│ - Feature 1
│ - Feature 2
│ - Feature 3
│
└─── SERVICE NAME Plan 2
│ - Feature 1
│ - Feature 2
│ - Feature 3
│ - Feature 4
│ - Feature 5
│ - Feature 6
│ - Feature 7
│
└─── SERVICE NAME Plan 3
│ - Feature 1
│ - Feature 2
│ - Feature 3
│ - Feature 4
│ - Feature 5
│ - Feature 6
│ - Feature 7
│ - Feature 8
│ - Feature 9
│ - Feature 10
A practical example for this would be the Azure Active Directory service: There is a basic plan free of charge, and there are two paid premium plans.
What you can note from this particular example as well is, that the free plan does not start with a name Plan 1, the free plan is simply called Basic. For other services however, even the free service plan starts with a name of Plan 1. It is sometimes inconsistently named, in particular when looking behind the marketing facade. What you can see there is that service plans are created very early in the process, and as they got an internal name that – due to technical limitations – can not be changed thereafter anymore, it is pretty obvious that the selling aspect is still undefined at that point in time. Naturally there is a display name that can be changed later on to better fit into the marketing machinery and this display name quite often is completely different. Indeed, it is very fascinating to sneak around in the technical details because there is so much to make conclusions from it. Somebody familiar with the matter might ask “Why are they using a fixed name, why are they not using a random universally unique identifier (UUID) like everyone else does?“. In fact, this is what Microsoft has started to do now in parallel for newer implementations. However, it seems they can’t get rid of the textual identifiers quite soon and probably never will, so they will just stay in parallel for compatibility reasons.
Another pattern I identified is that when it comes to some enhanced security features, there is often a Plan 1 for monitor-only or manual control/operation. Then there is a Plan 2 which will allow you to automate stuff, provide active help for end users, or bring some intelligence into the game and provide useful benefits for your IT governance. This is not only valid for Azure Active Directory, but for example also Cloud App Security (CAS) and Microsoft Information Protection (MIP, in progress to be renamed from Azure Information Protection, AIP).
Dependant service plans
Service plans sometimes are defined inconsistently. It doesn’t always matter if you have enabled or disabled a Plan 1 when you have a Plan 2 enabled for the user already. However, it might also be that Plan 2 was defined as some kind of an add-on service plan that in fact requires the features that Plan 1 will enable. It is hard so foresee such hard dependencies because they are not always evident. Sometimes a plan is a replacement for another, or it can be a supplementary plan. This very much depends on the service and the feature as well. There is no general rule as of today.
As a general rule of a thumb, you should always enable Plan 1 before you enable a Plan 2 of the same service. That way you’re on the safe side (with some exceptions, see Service plan conflicts below.).
In some cases, there can also be dependant service plans that seem to be totally unrelated. For example, MyAnalytics is actually an Exchange Online feature but is often not seen as being part of Exchange Online. This is also caused by the fact that you cannot purchase MyAnalytics as a single license, it only comes with Office 365 E5 or Microsoft 365 E5. It becomes more obvious if you go down to it on a technical level where you can implicitly assume this, based on internal names that Microsoft is using (e.g. see Product names and service plan identifiers for licensing).
Service plan conflicts
Depending on how a particular service works, there can also be conflicting service plans for it. Typical examples are service plans for SharePoint Online and Exchange Online. These services are unable to merge multiple service plans into a superset of features they ultimately apply to the end user, especially not when there is multiple product licenses involved and many include a service plan for the same service.
This can happen if you assign multiple licenses to the same user. For example, if you are dealing with Project Online or Dynamics 365 licenses, they will bring their own service plan for SharePoint Online Plan 2. This is to ensure users have the full feature set of SharePoint Online available in order to work with the Dynamics platform, even though they otherwise might only have a very basic license like for firstline workers (F1) or even no other license at all. In that case, the inferior SharePoint Online service plan needs to be disabled first so that the full service plan can be enabled.
For those interested, there is a list available from Microsoft here.
Ineffective service plans with tenant-level features
There are quite many features that once you have a service plan enabled for only a particular user, the feature becomes available to everyone. It does not matter anymore whether you had assigned a product license with a corresponding service plan to a user, or if you had even enabled such service plan. The reasons for such incomplete license handling are undoubtedly very divers; I personally think it is mostly due to time-to-market aspects.
Great, you might think, but in fact your license compliance obligation still matters. It has just become your own objective to restrict access to as many users as you have appropriate licenses available in your tenant. Microsoft describes more about such services here.
Fortunately, most services or features can be restricted to specific group membership only. However, it rapidly becomes a nightmare to manage for more global organisations. It even becomes worse when you realize that Microsoft might subsequently introduce real service plans for such services over time where you had features available to users who suddenly disappear for them. If you had ignored the risk of an audit and being noncompliant before, at least be sure to be properly prepared for a huge wave of complains at your 1st level IT support.
Proper management of change as part of IT governance processes has become key to effectively and efficiently prevent such costly occurrences.
Let’s put ourselves in the position of a marketing and sales person. The software department has completed a new service, and it will now become your product. Before it can actively be sold to the market, you have to become creative to invent a story line that will support you to properly explain it to potential customers. This is where it starts differentiating between a service and a product: A service is what you are delivering, a product is what you are offering to deliver the service later on. Sounds hairsplitting? Almost.
A product is defined, designed and formed precisely to support the whole line of distribution. You transfer the services that you have and shape a product out of it that will greatly help you to make the most money out of it. Consequently all you need to do is to invent a fancy product name, right? Not quite.
For most of the services, Microsoft is selling different product variants that will provide different feature sets to you, depending on how much you are willing to spend. Are you connecting the dots to the service plans from above already? Great, this is what they have been developed for in the first place.
Sales people might often use the term Stock Keeping Unit (SKU) which simply refers to a particular product variant. It has actually also become a technical term because during implementation of the product variant as a product license with service plans, Microsoft programmers had make use of that same term to describe what they are implementing. This is why a lot of tech discussions on the internet will also use SKU but in fact they are talking about a service plan. Sometimes for tech people SKU is even a unique identifier of the service plan, but most of the time they won’t tell you which identifer exactly (remember there is a textual identifier and a UUID?). You always have to imply this from the context and this is why doing research on the internet about Microsoft licenses is so exhausting.
Reasonably often, there is a direct 1-to-1 relationship between a product variant and a service plan. Both then actually mean the identical thing, just one is the non-technical term, the other is the technical term.
Following our imaginary example about a service plan structure from above, this looks extremely similar for a product and its variants:
PRODUCT NAME
│
└─── PRODUCT NAME, variant 1
│ - Feature 1
│ - Feature 2
│ - Feature 3
│
└─── PRODUCT NAME, variant 2
│ - Feature 1
│ - Feature 2
│ - Feature 3
│ - Feature 4
│ - Feature 5
│ - Feature 6
│ - Feature 7
│
└─── PRODUCT NAME, variant 3
│ - Feature 1
│ - Feature 2
│ - Feature 3
│ - Feature 4
│ - Feature 5
│ - Feature 6
│ - Feature 7
│ - Feature 8
│ - Feature 9
│ - Feature 10
Upselling and reduction of prices
Once you realize which product variants matter most to your customers, you start thinking about how you could sell even more to them. This is called upselling and essentially what you are attempting to achieve is to make your customers using more and more of your services and advanced features.
Microsoft has defined unique products that I would describe as virtual products because they don’t have a 1-to-1 relationship to a single service plan anymore. Instead, it is a bundle of many single products that Microsoft then calls a package (short: pack). Clearly it makes sense to spend less money on the package than what you would need to spend for getting all the single licenses. To make packages even more attractive, there are sometimes services or features that can not be purchased as a single product (for example: MyAnalytics). In my opinion, this exclusive bundling often just complicates decision makings.
If you practically got a mental breakdown because of all the different single products and all their product variants before, a package should then appear to you as your sheet anchor. Microsoft wants to make it easy for you (and your mental health) to go for a package instead of just one or two single products. Indeed, after considering only 2 or 3 single products, some packages become already cheaper and will also allow you access to additional services you didn’t actually consider in the first place.
However, of course there can be different variants of such a package again.
To remain things abstract with our imaginary example, a complete package family would now finally look quite a bit different:
PACKAGE NAME
│
└─── PACKAGE NAME, variant 1
│ └─── Product Name 1, variant 1
│ │ - Feature 1
│ │ - Feature 2
│ │ - Feature 3
│ └─── Product Name 2, variant 1
│ │ - Feature 1
│ │ - Feature 2
│ │ - Feature 3
│ └─── Product Name 3, variant 1
│ - Feature 1
│ - Feature 2
│ - Feature 3
│
└─── PACKAGE NAME, variant 2
│ └─── Product Name 1, variant 2
│ │ - Feature 1
│ │ - [...]
│ │ - Feature 7
│ └─── Product Name 2, variant 2
│ │ - Feature 1
│ │ - [...]
│ │ - Feature 7
│ └─── Product Name 3, variant 2
│ - Feature 1
│ - [...]
│ - Feature 7
│
└─── PACKAGE NAME, variant 3
│ └─── Product Name 1, variant 3
│ │ - Feature 1
│ │ - [...]
│ │ - Feature 10
│ └─── Product Name 2, variant 3
│ │ - Feature 1
│ │ - [...]
│ │ - Feature 10
│ └─── Product Name 3, variant 3
│ │ - Feature 1
│ │ - [...]
│ │ - Feature 10
│ └─── Product Name 4
│ - Feature 1
Did you already have candidates for packages in your mind? If you had thought about Enterprise Mobility & Security or Microsoft 365, you’re exactly right!
Congratulations if you had also thought about Office 365 being a package. Office 365 is likely the most misunderstood brand name ever. As you can see, it does not only describe a whole platform; it can also be interpreted as a licensing model. Not to mention all confusion between Office 365, Office ProPlus, and Office Online (What is Office?).
Needless to say, when Microsoft was first designing their new online services almost a decade ago, offering a package and naming it Office 365 was all about it. There were even different package variants available already then. Have you read about Office 365 Enterprise E1 and Office 365 Enterprise E2? Here you go, those are the package variants!
However, these days Microsoft has removed Enterprise from the package names because essentially this is what the E in E1 or E2 already represents. In fact, the E-x notation became so popular and well known that you can detect this on a whole lot of other packages that Microsoft offers for enterprise customers, not just Office 365. We also got other variants for Small, Medium, and Mid-sized organisations. As those companies typically know they are not enterprise and often don’t even want to be seen as such, product variants for those companies seem to avoid to include the term “enterprise”, even the E-x notation. Currently, all non-enterprise offerings are simplified to just be named Business, likely because all the choices between small, medium, and mid-sized was moderately overwhelming for companies that simply don’t have to deal with their IT that much.
Wait, did I just say Office 365 E2? You got me; this package variant is not for sale anymore and got replaced by Office 365 E3. As you might have guessed, it is the same situation for Office 365 E4 which got replaced by Office 365 E5 some time ago. Now you even know the secret why you might have thought that Microsoft can’t count from 1 to 5… makes sense now? And finally you also know why there are packages like Enterprise Mobility & Security E3 and Enterprise Mobilits & Security E5, or Microsoft 365 E3 and Microsoft 365 E5, but no E1, E2, E4 variants at all: It is simply coming from the success of the Office 365 package variants where it all started with. You can’t blame the marketing guys to just continue with what seems familiar to a lot of people already, can you?
Did you already notice that for newer package variants, there is also the letter F involved instead of E? F is for firstline workers, meaning it is a bundle of services with their lowest feature set. What you will see here is that service plans that come with such package variant will often include the term deskless or kiosk (or even just K1) which expresses that the service can only be used in a web browser. Fortunately Microsoft has realized that firstline workers often are not using a desktop PC anymore but are equipped with mobile devices like smartphones or even tablets. Restricting access to a web browser only for these devices is quite inconvenient so access options were now extended to Microsoft’s mobile apps for those kind of package variants. The term kiosk now seems a bit outdated but you might still face it here and there, knowing that it is not just a kiosk desktop computer in the lobby anymore.
If you wonder how Microsoft had come up with all the different packages and what their (potential) history was, I am now sharing some of my own thoughts. If you are doing research on the internet and any of the legacy package names will cross your way, you should be able to put it in better perspective. (This might be the part now where I mainly do glass balling… you have been warned.)
Business Productivity Online Suite (BPOS) - DEPRECATED
There was a predecessor of Office 365: The Business Productivity Online Suite was the very first approach to provide Software-as-a-Service and was based on the 2007 product versions of Exchange Server and SharePoint Server. Looking back to it from today, this was more like a field study to learn about the missing peaces and gather feedback from larger enterprise customers.
Surprisingly, the abbreviation BPOS is still present in a few areas so when it appears to you somewhere, you know where it comes from.
Office 365 (O365)
These are the essential packages you will always consider to purchase in one or more variants, depending on how many different use cases you have. I don’t remember any customer that would actually buy single product licenses for a majority of its user base. Only for some edge use cases, customers would purchase additional single product licenses in order to supplement a small group of users with some distinctive features they require to have.
Enterprise Mobility & Security (EMS)
Actually, this name is a bit misleading as it should also contain something like Identity Management, Governance, or Compliance. An absolutely essential and useful product variant that will help you here comes with this package and is called Azure Active Directory Premium. Indeed, Microsoft should have placed this as part of the Office 365 packages. They did not for a legitimate (selling) reason: You should either purchase the single product license on top of your Office 365 package, or you should start realizing this is almost half of the price of an EMS E3 package already.
Also, both buzzwords Mobility and Security likewise are extremely important nowadays. Users need to be flexible and work mobile almost always. This in turn triggers increased need for security protection, not to mention all regulatory and contractual requirements that have increased so much. In fact those requirements have become so high even smaller organisations have to think what they are doing to get a basic level of data loss prevention against unintentional data leaks, and to ensure data privacy for every user (yes, it is this nasty acronym GDPR I am referring to.).
Enterprise Cloud Suite (ECS) - DEPRECATED
As many enterprise customers were buying both packages Office 365 and Enterprise Mobility & Security already, they have asked a lot about the still missing piece of Windows 10 being an integrated part of Microsoft’s cloud. So in 2015, Microsoft introduced a new package consisting of Office 365 E3 + Enterprise Mobility & Security E3 + Windows 10 Enterprise E3. They named it Enterprise Cloud Suite. Adding the enterprise edition of Windows to this was basically about license optimisation at that time so the benefits were mainly by financials or had improved IT operational aspects.
Secure Productive Enterprise (SPE) - DEPRECATED
With the introduction of an E5 package variant in 2016, Microsoft renamed their Enterprise Cloud Suite into Secure Productive Enterprise (spoiler alert: It didn’t last really long…).
At that time, Microsoft introduced new Advanced Threat Protection features in Windows Defender and as cloud security topics started to become important for a broader enterprise audience, it seemed legit to point out the additional security benefits that you would not get from an EMS package.
It might even have been moderately too early for such package. Increased endpoint protection requirements on mobile clients, because they were no longer secured by network firewalls and stuff, was something that wasn’t on everyones list just yet.
Microsoft 365 (M365)
In 2017, not even one year after Microsoft had renamed their Secure Productive Enterprise package, it got renamed again into Microsoft 365. While all the renaming series seemed pretty annoying, I think this is a fairly good match now – Microsoft 365 is indeed what the name indicates to be: Every service that Microsoft has to offer for enterprise customers (Office 365 Enterprise + Enterprise Mobility & Security + Windows 10 Enterprise) in a single package. To be fair: The package does not contain the basic Windows 10 license, it solely consists of the Enterprise supplementary license to upgrade a PC with an existing Windows 10 Home or Professional license to Windows 10 Enterprise. This is confusing, I know…
It only just starts making sense when you look at the way Microsoft has re-designed their Mobile Device Management solution Intune and the integration into Azure Active Directory: Bring-Your-Own-Device scenarios with lots of self-service play a major role here, and it can go that far that with Windows Autopilot, you can have your hardware partner of choice send a blank notebook PC to your user and it will simply be onboarded to your company environment by a web login of the user during the Out-Of-Box-Experience setup run – no IT department involved at all. The user could even go to a tech store nearby and buy (almost) whatever PC s/he wants. It is assumed that such devices are always equipped with a Windows 10 Home or Professional license already (the product key is stored to the firmware of the device nowadays.). The user would then kind of bring his own Windows Enterprise license as an upgrade onto that device (in fact, the user could perform this on multiple of his devices.). This is efficient because IT is then able to make use of all the advanced enterprise management features that most users would expect by a managed device.
You made it until here to finally learn what a license really is? Awesome, here you go!
To be very precise, a product license is what you get in return when you had purchased a product. Again so smart to say this, I know… The point is, that a product license is now actually connecting the two worlds of marketing and sales on one site, and the technical enablement on the other site. So in marketing speech, a product license might be the same as what we defined as a product variant or package variant above. In technical terms, a product license is bringing the actual service plans into your tenant so that you can assign those to your users. All clear?
As you can see, you should mind the audience you are currently talking to about licenses. You might always talk about the similar thing but with different aspects. If you are a technician talking to your procurement guy, remember understanding the word license in a purchasing context. If you are a procurement person having a little chat to your IT department, remember a license comes with quite some technical details for the implementation and even limitations and own requirements.
The way you purchase a product license is that you actually sign a subscription contract for either 1 or 12 month while for the latter you may choose between a one-time and monthly payment. This is exceptionally attractive for both, Microsoft and customers: There is constant revenue for Microsoft with easy forecasts to be made. As a customer, you get rid of all the complex methods of settlement for your internal IT costs (Okay, almost.), and services will scale very flexible for your business needs. Plus, this allows for fast and continuos improvements of the services (Agreed, it could be faster most of the time, but you get the point.) so you as the customer will only need to make baby steps every other month to adapt; no more huge and costly migration and transformation project every 5 (or 10… 15?) years. The subscription model in fact has so many benefits and is so much different, it is absolutely impossible to do a proper comparison with the classical self-hosted approach of the last decades before. Are you still wondering about the success of Microsoft these days?
Last but not least, sometimes people talk about a User Subscription License (USL). What they are likely referring to is again a product license, but probably a license out of the pool that you have already available in your tentant ready for user assignment. I wouldn’t rely on people being consciously so picky and actually make a difference between a product license that you plan to buy, and a product license that you had purchased already. You better ask twice if the exact circumstance is crucial for you.
Actual representation of a product license in your tenant
Our abstract examples from above seem so well structured, right? It is nice to have the tree structure until all the way down, correct? Yes, easy to understand after explaining it to you.
The disappointment starts when you get back into your Office 365 tenant and look for what you can actually see there: It is a simple list of all the licenses you bought. If you bought multiple variants of the same product, they would just stand next to each other. What happened is that our explanatory structure got flattened to only serve the technical need to enable a service for users. Without all the explanation from above, you would certainly not be able to understand what this all means. Now you know better.
PACKAGE NAME, variant 1
│
└─── SERVICE NAME 1, Plan 1
│ - Feature 1
│ - Feature 2
│ - Feature 3
│
└─── SERVICE NAME 2, Plan 1
│ - Feature 1
│ - Feature 2
│ - Feature 3
│
└─── SERVICE NAME 3, Plan 1
- Feature 1
- Feature 2
- Feature 3
PACKAGE NAME, variant 2
│
└─── SERVICE NAME 1, Plan 2
│ - Feature 1
│ - Feature 2
│ - Feature 3
│
└─── SERVICE NAME 2, Plan 2
│ - Feature 1
│ - Feature 2
│ - Feature 3
│
└─── SERVICE NAME 3, Plan 2
- Feature 1
- Feature 2
- Feature 3
PRODUCT NAME, variant 1
│
└─── PRODUCT/SERVICE NAME, Plan 1
- Feature 1
- Feature 2
- Feature 3
PRODUCT NAME, variant 2
│
└─── PRODUCT/SERVICE NAME, Plan 1
│ - Feature 1
│ - Feature 2
│ - Feature 3
│
└─── PRODUCT/SERVICE NAME, Plan 2
- Feature 1
- Feature 2
- Feature 3
From a technical standpoint, the flattened structure makes a lot of sense. Well, technicians wish they could even get rid of the topmost layer, representing the product license, and just assign service plans directly to their users. That would really be helpful to easily manage user provisioning sometimes but of course, it makes a little sense to stay with what you had essentially bought in the first place.
Eventually, the product license (don’t say plan… right?) is what you need to assign to a user first to control what service plans of that license are enabled for the user. It is a trivial task unless you start using more services than what is included into a certain license, and when you need to optimise your costs. Assigning licenses to groups and working with group memberships instead helps for many cases (see GBL, group-based licensing). Besides the fact that for this feature, you (of course) need to have an Azure AD Premium license, it is not the answer of everything. Also mid-sized and maybe even small organisations have an extended need to properly govern their licenses, e.g. to integrate into corporate Identity Management (IdM) systems and automate the whole lifecycle management of user identities. Making the right use of GBL and transferring it into the right architecture to make the orchestra sound great is not an easy task at all.
Good luck the next time you come into contact with Microsoft online licenses.
]]>One or the other way, some people might have noticed it already: I launched my new personal website a couple of days ago.
Even though I transferred content from my old Tumblr blog here, this new beginning is certainly not just to modernize the look.
Earlier this year there was already some feeling that I wanted to producing more content for the community to document areas from my professional and personal activities in tech and consultancy work I do. Just recently I got some motivation to get back to that “feeling” and bring it to reality.
So what people can expect are a variety of topic categories being part of rather short and even longer posts on an irregular basis, but with the intention to release something now every few weeks. A plan about how to organize and categorize topics is in the process to manifest in my mind so let's see were this ends.
One important thing I want to point out here is that I will continue to write posts in both languages – English and German. While I can't guarantee that I will be motivated to translate each and every post into both languages, I plan to write the original post always based on the primary audience I would like to reach. Because of my work on international projects around the globe, this will likely be English for professional matters. For topics all around home automation, I know that there is quite a big group of people originating from the German speaking community so I might tend to give priority to create the German version first.
I will certainly document a few more aspects I considered to renew and setup this website and blog. If you notice anything special already now and you want me to explain more about it here, leave a comment below and it might become a part of one of the next stories.
So, what do you think – any thoughts about the status quo?
]]>I would like to share my experience on how to transform your pfSense appliance into a layer4 router for sharing all the encrypted traffic we have on port 443 with SSH and OpenVPN traffic.
SSLlabs.com will even give you an A+ for this configuration if you follow it closely.
For SSH, this will not only give you enhanced security and encryption but also a whole lot more flexibility for secure remote access to servers in your corporate network. It will even allow you to bypass a lot of corporate proxy servers (as long as there is no content inspection enabled for HTTPS traffic) and is a real alternative instead of using HTTP CONNECT method (which can easily be blocked). This solution could even be more blown up to fulfill enterprise level requirements, e.g. granular role-based user authentication. However, this will not be our main topic in this article but will be referenced from time to time. I know there is this shiny litte tool SSLH out there but this solution is much more flexible due to the power of HAproxy.
All in all, this is what we are going to share via port 443 on a single IP:
I am using pfSense to ease HAproxy configuration as it makes things a lot more comfortable. For your reference you may find a haproxy.cfg file here which has been created by pfSense 2.2.6. [[MORE]]
We are going to need 2 separate CA’s which we will be creating in the Cert Manager right now. I recommend using the following settings:
Descriptive name: Acmi VPN Remote Access
Method: Create an internal Certificate Authority
Key Length: 4096
Digest Algorithm: SHA512
Lifetime: 3650
Country code: US
State: NY
City: New York
Organisation: Acme Inc.
Email address: security@example.com
Common Name: Acmi VPN Remote Access
Descriptive name: Acmi SSLH Gateway
Method: Create an internal Certificate Authority
Key Length: 4096
Digest Algorithm: SHA512
Lifetime: 3650
Country code: US
State: NY
City: New York
Organisation: Acme Inc.
Email address: security@example.com
Common Name: Acmi SSLH Gateway
Let’s create a quick internal certificate for the OpenVPN server before we will set it up:
Method: Create an internal Certificate
Descriptive name: vpn.example.com
Certificate authority: Acmi VPN Remote Access
Key Length: 4096
Digest Algorithm: SHA512
Certificate Type: Server Certificate
Lifetime: 3650
Country code: US
State: NY
City: New York
Organisation: Acme Inc.
Email address: security@example.com
Common Name: vpn.example.com
Alternative Names: TYPE=DNS, VALUE=vpn.example.com
Let’s also create a quick internal certificate for our SSLH Gateway:
Method: Create an internal Certificate
Descriptive name: ssh.example.com
Certificate authority: Acmi SSLH Gateway
Key Length: 4096
Digest Algorithm: SHA512
Certificate Type: Server Certificate
Lifetime: 3650
Country code: US
State: NY
City: New York
Organisation: Acme Inc.
Email address: security@example.com
Common Name: ssh.example.com
Alternative Names: TYPE=DNS, VALUE=ssh.example.com
Each user who needs to be authorized using OpenVPN, HTTPS-auth secured backends or our SSLH gateway will need to have user certificates being created by our internal CA’s.
For OpenVPN and HTTP-auth users, we will create just one single certificate. We will just use the pfSense internal users for this example, you may extend this to more complex setups on your own.
Open the User Manager, click on edit for your user account and then the plus icon next to the User Certificates section (this will automatically assign the created cert to this user account for your convenience).
Let’s create the OpenVPN and *.vpn.example.com cert first:
Method: Create an internal Certificate
Descriptive Name: Acmi John Doe
Certificate authority: Acmi VPN Remote Access
Key length: 4096
Digest Algorithm: SHA512
Certificate Type: User Certificate
Lifetime: 3650
Country code: US
State: NY
City: New York
Organisation: Acme Inc.
Email address: john.doe@example.com
Common Name: Acmi John Doe
Alternative Names:
TYPE=email, VALUE=john.doe@example.com
TYPE=email, VALUE=netmaster@example.com
You may add other (pseudo/administrative) e-mail addresses here as an alias so you may even restrict access to certain pages/backends, e.g. allow access to the firewall on fw.vpn.example.com only for members of the netmaster staff (meaning this user needs to have netmaster@example.com as an alternative name). This will be kind of role-based authentication if you extend the ACL in the corresponding shared frontend we will be creating for each of the servers later. However, I don’t want this to become too complex here so this is just some inspiration for more advanced enterprise use you may follow up on later.
Let’s now create the SSLH cert:
Method: Create an internal Certificate
Descriptive Name: Acmi-SSLH John Doe
Certificate authority: Acmi SSLH Gateway
Key length: 4096
Digest Algorithm: SHA512
Certificate Type: User Certificate
Lifetime: 3650
Country code: US
State: NY
City: New York
Organisation: Acme Inc.
Email address: john.doe@example.com
Common Name: Acmi-SSLH John Doe
Alternative Names:
TYPE=email, VALUE=john.doe@example.com
TYPE=email, VALUE=hostmaster@example.com
Same info about the alternative names I mentioned above applies here.
Create a normal new OpenVPN instance listening on TCP port 1194 (it may use the WAN interface just as normal) using the CA “Acmi VPN Remote Access” and it’s certificate “vpn.example.com” we created above. I will not go any deeper into this as there are much other (and more sophisticated) how-to’s out there in the net.
We will start with a dummy backend and the second level frontends for HTTPS, HTTPS-auth and SSLH and combine them in a first level frontend instance afterwards.
In the general settings tab, you want to add this to the Global Advanced Pass Through field:
# Modern browser compatibility only as mentioned here:
# https://wiki.mozilla.org/Security/Server_Side_TLS
ssl-default-bind-ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK_
_tune.ssl.default-dh-param 2048_
# Time-to-first-Byte (TTFB) value needs to be optimized based on
# the actual public certificate chain see
# https://www.igvita.com/2013/10/24
# /optimizing-tls-record-size-and-buffering-latency/
tune.ssl.maxrecord 1370
Being in the backend section of the HAproxy configuration gui, create a new instance called “none”. We will use this backend later as our default destination as it’s actually doing nothing but being a placeholder for everything that does not match elsewhere.
Use the following settings:
Mode: disabled
Name: none
Forwardto: address+port
Address: 127.0.0.1
Port: 80 (or any other port which does **not** listen on localhost)
Health check method: none
Click on “save”.
For convenience reasons you would normally want to setup a redirect from port 80 to 443.
First, create a backend:
Mode: inactive
Name: ssl-redirect
Forwardto: address+port
Address: 127.0.0.1
Port: 8081 (or any other port which does not listen on localhost)
Backend pass through: redirect scheme https code 301
Health check method: none
Second, create the corresponding primary frontend:
Name: WAN_HTTP
Description: Redirect HTTP traffic to HTTPS
Listen address: WAN address (IPv4)
Port: 80
SSL Offloading: no
Backend server pool: ssl-redirect
Type: HTTP / HTTPS(offloading)
That was easy.
Switch to the frontend section and create a new instance using the following settings:
Name: WAN_HTTPS
Description: HTTPS Reverse Proxy
External address: localhost (IPv4)
Port: 2043
SSL Offloading: yes
Advanced: accept-proxy npn http/1.1
Backend Server Pool: none (or use any other webserver backend, e.g. to show custom error pages instead of 503)
Type: HTTP / HTTPS(offloading)
Client timeout: 7200000
Use ‘forwardfor’ option: yes
Advanced pass through:
# Remove headers that expose security-sensitive information.
rspidel ^Server:.*$
rspidel ^X-Powered-By:.*$
rspidel ^X-AspNet-Version:.*$
# add some security related headers
rspadd Content-Security-Policy: default-src https: data: 'unsafe-inline' 'unsafe-eval'
rspadd X-Frame-Options: SAMEORIGIN
rspadd X-Content-Type-Options: nosniff
rspadd X-Xss-Protection: 1; mode=block
Certificate: Ideally choose a wildcard cert you uploaded to the Cert Manager before, e.g. from StartCom/StartSSL. We are choosing “*.example.com” here. Put additional certificates as required.
Add ACL for certificate CommonName: No
Advanced SSL options: no-sslv3
Click on “save”.
Back in the frontend overview, you may just clone the instance we just created by using the plus icon right next to that line. I will only describe what needs to be changed here:
Name: WAN_HTTPS_auth
Description: *.vpn.example.com (HTTPS Reverse Proxy with X.509 Auth)
Port: 2044
Certificate: *.vpn.example.com (this needs to be an official wildcard certificate!)
Client verification CA certificates: Acmi VPN Remote Access (which we created before)
Note: You cannot link any CRL here at the beginning because even though you would have created it using the Cert Manager it’d be still empty at the beginning which HAproxy does not like. Add it here as soon as you actually have revoked any certificate.
Now we create the third 2nd level frontend which will do SSH routing for us.
Name: WAN_SSLH
Description: *.ssh.example.com (SSL-secured SSH gateway with X.509 authentication)
External address: localhost (IPv4)
Port: 2022
SSL Offloading: yes
Advanced: accept-proxy npn ssh/2.0
Backend Server Pool: none
Type: SSL / HTTPS(TCP mode)
Client timeout: 7200000
Certificate: ssh.example.com (as created before)
Add ACL for certificate CommonName: No
Advanced ssl options: no-sslv3
Client verification CA certificates: Acmi SSLH Gateway
Now that you’ve come that far you cannot use any services yet due to the localhost listening we used before. We will change this here.
First, we need to create special backend services for each of the 2nd layer frontends so we can loop back to them from our 1st level frontend instance.
Mode: active
Name: OpenVPN
Forwardto: address+port
Address: 192.168.178.2 (basically your WAN IP running the OpenVPN instance)
Port: 1194
SSL: No
Health check method: none
Connect timeout: 3000
Server timeout: 7200000
Retries: 2
Mode: active
Name: WAN_HTTPS
Forwardto: address+port
Address: 127.0.0.1
Port: 2043 (the port we used before for this frontend instance)
SSL: yes
Per server pass thru: send-proxy
Health check method: none
Server timeout: 7200000
Mode: active
Name: WAN_HTTPS_auth
Forwardto: address+port
Address: 127.0.0.1
Port: 2044 (the port we used before for this frontend instance)
SSL: yes
Per server pass thru: send-proxy
Health check method: none
Server timeout: 7200000
Mode: active
Name: WAN_SSLH
Forwardto: address+port
Address: 127.0.0.1
Port: 2022 (the port we used before for this frontend instance)
SSL: yes
Per server pass thru: send-proxy
Health check method: none
Server timeout: 7200000
After this, let’s finally create the main frontend instance:
Name: WAN_443
Description: Sharing port 443
Shared Frontend: No
External address: WAN address (IPv4)
Port: 443
SSL Offloading: No
Backend Server Pool: none
Type: TCP
Client timeout: 7200000
Advanced pass thru:
tcp-request inspect-delay 5s
tcp-request content accept if { req.ssl_hello_type 1 } or !{ req.ssl_hello_type 1 }
To route to the correct frontend, we will create a “shared frontend” for each of our 2nd level frontent (pfSense names it like this, actually this is simply additional configuration to the assigned primary frontend). So let’s create 4 shared frontends:
Name: WAN_443_OpenVPN
Description: OpenVPN
Shared Frontend: Yes
Primary Frontend: WAN_443
Backend Server Pool: OpenVPN
Access Control lists:
NAME=acl EXPR=Custom NOT=yes VALUE=req.len 0
NAME=acl EXPR=Custom NOT=yes VALUE=req.ssl_hello_type 1
Name: WAN_443_HTTPS
Description: HTTPS
Shared Frontend: Yes
Primary Frontend: WAN_443
Backend Server Pool: WAN_HTTPS
Access Control lists:
NAME=acl EXPR=Custom NOT=no VALUE=req.ssl_hello_type 1
NAME=acl EXPR=Custom NOT=yes VALUE=req.ssl_sni -m end -i .vpn.example.com
NAME=acl EXPR=Custom NOT=yes VALUE=req.ssl_sni -m end -i .ssh.example.com
Name: WAN_443_HTTP_auth
Description: *.vpn.example.com
Shared Frontend: Yes
Primary Frontend: WAN_443
Backend Server Pool: WAN_HTTPS_auth
Access Control lists:
NAME=acl EXPR=Custom NOT=no VALUE=req.ssl_hello_type 1
NAME=acl EXPR=Custom NOT=no VALUE=req.ssl_sni -m end -i .vpn.example.com
Name: WAN_443_SSLH
Description: *.ssh.example.com
Shared Frontend: Yes
Primary Frontend: WAN_443
Backend Server Pool: WAN_SSLH
Access Control lists:
NAME=acl EXPR=Custom NOT=no VALUE=req.ssl_hello_type 1
NAME=acl EXPR=Custom NOT=no VALUE=req.ssl_sni -m end -i .ssh.example.com
So much for the basic setup! But there is actually no server or web service available right now (beside OpenVPN which should be working right away now). This is what we are going to setup now. But oh wait, of course we obviously miss some DNS stuff so let’s shortly create these canonical name records in your DNS:
_ssh.example.com. IN A <your-WAN-IP-address>
vpn.example.com. IN A <your-WAN-IP-address>
*.vpn.example.com. IN A <your-WAN-IP-address>
Should you be using a dynamic IP address for your WAN device you may also use CNAME records to your DynDNS provider’s name.
Okay, let’s finally start with the examples on how to make internal services available through your ultimate HAproxy setup now.
Normal SSL offloading functionality is available creating shared frontends for each backend service an assign WAN_HTTPS as it’s primary frontend. You may just use the standard pre-defined expression for matching hostnames so route to specific backend web servers based on their URL (first create the backend, then create the secondary frontend). Put any server certificates in here as required.
You may also want to enable Strict-Transport-Security and Cookie protection here.
A lot of so called SSL-VPN appliances (e.g. Juniper) allow to granularly give access to internal websites without needing any VPN client software. In fact this is nothing else than some sophisticated reverse proxy and we can have pretty much same functionality (on top of the OpenVPN dial-in for more complex remote access requirements) using HAproxy and authentication via X509 user certificates.
The setup is exactly like with the public website described above, only difference is to assign WAN_HTTPS_auth as it’s primary backend.
For better convenience of this service we are using this wildcard certificate *.vpn.example.com together with wildcard DNS record so we can easily add additional backends without changing DNS or adding certs every time (of course this is still an option should you need a different URL, just takes more effort to set up).
Remember to import the user’s certificate and the public cert of your CA into his browser.
This is the one most of you will be interested in I guess so we’re finally here :-)
Obviously you need to create a new backend first:
Name: ssh_server
Mode: active
Forwardto: Address+Port
Address: <internal IP or DNS name>
Port: 22
SSL: no
Health check: none
Connection timeout: 3000
Server timeout: 7200000
Retries: 2
After it, let’s create the corresponding shared frontend:
Name: WAN_SSLH_server
Description: server.ssh.example.com
Shared Frontend: yes
Primary Frontend: WAN_SSLH
Backend server pool: ssh_server
Access Control lists:
NAME=acl EXPR=Custom VALUE=ssl_fc_npn -i ssh/2.0
NAME=acl EXPR=Custom VALUE=ssl_fc_sni_reg server.ssh.example.com
That’s it!
Optionally, you may add SSHFP records to your DNS based on server.ssh.example.com.
So, how you gonna access this server from external now? Basically it’s about using the ProxyCommand of your SSH client together with OpenSSL’s s_client command. This is pretty much forward for any Mac or Linux machine. For Windows dudes this article might be helpful but I will stay describing my Mac setup here.
Add these lines just once to your ~/.ssh/config
file:
Host *.ssh.example.com
ProxyCommand /usr/local/opt/openssl/bin/openssl s_client -verify 1 -verify_return_error -nextprotoneg ssh/2.0 -brief -quiet -servername %h -connect ssh.example.com:443 -CAfile ~/.ssh/sslh-ca.crt -cert ~/.ssh/sslh.crt -key ~/.ssh/sslh.key
If you’re like me, you also want a shortcut for your most used servers so you don’t need to enter the FQDN and user each time. This is still possible:
Host server
Hostname server.ssh.example.com
User root
The ProxyCommand assumes you stored your CA public cert, your personal public cert and private key to ~/.ssh
to handle the X509 authentication which allows you to actually make use of the SSLH gateway (or even access to a specific server behind it as mentioned earlier).
Also note I am not using the openssl installation that comes with OS X but installed a newer version using Homebrew because it gives you some more information and better encryption support. I’m also using Homebrew’s OpenSSH for better SSHFP support, see this page.
Now you can simply SSH into server.ssh.example.com
(or just server
). Your connection will have strong SSL encryption which you can see directly from the connection output (it’s probably better than most single SSH connections as ECDSA often is not available due to outdated SSH server packages even on fairly new servers). Secondly you are using kind of 2-factor-authentication (first X509 cert + username + password or SSH key) to actually login which makes this a really secure way to access any server in your internal network from the outer world.