Can I create a credential in SQL Server 2012 for a group? Not an individual user.
I am trying to give a group of users access to execute SSIS packages using the SQL Server Agent. which requires a proxy account on a credential.
Instead of creating a credential for every single user, I just want to create one credential. I do not know the password for the group, is there a password which exists that the DBAs might know of?
These are two different things.
On the SSIS side, your SSIS package has to run in a security context that gives it rights to do what it needs - connect to databases, open remote files etc. This has nothing to do with the user that starts the package.
On the user side, users need to have rights to execute the package. The user does not need the same file and database rights as the package. So hopefully you can understand these are two different security items.
Your SQL Agent proxy needs to be granted all rights required by the package. This is a single credential (windows account). It isn't a group. A group doesn't have a password, it just contains a bunch of logins
Your users on other hand can be belong to a windows group. Then you add that group to the SQL Server as a SQL Server login. Then you give that windows group access to the msdb or SSISCatalog database and add them to appropriate roles.
Here are the list of roles:
https://msdn.microsoft.com/en-us/library/ms141053.aspx
and here is a guide on granting access at the individual package level
https://blogs.msdn.microsoft.com/mattm/2012/03/19/ssis-catalog-access-control-tips/
I know that links for answers are frowned on but the main concept is that the package execution security and user rights to execute packages are two separate things
Related
DBA needs to remove some TFS 2013 permissions from SQL Server 2012. Which permissions TFS should contain on SQL Server after your first installation? FULL TFS has been installed
SQL Server permissions to first TFS installation I've found but daily permission I couldn't
Another specifics questions are:
Can we remove Optimize Database Job (Release Management)?
This TFS job basically executes Update Statistics and as we are working with shared SQL Server, this routing already exists on our DB
What is impact for TFS to remove "Agent User Role" from MSDB database?
You can check these two links for the details about Database Permissions requirements for TFS: https://msdn.microsoft.com/en-us/library/bb552341.aspx http://blogs.msdn.com/b/bharry/archive/2010/08/20/database-permissions-required-to-configure-tfs.aspx
The followings are some highlight points for your quick reference:
sysadmin and serveradmin for all databases that TFS uses.
CREATE DATABASE - We need this permission to be able to create configuration, collection, and warehouse database.
Reporting Services: Team Foundation Content Manager and either sysadmin or the db_owner group membership for the configuration database, the reporting and analysis databases, and the databases for team project collections.
If you want the user to have sufficient permissions to create a database as part of creating a team project collection, you must grant that user membership in the sysadmin role in SQL Server
To install, upgrade, and configure TFS, the user running the Team Foundation Administration console requires the following permissions and role memberships.
-Membership in the serveradmin server role
-ALTER ANY LOGIN, CREATE ANY DATABASE, and VIEW ANY DEFINITION server scoped permissions
-CONTROL permission on the master database
In addition, I don't it is a good idea to remove the Optimize Database job; and I think it is OK to remove the SQLAgentUserRole, but why do you want to do that?
I'm looking at using SQL LocalDB as the client side database which will replace the current SQL CE 3.5 database inside an in-house application developed in .net 4.
I've come across a problem that I'm not sure how to get around and that's with security setup of the LocalDB instance.
If I setup a script inside .net to create a private LocalDB instance, e.g. (localdb)\T1, then create a new database inside that instance plus add a SQL user account + password (non domain account), how do I stop the local windows users (like my own AD account) with admin level privileges from accessing the 'T1' instance + database using SSMS?
I could see a scenario playing out where we deploy the application, then we have some IT savvy user who goes snooping around and decides to install SSMS and connect to (localdb)\T1 with their windows account, which would give him/her full access to the database, which is exactly what I'm trying to stop from happening.
Some of our staff work remotely with no connection to a domain so we give them local admin rights to their pc so they can install software, so even if I could block their assigned windows login name, there would be nothing stopping them from setting up a new local admin account and logging in with that, opening SSMS then accessing the database.
Any pointers on this would be greatly appreciated!
In fact, it shouldn't be so hard. Install SQL Server on client machine using local admin account. To make you life easier, use Mixed Authentication.
After you have your instance installed, local admin account should have sysadmin server role assigned (that's normal security settings). Now, use the following:
Create new SQL Server user and assign sysadmin server role to that account. Close SSMS and log-in using new credentials. Or simply use sa account (not so good practice but in this case it's OK).
Go to "Security - Logins" and remove sysadmin role from local admin. Also, check in user mappings and take all rights "away" from local admin.
As a test, try to log-in as local admin, I guess you won't be able to log-in into server because there is no "home" database for that user. But even if you can log-in, it has only "public" role.
It's up to you to install your database and secure it - assign permission to user of your choice.
Regarding you fear that local admin can install MSSQL again: he/she can install it, but it would be another instance. That instance knows nothing about users in your instance so you should be safe.
You can also consider usage of application roles in SQL server.
I'm trying to run a database import using the Copy Database Wizard Tool from SQL Server Management Studio in SQL Server 2008.
I have connected to my database using the sa account and when I run the process I used the sa account on both the source and destination database.
All the processes are failing with
Event 18556, Login failed for user '{domain}\administrator'.
Reason: Failed to open the explicitly specified database. [CLIENT: ]
The SA account should have sufficient rights to import the database and the administrator account definitely has the rights.
So, the first question is, why is the administrator account even mentioned since everything is run as SA?
The second question is, why is the administrators account failing to open the explicitly specified database, when that account has total control of all databases on the destination server?
Finally, what exactly is the specified database? There is data in the binary portion of "event log" that points to Master but no mention of the database anywhere else.
Are you connecting to SSMS using pass through authentication? Your wizard will run as your user I believe if so. Connect to your database server in SSMS using the sa account and then try launching it.
Give it a valid account to the other database, sa needs access locally, the 2nd account needs access on your other SQL server.
Alternatively, make sure your domain user has access to the database in question (not the server, the db is dif.) and run it that way.
The master db is where all the sys tables reside, it's the overlord db so to say: http://msdn.microsoft.com/en-us/library/ms187837.aspx
I have been allocated the responsibility at work of revising the current reporting services authentication process. The aim is to maintain the necessary level of security and also simplify the maintenance/configuration of granting access to the individual reports.
I do NOT have access to the domain controllers to be able to modify or create new AD groups. I have to work with the groups/users that currently exist.
In terms of authentication, it seems that I have the option of using either:
Windows authentication
SQL Server authentication.
Both the report server and the report database will reside on the same server. With this in mind, I understand that Windows authentication is probably a better solution as there is no need to maintain a separate SQL Server table of Users (and their passwords). Granting access to a report once it has been deployed on the report server, would simply involve adding the user/group to the report (load the report in a browser and access the Properties\Security option).
Using the second option of SQL Server authentication does not seem as appropriate as using Windows authentication for the reason the report server and report database are on the same box.
I am using SQL Server 2000 databases. The version of reporting services I have installed is Microsoft SQL Server 2008.
Please could someone let me know if my thinking is correct (i.e. I should go for Windows authentication). Cheers.
Jimmy
Sql Server authentication is not an option for users connecting to SSRS. It is an option for SSRS connecting to databases where it will get its data.
So bottom line, yes, you need to use Windows Authentication for user connections to SSRS. You can use special user names such as "Authenticated Users" or "Everyone" in SSRS to allow broad access.
I understand that you don't have access to AD, but managing the user accounts' membership in AD groups would be much easier than tracking and managing individual access in SSRS.
But without the AD access you can still add Windows/AD accounts to the report permissions and use those. You just create a more complex system, since you need to manage permissions for every individual separately. You can group the reports in folders and secure the folders: the reports can inherit that security.
Best practices recommend not installing Sql Server to run as SYSTEM. What is the bare minumum you need to give the user account you create for it?
By default, SQL Server 2005 installation will create a security group called SQLServer2005MSSQLUser$ComputerName$MSSQLSERVER with the correct rights. You just need to create a domain user or local user and make it a member of that group.
More details are available in the SQL Server Books Online: Reviewing Windows NT Rights and Privileges Granted for SQL Server Service Accounts
Typically I create a Domain User with only the specific rights on the network which I will require the server to have (i.e. to write to the network backup drive), I then add the account to local power users or local administrators depending on what needs to be done on the machine, however this isn't required. I've installed SQL a number of times using a standard user as a Service Account but you need to ensure that the user has access to write to the resources as listed at https://web.archive.org/web/20081223155956/http://support.microsoft.com/kb/283811 . Its probably not as defined an answer as you wanted but I'm only a developer (not a professional DBA / System Engineer).
Mauro
PS dont downmark me for saying "only a developer" :P