Connecting Azure AD

Signs users in with the Microsoft work or school account they already have.

Where to find it

Architect Panel → Integration & Connections:

• Azure AD Tenants — the connections and their credentials

Architect Panel → Security:

• Authentication Methods — enabling the Azure AD route

Why it is usually the right choice

Where an organisation runs Microsoft 365, this is the least work and the strongest result. Their existing policy applies — conditional access, their own second factor, device compliance — and you implement none of it.

Disabling somebody centrally stops them signing in here, which is most of what a leaver process needs.

You register the application

In the Microsoft admin centre, producing a tenant identifier, a client identifier and a secret. Those three go into the connection here.

The registration belongs to your organisation, so you can see what it can do and revoke it without involving anybody else.

What a connection holds

• A name, so several are distinguishable.
• Tenant, client identifier and secret.
• An access mode.
• Scopes — what you are asking Microsoft for.
• A custom API path, where needed.
• A local tenant flag, tying the connection to one tenant of your installation.

The secret expires, and it will break everything

Microsoft client secrets have an expiry, commonly six or twelve or twenty-four months. When it passes, sign-in stops for everybody on that connection at once.

It is the single most common failure with this integration, and it is entirely preventable because the date is known when you create it. Diary the renewal at creation — not later, because later does not happen.

Choose the longest permitted lifetime, and note it somewhere your successor will find.

Ask for the minimum scope

Sign-in needs identity — who they are and their e-mail address. Requesting more may require administrator consent across the organisation, which turns a small change into a conversation with somebody else's IT department.

Redirect addresses must match

Registered exactly in the Microsoft application. A trailing slash or a wrong scheme fails before sign-in even starts, and it is the commonest configuration error after the secret.

Test with an ordinary account

Not a global administrator's — theirs may behave differently and will not exercise the same consent path. Use an account resembling a real user.

Keep a local route in

If every administrator signs in through Microsoft and that is unavailable, nobody can get in to fix it. One local administrative account with a passkey, tested rather than assumed.

Worked example

An organisation registers an application requesting identity scopes only, with two exact redirect addresses and a twenty-four-month secret diarised at twenty-two months with two named owners. Sign-in is tested with an ordinary staff account. Two local administrator accounts are retained and verified quarterly.

Recommendations

• Diary the secret expiry at creation.
• Request identity scopes only.
• Test with an ordinary account.
• Keep and test a local administrator.