Sign in with Microsoft Entra ID
With Entra ID single sign-on, your team signs in to aethercert with the Microsoft work account they already have. You register the application in your own tenant, so access, Conditional Access policies and MFA all stay under your control — aethercert never sees more than the identity your tenant hands it.
Whoever you allow into the application gets in, and is added to your aethercert organization the first time they sign in. No invitations to send. Revoking someone in Entra — or offboarding them — takes their aethercert sign-in with it.
Single sign-on is optional and additive: password sign-in keeps working for everyone, including for people who use Microsoft.
What you need
- Owner access to the aethercert organization.
- Permission to create an app registration in your Entra tenant (Application Administrator or Global Administrator).
- The email domain(s) your users sign in with, e.g.
contoso.com.
1. Register the application in Entra
Entra admin center → App registrations → New registration.
| Field | Value |
|---|---|
| Name | aethercert (anything you like — your users see it on the consent screen) |
| Supported account types | Accounts in this organizational directory only |
| Redirect URI | Platform Web, and the URI shown on the aethercert SSO settings page |
Copy the Redirect URI from Settings → Organization → Single sign-on in aethercert rather than typing it — it must match exactly.
After creating it, note the Application (client) ID and Directory (tenant) ID from the Overview page.
Client secret
Certificates & secrets → New client secret. Pick an expiry you'll remember, and copy the Value immediately — Entra shows it once and never again.
Secrets expire
When the client secret expires, Microsoft sign-in stops working for your whole organization. Set a reminder, create a new secret before the old one lapses, and paste it into aethercert. Password sign-in is unaffected, so nobody is locked out.
Email claim
Token configuration → Add optional claim → ID → email. Accept the prompt to turn
on the Microsoft Graph email permission if it appears.
aethercert identifies users by email address, so without this claim sign-in fails with "Microsoft did not return an email address for this account".
Who may use it
By default every user in your tenant can use the application. To restrict it:
- Enterprise applications → aethercert → Properties
- Assignment required? → Yes, save
- Users and groups → assign the people or groups who should have access
Entra then refuses to issue a token for anyone unassigned, so they can't sign in and are never created in your organization.
Conditional Access policies (MFA, compliant device, named locations) are scoped to this same application.
2. Connect it in aethercert
Settings → Organization → Single sign-on, then fill in:
| Field | What it does |
|---|---|
| Directory (tenant) ID | Your Entra tenant. |
| Application (client) ID | The app registration you just created. |
| Client secret | The Value you copied. Stored encrypted; leave the field empty later to keep the existing one. |
| Email domains | Which addresses get routed to your tenant at the login page — and which are accepted coming back. Guest accounts on other domains are rejected. |
| Role for new members | The role people get on first sign-in. Member unless you have a reason to hand out Owner. |
| Create accounts on first sign-in | On by default. Off: only existing members can use Microsoft sign-in. |
| Trust our Conditional Access for two-factor | See below. |
| Single sign-on enabled | Turn off to suspend federated sign-in without deleting the configuration. |
Click Connect.
3. Sign in
Clicking Continue with Microsoft sends the browser to your tenant, where people pick their account — or get signed in silently with the machine's work account, if Windows already has one. On the first sign-in they're added to your organization with the role you chose; after that they land straight in it.
Because every organization brings its own app registration, aethercert has to know which tenant to send someone to before redirecting. There are three ways it does:
- The direct link. The SSO settings page shows a link like
https://…/auth/sso?domain=contoso.com. Following it goes straight to your tenant with no aethercert login page in between. Put it on your intranet, hand it out as a bookmark, or set it as the app registration's Home page URL so aethercert turns up in the Microsoft 365 app launcher. This is the one-click path. - Remembered. After anyone's first successful sign-in, that browser remembers the domain — Continue with Microsoft then goes straight through, nothing to type.
- Asked once. On a browser that has never signed in and arrived at the login page directly, aethercert asks for the email domain. That's the only time.
Skip the login page entirely
Set the app registration's Home page URL to the direct sign-in link. Users launch aethercert from Microsoft 365 like any other app, and never see a login form.
Two-factor authentication
aethercert normally requires a second factor on every account. The Trust our Conditional Access for two-factor setting (on by default) waives that for people who signed in through your tenant, on the basis that your own policies already decide how they authenticate.
Two things are worth knowing:
- The waiver applies to the Microsoft sign-in only. If someone with a password signs in with it instead, aethercert asks for a code from their authenticator app as usual.
- Turn the setting off if your tenant doesn't enforce MFA for this application. Federated users then enrol an authenticator app like everyone else.
Existing accounts
Someone who already has an aethercert account with the same email address keeps it — Microsoft sign-in links to that account rather than creating a second one, and adds them to your organization if they weren't already a member. Their password keeps working too.
Accounts created by Microsoft sign-in have no password at all — their way in is your tenant. If one of those users wants a password as a fallback, they can set one through Forgot your password?, and will then be asked to enrol an authenticator app the first time they use it.
Removing the connection
Disconnect removes the tenant link and the domain claim. Current members keep their access and their password sign-in; what stops is Microsoft sign-in and the automatic provisioning of new people. To cut off individuals instead, unassign them in Entra and remove them under Settings → Organization → Members.
Troubleshooting
"Single sign-on isn't set up for contoso.com." The domain isn't on this connection's list, or it's claimed by another aethercert organization — a domain can only be used for single sign-on once.
"That app registration is already connected to another aethercert organization." One app registration backs one organization. Create a second registration, or disconnect the other one.
AADSTS7000215 / "Invalid client secret provided." The secret expired, or the Secret ID was pasted instead of the Value. Create a new secret and paste its Value.
AADSTS50011 / redirect URI mismatch. The redirect URI on the app registration doesn't match the one shown in aethercert. Copy it again — it must be identical, including scheme and trailing path.
"Microsoft did not return an email address for this account." The email optional
claim isn't configured — see Email claim.
"… is not on this organization's list of allowed email domains." The account signed in with an address on a domain you haven't listed. Common for guest (B2B) accounts, which keep their home-tenant address.
The user gets an error from Microsoft before reaching aethercert. They're not assigned to the application, or a Conditional Access policy blocked them. Both are decided in your tenant, not in aethercert.