My web app (asp VB 2005) uses Windows authentication. If the user isn't part of a specific AD security group they don't get to edit the data; instead I redirect the user to a read-only page.
The program works fine in the IDE.
I published the web app to my laptop and Disabled anonymous access. When I ran the program I got redirected to the read-only page. I added a write event to the application event log to see what was going on, and found that the WindowsPrincipal.Identity.Name contained my laptop's ID, not my user name.
I reassert: anonymous access is disabled in IIS and the web.config file has Windows Authentication.
Can anyone suggest what else to check? Or can you explain what's going on?
You probably need to set <identity impersonate="true" /> in your web.config:
<configuration>
<system.web>
<identity impersonate="true" />
See http://msdn.microsoft.com/en-us/library/72wdk8cc.aspx for more details.
Related
I can't figure this out for the life of me. I'm trying to get the name of the current user logged onto Windows using the following line:
string user = System.Security.Principal.WindowsIdentity.GetCurrent().Name.ToString();
When I run this line after publishing and opening it through IIS, it gives me a name of "IIS APPPOOL/SiteName". However, when I run this through the Visual Studio 2013 debugger, the correct name appears.
I've fiddled around with the config, IIS settings, and the string...but I think this line is what I needed to use:
string user = System.Web.HttpContext.Current.User.Identity.Name;
Seems to be returning a domain/username which I can use instead. Looks like an alternative solution.
you have to enable windows auth/impersonation on an ASP.NET site, else it will run in the context of the whatever account configured for the app pool.
https://msdn.microsoft.com/en-us/library/ff647405.aspx
<system.web>
...
<authentication mode="Windows"/>
<identity impersonate="true"/>
...
</system.web>
Base on my test under IIS having Windows Authentication only enable and not impersonation on the web.config;
System.Web.HttpContext.Current.User.Identity.Name; return to me the current login user not the application pool user and System.Security.Principal.WindowsIdentity.GetCurrent().Name.ToString() return the application pool user.
I tried again and having he following on the config file:
<system.web>
<authentication mode="Windows" />
</system.web>
For System.Security.Principal.WindowsIdentity.GetCurrent().Name.ToString() I got:
Office\atorr
which is my login account
For System.Web.HttpContext.Current.User.Identity.Name; I got
IIS APPPOOL.NET v4.5 Classic
which is the account the application pool is running.
All mentioned in other answers are true, PLUS THIS:
In IIS Manager, click Basic Settings.
In the Edit Application window click Connect as...
Choose Application User (pass through authentication). Do not use a specific user because that will be the identity detected.
Click on the project name and press F4 and it will open project properties window:
Enable Windows authentication
Disable anonymous authentication
Add <identity impersonate="true"> in web.config
Now, deploy your code it should work fine.
Try This
(((System.Web.Security.RolePrincipal)(ClaimsPrincipal.Current)).Identity).Name
We are creating an intranet site and want to use SSO. The problem is however, that Internet Explorer (11) keeps asking for credentials. By specifying the username and password we are able to access it. Then the intranet application can be used without a problem. When Internet Explorer is closed however it asks for credentials again. The problem occurs on the testing machine (running in a domain) and also on my laptop at home which I also use to develop on. I access the test server with Remote Desktop and then test the site on the same machine as it is running on, which is Windows 2012R2 running IIS 8.5.
On the test server the application (ASP.NET MVC with SignalR and WebAPI) is using a URL that will not be automatically recognized as an intranet site although it is in the same IP range. Therefore I have added the site explicitely to the intranet zone in the settings of IE.
When I then right click on the site and request the properties I can see it is in the intranet zone. This is for as far as I could find the solution in these situations but for us there is something else going on.
This is the system.web section of web.config:
<system.web>
<compilation debug="true" targetFramework="4.5.1" />
<httpRuntime targetFramework="4.5" />
<authentication mode="Windows" />
<authorization>
<deny users="?" />
</authorization>
</system.web>
In IIS I have tried enabling both Windows Authentication and Digest and also just one of those. The other authentication options are disabled, including Anonymous Authentication.
I also added the site to the trusted zone which did not help. Also changed the zone settings (for intranet and trusted) to do "Automatic logon on with the current username and password" but that didn't help either (I don't understand the setting Automatic logon only in Intranet zone though, because it seems a zone specific duplicate setting of the afore mentioned setting but ok). I also checked the advanced settings to be sure that Integrated Windows Security is enabled.
At the moment we're completely out of ideas.
Two more to your checklist:
make sure you have disabled anonymous authentication
make sure the domain controller is accessible from both the client PC and the IIS hosting the web app. Chances are the domain controller doesn't recognize the application server as coming from the same domain.
http://www.wiktorzychla.com/2012/06/iis-75-integrated-security-with-no.html
I have set the Full control to "Domain Users" in the Security Tab (NTFS permissions) of my Application Folder. Which resolved the problem in IE 11 but chrome is continuously asking for User name and password.
Another developer and I are both working on the same ASP.NET web app. The application uses Forms authentication, but the IIS virtual directory is configured with both "anonymous access" and "integrated Windows authentication". This mirrors the production site which authenticates as required.
A potentially key difference between our two setups is that he is on Windows 7 and IIS 7, whereas I'm on Windows XP and IIS 5 (for my sins).
Initially when we both run the app, the variable... HttpContext.Current.User.Identity.IsAuthenticated ...is false. This I'd expect because we're configured with Forms authentication. The app then redirects to a WindowsAuth.aspx page. That page checks the Request.ServerVariables["LOGON_USER"] server variable and, if this isn't null or empty, uses it to automatically sign in.
The issue is, on my PC Request.ServerVariables["LOGON_USER"] is always empty. To me this is correct since we have anonymous access enabled. But on my colleague's PC, and in production, the variable holds the user's username. I cannot understand why this is. Is there a difference between IIS 5 and 7 in this regard? Otherwise, can you explain this? Obviously I want my setup to reflect other environments but upgrading to Windows 7 is a last resort at this point.
https://support.microsoft.com/en-us/kb/306359
To populate the LOGON_USER variable when you use any authentication mode other than None, you can deny access to the Anonymous user in the section of the Web.config file. To deny access to the Anonymous user in the section, follow these steps:
Change the authentication mode in the Web.config file to anything other than None. For example, the following entry in the Web.config file sets the authentication mode to Forms-based authentication:
<authentication mode="Forms" />
To deny access to the Anonymous user in the Web.config file, use the following syntax:
<authorization>
<deny users = "?" /> <!-- This denies access to the Anonymous user -->
<allow users ="*" /> <!-- This allows access to all users -->
</authorization>
If you are using Windows authentication, you can also use the following steps to resolve this problem:
Change the authentication mode in the Web.config file to Windows as follows:
<authentication mode="Windows" />
In the Internet Services Manager, right-click the .aspx file or the Web Project folder, and then click Properties.
If you clicked Properties for the Web Project folder, click the Directory Security tab. If you clicked Properties for the .aspx file, click the File Security tab.
Under Anonymous Access and authentication control, click Edit.
In the Authentication methods dialog box, clear the Anonymous Access check box, and then select either the Basic, the Digest or the Integrated (NT Challenge/Response) check box.
Click OK to close both dialog boxes.
This is a follow on to a previous post about being unable to impersonate a currently logged in Windows user. There were many good suggestions, but the previous thread was getting messy, so I am resetting with this post. Hopefully with the current state documented below it will be obvious what the issue is. This is a well worn path, so I have to believe all I am missing is a little configuration step.
PROBLEM: I need to have ASP.NET impersonate the currently logged in user. When I run under IIS 7.5, it doesn't work. IIS Express works fine, but I believe that is because the debugging session is running under my user id.
I am using Environment.Username to determine who this user is. There was a suggestion that this property always returns the logged in user name, but from my testing it returns the impersonated user from IIS.
For example, if my web.config has…
<identity impersonate="true" />
When I run under IIS 7.5 with that setting, Environment.Username returns IUSR. I believe this is the IIS anonymous user account.
If I change web.config to…
<identity impersonate="true" userName="domain\jlivermore" password="mypassword" />
… then Environment.Username returns jlivemore. However, I need it to return jlivermore without me explicitly setting it in web.config.
Here are my IIS settings…
.NET Authorization Rules
Authentication
One question, if I disable Anonymous Authentication, then I am prompted to login to the site. I thought if you were logged in with an Active Directory account on a domain then this challenge wouldn't appear? Even if I enter my username/password into this prompt, I still don't get the impersonation to work.
Basic Settings
I'm not sure if you've found an answer, but if anyone is having problems with it you will need the following in your web.config file
<authentication mode="Windows"/>
<identity impersonate="true"/>
And in IIS you will need Asp.net Impersonation enabled as well as Windows Authentication enabled, the others should be disabled. And in Windows Authentication, go to Advanced Settings and UNCHECK the Enable Kernel-mode authentication. That should do it. Your site should now be set for Local Intranet apps and using any of the following will work
System.Security.Principal.WindowsIdentity.GetCurrent().Username()
HttpContext.Current.User.Identity.Name
System.Threading.Thread.CurrentPrincipal.Identity.Name
But using Environment.Username will only return the server name, hopefully this helps anyone struggling with this
I had a similar problem as you describe. The basic crux of the matter is that there is a difference between impersonation and delegation. My simple understanding of this is that impersonation will work when the client and server are on the same machine. If however, the client is on a different machine, you need delegation.
MSDN Reference
What is the difference between impersonation and delegation?
Impersonation flows the original
caller's identity to back-end
resources on the same computer.
Delegation flows the original caller's
identity to back-end resources on
computers other than the computer
running the service.
Related SO questions
Impersonation in ASP.NET MVC
Starting a console application from asp.net using authenticated user credentials
Have you tried using
HttpContext.Current.User.Identity.Name ?
I'm trying to enable passthrough or impersonation authentication inside an ASP.NET website that uses the TFS2010 API.
I've got this working correctly with Cassini, however with IIS 7.5 (Windows 7) something is going wrong.
I found this blog post on the subject, and tried the following:
private static void Test()
{
TfsTeamProjectCollection baseUserTpcConnection =
new TfsTeamProjectCollection(new Uri(Settings.TfsServer));
// Fails as 'baseUserTpcConnection' isn't authenticated
IIdentityManagementService ims =
baseUserTpcConnection.GetService<IIdentityManagementService>();
// Read out the identity of the user we want to impersonate
TeamFoundationIdentity identity = ims.ReadIdentity(
IdentitySearchFactor.AccountName,
HttpContext.Current.User.Identity.Name,
MembershipQuery.None,
ReadIdentityOptions.None);
TfsTeamProjectCollection impersonatedTpcConnection = new
TfsTeamProjectCollection(new Uri(Settings.TfsServer),
identity.Descriptor);
}
When I use Cassini nothing is needed besides
collection = new TfsTeamProjectCollection(new Uri(server));
I have enabled the web.config settings (and have the Windows Auth module installed):
<authentication mode="Windows"/>
<identity impersonate="true" />
Is there something obvious that I've missed out?
Solution 1
This is the delegation method. As Paul points out it's a single setting in your active directory:
Find the IIS server in the computers node of the "Active Directory users and Computers" console.
Click on the delegation tab, and select the second option:
Create a 'Cache' directory in your IIS root folder
Add the following to your web.config:
<appSettings>
<add key="WorkItemTrackingCacheRoot" value="C:\path-to-web-root\Cache\"/>
</appSettings>
Make sure your web.config contains:
<system.web>
<identity impersonate="true" />
</system.web>
Turn on Windows authentication and impersatonation and disable everything else in IIS authentication:
Solution 2
Another solution to avoid the steps above is to simply run your application under the TFS:8080 site, as a new application. The hop issue is then removed as you are running in the same context as the web service that your app is calling.
Create a new app pool, use network identity.
Make sure your application has anonymous authentication turned off
Make sure it has windows authentication turned on.
Add <identity impersonate="true" /> to the web config.
I wonder if you're hitting the old Double-Hop issue here?