Read your own identity, sign-ins and sign-in methods in Microsoft Entra ID
Task
Without changing a single setting, see Microsoft Entra ID from the inside. You will read which tenant your subscription trusts and how your own account appears in it, find which Entra ID licence the tenant has and what that means for Conditional Access, read your recent sign-ins with the signals Conditional Access would use, sort your registered sign-in methods into the three kinds of factor, and count the guest users in your directory. Then sort a set of scenarios into single sign-on, MFA, passwordless, Entra Domain Services, Entra Connect, External ID and Conditional Access.
Steps
- Read the subscription's tenant and the identity Cloud Shell signed in as:
az account show --query '{subscription:name, tenant:tenantId, signedInAs:user.name}' -o table
The tenant value is the one Microsoft Entra ID tenant this subscription trusts (lesson 6): the directory that authenticates everyone who can be given access to it. 2. Read how your own account appears in that directory:
az ad signed-in-user show --query '{name:displayName, upn:userPrincipalName, type:userType}' -o table
If you created the subscription with a personal Microsoft account, your user principal name contains #EXT# and ends in onmicrosoft.com: the directory holds a record that points at an identity Microsoft stores elsewhere. Either way, type reads Member for the person who created the tenant. 3. Find the tenant's licence. In the portal, search for Microsoft Entra ID and open its Overview. Read the tenant name, the primary domain and the License field. On a new subscription it reads Microsoft Entra ID Free. That is why the Conditional Access page will tell you it needs a premium licence: the policy engine from lesson 10 is a P1 feature. Close any trial banner without starting it. 4. Read your recent sign-ins. In Microsoft Entra ID, open Sign-in logs (under Monitoring) and open the most recent entry for your own account. Its tabs show the signals lesson 10 lists: the application you signed in to (for example the Azure portal), the location and IP address, the device details, and whether it was single-factor or multifactor. The Conditional Access tab most likely reads Not Applied, because no policy exists. If a policy did exist, this is where its decision (grant, block or require MFA) would be recorded. 5. Read the sign-in methods registered to your account, and add or remove none. For a work or school account, open https://mysignins.microsoft.com/security-info; for a personal Microsoft account, open https://account.microsoft.com/security and its advanced security options. Write down each method listed and sort it: something you know (a password or PIN), something you have (the Microsoft Authenticator app, a phone number, a security key) or something you are (a face or fingerprint through Windows Hello). Two methods of the same kind are still one factor. 6. Count the guest users in your directory: outside people invited through B2B collaboration, who sign in with their own identities:
az ad user list --filter "userType eq 'Guest'" --query 'length(@)' -o tsv
On a new tenant this prints 0. Each guest would appear here with #EXT# in their name, and you would control what each can reach. 7. Match each scenario to one feature, then check the Notes: (a) staff sign in once each morning and open many apps with no further prompts; (b) a hospital's shared workstations, in wards where phones are not allowed, must sign in with no password; (c) a legacy app on Azure VMs needs domain join, group policy and Kerberos, with no domain controllers to run; (d) the company's own staff from on-premises Active Directory need the same identity in the cloud; (e) consultants from a partner firm need one SharePoint site, with no passwords issued to them; (f) require MFA only for sign-ins from outside the office network; (g) in rule (f), name which part is the signal and which part is the decision.
Verify
Read the kind of identity Cloud Shell used and your account's type in the directory.
az account show --query user.type -o tsv
Expected output: user.
az ad signed-in-user show --query userType -o tsv
Expected output: Member. If it prints Guest, you are working in someone else's directory as a guest: stop, and switch to your own subscription and tenant before any other lab.
Cost and clean-up
This lab only reads, so it creates nothing that can be charged. Microsoft Entra ID Free carries no charge; the premium licences that Conditional Access needs are paid, which is why this lab never starts a trial of one.
Created by this lab: nothing.
- There is nothing to delete: every step only read. Confirm on the security-info page from step 5 that the list of methods is exactly as you found it, close the portal pages you opened, and close Cloud Shell; the ephemeral session keeps nothing.
Check it is gone
Confirm that no lab resource group exists for this lesson:
az group list --query 'length([?starts_with(name, `"az900-lab10"`)])' -o tsv
Expected output: 0.
Notes
Answers to step 7: (a) single sign-on; (b) FIDO2 security keys, a passwordless method that needs no phone; (c) Microsoft Entra Domain Services; (d) Microsoft Entra Connect (or Cloud Sync); (e) Microsoft Entra External ID, B2B collaboration with guest users; (f) a Conditional Access policy; (g) the sign-in location is the signal, and require MFA is the decision.
The Sign-in logs path in the portal has moved more than once as Microsoft Entra ID's menus were reorganised. If you do not see it under Monitoring, search the portal for Sign-in logs.
This is an independent study companion for the Microsoft Azure Fundamentals (AZ-900) exam and is not produced by or endorsed by Microsoft. Microsoft, Azure and Microsoft Entra are trademarks of the Microsoft group of companies.
This is an independent study companion for Microsoft Azure Fundamentals AZ-900 and is not produced by or endorsed by CompTIA.