I have a .NET 4.0 C# console application. The application is deployed to a network file share (which I believe is a Windows 2000 Server file server) like this:
\\server\share\Apps\Beta\Group\JobName\JobName.exe
The agent machine that will execute the application is a Windows 2008 R2 Server, x64. I use a domain user account to run the application from the command line. When run under a certain account we'll call UserBeta, the application throws the following exception when trying to connect to a WCF service:
System.Configuration.ConfigurationErrorsException: Error creating the Web Proxy specified in the 'system.net/defaultProxy' configuration section. ---> System.Net.Sockets.SocketException: An invalid argument was supplied
The user account, UserBeta, has Modify, Read & Execute, List folder contents, Read and Write permissions introduced at the folder Beta and inherited by the child folders in the above path. If I use a second user account, UserStage, which has the same permissions except that they are introduced one folder higher, at the Apps folder, the application runs without exception. Both accounts belong to the local Administrators group on the agent server.
Interestingly enough, if the application is executed as UserBeta within 15 seconds or so of it being executed as UserStage, it will also run successfully.
I should also note that the application runs fine if run from a local drive as the GroupBeta account, so there seems to be some sort of trust issue with the particular account running from the network share.
I need the application to run as the UserBeta account from the network share. ClickOnce is currently not an option. I believe I could solve the problem by adding the permissions for UserBeta at the Apps folder, however I don't like throwing more access at something unless that's really the issue. If anyone has any other ideas or can point me to the reason adjusting permissions is the correct course of action, I'd be much appreciative.
Related
Goal:
I periodically upload new .exe file to windows server 2003 via FTP and I want to run it manually by hitting Url of a web site on same server. Exe needs to be run under an Admin account, and not the NETWORK SERVICE account.
What I achieved so far:
I have been able to successfully run applications like notepad under the Admin account on the server via a web request by using any of these:
PsExec,
.net process.Start() with credentials supplied to process.StartInfo and even
by impersonating admin and then using process.Start without credentials (http://www.f4cio.com/programmatically-impersonate-in-csharp)
The problem:
The above methods run my exe but Task Manager, or a call to System.Security.Principal.WindowsIdentity.GetCurrent().Name shows me that it is running under NETWORK SERVICE.
I suspect that this file has added security constraints because it arrived from ftp link. Checking run-as-administrator in properties of file is not an option because file will be replaced periodically and all needs to be automated. Also manual server configuration should be minimal or ideally non-existent. Code-only single-web-page solution is ideal. Editing both that asp.net web page and exe is ok. (I tried something with exe self-restarting).
Not sure about this, but I suspect this has to do with you website running under the NETWORK SERVICE user. Whatever privileges your website-user has, the same are probably granted / passed on as you try to run your executable.
Is this server on an internal network or protected in some other way? (I should hope so!). If so, you might try changing App Pool that the website is running under to an admin account (in IIS, right click the App Pool running the site, select Advanced Settings, and look for the Identity setting). If I'm right, that will allow you to run your executable as an admin too.
Be aware however, that this may increase the security risk of your setup: Allowing your site to run under an admin account means easier access to your entire server if anyone is able to penetrate whatever security measures you have in place. Make sure access to this server is tightly limited, and preferably, that it in turn does not have access to other systems, since that would in turn make them vulnerable by extension.
I have a windows service written in C# running on Windows Server 2012. The service is running as a domain user with permissions on the local machine and NTFS permissions to shared network resources on an Isilon SAN. I can access shared files and directories in Windows Explorer when logged on as this user with the following format:
\\isilon\path\to\dir\
However, calls to
System.IO.Directory.Exists()
always return false. At first I thought it was this:
http://support.microsoft.com/kb/827421
However, implementing the workaround suggests that you can use
System.IO.Directory.GetDirectories()
to just access the directories (without checking first if they exist) instead. This just throws
System.IO.IOException: An unexpected network error occurred.
This same service code works when running on another server (Windows 2008) on the same network.
What is really crazy is that if I reboot the server, the file system calls succeed at first. Then after some amount of time, or after accesses to the same file path from that computer, the programmatic calls will start to fail and will never spontaneously succeed again. Rebooting the server fixes the issue for a very short while.
I'm totally stumped as it shouldn't be necessary to reboot a Windows server instance hardly ever. I don't have any idea what could be affecting the fileshare permissions or accessibility. Maybe it is related to the new implementation of SMB 3.0 on Windows server 2012?
Edit: OK, It turns out that I'm not crazy. The version of OneFS (the FileSystem running on the Isilon SAN) was not explicitly compatible with Windows server 2012. While it claimed to be compatible with SMB. Updating from OneFS version 6.5.5.14 to 6.5.5.20 fixed the problem immediately and has been stable since.
I am facing a strange issue with my site in IIS 7. I have 10 sites with different sub-domains hosted on IIS 7. I am using .NET framework 3.5 and SQL Server 2008 R2. Three sites I have configured on DefaultAppPool while for others I have created separate application pool for each and configured them with their specific.
I allows user to upload video, after upload completes I used to hint it (a process to make bit rates of video equal for on-line streaming on android) using MP4BOX - a command line interpreter, with server side code.
What issue I am facing is while using DefaultAppPool the MP4BOX works fine but when I configured site to its specific appPool, MP4BOX stops working. I have go through the settings but haven't find any issue. Can anyone help me to overcome this issue.
Awaiting for your valuable response.
Resolved it myself by assigning read/writes permission to the application pool to the directory.
After lots of research I have found that it was happening due to read/write permission of this exe to the specific directory. MP4BOX need to have read/write permission to create video file in the IIS directory. So I have added application pool as a user to the specific directory to which mp4box was accessing for read write.
I have an MVC application in which users are able to upload files. Before I write the uploaded file, I create a directory according to date time. I start off with C:\ApplicationName and end up with C:\ApplicationName\20111001\Filename.ext when the upload is completed (in theory).
My problem on my local Windows 7 machine is that I can not write the file.
I get an "access denied" exception no matter which user I give full access to the directory. The strange thing is that the date directory gets created just fine.
I have given the following users full access:
[Current logged in user]
NETWORK SERVICE
IUSR
IIS_IUSRS
Guests
Everyone
Without any success. I really don't understand what is going on here. When I give Everyone full access, I should be able to create a file right?
PS: I use Visual Studio 2010 and ASP.NET Development Server straight out of the box.
I am not running IIS, I am running the watered down version "ASP.NET
Development Server". So I am quite limited
The problem is that in order for you to write to the file directory from the application you will need to run Visual Studio as Administrator.
Windows 7 is preventing the process from going outside of its sandbox because it is running with limited privileges. This is true even if your account is the administrator.
Check the permissions of the parent folder and make sure they are inheritable, you can check this on the advance options window.
This might help a bit... probably application pool permission is the culprit here:
IIS AppPoolIdentity and file system write access permissions
Just had the same problem myself. By default IIS7 AppPools use AppPoolIdentity. Just open up your AppPools in IIS Management Console, select the one you are having problems with, choose Advanced Settings and under Process Model change Indentity to Built-in Acoount > NetworkService.
Since you have already granted NETWORK SERVICE acces to your folder everything should work.
On my test machine running (Windows XP, IIS5.1) the following code executed within a C# .NET WebService (.SVC) under a custom process identity (using machine.config to specify the user)
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
correctly returns
c:\Documents and Settings\myUserName\Application Data
However, on (Terminal Services) Windows 2003 machine running IIS6 and executing the same code but now using ApplicationPool to specify the same process identity the method returns:
c:\Documents and Settings\Default User\Application Data
Things I have checked while running on the Win2003/IIS6 machine:
myUserName belongs to the group IIS_WPG (even tried Admin)
a call to Environment.UserName correctly returns myUserName
a call to Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData); also returns a 'Default User' path, likewise with DesktopDirectory
logged on as myUserName and ensured that C:\Documents and settings\myUserName exists
running the exact same code in a .net application on the Windows 2003 box, this works and returns the correct path.
I am baffled, it only occurs when runing under IIS6. It is almost like it thinks that the call is coming from Network Service or Local System users and it is not checking the Identity running the Application Pool.
Incidentally when I look at Procmon and watch a C++ application that is called from the webservice it has no such problem reading and writing to C:\Documents and settings\myUserName\ApplicatonData, it does not seem to have a problem, perhaps it builds the path differently.
I am starting to think this might be a bug in .NET??
Thanks.
Tom Deloford
Solved. Apparently this is 'by design' because IIS6 does not load user profile settings.
Microsoft advised me to upgrade to IIS7 or call LoadUserProfile first, I wonder what possessed them to change that functionality from IIS5.1.
http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/890fa85a-b11a-4fbe-a333-cbe69abd72a7
Anyway lesson learned, don't assume functionality hasn't been removed and always test with the same application server even if annoys the IT department!
Yes. it's not a bug.
Under which user is running the app pool??
Let's split this a little:
The Test Machine uses IIS to host the service or the built-in web server?
If you use the built-in web server, it runs under your user.
If you use IIS, which one is the pool user?
If it is Network Service or Local System, the process runs under the context of one of those users, and indeed, the call to:
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
is OK.
You should change the user of the pool (and recycle the pool) to see the change.