The userid that is the identity of the application pool is also in the Farm Administrators group.
Is that a bad thing?
We started seeing some weird permission errors after this change was made (that userid was added to the farm admin group).
Microsoft recommends using seperate accounts:
http://technet.microsoft.com/en-us/library/cc263445.aspx#Subsection2
We have done this several times in our dev environments where we wanted one single account with godlike permissions on everything.
It should not be causing permission problems as far as I know, but SharePoint can be a bit...fickle in this regard.
Related
This is probably a silly question, but I am not seeing the answer on stackoverflow or the microsoft community.
We are creating an enterprise app which will be used between multiple domains. I understand you can add the application permissions manually and we know how to do this.
The question is:
Is there a way to allow your app temporary permissions? Basically, the user consents to the permission to the app, but once the app is done with it's task, then the consent is immediately removed or there is a time frame for it?
As you can see below, we want to only allow
Domain.ReadWrite.All
for the purpose of creating a new domain, but then it is not needed after that.
Without going into Azure and deleting the Enterprise app or revoking individual permissions.
Image of Azure Enterprise Application API Permissions
when i change identity to localservice restart,it`s work,but why?applicationPoolIdentity created by default,it should has power with site folder,and when site run,i change identity to ApplicationPoolIdentity again,still work,dose some one know doc with it?
"it should has power with site folder". No. That's not correct.
Many permissions are granted by server administrators after deploying a web app and they don't come automatically.
For example, IIS_IUSRS has read and execute permissions in \inetpub\wwwroot only because that's the folder for the sample Default Web Site.
If you create a new site then you are responsible to grant IIS_USRS the permissions there. From security perspective, that's the right way to go, and this behavior was there since at least IIS 6 (two decades ago).
Reference
https://learn.microsoft.com/en-us/troubleshoot/developer/webapps/iis/www-authentication-authorization/default-permissions-user-rightshttps://learn.microsoft.com/en-us/troubleshoot/developer/webapps/iis/www-authentication-authorization/default-permissions-user-rights#inetpubwwwroot
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!
Every guide, blog and the health analyser keeps saying that you need to set up different accounts for different services, farm account and application pool accounts.
But no-one want to explain me why! I have tried to search for an answer, and while I am pretty sure it has a good reason I just cannot seem to find one. I really would like to know why. I want to learn! Try to be concrete!
To narrow down the question a bit. What are the reason for these two security issues reported by the health analyser:
The server farm account should not be used for other services.
Accounts used by application pools or service identities are in the local machine Administrators group.
I followed these two questions:
IIS 7.5 App Pool Identity permission not assigned to folder, but application still can write to its folder?
IIS AppPoolIdentity and file system write access permissions
To try to understand how it is possible to isolate IIS ApplicationPoolIdentity users although they are members of the Users group that has read access practically everywhere.
I think that should be more secure that the App Pool\myapp could only read the contents of the site (or read/write its virtual directory), but what is the best practice to do that without removing the Users group ACL from everywhere?? my Windows server defaults has the "users" group on the volumes acl with read access and inherits to all folders...
This question is also answered in the answer you linked to, by Kev. You should preferably set up your web root on a separate non-system drive. There you can remove the Users group from the top level and grant rights to the home folder of each site to the respective application pool identities only.
AMit - that still doesn't solve the issue that his web app can read practically any file on the c:/ drive. But it's even worse than that. The web app can WRITE to the c:/ drive. Because the users group has permission to do so...
It's a fundamental security flaw in Microsoft's design. I've been searching for a solution myself and yet to find one.
Putting the web site on a different partition is security through obscurity... Which is basically no security at all - rather the mere hope that they don't find...