My web app is set to use Windows Authentication and Impersonation is set to true.
<authentication mode="Windows"/>
<identity impersonate="true"/>
When I run it on my local machine (IIS6), I access Active directory with my current login.
WindowsIdentity curIdentity = WindowsIdentity.GetCurrent();
WindowsPrincipal myPrincipal = new WindowsPrincipal(curIdentity);
However when I access my site remotely Impersonation does not seem to be working; I display the groups that the user belongs to - and get a very short list!
What else do I need?
Impersonation does not pass credentials more than 1 hop between machines. So your creds go from your machine to IIS but no further, accessing active directory is a 2nd hop. When everything runs on the same machine (as in your local case), it will work fine.
http://msdn.microsoft.com/en-us/library/aa292118(VS.71).aspx
I'm pretty sure you need to be specifying a user:
<identity impersonate="true" userName="contoso\Jane" password="pass"/>
Otherwise it will use the ASP.Net user, which will have limited privileges.
See here for more information (including how to store the username/password encrypted).
Related
I have a web app, in the web.config, I have following settings:
<authentication mode="Windows"/>
<identity impersonate="true" userName="domain01\user01" password="***"/>
I deployed the app to Windows 2008 (IIS 7), the Identity of the application pool is domain01\user01, and in the Authentication of the app, I have following set:
Anonymous Authentication Disabled
ASP.NET Impersonation Enabled
Basic Authentication Disabled
Digest Authentication Disabled
Forms Authentication Disabled
Windows Authentication Enabled
Now I need to get the user name who is currently logged on the machine, could be any authorized user with different domain. But no matter what I tired, I always got the impersonated user domain01\user01. I tried, HttpContext, WindowsIdentity, etc. Does anybody know how do I get the correct user name without changing my settings?
You are specifying domain01\username as the identity that you want to impersonate. That is why the current user is always that. If you remove the configured identity you will get the actual logged in user.
<identity impersonate="true" />
This is documented here:
http://msdn.microsoft.com/en-us/library/xh507fc5(v=vs.85).aspx
In my current ASP.Net site, I am already using impersonation to run all of the requests under:
<authentication mode="Windows">
</authentication>
<identity impersonate="true" />
Then, I want to grab the status of a service. this creates a double hop, so I impersonate a specific user. I am then able to query the service on the remote machine.
I then want to undo the specific impersonation and revert back to the users original impersonation.
When I try the examples linked below, it always reverts back to the ASP.Net user.
How do you do Impersonation in .NET?
Help Understanding Impersonation
My page/controller needs to follow the following example:
1) Request made as BoFlexson --Auto impersonates as BoFlexson
2) Impersonate ServiceUser: Ask for Service Status
3) Revert Back to BoFlexson: Do some other task.
4) Impersonate ServiceUser: Ask for Service Status Again
5) Revert Back to BoFlexson: Do some other task.
Again, when I try to Undo the impersonation context, it goes all the way back to the ASP.Net user, as if I didn't have the <identity impersonate="true" /> setting at all.
Any help with this would be greatly appreciated.
code:
System.Security.Principal.WindowsImpersonationContext impersonationContext;
impersonationContext =
((System.Security.Principal.WindowsIdentity)User.Identity).Impersonate();
//access network resources.
impersonationContext.Undo();
web.config:
<authentication mode="Windows">
</authentication>
<identity impersonate="true"
userName="user"
password="password"></identity>
As clear from web.config file, the app runs in an impersonated mode. I need to impersonate temporarily on top of that to access a network resource. I do that as shown above.
This works fine on server if I browse to the website on the local IE installed on the server but when I access the app from my PC or any other PC, I get a access denied.
Btw, this is all within an enterprise domain environment. so IE in both cases is passing a valid authenticated token.
Any ideas what is going on. thanks.
You need to make sure the server will delegate the impersonated security contexts in your application to another server (the network resource you mentioned).
I'm pretty sure it works while you're logged onto your server because it is using the security context of you being logged in directly, and not the impersonated context that exists in the application.
I can't remember specifics on configuration but I do know it is referred to as delegation or "Kerberos Double Hop". "Constrained Delegation" is when you configure such that only one type of delegation is allowed. IE, your app is only allowed to delegate security contexts when talking to Active Directory (port xyz) on this other specific server - otherwise not.
See Understanding Kerberos Double Hop
See DelegConfig - it is helpful in configuring delegation.
Also see: TechNet Article
And: this other article
I'm trying to use Impersonation and Delegation in an intranet ASP.Net web-app in order to pass authenticated users' credentials onto a SQL Server.
The web server and SQL server are two separate machines, but in the same domain, so Delegation is required.
I've done the following:
set <authentication mode="Windows"/> and <identity impersonate="true"/> in my web-app's web.config.
enabled Constrained Delegation from the web server to the MSSQLSvc service on the SQL Server, in Active Directory.
enabled only Windows Authentication in the website, through IIS.
Apparently this should all work, but it doesn't (the SQL Server is denying access to the anonymous user - "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'").
In IIS7, the Application Pool is set to use Integrated Pipleline Mode and is running with the NetworkService Identity. The website only has Windows Authentication enabled, Extended Protection is Off, Kernel-mode authentication is enabled, and NTLM is the provider.
All the web pages I've read seem to indicate that my setup should work. What am I missing?
I've discovered the answer:
The Windows Authentication provider in IIS7 must be set to Negotiate:Kerberos, not NTLM. This means that the Kernel-mode authentication setting must be disabled. This seems to be fine. I think I'm right in saying that Kernel-mode authentication is required when using a custom identity, i.e. one specific identity. Delegation can use an arbitrary number of identities. So all is well.
I've written a blog post about this too, which goes into a bit more detail.
No - it is not accurate to say you need Kerberos, an SPN, to trust the server for delegation, and that this is the ONLY way to do it. Yes, this is one way to do it (and you do need all of it to make it happen via Kerberos), but it is not the ONLY way, or even technically the most secure way or easiest way. Do you really want to have to do extra configurations and create a login for every web user to your DB in SQL? What if any one of those accounts is compromised? More accounts, more vulnerabilities.
No, create a Domain service account, instead, and let that access SQL. If your security guys lock down things, give that user these rights: Logon as a service, Logon as a batch job, and Allow logon locally. Or, if this is just to develop and test the theory or you don't care or can't find the settings or are still getting errors later on, and this might not get a large following, but give it local Admin (sometimes you gotta do what you gotta do - some security pros lock down things tighter than I would care to write about - can always troubleshoot security later to lock it back down). Then set that account as the custom account on the app pool and give that account a login in SQL. Give it dbo on just THAT ONE database.
On the website in IIS, set the authentication type as Windows. I've seen them say "Basic" in other blogs so Kerberos will work, but NTLM uses Windows authentication. In IIS 7, you may also want to enable ASP .NET impersonation. Personally, I've only tried this on IIS 6, but the principal is the same.
In the web.config, add this under <configuration>, which is a "peer" to <system.web>:
<connectionStrings>
<add
name="NorthwindConnectionString"
connectionString="Data Source=serverName;Initial
Catalog=Northwind;Integrated Security=SSPI;User
ID=userName;Password=password"
providerName="System.Data.SqlClient"
/>
</connectionStrings>
And in <system.web>:
<authentication mode="Windows"/>
<identity impersonate="true"
userName="domain\user"
password="password" />
Then read the string into your app like this:
using System.Configuration;
string connString = String.Empty;
if (ConfigurationManager.ConnectionStrings.ConnectionStrings.Count > 0)
{
connString = ConfigurationManager.ConnectionStrings["NorthwindConnectionString"].ConnectionString;
if (connString != null) // do DB connection stuff here
Console.WriteLine("Northwind connection string = \"{0}\"",
connString.ConnectionString);
else
Console.WriteLine("No Northwind connection string");
}
See http://msdn.microsoft.com/en-us/library/ms178411.aspx.
If it will not connect with the service account after filling in that account in the web.config for the impersonate tag and the SQL connection, you can then use impersonation methods using WindowsImpersonationContext (http://msdn.microsoft.com/en-us/library/system.security.principal.windowsimpersonationcontext.aspx). Specifically, you want wic.Impersonate() and wic.Undo() after getting their token. You can read in the service account domain, name, and password from the web.config, in the form of AppKeys.
In short, there are ways around the issues. You can even encrypt the password in the web.config - both in the ConnectionString, and if you want to store it in an AppKey instead of directly in the "impersonate" tag, if you don't want plain text passwords in there (which I'd recommend against), and so you can have it for the creation of a Logon token, if you need to use the Impersonation methods (as I did).
How can an application, running on a production server, access the login username of the machine that a user is accessing an application from? For example, I am currently logged into my machine on the INTRA corporate intranet. My username will be INTRA\Username.
I have added specific usernames to a database and wish to check this intranet username against the database to restrict access to an application and leverage the username across the application.
Currently, I am using the following code to access the username:
Private username As String = Thread.CurrentPrincipal.Identity.Name
This is working great on localhost, but when authenticating against the database on a development server, I'm getting the following error:
Login failed for user 'NT
AUTHORITY\ANONYMOUS LOGON'.
Is this an incorrect approach? Is this even possible, or is it too much of a security issue? This application will be an internal intranet application running in an IE shop. Relevant pieces of web.config that already exist include:
<identity impersonate="true"/>
<authentication mode="Windows"/>
<authorization>
<deny users="?"/>
</authorization>
<connectionStrings>
<add name="CONNSTR" connectionString="Initial Catalog=DATANAME;Data Source=servername;Integrated Security=True;" providerName="System.Data.SqlClient"/>
</connectionStrings>
When setting up your web application on the server, you need to go into the Document Security section (the name of it changes depending on what version of IIS your server is running, but it's something like that), turn off anonymous authentication, and turn on Windows authentication. That tells the server to request windows login authentication from the browser. (Perhaps someone who knows web.config files better than I [which is nearly anyone] can edit this to point to the relevant bit; I don't think it's impersonate but if I knew, I'd say. I've so far only done this via the UI.)
in your example, you are locating the username that your webserver is running under. What you are after is the username of the user accessing the page.
Try something like this:
How To: Use Windows Authentication in ASP.NET 2.0
If setting the directory security to Windows Authentication is not working, change it to Basic Authentication. You'll also need to specify the domain name to authenticate against. This was the only way we could get the security to propagate through from the IIS layer to the DB. Unfortunately this causes the username and password to be sent through clear text. Its not the best solution, but since things were on the Intranet, it worked while we work on updating our login procedure.