WS2016 AD upgrade problem: TLS ciphers

We’ve been replacing all our WS2012R2 DCs with WS2016 DCs. A non-Windows platform application which performs LDAPS queries against AD had a breaking issue. That application leverages a JDK library to establish the TLS connection (for LDAPS) with a domain controller.

See https://docs.microsoft.com/en-us/windows-server/security/tls/tls-schannel-ssp-changes-in-windows-10-and-windows-server for Microsoft details on the newly added crypto ciphers. An interesting detail is that the preferred crypto cipher for WS2016 is still in draft status! Presumably it was chosen because it is significantly faster than the other new/strong ciphers.

The exact details of the known problem are still a bit sketchy, so I can’t share that level of detail definitively. The facts are that both WS2016 server and JDK client have ciphers in common, but a mutually supported cipher is not negotiated (whereas a WS2012R2 server with the same JDK client does negotiate successfully). The JDK team has an issue tracking this which they have resolved based on wire-level examination showing that the WS2016 server doesn’t properly do TLS cipher negotiation: https://bugs.openjdk.java.net/browse/JDK-8178429.

So we looked to find a solution. We are aware that the ‘bouncy castle’ provider (instead of JDK) has been used in similar situations. Our working hypothesis was that WS2016 is just overzealous in negotiation when the newer ciphers are enabled or suggested first.

Our testing showed that switching the order so that the cipher still in draft status is not first was enough to allow the JDK based client to negotiate, which seems to support that hypothesis.

We rolled an order switch out, and plan to keep that in place for 6 months when the dependent application will be retired.

Some related links:

Office ProPlus Device Based Activation

Microsoft has a special capability called Office ProPlus Device Based Activation, which is only offered to Office 365 for Education customers. It allows the click to run Office to be licensed on a device basis instead of on a user basis.

http://boards.microsoft.com/public/prism/80710?token=f55452094b has more info, including a video, brief guide (which is not a guide, but just a step-by-step to implementation), and a FAQ partly hidden a layer below.

This capability has a lot of upside, and I appreciate the solution. There are several aspects of the design that are under-documented and which deserve thought:

  • Most of the issues center on the “device users” which are created and leveraged to enable this capability. Undocumented by Microsoft, the Azure AD object type/class these “device users” are is simply just Azure AD users with _Device_ as a prefix.
  • How do these objects go away? This topic is not covered, and I presume that you must invent your own mechanism to remove them when unnecessary. How you’d effectively do that is pretty unclear.
  • Another issue is where the Office ProPlus licenses which get applied to these users come from.

I’ve got a longer analysis paper over at https://itconnect.uw.edu/wares/msinf/comm/analysis/office-proplus-device-based-activation-analysis/ which discusses the topic and our proposal to implement.

Azure AD Role Activation

I’ve been trying to start using one of the many directory roles which Microsoft has defined for Azure AD. See https://docs.microsoft.com/en-us/azure/active-directory/active-directory-assign-admin-roles for the primary documentation on Azure AD roles.

If you’ve looked at Azure AD directory roles, you know that there are some roles which are immediately usable and others for which you have to do something to “turn them on.” I got stuck at the point of turning one on, and I figured an information post about this would be useful to others.

Behind the scenes there are two AAD objects in play. There is the DirectoryRole—which are all the roles that are usable in your tenant. And then there is the DirectoryRoleTemplate—which are all the roles which might be usable in your tenant. You “activate” a template to create a role object, which is effectively “turning it on”. I wrote a detailed blog post about this several months ago at: https://blogs.uw.edu/barkills/2017/02/28/azure-ad-roles/ if you want to learn more, but for the purposes of this post, you don’t need to know what’s in that other post.

From what I’ve been able to determine, there are three ways to turn these things on (listed in order I think they were available):

  1. MSOnline PowerShell module, via Add-MsolRoleMember, https://docs.microsoft.com/en-us/powershell/module/msonline/Add-MsolRoleMember?view=azureadps-1.0
  2. Azure AD Graph API, via REST call documented at https://msdn.microsoft.com/en-us/library/azure/ad/graph/api/directoryroles-operations#ActivateDirectoryRole
  3. AzureAD PowerShell module, via Enable-AzureADDirectoryRole cmdlet, documented https://docs.microsoft.com/en-us/powershell/module/azuread/enable-azureaddirectoryrole?view=azureadps-2.0.

