I am setting up a new instance of Report Server on a new box and need to create a couple new roles. The problem is that I don't have permissions to access /reports or /reportserver:
/reports: User '<username>' does not have required permissions. Verify that sufficient permissions have been granted and Windows User Account Control (UAC) restrictions have been addressed.
/reportserver: The permissions granted to user '<username>' are insufficient for performing this operation. (rsAccessDenied)
The domain user through which I am trying to access these has been granted full local admin rights. I would assume there might be a ReportServer user group in Local Users and Groups, but one doesn't exist.
The service account is the built-in account 'Network Service'. I'm not sure if that's relevant.
Any idea how I'd access the server to begin granting these permissions?
Did you assign the permissions for the user on the report folder level? Doing this via report management URL (with Internet Explorer) by clicking the little arrow to the right of the report folder and selecting permissions.
Related
I'm trying to create database users that are integrated with azure active directory. All of our users are guest users. I've been following multiple articles on how to create users in the SQL db but none have worked.
For example, this article: https://www.mssqltips.com/sqlservertip/5242/adding-users-to-azure-sql-databases/
Suggest to create users like so:
CREATE USER [name#domain.com]
FROM EXTERNAL PROVIDER
WITH DEFAULT_SCHEMA = dbo;
This yields the error:
Principal 'name#domain.comm' could not be found or this principal type is not supported.
Googling this error lands me on stackoverflow post (https://dba.stackexchange.com/questions/148325/add-active-directory-user-for-azure-sql-db):
which suggests:
CREATE USER [name_domain.com#EXT##<yourAzureSubscriptionPrefix>.onmicrosoft.com] FROM EXTERNAL PROVIDER
and accesses:
EXEC sp_addrolemember 'db_datareader', 'name_domain.com#EXT##<yourAzureSubscriptionPrefix>.onmicrosoft.com'
EXEC sp_addrolemember 'db_datawriter', 'name_domain.com#EXT##<yourAzureSubscriptionPrefix>.onmicrosoft.com'
and this does not give an error, but it also does not provide access to the database. Since I get error NT AUTHORITY/ANONYMOUS LOGIN
I also tried to create an AAD group and provide that group access, also no error here but couldn't login either.
Couple of notes:
All IP addresses are allowed on the firewall
all users have been added in sql db IAM (not sure if this is even necessary)
I've enabled Active Directory Admin in the sql server, I put the subscription admin here
This is also the users with which I created users in the SQL DB
I'm able to create native sql users without a problem
Still I'm only able to login using the Active Directory Admin, and no other user is able to login.
Any advice on how I can login to my Azure sql database using windows credentials from Azure Active Directory?
When using external users, you need to use the "mangled user principal name" when adding them.
That's this one:
CREATE USER [name_domain.com#EXT##<your-azure-ad-default-domain>.onmicrosoft.com] FROM EXTERNAL PROVIDER
Secondly, the users will be created only in that database; they cannot connect to master.
So you need to choose the DB to connect to.
You may also need to specify the AAD tenant id in advanced connection settings.
The reason you might need to do this is because by default an external user will login to their home tenant. Which is not the one connected to your DB. So you may need to specify the tenant to have them explicitly login against your tenant.
When i run this SQL command in Domain User login, there is
COM Error 80020005
SELECT group_database_id FROM sys.databases WHERE name = N'db5'
When i run the same command in windows local user, it runs sucessfully.
How does the domain User login differs?
Backup failed for Server 'hostname\instancename'. (Microsoft.SqlServer.SmoExtended)
To accomplish this action, set property Devices. (Microsoft.SqlServer.SmoExtended)
Windows local user is likely the account used to install the instance, making it a sysadmin. The domain user likely doesn't have the permissions to access it.
If the caller of sys.databases is not the owner of the database and
the database is not master or tempdb, the minimum permissions required
to see the corresponding row are ALTER ANY DATABASE or the VIEW ANY
DATABASE server-level permission, or CREATE DATABASE permission in the
master database. The database to which the caller is connected can
always be viewed in sys.databases.
By default, the public role has the VIEW ANY DATABASE permission,
allowing all logins to see database information. To block a login from
the ability to detect a database, REVOKE the VIEW ANY DATABASE
permission from public, or DENY the `VIEW ANY DATABASE permission for
individual logins.
MSDN
From MSDN: Application Roles on MSDN
An application role is a database principal that enables an application to run with its own, user-like permissions. You can use application roles to enable access to specific data to only those users who connect through a particular application. Unlike database roles, application roles contain no members and are inactive by default. Application roles work with both authentication modes. Application roles are enabled by using sp_setapprole, which requires a password. Because application roles are a database-level principal, they can access other databases only through permissions granted in those databases to guest. Therefore, any database in which guest has been disabled will be inaccessible to application roles in other databases.
Can someone explain this to me?
Does this mean that I cannot write a cross database query which refers to tables from another database on the same SQL Server Instance if guest account is disabled for that instance?
First, disabling the guest account on an instance is IMHO a bad idea. The guest account is designed to allow users to "see" databases (and very little more). Disabling the guest account for the instance (and consequestially master) will stop enumeration of the databases which may well stop an otherwise authenticated role connecting, depending on the connection string used. You can grant an application role to one or more databases and instances and the application running under this account will have access (unless its denied in some other way) Thus any userrs who can run the applicaion will have that access via the application) Its a way of allowing an application t do something without granting the user those rights. http://msdn.microsoft.com/en-us/library/aa905195%28v=sql.80%29.aspx By Instance I presume you mean sQL install instance...?
My report was build and deployed successfully but after I give the url http://localhost/ReportServer it returns
The permissions granted to user 'suresh\admin' are insufficient for performing this operation. (rsAccessDenied).
Can you help me ?
Based on MSDN :
Permission to access report server content and operations are granted
through role assignments. On a new installation, only local
administrators have access to a report server. To grant access to
other users, a local administrator must create a role assignment that
specifies a domain user or group account, one or more roles that
define the tasks the user can perform, and a scope (usually the Home
folder or root node of the report server folder hierarchy). You can
use Report Manager to create the role assignments. For more
information, search for "Role Assignments" in SQL Server Books Online.
I have a SQL Server 2005 database that I'm trying to access as a limited user account, using Windows authentication. I've got BUILTIN\Users added as a database user (before I did so, I couldn't even open the database). I'm working under the assumption that everybody is supposed to have permissions for the "public" role applied to them, so I didn't do anything with role assignment. Under tblFoo, I can use the SSMS Properties dialog (Permissions page) to add "public", then set explicit permissions. Among these is "Grant" for SELECT. But running
SELECT * from tblFoo;
as a limited (BUILTIN\Users) account gives me an error "Select permission denied on object 'tblFoo', database 'bar', schema 'dbo'". In the properties dialog, there's an "Effective Permissions button, but it's greyed out.
Further, I tried creating a non-priv account called "UserTest", adding that at the server level, then mapping it down to the "bar" database. This let me add UserTest to the "Users or Roles" list, which let me run "Effective Permissions" for the account. No permissions are listed at all -- this doesn't seem right. The account must be in public, and public grants (among other things) Select on tblFoo, so why doesn't the UserTest account show an effective permission? I feel like I'm going a bit crazy here.
ASIDE: I am aware that many people don't like using the "public" role to set permissions. This is just my tinkering time; in final design I'm sure we'll have several flexible (custom) database roles. I'm just trying to figure out the behavior I'm seeing, so please no "don't do that!" answers.
UPDATE: Apparently I know just enough SQL Server to be a danger to myself and others. In setting permissions (as I said, "among others"), I had DENY CONTROL. When I set this permission, I think I tried to look up what it did, had a vague idea, and decided on DENY. I cannot currently recall why this seemed the thing to do, but it would appear that that was the reason I was getting permission failures. So I'm updating my question: can anyone explain the "CONTROL" permission, as it pertains to tables?
You only need to have SELECT rights. In raw SQL (see the "script" icon/button in your dialogue box), it's GRANT SELECT ON dbo.tblFoo to public. This is the only permission needed to view the data,
In this case, the error message explicitly mentions "deny". "DENY" is a right in itself, so it mentions it,
If you had no rights, you'd get the message (very approximately) "tblFoo does not exist or you do not have rights"
"DENY CONTROL" is mentioned here. In this case, you denied all rights to the public role.
The grantee effectively has all
defined permissions on the securable
Assuming "UserTest" is a domain user account, connect as a member of the sysadmin role and run
EXEC MASTER.dbo.xp_logininfo 'Domain\UserTest', 'all'
(substituting your domain name for "Domain")
this will display the Windows groups etc. that the account is inheriting security permissions from and the level of access, e.g. you would expect to see something like:
account name type privilege mapped login name permission path
domain\usertest user user domain\usertest BUILTIN\Users
This will help troubleshoot where the account is inheriting permissions from, e.g. which Windows groups it is part of that have permissions to the database. If this all looks OK then I would follow your own advice and not mess with the public role.
Create a database role in your
database
Assign explicit permissions for that
role
Create a server login for your user
account
Open the server login, go to the
User Mapping section, click on the
database and select the database
role you created