Even though I have umbraco running with impersonation, with a custom user, and everything (almost) is working fine, I keep getting errors in windows event viewer, every minute, from NETWORK SERVICE trying to login to SQL Server:
Login failed for user 'NT AUTHORITY\NETWORK SERVICE'. Reason: Failed to open the explicitly specified database. [CLIENT: <local machine>]
This is logged every minute... on the clock. Which is bizarre. This stopped when I allowed NETWORK SERVICE to login to umbraco's database (just public).
Could be the scheduled publishing routine. It runs in the background, and every minute it looks for content that has a "Publish at" date. The thread do not run because of a request, so maybe that just uses the app pool user?
Are you using integrated security in your DB connection string?
I didn't think umbraco would use the app pool user for anything in this setup. I assumed all communication with the database would be done through the impersonated user. Guess I was wrong. But should it?
Impersonation is not really my strong side, but from what I can search myself to, it seems that there are at least some issues when spawning thread, where you need to make sure that the new thread inherits the identity.
If you are hardcoding the identity, then why do you want to use impersonation? Maybe there is another way to achieve your goal?
I'm not developing, just installing umbraco without creating a new app pool with a custom user.
So using the default app pool, and with impersonation defined in the web.config, I get to define the umbraco connection with integrated security and a user that's not NETWORK SERVICE. That's it. I was just surprised to see all content and configuration being access ok by umbraco, mas still getting NETWORK SERVICE trying to connect every minute. It seems to me it shouldn't. Umbraco should use the same connection string in all occasions. It must be like you said, the thread is using the app pool user and not the impersonated user of the asp.net application. Maybe something to change in the future?
NETWORK SERVICE tries to login even with impersonation on
Even though I have umbraco running with impersonation, with a custom user, and everything (almost) is working fine, I keep getting errors in windows event viewer, every minute, from NETWORK SERVICE trying to login to SQL Server:
Login failed for user 'NT AUTHORITY\NETWORK SERVICE'. Reason: Failed to open the explicitly specified database. [CLIENT: <local machine>]
Could be the scheduled publishing routine. It runs in the background, and every minute it looks for content that has a "Publish at" date. The thread do not run because of a request, so maybe that just uses the app pool user?
Are you using integrated security in your DB connection string?
Hi Morten.
I'm using integrated security, but did not define a custom login for the application pool. I just use impersonation in the web.config.
This is the connection string I'm using:
This is the impersonation tag in the web.config:
I didn't think umbraco would use the app pool user for anything in this setup. I assumed all communication with the database would be done through the impersonated user. Guess I was wrong. But should it?
Duarte
Impersonation is not really my strong side, but from what I can search myself to, it seems that there are at least some issues when spawning thread, where you need to make sure that the new thread inherits the identity.
If you are hardcoding the identity, then why do you want to use impersonation? Maybe there is another way to achieve your goal?
I'm not developing, just installing umbraco without creating a new app pool with a custom user.
So using the default app pool, and with impersonation defined in the web.config, I get to define the umbraco connection with integrated security and a user that's not NETWORK SERVICE. That's it. I was just surprised to see all content and configuration being access ok by umbraco, mas still getting NETWORK SERVICE trying to connect every minute. It seems to me it shouldn't. Umbraco should use the same connection string in all occasions. It must be like you said, the thread is using the app pool user and not the impersonated user of the asp.net application. Maybe something to change in the future?
Duarte
Why not just put the user in the connection string? Or set the user in the app pool? Not sure i understand the reason for doing this.
Sure, we can do that. Just seemed odd. I didn't want to create an app pool.
The point is to know umbraco better...
thanks,
duarte
I don't think you got this because of Umbraco.
The SQL service is running on same machine or on different machine ?
What version of IIS are you using ?
You machines are in AD infrastructure?
is working on a reply...