This post is about an interesting case where the final goal of the system administrator was to allow “all” public users to access some reports that were located/generated by SQL Reporting Services 2008. The regular web site was published by ISA Server and it was working perfectly. ISA Server was not doing any type of authentication since the real goal was to allow anonymous. The relevant parameters from the rule and listener were configured like this:
o Authentication: No Authentication and client may authenticate directly.
o Users: All Users
o Paths: /*
· Web Listener:
o Authentication: No Authentication
§ Advanced: Allow client authentication over HTTP
This means that ISA was allowing the traffic all the way from Internet to the published server. When the rule has those parameters you can be certain that ISA is not asking for authentication, therefore if you are receiving prompts for authentication in a publishing rule you should start investigating the server that you are trying to publish. Interesting enough, in this case the IIS Server that has the web site was indeed allowing anonymous and we were able to browse the whole web site but the link that generates the report. During that time, we were able to see that the internal NIC of ISA was receiving the following answer from the web server:
Weird, since IIS was configured to allow anonymous, right? Wrong…because on top of IIS we have Reporting Services virtual web site and there was the catch. According to “Authentication Types in Reporting Services” paper, anonymous authentication is not supported, it says:
The report server will not accept unauthenticated requests from an anonymous user, except for those deployments that include a custom authentication extension.
Report Builder will accept unauthenticated requests if you enable Report Builder access on a report server that is configured for Basic authentication.
For all other cases, anonymous requests are rejected with an HTTP Status 401 Access Denied error before the request reaches ASP.NET. Clients receiving 401 Access Denied must reformulate the request with a valid authentication type.
There we go. This explains why ISA’s internal NIC was receiving the 401….and all that started because system admin was saying that it was an ISA issue since it worked perfectly inside of his network. Well, it make sense working internally since it will negotiate NTLM for domain users and it will be transparent that something is going on behind the scenes. However, the SQL guy that worked with me on this issue did find a workaround which is documented in here: http://blogs.msdn.com/jameswu/archive/2008/07/15/anonymous-access-in-sql-rs-2008.aspx
Again…not an ISA issue J.