In my current environment in azure we are using azure graphapi mostly, for that we want to know who is doing what like logging of each request, when ever any request via graph api is there is option to see what data they access in azure portal?
Or logs for service principle also when ever any one logs in using service principle we wanted to know what actions they are doing.
I think the log reports in the portal currently could not fully meet your requirements.
Navigate to the Azure Active Directory in the portal -> Enterprise applications -> find the service principal you want -> in Sign-ins, you could check the login information.
In this blade, you can just get the login information, the Resource is Microsoft Graph, but you could not know what actions they are doing via Microsoft Graph.
To check what actions the users are doing in the AAD tenant, navigate to the Azure Active Directory -> Audit logs, you can check the users' actions, but you could not know if they did these things via Microsoft Graph/AAD Graph or not.
For more details, see Sign-in logs and Audit logs.
Related
I'm trying to publish a developer portal for our APIM instance for the first time, but most of the APIs in our APIM are for internal use only and I don't want them in the developer portal. Is there an easy way to pick which APIs show up in the developer portal?
API visibility is controlled through products and groups. You can assign user groups to a product to expose it and its APIs to users of that group. Most likely right now you see all APIs since you act as an admin. Try logging into dev portal as a normal user.
I know that to track user sign-ins I need to go to Active Directory -> (under Activity) Sign-ins, and have the necessary "Azure Active Directory Premium 2" subscription.
I am trying to find the equivalent for sign-ins via an access key of a given application created via app registrations.
Where can I see this in the Azure Portal? Bonus question: where is it available in the SDK or API?
From Azure portal,
Go to App registrations -> filter listed application by app Id (access key) or name.
Which lead you to application blade,
Click on Managed application in local directory, which show you sign-ins option for this application
If you want to access your active directory application by API, Office Graph can help.
Please see this document: https://learn.microsoft.com/en-us/azure/active-directory/active-directory-reporting-activity-sign-ins
Do you have a Premium subscription? If you do not, you will not be able to see these logs.
I have some Azure Functions that I share to my partner companies who then run the Azure Functions in their own Azure subscriptions.
Occasionally the partners run into issues and reach out to me for help. I have to instruct them to manually pull the Azure Function logs and send to me via email.
Is there anyway they can grant me permission to pull the logs from their Azure Subscription?
It depends on where you have the logs.
Either way, they can grant you RBAC permission to their resource in their subscription. Generally, they have read only access options available. All resources have the same experience for modifying RBAC (but they do differ on which policies they support). It's pretty straightforward, but this doc has more information: https://learn.microsoft.com/en-us/azure/active-directory/role-based-access-control-configure
If you're using our default Storage logs, do yourself a favor and turn on App Insights because it's great. Then, if you still want to use Storage, you can get RBAC access or a SAS token and grab those logs from the Storage Account associated with the Function App. (Name should be in the AzureWebJobsDashboard setting). If you get a SAS token, you can use the Storage Explorer by choosing the SAS URI option when you connect.
If you're using App Insights, good job, you've made the right decision. You can get RBAC access to the App Insights resource and use all their great UI experience/etc. You can also get an API Key and make direct API calls against it, in the case that RBAC wouldn't work. (I would try to get RBAC access, but if that's not possible, here's a link to App Insights REST API docs: https://dev.applicationinsights.io/quickstart)
Short answer, use RBAC to get granted limited permissions (and App Insights because it's great)
Ive created a website in Azure and I want to allow users to login and use the app, but im slightly confused by azure active directory access. I want users to only have acces to the web app, not to the portal. Users will be from within my organisation and from outside it so its vitally important that access is locked down, If a user somehow ends up at the azure portal they must not be able to access it. If I set users up in our active directory, wont they be able to login to the azure portal too ? I want to take advantage of authentication as a service and hand over authentication and multi factor authentication to azure but everytjhing Ive read so far seems to suggest If i use azure active directory, users will be able to acess the Azure portal too, is this correct or am i misinterpreting the information ? Are there any step by step guides available for these sorts of scenarios ?
If i use azure active directory, users will be able to acess the Azure
portal too, is this correct or am i misinterpreting the information ?
No, your users will not have access to Azure Portal (rather Azure Subscription as Azure Portal is an application using which a user manages one or more Azure Subscriptions) unless you grant them permission to access it. In order for your users to have access to Azure Portal, you would need to grant them permissions explicitly to do so. In the new portal, you do it by assigning roles (e.g. Owner, Contributor, Reader etc.) and in the old portal you do it by making them co-administrators.
Unless you do this, when they login into Azure Portal all they will see is a message stating no Azure Subscriptions were found.
I'm developing a tool, similar to Visual Studio's Cloud Explorer, that performs a limited set of management and deployment tasks inside a user's Azure subscription.
I'm thrown-off by a few things relating to authenticating against Azure and how the application represents itself to Azure.
Most of the documentation about authentication with Azure is concerned with web-applications that let users authenticate themselves against an Azure Active Directory. This is not my scenario. While me application necessarily authenticates users against Azure AD (as all Azure users are), my users are administrators, not "users".
I understand previously software that performed administration tasks would be assigned a Management Certificate which is separately-registered in the web-based Azure Management Portal. I understand this fine.
...however I also understand that Management Certificates are almost deprecated and are replaced with Service Principals, which itself makes more sense from a security perspective (as it enables more granular role-based security) - however the downside is that there are a lot of manual steps and hoops to jump through in order to enable the use of Service Principals with administration software - in particular you need to pre-register your application in Azure Portal.
I don't like this because it greatly increases user-friction with the software I'm writing. I want my software to behave like the Visual Studio Cloud Explorer or Azure PowerShell in that you don't need to pre-register anything: 1. just run the program on your desktop; 2. you'll get a prompt to sign-in with your Azure administrator account credentials. 3. my softwware lists the contents of your subscriptions and lets you perform your management tasks.
So far I have actually got something that does this - I perform the following steps:
Use Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext to authenticate against https://login.microsoftonline.com/common (using AcquireTokenAsync which presents the webview to login). I use clientId: "1950a258-227b-4e31-a9cf-717495945fc2" which is the Azure PowerShell clientId.
Use the token from step 1 to enumerate Tenants and Subscriptions in the user's account.
The user is prompted to select a tenant and then a subscription from the list downloaded in step 2.
Send a new authentication request to https://login.microsoft.com/{tenantId} (where {tenantId} is retrieved from step 3), again using the same clientId.
However I don't like impersonating Azure PowerShell - Microsoft could revoke that clientId.
...but how do I register a clientId that can be used to login in step 1 (when there's no tenantId or subscription context, thus no Azure AD which contains Service Principals)?
I don't like this because it greatly increases user-friction with the software I'm writing. I want my software to behave like the Visual Studio Cloud Explorer or Azure PowerShell in that you don't need to pre-register anything: 1. just run the program on your desktop; 2. you'll get a prompt to sign-in with your Azure administrator account credentials. 3. my softwware lists the contents of your subscriptions and lets you perform your management tasks.
Actually, the Visual Studio Cloud Explorer also register the app on the Azure AD and use the Service Management REST to manage the Azure subscription. And you can caputer the request using the Fiddler when you add account to the Cloud Explorer.
...but how do I register a clientId that can be used to login in step 1 (when there's no tenantId or subscription context, thus no Azure AD which contains Service Principals)?
We need to develope a multi-tenant application which enables the users from different tenant to use the application. After that we can use the Common endpoint instead of the specific tenant id you register the app. Then users login-in with their account which associate with Azure subscription and get the access token for the Service Management REST. At last the applicaiton can manage the Azure resource with the access token. For example, we can use the REST below to list the Azure Sbuscriptions:
Get:https://management.core.windows.net/subscriptions
Authorization: Bearer {token}
x-ms-version: 2013-08-01
And more detail about the authenticating Service Management requests, you can refer here.