I also suspect that there may be ways to silently activate a role via one of the GUI admin consoles, but I have not extensively explored this.

Speaking of silent activation, I think that’s what option #1 does—you don’t have to know anything about DirectoryRoles, DirectoryTemplates, or even be aware there is an activation. But since that module is “old”, I’ve been purposely avoiding it, and I have to believe that’s what at least some others are doing.

Option #2 is likely not an option that many try. But I happen to like the Azure AD Graph Explorer because I find I can get more low-level details from it than any other AAD tool, so this is an option I tried. However, the documentation referenced is pretty opaque to me, with a recommended call that didn’t even include the required parameter—which I have to guess is because the documentation is incomplete. I couldn’t find a way to make it work, even by adding in the required parameter and the objectId of the DirectoryRoleTemplate I wanted to activate. I’m left wondering what the right incantation is to get this option to work.

Option #3 is where I started because I’ve come to like the AzureAD module. And I followed the example in the documentation ending up with the error message:

Enable-AzureADDirectoryRole : A parameter cannot be found that matches parameter name 'DirectoryRole'.

This drove me batty for a while, especially since it is a required parameter.

Eventually, I realized that the example listed is for a prior version of the AzureAD module, and they made major changes to the parameters. This issue was masked by two things:

  • the example in the documentation is completely incorrect for the current version—it must be based on a prior version
  • the help for this cmdlet is also incorrect, and not just the example but all of the help is incorrect

Making major changes to the parameters, especially when you drop the only required parameter, and not updating the documentation is bad, and that’s what seems to have happened here.

The good news is that the steps required, which used to include instantiating a special object to pass into the cmdlet, are much less complicated. From a high-level, you grab the objectId of the DirectoryRoleTemplate you want to activate, then pass that into the cmdlet as a string. So the example *should* read this:

$InviterRole = Get-AzureADDirectoryRoleTemplate | Where-Object {$_.DisplayName -eq "Guest Inviter"}

$InviterRole

 

ObjectId                             DisplayName   Description

--------                             -----------   -----------

95e79109-95c0-4d8e-aee3-d01accf2d47b Guest Inviter Guest Inviter has access to invite guest users.

 

Enable-AzureADDirectoryRole -RoleTemplateId $InviterRole.ObjectId

 

ObjectId                             DisplayName   Description

--------                             -----------   -----------

03618579-3c16-4765-9539-86d9163ee3d9 Guest Inviter Guest Inviter has access to invite guest users.

I hope this helps save someone else time. And I hope Microsoft takes note of the mess here and the places they might improve the documentation to help others in the future.

Azure AD Roles

I’ve been exploring AAD roles, but there’s a lot left unexplained by Microsoft. This is a bit of discovery, via stream of consciousness which hopefully will be helpful to others.

The general task I’m looking at is finding out all possible AAD roles and the membership of each. This task is not as straightforward as it seems. For one, the various interfaces to AAD don’t agree on what the AAD roles are. None of the GUI interfaces give you a way to discover who is in a role. When I run into ‘can’t do that with the GUI’, I generally turn to Graph because then I get full details. Yes, there are ways to approach this with PowerShell, but I note that it also doesn’t list a couple of the possible roles.

