Six Considerations Identity Admins Should Be Aware of Around Scripting

*NOTE: This article was originally published on Thursday, 2/29/24. After receiving feedback from the MVP Community, we decided to unpublish on Monday, 3/4/24 and re-review the article for specificity and clarity. We appreciate the feedback and support from the MVP Community, and we welcome all IT Pros alike to continue providing ENow and our authors directly with constructive feedback.

As an Identity admin, you’ve surely had to use your scripting skills to accomplish some incredible feats, streamline specific actions, or get something reported neatly and tidily. Chances are, you used the Active Directory PowerShell module, as it has been available since Windows Server 2008 R2.

With Entra ID (previously known as Azure AD), this has all changed.

Sure, you could still report on attribute anomalies for user objects that were synchronized within your hybrid organization… However, it just isn’t the same for organizations when multi-factor authentication and Conditional Access policies come into play and are only available on the cloud side of things.

Over the years, as Identity admins, we went from DirSync via Azure AD Sync Services to Entra Connect and from the msonline, to the azuread and even azureadpreview PowerShell modules… until finally (and this moment rapidly approached…) everything PowerShell got swooped up in the Microsoft Graph PowerShell SDK… v2.

All these changes present significant challenges when creating and maintaining scripts. Below I’ve identified some considerations that Entra ID admins should be aware of around PowerShell scripting, because if not handled properly it can cause unnecessary bottlenecks. My intent is not to suggest that Identity admins dismiss scripting altogether; just provide some practical observations and opinions I’ve developed over the years that can possibly guide and help others.

Azure AD? Whatcha talkin’ ‘bout, Willis?!

First off, Microsoft renamed Azure Active Directory to Microsoft Entra ID. In my opinion, this poses challenges for Identity admins when:

• Looking for scripts that provide reports for specific products that may or may not have been renamed. (It is a little strange, that Azure AD B2C wasn’t renamed, but at least now you won't have to search online for Entra Consumer ID as the likely name for the successor, as is the case with Entra External ID... Soon, searching for Azure AD B2B only surfaces outdated information).
• Analyzing scripts or adding comments to scripts written by others in your organization.
• Troubleshooting scripts.

While this change poses additional challenges - I do believe Microsoft did the right thing by renaming Azure AD to Entra ID. The new suite, also incorporating Permissions Management and Entra Verified ID, makes conversations easier. People don’t get hung up on Azure or Active Directory monikers anymore.

With the new Entra ID name, Active Directory/Identity admins also have more realistic expectations, because most of their knowledge around Active Directory is outdated and doesn’t apply to Entra ID. The products are nothing alike. Writing scripts to report in Entra is a different beast altogether, mainly because managing Identity, underpinning most security efforts for an organization, and writing scripts still seem worlds apart.

Don’t think random scripts you find on the Internet will just work

When you search the Internet for people with the same reporting challenges (let’s stick to the identity topic for now) you’ll find a lot of scripts that you think should work. Yet, when you run them, they don’t. Even though the script may have been written by favorited Microsoft Most Valuable Professionals, it may:

• Be outdated as it uses endpoints that have long been deprecated, especially when the scripting approach was to invoke web requests.
• Be difficult to understand as terminology in the Microsoft Graph API is sometimes different to terminology used in the Entra portal. The use of serviceprincipal in the Graph API vs. application objects in the Entra Portal still confuses more Identity admins than that it helps them grasp what is going on under the hood of Entra, from my personal experiences.
• Be difficult to troubleshoot as some cmdlets in the Microsoft Graph PowerShell SDK provide some sought-after attributes only when you dig deeper into additional properties of their output objects.
• Not be returning all the information you need or expect. In my experience, some functionality was only available in the Beta Graph PowerShell SDK and not in the supported Graph PowerShell SDK, even though the (Preview) text had long been removed around the functionality in the Entra portal.

It takes time, and trial and error to figure this out, which can be frustrating and time-consuming; in my experience – I feel like that unproductive time could be better allocated.

However, hindsight is 20/20 as they say. Admins and IT Pros didn’t know what they didn’t know, impossible to know that everything would end up changing. So, we all used the msonline module in PowerShell v2 to get everything done.

Unfortunately, that ship has sailed, and in my opinion, Identity and security admins must pivot. Microsoft was able to delay the inevitable for a long time – probably to keep their enterprise customers somewhat happy since their initial announcement mid-2020 – but could no longer prolong it. Now, Microsoft only guarantees that the msonline, azuread and azureadpreview PowerShell modules will work until September 30^th, 2024. Sometime after that date, the API backing these PowerShell modules is retired. Furthermore, the authentication libraries (ADAL) used by the affected modules are being deprecated.

What does that mean exactly?

It means everything is going to have to be rewritten to use the Microsoft Graph and thus the Microsoft Graph PowerShell SDK. You won’t be able to get by just knowing the earlier names for Entra products in everyone’s favorite search engine as your ace up the sleeve anymore.

The map that provides equivalents for cmdlets in the msonline and azuread modules in the Microsoft Graph PowerShell SDK is riddled with exceptions and new approaches. For some categories, like the Entra Application Proxy cmdlets in the azuread module, equivalent cmdlets don't even exist (yet) in the Microsoft Graph PowerShell SDK. The same goes for the Get- and Set-MsolCompanyAllowedDataLocation and Get- and Set-MsolPartnerInformation cmdlets in the msonline module, even though these functionalities are not yet fully deprecated...

The least privilege principle applies to all principals

In Identity Management, a principal is any entity that can be authenticated by the operating system. Things such as a user account, a computer account, or a thread or process that runs in the security context of a user or computer account, and the security groups for these accounts.

With two decades of history and malmanagement applied towards a lot of Active Directory environments, I still come across environments where service principals are members of the Enterprise Admins group. In my opinion, most of the time, the service itself – mostly monitoring and backup solutions – has long gone.

While this works for the identity provider that operates within the walls of your organization and only serves up identity for your organization, it isn’t a secure setup. Not at all. However, most scripts targeting Entra ID and the Graph API run with the credentials of a Global Administrator or a service principal with risky permission (combination)s like Directory.ReadWrite.All and AppRoleAssignment.ReadWrite.All.

At first, as a coder, this doesn’t hurt you… until it does. Even Microsoft has struggled with this, where Midnight Blizzard abused toxic combinations of API permissions consented to for applications. It really hurt Microsoft as adversaries cunningly had access to all email messages of Microsoft's top brass. Further down the road, when your organization revamps your script to a multi-tenant app, it doesn’t seem to make the waves you thought it would. Security-savvy people will laugh at permissions that do not follow the principle of least privilege and downright dismiss your solution for it.

The fact is any service principal used by scripts should only have the least number of privileges assigned to be able to perform its job. Not one API permission more, if you don’t want to be pwned.

Microsoft does offer some guidance in its Microsoft Graph permissions reference, where all API permissions can be reviewed. It is updated regularly, but unfortunately Microsoft doesn’t offer a notification service to get notified of any changes so that you can research, rewrite and reapply the least privilege to your scripts or apps… The new Read.UserBasic.All permission was recently introduced to replace the commonly used Read.User.All permission to avoid privacy issues. It can easily be replaced in most scripts, but at the same time, a lot of apps in production Entra tenants I encounter still have the User.Read permission in the Windows Azure Active Directory API consented to.

The Find-MgGraphPermission cmdlet in the Microsoft Graph PowerShell SDK provides least permissive scopes for running PowerShell against the Microsoft Graph. However, when you use certain cmdlets to only get specific information, all the *.ReadWrite permissions shouldn't be consented to. When you pipe the output of one cmdlet into another, the permissions for both cmdlet actions should be added.

At the end of the day, I found that the Microsoft Graph Command Line Tools enterprise application in many Entra tenants, has accumulated over 35 API permission scopes. Salient detail: removing excess consented permissions cannot be done in the portal.

The only constant in life is change

It feels like Entra admins are headed for calmer waters when it comes to Microsoft Entra using a Graph API-only approach, but this is only a snapshot. Active Directory used to offer new features every three years, but Entra – this magnificent new beast that runs on hundreds of thousands of CPUs worldwide, offering services to over a hundred million organizations – has a much different, faster change rate. Microsoft seems to make three changes per day, on average. Identity admins I have worked with in hybrid environments have shared with me that it feels like a delicate balancing act that, in recent years, has made them feel insecure in this aspect of their jobs.

Keeping up to date is essential. Microsoft’s What’s New in Microsoft Entra page features a lot of these changes. In contrast, their What’s deprecated in Microsoft Entra page zooms in on the tail end. Both, however, don’t typically include announcements and changes from events like Microsoft Ignite and Microsoft Secure. They also don’t feature everything that you can read in the Message Center.

To be really in the loop, you’ll need to combine a couple of sources. I specifically made the choice a couple of years ago to keep up to date with Microsoft Identity only, as keeping up to date in that area alone felt like drinking from a firehose.

Maintaining and Updating Scripts

Back in the day, I used to share the scripts I wrote. Sometimes, someone would come along and complain about the script not working as intended in their environment, usually because of some choice their organization made a while ago. I addressed the feedback, we all laughed, and we went our merry ways.

I know that this happens within organizations, between organizations and individuals. If you had told a man 24 years ago that all his efforts into what he just released as v1.0, would eventually lead to the biggest patching event of 2021 – no one would have believed you. Yet, we were all still scrambling to get Log4J patched in our environments.

However, for organizations offering solutions, the rules of the game have recently changed. The European Cyber Resilience Act includes requirements for ‘products and software with a digital component to be cared for and supported for the entire lifecycle of these products. An exception is made for services and open-source software, but these exceptions may not apply to you when you share scripts as part of your company's solutions. Don’t think this won't apply to you as you live outside of Europe and share scripts as part of the services your company provides... In the past, European regulations have made it across the pond, like into California’s CCPA and Canada’s DCIA.

Zero trust… but how often?

Your reporting scripts run. They provide snapshots of your Identity infrastructure, but does that accomplish the goal? With Logic Apps, you can trigger your scripts, but does that happen often enough?

As the Identity world moves around us at a break-neck speed, attacks are also happening with increased frequency. The 8-second breach that impacted 123 employees at AmeriGas raised eyebrows in 2021; but the record from first access to complete encryption now stands at 1h17, and SecureWorks reports on an average dwell time of a mere 5 hours. Response times can vary because when ransomware hits your organization outside office hours, your scripts may or may not run, and there may or may not be an SOC person investigating the incidents.

The point is these “mere snapshots” just don’t always cut it anymore. When you run scripts for monitoring and security reporting purposes, they must provide near real-time, instantaneous, useful information.

A Solution for monitoring Identity

When you’re a lone scripter or the only Identity-savvy person in your organization, it can be difficult to effectively script these days. It doesn’t have to be this way. There are Identity Reporting solutions in the marketplace that save time and offer the same and often more - of functionality of scripts that you could write to generate reports. This doesn’t require Entra knowledge from your side. ENow’s AppGov Score (free assessment report) and App Governance Accelerator (paid version) are two of those Identity Reporting tools available for Application Security Posture Management. At ENow, their professional team keeps up with Microsoft’s daily Entra ID changes, applies recommended practices like least privilege, and knows how to work with regulators so the solutions they offer don't pose additional risk in the context of supply chain attacks.

App Governance Accelerator provides specific reports on API permissions and other typical application risks – automating a process that would typically require hours of scripting and scheduling effort by an Identity admin, to retrieve.

Additionally, in the next product release update App Governance Accelerator will issue alerts when risky permissions or credentials are added to existing applications, so Identity and security admins can act near real-time, if necessary, thereby strengthening their organization’s security posture. These as-a-Service features set their solution apart from many of the as-a-Script functionality that is available through others.

Whether you choose to continue scripting or work with a vendor like ENow for monitoring and reporting on Entra ID, ensure you consider the management, maintenance and security of your efforts to ensure your organization is both efficient, effective, and protected.

The free AppGovScore provides a score card that Identity and security admins can share with their peers that outlines the importance of application governance and where your organization can improve. The App Governance Accelerator enables Identity and security admins to work with others in their organization on improving governance of enterprise applications and application registrations in Microsoft Entra. It offers reports tailored to Entra admins, application owners, SOC personnel and C-level executives.                                                                                                                                                                                                                 

Does your Entra ID tenant follow Microsoft-recommended security practices? Sign up to get your score and assessment report in just a few minutes - get your AppGov Score now!