IIS 7.5 应用程序池用户（域用户，而不是 AppPoolIdentity）所需的用户权限
我们有一个活动目录域（我们称之为foodomain）和一个用于 IIS 应用程序池标识的域用户帐户（foodomain\fooAppPoolUser）。
我们希望在此用户帐户下运行应用程序池，而不是在网络服务或新的 AppPoolIdentity 下运行，因为我们必须访问 SQL Server 并在 IIS 上拥有多个应用程序（具有自己的应用程序）应用程序池）访问不同的数据库。
问题是我找不到明确的操作方法解释，必须为此用户帐户设置哪些用户权限以及如何设置 IIS 才能使其正常工作。
首先我遇到了错误（不幸的是我不记得是哪些错误），然后我将 fooAppPoolUser 添加到本地管理组（Administrators，我知道，只是为了测试），然后它起作用了。现在我再次删除该用户，重新启动 IIS，它仍然有效。
所以我有点困惑，想知道如何配置/设置才能使其正常工作。
我在其中读到，该帐户需要具有“身份验证后模拟客户端”用户权限。这就是我将帐户添加到管理员组的原因（用户权限分配是通过组策略阻止的，但如果确实需要的话，这肯定可以更改。
我希望我足够清楚问题是什么，并希望有人能给出答案。
We have an active directory domain (let's call it foodomain) and a domain user account (foodomain\fooAppPoolUser) used for the IIS application pool identity.
We want to run the app pool under this user account and not under Network Service or the new AppPoolIdentity as we have to access SQL server and have multiple applications on IIS (with own app pools) accessing different databases.
The problem is that I can't find a clear HOW-TO explaining, which user rights have to be set for this user account and how IIS has to be setup so that this will work.
First I got errors (unfortunately I can't remember which ones), then I added fooAppPoolUser to the local admin group (Administrators, I know, was only to test), then it worked. Now I removed the user again, restarted IIS and it still works.
So I'm confused a bit and would like to know, how the configuration/setup has to be to have it working.
Somwhere I read, that the account needs to have the "Impersonate a client after authentication" user right. That's the reason I added the account to the Admin group (the user rights assignment is blocked via group policy, but this can for sure be changed if really needed.
I hope I was clear enough what the question is and hope somebody has an answer.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
令人沮丧的是，这些信息如此难以找到，因为一些安全管理员似乎很享受更改默认策略设置以阻止在 IIS 中安装应用程序的残酷和不寻常的惩罚。
我认为您应该执行以下操作来使帐户能够作为应用程序池身份工作：
aspnet_regiis -ga DOMAIN\USER以添加访问 IIS 配置数据库的权限。 （到底这意味着什么，谁知道呢？）aspnet_regiis 参考IIS_IUSRS组。这可能会根据 IIS 配置设置 processmodel.manualGroupMembership 自动完成，但您自己添加最简单。Negotiate)，则根据 URL 以及内核模式身份验证是否打开，您可能需要设置注册 SPN。如果可能的话，我建议切换到 NTLM。否则，请参阅下面有关 SPN 的文章，并找到友好的域管理员来为您添加它们。有趣的阅读：
It's frustrating that this information is so hard to find, since some security admins seem to enjoy the cruel and unusual punishment of changing default policy settings to thwart installing apps within IIS.
Here's what I believe you should do to enable an account to work as an ApplicationPool identity:
aspnet_regiis -ga DOMAIN\USERto add permissions to access the IIS Metabase. (Exactly what that means, who knows?) aspnet_regiis referenceIIS_IUSRSgroup. This may be done automatically depending on the IIS configuration setting processmodel.manualGroupMembership but easiest to add it yourself.Negotiate) then depending on the URL and if kernel-mode auth is on you might need to set up an SPN. I suggest switching to NTLM if possible. Otherwise, see articles below about SPNs and find a friendly domain admin to add them for you.Fun reading:
您的应用程序在删除管理员权限后工作的原因是您的应用程序是使用管理员权限编译到框架临时文件夹的 - 您的应用程序在删除管理员权限后工作，因为应用程序是编译的。如果您更新应用程序并且需要重新编译，则应用程序池帐户将再次需要信任。
The reason why you application worked AFTER removing Administrator rights is that your application was compiled to the Framework temp folder using the administrator rights - Your application worked after removing the administrator rights because the application was compiled. If you update your application and it requires recompilation, the app pool account will need trusts again.
我发现以下链接回答了我遇到的类似问题： http:// /www.iis.net/learn/manage/configuring-security/application-pool-identities
基本上，ApplicationPoolIdentity 是一个虚拟用户帐户，其行为仍然类似于 NETWORK SERVICE，但没有一些缺点；每个应用程序池都有一个用它创建的自己的 ApplicationPoolIdenity 帐户。
还可以找到更详细的信息，这些信息也特定于 IIS 7.5 应用程序池标识。
I found the following link answered a similar question I had: http://www.iis.net/learn/manage/configuring-security/application-pool-identities
Basically, ApplicationPoolIdentity is a virtual user account that still behaves like NETWORK SERVICE, but without some of the down-sides; each app pool has it's very own ApplicationPoolIdenity account created with it.
More detailed information can also be found that is also specific to IIS 7.5 Application Pool Identities.