Forum Widgets
Latest Discussions
Understand Why a Service Principal Was Created in Your Entra Tenant
Are you a tenant admin or member of a security team in your organization and find yourself asking “Why was this service principal created in our tenant?” Historically, answering this required correlating audit logs with Microsoft Graph queries or going through long investigations. Microsoft Entra now introduces enhanced audit log properties that make it significantly easier to understand the origin and intent behind newly created service principals directly from tenant audit logs. These new improvements surface additional insights within the Add service principal activity under the ApplicationManagement category—helping administrators determine whether a service principal was provisioned automatically by Microsoft services, triggered by a purchased subscription, or explicitly created by user or application activity. What’s in it for me as an Admins or member of the Security Team When a service principal is created, new metadata is now captured within Microsoft Entra audit logs that enables faster root‑cause analysis. These properties help distinguish between Microsoft‑driven provisioning processes and tenant‑initiated actions, allowing teams to quickly assess whether an event is expected platform behavior or something requiring deeper investigation. For example, administrators can now: Identify provisioning initiated by Microsoft services versus internal users or automation. Determine which tenant subscription or service plan enabled just‑in‑time provisioning. Recognize provisioning linked to Azure resource onboarding or managed identities. Investigate service principal creation without relying on additional Graph lookups. By leveraging these enriched audit logs, security teams can streamline investigations into newly created enterprise applications and reduce manual dependency on downstream data sources. This ultimately improves visibility into application onboarding events and supports faster decision‑making when assessing potential risk or unexpected provisioning activity within the tenant. Learn more here- Understand why a service principal was created in your tenant - Microsoft Entra ID | Microsoft Learn
Disabling PIN-based login on Entra-joined PCs
Hi guys. Yesterday I took two machines off the domain and Entra joined them. The goal was 1) remove their access to domain resources 2) have tenant users login to the machine and get enriched tokens every time. this works as desired. The problem is every user gets prompted to set a pin. these are both shared secondary/tertiary PC's - there is no point to having a 6 digit PIN on them. I thought the new Authentication Methods tools had controls for this, but apparently not. A script was run to change certain related Reg Keys (by my onsite tech) but this had no change on reboot. textreg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PassportForWork" /v Enabled /t REG_DWORD /d 0 /freg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PassportForWork" /v DisablePostLogonProvisioning /t REG_DWORD /d 1 /f HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PassportForWork Enabled key was set to 0, and DisablePostLogonProvisioning was set to 1. These are from various help threads I found here and other resources. Unfortunately, they do not work. Not sure what to do here. I've read there are InTune controls for this - but I don't really have the time to work out WindowsPC ennrollment profiles for 2 machines. The site has InTune, but only for iOS mobile management. Thoughts?Report suspicious activity (Preview)
Allows users to report suspicious activities if they receive an authentication request that they did not initiate. This control is available when using the Microsoft Authenticator app and voice calls. Reporting suspicious activity will set the user's risk to high. If the user is subject to risk-based Conditional Access policies, they may be blocked.
Entra CBA Preview Bug: Issuer Scoping Policy fails group claim (AADSTS500191)
I am deploying a zero-trust, cloud-native Certificate-Based Authentication (CBA) architecture for a break-glass emergency access account in Microsoft Entra ID. I am intentionally bypassing Intune/MDM to prevent circular dependencies during an outage. The PKI is generated via OpenSSL (Offline Root CA -> Client Cert). The cryptography is flawless: - The OpenSSL chain verifies perfectly (openssl verify -CAfile...). - The Root SKI and Client AKI are a perfect 1:1 hex match. - The client cert EKU includes TLS Web Client Authentication. - The client cert SAN includes othername: UPN::[break-glass-UPN]. - The Root CA and CRL are uploaded to Entra and publicly accessible via Azure Blob Storage. The Issue: When I attempt to restrict the Root CA using the "Certificate issuer scoping policy (Preview)" targeted to a specific Security Group (e.g., sg_cba), the TLS handshake drops and Entra throws: Error: AADSTS500191: The certificate authority that issued your certificate has not been set up in the tenant. Troubleshooting Performed: 1. Group Architecture: Verified via Microsoft Graph that the user is a direct, static member of sg_cba (Security Enabled, non-dynamic, not nested). 2. Micro-Group Bypass: Created a brand-new cloud-only micro-group with only the break-glass user. Waited for replication. Same 500191 error. 3. The Control Test (Success): If I completely remove the Preview scoping policy and move the targeting to the Generally Available (GA) tenant-wide trust ("All Users"), the login succeeds immediately. (I am securing this via High-Affinity binding matching the SKI to CertificateUserIDs). The Ask: Because the tenant-wide GA policy works perfectly, it mathematically proves the certificates, CRL, and bindings are correct. The failure is entirely isolated to the Preview scoping engine failing to correlate the incoming certificate to the Security Group claim fast enough. - Has anyone successfully deployed the "Certificate issuer scoping policy (Preview)" using a targeted security group without it dropping the trust? - Are there undocumented constraints on group evaluation during the CBA TLS handshake that cause this Preview feature to fail closed?
Introducing the Entra Helpdesk Portal: A Zero-Trust, Dockerized ITSM Interface for Tier 1 Support
Hello everyone, If you manage identity in Microsoft Entra ID at an enterprise scale, you know the struggle: delegating day-to-day operational tasks (like password resets, session revocations, and MFA management) to Tier 1 and Tier 2 support staff is inherently risky. The native Azure/Entra portal is incredibly powerful, but it’s complex and lacks mandatory ITSM enforcement. Giving a helpdesk technician the "Helpdesk Administrator" role grants them access to a portal where a single misclick can cause a major headache. To solve this, I’ve developed the Entra Helpdesk Portal (Community Edition)—an open-source, containerized application designed to act as an isolated "airlock" between your support team and your Entra ID tenant. Why This Adds Value to Your Tenant Instead of having technicians log into the Azure portal, they log into this clean, Material Design web interface. It leverages a backend Service Principal (using MSAL and the Graph API) to execute commands on their behalf. Strict Zero Trust: Logging in via Microsoft SSO isn’t enough. The app intercepts the token and checks the user’s UPN against a hardcoded ALLOWED_ADMINS whitelist in your Docker environment file. Mandatory ITSM Ticketing: You cannot enforce ticketing in the native Azure Portal. In this app, every write action prompts a modal requiring a valid ticket number (e.g., INC-123456). Local Audit Logging: All actions, along with the actor, timestamp, and ticket number, are written to an immutable local SQLite database (audit.db) inside the container volume. Performance: Heavy Graph API reads are cached in-memory with a Time-To-Live (TTL) and smart invalidation. Searching for users or loading Enterprise Apps takes milliseconds. What Can It Do? Identity Lifecycle: Create users, auto-generate secure 16-character passwords, revoke sign-in sessions, reset passwords, and delete specific MFA methods to force re-registration. Diagnostics: View a user's last 5 sign-in logs, translating Microsoft error codes into plain English. Group Management: Add/remove members to Security and M365 groups. App/SPN Management: Lazy-load raw requiredResourceAccess Graph API payloads to audit app permissions, and instantly rotate client secrets. Universal Restore: Paste the Object ID of any soft-deleted item into the Recycle Bin tab to instantly resurrect it. How Easy Is It to Setup? I wanted this to be universally deployable, so I compiled it as a multi-architecture Docker image (linux/amd64 and linux/arm64). It will run on a massive Windows Server or a simple Raspberry Pi. Setup takes less than 5 minutes: Create an App Registration in Entra ID and grant it the necessary Graph API Application Permissions (e.g., User.ReadWrite.All, AuditLog.Read.All). Create a docker-compose.yml file. Define your feature toggles. You can literally turn off features (like User Deletion) by setting an environment variable to false. version: '3.8' services: helpdesk-portal: image: jahmed22/entra-helpdesk:latest container_name: entra_helpdesk restart: unless-stopped ports: - "8000:8000" environment: # CORE IDENTITY - TENANT_ID=your_tenant_id_here - CLIENT_ID=your_client_id_here - CLIENT_SECRET=your_client_secret_here - BASE_URL=https://entradesk.jahmed.cloud - ALLOWED_ADMINS=email address removed for privacy reasons # CUSTOMIZATION & FEATURE FLAGS - APP_NAME=Entra Help Desk - ENABLE_PASSWORD_RESET=true - ENABLE_MFA_MANAGEMENT=true - ENABLE_USER_DELETION=false - ENABLE_GROUP_MANAGEMENT=true - ENABLE_APP_MANAGEMENT=true volumes: - entra_helpdesk_data:/app/static/uploads - entra_helpdesk_db:/app volumes: entra_helpdesk_data: entra_helpdesk_db: 4.Run docker compose up -d and you are done! I built this to give back to the community and help secure our Tier 1 operations. If you are interested in testing it out in your dev tenants or want to see the full architecture breakdown, you can read the complete documentation on my website here I’d love to hear your thoughts, feedback, or any feature requests you might have!
'Microsoft App Access Panel' and Conditional Access with SSPR combined registration bug
Currently, enabling self-service password reset (SSPR) registration enforcement causes the app 'Microsoft App Access Panel' to be added to the login flow of users who have SSPR enabled. This app is not able to be excluded from Conditional Access (CA) polices and is caught by 'All cloud apps', which breaks secure zero-trust scenarios and CA policy configurations. Best way to demonstrate this is through examples... ----Example 1---- Environment: CA Policy 1 - 'All cloud apps' requiring hybrid/compliant device, but excluding [App] (for all non-guest accounts) CA Policy 2 - [App] requiring MFA only (for contractor accounts, etc) CA Policy 3 - [App] requiring hybrid/compliant device (for internal accounts, etc) SSPR registration enforcement (Password reset > Registration) - set to 'Yes' MFA registration enforcement (Security > Authentication Methods > Registration campaign) - set to 'Enabled' Scenario: A new user requires access to web [App] on an unenrolled device and is assigned an account that falls under CA Policy 1 and 2, however [App] is excluded from 1 and shouldn't apply to this login. When accessing [App] for the first time, users must register SSPR/MFA. They see the below message, click 'Next' and are directed to https://accounts.activedirectory.windowsazure.com/passwordreset/register.aspx: Then they see this screen, which will block the login and try to get the user to download the Company Portal app: While behind the scenes, the login to [App] is being blocked by 'Microsoft App Access Panel' because it is seemingly added to the login flow and caught in CA Policy 1 in Req 2/3: CA Policy 1 shows as not applied on Req 1, CA Policy 2 shows as successful for Req 1/2/3 and CA Policy 3 shows as not applied for Req 1/2/3. Creating a CA policy for the 'Register security information' user action has no effect on this scenario and also shows as not applied on all the related sign-in logs. ----Example 2---- Environment: Same as above, but SSPR registration enforcement - set to 'No' Scenario: Same as above, but when accessing the [App] for the first time, they see the below message instead, click 'Next' and are directed to https://accounts.activedirectory.windowsazure.com/proofup.aspx: Then they are directed to the combined SSPR/MFA registration experience successfully: The 'Microsoft App Access Panel' doesn't show in the sign-in logs and the sign-in is successful after registration. From the two examples, it seems to be a bug with the SSPR registration enforcement and the combined registration experience. ----Workarounds---- 1 - Prevent using 'All cloud apps' with device based CA policies (difficult, requires redesigning/thinking/testing policies, could introduce new gaps, etc) 2 - Turn off SSPR registration enforcement and turn on MFA registration enforcement like in example 2 (easy, but only enforces MS MFA App registration, doesn't seem to re-trigger registration if the MS MFA App is removed, no other methods are supported for registration, and doesn't remind users to update) 3 - Disable SSPR entirely for affected users (medium depending on available security groups, and doesn't allow for affected users to use SSPR) ----Related links---- https://feedback.azure.com/d365community/idea/d5253b08-d076-ed11-a81b-000d3adb7ffd https://feedback.azure.com/d365community/idea/1365df89-c625-ec11-b6e6-000d3a4f0789 Conditional Access Policies, Guest Access and the "Microsoft Invitation Acceptance Portal" - Microsoft Community Hub MS, please either: 1 - Allow 'Microsoft App Access Panel' to be added to CA policies so it can be excluded 2 - Prevent 'Microsoft App Access Panel' from showing up in the CA login flow when SSPR registration enforcement is enabled
Entra ID Private Access - data flow
Hello, I am successfully testing Entra Private Access. From outside, I can easily access my shared permissions. However, I have one more question. What happens if I my device on the internal network? If I access the shares directly, I get about 1GB/s. What happens if the "Global Secure Access" client is active? Do all the data go through the Entra portal, or just the authentication? If all the data go through the Entra portal, there could be challenges with the internet connection (all data in and out). Thank you for your support StefanPIM
Hello, everyone. I need some help. We already use PIM for Just-in-Time activation of administrative functions in Entra ID, but we would like something more granular. For example, we want certain administrative actions in Microsoft 365, such as accessing sensitive data or performing critical tasks, to only be possible upon specific request and approval, even if the user has already activated the function in PIM. Is this only possible with PIM, or is there another feature in Microsoft 365 for this type of control?
Challenges with custom data provided resource reviews
I was thrilled to see the ability to review disconnected applications in Entra, and even more thrilled to see that the permission and its description are available to the reviewer, which addresses a significant gap present in group-based reviews. However, the current decision-tracking approach does not adequately replicate the closed-loop remediation model typically found in traditional IGA access reviews for integrated applications. Requiring reviewers to upload confirmation that revocations have been completed is problematic. This approach does not mitigate the core risk: access may remain in place due to fulfillment errors or be incorrectly retained, and the reviewer may unknowingly validate an inaccurate state. This can lead to a compliance incident or audit finding. A more effective solution would allow reviewers to upload a current export of access data, enabling the review system to reconcile intended revocations against the actual state. Any discrepancies could then be flagged for remediation where revocations were missed or have failed, or for validation where access was revoked and immediately reinstated (e.g., due to reviewer misjudgement), ideally supported by corresponding ticketing or justification. There are currently a lot of gaps in Entra ID access reviews, and while this new feature arguably resolved the worst one, I think it's headed down the wrong path. I am curious about other people's thoughts.
