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.
Related
I am trying to set up a Test server to try out asp.net (3.5) web applications before they're moved to Production. I want to mirror the settings in IIS from Production server. On my web app, application pool is set as Classic .NET AppPool with identity NetworkService and Windows Authentication is enabled. When I attempt to access app on Test server I get error "The EXECUTE permission was denied on the object 'GetTable', database 'DatabaseName', schema 'xxx'. I realize I can add the network account to that stored procedures security but I shouldn't have to - it works in production without it.
I am using a restored copy of the production database thus the permissions are identical between the two. I did have to add the querying Test server name (i.e. xxx\Test$) to the database security in SQL server to gain access to the database, but I shouldn't have to add other local network permissions as they are included in the Security Logins of SQL (public).
In Windows Event Log* on Test server this piece of the error detail bothers me because the "Thread account name is NT AUTHORITY\NETWORK SERVICE compared to when a permission error is thrown on production server the Thread account name is the name of the user.
I think I need to get the Test server to recognize the real user. I (obviously) do not understand security to the fullest for web apps yet. Can someone suggest other areas for me to investigate? I did research this but I'm only finding things like how to change the apppool account, or identity, not the piece that troubleshoots permissions between client to web server to database server. BTW the production and test databases are on the same server. The product and test applications are on different servers (both Server 2008/IIS 7).
There is one difference: ASP.NET 1.1 application pool is not installed on IIS on Test server. Could that be the issue?
*Windows Event Log snippet:
Request information:
Request URL: http://server/appname/default.aspx
Request path: /appname/default.aspx
User host address: xx.xxx.xx.xx
User: xxx\username
Is authenticated: True
Authentication Type: Negotiate
**Thread account name: NT AUTHORITY\NETWORK SERVICE**
BTW if I move my test app to production server in a new folder, it works fine. Problem is with the test server configuration.
ANSWER: Set Active Directory for IIS server to say "trust this computer for delegation". I found my answer from a 2007 entry posted by plq in this: Microsoft ASP.NET forum
ANSWER: Set Active Directory for IIS server to say "trust this computer for delegation". I found my answer from a 2007 entry posted by 'plq' in this forum: Microsoft ASP.NET forum
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 am working on a C# Asp.net site that adds users to Active Directory and assigns them to security groups.
The whole script works great except for one issue. I can add users to groups, but I get an "Access Denied" exception when trying to add the user to a group that the Application Pool's Identity is a member of.
I think it's a windows permissions issue, but I'm not sure what permission is required. We had the same issue in the past when using an older VB script.
Any ideas?
I had this kind of issue with a website designed for active directory management. The execution environment was not allowed to manage AD so far. So, through IIS, we changed the default account to local system, who has full permission (almost, he can't reboot the system for example) and cannot be logged (security first). This works for you are impersonating your website.
If not, You will need an advanced group and user management. AD permissions are very touchy.
Edit:
In your case, using a specific account is not a problem. Check the identity when your admin logs, and use impersonation with Local System. Your application environment will be alright, and only your admin will have an access.
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'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).