Sign-ins, apps and policies

Three tabs on a tenant's page (open the tenant from Cloud > Tenants) cover who is signing in, which apps hold access to the tenant's data, and which Conditional Access policies protect it.

Sign-ins#

The Sign-ins tab has three views across the top: Sign-ins, Risk and Directory activity.

Sign-ins worth a look#

Tenvara keeps the last 30 days of sign-ins worth a look: Failed, Legacy (old protocols such as IMAP and POP, which cannot do MFA) and Risky. Use the buttons (All kept, Failed, Legacy, Risky) to narrow the list, and filter by user, app, client app, result and risk.

Each row shows When, User, App, Client app, Location (city, country and IP address), Result with Microsoft's error code and reason (for example "Failed (50126) Error validating credentials due to invalid username or password.") and Risk.

Look out for successful sign-ins from unexpected countries, legacy clients that succeed, and many failures against one account.

One person's full sign-in log#

Full sign-in log on a user's panel reads that person's sign-ins straight from Microsoft, not only the ones kept here. It shows the newest 500 of the period you pick, with Load more while there are more. Failures only, App, Country and the period are asked of Microsoft itself, so a filtered view reaches back past the newest 500 rather than only searching inside them. Each sign-in lists the Conditional Access policies that applied, each linked to the policy.

Note: Sign-in logs need Entra ID P1 and risk needs Entra ID P2. Without them, the tab says the data is not known and why, rather than showing an empty list. The full sign-in stream (every sign-in, not only the ones kept here) goes into Security events: see Security events.

Risk and directory activity#

Risk lists Entra ID Protection risk detections and risky users (P2). Directory activity lists the tenant's directory audit events: role changes, accounts created and deleted, MFA methods, app consent, Conditional Access changes and so on.

Some of these raise alerts that a person acknowledges: a new high-risk sign-in, a user newly at high risk, leaked credentials, impossible travel, password spray, someone added to an administrator role (critical for Global Administrator), a Conditional Access policy deleted or switched to off or report-only, app consent, strong authentication switched off, security info deleted, a new cross-tenant partner, and the audit log being switched off.

Apps#

The Apps tab lists the tenant's enterprise apps with the permissions they were actually granted, not what they ask for. Views: Third-party, Microsoft, All and Expiring in 60 days (apps whose secret or certificate is about to end); filter by privilege and state.

Each app shows its publisher, Privilege, Application permissions, Delegated permissions (with "everyone" when consented for all users) and State. Tenvara's own app is labelled as such. Microsoft's own apps are listed but never judged.

An app is High privilege when it holds permissions that can read or send everyone's mail, read every file, change the directory or give itself more rights (for example Mail.ReadWrite, Files.Read.All, Directory.ReadWrite.All, Policy.ReadWrite.PermissionGrant). A banner at the top counts them. Grants people made for their own mailbox only are shown but are not what makes an app high privilege.

The security check High privilege apps are reviewed lists the enabled high privilege apps from outside Microsoft that nobody has reviewed, unverified publishers first. Marking an app Sanctioned on the SaaS apps page counts as its review, and the tenant is checked again straight away. See SaaS discovery.

Click an app to open its panel with its publisher (and whether it is verified), app id, and every application and delegated permission explained. For an app that is no longer wanted:

• Disable it (and enable it again later), or
• Revoke permissions: every delegated grant and application permission is removed. This is destructive; what it held is kept in the change log so you can see what it had.

For backup and security apps, Disable this app sits under More with a warning, because switching one off can stop protection the customer relies on.

To see one app across every tenant you look after, switch an app off everywhere at once, or clear out apps nobody uses, see Apps across tenants and the kill switch and App cleanup, approved apps and the watchlist.

Policies#

The Policies tab lists the tenant's Conditional Access policies with their State (Enforced, Off or Report-only), Control (for example MFA), a one-line summary in words and when they were Changed. Policies Tenvara deployed say so. Each has an actions menu.

Click a policy to open it in a side panel: who it covers and leaves out, by name, its apps, conditions, grant and session controls, the template it matches, what it did over the last 7 or 30 days, What if for one person, and its history with who changed what. Copy as template saves it for your other tenants. See Conditional Access policies in detail.

Templates#

Below the policies, Templates are policies Tenvara can deploy for you:

To deploy one:

1. Press Deploy on the template.
2. Under Leave out these accounts, choose your emergency access (break-glass) accounts, so a mistake cannot lock every administrator out. When a template is deployed from a finding's Fix, the accounts Tenvara recognises as emergency access accounts are left out for you. And these groups optionally leaves out a group. The directory sync account is always left out.
3. Leave Enforce straight away unticked, then press Preview and confirm. The policy is created report-only and named with your prefix followed by its purpose, for example "Tenvara - Require MFA for administrators". The prefix is set under Changes Tenvara makes in Settings > Microsoft 365, the Connection tab.
4. Watch the sign-in logs for a while to see who it would have affected.
5. When it looks right, choose Enforce from the policy's actions menu. Under Who is left out of the enforced policy, choose Leave the emergency access accounts out (added to its exclusions in the same change) or Keep the exclusions as they are. The preview shows what the policy did in report-only over the last 30 days: the sign-ins it would have blocked or asked more of, and the accounts behind them. Enforcing is high risk, so it needs an administrator or their approval.

Templates you saved from a policy with Copy as template show beside the built-in ones and deploy the same way. A template that another policy already does says Already done by with the policy's name, and offers Deploy anyway.

The actions menu on each policy has Enforce, Turn off and Delete. If a template was already deployed report-only, the matching finding offers to switch it on rather than deploying a second copy. Deleting a policy is destructive; the named location a template made is deleted with it.

Warning: Enforce straight away skips report-only: anyone the policy applies to who cannot meet it is stopped from signing in at once. It is high risk and needs an administrator.

Named locations#

Named locations lists the places Conditional Access can allow or block: IP ranges (with whether they are trusted) and countries. The high-risk countries template creates its own named location.