We are not able to caputre User sign_In details, when user try to use "Login with OTP" in AAD >Sign-In Logs.
According to [!NOTE] in azure-docs/view-audit-logs.md at master ยท MicrosoftDocs/azure-docs (github.com)
You wont be able to see user sign-ins for individual Azure AD B2C applications
under the Users section of the Azure Active Directory or Azure AD B2C
pages in the Azure portal. The sign-in activity over there show user
activity, but can't be correlated back to the B2C application that the
user signed in to. You must use the audit logs to see the sig-in
activity for that.
Sign-in logs
Audit logs:
And we need to note that Audit log events are retained only for seven days.
Reference:
signup-signin-with-phone-number - azure-ad-b2c/samples (github.com)
Related
I have web app which implements Azure AD sign in for authentication. After authenticating user with the help of Microsoft Graph I grab few details like email of the user and then look for user in my database.
The problem is, lets say the user gets authenticated in Azure AD account but the email is not present in database. In that case I want when user again try to authenticate then Sign in page by azure should be showed again.
We have an application which parses the Audit Logs emitted by Azure AD. More specifically we are parsing the 'Update application' log to detect when a new Role has been added to an Application (see example below).
We would like to find out more information about the "DirectAccessGrantTypes" and "ImpersonationAccessGrantTypes" fields. If someone can point us to documentation for this that would be great.
[{"EntitlementEncodingVersion":2,"EntitlementId":"654a4f1f-1b7f-4354-a6d6-fcf7346af0ec","IsDisabled":true,"Origin":0,"Name":"Data Manager","Description":"Manager for test app","Definition":null,"ClaimValue":"DataManager","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[20],"ImpersonationAccessGrantTypes":[],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]},{"EntitlementEncodingVersion":2,"EntitlementId":"3d03256d-cf0c-4553-b8af-98d7ebbee1f2","IsDisabled":false,"Origin":0,"Name":"Application Manager","Description":"Admin for test app","Definition":null,"ClaimValue":"ApplicationManager","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[20],"ImpersonationAccessGrantTypes":[],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]},{"EntitlementEncodingVersion":2,"EntitlementId":"88d0d3e3-b661-4760-aea3-f4548db1ff96","IsDisabled":false,"Origin":0,"Name":"Read","Description":"Allow users to add a admin consent","Definition":null,"ClaimValue":"Read","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[],"ImpersonationAccessGrantTypes":[{"Impersonator":29,"Impersonated":20}],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]}]
From article > View reports & logs in entitlement management - Azure AD | Microsoft Docs
When Azure AD receives a new request, it writes an audit record, in
which the Category is EntitlementManagement and the Activity is
typically User requests access package assignment. In the case of a
direct assignment created in the Azure portal, the Activity field of
the audit record is Administrator directly assigns user to access package, and the user performing the assignment is identified by the
ActorUserPrincipalName.
Application Impersonation is basically an administrator-managed, not user-managed permission.
Impersonate access grants logs gives information ex:count., of users given consent by the admin to access the application to impersonate user.
ImpersonationAccessGrantTypes gives count or info of access grants by admin on behalf of user whereas DirectAccessGrantTypes gives info about the users who directly access the application ,as they are already assigned by admin.
Reference:
Multiple Client applications authorisation to WebApi (microsoft.com)
On guest user login on redirect URI I got an error:
AADSTS1000031: Application {App name} cannot be accessed at this time. Contact your administrator.
I'm using multi-tenant approach. The authorization URL looks good and it redirects me with such an error.
But I can't find any description of the error or configuration in the azure related to this error.
Also, "normal" users can log in without any issues.
I have such configuration in my Azure App:
Could you please advise how can I enable guest accounts support here?
This error can occur if you have not granted admin consent.
Go to Azure Active Directory within the Azure portal.
Go to Application registrations.
Select the Application based on the App-Id.
Go to API Permissions.
Click Grant Admin consent.
https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/grant-admin-consent
Has this SSO been setup as an Enterprise application?
Or are you just trying to get a guest user logged in to your tenancy as a guest?
If it is the later just create a new Guest user within your tenancy, make sure you have the rights to to do this first.
Then have the guest user accept the email invitation they receive.
Confirm within Azure they have accepted the invite.
Also make sure they are using the same email address as the invite was sent to and not an alias, which can cause confusion.
I have a Desktop application using ADAL to authenticate to a multi-tenanted Azure AD v1 application.
Version 1 of my application only required delegated permissions that didn't require Admin consent:
Microsoft Graph - sign in and read user profile
Skype for Business online - Create skype meetings
Version 2 now requires an additional permission, which requires Admin consent:
Microsoft Graph - Access directory as the signed in user
I've updated the Azure AD app with this permission, and granted admin consent through the Azure AD portal using an admin user homed in the same tenant as the application.
Signing in as a non-admin user who had already consented to the Version 1 permission set (also homed in the same tenant as the application), I don't see the new permission in the "scp" property of the access token I receive - so I'm assuming this means I haven't been given the new permission.
I then try and re-consent as the user, using "prompt=consent", but receive
AADSTS90094: The grant requires admin permission
Implying that admin consent has not been set - although the portal is reporting that it has been set.
From all that i've read, it looks like this should work just fine, so I'm struggling to see what's going wrong. How can I get this working?
I think this is a configuration issue. First, check that your permission type is following the 'as an application' flow.
The clue here is how you described your permission: " Access directory as the signed in user"
That sounds to me like the 'on behalf of' flow, not the 'as an application' flow.
When I log onto the Microsoft Graph Explorer with my Microsoft account and run the following query https://graph.microsoft.com/v1.0/users/ I get the correct user returned.
On Azure AD (using the same login) I created an application with a key and when I sign in through c# using Microsoft.IdentityModel.Clients.ActiveDirectory.ClientCredentials with a token for resource https://graph.microsoft.com and run the same query I get a completely different user. They are out of sync and I'm baffled.
Any ideas? Should I create a new Azure account as I've had the Azure account from day 1 and I'm only doing this now to test for a client request.
Don't create a new Azure account. When you are using Graph Explorer, are you signed in with a user from your Azure AD tenant? If not, Graph Explorer will default to use a demo tenant for your queries.
Also (if you have more than one tenant) you need to make sure that you select the correct tenant as part of the token acquisition (from https://login.microsoftonline.com/{tenantId | tenantDomain}. If you want the results to match between Graph Explorer and your app, the tenant the signed-in user belongs to (for Graph Explorer case) and the tenant used by your app needs to be the same.
UPDATE based on comment below:
I think I know what's going on here. In graph explorer, you are signing in with your personal account - and it's showing you profile data of that personal account, including the unique ID for this account in the Microsoft Account system. In this case you aren't signing into an Azure AD tenant at all. Microsoft Graph supports access from both personal and commercial accounts.
Now, additionally, I'm guessing when you signed up for an Azure subscription, you used this personal account. When you do that, it creates an Azure AD tenant, and creates a guest user in that tenant that is (linked to) your personal account - this account is also configured as an admin account. This mechanism allows you to sign in with your personal account (authenticated by the Microsoft Account system) into an Azure AD tenant, because the personal account maps to this guest user in your tenant. In your application, you are getting an app token to your Azure AD tenant. When you query the tenant for users, you don't see any user with the same id or email address as you did with graph explorer. However if you actually look at the userPrincipalName, you'll see it should be a mangled form of the original email address of your personal account. This indicates that this Azure AD user account in your tenant is a guest/external user (similar to a foreign principal).
Hope this helps,