Applications registered through AAD (https://learn.microsoft.com/en-us/azure/active-directory/active-directory-app-registration) are provisioned a client id and secret to access Azure resources via the MS Graph REST API using an Oauth flow.
There are currently no logs for these calls being emitted to the AAD sign-in or audit logs. I am not currently aware of any endpoint where I can obtain these external calls.
This means that if a client secret was ever leaked, I have no way to identify that there are calls being made.
I would like to see activities related to registered application/service principal:
• Event that shows when users register/change/remove AAD applications
• AAD application authentication events
As a POC, I have tried registering an application from App registration module and tried creating client ID and Secret but did not find any relevant audit logs for it.
To access the audit report, you should be the Security Admininistrator, Security Reader or Global Administrator roles.
All users (non-administrators) can only see their own audit activities. You could read this doc to know the details.
In my audit logs, I could get all the changes like the following:
About Sign-in activity reports. The sign-in user should be the Security Administrator, Security Reader, Report Reader role, or Global Administrator.
Any user (non-admins) can only access their own sign-ins. And your tenant must have an Azure AD Premium license associated with it. For the details, please read here.
And the information about the sign-in likes this:
Note: The sign-ins report only displays the interactive sign-ins, that
is, sign-ins where a user manually signs in using their username and
password. Non-interactive sign-ins, such as service-to-service
authentication, are not displayed in the sign-ins report.
Related
I have created an Azure AD app registration for a cross-platform (Xamarin.Forms) mobile application for our employees. The app registration is setup to work as a single-tenant app and in order to function properly, we have specified a number of permissions to Microsoft Graph, such as "openid", "profile", and "User.Read", which have been given admin consent by our Admin. The app uses broker authentication (using ADAL) in order to sign-in users to the app via the Intune Company Portal app already installed and setup on every user's device.
Up until recently, everything worked fine until we needed to add a new Microsoft Graph permission to the app registration, namely "Group.Read.All". So, we added the new permission to our app registration as a delegated permission and had our admin provide the admin consent for all the users.
After giving consent to the new permission, our users could not login to the app since the Intune Company Portal app did not sign-in the users to the app, but instead advised them to setup their device by installing and setting up the Intune Company Portal app on their device (?!).
As I mentioned before, the devices already had Intune Company Portal installed and properly setup on their device for more than 2 years now.
So, we thought of checking the user sign-ins of the user to find out what the problem was and we found a failure event recorded with sign-in error code 530003 (Access has been blocked due to conditional access policies.) where it showed that the policy "Access Policy: Require Device Enrollment for Accessing EOL & Sharepoint from handheld devices" failed with reason "require compliant device" (under column Grant Controls).
As soon as we revoked the newly added permission "Group.Read.All" from the app registration, our users could sign-in to the app successfully.
When we tried adding other permissions like Directory.Read.All and GroupMember.Read.All, we did not have any issues with our sign-in flow via the Intune Company Portal.
Can you please advise what it is so special about the "Group.Read.All" permission that raises the Azure sign-in error code 530003, forcing the Intune Company Portal app to require the users to setup their (already setup) device, before they can sign-in to our app?
I am at my wits' end with this one.
Any ideas?
For me it is not possible to reproduce your issue due to multiple things involved.
Few suggestions that you could try at your end:
Try isolate each component and leverage graph explorer/postman to make an API call and observe behavior.
I didn't get the need to add graph permission, but as per your use case see if there is any other least privileged permission that could get your job done, add that permission and check behavior.
Check if your scenario really demanded adding permission as delegated and if this is really supported? For e.g, below image shows necessary permssion to get the properties and relationships of a group object.
If problem still persists, consider contacting Microsoft support for your specific scenario.
we are using UIPath within our company for RPA. We tried setting up UIpath to send mail on behalf of other users. We followed this guide: https://docs.uipath.com/marketplace/docs/microsoft-office-365-setup
There are 2 odd things to this setup:
We HAVE to make the App Registration a "Public Client" in Azure. To my knowledge, normally this applies to frontend web applications where the app secret cannot be kept hidden. This is a backend process, so I think there is no reason of having to use a public client. Am I right in this statement? What are the downsides of having a public client? Anyone possessing the client_id can impersonate this app registration? (can act as this app registration and ask users for credentials and get a token on behalf of this app?)
I added some api permissions to the App Registration like mail.read, mail.send, etc. It stated that no "Admin consent required", but it didnt work. After I pressed the "admin consent" button it said that it granted those permissions and the configuration seemed to work. What does this ADMIN CONSENT button do? If I add permissions to an App Registration, do I always have to press admin consent?
Some extra clarification about the public credentials:
-I register an application called App-X, which is set to public.
-Normally, without a public client, when I request a token, I need both the client_id and the client_secret. By using the client_secret, microsoft knows that I am indeed really the application App-X who is requesting this token on behalf of the user.
-Without using client_secret, anyone who knows the client_id, can request consent from a user and say "I am App-X and I am asking for permissions", while in fact they are not App-X (just some random someone who finds the client_id). After the user consented, because "he knows App-X and he trusts it", then the malicious user/app can also request a token from microsoft because he only needs a client_id.
1.This is a backend process, so I think there is no reason of having to
use a public client. Am I right in this statement? What are the
downsides of having a public client? Anyone possessing the client_id
can impersonate this app registration? (can act as this app
registration and ask users for credentials and get a token on behalf
of this app?)
It depends on your application type. "Public client" is usually used to configure mobile and desktop client applications. Since UIPath is a mobile application that monitors the RPA environment, for your application registration, you need to choose to use "Public Client" registration.
If you don’t want your application to be used by users of other organizations, you don’t need to register the application as a multi-tenant application when you register your application. If your application needs to be used by multiple organizations, you need to register the application as Multi-tenant application. In this case, in theory, all tenants can use this application. However, you can verify which tenant the logged-in user comes from when logging in, and you can prevent tenants that you do not want to log in from logging in. Please see:here.
2.What does this ADMIN CONSENT button do? If I add permissions to an App Registration, do I always have to press admin consent?
Each application registers permissions it requires. Some permissions can be granted by users, some other only by the administrator.
Let's suppose you have only permissions that can be consented by users. The first time they use the application, they'll be prompted (each user) to consent those permissions to the application. If in the same scenario you click on grant admin consent, it is the equivalent of accepting it for all users on the tenant.
Now let's suppose the application registers permissions that require admin consent, you have no choice but to click that button if you want the application to work and be able to request tokens.
For those permissions that require the administrator’s consent, you You can go to Azure portal>App registrations>API permissions>Admin consent required to view .
Not sure how to go about the following scenario:
User logs in with SAML using in an Azure enterprise configured application.
User authenticated succesfully.
If user now logs out from Azure -> I can catch this event using the logout url.
However if the user is deleted / removed from the organisation the user is still logged in in my application.
I've implemented similar logic with Oauth and refresh tokens, didn't find an equivalent using SAML.
As of now there is no support in SAML for the user provisioning events performed by the Idp.
In Azure enterprise configured application there is feature for Automate user provisioning and deprovisioning to applications which ensure that the identities in your app and systems are kept up to date based on changes in the directory or your human resources system.
For more information you can refer this link
We used Azure AD to setup an app which allows gives trust/permissions to an MSGraph Office account. The permissions were not setup to allow the code to programmatically send a email on the users behalf when they sign up.
Some beta users started using the service. Then after some time we changed the permissions in Azure AD to give permissions to allow to send emails on behalf of the user.
Since then new users can send emails, but beta and older users still have not got these permissions. The token expiration I believe is set to 3 days and its been a lot longer than that. Is there a way to force the permissions to propagate to all users?
If not, is there somewhere where beta users can unsubscribe from the app (kind of like you can with playstore apps) and then reassign permissions when they login again?
I would expect this to have already occurred but, if it's taking too long, you can force the user to re-consent to the permision by adding prompt=consent to your inital OAuth URI:
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?{parmas}&prompt=consent
I am developing a multi-tenant Office 365 daemon that requires access to user calendars.
I have successfully registered in the company tenant (Tenant1) that has deployed this app using certificates and I am able to get access tokens.
Now I created a separate AAD tenant (Tenant 2) and logged in to daemon app using administrator account of Tenant 2, it prompted the Admin Consent screen and I provided consent. There was no errors returned.
When I tried to get an app token however, I am able to get a token but with blank permissions. If I call the Office 365 API using this token, I get a 401.
I was of the view that service principal objects should be created. Also I am unable to see this app in Tenant 2 app registrations.
Do all my consumers have to register this app manually in their AD tenant and modify application manifest file to add certificate details?
I am not sure about the benefit of multi tenancy if that's the case.
I found the follow in the Azure Active Directory documentation:
The following diagram illustrates the relationship between an application's application object and corresponding service principal objects, in the context of a sample multi-tenant application called HR app. There are three Azure AD tenants in this scenario:
Adatum - the tenant used by the company that developed the HR app
Contoso - the tenant used by the Contoso organization, which is a consumer of the HR app
Fabrikam - the tenant used by the Fabrikam organization, which also consumes the HR app
You do not need to have each tenant register your application. In fact, you shouldn't since having dozens (or hundreds) of unique App IDs floating around would only create headaches for you.
Each tenant does however need to execute the Admin Consent workflow. This will authorize the App ID you've registered on your end to access the scopes you've requested.
Generally, I recommend using the v2 Endpoint and the apps.dev.microsoft.com portal for registering your app. While you can also register your app in your own Active Directory, the portal makes it a lot easier to manage.
The general process is:
Register you application in the Registration Portal
Populate the "Application Permissions" in the Microsoft Graph Permissions section.
Launch the Admin Consent workload using https://login.microsoftonline.com/common/adminconsent?client_id=[APPLICATION ID]&redirect_uri=[REDIRECT URI]
Get a beer
A couple of tips:
The Registration Portal only supports MSA (i.e. personal) accounts at the moment. I'd suggest creating a new Outlook.com account for this purpose so you can easily share the credentials with folks who need them internally.
If you create a shared Outlook.com account, you should also set up forwarding rules for all of the interested parties internally. This is in case something should every go wrong or change down the road and you need to recover the account.
I wrote a v2 Endpoint and Admin Consent primer that you might find helpful. They assume you're using the Authorization Code flow but the concepts remain the same for Client Credentials.