I am having an issue accessing a webservice with impersonate without a specified user.
Works:
<identity impersonate="true" userName="DOMAIN\USERNAME" password="MyPassword" />
Doesn't Work
<identity impersonate="true" />
While debugging I used the code below to verifiy the correct Domain and Username were being used, they are.
System.Security.Principal.WindowsIdentity.GetCurrent().Name;
Here is more of my web.config
<authentication mode="Windows" />
<identity impersonate="true" />
<authorization>
<allow users="*" />
<deny users="?"/>
</authorization>
I am logging into the prompt, image below
Any ideas why it will only work when I specify a user in the web.config? I am logging in with the same Domain\Username and password that I put into the <identity impersonate="true" userName="DOMAIN\USERNAME" password="MyPassword" /> . I've tried with multiple accounts and they all work when I put their credentials in the web.config but none work with identity set as<identity impersonate="true" /> and logging in.
EDIT
The remote server returned an error: (403) Forbidden.
EDIT 2
Everything works fine while debugging and while hitting the service on the server that contains the IIS it is hosted on, I've tried with multiple accounts and they all work. Everything is on the same domain
Note the following text from https://support.microsoft.com/en-us/kb/306158
Impersonate a Specific User for All the Requests of an ASP.NET
Application
To impersonate a specific user for all the requests on all pages of an
ASP.NET application, you can specify the userName and password
attributes in the tag of the Web.config file for that
application. For example:
Note The identity of the process that impersonates a specific user on a thread must have the "Act as part of the operating system"
privilege. By default, the Aspnet_wp.exe process runs under a computer
account named ASPNET. However, this account does not have the required
privileges to impersonate a specific user. You receive an error
message if you try to impersonate a specific user. This information
applies only to the .NET Framework 1.0. This privilege is not required
for the .NET Framework 1.1.
To work around this problem, use one of the following methods: Grant
the "Act as part of the operating system" privilege to the ASPNET
account (the least privileged account).
Note Although you can use this method to work around the problem,
Microsoft does not recommend this method. Change the account that the
Aspnet_wp.exe process runs under to the System account in the
configuration section of the Machine.config file.
You could setup the Aspnet_wp.exe process to run as the user you are trying to impersonate to get the desired privileges.
This has also been discussed before: How do you do Impersonation in .NET?
It could be the NTLM double-hop authentication issue. In short, ensure that Kerberos SPNs are properly set so it is used instead of NTLM. This MSDN blog post has a great explaination.
http://blogs.msdn.com/b/besidethepoint/archive/2010/05/09/double-hop-authentication-why-ntlm-fails-and-kerberos-works.aspx
Alternatively, basic or forms authentication will also achieve what you're looking to accomplish. This is because the application will have the user's credentials and, if properly configured, can use them to access back end resources.
You may also want to look into Kerberos delegation. Its a way to restrict that second hop to just one resource via it's SPN.
Related
I have an existing mvc webapi system that uses no authentication or authorization and I am attempting to add Windows authentication in. I approached this by creating a new simplified system with a single controller returning just static data.
The new system is set up to use Windows authentication, and as a result when I hook into the Application_AuthenticateRequest the HttpContext.Current.User is not null and has a populated Identity property with the correct WindowsPrincipal for the user sending the request.
In the existing system, when I amend the web.config to match the new (working) system all incoming requests have a null HttpContext.Current.User in Application_AuthenticateRequest.
I saw a post suggesting that I use the Application_AuthorizeRequest event handler as it is fired later in the pipeline. As expected the HttpContext.Current.User is not null at this point, however the Identity property of this is set as having an impersonation level of Anonymous and importantly is not authenticated.
I assume that my production system that I am trying to add authentication to is somehow configured to not use impersonation, yet my new proof of concept system is. As a result the Authenticate stage of the pipeline is adding an anonymous user to the HttpContext which is what I am seeing in the Authorize stage of the pipeline.
My question is how do I configure my production system to use impersonation so that I can access the user that has sent the request?
Please note that the system is deployed to an intranet so the Windows identity of the user is all I need and gives sufficient security.
my web config contains the following:
<system.web>
<compilation debug="true" targetFramework="4.6.1" />
<httpRuntime targetFramework="4.6.1" />
<authentication mode="Windows" />
<identity impersonate="true" />
<httpModules>
</httpModules>
</system.web>
in both systems (production and POC) and I have tried removing the <identity/> element from both and it appears to have no effect.
At this stage I am hosting only in IISExpress through VS2015
Turns out this was all down to IIS configuration.
When hosting a site within VS2015 using IISExpress, the applicationhost.config file that is used by IISExpress is one stored locally with the soure. Specifically in the $(SolutionDir).vs\config folder.
The config for my production system had windows authentication disabled and anonymous authentication enabled, and the POC system had the reverse. Changing this config file has fixed my problems, now the question is whether this will work on another user's PC or will an incorrect applicationhost.config file be generated??
I need to create an ASP .NET web page (hosted on Windows Server 2008R2 with IIS 7.5) which should be visible by domain users and anonymous users without prompting credential requests for both of them. Domain Users should be authorized to see the entire page, while anonymous users can see the public part of the page.
When I enable Windows authentication: domain users can see the entire page, but anonymous users are prompted for credentials.
When I enable anonymous authentication or both (anonymous and windows): anonymous users can see public part of the page, but domain users do not see the entire page (they are like anonymous users).
I use the following string to discriminate anonymous users and domain users:
WindowsAccountName = HttpContext.Current.Request.LogonUserIdentity.Name;
If WindowsAccountName is empty user is anonymous, otherwise is a domain user. Unfortunately, when anonymous authentication is enabled WindowsAccountName is always empty (even for domain users), but when anonymous authentication is disabled non-domain users are prompted for credentials.
Do you have any solution for these problem? Keep in mind that domain users are spread among different networks so IP address is not a good choice to discriminate domain users and non-domain users.
it looks like a catch-22 for me
Thanks.
The term for this is Mixed-Mode Authentication. I have done this multiple times.
This can be accomplished by using a windows authenticated site that does no more that pull the users credentials from AD and pass those to the anonymous site. I have done this using a custom ticket (GUID in a database) that expires in 5 seconds. The anonymous site takes the GUID passed, queries the DB and obtains the user id. Other ways I have done this with an encrypted URL parameter that contains the user id and time-stamp.
Internal Site
Create a Redirect URL Site: Setup this site as Window Auth so you can pull the User ID from Active Directory. Give your users this URL and/or make it the link they click on your Intranet. Then this site calls your anonymous site and passes the user credentials (login id).
a. This can be done either via an encrypted string on the URL or encrypted value in a cookie. You can encrypt with an expiration date/time value too.
b. (Speaking from Forms Auth) Create a Forms Authentication Ticket with that user ID. Run any other login logic you have. Done.
External Site - No Changes required. Let the users login as-is.
I don't know if it's too late to post this.I recently worked on enabling anonymous authentication on one page in the .NET 4.8 MVC application.
Let's say the page was accessible via URL: User/MyCustomPage
Application configuration was as follows:
1. In web.config authentication mode was specified and authorization was
set to deny for anonymous users.
<system.web>
<authentication mode= "windows"/>
<authorization>
<deny users="?"/>
</authorization>
</system.web>
2. In the controller, authorize tag was there.
3. In IIS, windows authentication was enabled, and anonymous mode was disabled.
I did the below steps:
1. Removed authorize tag from the specific controller and added
[AllowAnonymous] tag.
2. Enabled anonymous authentication in the IIS server. Go to
server->authentication-> Anonymous-> click Enable in the right pane.
3. I had to add the particular path, to exclude it from regular
windows authentication by writing the below code in web.config file.
<location path="User/MyCustomPage"/>
<system.web>
<authorization>
<allow users="?"/>
</authorization>
</system.web>
</location>
But Still, I was getting prompt for windows credentials on accessing the above URL. The reason I found that was:
The View that MyCustomPage was returning, was consuming another resource.
So, I have to add that path too in the web.config.
<location path="Bundle/Content/css"/>
<system.web>
<authorization>
<allow users="?"/>
</authorization>
</system.web>
</location>
I have an ASP.NET MVC4 website deployed on IIS with Windows Authentication enabled. My config file has this setting:
<authentication mode="Windows" />
<authorization>
<deny users="?" />
</authorization>
My understanding is that this will allow me to authenticate without having to type in credentials; i.e. an intranet site.
This works as intended, except for the first page load. When I first access the website, I am directed to the following URL:
http://localhost/SandboxWebsite/login.aspx?ReturnUrl=%2fSandboxWebsite
This is obviously a page that asks for credentials. When I then navigate again to http://localhost/SandboxWebsite/, I am automatically authenticated without having to enter any credentials.
Why is this occurring and how can I prevent it?
The problem was that, whilst anonymous access was disabled as a setting, there was no authorisation rule to deny anonymous users. Why this redirected me to Login.aspx I do not know, but I fixed it by adding the following rules.
IIS > MyWebsite > .NET Authorization Rules
John,
this is a long shot but have you tried using an address other than LocalHost to access the site ? It may be that your ASP.NET MVC4 website is expecting a specific domain name/computer name or IP address because of the way it was setup.
You could alter your hosts file to test this out.
Hope this helps.
Dorje
I tried to create an authentication system in aspx using Windows Authentication. It seems to be the default mode for authenticating users in an intranet, for a company using Windows PCs. I enabled 'Windows Authentication' for my site in IIS, and disabled the other types of Authentications. This is my Web.config file:
<system.web>
<authentication mode="Windows" />
<compilation debug="true" targetFramework="4.5" />
<httpRuntime targetFramework="4.5" />
</system.web>
What I have is a feedback provided by this line in my code (always false)
Response.Write(User.Identity.IsAuthenticated.ToString());
I'm not sure I'm doing all in the right way, but I've read many tutorials and all seems so easy... so, what I miss to do? I'm doing something wrong?
I haven't found anything that helped me in the implementation, simply all what I wrote seems to do nothing. Uh, also I don't see the Windows Auth Dialog
I solved adding a row in 'Authorization Rules' in IIS. In my company we all are admin, so I added an allow rule for admin users and I denied the access for others. All works correctly now, I show the Windows Auth Dialog and with username and password I am able to authenticate.
Check these requirements:
Windows authentication is enabled in IIS (you did it already).
Anonymous access is disabled in IIS (http://technet.microsoft.com/en-us/library/cc731244(v=ws.10).aspx).
Windows authentication is enabled in client's Internet Explorers.
impersonation is switched on in web.config ( http://msdn.microsoft.com/en-us/library/134ec8tc(v=vs.140).aspx).
As far as I remember, that's all.
Here's my scenario:
I have an intranet application. I want to let the network users automatically get logged into the application using the Windows Authentication features. If the user isn't into my network, I'll pop up to them a login screen.
So, I changed the authentication mode into web.config file to Windows. Then I'm using the HttpContext.User.Identity object in order to get the logged user into the network. So I ran the app into my localhost and it works great.
When I publish the application into the server, when I try to automatic log in, the Identity object is always empty.
So, I've tried the following steps:
Deny anonymous users. <deny users="?"/>, which not allows any anonymous users to enter in the application, but I got a problem here: when the user isn't into our network, the server pops up that default authentication window from Window Servers, not my personal login screen.
Let anonymous users in. If I get rid with that <deny users="?"/>, any user can access the page, but it ALWAYS goes to the login screen, even if I'm into my local network.
So, what I need is: when the user is into the local network, go straight without login. If they aren't, pop up a login screen to them.
Can someone help me to figure out what's going on?
Thank you all!
Do the following,
<identity impersonate="true" />
<authentication mode="None" />
<authorization>
<deny users="?" />
</authorization>
Hope it helps.