↓ Skip to main content
dp666

Introducing DUDE Manager Posture: Why It Matters

·6 mins
Automation Azure Functions DUDE Manager Microsoft Intune PowerShell Security

Automation is useful. Evidence is what makes it operational.

That is the reason I built the new Posture feature in DUDE Manager.

DUDE Manager started as a practical answer to a very real Intune problem: organizations think in user groups, Intune assigns many things to device groups, and there is no clean native bridge between those two worlds. DUDE reads user membership, resolves the user’s devices, and keeps the target device groups in sync from an Azure Function.

That part matters.

But once automation starts changing directory membership, Administrative Unit memberships, or Microsoft Defender for Endpoint machine tags, another question becomes just as important:

Can I review the automation before I rely on it?

Posture is the answer to that question.

Why DUDE Manager Posture matters
#

Most automation failures do not start with the main logic being completely wrong.

They start with something around the logic drifting:

  • A Function App is still in debug mode when someone expects production behavior.
  • A managed identity has more permission than expected.
  • A Graph permission was added during testing and never removed.
  • A storage role allows key access where Azure RBAC would have been enough.
  • Telemetry exists, but not enough evidence is available to explain what happened.

None of those are exciting feature bullets.

They are exactly the things you want to know before you rely on an automation system with user, device, and tag membership.

That is what Posture is for. It gives DUDE Manager a review surface for the automation control plane and runtime environment, not only the configuration table.

What Posture checks
#

The first version of Posture focuses on evidence that is practical to collect from the DUDE deployment itself.

The first check set is intentionally small and named: DSEC-001 through DSEC-011.

Posture reports findings using statuses such as PASS, WARN, FAIL, INFO, UNKNOWN, and NOT_APPLICABLE. UNKNOWN is intentional. It means the available evidence was not enough to prove the state. That is not the same thing as NOT_APPLICABLE.

It looks at things like:

  • Runtime mode
    Whether the Function App is configured for debug/WhatIf or production behavior.

  • Managed Identity
    Whether the Function App has a system-assigned managed identity and whether the expected application permissions are present.

  • Microsoft Graph permissions
    Whether the managed identity has the core Graph permissions DUDE needs, and whether optional Admin Unit Graph permission and Defender API permission match the enabled features.

  • Storage RBAC
    Whether the managed identity has table access to the DUDE storage account, and whether broader storage access patterns are visible in the covered scope.

  • Function App settings
    Whether the required DUDE setting names are present without exporting raw setting values.

  • Operations telemetry
    Whether recent execution evidence is available, including runtime mode and success/failure information when Application Insights data is accessible.

  • Redacted export evidence
    Whether a review snapshot is designed to omit or redact common sensitive identifiers such as tenant IDs, subscription IDs, raw connection strings, user names, device names, and table rows.

The goal is not to turn DUDE into a generic compliance scanner.

The goal is narrower and more useful: make the DUDE deployment reviewable.

What it deliberately does not claim
#

Posture is not a certification.

It is not a penetration test.

It is not a replacement for Microsoft Entra governance, Conditional Access design, Privileged Identity Management, Defender configuration, or a formal audit.

It also does not claim that every business rule in a tenant is correct. DUDE can tell you whether a configured group, identity, permission, runtime mode, and telemetry surface line up with what the tool expects. It cannot know whether your organization intended a particular user to own a particular device or whether a target group is the right business target.

That distinction matters.

Posture is evidence for reviewing DUDE. It is not a blanket statement about the tenant. DUDE prefix allowlists constrain what the runtime processes, but they do not resource-scope the underlying Microsoft Graph or Defender application permissions.

Redacted and internal exports
#

The Posture tab can export review data in two modes:

  • Redacted export for creating a review snapshot designed to omit or redact raw tenant identifiers, user names, device names, connection strings, and secret-bearing values.
  • Internal export for deeper troubleshooting when you are working inside the tenant boundary.

The redacted export is intentionally conservative. It keeps the useful review shape: check IDs, statuses, counts, permission names, role names, and setting names. It removes values that should not casually end up in an issue, a chat, or a public discussion. Because redaction is field and pattern based, review any export before sharing it outside your tenant boundary.

This is one of the small details that matters in real operations.

The fastest way to make people stop sharing evidence is to make the evidence risky to share.

Why this belongs in DUDE Manager
#

DUDE already separates responsibilities:

  • The GUI configures, deploys, validates, and starts operations.
  • The Azure Function runtime performs the Graph group membership changes, Administrative Unit membership changes, and Defender for Endpoint machine tag changes using managed identity.

Posture extends that model.

It gives the GUI a way to inspect the deployed runtime environment without turning the GUI into the runtime writer. The GUI still does not perform the membership writes itself. It reviews the deployment, permissions, telemetry, and evidence around the runtime.

That keeps the architecture honest:

  • configuration lives in the GUI and Azure Table,
  • execution lives in the Function App,
  • review evidence lives in Posture.

If you want the background before this release, start with the original DUDE Manager launch post and the follow-up DUDE Under the Hood: Managed Identity Setup and Permissions.

The practical release value
#

For this release, Posture is the headline feature.

There are also a lot of stabilization fixes in the changelog: one-login authentication behavior, telemetry normalization, Function App log handling, cleanup and deployment reliability, empty-tenant behavior, Defender tag sync edge cases, and release validation hardening.

Those fixes matter, but they are not the story.

The story is that DUDE Manager is moving from “this automation works” toward “this automation can be reviewed before and after it runs”.

That is a different level of operational maturity.

When to use it
#

Use Posture when:

  • you deploy DUDE in a new tenant,
  • you update an existing DUDE installation,
  • you enable Admin Unit sync or Defender tag sync,
  • you want to check whether runtime mode and permissions match expectations,
  • you need a redacted review snapshot for documentation or peer review,
  • you want to review whether permissions, runtime mode, and telemetry evidence still match expectations.

It is especially useful before switching from debug/WhatIf mode to production mode.

That is the moment where evidence is worth the extra minute.

Closing thought
#

Automation without evidence becomes a guessing exercise.

I do not want DUDE Manager to work that way.

DUDE should be inspectable, explainable, and boring in the places where operations need it to be boring. The new Posture feature is a step in that direction.

DUDE Manager is open source and MIT licensed.

GitHub: https://github.com/danielpetri666/DUDE-Manager

Further reading: