Get-ADGroupMember and ADWS parameter MaxGroupOrMemberEntries

By default, ADWS restricts several of the AD PowerShell cmdlets, like Get-ADGroupMember, to returning a mere 5,000 member entries. Which is annoying when you have larger groups, like we do.  Back in July 2015, we were pondering bumping up that limit, as described here:, but couldn’t find others who had made this change.

I ran into this annoying limitation again recently, and after a bit of fresh research found, as someone who actually did make the limit change and had specific syntax to make the change, although there is no real report on impact.

I went ahead and changed this ADWS limit to 200,000 on one of our DCs and re-ran my PS script against that DC. One of many large groups had a timeout (as might occasionally be expected due to other load), but otherwise there was no significant impact (to the DC) and I didn’t have to use the awkward & annoying workarounds of:

$members = Get-ADGroup <groupname> -properties Member | select-object -expandproperty member


(Get-ADGroup <groupname> -properties members).members | Get-ADUser -properties samAccountName | Select-Object samAccountName


$group =[adsi]”LDAP://CN=Group1,OU=Groups,DC=msad”

$members = $group.psbase.invoke("Members") | foreach {$_.GetType().InvokeMember("name",'GetProperty',$null,$_,$null)}


As a domain which has large groups, we seem to run into quite a few Microsoft design constraints, and after trying this in a large AD at 40 times the existing limit, I’m not sure I really understand why Microsoft chose such a low number, although I guess it is because of customers which run DCs on underpowered hardware.

Managing Azure AD Applications

About 10 months ago, it came to my attention that there was a fundamental problem related to Azure AD and applications.

This was a surprise to me–I had cheered on the product team manifesto that applications were first-class citizens in Azure AD.

Since then, I’ve been on a journey of discovery and advocacy. My journey eventually led me to talking with several PMs on the Azure AD product team.

I’ve learned that there is a lot about Azure AD applications and the AAD settings governing them that is poorly documented. I’ve encouraged the product team to fill the documentation gap, and amend the design to provide the right access controls. That journey still continues, and I’m here now to share what I know.

First, I’ll call your attention to the published documentation and relevant links related to the topic of AAD and applications.

The Application object vs. ServicePrincipal document is important in that provides some key understanding if you want to go about identifying all the applications in your AAD tenant. You won’t find all of your AAD applications in *any* of the GUI interfaces, such as the Azure Management Portal or the AAD Access Panel. This omission of some AAD applications in the GUI interfaces is unfortunate because it makes it harder to understand what’s really going on specific to your tenant. You can use the MSOnline Powershell module or the AAD Graph API to discover all of your AAD applications.

The Consent framework document is useful, but it’s one of the documents which is flawed in my opinion–it is incredibly misleading about reality. The reality is that only a fraction of your AAD apps allow user consent–all the others *assume* that the user consent is unnecessary. To my way of thinking, this is a significant design flaw, and the documentation isn’t doing anyone favors by not pointing out that not all apps are subject to user consent.

This brings me to the heart of the new information I have to share. The first link above likely isn’t known to you–it reveals some behind-the-scenes details that aren’t revealed elsewhere, and documents published in that platform are harder to find for some reason. Note that every AAD application has a “home” tenant. Some are enabled for multiple tenancy and some aren’t.

Note that some applications are “curated” by Microsoft–these are the pre-integrated applications in the Azure AD App Gallery. These pre-integrated applications live in a special tenant that Microsoft owns/runs.

Note that there are some applications “owned” by Microsoft–these are applications like Sharepoint Online. It turns out that these applications are “special” in that they are automatically deployed to *every* AAD tenant without any explicit acceptance on your part.

And then there are the applications that anyone might create/develop. These applications fall into two sub-categories:

  • Those that are only in your tenant–one of your users adds them. Microsoft sometimes uses the code words “line of business” apps to refer to these.
  • Those which live in some other tenant and have been added to work with your tenant. Microsoft has two different nicknames for these: consented apps or multi-tenant apps.

It turns out that the only type of AAD app which permits user consent are that sub-category with the consented app nickname.

Down below is a handy reference table I put together while interacting with the AAD PMs that own each of these different AAD app categories that includes all of these details.

Moving beyond the documentation gap and the user consent design flaw, there are several other fundamental problems.

One problem I implied above–that Microsoft can deploy applications to your tenant without notice or consent. I think this assumption on Microsoft’s part is very problematic and I’d encourage them to rethink it and provide enterprise controls for each app they would like to deploy. This is problematic because it violates the design principle that we own our Azure properties. I do not want Bing for Business published to my users–or the latest app that Microsoft has created but which has no HIPAA and BAA agreement. Putting such an application in front of my users will lead to regulatory problems, and is a significant deal breaker. Microsoft’s hubris in thinking they know my environment or that they can use a captive audience to instantly gain market share for their latest creation is ultimately not good for their long-term business relationship with their customer. They need to provide a control here.

