@roger_that wrote:
What application actually receives this packet - https.sys, Power BI Report Server, SQL Server 2014, something else?
Report Server registers itself with http.sys so I believe http.sys does all the low level http handling (probably including the windows auth) before the request is passed off to the rsportal.exe process
The user types in their credentials, and sends them back to the application.
A default install Report Server uses windows authentication, so if the user is already authenticated against the domain they do not need to type in any credentials.
If this is Power BI Report Server receiving the credentials, my guess of credential flow would be: from PowerBI RS to SQL server 2014, to the Domain Controller for verification that the credentials are valid. If valid, the DC would send back to SQL Server 2014 the group members of the user.
No this is not correct. SQL Server 2014 plays no direct part in the authentication flow. It holds metadata about the reports and folders and which users are allowed to see those reports and folders. But the RSPortal.exe process would talk directly to the AD domain controller, it will not go via SQL Server.
@roger_that wrote:
if a match is made, the user info is passed to PowerBI RS, where the username is compared to Roles, to see what access/permissions the user has. I _think_ that this would be the point where the user is "logged on". Where is that logged?
Technically there is no concept of being "logged on" in PBIRS. Some websites fake this, but HTTP is request based not session based. So every request has to go through authentication (who are you) and authorization (what are you allowed to do). The RSPortal log appears to have all the successful http requests - you can see responses with a status of 200. But for some reason it does not appear to be logging all errors. I was expecting to see 401 (unathenticated error) if I tried to access the site without entering credentials ( I did this using an anonymous browser window and cancelling the authentication prompt). However I do see 404 errors if I try to access a report name which does not exists. So I'm hoping that it would also log 403 (access denied) errors if a user is authenticated, but tries to access a report which they are not allowed to (this is a bit harder for me to test locally)
I'm trying to see if I can find out if there is a way of logging 401 errors.
@roger_that wrote:
I am _guessing_ that the SQL Server 2014 would log both successful and failed logon attempts, perhaps in the Execution3 log, but I really don't know enough about SQL Server to know.
The Execution3 log only logs report executions, so by that time the user has already been authenticated and authorized and they've got access to the report. This log will then record who ran the report, how long it took and if it was successful or if there was an error while trying to render the report. This log definitely does not record failed logons.
