Azure AD / Microsoft Entra

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.

Multiple Tenants

More than one Azure AD connection can exist, each pointing at a different Microsoft directory.

Where to find it

Architect Panel → Integration & Connections:

• Azure AD Tenants — the connections

Architect Panel → Configuration:

• Multitenancy — the platform tenants they may be tied to

When you need several

• A multi-tenant installation where each customer signs in with their own Microsoft directory.
• A group whose subsidiaries have separate directories.
• Partner access, where an external organisation's staff sign in with their own accounts.

Tie each to its tenant

The local tenant setting binds a connection to one tenant of your installation. On a multi-tenant platform that matters a great deal: without it, a connection intended for one customer is available to another.

Set it deliberately on every connection. This is the field that keeps customers separate, and the failure is not obvious from the sign-in page.

Name them for the organisation

Not "Azure 2". When a secret is about to expire or a connection fails, you need to know whose it is immediately — and the person handling it may not be the person who set it up.

Each has its own expiry

Several connections means several secrets on different dates. That is several diary entries, and the one that is missed will be the connection nobody thinks about.

Keep a single list of every connection and its expiry rather than relying on remembering. Reviewing it quarterly takes minutes.

Know who administers each directory

Renewing a secret needs somebody with rights in that Microsoft tenant, who may work for another organisation entirely. Record who that is alongside the connection — discovering you do not know, on the day it expires, is a bad afternoon.

The same person in two directories

Somebody with accounts in two connected directories arrives as two identities, because identity includes the method and domain. Usually correct — they are acting in two capacities — and occasionally confusing.

Be ready to explain it, particularly to consultants who work with several of your customers.

Test each separately

A working connection tells you nothing about the others. When adding one, test that one, and confirm it lands users in the right tenant with the right groups rather than assuming it inherits the behaviour of an existing connection.

Retiring one

When a customer leaves, disable their connection. Their accounts remain until you deal with them, so decide what happens to those too — an account that can no longer authenticate is not the same as one that has been closed.

Worked example

A multi-tenant platform runs four Azure connections, each named for its customer and tied to its own local tenant. A single reviewed list holds each secret's expiry and the administrator contact at that customer. When one customer's directory was restructured, only their connection needed attention.

Recommendations

• Always set the local tenant on a multi-tenant installation.
• Name connections after the organisation.
• Keep one list of connections, expiries and contacts.
• Test each connection separately.