Another is in the lack of controls Microsoft has provided around application permissions. OAuth is really cool–it is the protocol Microsoft has adopted that allows one application to be given permissions to another. But Microsoft hasn’t provided the right controls to manage these permissions. Here’s how things work: a developer somewhere writes an application. That developer decides which application permissions their application needs. That developer publishes their application so it is multiple tenant aware. Someone in your tenant comes along and decides to add that application. In the current state, that decision to add the application is an acceptance that the application permissions are acceptable. For many of the types of AAD applications, the person adding the application has no understanding of the implications nor responsibility in your organization for the consequences. A better design would involve a workflow where individuals with specific roles had to approve any application that asked for certain application permissions. Global admins should be required to approve any application that requires the ability to query AAD. Exchange Online admins should be required to approve any application that requires the ability to query Exchange Online. And so on. In the absence of this kind of design, Microsoft needs a stop-gap where it notifies global admins that an application has been added which grants permissions to high-value and high-risk applications like AAD and the set of O365 applications.

Another problem in this area is the poor presentation and documentation specific to the AAD tenant application settings. The Configure tab in the AAD section of the Azure Management Portal has two settings under an “integrated applications” heading.


The names of these settings imply something very different from reality. If you set the first one to yes, you’d think that users can consent to all applications now. And if you set the second one to no, you’d think that no users can add applications. In both cases, you’d be wrong. What’s worse is that if you try to educate yourself by following the help link for these settings, you are sent to a useless AAD product “marketing” page which doesn’t tell you anything about Azure AD applications at all. Of course, there is no Microsoft documentation which informs you that what these settings claim to do isn’t really possible.

To the best of my knowledge, here is what those two settings really mean:

Users may give applications permission to access their data

If the AAD app is a multi-tenant application which is neither a Microsoft nor AAD App Gallery application, then user consent to access their data is possible with that application . The data might be in any number of other AAD applications, including Azure AD itself.

Note that some applications have no user consent or explicit admin consent whatsoever.

Users may add integrated applications

If this setting is yes, then any user in your tenant can add a developed application whether it is a consented/multi-tenant application or a “line of business”/single tenant application. If this setting is no, then only global admins can add these kinds of applications.

Note that if users can add applications, there is no enterprise controls for which data a given application can access. The only control in this case is the user.

A Reference Table for different types of Azure AD Applications

Here’s a handy reference table for keeping things straight:


Pass the Hash Mitigations

Over the last couple years, I’ve seen countless articles explaining Pass the Hash, and there are even a few high-level whitepapers about what to do about it. Here’s some of the best of those:

There’s also a good paper covering the Kerberos equivalent:

Awareness and understanding is all good, but there isn’t enough thinking and public discussion about the specific ways to mitigate the risk.

In many ways, it feels like folks are holding their breath and hoping Microsoft will fix it all.

And of course, in the meantime more places are getting compromised. I have little doubt that yesterday’s announcement of the Premera compromise will turn out to be yet another PtH story.

We’ve closely looked at the Protected Users & Authentication Policies stuff. Like several notable 3rd parties, we’re not convinced they are especially effective given the design. I have high hopes for the Aorato Directory App Firewall (or whatever Microsoft chooses to call it after it re-releases it) and its ability to detect PtH. Likewise, I’m hopeful about the Next Generation Credentials that Joe Belfiore publicly revealed more about recently (but it isn’t yet clear that NGCs help with PtH). And there is the Just in Time administration capabilities that should be released soon with MIM, which would limit how long a given account has privs, instead of it always having privs. There’s also the recent guidance on how to reset the KRBTGT account password. Those are the major things Microsoft has cooking/available for this problem. But those are just part of a strategy, most aren’t available yet, and in some cases require major changes that aren’t realistic to expect anytime soon.

Don’t get me wrong, I’m totally impressed with how much investment Microsoft has poured into this, it’s just that I don’t want to sit around idly any more and I don’t think anyone else should either.

