I have an interactive windows service which run on a Local System account and with Interact with desktop checkbox checked(this is mandatory for my project as my service needs to invoke .exe with UI ). I am getting an exception as Access denied while writing to network drive. I am passing the UNC path from config file. i tried giving full control access to anonymous user on the folder which i want to access but its still not working. i cannot run my windows service under Network service account or under any other account as suggested in some other posts because i want it interact with desktop check box checked. is there any way to achieve this?
Edit: UNC path of network drive: //server/ABC/pqr
my service should create .txt file in pqr folder. should have access to delete it afterwords too.
i have tried creating anonymous user for pqr folder and giving it full control but still i am getting access denied exception. as i mentioned before i cannot run it under any other account other than local system account because it will automatically disable interact with desktop option in the properties of that service. is there any way to make it run under Network Service Account and still keep it interactive(interact with desktop option checked in the properties of service)?
Try using the following nugget package named SimpleImpersonation
This way you could wrap the code you use to access your remote file location like this:
using (Impersonation.LogonUser(domain, username, password, logonType))
{
// do whatever you want as this user.
}
It worked for me. I used it to turn on and turn off a windows service remotely. Like this:
await Task.Factory.StartNew(() =>
{
using (
Impersonation.LogonUser(serviceInfo.Domain, serviceInfo.User, serviceInfo.Pswd,
Environment.MachineName.Equals(serviceInfo.ComputerName,
StringComparison.InvariantCultureIgnoreCase)
? LogonType.Network
: LogonType.Interactive))
{
var service = new ServiceController(serviceInfo.ServiceName, serviceInfo.ComputerName);
if (service.Status == ServiceControllerStatus.Stopped)
{
service.Start();
service.WaitForStatus(ServiceControllerStatus.Running, TimeSpan.FromSeconds(60));
}
else
{
service.Stop();
service.WaitForStatus(ServiceControllerStatus.Stopped, TimeSpan.FromSeconds(60));
}
}
});
(the snippet was taken from the project site)
Related
I need to read some files from a mapped drive, I have to access this drive in a mapped way because it is outside the domain. This is troubling me because if I run my code as a Console application in C#, I can access it correctly, instead if I convert the same code to Windows service I can not: it throws me an exception in Event Viewer saying that the username and password are not correct. I've been looking information about but I couldn't find a clear answer.
I'm getting this from event viewer.
"Access to the path is denied"
I've tried to set my service to run as User account.
also setting the credentials in ProjectInstaller class like this
serviceProcessInstaller1.Account = System.ServiceProcess.ServiceAccount.User;
serviceProcessInstaller1.Username = "domain\\UserName";
serviceProcessInstaller1.Password = "password";
maybe it is not possible to access?
I have a .net/c# web app (web api) with windows authentication. The service is hosted on my local computer, IIS 10. Application pool identity set to me, currently logged in windows user. Computer is in active directory domain.
I want to access shared file using account, currently logged in to the app. File has appropriate permissions. For this purposes I use impersonation like this:
if (HttpContext.Current.User.Identity is WindowsIdentity windowsIdentity)
{
using (windowsIdentity.Impersonate())
{
FileStream stream = new FileStream(#"\\server\share\file.ext", FileMode.Open, FileAccess.Read);
}
}
I logging in with current windows account, the same as set in app pool identity. This works fine with a shared file on a local computer, where the app is hosted. But does not work with a remote shared file, located on another computer. The other computer is in active directory domain too.
From a hosting computer I can access shared file using windows explorer or my browser. Also if I do not impersonate user, .net trying to access shared file with application pool identity account(set to the same user, me) and it succeeded for both, local and remote files.
It also works with impersonated identity got from LogonUser method from advapi32.dll. But it requires user password and I do not want to request password from user, already logged in to app.
What am i doing wrong?
Update: If a shared file located on hosting machine, then logon event generated by windows (security tab in event viewer) shows the right user. If a shared file located on another machine, then logon event generated by windows on this machine shows the anonymous user. So, account somehow lost.
Update 2: Impersonation works if I run site on IIS like localhost(localhost in url). But if I run it using ip or site name it stops working.
Update 3: Wireshark shows the request for getting ticket(to access shared file server) for delegation fails with error "KRB5KDC_ERR_BADOPTION NT Status: STATUS_NOT_FOUND". Delegation for application pool user allowed in AD.
The same ticket(for cifs/fileshareservername) without delegation can be successfully retrieved(wireshark shows) when doing Dir command in cmd. Seems like problem in AD.
Can't for sure if what you're doing is wrong, but I can tell you what I've done to do a very similar thing. My .Net site doesn't have WindowsLogin normally, so I had to make an extra jump that I think you could do to facilitate the same thing, just perhaps not the best answer.
At login ( in my membershipProvider ) I run this code:
try
{
if (LogonUser(user,domain,password, [AD_LOGIN],
LOGON32_PROVIDER_DEFAULT, ref handle))
{
IntPtr tokenDuplicate = IntPtr.Zero;
if (DuplicateToken(handle, SecurityImpersonation,
ref tokenDuplicate) != 0)
{
// store off duplicate token here
}
}
}
finally
{
if (handle != IntPtr.Zero)
{
CloseHandle(handle);
}
}
then when you need to impersonate, do this:
var context = WindowsIdentity.Impersonate(tokenDuplicate);
try
{
// do your file access here
}
finally
{
context.Dispose();
}
I had to do some funny conversion of that tokenDuplicate variable. It's an integer value but pointing at a specific memory address where the token information is stored. It stays good as long as your logged in.
Why you can't do the impersonate directly on your identity, don't know. I just know it worked for me with a token, and that was my method to get a token I could use for impersonation.
It started working for me with the following settings.
IIS:
Application pool identity set to a specific user(let's say IISUser).
Windows authentication enabled for IIS site. Kernel mode enabled (important!).
All other magic is happening in Active directory:
Computer with shared files has an SPN: cifs/%computer_name%.
Hosting computer(where IIS installed) is trusted for delegation. Delegation tab -> Trust this computer for delegation to specified services only -> Use any authentication protocol. Then select SPN from item 1. Important: you should select computer SPN, not IISUser SPN.
IISUser is trusted for delegation for SPN from item 1.
I deployed my internal web application to server A and got an error when creating a file to a network drive on server B. If I run locally, the file got created on server B successfully.
System.UnauthorizedAccessException: Access to the path '\\b\folder\test.pdf' is denied.
The identity of the application pool is networkservice. And I gave networkservice full control on the destination folder on server B. I even gave Everyone full control, but it still got the error.
Server A runs .NET 7.5. Code to create file:
var byteArray = generateArray();
var destination = "\\\\b\\folder\\test.pdf";
try {
var destinationFile = new FileInfo(destination);
if (destinationFile.Exists) {
destinationFile.Delete();
}
System.IO.File.WriteAllBytes(destination, byteArray);
} catch (UnauthorizedAccessException) {
//
}
I've seen someone got the exact same problem here. But it didn't solve mine.
Solution:
I changed the identity to administrator account instead of using network service for the application pool. It works but I don't fully understand why it works. Because the network service on A is different than the one on B?
Even though you provided access to everyone, certain applications have to receive specific permission. This was apart of the UAC System introduced in Window's Vista. This move was to increase security, so an application couldn't run under any user and basically have full access.
What you should do, is on the directory provide the following access:
IIS AppPool\NameOfAppPool
That will provide specific access to your hosted web application to that directory, for IIS will be able to correctly manipulate the directory. Some code you could implement to help validate before you write or read, would be:
public static bool ValidateIOPermission(string path)
{
try
{
if(Directory.Exist(path))
return true;
else { Directory.CreateDirectory(path); }
}
catch(Exception ex) { return false; }
}
The above code is a small sample, basically try to perform the action and catch the exception, that way you know if you have access or not.
I'm using EWS to grab file attachments from emails in an inbox, and need to put those files (if they meet certain criteria) onto a network directory path that requires an active directory user/pass that is not the same as what the machine running the service is using.
There's probably multiple ways to attack this. Without having to set that directory path to allow the user/pass that is running the windows service to have rights to read/write is there a way in code that I can set the user/pass before I try and place the files in that path?
In the installer setup of the windows service I've tried the following:
this.serviceProcessInstaller1.Account = System.ServiceProcess.ServiceAccount.User;
this.serviceProcessInstaller1.Password = "password";
this.serviceProcessInstaller1.Username = #"\\serverName\user";
when I try and install I get an error about mapping the user pass, so I tried this:
this.serviceProcessInstaller1.Account = System.ServiceProcess.ServiceAccount.NetworkService;
this.serviceProcessInstaller1.Password = "password";
this.serviceProcessInstaller1.Username = #"\\serverName\user";
the installer works, the service shows up and I can start it, but when I debug/attach to the process it throws an exception when trying to write to the directory about access rights.
So maybe I'm not even attacking the right issue/section, as this is probably an active directory issue and something not done in code.
Any suggestions?
What you tried there is irrelevant to your problem.
If you're on windows 7, you may workaround by going to [Control Panel]->[User Accounts]->[Credential Manager] to store login information of target machines.
I have a C# 2.0 (WinForms) project in which I try to activate word 2003 (word is installed on the system). By using the following code:
private void ActivateWord()
{
this.Activate();
if (m_WordDocument != null)
{
try
{
m_WordDocument.Activate();
if (m_WordDocument.Application != null)
{
m_WordDocument.Application.Visible = true;
m_WordDocument.Application.Activate();
}
}
catch (COMException comEx)
{
ShowError(this, comEx.Message, false);
}
}
}
When my application executes m_WordDocument.Application.Activate() I receive a COM Exception 0x800A11F9.
Stacktrace:
"System.Runtime.InteropServices.COMException (0x800A11F9): Cannot activate application
at Word.ApplicationClass.Activate()
at Roxit.SquitXO.GUI.DocumentCreatie.frmSelectVeld.ActivateWord()"
What could be the cause of this problem?
COM error 0x800A11F9 is a well-known permission problem that occurs when an underprivileged user (such as Network Service) tries to activate an Office application.
In your case, the problem can't come from IIS since you're developing a WinForms application. Rather, it looks like your app is started by a Windows service running under the Local Service or Network Service user account.
If that's indeed the case, you need to change the user account used by the service in the Log on tab of the service's properties dialog box.
EDIT: You might want to try putting the code that activates Word into a COM+ component and configuring the identity of the component so it runs under a user account that can launch Word.
Just a thought i've seen a similar error when doing word automation on the server (which we no longer do due to flakiness), however at that time it was caused by permission issues from the ASP.net account, I know you are running in winforms but could this possibly be related to permissions ?
If it is a permissions problem, and you can't get Sitecore to run as a user with sufficient permissions, perhaps you could write a different service ("WordService") for your Sitecore application to send requests to. Then WordService could run as a slightly more privileged user, do your stuff with Word, then e.g. write the filled-in Word file to a known location SiteCore can access, or whatever you want it to do.