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 ( 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.

However, the general documentation about 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.


Preferred Name, Shared UW NetIDs, UWWI, and Exchange

You may be familiar with the friction we’ve experienced over the years around displayName. Here are a couple past posts I’ve written on this:


I’m writing to make sure you are aware of a new behavior that was introduced likely at or after the PersonReg 3.0 release (now called IdentityReg). The effect of this new behavior is that the benefits to UWWI of the imagined “preferred name” work for Shared UW NetIDs are, for the most part, here today.


Prior to this, if you wanted to change the name value on a UWWI user that was a Shared UW NetID, you called the UW-IT Service Center and asked them to change the AVF displayName value. It wasn’t ideal, but it worked. That still works (except in some cases—more on that in a second), but there’s a better scenario now.


From the UW NetID Manage tool, if you set the Name value (see “Basic Settings”) for a Shared UW NetID, it now results in the PDS displayName value being set to that value (overriding any AVF displayName value). This then results in the UWWI FIM system using that value and propagation to UWWI. Keep in mind that account owners or admins can use the Manage tool on their Shared UW NetIDs by logging in with their personal UW NetID, so they don’t even need to have the Shared UW NetID password handy.


So in summary, self-service UWWI user name changes have been attained for Shared UW NetIDs. Getting to this milestone for Personal UW NetIDs still remains outstanding.

Hiding Data in Active Directory

I have a bit of a reputation as an expert on hiding data in Active Directory. So I often get questions about how to hide X, where X changes a bit depending on the scenario. Lately I’ve gotten a flurry of such questions, and it’s become obvious to me that I should blog about this.

The key to all of these questions is understanding a few key Active Directory concepts. After you understand these few things, you can quickly find a solution for whatever your X is.

Outside of understanding how to achieve your goal, you also need to understand the implications or consequences. Sometimes those consequences are enough that you may decide not to implement.

This post is divided into 3 sections:

  1. Explaining background concepts needed to craft a solution
  2. Describing potential consequences
  3. Describing some real-world examples & the specific solutions

Background AD Security concepts

There are three methods or approaches to hiding things in AD.

Let’s agree to throw out one out of consideration straight out of the gate. AD supports marking an attribute as confidential (see But it doesn’t only allows this to happen on attributes which are part of the base schema. So this solution is only valid for custom attributes you’ve added, and in my experience, no one really cares about hiding their custom attributes—it’s the base ones they are interested in.

The other two involve getting a lot more familiar with AD security descriptors. As background, you have to must know where every AD object gets the ACEs it has. There are three sources:

a) inherited ACEs from objects “above” it
b) explicit ACEs that have been added to that object
c) explicit ACEs that are set upon object creation from the default security descriptor defined by the object’s schema

You are in control of all three of these sources.

To my knowledge, Stanford is the only AD implementation which has changed c). Incidentally, if you have an AD implementation that has done this I’d love to hear about it. Stanford removed the default security descriptor from the user objectclass. They’ve set some inherited ACEs, and their provisioning then adds any explicit ACEs that they desire. With the exception of domain admin accounts, they don’t hide users.

I’d encourage you to take a close look at the default security descriptor on the user objectclass. You’ll see that a group called “Pre-Windows 2000 Compatible Access” is granted Read access. This ACE and the membership of this group is therefore critical to whether or not someone can see a given user. You’ll find this is also true for computers and groups.

Another point of background. You need to understand the order of permission processing for AD. This is:

  1. Explicit Deny ‘Owner Rights’
  2. Implicit Allow Owner (change permissions + change ownership)
  3. Explicit Deny
  4. Explicit Allow
  5. Inherited Deny
  6. Inherited Allow

Note that an explicit allow overrides an inherited deny. This means that if you want to either hide an AD object or hide attributes on an AD object, you must get into the business of managing explicit ACEs–there is no easy solution of setting a single inherited ACE that will achieve your aim.

Once you understand this background, the rest is usually just implementation details. Most solutions involve:

a) either remove the troublesome explicit allow ACEs or empty the membership of the groups referenced
b) add an inherited deny ACE

Working within this framework is the usual approach most AD implementations take when they need to hide information in AD,and it’s what I’ll focus on in the other sections. I should probably also mention that back in 2005/2006 timeframe I opened a very lengthy PSS engagement to validate that there were no APIs that didn’t respect the AD ACLs.

But there is one other approach (the third I mentioned earlier). That’s to turn on the “List Object” permission in AD (see on how to do this). I am not as familiar with how you’d use this approach, and whether it reduces the consequences. The “List Object” permission is not on by default, and information from Microsoft indicates this is because they thought there might be performance impacts to using it at larger scales (see for that warning). More can said about List Object mode and using this approach, but in general I don’t know about many ADs that have used it, and have no direct experience to share. If you do have experience to share, let me know and I’ll share it here. 🙂

Potential Consequences

If you start to make changes to your AD ACLs, there are some consequences which you may not have anticipated.

For example, if you hide an object such as I mentioned Stanford does with its domain admin accounts, except for the AD itself, nothing can find that object. This means that others can *not* grant that account permissions to almost anything–about the only exceptions are granting access to AD objects or membership in AD based groups. This is because as soon as the object is hidden, the “behind the scenes” username -> objectSID operation that is required for almost all Windows access control changes fails.

The University of Washington (and many other universities) hide the member attribute on some groups, and the memberOf attribute on all users. You can see what we specifically did to achieve this documented at: I should probably mention that we have a C# code sample (and PowerShell–which is using the same stuff) of what’s there. There are a bunch of consequences that we have to live with, and find workarounds for.

The key issue for any scenario where you hide something in AD is that applications that integrate with AD may expect that they have read access to whatever you’ve hidden.

In our case, since we’ve hidden memberOf across all users and member on some groups, we sometimes run into applications that have problems doing access control. But there are obviously options you can implement to address it. For example for our scenario, assuming you do due diligence in evaluating whether that application “leaks” PII or only uses that group membership information for access decisions, you can grant the user account running that application the permissions to read the AD groups with private membership (and/or the user objects memberOf and tokenGroupsGlobalAndUniversal attributes).

But you’ll need a process to evaluate and approve granting that access. And the process will need to somehow take into account {getting permission/letting know} the owners of the membership private groups that application X can read their info.

More recently, we’ve been struggling with the tokenGroupsGlobalAndUniversal attribute (and its partner the Windows Authorization Access Group) since Microsoft seems to be leveraging it with greater frequency in its products, but not doing a very good job documenting this dependency in product documentation. Exchange 2007+, Sharepoint 2007+ (Search security trimming), SCOM (reporting services), and maybe SCVMM all make some use of this mechanism. In some cases, for certain user attributes, you can just add an ACE granting access to whatever the special application or need is. For example, for Likewise (a unix/mac AD integration solution) we opened up the userAccountControl attribute to all computer objects. Nothing really earth shattering about that, but you do have to be willing to do a little extra work to find out what these applications need. And that may introduce unexpected friction between your AD team and project teams. And it often doesn’t help to be proactive–many times I’ve been in the situation where I was explaining to highly-paid consultants that when I previously asked them if this new application they were deploying needed read access, I was referring to the critical problem their application was now experiencing. This gets back to lack of deep understanding of how a given application makes authorization decisions.

Unfortunately, when you do want to authorize an application, there aren’t many good fine-grain solutions within AD for making that happen. For example, we end up granting an application account permissions to read all user accounts, even if that application only has a user population that is a small fraction of all of our users. We hope that Microsoft will eventually extend its Dynamic Access control capabilities to Active Directory resources to help solve this problem of granularity of access control, but that hasn’t happened yet.

In terms of hiding entire objects, I generally try to discourage others from doing it. There are alternatives. For example, while I was at Stanford, Chelsea Clinton was a student. She had a user account, but the name associated with it was not her actual name. So obfuscation. We do something similar here at the UW. A key thing to keep in mind is that you generally aren’t obligated to hide an entire object—it’s generally the case that what is considered sensitive data is a combination of attribute values in conjunction with each other. For example, in our case it’s the ability to tie a course name with a person. If there is no public way to determine that a given person has a given user account, then we wouldn’t need to hide the course group membership at all.

Real World Examples

I’ve already mentioned the UW solution. But I didn’t really explain much of the business reason behind it. So let me backtrack a bit. The US government has this law called FERPA. It allows students to control who has access to their student records. Whether a given student is taking a course or not is considered part of their student record. So group membership in a group that represent a specific course are FERPA protected information. We are obligated to limit access to business functions. Beyond this, we believe that other group memberships are confidential in nature. The nice thing about hiding the membership of groups is that they can still be referenced in ACLs and many Windows security processes work just fine without any need to directly read the membership of the relevant group or user objects. I’ve already mentioned the consequences we deal with, and there are applications that we do need to help to enable.

I’m aware of several universities in Canada which have interpreted FIPPA legislation (which is similar to FERPA) to mean that they must hide user objects. I advised against this, but I believe some of them proceeded. I haven’t heard how that worked out for them, but I’ll update this if I do.

I’ve heard from someone wanting to hide the mail attribute on a specific user. Here’s what I told them:

The mail attribute is part of the property set called “Public-Information”. An explicit ‘allow Authenticated Users: Public-Information’ is granted by default as part of the defaultSecurityDescriptor from the schema definition of the user object class. If you want to hide mail, in addition to emptying the ‘pre-windows 2000 compatible access’ group (or just removing the explicit ACE on that one user object), you’ll also need to remove the explicit Public-Information allow ACE from the relevant user object. But Public-Information includes a whole slew of attributes that frankly are really important to have read access to. So you’ll then need to re-add explicit allow ACEs to each of the attributes in that property set except for mail. That’s like 63 ACEs or so (I’m a bit behind on AD schema analysis, so that number is only good circa 2010 schema). And you’ll need to watch all future Microsoft schema changes to find new attributes they add to Public-Information and manually add those too. Doable, but yucky.

Wrap Up

So as you can see, you can hide information in AD. There is a cost to doing so that you will continue to pay beyond implementation. You’ll need to make a decision whether the value you get is worth that cost.

Some presentations I’ve given about this topic:


2012 and 2013 UW Holidays for Outlook

In the past I’ve provided a custom OUTLOOK.HOL file to add the UW Holidays to Outlook.

You can read for the first post where I mentioned this mechanism.
I’ve just updated the Outlook.hol file noted in that post to include the 2012 & 2013 UW Holidays.

Note that this newly updated OUTLOOK.HOL file is based on the stock Outlook 2010 file with just the UW 2012 & 2013 dates added. You’ll be closing Outlook, replacing the stock file at C:\Program Files (x86)\Microsoft Office\Office14\1033 with this new copy (to be safe, make a copy of your stock file first), then via the File toolbar, Options, Calendar, Add Holidays…, Uncheck United States and Check UW Holidays 2012 and 2013.

Finally, I note that Outlook 2010 has an internet calendar subscription feature, where you can subscribe to a web-based calendar. I don’t know how well this feature works, or if there’s an iCal formatted calendar for the UW holidays that’s maintained somewhere already, but it’s something worth considering as a possible better solution here.