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.
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 enabledDisplay On-prem Password Policy on SSPR Page
Hi All We are beginning to rollout SSPR with on-prem writeback. So far so good. Is there a way we can display our on-prem password policy requirements on the SSPR screen? I have seen the MS docs, but can't really make any sense of them so any help would be greatly appreciated. SK
Enable MFA method
Dear, Currently in our company, the authentication methods policy > Microsoft Authenticator defaults to “any”. Either “passwordless” or “Push”. It is possible to enable the following authentication method through a conditional access policy, currently it is enabled for some users. Desired authentication method: The current method is as follows: Can it be enabled for professional accounts or is it only focused on personal accounts? Thanks in advance.
Configuring the OAuth2 Verification Method for the Forgotten Password Module In SSPR
Hello I am setting up OAuth2 on NETIQ SSPR for the Forgotten Password module, using Entra as the verification method. According to the SSPR documentation, Entra needs to support the following endpoint for proper functionality: "The remote OAuth server must support the non-standard /sign endpoint for this to work." However, when I registered the SSPR application on Entra, I couldn't find any information or documentation regarding the /sign endpoint. Could you please confirm if this endpoint is supported by Entra? Regards,Password recovery using alternative email address
Hi, I am in charge of a school, having one tenant. The tenant includes both staff and students. I have enabled Password reset (SSPR) for a selected security group (containing all staff) to use their mobile number to reset their Office 365 password. I logged in to Microsoft Entra, went on Manage > Password reset > Properties, Enabled it for 'Selected', selected the security group and selected Email and mobile phone. It works for all staff that are members of the selected security group. Now, I would like to enable SSPR for students using an alternative email address. All my students are grouped in one security group. So I went to Password Reset > Authentication Methods, clicked on Email OTP and enabled it for 1 group containing all my students. When I login to myaccount.microsoft.com and click on Security Info, when I click to add a sign-in method, I am NOT having 'Email' in the method pull-down menu: May I please ask what am I doing wrong? My objective is to have mobile phone for staff SSPR and email for students. Is it supported by Microsoft in the first place? Please help ThanksUnable to disable SSPR for Administrators
According to this link I can disable SSPR for Administrators. https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sspr-policy?WT.mc_id=Portal-Microsoft_AAD_IAM#administrator-reset-policy-differences However, upon attempting to do so I am met with the following error. S C:\Windows\System32> Update-MgPolicyAuthorizationPolicy -AllowedToUseSspr:$false Update-MgPolicyAuthorizationPolicy_UpdateExpanded: Insufficient privileges to complete the operation. Status: 403 (Forbidden) ErrorCode: Authorization_RequestDenied Date: 2024-07-22T16:28:11Self Service Password Reset without being forced to have MFA enabled
We have enrolled MFA for parts of our company (Guests, IT department, parts of the administration) so far and are slowly pushing forward. MFA is controlled by a Conditional Access policy where users or groups are added manually. At the same time we are currently implementing SSPR for our company. SSPR is set to "selected" and not to "all". That means we have a group where we add users to get SSPR enabled for them. This is how it is set up: If we enable SSPR for a user that has not being enabled for MFA by conditional access yet then this user is facing issues to set up his Self Service Password Reset questions. He is forced to register MFA what we do not want at this point (that is why we have not added him to the MFA Conditional Access policy at this point). Is there a way to make the users register SSPR for their account but not being forced to register MFA yet? Is it even possible to enable SSPR without MFA? We know that MFA is highly recommended. We are working on the full rollout. But there are users that are not ready yet. This is what the user is facing when SSPR is enabled for him but MFA is not yet enforced by conditional access: Says: Protect your account. Microsoft Authenticator. Get the app first.
How to correctly implement Entra ID Connect sync when users exists in Entra ID as cloud users?
Hi Everyone, I have a small on-premises exchange server 2016 setup which we're planning to make Hybrid. We do have a O365 environment (Business Standard Licensed) which is independent as users signed in for Teams and SharePoint Online usage. We now have to implement Entra ID Connect (Azure AD Connect) to facilitate Exchange Hybrid deployment. My questions are: 1. These users currently exists in Entra ID as cloud accounts (as they've been using Cloud Apps such as Teams, SPO with their Windows 10 joined to Entra ID) will there be any issues when sync is configured ? (i.e. duplicate of identity errors etc..) 2. What's the best approach to implement Entra ID Connect and sync these user from AD to Engtra ID without having to remove these accounts from Entra ID? Any inputs are highly appreciated ! Thank you!
