I have deployed a couple of reports in SSRS2012, the report uses the user's windows token to do some verification. When testing the report in VS I successfully read the windows token but when I deploy to SSRS token is empty.
I did configure all data sources to use windows authentication and to impersonate the user.
any ideas?
Thanks
I'm a little unclear on the specifics here, but I'm thinking the problem is with the authentication method you're using in IIS.
Check out this other question:
Why does Windows/Integrated Authentication in IIS not pass user credentials to SSRS and SQL?
The versions are a bit different (SSRS 2005) but I think the issues here are the same. I won't get into it too much, because the answer in that link explains it better than I could, but essentially, it works from Visual Studio because your Windows Token is the one making all the requests. When you deploy to IIS, however, without explicitly configuring Windows Authentication and Identity Impersonation, the requests are being executed as the App Pool User, not the user using your web app. I hope this helps!
Related
I'm new to Federation Services and I'm trying to understand how ADFS works as a whole and I've started to get down into the details. I followed along with creating an app using OIDC to authenticate a user, however, within the tutorial, they specified using a "Server Application" when setting up an Application Group. This ended up not working for me so I tried setting up a "Native Application" application group for kicks and was able to successfully login.
The thing that threw me off is, I ended up hosting ADFS on a server outside of the domain in which I had my application running, so I'm confused as to how that is "native" in terms of ADFS.
I went looking for this answer within microsoft's documentation but I didn't find the information very clear.
Native Application:
"Sometimes called a public client, this is intended to be a client app that runs on a pc or device and with which the user interacts."
Server Application:
"A web application that runs on a server and is generally accessible to users via a browser. Because it is capable of maintaining its own client 'secret' or credential, it is sometimes called a confidential client."
This may seem simple to some, but I'm trying to really get a grip on what would be used when. To me it sounds like a native application is used when you're running the application natively on a pc in which the user is also using the same pc, and the server application is run remotely in which the user would not be using the same machine. Is it really that simple or am I misunderstanding?
A native application (in Microsoft speak) is something that is not browser based e.g. mobile. The code runs client side. It may use JavaScript in which case the secret key is publicly accessible. (The secret key is one of the OAuth parameters). You use ADAL / MSAL to access it.
A server application runs server side e.g a web API. The secret key is not publicly accessible. You use OWIN to access it.
These terms have no relevance to where ADFS is actually installed. Native applications typically are not domain joined.
I am using SSRS reporting service in my MVC application. I am using some reports and accessed these reports from web application by specifying URL like this
and passing username, password and domain as credential.
When I use this code on local it's working fine but when I use same code on the live environment its giving a
401 unauthorised error.
Can anyone help me what I am doing wrong? One thing to mention that when I am using this locally both the database and the deployed code are in same domain but on live environment both database and code are on different domains.
Any help would be appreciated.
Sorry my question might be duplicate but i dint find any correct solution.So im posting this question again...
First i have deployed a DNN website with sql server authentication.Site was working fine.
Later we re installed the sql server 2008. So im trying to give windows authentication to connect the site.
In web config connectionstring:i have removed the username and password and gave Integrated security="true" .
In IIS :Site -> Authentication -> windows Authentication ->enabled and all others disabled.
once i browse the site is redirecting to DNN install Wizard
Need Help.
In SQL Server did you configure the Windows account that the application pool (in IIS) is using to have DBOwner access to the database?
Also make sure to change BOTH connection strings in the database.
Depending on what version of IIS you are on, that account might differ. Older versions likely would use "Network Service" while newer versions might also use "Network Service" or an application pool specific account like "iis apppool\dnndev"
You'll also want to make sure that you aren't trying to assign a DOMAIN account to the database, unless of course that is what IIS is configured to use (as opposed to a local account)
I am working on setting up my report server to use a web service as an XML datasource. I seem to be having authentication issues between the web service and the report with I choose to use Integrated security. Here's what I have:
1) I have a website w/ an exposed service. This website is configured to run ONLY on Integrated Security. This means that we have all other modes turned off AND Enabled anonymous access turned off under directory security.
2) Within the Web.config of the website, I have the authentication mode set to Windows.
3) I have the report datasource set to being an XML data source. I have the correct URL to the service and have it set to Windows Integrated Security. Since I am making a hop from the Browser to the Reporting Server to the Web Service, I wonder if I am having an issue w/ Kerberos, but I am not sure.
When I try to access the service, I get a 401 error.
Here are the IIS logs that I am generating:
2011-01-07 14:52:12 W3SVC IP_ADDY POST /URL.asmx - 80 - IP_ADDY - 401 1 0
2011-01-07 14:52:12 W3SVC IP_ADDY POST /URL.asmx - 80 - IP_ADDY - 401 1 5
Has anyone worked out this issue before? Thanks!
It does sound like you are experiencing the "double hop" issue. Is it possible to create an account on your web service that the reporting server uses explicitly instead of passing through the users credentials?
There's a simpler solution if you dont want to muck around with Kerberos... although the user experience is less desirable.
On the Data Source...If you check the "Credentials supplied by the user running the report" and the "Use as Windows credentials when connecting to the data source" then the user will be promoted to log in when they run the report. Since the credentials are being supplied to the SSRS server it's only a single hop from SSRS to the webservice... thus avoiding the double-hop NTLM authentication problem.
It's less user-friendly, though, since you have to log in to run the report.
I have a website that works correctly under IIS 6.0: It authenticates users with windows credentials, and then when talking to the service that hits the DB, it passes the credentials.
In IIS 7.0, the same config settings do not pass the credentials, and the DB gets hit with NT AUTHORITY\ANONYMOUS.
Is there something I'm missing? I've turned ANONYMOUS access off in my IIS 7.0 website, but I can't get the thing to work.
These are the settings that I'm using on both IIS 6.0 and 7.0:
<authentication mode="Windows">
<identity impersonate="true">
What changed from 6.0 to 7.0?
There has been changes between IIS7 and IIS6.0. I found for you one blog post that might actually help you (click here to see it).
Are you running your application in Integrated Mode or in Classic Mode? From what I saw, putting the Impersonate attribute at true should display you a 500 error with the following error message:
Internal Server Error. This is HTTP
Error 500.19: The requested page
cannot be accessed because the related
configuration data for the page is
invalid.
Here is the workaround that is proposed:
Workaround:
1) If your application does not rely
on impersonating the requesting user
in the BeginRequest and
AuthenticateRequest stages (the only
stages where impersonation is not
possible in Integrated mode), ignore
this error by adding the following to
your application’s web.config:
<validation validateIntegratedModeConfiguration="false"
/>
2) If your application does rely on
impersonation in BeginRequest and
AuthenticateRequest, or you are not
sure, move to classic mode.
I hoped that was useful to understand how IIS 7.0 now works.
Is your IIS server set up to be trusted for delegation by the SQLServer? I've run into this before with WebDAV where we've had to have the server running IIS trusted by the file server to authenticate on the file server's behalf.
Interesting... I have the opposite problem - Not being able to get the authentication to be passed from the client browser, through the webserver and onto the database within a large corporate network over firewalls.
I also feel that "end to end user" authentication to the database is a bad idea and a potential security risk. There is nothing to stop the end user from loading up SQL Query and connecting directly to your database, so you'd better have your schema locked down!
#Esteban - Clarified my not very useful in helping you answer.
Typically if you are doing double hop authentication like this, Kerberos is typically involved unless the first authentication is Basic.
I would check the authentication on the IIS 6 servers and make sure that it's the same on IIS 7.
If the IIS 6 box is set to Windows Integrated, then you need to verify the kerberos settings - SPNs, Delegation etc.