Via Graph, there are role template objects and role objects. You can find out the members of a given role by querying graph (https://msdn.microsoft.com/en-us/Library/Azure/Ad/Graph/api/directoryroles-operations). However, I note that in Graph, there is not alignment between the role objects and the superset of roles listed in the GUI interfaces (nor with a list presented to MVPs as ‘recently released’). The missing role objects are present as role template objects (and even the list of “roles coming soon” are present as role template objects).

This left me wondering … how do those role objects get created? Is my tenant out of expected state because some Microsoft task failed or hasn’t reached my tenant yet? Or is there a ‘just in time’ provisioning of role objects when the first user is assigned to them? Or is there some step a tenant is expected to do to activate a role?

Aha. I partially see now. Graph documentation says that I have to activate directory roles from newly added templates. https://msdn.microsoft.com/en-us/Library/Azure/Ad/Graph/api/directoryroles-operations#ActivateDirectoryRole

However, the general documentation about roles https://docs.microsoft.com/en-us/azure/active-directory/active-directory-assign-admin-roles doesn’t mention this, whereas the developer documentation for Graph does … this makes me wonder if it might be both of the possibilities I mentioned. In other words, if you are using graph to do role assignment you must manually activate roles, but if you are using the GUI interfaces or PowerShell cmdlets, it silently does that for you via a just-in-time creation of the role object. Is that accurate?

I also wonder what controls which roles are present in each of the various interface’s experience—heck, let’s get really specific and talk specifically about the new Azure portal. Why does the new Azure portal not list every possible role in my tenant?

I wonder about these role templates which are present in my tenant Microsoft told MVPs aren’t yet released. What happens if I activate one of them now? If there is a downside to doing that, how is a tenant admin expected to know that a given role template isn’t ready?

I got around to testing the AzureAD PS module. When you combine the two cmdlets it provides, it returns more roles than the MSOnline module. Its approach follows the AAD Graph object types.

The MSOnline PS module seems to return roles which are both a role object and a role template object, minus a couple. 🙁

The AzureAD PS module cmdlets returns the AAD objects they are named for. So get-azureAdDirectoryRole returns only roles which are a role object, and get-azureAdDirectoryRoleTemplate returns role template objects.

The output of get-azureAdDirectoryRoleTemplate does not match the output of the MSOnline get-msolrole. The difference is that get-azureAdDirectoryRoleTemplate has a couple additional roles:

  • Mailbox Administrator
  • User
  • Email Verified User Creator
  • Adhoc License Administrator

This gives me greater confidence in the AzureAD PS module than the MSOnline PS module.

Lacking verification from Microsoft, I think my hypothesis that some of the tools do just-in-time activation of role templates (i.e. create a role object based on the template) and some require you to do that yourself seems to fit what I can see. I’m still left wondering what happens if you activate a role template that Microsoft has added to your tenant but not said was “released”.

 

Gaps I see that Microsoft might want to address:

  • *Should* document that some roles can only be provisioned via some tools
  • *Should* be more accessible listing of all the possible roles—the fact that you have to use either Graph or a non-GA PS module to get that info comprehensively is not a good state of affairs
  • Might want to talk more about role activation in IT Pro documentation
  • Depending on whether some role templates that are deployed are dangerous or not, there should be some definitive list of released roles, or an attribute on the role template that says whether it is usable, or even something at the Graph layer that blocks certain templates from being activated until they are ready. I haven’t dived very deep on this topic, so there is some ambiguity on this that I might explore further by trying to activate some of those roles that aren’t yet “released”.
  • Deeper documentation on role assignments.
  • What objects can be assigned? I see users and servicePrincipals, and I think I heard that groups can be assigned. What else? Put it in the documentation.
  • Sub-delegation of roles. When a servicePrincipal is a role holder there is some ambiguity about who has the permissions associated with that role. For example, the ‘Office 365 Service Trust Portal’ is a “Directory Writer’ in any tenant with O365 in it. I presume that some of the roles defined by that AAD application  sub-delegate some portions of the ‘Directory Writer’ role out. The point here is calling attention to the fact that when a servicePrincipal has a role, you are extending some trust to users of that AAD app. Documentation should call this out.

Note: A specific example that I’m worried about is the ‘Microsoft Power BI Information Service’ servicePrincipal having been added as a Global Admin (I presume by Microsoft). That seems like an extreme amount of permissions and assuming Microsoft added it is a bit of a violation of Azure first principles (you own your own tenant). I haven’t dug into that one via the Audit API to find out who/when it was added, but it is on my list to investigate further.