I am running SQL Server Reporting Services on SQL Server 2008 Standard and trying to get the web pages to work.
What do I have to do to get RS (Report Manager, Reporting Services Connection), to see me as an admin in the first place so that I can make then change my role and look at the Web Service URL properly?
I have Windows authentication Enabled in II7 and I have anonymous authentication disabled.
I am logged in as a local Administrator (however the pages don't seem to realize that I am an admin).
Through the tables in ReportServer db, I can tell that BUILTIN\Administrators is in there.
I have my local machine in Trusted Sites in Internet Explorer.
Using Chrome instead of IE, I get similar results. I have not tried Firefox.
Most of the help I have found online assumes that you can add your login as an administrator explicitly from the perspective of RS. I cannot figure out how to do that because everyway I try to administer roles I cannot get to work....
At:
http://machine/ReportServer_DEPAHELIX
I get:
Reporting Services Error
The permissions granted to user 'Chris-PC\Chris' are insufficient for performing this operation. (rsAccessDenied) Get Online Help
SQL Server Reporting Services
At:
http://machine/Reports_DEPAHELIX/Pages/Folder.aspx
I see only Home, with Home, My Subscriptions, Help and cannot really do anything. There are no reports there yet because when I try to deploy from BIDS, I get Error 1 The permissions granted to user 'Chris-PC\Chris' are insufficient for performing this operation. 0 0
At:
http://machine/Reports_DEPAHELIX/Pages/SystemSecurity.aspx
I see
You do not have permission to access this page.
And when I connect to Reporing Services through SQL Server Management Studio, I see Jobs, Security and Shared Schedules, and that's it. I can expand Security>Roles and see 5 built in roles, however
when I right click on a Role, the context menu has Properties grayed out.
What do I have to do to get RS to see me as an admin?
Appreciate you have a resolution; if anyone else has this problem; MS have put a step by step guide up on msdn. "Configure a Report Server for Local Administration on Windows Vista and Windows Server 2008"
http://msdn.microsoft.com/en-us/library/bb630430.aspx
I have the same exact problem, i am running on Windows 7. I also cannot deploy to the SQL Server, if I am not logged in as Administrator (and not as a users of the Admin group.)
One thing that solved my problem is to start Internet Explorer as Administrator, even if you are logged in as a Admin users. (Right-click and select "Start as an Administrator") Same in Visual Studio in order for you to deploy. It's annoying, but it works...
As stated by John, must be "Administrator", not just a member of Administrators group. Trying to make more users part of BUILTIN\Administrators is not the answer. The answer is to login initially as "Administrator" and then setup Reporting Services related groups for your system or domain then configure the roles associated with those groups using RS tools, and add the appropriate users to the specific new groups.
Found my answer after hours of searching ...
As other users suggest, you need to right-click and choose Run As Administrator. However, on Windows 7 it seems that Internet Explorer by default does not provide current user credentials to Reporting Services. What happens then is that you get a login prompt when you try to access Reporting Services. If you get a login prompt, you need to adjust security settings.
Choose Intenet Options and go to the Security tab. Click on Trusted sites. Either drag the security slider to low security or click on Custom level. If you click on Custom level, go to the User Authentication/Logon option and choose "Automatic logon with current name and password".
Original post here for reference:
http://blogical.se/blogs/jahlen/archive/2009/10/02/setting-up-sql-server-reporting-services-on-windows-7-vista-or-windows-2008.aspx
Sql Server 2008 does not recognize Windows administrators as database sysadmins. You have to add the Windows administrator group to the Sql sysadmins role.
You can add the group like this:
Open Sql Server Management Studio
Open Security -> Logins, and create a login for the Administrators group
Open Security -> Server Roles, and add the login to the syadmin role
During installation, setup will offer to make the current user a database administrator. If you accept that, the current windows user will be added to the database sysadmin group. If you installed Sql Server as "Administrator", that explains why only the "Administrator" account was able to configure your Reporting server.
If you had installed Sql Server as "YourDomain\YourAccount", that account would have added to the sysadmin role instead. So there's nothing special about "The" administrator.
I have found that the BUILTIN\Administrators account is not treated correctly for permissions within SSRS, if you create a new group Eg SSRS_Administrators and add all your admin users to this group and define SSRS_Administrators as a content manager within report manager all is good.
If you're a local admin, run c:\program files\Internet Explorer\iexplore.exe as administrator (right-click, run as administrator). This open the SSRS Report Manager and you can do what's needed.
Related
I run SQL Server 2014 locally. My old windows account has been corrupted. I created a new windows account, gave myself sysadmin permissions on SSMS and I can log onto the database fine. I also logged on Reporting Services Configuration Manager and changed the Service Account to the new user account. However I can not access localhost/reportserver on internet explorer. It's saying I don't have sufficient permissions.
Ah I just found the answer. It's a Trusted Site issue:
To Configure Local Report Server and Report Manager Administration
Complete the configuration steps in this section if you are browsing to a local report server and you see errors similar to the following:
User 'Domain[user name]' does not have required permissions. Verify that sufficient permissions have been granted and Windows User Account Control (UAC) restrictions have been addressed.
Trusted Site Settings in the Browser:
Open a browser window with Run as administrator permissions. From the Start menu, click All Programs, right-click Internet Explorer, and select Run as administrator.
Click Allow to continue.
In the URL address, enter the Report Manager URL. For instructions, see Report Manager (SSRS Native Mode) in SQL Server Books Online.
Click Tools.
Click Internet Options.
Click Security.
Click Trusted Sites.
Click Sites.
Add https://[your-server-name]
Clear the check box Require server certification (https:) for all sites in this zone if you are not using HTTPS for the default site.
Click Add.
Click OK.
https://learn.microsoft.com/en-us/sql/reporting-services/report-server/configure-a-native-mode-report-server-for-local-administration-ssrs?view=sql-server-2017
I'm getting the error below when I try and access SSRS on SQL Server 2008 R2
I'm not sure how many others have started using SQL 2008 R2 SSRS, but I am having an issue with getting the error below when I try and access the reports server url
User does not have required permissions. Verify that sufficient permissions have been granted and Windows User Account Control (UAC) restrictions have been addressed
What I have tried:
I can access the url if I run IE as an administrator
Once you're able to log in to YourServer/Reports as an administrator, click Home in the top-right corner, then Folder Settings and New Role Assignment. Enter your user name and check a box for each role you want to grant yourself. Finally, click OK. You should now be able to browse folders without launching your browser with elevated privileges.
Don't forget to set the security at the site level **AND ** at the folder level. I hope that helps.
I am having quite a problem with SQL Server.
When I installed it, my account was not an administrator, now it is. Apparently, since it was not an administrator of the machine, it is not an administrator of SQL Server, as a consequence I cannot create databases on my machine.
Now, I am on Windows 8, so it seems like SQL Server Configuration Manager is not as accesible as it was before, I managed to run it (I THINK!) from the MMC by running the following command: sqlservermanager10.msc.
Now, can anyone help me configure my current user as an SQL Server admin so I can create databases properly?
Thank you!
if I understand you correctly, you want your account to have sysadmin rights on SQL Server. You can either do this via SQL Server Management studio, or the SQLCMD command line utility. You don't use the SQL Server Configuration Manager.
You need to login as an existing SA (or whichever the identity has the sysadmin role).
Using TSQL via SQLCMD
Run the following command (replacing domain\user with your details)
USE [master]
GO
CREATE LOGIN [domain\user] FROM WINDOWS WITH DEFAULT_DATABASE=[master]
GO
ALTER SERVER ROLE [sysadmin] ADD MEMBER [domain\user]
GO
Via the UI
In SQL Server Management Studio
Navigate to the Security node of the server, and R-Click & Select New Login
In the New Login dialog enter your domain user into the Window Authentication box
Then on the Right side select Server Roles and then make sure SysAdmin is selected
Then Ok that dialog and the windows account will have SA rights. This means then you can full administer the SQL Server.
It's not clear at all what's going on here, but it sounds to me like you haven't got any sysadmins if #Preet isn't correct.
The local Administrators group is not a member of the sysadmin role on recent versions of SQL Server (2005+, IIRC), and if I recall the installer complains if you try to configure it that way. Instead, when you install the instance you specify the users or groups who will be granted the sysadmin role on the instance.
If you did not do this (I think it adds the account doing the installation by default) or used an account or group which was later deleted, had the SID changed, or some similar event, then you have an instance with no sysadmin logins that can authenticate. You may be able to add one by switching the server to single user mode or minimal configuration mode (-f instead of -m).
If none of that works, then you'll have to save your database files, nuke the instance, install the instance again, re-attach your database files, and go from there.
The only other thing I can think that it might be is that the instance is somehow running as a user account that doesn't have permissions to create files in the default database or log directory, but that seems highly unlikely.
I had recently installed SQL server 2012 and I used mostly the default settings. Database works fine and I can happily connect using SSMS (SQL Server Management Studio) but when I connect to the Integration Services Server I get this message
Connecting to the Integration Services service on the computer
"localhost" failed with the following error: "Access is denied."
By default, only administrators have access to the Integration
Services service. On Windows Vista and later, the process must be
running with administrative privileges in order to connect to the
Integration Services service. See the help topic for information on
how to configure access to the service.
here is the screenshot
I am not sure why but I am the domain admin and have full rights over the server. Also why when I connect from my Desktop it can successfully connect, only if I connect from the server itself which gives me this issues. How do I fix this so that I can make SSMS on the server connect to its Integration Services instance.
As I understand it, User Access Control, or UAC, can basically intercept requests for your group membership so in this case, it appears it was preventing your membership getting passed to SQL Server.
Others have noted in their comments that you may still need to right click and run SSMS as an Administrator.
As noted by an astute observer "This is a quick-fix, not a real solution. People shouldn't just be running stuff as administrator. These security walls are in place for a reason" And I agree. UAC is designed to get Windows users into a Principle of least privilege mindset - only escalate to a powerful account when required. The issue is that SSMS is known to not "play well" with UAC. As I see it, this leaves you with three options
You can turn off UAC and get your work done
Leave UAC on and tell your boss you are unable to work
Write your own query tool that is not affected by UAC
Go to all programs Click on Microsoft SQL Server 2012 folder Right click on SQL Server Management Studio Click on Run as Administrator
This should take care of problem for now. (With this you need to always repeat the same process). To avoid this every time and for a more persistent solution you need to get permission(s). Please do the following process and you should be good.
In previous versions of SQL Server, by default when you installed SQL Server all users in the Users group had access to the Integration Services service. When you install the current release of SQL Server, users do not have access to the Integration Services service. The service is secure by default. After SQL Server is installed, the administrator must grant access to the service.
To grant access to the Integration Services service
Run Dcomcnfg.exe. Dcomcnfg.exe provides a user interface for modifying certain settings in the registry.
In the Component Services dialog, expand the Component Services > Computers > My Computer > DCOM Config node.
Right-click Microsoft SQL Server Integration Services 11.0, and then click Properties.
On the Security tab, click Edit in the Launch and Activation Permissions area.
Add users and assign appropriate permissions, and then click Ok.
Repeat steps 4 - 5 for Access Permissions.
Restart SQL Server Management Studio.
Restart the Integration Services Service.
(Source MSDN)
I hope this will help
Right Click on the Sql Server Management Studio and select Run as Administrator and try to connect
if it is installed on the local instance
You should check to see what user the SSIS Service is running under. Go to Start > Run > Type "services.msc" and scroll down to the SQL Server Integration Services 11.0 entry. Right click and check the properties to find out what user it's running under. The second tab should be the LogOn tab. Since you're just running on a local instance, you can set your user as the LogOn User account and SSIS will have the same permissions that you do.
Lost a day of work on that problem. My package has a .NET script task to copy file from a shared network folder to a local folder and I was stuck with the "access denied" exception every time I tried to execute the package from the server (Through SQL Studio). The package works fine when running locally.
Tried many things picked up here and there and at the end of the day what worked is to create a Job (owner is sa) which execute the package as SSISExecutor.
I have to mention that the file on the network has read access for everyone, and that I still don't understand what was wrong.
I recently installed Microsoft SQL Server 2012 on a fresh Windows 7 installation, but whenever I want to run the server, I get the following error:
Error 1069: The service did not start due to a logon failure.
The following user is configured to start the service: NT Service\MSSQL$SQLEXPRESS
How can I fix this problem?
The answer to this may be identical to the problem with full blown SQL Server (NTService\MSSQLSERVER) and this is to reset the password. The ironic thing is, there is no password.
Steps are:
Right click on the Service in the Services mmc
Click Properties
Click on the Log On tab
The password fields will appear to have entries in them...
Blank out both Password fields
Click "OK"
This should re-grant access to the service and it should start up again. Weird?
NOTE: if the problem comes back after a few hours or days, then you probably have a group policy which is overriding your settings and it's coming and taking the right away again.
This happened to me. A policy on the domain was taking away the SQL Server user account's "Log on as a service" rights. You can work around this using JLo's solution, but does not address the group policy problem specifically and it will return next time the group policies are refreshed on the machine.
The specific policy causing the issue for me was:
Under, Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignments: Log on as a service
You can see which policies are being applied to your machine by running the command "rsop" from the command line. Follow the path to the policy listed above and you will see its current value as well as which GPO set the value.
While ("run as SYSTEM") works, people should be advised this means going from a minimum-permissions type account to an account which has all permissions in the world. Which is very much not a recommended setup best practices or security-wise.
If you know what you are doing and know your SQL Server will always be run in an isolated environment (i.e. not on hotel or airport wifi) it's probably fine, but this creates a very real attack vector which can completely compromise a machine if on open internets.
This seems to be an error on Microsoft's part and people should be aware of the implications of the workaround posted.
Short answer:
install Remote Server Administration tools on your SQL Server (it's an optional feature of Windows Server), reboot, then run SQL Server configuration manager, access the service settings for each of the services whose logon account starts with "NT Service...", clear out the password fields and restart the service. Under the covers, SQL Server Config manager will assign these virtual accounts the Log On as a Service right, and you'll be on your way.
tl;dr;
There is a catch-22 between default settings for a windows domain and default install of SQL Server 2012.
As mentioned above, default Windows domain setup will indeed prevent you from defining the "log on as a service" right via Group Policy Edit at the local machine (via GUI at least; if you install Powershell ActiveDirectory module (via Remote Server Administration tools download) you can do it by scripting.
And, by default, SQL Server 2012 setup runs services in "virtual accounts" (NT Service\ prefix, e.g, NT Service\MSSQLServer. These are like local machine accounts, not domain accounts, but you still can't assign them log on as service rights if your server is joined to a domain. SQL Server setup attempts to assign the right at install, and the SQL Server Config Management tool likewise attempts to assign the right when you change logon account.
And the beautiful catch-22 is this: SQL Server tools depend on (some component of) RSAT to assign the logon as service right. If you don't happen to have RSAT installed on your member server, SQL Server Config Manager fails silently trying to apply the setting (despite all the gaudy pre-installation verification it runs) and you end up with services that won't start.
The one hint of this requirement that I was able to find in the blizzard of SQL Server and Virtual Account doc was this: https://msdn.microsoft.com/en-us/library/ms143504.aspx#New_Accounts, search for RSAT.
I had a similar issue that was resolved with the following:
In Services.MSC click on the Log On tab and add the user with minimum privileges and password (on the service that is throwing the login error)
By Starting Sql Server to run as Administrator
If the user is a domain user use Domain username and password
One possibility is when installed sql server data tools Bi,
while sql server was already set up.
Solution:-
1.Just Repair the sql server with the set up instance
if solution does not work ,
than its worth your time meddling with services.msc
I don't know how good of a solution this is it, but after following some of the other answer to this question without success, i resolved setting the connection user of the service MSSQLSERVER to "Local Service".
N.B: i'm using SQL Server 2017.