Folks, please excuse my lack of knowledge in this area, it's something I've been tasked with fixing, but haven't had much luck with..
I've got a server, with SQL Server 2008 R2 installed, it's the default isntance, and I can see that the SSIS service is installed and currently running.
The issue I have is that, none of the SSIS roles described on this page:
http://msdn.microsoft.com/en-us/library/ms141053.aspx
Are present in the server roles subsection of security... How do I make these available, or perhaps, why are they missing?...
Thanks in advance,
Dave
The roles db_ssisadmin, ds_ssisltduser and db_ssisoperator can be found within the system database msdb. Refer screenshot #1.
Refer the following link for answer mentioned in http://social.msdn.microsoft.com:
SSIS Package Roles - Assigning user to Role
Answer excerpt from social.msdn.microsoft.com:
These are just roles in the msdb database.
To assign the user to the role, you need to have the login as a user in
that database and assign the role as usual (i.e. go through the gui to
set the roles of the user or use T-SQL to set them).
USE msdb;
GO
EXEC sp_addrolemember N'db_dtsltduser', N'{User Name Here}';
GO
Hope that helps.
Screenshot #1:
Related
I am looking for an easy way to create logins and associated users into SQL Azure.
The thing is that, with Azure, one first needs to create a login in the master database.
Based on that login I need a user to be created in a specific database (DATABASE1)
After that roles need to be assigned:
CREATE LOGIN login1 WITH password='<ProvidePassword>';
CREATE USER login1User FROM LOGIN login1;
EXEC sp_addrolemember 'dbmanager', 'login1User';
EXEC sp_addrolemember 'somerole';
The thing is, since one cannot use the USE command to switch databases, this seems to become quite a tedious task. More so because the number of accounts per database can range from ten to a few hundred, databases and users are being added all the time.
So I need a solution that can be easily reused.
I would like to have a script of some sorts (powershell?) that will read a file (containing username, password and databasename) and then create the appropriate logins, users and rights.....
Icing on the cake would be some sort of job that would regularly check whether there are (new) files present in a certain folder and if so, read those files and create new accounts where needed.
I must admit that I do have TSQL knowledge, basic programming knowledge but no Powershell experience at all. How would you advise that I go about? Is powershell the way to go? Or are there any other mechanisms I could use?
Greetings, Henro
As described here you sure can use Powershell from your desktop machine to connect to SQL Database to manage SQL Database account in similar way you would connect to other SQL Server.
PowerShell scripts can run on an on-premise computer and connect to SQL Database using System Management Objects or Data-tier Applications Framework object.
The very first step in this direction is to get your Powershell commands connecting to SQL Database and you can use this article to get upto here.
After that you just need to use the Powershell script to create users login and searching quickly I found this article and this one promising which includes a few more functionalities along with your objective. You may need to tweak script to make it working with SQL database.
Finally you can search internet to read data form a file (or XML to be better) and feed user info to your SQL Database script. If you have any issue in between step, open specific question and you will be helped.
I executed the task Take offline of a SQL Server 2008 R2 database.
I cant bring it online!
I tried with
USE master;
GO
ALTER DATABASE [DBNAME] SET ONLINE
I get an error.
User does not have permission to alter database 'DBNAME', the database
does not exist, or the database is not in a state that allows access
checks.
I also tried using the task Bring online and I get the exact same error.
Can anyone help me asap?
I think you're going to need to login with the SA account, or some other account with sysadmin privileges, and then run your code to put it back online. While you're in there, add sysadmin to your account, too. If you don't own the database, you may need to talk to someone else to get the SA password, or ask them to do it for you. Unless you don't have the SA password or it's been dumbed down for security reasons.
Your error is too generic to be usable. Do you actually have the rights to alter the database (I guess you do if you managed to bring it offline)? Can you access teh SQL logs (accessible in the tree via Management > SQL Server logs)? Are you sure the user who is executing the script is the one you expect?
Also, you can try any of the following
* restart the service then retry
* Use the mouse GUI o bring it online (right click on the DB, Tasks, Bring Online)
Had same problem, same error. Even logged on as SA and returned same error. On both problem database the owner was not SA.
Solved by attaching the database. This gives you the opportunity to rename the database was well assign an owner. Assigned owner as SA.
Detached failed database the renamed the newly attached database to the original name.
A lesson in always give SA ownership of new databases.
I'm installing an SQL database and our application on a single PC. Under Vista this needs to be installed by an administrator account, but this means that the regular user account(s) can run our program, but it can't access the database it needs.
What I need is a simple way of allowing all NT logins on the PC to have access to the database.
I thought I'd solved it: In SSMS I can manually assign db_datareader/writer roles to BUILTIN\Users, and it works perfectly.
However, if my installer programmatically executes the following, it doesn't work:
USE [OurDatabase]
GO
EXEC sp_addrolemember N'db_datawriter', N'BUILTIN\Users'
GO
EXEC sp_addrolemember N'db_datareader', N'BUILTIN\Users'
GO
The users get assigned the roles, but they still can't access the database. The only difference I can see in SSMSE is that in the latter case, they also gain ownership of a new "BUILTIN\Users" schema, which I suspect may be screwing things up. Clearly SSMS does something slightly different...
Can anyone suggest a way to get this working programmatically?
In OurDatabase, what user is mapped to the login? Do you see a difference in the SSMS method vs. programmatic? What is the default schema for the user mapped to the group login when it works?
What about setting the application only to run as administrator on vista?
Ah, it appears that SSMS also does a
CREATE USER [BUILTIN\Users] FOR LOGIN [BUILTIN\Users]
on the database if the user doesn't exist.
I was twiddling the permissions on and off several times while trying to work out what to do, and on subsequent attempts the user already existed so SSMS didn't bother with the CREATE command. So when I finally figured out what I needed to do, I was getting an incomplete (for my needs) script out of it.
This wasn't obvious because the effects of this command are not seen in the user properties; they appear in the User Mapping in the Server Security\Logins section of SSMS.
Thanks to Aaron (the mention of logins had me looking at the Security\Logins page and I spotted the difference in the mappings there)
By default if you connect to a remote SQL Server via an account that has access to say 1 of the 10 databases. You will still see in the Object Explorer all other databases, obviously due to permissions you cannot actually query them, but you can see their names.
I have heard that there is a method that disable this behavior, but I've been unable to find the answer, does anyone know how to do this? To give an example I have a SQL Server called MyDbServer, it has 4 databases,
MyDatabase
YourDatabse
PrivateDatabase
ReallyPrivateDb
If you connect via an account that only has permissions to "YourDatabse" you will still see a listing of all other databases, attempts to query will grant "select" permission denied or a similar error.
For security resons, we DO NOT want users to see any database other than the ones they are mapped to.
This blog talks about methods for hiding DBs for both SQL 2000 and SQL 2005.
After having my client struggle with the identified resources I did some testing and created this blog posting with a bit more context and instruction on how to get this working.
The short of it is:
use master
go
deny VIEW any DATABASE to login1
go
where login1 is the login account that you want to limit.
When I try to create a SQL Server Login by saying
CREATE LOGIN [ourdomain\SQLAccessGroup] FROM WINDOWS;
I get this error
The server principal 'ourdomain\SQLAccessGroup' already exists.
However, when I try this code
DROP LOGIN [ourdomain\SQLAccessGroup]
I get this error
Cannot drop the login 'ourdomain\SQLAccessGroup', because it does not exist or you do not have permission.
The user that I am executing this code as is a sysadmin. Additionally, the user ourdomain\SQLAccessGroup does not show up in this query
select * from sys.server_principals
Does anyone have any ideas?
We are still struggling to understand the HOW of this issue, but it seems that [ourdomain\SQLAccessGroup] was aliased by a consultant to a different user name (this is part of an MS CRM installation). We finally were able to use some logic and some good old SID comparisons to determine who was playing the imposter game.
Our hint came when I tried to add the login as a user to the database (since it supposedly already existed) and got this error:
The login already has an account under a different user name.
So, I started to examine each DB user and was able to figure out the culprit. I eventually tracked it down and was able to rename the user and login so that the CRM install would work. I wonder if I can bill them $165.00 an hour for my time... :-)
is this when you are restoring from a backup or something? I've found that the following works for me in situations when I'm having problems with user accounts in sql
EXEC sp_change_users_login ‘Auto_Fix’, ‘user_in_here’
This happened to me when I installed SQL Server using a Windows username and then I renamed the computer name and the Windows username from Windows. SQL server still has the old "Computername\Username" in its node of Server->Security->Logins.
The solution is to go to Server->Security->Logins and right-click -> rename the old Windows user and use the new MachineName\Username.
I faced similar issue and i believe the issue was as a result of trying to recreate a login account after deleting an existing one with same name.
Just go through the various databases on the server using SQL Studio.
Example steps:
DBName ->Security->users
at this level for each of the databases, you may see the name of the user account there. Delete all occurrence in each Database as well as its occurrence in the top level Security settings at
Security->Logins
When done, try recreating the login account again and you should be fine.
I had the same story as Shadi.
On the top I can add that it can be also done by query:
ALTER LOGIN "oldname\RMS" WITH name="currentname\RMS"