My web application is a product which has to deploy to a variety of web servers. Is there a way to determine the account name that the .Net worker process account is using at runtime?
Using .Net 3.5, C#
Thanks in advance
-Pete
Have you tried System.Environment.UserName ?
Edit:
You're right, the environment username doesn't seem to work. Here's something else you could try, which I've tested on IIS 7 / Windows Vista:
System.Security.Principal.WindowsIdentity.GetCurrent().Name
Returns "NT AUTHORITY\NETWORK SERVICE" for me since my default app pool runs as network service.
Related
I want to try moving to VNext from Asp.Net MVC 3, I used windows service project (http://www.interworks.com/blogs/banderton/2009/10/30/long-running-tasks-aspnet) but this doesn't seem to work on VNext, because it doesn't have proper System.ServiceModel reference and I cant add dll.
Is there a way around? Would you recommend other ways to run long tasks such as big file import/calculations with VNext?
Generally, no - not because of any feature-set in ASP.NET vNext (it's been possible since .NET 1.0) but because of permissions: a process needs to run under a high-privilege security context or be able to impersonate such a user account in order to control Windows Services.
w3wp.exe (the application pool hosting process, and by extension, the application pool and the applications within it) all typically run under a least-privilege user-account (often NT AUTHORITY\NETWORK SERVICE or a custom user account with enough permissions to write to the website's root directory, a database server, and not much else (in recent versions of Windows this is further reduced to the concept of a "service account" which your worker-process and pools run under).
The easiest solution is to create a user-account with the necessary privileges to control services and run your application pool process under this user-account, but I don't recommend this.
Consider, instead, creating a new Windows Service that then controls the other service (or if it's your own service, do it in-proc) that uses some form of IPC to communicate with your ASP.NET application to shut itself down and perform other tasks. You might want to look at named-pipes, for example.
If you need to run ASP.NET in a Windows service, you can do it now using ASP.NET 5. I wrote a detailed post on how to do this here: http://taskmatics.com/blog/host-asp-net-in-a-windows-service/
I have to debug a WCF hosted in local IIS. Each time I have to attach two processes "w3wp.exe".
One ID is 7624, the other is 8372.
Users: one is "IIS APPPOOL\ASP.NET V4.0 Integrated[administrator]
the other one is "IIS APOOL DefaultAppPool[administrator]
Questions:
What they are? (google search but bo clue)
Can I just attach one process rather all?
Thanks
Updated:
See IIS image:
Just check in your IIS Management Console the Application Pool in which your site resides, then attach to the proper one. Probably, as you're using WCF, you're running under .NET 4, so under the first process you linked.
Application pool is the set of apps that run under same worker process.
Important thing in practice is that one app pool can serve only applications with same version of .NET (version of .NET CLR - to be precise). It is also good to remember that applications from the same app pool will "share" recycling of worker process.
So, you should look up at the IIS in which app pool your service is running and debug only process associated with this app pool.
They are Application Pool Identities. This is the newer (and securer) way of assigning priveleges to websites. Essentially a site runs on its own application pool, so you assign rights to files based on that pool.
See: http://www.iis.net/learn/manage/configuring-security/application-pool-identities
I have developed a web site to show job status of our fax server. I use windows fax service (fxscomex.dll interop). when I am debugging from VS2010 (using development sever), everything is fine, I can read jobs status of, but when I run my web site under IIS, job queue is always empty.
here is my code to check sent items:
FaxOutgoingMessageIterator sentItems = fxServer.Folders.OutgoingArchive.GetMessages(100);
sentItems.MoveFirst();
while (!sentItems.AtEOF)
{
Response.Write(itm.Recipient.Name);
sentItems.MoveNext();
}
on IIS, sentItems.AtEOF is always true.
Thank you
I received this answer from asp.net forum and it worked!
The identity is different from visual studio and IIS application pool. You can try to change the IIS application pool's identity to be local system or your machine/domain account or event administrator to have a try.
however the other built-in accounts didn't work but when I set the application pool identity to a admin user, it worked.
I have a windows service that hosts the main WCF service. The clients for this service are both hosted in IIS 7, the first one is an IIS hosted WCF service and the second is a standard Asp.Net application. Both of the IIS hosted clients communicate with the windows service over named pipes.
The IIS hosted WCF service can communicate with the windows hosted WCF service perfectly, but the Asp.Net service fails with this error:
The pipe name could not be obtained from the pipe URI: Access is denied.
My first reaction is that this is a permissions issue somewhere, but I dont know where. And second, why would the IIS hosted WCF service be able to communicate without issue, but the Asp.Net application fail?
Ok, I solved it, or rather I figured out where the permission issue was.
It turns out the Anonymous Authentication setting was using some weird user created by our client (the physical person, not our WCF client), and not the NetworkService user (the identity the app pool was using).
But this almost begets another question: Why were even newly created sites defaulting to this IUSR and not the system defaults? In anycase, I just hope this gets indexed in google as, there were virtually no articles relating to it.
Check the Identity of the Application Pools that the WCF and ASP.NET services resides in.
Maybe the WCF service's AppPool has an identity that has different rights than the other AppPool?
Also, you might want to note that IUSR is the default IIS7 account for Anonymous accessors. See Understanding the Built-In User and Group Accounts in IIS 7.0 for an explanation of the default accounts.
Hope this is helpful.
I've recently had my PC upgraded to Vista, which means it includes IIS7. The problem is that the ASP.NET website we're working on doesn't work anymore. I get an error because the application is trying to connect to the SQL Server with NT AUTHORITY/ANONYMOUS LOGON instead of my domain user, and anonymous isn't authorized. I've tried several things, but no solution yet:
- install and enable the 'IIS Metabase and IIS 6 configuration compatibility'
- enable Windows Authentication for this website
- created a different Application Pool with managed pipeline mode set to Classic
- enabled IIS6 WMI compatibility and IIS6 management console (getting desperate here)
In our web.config there's and in our machine.config there's . I've tried putting impersonate to false and entering my domain user and password in the machine.config (it used to be like this) but that didn't help either.
Are there things I'm missing? Has anyone else had a similar problem?
How does your application authenticate with SQL Server? Does it use SQL or Windows Auth? I hope you are trying to use Windows Auth. In that case, your IIS worker process should be running under that Windows user account. If not, it should at the least impersonate a Windows user account that has necessary access rights to SQL Server. If you have impersonation enabled and if you are using the right Windows user account and if SQL Server authenticates using Windows auth and if you are still unable to access SQL Server, you may be running into the classic double hop issue. In other words, you are trying to authenticate to IIS once and you are using the same crdentials to authenticate to the SQL Server over a network next(which is your second hop) and Windows does not allow that for security reasons.
I believe I have found a/the solution. At least it's working now. This is what I did:
The website is now running in a seperate application pool with Managed Pipeline mode set to classic, Load userprofile set to False and Identity set to custom and using a domain user (and password) that has access to the database.
Under 'authorization' of the website itself, I have Anonymous set to enabled and ASP.NET impersonate set to disabled.
in the web.config of the site is also set.
Credit where it's due, this site helped me.
I'm sorry to say I can't look into the issue any further. Indeed, it probably is something with the way we connected to SQL Server (Win Auth) because we've changed it now. Now we connect with username and password in the connection string and it's solved.
So I can't really say if you provided the answer, msvcyc, but I did vote on your solution. Thanks for the time and trouble.
Well, I recommend you migrate to Integrated mode if there is not too many troubles to enjoy the innovation it brings. :)
http://mvolo.com/blogs/serverside/archive/2007/12/08/IIS-7.0-Breaking-Changes-ASP.NET-2.0-applications-Integrated-mode.aspx