Currently all of our web apps have their Application Pool Identity set to ApplicationPoolIdentity. Now, When an app needs to access some resources on some some server, say, add/read some file, the app performs impersonation in code to a user that has permissions to do this stuff. But now, we are contemplating to create a specific user for each app, and set its app pool identity to its specific new user. But I have noticed in the Advanced Settings dialog that Microsoft recommends to use the application pool identity, as shown in the following image:
Why does Microsoft recommends to use this identity, and is using a specific user is not best practice or a wrong move?
thanks,
ashilon
ApplicationPoolIdentity uses a concept called Virtual Accounts
and is implemented to have App Pool isolation.This blog explains
in detail about that .
ApplicationPoolIdentity is the recommended approach to have proper isolation between each website/application pool in IIS7+ onwards.So you can have code or files running for one website or app which cannot be accessed by no one else.
But for your scenario where you need to access resource on another server,When you use ApplicationPoolIdentity it uses the Machine identity only always.So the best approach is to use managed service account
Managed Service Accounts are a great way to manage Services
that need network access. Let Windows take care of passwords and SPNs
for you
Please find more information here ,here
But this has problem as only one managed service account can be assigned to one Server.Even with Application Pool identity,it will be using the $machineaccount to access network resources.
If network resources you have to isolate for each website/application,then your only way to create the separate User Account for each Websites and manage that.
Hope this helps!
Related
We're developing a managed app (using ARM templates) that will be deployed to multiple tenants. The solution will, among other things, work with SharePoint sites on the end users' tenant.
We have looked into using a single multi-tenant app registration with the appropriate rights. Because of security restrictions on the SharePoint API when using Azure app-only, a certificate must be added to the app registration and the PFX must be provided in all API calls.
We wish to have as little data at our end as possible, so the we hoped to include the application that connects to SharePoint as part of the deployment. However, this would lead to multiple apps having access to the same PFX, which doesn't seem safe.
I'm hoping there is a better way to go about this. Must the connecting web app instead be hosted on our end? Is there a safe way of storing the PFX in multiple locations, or make it accessible to multiple tenants? It is important to us that we can automate the process as well, preferrably using ARM or an automation job as part of the deployment ... At the very least, I would be thankful for suggestions on making any configurations relatively pain-free for the end user.
PS: We would like to avoid the use of service user accounts.
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.
Is there any possibility to configure IIS server to enforce Azure Active Directory authentication in hosted application? I don't want to apply any changes to app's code, it would be great to provide this authentication only on server level/layer (configuration IIS). Is this even possible?
EDIT
I have situation like this:
Have many applications from a customers. Have Azure AD and users added there. I need to provide Azure AD authentication to these applications. Moreover, i shouldn't do anything with code of these applications so i thought that i can try to enforce authentication not on application level but on server level. I've been searching informations about possibility of this method but can't find any (only application scenarios supported by Azure AD https://azure.microsoft.com/pl-pl/documentation/articles/active-directory-authentication-scenarios/ ). The only thing i have found is Azure Multi-Factor Authentication but i don't think it is helpful.
We tried to find it, and all that i have found that there is no possibility to enforce AAD authenticatoin on the IIS level and that it should be set up on the application layer which is actually the only one recommended and described process on the sites and in the AAD-related articles. I would say, that it can be even hard from a technological standpoint.
Reference 1
Reference 2
Could someone please confirm whether it's possible to make user of Azure Dedicated Cache using normal console application OR it should be the azure project?
If you're using In Role caching, then it would only work from within your roles that too within the roles in your cloud service. You can't use In Role cache outside of your roles.
If you want your cache to be accessible from outside of your roles, you may want to look into Windows Azure Caching Service which is in preview currently. From whatever documentation I have read about it, my understanding is that this cache can be shared among various cloud resources (Cloud Services, Web Sites, VM etc.). Going by that, I would assume that this cache should be available to your console application also. Check out this blog post from Scott Guthrie: http://weblogs.asp.net/scottgu/archive/2013/09/03/windows-azure-new-distributed-dedicated-high-performance-cache-service-more-cool-improvements.aspx.
You can have a console app for development purposes, but if you want to access with a decent latency, you would anyway have to use cloud.
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?