4

I have deployed asp.net core 2.2 web app as a WebSite to IIS. I've set the application pool identity to ApplicationPoolIdentity:

[IIS Screenshol[1]

I can see that System.Security.Principal.WindowsIdentity.GetCurrent() returns

IIS APPPOOL\MyCustomAppPool

But when I try to connect to SQL Server using connection string:

Server=localhost;Database=MyDadatabse;Trusted_Connection=True;

I get following error (ignore the german):

SqlException: Fehler bei der Anmeldung für den Benutzer "CompanyDomain\ComputerName$".

Why it is not using the ApplicationPool identity?

Also note, that when I set custom username/password as the identity for application pool, it works.

Liero
  • 25,216
  • 29
  • 151
  • 297
  • What is the identity of your pool? Your warning message indicates that it is using the `machinename` or [machine service account]. – tgolisch Jan 24 '19 at 14:30
  • The identity of my application pool is `IIS APPPOOL\MyCustomAppPool` and I have verified it by displaying result of the `WindowsIdentity.GetCurrent()` call – Liero Jan 24 '19 at 15:02
  • By design if you carefully read the documentation, https://learn.microsoft.com/en-us/iis/manage/configuring-security/application-pool-identities#what-about-application-pool-identities – Lex Li Jan 24 '19 at 15:07
  • @LexLi: I would accept this as an answer. – Liero Jan 24 '19 at 16:07
  • You can accept the answer below (which talks about the same thing, and just missed the article itself). – Lex Li Jan 24 '19 at 16:09
  • If I saw only the answer, I wouldn't know why apppool identity is not used, when I set it explicitely – Liero Jan 24 '19 at 16:11

1 Answers1

5

To clarify this, APPPOOL\MyCustomAppPool, like LocalServer, NetworkService, and per-service SIDs are local identities. They don’t exist on the domain, and so can't be used to access remote resource. However the server itself has an account on the domain, and when code running under these identities access remote resources, they use the computer account.

If you have multiple app pool identities on a IIS server and need to differentiate their access to network resources, or prevent the accumulation of privileges for the machine account, you will need to provision domain accounts for the app pools.

If you are connecting to a local SQL Server using the app pool identity, the error message will (confusingly) claim that you are connecting with the machine account. This is a deficiency how SQL Server reports the error. EG if I try to connect to my local SQL Server from an IIS app, it will fail with,

Login failed for user 'MyDomain\MyServer$'

until I grant access to the local SQL Sever with

create login [IIS APPPOOL\DefaultAppPool] from windows
create user [IIS APPPOOL\DefaultAppPool] for login [IIS APPPOOL\DefaultAppPool]
grant select to [IIS APPPOOL\DefaultAppPool]
David Browne - Microsoft
  • 80,331
  • 6
  • 39
  • 67
  • I have SQL server on the same machine, so the problem was elsewhere. I didn't know that when using application pool identity, another identity will be used to access SQL, as @LexLi explained. It seems counterintuitive, but ok... – Liero Jan 24 '19 at 16:06
  • When connecting locally the AppPool identity _is_ used. The error SQL Server returns is simply misleading. See edited answer. – David Browne - Microsoft Jan 24 '19 at 16:38
  • I was getting `Login failed for user 'MyDomain\MyServer$'` so I created this username as a LOGIN on the server instance and USER on the required DB, then set my appPool to run as `NetworkService` instead of `AppPoolIdentity`. Worked for me. – jamheadart Mar 31 '20 at 14:50
  • 1
    @jamheadart Sounds like you already had a login for NT AUTHORITY\NetworkService, or a group it is a member of. – David Browne - Microsoft Mar 31 '20 at 15:20
  • Ah ok, so it isn't actually my `MyDomain\MyServer$` that is logging in and defining the permissions? Is that login actually doing nothing? – jamheadart Mar 31 '20 at 18:29
  • That's the machine account, a Domain account that those services will use to authenticate to off-box resources, but not local resources. So if the SQL Server was on a different server, that would be the correct account to provision a login for. – David Browne - Microsoft Mar 31 '20 at 18:34