Skip to content

2022

SpAML: Spoofing Users In Azure AD With SAML Claims Transformations

For those that believe SAML is dead, they should take a look at the Azure AD Application Gallery. While the authentication standard finished baking almost two decades ago, it’s still a staple for integration of applications with Azure AD. As of writing, the Azure AD App Gallery has 2015 applications available for SSO integration, and 1335 of them use SAML, roughly two-thirds. Beyond this, there are thousands of line-of-business (LOB) and other 3rd party applications that don’t exist in the gallery but leverage SAML. Many well-known applications and platforms are published in the gallery using SAML – Salesforce, Google Workspace/Google Cloud, AWS, SAP, Oracle Cloud, ServiceNow, Workday… the list goes on and on.

With the ease of federated identity, not only are we tying other cloud providers to Azure AD, but we are also bringing in business critical applications. With this, we need to keep in mind that threat actors are not always targeting critical IT resources; one can do plenty damage with access to records and data stored within SaaS applications.

Azure AD makes it easier than ever to spoof (impersonate) a user within a SAML response. This relatively easy technique allows us to impersonate a highly privileged user in the target application. At the same time, authentication behavior for all other users of the application, including the legitimate user being spoofed, will not change. If your organization leverages SCIM for user provisioning, which is the direction the industry is going, this lends in favor of spoofing going undetected, as optional attributes in the SAML response will go unused by the application.

Within Azure AD, you do not need to be a Global Administrator to configure an Enterprise Application. Anyone with Application Administrator, Cloud Application Administrator, or assigned Owner to a specific application can manage it. From a usability perspective, Microsoft pushes delegation of ownership to the business units. The users, however, that now can manage the application, likely fall under the bar of PIM or any privilege separation. Suffice to say, this opens our potential pool of targets in an organization; needing Global Administrator for movement into target applications is not necessary, just whoever has ownership. Likewise, it’s ripe for abuse by insider threats.

  • in AD FS
  • 9 min read

Field Notes: Migration From Federation To Cloud Authentication

During my stint at Microsoft, I spent a good deal of time with Windows Hello for Business (WHfB), and subsequently would be involved in prerequisite work to set the stage. For the enablement of WHfB, one of these items is device join, and it usually would be Hybrid Azure AD Join (HAADJ) for existing devices already within Active Directory. Device join can be a bit of a rabbit hole if the organization has federated authentication with AD FS in place, as there are different ways you can configure the device join process.

One customer I was working with decided that they wanted to use their WHfB prerequisite work as the same point to switch from federated to cloud authentication with PHS; they were already sending their passwords to Azure AD for use with Azure AD Identity Protection. I discussed high-level what was required to switch but figured the conversation would continue after lunch. Instead, the customer decided to implement the switch during lunch, and their thousand or so users were moved to cloud authentication, with relatively little planning.

Luckily their environment was relatively straightforward from an identity architecture perspective; I wouldn’t recommend going into the switch without more thorough planning. But the point being made here is that the actual period of cutover has a much lower actual risk than perceived risk.

  • in Entra ID
  • 24 min read

CISA SCuBA: Diving Into The Azure AD Baseline

CISA recently released baseline guidance for cloud application security, dubbed SCuBA, or Secure Cloud Business Applications. Within this guidance they cover the M365 and Google Workspace stacks, and they have also released the ScubaGear tool, which you can find here, cisagov/ScubaGear: Automation to assess the state of your M365 tenant against CISA’s baselines (github.com). The ScubaGear tool provides the ability to run an assessment against a targeted M365 environment against baselines. I’ve tested the ScubaGear tool against the Azure AD baseline, and it works well enough, but for the purposes of this post I’m targeting the baseline itself.

When released, there is the natural curiosity to see where things intersect with CISA recommendations, Microsoft recommendations, and what actually works out in the real world. I saw some folks on Twitter commenting that this could be potentially a great tool for analysis for all sorts of commercial and public organizations, big and small. But do the recommendations from, and for, the Federal Government align to what most organizations really need?

I’ll be taking a look at each baseline policy as defined and providing analysis on it specific to the context of its applicability outside of government scenarios. I’ll be going through in order as written, and then providing a final take. Note that for ease the header numbering aligns to the baseline.

If you’re curious to obtain the baseline, CISA has it available as a PDF found here, Microsoft Azure Active Directory PDF. There is also a markdown version on Github that is easier to consume, found here, ScubaGear/aad.md at main · cisagov/ScubaGear (github.com). As I’m only providing reference to the policy itself, I’ll point out that the CISA documents in either format also provide useful license requirement information and details on implementation, which are mostly links to Microsoft Docs Learn articles.

Content between policy definition header and analysis is provided from CISA recommendations. Content after colored Analysis header to next recommendation is my analysis.

VM Contributor To Domain Admin In 60 Seconds

When Microsoft revamped the privileged access model in the late fall of 2020, it was received with mixed results. To some, it felt as if it was overcomplicating the simple three-tier model that had been the gold standard for protecting Active Directory and other critical business assets for about a decade.

However, the shift was necessary, as it was acknowledging that business critical assets are not just the identity provider. The revamp changed how we look at things, with the proliferation of virtualization and cloud providers, and pointing out the management and control plane as critical privileged points of access.

Figure 1

The modern Enterprise access model, courtesy Microsoft

It’s quite a common pattern to extend Active Directory to Azure as the initial standup of infrastructure out there, to support all the other “things” dependent on it.

But as it goes with the cloud, there are new vectors to be on the watch for, and in this case, it’s ensuring that your RBAC permissions over Tier 0 assets in Azure are properly defined.

  • in MFA
  • 8 min read

Azure AD: New Controls For Authentication Strength

Microsoft has released a much asked for setting, which also aligns to the Whitehouse memorandum, M-22-09, calling for federal agencies to require phishing resistant MFA by 2024, you can read the full memorandum here, M-22-09 Federal Zero Trust Strategy (whitehouse.gov).

With this, we now have granularity in Conditional Access to not just specify whether MFA is required, but also how strong the collective authentication is.