I need to check some job that ran on a SQL Server 2008, but the user used when logging on to that server can not have sysadmin rights.
So my question is can I have an user that can access SQL Server Agent - Job Activity Monitor, but that user is not in the sysadmin group?
Add the user to msdb and put them in the SQLAgentOperatorRole fixed database role. For more information see the Books Online topic How to: Configure a User to Create and Manage SQL Server Agent Jobs.
In T-SQL, this would be:
USE msdb;
GO
CREATE USER UserName FROM LOGIN [UserName];
GO
EXEC sp_addrolemember N'SQLAgentOperatorRole', N'UserName';
GO
In SQL Server 2012 that sp_addrolemember should not be used; instead:
ALTER ROLE [SQLAgentOperatorRole] ADD MEMBER [UserName];
Related
in Azure monitoring need to find out which user and server details for the failed connections in mysql dbs.
Is there any query to find out and user details.
also once we find out user and details we need to add that logic into logic app.
You can navigate to your SQL server overview page and know your username under the name of server admin.
and can reset the password as mentioned in the below image.
Following the above way you can add the details to connect to your SQL Server in logic apps
I have SQL Server 2008 running on my local machine. I have removed myself from Database --> Sercurity. Now I cannot login and I am getting following error
Login Failed for User (Microsoft SQL Server, Error: 18456)
My Login is auttenticating from Active Directory
If you removed or disabled your login to the dmbs and have no other Logins to repair the situation, this Tip from a Microsoft Blog may apply:
Here are the steps you will need to perform:
Start the SQL Server instance using single user mode (or minimal configuration which will also put SQL Server in single user mode)
From the command prompt type: SQLServr.Exe –m (or SQLServr.exe –f)
Note: If the Binn folder is not in your environmental path, you’ll
need to navigate to the Binn folder.
(Usually the Binn folder is located at: C:\Program Files\Microsoft SQL
Server\MSSQL10.MSSQLSERVER\MSSQL\Binn)
Once SQL Server service has been started in single user mode or with minimal configuration, you can now use the SQLCMD command from
command prompt to connect to SQL Server and perform the following
operations to add yourself back as an Admin on SQL Server instance.
SQLCMD –S
You will now be logged in to SQL Server as an Admin.
Once you are logged into the SQL Server using SQLCMD, issue the following commands to create a new account or add an existing login to
SYSADMIN server role.
To create a new login and add that login to SYSADMIN server role:
1> CREATE LOGIN ‘’ with PASSWORD=’’
2> go
1> SP_ADDSRVROLEMEMBER '','SYSADMIN'
2>go
To add an existing login to SYSADMIN server role, execute the
following:
1> SP_ADDSRVROLEMEMBER ‘’,’SYSADMIN’
The above operation will take care of granting SYSADMIN privileges to
an existing login or to a new login.
Once the above steps are successfully performed, the next step is to stop and start SQL Server services using regular startup options.
(This time you will not need –f or –m)
On my production system I login to SQL Server with CPSDOM\mconnors. When I execute 'SELECT CURRENT_USER;' it returns 'CPSDOM\mconnors'.
On my test system I login to SQL Server with CPSDOM\mconnors. When I execute 'SELECT CURRENT_USER;' it returns 'dbo'.
Can someone help me understand what is going on? Is this difference based on a configuration setting?
Thanks in advance.
There's a difference between a login and a user on SQLServer.
Each database has a set of users and a set of logins. Logins are server-wide, users are per-database. The login can be your Windows user account or a SQLServer internal one (eg sa).
The login is mapped to a user for each database, so in the production system you have your windows user (the login) mapped to a user with the same name. In the test system they just mapped your login to the inbuilt dbo user.
You should not rely on your login being the same name as the windows account, when you setup security for the sql server, it will default-map your windows user to a new sql user of the same name, but sometimes people map it to pre-defined sql users, and sometimes for dev/test to one of the 'admin' users that already exist.
You can see this mapping in the security section of SQLServer management studio, or in the users section of the individual database.
I want to put the logs in some stored procedures in our database to monitor the working of stored procedures. I am new to SQL Server 2008. The logs should be created on the production server.
I had tried this link:
http://www.codeproject.com/Articles/18469/Creating-Log-file-for-Stored-Procedure
but get the error message:
The EXECUTE permission was denied on the object 'xp_cmdshell', database 'mssqlsystemresource', schema 'sys'.
Please provide me some needful.
First of all are you sure you want to log data to text file? May be it will be better to store log into separate table ?
If you want to work with text file:
Look at description xp_cmdshell
The Windows process spawned by xp_cmdshell has the same security rights as the SQL Server service account.
Check the security rights for this account.
xp_cmdshell can be enabled and disabled by using the Policy-Based Management or by executing sp_configure.
Check you have it enabled.
EXEC sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO
EXEC sp_configure 'xp_cmdshell', 1
GO
RECONFIGURE
GO
When it is called by a user that is not a member of the sysadmin fixed server role, xp_cmdshell connects to Windows by using the account name and password stored in the credential named ##xp_cmdshell_proxy_account##. If this proxy credential does not exist, xp_cmdshell will fail.
You need to create proxy account.
EXEC sp_xp_cmdshell_proxy_account [MyDomain\SQLServerProxy], 'usdcu&34&23'
Add permissions to use this SP:
USE master;
GRANT EXECUTE on xp_cmdshell to Current_user
Here is a more detailed information.
granting permissions using the master database to the object should do
Use Master
grant execute on xp_cmdshell to 'user'
Using xp_cmdshell for logging is bad for both security and performance. Please delete that codeproject link from your browser and forget you ever saw it. Seriously, it is badness.
If you want to log calls to procs, either:
Set up a table for this (as demas also suggested). You can have a DATETIME field defaulted to GETDATE() or GETUTCDATE(). You can have a field for the Proc Name, a field for parameters. Whatever.
or
Use SQLCLR to create a stored procedure that does a simple File.Write of the info. You can use Impersonation (something xp_cmdshell can't do) to have the security context be that of the person running the proc and not the Log On account of the SQL Server process. This approach is far more efficient and contained than xp_cmdshell, even when not using Impersonation.
or
Do a combination of the log table + SQL CLR [or something else]: You can log to the table for immediate writing. And then set up a SQL Agent job to archive entries over X days old to a file using SQLCLR or some other means. This way the table doesn't grow too big with info that is probably older than you need anyway for researching problems that are currently happening.
I have a SQL Server server which has around 50 databases on it.
I wish to create a new Login for a client who wishes to have access to their database.
But I don't want to give them access to the other 49 databases.
How can I do this?
I think this is what we like to do very much.
--Step 1: (create a new user)
create LOGIN hello WITH PASSWORD='foo', CHECK_POLICY = OFF;
-- Step 2:(deny view to any database)
USE master;
GO
DENY VIEW ANY DATABASE TO hello;
-- step 3 (then authorized the user for that specific database , you have to use the master by doing use master as below)
USE master;
GO
ALTER AUTHORIZATION ON DATABASE::yourDB TO hello;
GO
If you already created a user and assigned to that database before by doing
USE [yourDB]
CREATE USER hello FOR LOGIN hello WITH DEFAULT_SCHEMA=[dbo]
GO
then kindly delete it by doing below and follow the steps
USE yourDB;
GO
DROP USER newlogin;
GO
For more information please follow the links:
Hiding databases for a login on Microsoft Sql Server 2008R2 and above
Connect to your SQL server instance using management studio
Goto Security -> Logins -> (RIGHT CLICK) New Login
fill in user details
Under User Mapping, select the databases you want the user to be able to access and configure
UPDATE:
You'll also want to goto Security -> Server Roles, and for public check the permissions for TSQL Default TCP/TSQL Default VIA/TSQL Local Machine/TSQL Named Pipesand remove the connect permission
For anyone else out there wondering how to do this, I have the following solution for SQL Server 2008 R2 and later:
USE master
go
DENY VIEW ANY DATABASE TO [user]
go
This will address exactly the requirement outlined above..
this is to topup to what was selected as the correct answer. It has one missing step that when not done, the user will still be able to access the rest of the database.
First, do as #DineshDB suggested
1. Connect to your SQL server instance using management studio
2. Goto Security -> Logins -> (RIGHT CLICK) New Login
3. fill in user details
4. Under User Mapping, select the databases you want the user to be able to access and configure
the missing step is below:
5. Under user mapping, ensure that "sysadmin" is NOT CHECKED and select "db_owner" as the role for the new user.
And thats it.