We’ve been talking a bit here about potential ways to mitigate risk that don’t require some new thing and wouldn’t necessarily be a major impact to implement. Not eliminate the risk, but limit it. Here’s some ideas we’ve been tossing around:

  • Automatic user profile deletion after X days via group policy setting. Eliminates cached creds laying idly around. Definitely a good idea for servers, maybe not so much for workstations given the roaming scenario. 
  • Develop strategy to block ‘logon over the network’ user right. Idea here is to inhibit the lateral movement. Still struggling with whether this should leverage the block setting or reduce who has the allow, and beginning to lean toward the latter. Things that need more thought are how to break your sets of computers into logical groupings of levels of trust where you’d apply this–put another way, what are the trust boundaries for this idea? Also needing thought are which accounts would lose logon over the network–seems like you’d want to target accounts that have any sensitive permissions.This idea seems to have lots of promise, but the details are a bog.
  • Push Group Managed Service Accounts more heavily. Perhaps to the point of eliminating “normal” user accounts for services, scheduled tasks, etc.
  • Have better education/practices for which admin accounts should be used in which scenarios. “workstation admin” account only used to log into workstations. “server admin” account only used to log into servers. “domain admin” account only used to log into DCs. Never use these on the same computer, because then you’ve created an escalation bridge. If possible detect when a type of admin account has been used improperly, and alert to take actions to eliminate risk from that.

We’re open to hearing other’s ideas, hearing critiques, or collaboration on these ideas.

Diving Deeper on Azure AD Premium Licensing

Update 2/26/2015: This post resulted in a follow-up conversation with Microsoft. They suggested some changes and improvements which I’ve incorporated below in italics.

I recently seized an opportunity when an Azure AD product team member offered to explain anything about Azure AD licensing. Until that conversation, I was really confused about when we needed an Azure AD premium (AADp) license and when we didn’t.

There are a number of misconceptions around Azure AD premium. For example, AADp is not something you use to refer to a AAD tenant. AADp is something you use to refer to a user. You do not “have an Azure AD premium”. You have an Azure AD user with a AADp license. Unfortunately, some of the literature from Microsoft encourages this kind of misconception.

Anyhow, at the end of that conversation, I got their OK to share the info I learned (and I encouraged them to publish these more nuanced details), because I suspect that if you are like me, you may have some faulty assumptions like these:

  1. That to use any of the advanced capabilities, you need to have an AADp license for all of your users
  2. That since you had to license everyone, that resulting cost meant that the advanced AAD capabilities were dead to you is the (only) published guidance to help you navigate these waters. Using the table at the heart of that page, for each of the capabilities listed (the rows) I got clarification about who (or how many) AADp licenses were needed to leverage that capability. I’ve taken the liberty of re-ordering those rows slightly, mostly to more closely group rows that are related to one another. AAD Basic (AADb) licensing is provided by an Office 365 license.

Here’s a breakdown:

Capability Licensing coverage needed
Directory as a Service AAD Free (AADf)
Service Level Agreement (99.9%) If you have one user with AADb or better, then you get this.NOTE: If there is an outage, only those users which have AADb or better are entitled for refunds. In other words, AADf users don’t pay anything, so they are entitled to no refund.
User and group management AADf
Directory Synchronization AADf
Directory Object Limit (500K) If you have one user with AADb or better, then no limit.Your number of AADf users can not exceed 500K.
Logon/Access Panel branding If you have one user with AADb or better, then you can use this.
Access Panel AADf
SSO for SaaS Apps (assignment limit of 10) AADp required for each user that you want to assign > 10 SaaS apps to.
Secure Remote Access and SSO to on-premises web apps (i.e. App Proxy) Each user that leverages this capability must have AADb or better.
MFA (AAD only) Each user needs AADb license or better.NOTE: see for more details about this and the following item.
MFA (AAD + on-premises) Each user needs AADp license or better.
Group-based Access Management and Provisioning (e.g. license assignment via group) Each admin that leverages this capability must have an AADp license.
Self-service password reset (SSPR) Each user that needs access to this capability must have an AADb license or better.
SSPR write-back to on-premises Each user that needs access to this capability must have an AADp license.
Self-service group management Each user that needs access to this capability must have an AADp license.
Microsoft Identity Manager User CAL Each user that leverages MIM portal must have an AADp license (or separately a MIM user CAL). This is relevant for the Just In Time (JIT) Admin and other on-premises capabilities
Basic Security Reports AADf
Advanced Usage and Security Reports Each admin that leverages this capability must have an AADp license.Every user in a report must have an AADp license.
NOTE: This isn’t yet enforced, and it’s unclear what future changes would reflect this.

So if you have Office 365 licensing, there are actually only a few of these capabilities that require a broad number of AADp licenses, many actually are either covered by AADb or you only need AADp licenses for a handful of users (your AAD admins).

The next trick is to analyze your needs and figure out how may AADp licenses you’ll need based on which of these capabilities you plan to leverage. Keep in mind that the Enterprise Mobility Suite (EMS) is likely the most cost-effective way to purchase an AADp license, so you may also need to take into account your Intune and Azure RMS licensing needs too.