I have a web service running in IIS 6.0 on Windows 2003. It's authentication mode is Integrated Windows security (anonymous disabled), and authorization is done with Authorization Manager and an XML authorization store. My test user is a domain user (admin, actually) with membership in an authorized role.
I am testing this (for now) on the web server (localhost), and using (for now) Internet Explorer to access the web service (.asmx).
I can successfully open the web service (wsdl) page through localhost, like this:
http://localhost:8080/MyService/MyService.asmx
Using this url, integrated windows authentication succeeds (silently), and I am sucessfully authorized by AzMan to access the service. The same goes for the server name:
http://myserver:8080/MyService/MyService.asmx
Now I need to use the external host name (www.mysite.no) to access the service (this in order to get ssl to work with a certificate issued to that sitename). To do this, I add the host name to my HOSTS file, like this:
127.0.0.1 www.mysite.no
...then type this into IE:
http://www.mysite.no:8080/MyService/MyService.asmx
What happens then is that authorization fails. I get the IE/Windows login box and enter my correct credentials three times. Then I get a 401.1:
HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials.
Internet Information Services (IIS)
How is authorization through AzMan influenced by the host name?
Edit: I have reason to believe AzMan has nothing to do with it - it seems to be the authentication that fails.
I have reproduced the problem on another server. The essence seems to be that accessing localhost via an entry in the local host file somehow messes up the integrated windows authentication between the browser and IIS.
I have worked around the problem, now my curiosity is all that's left...
Enable audit login failure auditing & check the security event log on the host.
1) On the webserver, go to Control Panel, Administrative Tools, Local Security Policy.
2) Go to local policies, audit policy. Add failure for 'audit logon events'.
3) Close the MMC. Open a command prompt and type gpupdate.
4) browse to http://www.mysite.no. You will get the error again.
5) Launch event viewer (control panel, admin tools, event viewer). Navigate to the security event log and look for the login failure(s).They shoudl tell you something descriptive, like 'the user has not been granted the specified logon type'. Unfortunately the login type itself is not descriptive; logon type 2 is interactive (locally), 3 is 'access this computer over the network', 5 is 'logon as a service' (NT service, not WCF service). The rights required can be granted in the local security policy.
Also, check to see if you have a proxy enabled in IE. If your traffic is being routed to the proxy, it is possible that the proxy does not support NTLM. Add the host as a proxy exception while you test using IE.
My first guess is that it's not the host name.
The first thing to do is narrow down the problem as there are a couple things that could be going wrong.
First set the IIS site to anonymous access, and make sure you can pull up the web service. That will verify that you're accessing the right IIS web site and it's truly narrowed down to an authorization problem.
Also, check the Application Pool credentials, and the security settings on the file folder containing the web service as these could be contributors.
Related
My company just finish set up a reporting services server 2017.
The service run under a domain name.
At the same server, an IIS has been setup to run a web application in ASP.NET which will server the report from a report viewer. The IIS is currently running with default App Pool.
GOAL : We want client to be able to access the report from the web application without having to fill in the username and password from anywhere be it on intranet or internet.
Before this, we have ssrs 2008 with similar setup but for authentication we go with anonymous authentication, which is what we want, they can view report from anywhere.
But from microsoft site, they stated that authentication isn't supported anymore in the latest version, and we have tried doing it which results in error 401: Unauthorized.
Currently, I'm trying to do a kerberos authentication,
Things that I have done :
SPN for reporting services account.
Delegation for reporting services account.
Web application web.config I've added authentication mode="Windows" identity impersonate="true"
On IIS, I've enabled windows authentication and impersonate.
But when I try to request a report from the web application, I still got the prompt for username and password, when I fill in my domain and password, I still got the same error 401: Unauthorized.
Am I doing something wrong? Is Kerberos really suitable for my GOAL?
Thanks in advance.
EDIT : Sorry, If I am posting in the wrong section. I don't know where is the correct section for this question.
When you are planning to deploy the reporting service on the internet its batter to use the custom authentication instead of the windows authentication. Creating a custom authentication extension requires custom code and expertise in ASP.NET security.
If you do not want to code a custom authentication extension, you can use Microsoft Active Directory groups and accounts, but you should greatly reduce the scope of a report server deployment. The following guidelines describe how to support this scenario:
Create a low-privileged domain user account with read-only permissions. The account must have access to the computer hosting the report server. Provide a custom Web form so that users can log on using the low-privileged domain account.
Create role assignments that map the user account to specific items in the report server folder hierarchy. You can limit access to read-only operations by choosing as the role assignment the Browser predefined role.
Configure reports to use stored credentials to get data for the report. This approach is useful if you want to query the external data source using an account that is different from the account that allows access to the report server.
you could refer to the below links for more detail:
https://learn.microsoft.com/en-us/previous-versions/sql/sql-server-2005/bb283249(v=sql.90)?redirectedfrom=MSDN#configuring-authentication-for-extranet-and-internet-access
https://learn.microsoft.com/en-us/sql/reporting-services/security/authentication-with-the-report-server?view=sql-server-ver15
https://forums.asp.net/t/2095478.aspx?401+Unauthorized+SSRS+authentication+from+NET+IIS
https://forums.asp.net/t/1273411.aspx?Setting+up+Reporting+Services+with+IIS+Access+Denied+Error
I have the following scenario:
(Client/Browser) => (Web Service/Web API) => (SharePoint REST-Api).
Basically what I want to achive is to have the middle application (WebService/Web API) to act as a facade infront of the SharePoint-REST-API to ease the development for anybody that needs to communicate with our SharePoint-application. (Basically we wrap a few SharePoint-request-calls into one single call in the Web API/Facade).
Now the problem is that I also want to be able to send the logged in Windows user (AD-user) from the Client to the Web Service, and then the web service should act on behalf of that Windows user and perform whatever actions needed in the SharePoint REST-API (this is to make sure that permissions to files and so on are actually set based on the authenticated user).
What we have tried so far is setting uo the Web Service on one server, and SharePoint on a different server.. and then we have tried to setup authentication using Kerberos and delegation, but we could not get this working.
Based on the information I have provided, do you guys think that a "double hop" like this would work if we manage to get Kerberos setup properly?
Another thought that hit me is that maybe we dont have to host the Web Service and the SharePoint applications in two different servers, but we could actually host them both on the same server within one single IIS-server with two sites.
Would this still require Kerberos to be setup with a double hop? Or does a "hop" only count once the ticket actually leaves one server to another.. cause in the case described here, the request from the Web Service to the SharePoint-REST-API would never leave the actual server, but it might cross domains (as in web-domains.. not AD-domains).
Could this work, instead of having to hassle with Kerberos double hop, SPNs and what not..?
when you use integrated authentication, anonymous is disabled at that time and impersonate is enabled.so security settings will not allow your site to access resources on any network servers.
When you authenticate to the IIS server using Integrated Authentication, that uses up your first 'hop'. When IIS tries to access a network device, that would be the double or second hop which is not allowed. iis will not pass those credential to the next network device.
if you use anonymous enable and impersonate off this issue will not occur.
to configure Kerberos Authentication in iis you could follow the below steps:
1)open iis manager and select site.
2)select the authentication feature from the middle pane.
3)enable windows authentication and disable anonymous.
4)With Windows Authentication, click on the Providers from the Action pane.
5)set the provider in below manner:
Negotiate
NTLM
save the changes.
6)go back and select the configuration editor.
from section dropdown select system.webServer/security/authentication/windowsAuthentication.
“useAppPoolCredentials” set to true.
"useKernelMode" to "True" and save the settings.
7)restart the iis.
8)Configure SPNs
open the command prompt as administrator and run below command to check the machine name:
hostname
When you have a custom hostname and you want to register it to a domain account, you need to create a SPN a below.
setspn -a HOST/${FQDN_HOST} ${MACHINE_NAME}
setspn -a http/${FQDN_HOST} ${MACHINE_NAME}
9)after doing that set application pool identity to the custom account and set the username and password.
You could refer this below article for more detailed information:
https://weblogs.asp.net/owscott/iis-windows-authentication-and-the-double-hop-issue
https://active-directory-wp.com/docs/Networking/Single_Sign_On/SSO_with_IIS_on_Windows.html
https://techcommunity.microsoft.com/t5/IIS-Support-Blog/Setting-up-Kerberos-Authentication-for-a-Website-in-IIS/ba-p/324644
I am getting an "Access is denied" error on a 2012 R2 server when my web app on that server tries to access a self-hosted WCF service on that server using named pipes.
I do not have this issue on my development machine (Win 7). I can access the WCF service via the client test app on both the server and my development machine.
If I enable ASP.NET Impersonation on the web site using a user account that has full control permissions to the install folder for the WCF service, then the error goes away. I do not want to use impersonation since I understand it has significant performance penalties (not to mention security issues) and the WCF service is called for every user input during a session.
The strange thing is... If I set the app pool to run as either the user with rights to the service folder as described above or as a user with admin privileges, then I still get the error if ASP.NET Impersonation is disabled. The error will go away only after I enable ASP.NET Impersonation on the web site.
I do not have access to the source for the WCF service.
In this case, the web app was located on the D:\ drive and the Anonymous Authentication user (IUSR) did not have RX permissions to the web app location.
Note that if you are using Windows Authentication, then the same issue occurs if the Windows Authenticated user does not have RX permissions to the location of the web app.
The problem was resolved once I gave the authenticated user the proper permission.
Sometimes the solution really is just plain simple...
"Ain't got no gas in it" - Slingblade.
Short version:
For IIS 7.5 web applications with Windows Authentication does the end
user need to have Read file access?
Long version:
I have an intranet ASP.NET web app that uses windows authentication. It's installed at dozens of different companies and normally the authentication works fine: users navigate to the site e.g. http://appserver/MyApp, the app recognizes who they're logged in as and displays pages accordingly. I just installed it at a new client and encountered a problem:
When connecting e.g. to http://appserver/MyApp I'm prompted for windows credentials but after entering them I'm repeatedly prompted. After several re-entering credentials I'm shown a 401 error page saying "401 - Unauthorized: Access is denied due to invalid credentials.". So not only is it not passing through my identity but even when entering the username & password it's still denying access.
Giving Read & Execute permissions to the end users of the app solves this problem, but I don't think this should be necessary at all.
In the windows Application Event Log there's a message "File authorization failed for the request" along with Thread account name: NT AUTHORITY\NETWORK SERVICE and User: [the correct workstation users's domain account]. This suggests that the file access is being performed with the User's identity, not the AppPool identity of Network Service. Sure enough if I grant the end user Read & Execute permission (I didn't try Read only) to the application's directory then everything works correctly: when the user browses to the site they're authenticated automatically, not prompted, and the web site correctly recognizes their identity! Therefore my workaround solution is to give Read & Execute permission to Everybody on the application directory...but this is not an ideal solution.
This seems very strange. I've never needed to do this before in IIS 7.5, so far as I recall, and definitely never needed to in IIS 6 or IIS 7. Is this a new IIS7.5 thing? The documentation says that Impersonation is turned off by default. I added a element to the web.config to be sure, removed file permissions other than Network Service, but the problem remained.
Any thoughts? Is it normal for Windows Authenticated sites on IIS 7.5 for end users to need file permissions on the web server files?
Some relevant details:
Network Service
has Full Control file permissions to the app folder.
When connecting from the server itself I was prompted for credentials
but after entering them i'm authenticated and the application works
correctly including displaying my windows login and connecting and
retrieving data from the db. I later determined that it was prompting
for credentials because http://localhost was in the trusted sites
and therefore not recognised as the Intranet Zone and thus not
passing identity through. I also determined that it was working as
this user identity because it's an admin user who has file
permissions.
The web server is running Windows Server 2008 R2 / IIS
7.5. It didn't have IIS on it until I installed it. I installed the default features as well as Windows Authentication, ASP.NET, and
possibly a couple of other items. A separate WCF app I installed that
uses IIS, anonymous authentication & .net 2.0 is working fine on
that web server.
The app install process is a manual copy of files,
creation of IIS App Pools & web apps, updating connection strings,
etc.
I checked the IE security settings. It was recognizing the
server as in the Intranet zone and had the option 'Automatic logon
only in Intranet zone' selected. Also on Advanced Settings the
'Enable Integrated Windows Authentication' option was checked.
After
installing IIS I ran aspnet_regiis -i for .net 2.0 and
aspnet_regiis -iru for .net 4.0.
Anonymous authentication is
disabled for my app and Windows Authentication enabled.
The app is
running on ASP.NET v4 but there's another app I installed
experiencing the same issue running ASP.NET v2.
The app is running
with Identity = Network Service and in 32-bit mode.
Database
connection string includes Trusted Connection=True and database
permissions are granted to the web server account [domain]\[server]$
e.g. DGM\MyServer$.
In IIS > Authentication > Windows Authentication > Providers the list was Negotiate first then NTLM. I tried reordering so NTLM is first.
In the Windows Security Event Log there
were a series of Microsoft Windows security auditing events: Logon
and Logoff. They indicated that the Logon was successful and was
displaying the User Id of the workstation user. This are from when
I'm connecting from another workstation and receive a 401
Unauthorized after several attempts.
I see someone has had this problem reported here but with no solution. Originally I posted in the ASP and then the IIS forums with no answers so far.
Update:
This msdn article says
When Windows authentication is enabled but impersonation is disabled, ASP.NET performs file access checks in the file authorization module using the credentials that are sent from the browser (my emphasis). Impersonation does not need to be enabled, because the FileAuthorizationModule module ensures that the requesting user is allowed read access or write access to the resource, depending on the request verb (for example, GET or POST) before executing the request. This behavior applies to any requests that enter managed code. In earlier versions of ASP.NET, accessing files based on URIs such as "Default.aspx" triggered the access check. In ASP.NET MVC applications, where access to resources is typically performed using extensionless URLs, this check typically does not apply, because there is not a physical file to check. In that case, the FileAuthorizationModule class falls back to checking access-control lists (ACLs) for the folder.
This does suggest that the end user needs permissions to the files (in the case of .aspx) or the folder (for MVC) ... although still this seems slightly tucked away and non-definitive. This article about App Pools says they're used as the identity for securing resources, which contradicts the idea of needing to grant privileges to end users. Unless the rules are different for App Pools and NETWORK SERVICE, which could be the case but would be surprising.
Are authenticated users allowed to the app folder?
We were also fighting with this issue, and started setting up security groups so we could give our users file level permissions. Then one of our server admins stumbled across a couple of new properties that allow the app to authenticate to the file system under set credentials, and resolved the need for the users to have access. Here is what he came up with…
There are two IIS settings that control this:
Physical Path Credentials Physical Path Credentials Logon type
By default, Physical Path Credentials is set to Application User
(Pass-through authentication). This means that IIS doesn’t do any
impersonation when handling Windows Authentication requests. This can,
however, be set to a specific user (though not, unfortunately, the
application pool identity, which would be ideal). Physical Path
Credentials Logon Type is set by default to Clear-Text. For my testing
I set this to Interactive (though this may not be the correct value).
Possible values are Clear-Text, Batch, Interactive, and Network.
To set this up I did the following:
Created a local account (IIS-AccessUser)
Granted IIS-AccessUser read and execute access to the /home directory of the site.
Added IIS-AccessUser to IIS_IUSRS group (necessary for accessing .NET temporary files)
Set IIS-AccessUser as the Physical Path Credentials
Set Physical Path Credentials Logon Type to Interactive
Doing the above allowed me to log in to the application directly,
without having to allow Authenticated Users, or me having to be a
member of any of the groups in the /home folder. It also still
preserved .NET Authorization roles, so I still could not access parts
of the site that I was not allowed to.
The short answer is NO. You are not required to grant file access permissions when using Windows Authentication in IIS 7.0 and IIS 7.5.
We were only able to discover this because our server admin smelled the security and management issues that arise from taking the route of granting file level access to users and groups.
For anyone dealing with this issue or if you are setting up a new IIS7/IIS7.5 server and/or moving from IIS 6, here is an article that gives you all of the Windows Authentication options and configurations that need to be modified to avoid granting file level access to individuals or groups.
Please read the two comments in at the end of the POST for some valid critiques of the methods used in this article.
http://weblogs.asp.net/owscott/iis-using-windows-authentication-with-minimal-permissions-granted-to-disk
In addition to the information in the article, please be aware that IIS 7.5 is not using the web configuration tags for system.web (at least not in my MVC 4 application).
It is looking in the system.webserver tags for authorization configuration (where you will need to list the windows domain\groups a user needs to be in to access your application).
-- DSB
I recently created a web service which all worked fine until I moved it from my local PC to our development server. I now get a HTTP status 401: Access Denied message when I try to connect from a small test website. I googled around and found the following code:
SoiisdevJobService.JobsService jService = new SoiisdevJobService.JobsService();
jService.Credentials = System.Net.CredentialCache.DefaultCredentials;
And it now works, but I'm not sure what this code actually does. Can someone explain it to me? I'm using IIS 6, Windows auth, and in my config I've set the auth mode to Windows and to deny non-authed users. In my small test app I've set the same in my config.
Why do I need to provide the code above? I expected this to just work.
It is because you have turned off access for non-authenticated users. See the quote below from the Microsoft website (http://support.microsoft.com/kb/811318/EN-US):
When Anonymous access authentication is turned off for the Web service
application, all the caller applications must provide the credentials
before making any request. By default, the Web service client proxy
does not inherit the credentials of the security context where the Web
service client application is running.