identity management
585 TopicsSCIM provisioning - custom app authentication
Hi, in the documentation for handling endpoint authentication, two methods are given: 1) a "long-lived token" (i.e. a secret key that has to be pasted in-clear by the admin) 2) "Microsoft Entra bearer token" - similar to other services (e.g. callbacks for MS Teams bots), Microsoft sign the outgoing calls, and the app being provisioned can validate them against Microsoft's public keys To me, option (2) is by far the best - each message is signed individually, there is no manual handling of secrets etc. As said in the documentation - "Apps that use Microsoft Entra ID as an identity provider can validate this Microsoft Entra ID-issued token." - great! So why on earth does it then say "The token generated by the Microsoft Entra ID should only be used for testing. It shouldn't be used in production environments."? Why not? The whole system of Entra bearer tokens is only for test? And production should go back to secret keys, with all the problems they have? It doesn't seem right.. What am I missing here?46Views7likes0CommentsNew role recommendation: Read Only Exchange Admin
To fully leverage PIM, we are transitioning to Entra roles wherever possible. We wish we could get off of customized Exchange RBAC roles, but the Exchange Recipient Admin role, lacks access to information like mail flow rules, which is essential for troubleshooting mail delivery issues. We would appreciate the introduction of a read-only role that allows viewing all information in Exchange without the ability to make changes.147Views0likes3CommentsMembers of a privileged access group cant validate dynamic group membership
Hi All, Does anyone know when this ability will be rolled out to members of a PAG with the group administrator role. Currently we are rolling out a PIM implementation using access packages to control PIM roles using privileged access groups using the least privileged model. Although this has worked well so far, we have an issue with admins who have the group administrator role via a PAG not being able to validate a dynamic group membership role. I know this feature is currently in preview, but was wondering if this is on Microsoft's roadmap to resolve it before it the preview is completed? As our admins use this feature a lot, we are currently having to assign this role as eligible to a user via PIM, which defeats the object of using the entitlement management access packages controlled via PAG's. Rgds Lee106Views0likes0CommentsEntraID account on Windows 11 being started under a TEMP user profile
I have a EntraID user on Windows 11 (Intune Managed). User is the "primary user". The user started experiencing login issues where "user name or password not recognized". Password was reset in EntraID. PC recognized the new password and allows the user to login BUT the account profile is mapped to C:\Users\TEMP and not to their normal C:\Users\<UserName> profile. How do I reconnect the user with their profile?260Views1like3CommentsDouble entries in userCertificate avoids Hybrid Join
Hey guys, I have an interesting situation at a customer. He utilizes a third party MFA provider while being on a federation. That means new computers never will have a registered state. For users it is mandatory that theirs clients have fulfilled the Hybrid Join to use M365 apps, what can be a real pain. So the Automatic-Device-Join task has to create the userCertificate on the OnPremises computer object, before it can be synchronized to Entra. Here comes the issue. In some cases we see that some computers will create two userCertificate entries. This situation will lead to an inconstistent Hybrid Join. I already tried to remove one of the certificates, but for me it is impossible to recognize which is the right one. Only solution for me was to remove both entries under userCertificate and let the Automatic-Device-Join task create a new one. Afterwards the Hybrid Join will work. I want to understand, which process or scenario might create the double userCertificate entries?209Views0likes1CommentID token issued by AAD doesn't match public signing key
Hi, I've encountered an issue that ID tokens (JWT) issued by AAD do not match a public signing key. This is my JWKS url:https://login.microsoftonline.com/1d063515-6cad-4195-9486-ea65df456faa/discovery/v2.0/keys However the ID token I receive has a unmatched kid like below { "typ": "JWT", "alg": "RS256", "kid": "ylQQc6jLgNEIt8AMAPm8jR27QCE" } It's been working fine until a couple of days ago. It is mentioned somewhere that AAD rotates public keys but it seems tokens might be persisted without knowledge that the signing key has changed. However access token match one of the keys like { "typ": "JWT", "nonce": "ExKWqBKO2TvzbusXVkALk0RQhka3YiNxEKQg69gs27Q", "alg": "RS256", "x5t": "huN95IvPfehq34GzBDZ1GXGirnM", "kid": "huN95IvPfehq34GzBDZ1GXGirnM" } Is this the expected behaviour? AAD is my IDP and AWS Cognito is the auth server in my set up. Because of this issue, Cognito is unable to verify signature of ID tokens therefore users can sign in but cannot proceed further because of this. Has anyone come across a similar issue before?18KViews0likes8CommentsNo Application Access Policy Found for Graph API in MS Teams Virtual Events Integration
Hello Microsoft Community, I’ve encountered an issue while integrating Microsoft Teams Virtual Events using Microsoft Graph API and would appreciate any guidance on how to resolve it. Here’s the setup: I have registered an application in Microsoft Entra ID. The app is set up with application-level permissions: VirtualEvent.Read.All VirtualEventRegistration-Anon.ReadWrite.All I’ve configured an OAuth flow for users to authenticate with their Microsoft accounts and grant these permissions. After authentication, the user is redirected to our app, where we successfully fetch an application access token. The app is registered as a multi-tenant application. The issue: We are using application permissions and receiving an access token correctly. The Entra ID dashboard shows that the app has been granted the required permissions. However, when using the Graph API to access virtual events (Teams webinars), I get the following error: bash Copy code GET: https://graph.microsoft.com/beta/solutions/virtualEvents/webinars/:id Response: { "error": { "code": "General", "message": "No application access policy found for the app (707b5896-7828-4010-834e-74d3201a3137) on the user (7f27a9fb-af1a-4d36-a102-3a9591e6aaf9).", "innerError": { "request-id": "00af9b4e-043c-4f93-8a02-a5ee14e7d29c", "date": "2024-10-02T09:10:26", "client-request-id": "00af9b4e-043c-4f93-8a02-a5ee14e7d29c" } } } Additional Details: The app is meant to access data related to Microsoft 365 services (especially Teams). We are using application permissions and not delegated permissions. The app needs to work across multiple tenants. My question: Do I need to configure additional application access policies for Microsoft Teams or Exchange Online to allow this app to access Teams-related data? Should I use Exchange PowerShell to create this policy, given the data is related to Microsoft 365 services (like Teams webinars)? Is there anything else I should verify for multi-tenant application permissions? Any insights or troubleshooting guidance would be much appreciated! Thank you!147Views0likes0CommentsNew Blog | The latest enhancements in Microsoft Authenticator
ByNitika Gupta Hi folks, I'm thrilled to announce three major Microsoft Entra ID advancements that will help you protect your users with phishing-resistant authentication: Public preview refresh:Device-bound passkey support in Microsoft Authenticator Public preview:Support for FIDO2 security keys on native brokered applications, such as Outlook and Teams, on Android 14 General availability:FIPS compliance for Microsoft Authenticator on Android These advancements are crucial, not only for adhering to theUS Executive Order 14028 on Improving the Nation's Cybersecurity, but also for safeguarding all organizations and users who rely on secure digital identities. Let’s dig deeper! Read the full post here:The latest enhancements in Microsoft Authenticator262Views0likes0CommentsIs it possible to disallow proxyAddress as Sign-In Identifier?
As part of a revised naming scheme for user accounts we're planning to roll out, I'd like to disallow Exchange Online email addresses and proxyAddresses from being used instead of the User Principal Name as an alternative identifier when users sign in to their accounts. This is supposed to strengthen security as users don't share one of the authentication factors with every email they send and the user names can't be easily guessed because they don't use the actual first or last name of the user behind them. This is the only Microsoft Learn article I found that was describing something similar: https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-use-email-signin Basically I want to do the opposite of what the article is describing and I'm not synching my users using Microsoft Entra Connect. I disabled the "Email as alternate login ID" option described in the article anyways but unsurprisingly, that didn't have the desired effect. Does anyone know if this is even possible and if so, how to do it? Thanks in advance! This is my first post in this community. If I did something wrong (like choosing the wrong label) please be kind, tell me, and I'm going to adapt my post.Solved314Views0likes2Comments