I'm working on a Windows Service that one of its tasks is archiving files on remote machine but I've problem regarding access privileges "Access id denied".
The service account is "LocalService",
How can I give service access to remote machine?
You'll need to run the service in a dedicated account (such as a domain account) that both machines recognise. Then grant this account the necessary ACL permissions to access the second machine.
If you aren't on a domain, there are things you can do with having the same username and password...
Another approach is to use the "network service" account - this will authenticate with the identity of the machine that is hosting the service; it can work, but personally I like the dedicated account approach - it makes it easier to achieve granular security, and means you can relocate the service to another host without much effort.
LocalService cannot have permissions on another machine, so you'll need to change the service account to something else and make sure the account has the necessary permissions on the remote machine.
A service on server1 that's running under the Local Service principal and that tries to access the folder on server2 is seen as an anonymous connection attempt that is or isn't allowed depending on the policy of server2. So you need to either allow anonymous access on server2 or change the service account (recommended).
Related
I am new to Active Directory and was given a task to fix a bug where a app on one of our servers could not access active directory on another server. The user we are using to bind to active directory is a "Domain Admin" and we are using this user's credentials in a C# application to access active directory with the System.DirectoryServices.AccountManagent classes of .net 3.5.
The server is in the same domain as the active directory server.
After struggling to make the app work, the network administrator set up trust (as a last resort) to the server computer (where the app is installed) and that allowed the app to work.
The network admin said :
"If I open the computer account in AD and click on Delegation (and then select 'Trust this computer for delegation to any service (Kerberos only)' it works!! I can't see why I should need to enable delegation for the server as it's already on the domain anyhow - but it works"
My question is why was this necessary?
It sounds like a programming error where PrincipalContext isn't taking effect. None of these samples change the default service context... If he looks at the event logs he probably sees MachineName$ (dollar sign) logging in.
Try this - Set the service account name from LocalService to the account you want to use with LDAP. It should work, even without domain admin rights.
I have a local Intranet application that does some file validation using Directory.Exists and File.Exists. Unfortunately, the checks fail due to the fact that the application is running as "ApplicationPoolIdentity" and that account doesn't have access to the UNC paths the Directory.Exists and File.Exists are checking.
Should I give that ApplicationPoolIdentity account permissions to read those directories? (All of the directories appear under a top level folder of a single server.) If so, how?
Or, should I run the Application Pool under a domain account and grant that account permissions? (If I do need to create a new account, what permissions should I give it?)
Thanks for any input!
As a rule I normally create a custom account, but if you want to grant additional rights to shares etc. I would say that it is the best option.
Create a new AppPool with a custom identity with the relevant access to the shares. Then have the application run under this new AppPool. That way you can have other applications that do not require access to the shares in AppPools that do not have this access.
If you are using Windows 7 or Window 2008 R2 you might want to look at Virtual Accounts.
Here is a good article on the topic of Application Pool Identities
You need to set read ACLs for the following identity: IIS AppPool\. You can do it either from the folder properties dialog (if your computer is on the domain, make sure Locations is set to the local machine in the "Select Users or Groups" dialog) or using icacls from the command line.
I have a web application set up on our intranet that uses windows authentication (successfully) that I am trying to link to a database running on a separate server.
The problem that I am having however, is that when I try to use a trusted connection to log in to the sql server, instead of passing the domain/username of the person using the website the application is passing NT AUTHORITY\ANONYMOUS LOGON.
I checked that the authentication was working by having the website display a greeting that does identify my username correctly when I log on to the site, so it isn't an anonymous access issue. I think it is an impersonation issue somehow despite the fact that set in the web.config file for the application.
Curiously, the web application works fine when I run it on either my dev machine or even locally through remote desktop on the production server. I'm not sure what's going on here.
Finally, I'm running iis 7.5, windows server 2008 r2 and sql server 2008
This is called Constrained Delegation. Basically what that means is that an impersonated context by default cannot be delegated to authenticate with a resource on the network. If constrained delegation would not be in place anyone could create a web site in the enterprise and expose some benign application. But underneath, once the user authenticated with the site, it could impersonate that user to do anything, like read his mail, sale stock on his behalf, give raises to site developer, *anything. This is why impersonated contexts are not trusted outside the machine that impersonated the user.
To allow an impersonated context to connect to a remote resource (like a file share, or a database server) the domain administrator has to explicitly set up Constrained Delegation, which allows the impersonated context to authenticate with one specific resource.
There are numerous articles describing the problem and the solution:
How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0
Protocol Transition with Constrained Delegation Technical Supplement
How To: Connect to SQL Server Using Windows Authentication in ASP.NET 2.0
Configuring Servers for Delegation (IIS 6.0)
How to: Use Protocol Transition for Impersonating and Delegating the Original Caller in WCF
it is a known behavior called double-hop issue. See http://weblogs.asp.net/owscott/archive/2008/08/22/iis-windows-authentication-and-the-double-hop-issue.aspx
If your web application tries to access your database it does it with the account under which the IIS w3wp.exe process is running (networkservice by default).
If you want to change this, you will need to use impersonation.
This document explains it pretty good.
As the document also explains depending on your application, you might want to use trusted subsystem instead of impersonation.
I have a winforms, and it connecting wit webservice.
Webservice has method which create folder
Directory.Create(path);
Webservice is at company server, and this folder must me create at another disc in out company.
When I invoke this method, i get exception "Access denied to path..."
When webservice was running at my computer everything was ok.
I have full access to this network disc.
But how to set full access to my company server??
When I check this method:
[WebMethod]
public string GetNameOfUser()
{
return WindowsIdentity.GetCurrent().Name;
}
I get <string>NT AUTHORITY\NETWORK SERVICE</string>
Rest of webmethods without directory instructions working properly
Edited Structure
Computer A is in domain and there is running win forms
Server A : there is running webservice
Network disc: there are folders with important files for winforms application
yes, we have a domain.Computer A has access to network disc.
As I understand, your application tries to create a folder which resides on a different server than the web application.
Your web application is running under a local account NT AUTHORITY\NETWORK SERVICE. In order to access a network share you need it to be running under an account available on both machines, for example a domain account.
If both the web server and the server with the network share are on a domain, you can:
Create a domain account
Grant the account write access to the parent folder where you want to create new folders
Make the Application Pool on your web server run under the domain account
This will should let your web application create foldera on the other server.
When you were running your web-app on your own machine, it worked onder your own account, therefore it could create directories.
On the server the app runs under an account with very low rights.
If you want to create those new directories below a specific fixed directory, you can allow that server account to modify that particular directory.
I am using impersonation is used to access file on UNC share as below.
var ctx = ((WindowsIdentity)HttpContext.Current.User.Identity).Impersonate();
string level = WindowsIdentity.GetCurrent().ImpersonationLevel);
On two Windows 2003 servers using IIS6, I am getting different impersonation levels: Delegation on one server and Impersonation on the other server.
This causes issues where I am unable to access the UNC share on the server with 'Impersonation' level.
What could be causing this difference? I searched through machine.config and IIS settings for the app pool, site and virtual directories - but aren't able to find the cause of this problem.
It sounds like one of the computer is trusted for delegation by your Active Directory, but the other is not. If the app pool identity is Network Service, make sure the Computer Account is marked "Trusted for Delegation" in AD.
You may need to ask your AD admin to force a replication and then log out/in to your workstation to refresh your Kerberos ticket cache.
If your testing with localhost as webserver and its working but when deployed you receive errors you could be running into the double-hop issue....outlined in this blog post
For one of our applications where we did Impersonate() we found that we had to modify the local security policy for the application pool owner and add that account to the following policies/groups:
Act as part of the operating system privilege.
Impersonate a client after authentication.
On the server(s), run Start > All Programs > Administration Tools > Local Security Policy then navigate to Local Security Policies > User Rights Assignment and look for the two policies above.