Azure Identity and Integration: Recurring Questions

In a Microsoft 365 estate, most Azure questions turn out to be identity questions. Something cannot reach something else, and the reason is a permission model that four different documents describe with four different vocabularies.

These are the questions that recur, answered so that the reasoning transfers to the next variant.

Applications and identities

What is the difference between an app registration and an enterprise application?

They are two halves of the same thing. The app registration is the definition: it lives in the tenant where the application was registered and describes what the application is, what it may request and how it authenticates. The enterprise application — the service principal — is the local instance in a tenant that uses it: it holds the consent that was granted, the users assigned, and the sign-in records.

For a single-tenant application both exist in your tenant and it is easy to confuse them. For a multi-tenant one, the registration is in the publisher's tenant and only a service principal exists in yours. That is why you can see sign-ins for an application you did not register.

Delegated or application permissions?

The most consequential distinction in the model.

• Delegated — the application acts on behalf of a signed-in user. Effective access is the intersection of what the permission allows and what the user can do. A delegated Files.Read.All reads only files that user can read.
• Application — the application acts as itself, with no user. Effective access is exactly what the permission allows, tenant-wide. An application Files.Read.All reads every file in the tenant.

Application permissions are appropriate for daemons and background services and dangerous in an interactive application, because the user's own permissions stop constraining anything. If a design uses an application permission to serve a signed-in user, that design has removed the security boundary and is now enforcing it in its own code.

What is a managed identity, and why prefer one?

A managed identity is a service principal Azure creates and whose credentials Azure rotates, usable by an Azure resource. There is no secret to store, rotate, leak or forget.

System-assigned identities are tied to one resource and deleted with it. User-assigned identities exist independently and can be shared across resources, which is what you want when several components need the same access.

If a workload runs in Azure and needs to authenticate to something that supports it, use a managed identity. It removes an entire category of incident.

Client secret or certificate?

Certificate, where the option exists. Secrets are strings: they end up in configuration files, repositories and chat messages, and they expire at a moment nobody diarised. Certificates are harder to exfiltrate accidentally and can be held in a key vault.

Either way, track the expiry as a dependency with a date. An expired credential produces a total outage at a moment nobody predicted, and it is one of the most common self-inflicted incidents in this space.

Consent

Why does an application need admin consent?

Some permissions are considered high impact and cannot be consented to by an ordinary user — anything tenant-wide, and all application permissions. An administrator grants consent once for the whole tenant.

Practical consequence for anyone building on the platform: the permissions you request determine who can approve your application. Requesting more than you need turns a self-service install into an approval process, and sometimes into a refusal.

Can I see what has been consented to?

Yes — the permissions blade of each enterprise application lists granted permissions and who granted them. Reviewing this periodically is worthwhile: consent granted years ago for a trial that ended is still consent.

Access and conditional access

Why does conditional access not apply to this sign-in?

Common causes, roughly in order: the policy is in report-only mode, the user or group is excluded, the application is not in scope, the condition genuinely does not match, or the sign-in used a legacy authentication protocol that policies cannot evaluate.

The sign-in logs are definitive. Each entry shows which policies were evaluated and the result for each. Read that rather than reasoning about which policy ought to have applied.

What is the emergency access account for?

A policy that locks everyone out — including administrators — is entirely possible, and it happens. Break-glass accounts are excluded from conditional access, hold strong credentials stored securely offline, and are monitored so any use raises an alert.

Create them before you need them, and test that they work. Discovering a break-glass account does not work is a very bad way to learn.

Group-based or role-based access?

Groups for collections of people who need the same thing; roles for what may be done. In Microsoft 365 this shows up as security groups controlling resource access and directory roles controlling administrative capability. Keeping the two concepts separate keeps both auditable.

Common mistakes

• Application permissions in a user-facing app. The user's own access stops constraining anything, and your code becomes the security boundary.
• Secrets in configuration. Managed identity or a key vault, always.
• Untracked credential expiry. A predictable outage with an unpredictable date.
• Requesting broad scopes to avoid a second conversation. It creates a harder one.
• No break-glass account. Or one that has never been tested.
• Reasoning about conditional access instead of reading the sign-in log. The log knows; you are guessing.

Frequently asked questions

What replaced Azure AD?

Nothing, in function — it was renamed. Microsoft Entra ID is the same directory service. Older documentation, older blog posts and some older interfaces still use the previous name.

Can a managed identity be used from outside Azure?

No. It is issued to an Azure resource and the token is obtained from within Azure. Workloads elsewhere need a different mechanism, such as workload identity federation, which allows an external identity provider to be trusted without a stored secret.

How do I give an application access to only some mailboxes?

Application permissions are tenant-wide by default. Application access policies scope certain Exchange application permissions to a defined set of mailboxes, which is the supported way to narrow this. It is a specific mechanism and worth finding rather than granting tenant-wide access and hoping.

How long is a token valid?

Defaults exist and are configurable, and the specifics change. Design so that expiry is handled by acquiring a new token rather than by assuming a duration, and look up current defaults when a number actually matters.

The question behind the questions

When something cannot reach something else, ask one thing first: which identity is making this call? A user, a user delegating to an application, or an application acting alone. Almost every answer in this article follows from that, and getting it wrong is why permission problems feel unpredictable when they are not.