Sign in with Microsoft (Entra ID)

The Integrations page has a Microsoft Entra ID card. When it is on, the sign-in page leads with Continue with Microsoft (the password form is under Other sign-in methods), and the people in one Entra group can sign in with their work account. Everyone else is refused, even if they are in your organization.

Set it up. The card has the steps; in short, in the Entra admin center:

1. Register an app (App registrations, New registration, this directory only). Add a Web redirect URI, which the card shows (your SIEMLite address plus /api/v1/auth/entra/callback). SIEMLite is https only, so the address must be https.
2. Copy the Directory (tenant) ID and Application (client) ID, and create a client secret (copy its Value).
3. Under API permissions, add the Microsoft Graph application permission GroupMember.Read.All and grant admin consent.
4. Copy the Object ID of the group whose members may sign in. Optionally copy a second group's for Admins.

Enter them on the card, choose Test connection (it shows the group names and how many people are in them), then Save.

How it behaves

• Who may sign in is decided by Microsoft Graph at the moment of sign-in, by asking whether the person is in the access group (members of nested groups count). Nothing in the sign-in token is trusted for that.
• First sign-in creates the account (named after their Microsoft user name, lower-cased) as a Standard user who sees every source, like a new Standard user made by hand; limit them on the Users page. With an admin group, its members are Admins and everyone else is Standard; the role follows the group at each sign-in and check. Without one, roles are yours to set.
• Leaving the group switches the account off and ends its sessions within five minutes (SIEMLite checks every five minutes, and you can choose Check the group now). It is also refused at the next sign-in. Someone who is added back is switched on again. If Microsoft can't be reached, nothing is changed. An account is never switched off or demoted if it is the last enabled admin: it is kept, the check says so, and it can't sign in again while it is outside the group, so create another admin.
• Accounts are matched by Microsoft's object ID, not by name. A Microsoft user name that matches an existing local account is refused, never linked to it, so nobody can take over a local account by having the same name.
• The display name is shown (Justin Waters) in the sidebar, on the Account and Users pages and in audit messages, with the account's email (its username, which stays unique) beside it where it identifies the account. It is taken from Microsoft at each sign-in and at every membership check, so a rename in Entra shows up within five minutes.
• Password sign-in stays for local accounts unless you choose Only allow sign-in with Microsoft (see Sign-in restrictions), so keep a local admin in case Microsoft is unreachable. Accounts that sign in with Microsoft have no password. Turning the integration off, or removing it, stops new Microsoft sign-ins and signs out everyone who signed in with Microsoft right away; the accounts stay, and local sessions are not touched. It is refused if the only enabled admins sign in with Microsoft, since they would be locked out: create a local admin first.
• The client secret is encrypted like the email password (with siemlite-secret.key), is never shown again, and is only ever used with the tenant and app it was saved for.
• Sign-ins, refusals, and changes to these settings are in the audit log (signin.sso, signin.sso.failed, system.entra.save, system.entra.test, system.entra.sync).
• This is for the Microsoft public cloud. Government and other sovereign clouds use different addresses and aren't supported yet.