I have built a web application that uses Microsoft Graph to connect to OneDrive to upload files to a user's drive.
The web application is registered in Azure under the App Registrations and is also in the Enterprise Applications, having been granted permissions by an administrator to access OneDrive.
There is a section in the Office365 Admin Console to run searches and raise email alerts, however, the user that appears to be performing the action just comes through as 'app#sharepoint', so we cannot monitor what the actual web application is doing because this is too general.
The question I have is, is there any way to specifically monitor what this app is doing, in terms of uploading files or reading files? I don't know if there is any way set the user that the Enterprise App runs under, or if there is anything that the application can pass to identify itself?
To view a report on user specific activity details on OneDrive connected to via Graph to an app registered on Azure, use GET /reports/getOneDriveActivityUserDetail(period='{period_value}') or GET /reports/getOneDriveActivityUserDetail(date={date_value}).
You will however need Reports.Read.All application permission.
Please see the following documentation for a better understanding of the usage of this query: https://learn.microsoft.com/en-us/graph/api/reportroot-getonedriveactivityuserdetail?view=graph-rest-1.0#code-try-1
Related
My Requirement is
Capture the user information e.g. name, id, email id, etc. which currently Im capturing through the excel sheet by sending the sheet to everyone. I want to automate this in Azure by creating a simple web application.
Store the information in a DB or storage.
Create Graphs and dashboards. Update the dashboards automatically as and when the informrtaion gets added/updated.
Provide users access to the Web application(Front-end) forms only.
Allow users to update the information they provided as and when needed.
Allow application access using Azure AD
What are the possible simple solutions available in Azure with minimal cost.
Thanks,
Yogesh
Have a look at https://learn.microsoft.com/en-us/azure/app-service/tutorial-dotnetcore-sqldb-app?pivots=platform-windows which is a quick start tutorial that uses https://github.com/azure-samples/dotnetcore-sqldb-tutorial. It outlines creating an application and storing in an Azure SQL DB. By using .NET Core, you can leverage either Windows or Linux app service plan which opens your options as far as pricing goes. In the repo, you can modify Todo.cs to match your user information requirements.
For allowing application access using Azure AD, have a look at https://learn.microsoft.com/en-us/azure/app-service/tutorial-auth-aad?pivots=platform-windows.
You can get started easily by using a Free tier app service plan and either basic or general DTU or v-Core Azure SQL Database pricing.
I have two applications:
MVC Site (User-facing Web App secured via OAuth -> Google)
Web API Site ("Private" Web Services)
These are hosted in an App Service Plan in Azure. These web services will only be consumed by my own applications - I don't need to worry about outside consumption. In fact, I specifically don't want outside consumption. My Web App is using OAuth to Google - that shouldn't matter here.
So to get to the heart of my question: My web services currently have no authentication/authorization model in the code but I don't want it just publicly available to anybody. On prem, we just lock this down via IIS using Windows Auth and set the service account for the consuming web app to run as a user that Windows Auth allows access to. I'd like to do the equivalent in Azure.
I understand Azure isn't exactly the same but I have to believe this is possible. I have even gotten my web services locked down the way I want using the settings in the Authentication/Authorization tab (I can try to navigate to it but I only get my Swagger UI once I login with a valid organizational account). So half of my battle is solved but I cannot figure out how to do the other half - the equivalent of setting the service account for my consuming MVC application to run as.
Can I do this via the portal without having to code specifically to this scenario? I'd really like a PaaS-level or IaaS-level solution for the security portion of consuming the above locked-down services. I'm also open to other avenues if I'm going down the wrong path in having a PaaS or IaaS security solution to this problem. I'm not against making code changes - we did have a one-liner in our RestSharp code to engage Windows Authentication, but the bulk of the work/configuration was outside of code and that's what I'm going for here.
If going the IaaS path you can host the application inside of an VM in the exact same way as you did before when running it directly on-top of IIS. The benefit is that you can get running the same way as before but you will still need to manage the VM; i.e install updates and take care of its security.
However, if you want to have a PaaS solution, then you need to modify the code of your front-end application to pass on the authentication token to the back-end API, assuming the back-end accepts the same authentication as the front-end. See https://azure.microsoft.com/en-us/documentation/articles/app-service-api-dotnet-get-started/ as an example on how to pass on authentication information from one app to another.
Alternatively you can use the app identity to make calls to your back-end API. This way the calls are not related to any user but are instead done in the context of the app. See https://github.com/Azure-Samples/active-directory-dotnet-daemon for more details on how to set it up, both configuration and needed code.
If you want to allow your users to sign-in using their Google accounts then you could handle authorization to your API using the app identity (second alternative above), assuming the API is independent of the requesting users identity.
Enabling authentication for a Azure Web App directly through the menus in the Azure Portal adds Azure AD authentication in-front of your application and require your to pass an access token generated by Azure AD to your API for it to work.
Scenario:
One team had built one application, and application is running on azure.
maintenance is taken care by same team, we don't want to give full access of production instance to developer team, but want to give read permission, like - monitoring of logs, cpu usages etc.
Solution according to me is build an application which will get dashboard data and log data from azure via api and that data will be displayed to development team.
I am referring these 2 links
https://msdn.microsoft.com/en-us/library/azure/dn722415.aspx
https://azure.microsoft.com/en-in/documentation/articles/api-management-get-started/
Question:
Still I am not able to find api which will give the dashboard data. if anyone know api for the same, please help.
Is there any alternative solution for this scenario.
If you deploy your app using the new Azure Resource Manager mode, it provides a Role Based Access Control to your resources. You can deploy your app inside a Resource Group and provide read access to your developers. They will be able to view the information about the services that your app are made of but without the option to change anything.
This session from Build 2015 can help you to understand what ARM is and what you can do with it: https://channel9.msdn.com/Events/Build/2015/2-659
I work for a network management company and I want to write a .Net application (MVC 4) that will allow us to service Active Directory users from a cloud-based application.
As I have never written a cloud-based app, I don't know if I'm using that term correctly or not. I am in the requirements gathering stage. Basically, I'd like to provide our customers with the ability, for example, to change their own password using our cloud-based application.
is this an application that should be written specifically using Azure? If not, what tools and platform(s) should I take into consideration?
What tutorials or other resources are available ?
Actually, I don't even know enough about Active Directory and Cloud computing to ask the right questions. But, I hope someone will point me in the right direction
Read How to Authenticate Web Users with Windows Azure Active Directory Access Control. There are great walk-throughs there. There is more reading and code samples here - Access Control Service 2.0.
That's using ACS.
You could go direct to Azure Active Directory if you wished?
Refer: Adding Sign-On to Your Web Application Using Windows Azure AD.
If you use Office 365, you already have an AAD tenant.
I'm trying to confirm my findings on permissions.
In order for the SharePoint object model to be accessed from a console application or for that matter a WinForm application, the user running the application must have db_admin permission to the content database for the web application in question.
In order to use Microsoft.SharePoint.Administration (like calling SPFarm.Local.Solutions.Add) inside an ASP.NET application the following must be true:
The call must be wrapped with RunWithElevatedPrivileges like the following:
SPSecurity.RunWithElevatedPrivileges(delegate() { code to run } );
The user accessing the ASP.NET page must be part of the Farm Adminstrators Group (the page is running under _layouts)
The user in the identity of the App Pool for the web application in question must also be in the Farm Adminstrators Group
Does this information look correct?
Yes but within the web service code you call the functional code using RunWithElevated Privileges this bypasses the identity you are running the web service as and instead uses the SPFarmAdmin user to execute the code.
Alternatively host the web service in an app pool which uses the same domain account as your central admin site, and allow anonymous access to the web service. This would be safe for internal use only and would mean that the web service always had elevated permissions.
Edit: Contrary to Michael's comment I have assumed that this app is not going to be run from within the SP farm.
I would not recommend this approach at all as it is an unupported method of using the SharePoint OM.
You are much better off writing a web service that sits on the SP farm and uses the OM, and then access the web service mehods to perform your required functionality.
You could also look at the out of the box sharepoint web services.
RunWithElevatedPrivileges will not work in your scenario I dont think as it requires a base indetity to fall back on which in the case of code executing on the SP farm is the SP App Pool identity which is usually a farm admin account.
I am happy to be corrected on all of this, but certainly in my environment it would not be wise to invest in a non-standard and unsupported approach to a problem.
Yes the web service will need proper access rights, but this is easier to control with a web service running locally.
However if as you say the apps are always running on the server then using RunWithElevatedPrivileges will solve any permissions issues as you are in effect running that code as an SPFarmAdmin (as long as the app pool identity is configured correctly).
Note: you could use this approach with either bespoke web services or client apps such as console applications or windows forms.
Apologies hobbyman, I never saw you reply.
If you use RunWithElevatedPermissions then it doesn't matter which user the web service runs as, because you are effectivley impersonating a farm admin account.
You could additionally do your own impersonation within the web service and impersonate any user you wish.
Essentially if the web service is running within a given application pool then the web service will run under the indentity which the app pool runs as. Does this clarify things?