August 30, 2019 at 2:14 pm
Good morning, everyone:
There is a need for us to lock down the SSRS web service URL to only authenticated users. I have tried a number of things to get it locked down, but to no avail. Does anyone have any suggestions on how this can be accomplished? Any information/assistance would be greatly appreciated. Thanks-
TC
Experience is what you get when you don't get what you want!
August 30, 2019 at 3:51 pm
I thought that it was open only to authenticated users. Are you saying that unauthenticated users have access?
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
August 30, 2019 at 3:56 pm
Hi Phil:
Yes. We get all of our URL's tested by our Pen Test team and they found that they can access http://[server]/reportserver without entering credentials. I confirmed that by having personnel that I know are not supposed to be able to access the SSRS instance and they are still able to access the reportserver URL.
Tim
Experience is what you get when you don't get what you want!
August 30, 2019 at 4:03 pm
How far can they get? Can they run reports too?
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
August 30, 2019 at 4:09 pm
Perhaps you have the "everyone" group added as a user that can browse the reports rather than a "users" group (which excludes accounts like those used by penetration testers? If, however, the user is logged into a PC then they are already authenticated, so no sure how they accessed other than that they were already authenticated (which negates their statement).
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
August 30, 2019 at 4:26 pm
I only have domain groups added to the site security and there is not an "everyone" in those groups. I also removed the BUILTIN\Administrators group when I first set up the SSRS instance (it's the first thing I do to make sure no one can sneak in). They can get into the all of the folders, but receive errors when trying to execute the reports if they're not part of a Windows group that has execute permissions on the stored procedures.
And just so we're all speaking about the same site/URLs:
http://server/reports: The Pen Test team and users I selected to test accessibility could not access this URL
http://server/reportserver: The Pen Test team and users I selected to test accessibility COULD access this URL
I am one of the first people that teams approach when they have SQL-related questions or issues, since I'm the one on our server sizing team who evaluates SQL Server instances. The reason why I threw this question out here is because someone on one of the teams with which I've worked approached me about locking down the web service side. I was under the impression that the security set up in the instance applied to all components of SSRS but it does not appear that way, based on what I'm finding on my own instances.
Experience is what you get when you don't get what you want!
September 2, 2019 at 9:12 am
If I open either of those urls (obviously for my own instance), I'm asked to authenticate in a browser that doesn't support kerboros (i.e. Firefox). If I try with an account that isn't a member of the required AD roles on then I get a "User 'User Here' does not have required permissions" and "The permissions granted to user 'User Here' are insufficient for performing this operation." error on the pages respectively.
This almost certainly tells me that the user(s) you are using do at least have the browser permissions; either on the user account or through an AD account. You need to check the AD groups the auditor/tester account was using and ensure it doesn't have access to browse the reports, etc.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
September 5, 2019 at 11:54 am
Thanks, Thom A! I'll double-check the Windows groups to make sure there are no "unauthorized users" in it
Experience is what you get when you don't get what you want!
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply