I have a client that is having an 'Access Denied' to a call to xp_regread (trying to find the database path), but I cannot seem to reproduce this. I have tried running the following
REVOKE execute on xp_regread to public
But it still works. I also found some articles on SQL Server 2000 problems (http://support.microsoft.com/kb/887165) but the clients server is 2005. Any ideas on how to go about fixing this problem.
Edit: I have tried the following
USE MASTER
GO
REVOKE execute on xp_regread to public
GO
DECLARE #InstanceName nvarchar( 128 )
SET #InstanceName = ISNULL( CONVERT( nvarchar( 128 ), SERVERPROPERTY( 'InstanceName' ) ), N'MSSQLSERVER' )
DECLARE #InstanceKey nvarchar( 128 )
EXECUTE master.dbo.xp_regread N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\Microsoft SQL Server\Instance Names\SQL\', #InstanceName, #InstanceKey OUTPUT
print #InstanceName
print #InstanceKey
But it is still working. To be clear, I am trying to reproduce an issue where the call does NOT work. Revoking permissions was one way that I read should do it, but it still works for me.
It's an extended stored procedure so needs
EXEC master..xp_regread ...
Then, it would be
USE master
GO
GRANT EXECUTE ON xp_regread TO public
GO
If an explicit DENY has been set then REVOKE will remove it. This is not the same as GRANT though. This only applies to a normal user.
Anyone with sysadmin rights or db_owner in master (sa is dbo in master) will bypass permissions anyway
You should explicitly DENY the permission:
GRANT DENY ON xp_regread TO XYuser.
Be careful though, it might cause issues later. Like the backup dialog in SSMS won't work for that person.
To reproduce the issue, first you have to make a difference between two different errors: 'Access is denied.' and 'EXECUTE permission was denied'.
The first error is due to a configuration issue over a non sysadmin user. The second is due to lack of execute permission over the extended procedure.
For both please follow the post How to configure permissions for xp_regread
Related
I'd like to give a non-admin the ability to create folders on the SQL server's local hard disk using xp_create_subdir. Reason - need to create a folder structure so that manufacturing equipment can FTP large files. Meta data for the files is stored in SQL.
Server is SQL 2016 Express. OS is Windows 10 Pro.
I've found lots of explanations of how to get this to work but can't figure out what I'm missing. Using the SA account I've created a stored procedure like this:
use [DBname]
CREATE PROCEDURE dbo.usp_CreateDirectory
#directoryFullPath varchar(500)
WITH EXECUTE AS owner
AS
BEGIN
SET NOCOUNT ON;
EXEC master.dbo.xp_create_subdir #directoryFullPath;
END
GO
GRANT EXECUTE ON dbo.usp_CreateDirectory TO [TestUser]
GO
Code to run the stored procedure:
DECLARE #RC int
DECLARE #directoryFullPath varchar(500)
set #directoryFullPath = 'd:\FTP_Root\2020\08\22\'
EXECUTE #RC = dbo.usp_CreateDirectory
#directoryFullPath
GO
In Windows I've given NT Service\MSSQL${InstanceName} full access to d:\FTP_Root\
What am I missing? Running xp_create_subdir 'C:\FTP_Root\2020\08\22' in MSSMS works fine.
Running the stored procedure as SA or the non-admin TestUser gives this result:
Msg 229, Level 14, State 5, Procedure xp_create_subdir, Line 1 [Batch
Start Line 2] The EXECUTE permission was denied on the object
'xp_create_subdir', database 'mssqlsystemresource', schema 'sys'.
I found this on another site: https://www.sqlservercentral.com/forums/topic/xp_create_subdir-for-non-sysadmins
The headlines here are two main points
Although this post is old,
In order to solve this issue, you should make sure that your database is Trustworthy - since the SP xp_create_subdir is on different DB
You still need to set "with Execute as 'dbo'
alter database [DBNAME] set trustworthy on
- Guy-456224
And DO understand the security ramifications of using SET TRUSTWORTHY ON. It may not be a problem or... it may. "It Depends" but you won't know until you read about it.
- Jeff Moden
I completely agree with Jeff on this one. If you remotely care about security, understand what the TRUSTWORTHY setting does before adjusting it.
I think the larger question here is to ask why SQL Server needs to create the directory? Powershell could both query the database for the Directory Path and create the Directory. You could have a SQL Server Agent job that will execute this under the security context of either a SQL Server Proxy account, or the SQL Agent service account (I would pick the proxy account personally, but that's just me).
I'm trying to use another database on the same server, but my current db-user has no access to the other one.
I tried to sp_addlinkedserver-link the server to itself, so I could use sp_addlinkedsrvlogin to specify another user, but I get error messages for denied permission before I even get to the second part; I suspect because it is on the same server.
Here's what I came up with:
exec sp_addlinkedserver
#server= N'SameServer',
#srvproduct= N'SQL Server';
exec sp_addlinkedsrvlogin
#rmtsrvname= N'SameServer',
#useself= N'FALSE',
#rmtuser= N'AlternativeLogin',
#rmtpassword= N'';
The error messages tell me that the user lacks permissions for the procedure sp_MSaddserver_internal (?), as well as sp_addlinkedsrvlogin
Ultimately, I'd also like to use an alias for the connection because SameServer.dbName will be confusing, and I've found answers for doing that, but obviously, since I haven't gotten that far I can't test how that goes.
If you can run sp_addlinkedserver, then you most likely already have the permissions needed to gain access to the other database.
If you have rights to run sp_addlinkedserver, then sp_addlinkedsrvlogin would require you to know the password of "AlternativeLogin" or it has no password, ergo you don't need a linked server
Both sp_addlinkedserver and sp_addlinkedsrvlogin require elevated rights that would not typically by delegated outside the sysadmin group
Do it properly: ask your sysadmin or DBA.
I am using windows 8.1 and SQL Server 2012.
I was using an OS account "Manoj" for accessing SQL SERVER with windows authentication.
Recently I have deleted my user account "Manoj" of OS and created a new account with same name "Manoj".
But the system took the new account as "Manoj_2". This change keeps me out from accessing the old databases, I have created.
It says that
The database [dbName] is not accessible. (ObjectExplorer)
whenever I try to access any of the previous DBs I have created.
I used to create new login in SQL Server for "Manoj_2", with default DB as "master". But still the problem persists.
I cannot able to detach the DBs. I am unable to expand the DBs.
Note: In OS, I have admin rights for the "Manoj" account.
Please anybody tell me, what to do? either with OS or with SQL Server
For this situation you have to connect to database in Single-User mode.
Starting SQL Server in single-user mode enables any member of the computer's local Administrators group to connect to the instance of SQL Server as a member of the sysadmin fixed server role.
Here you can find step-by-step instruction to do this.
In short you must start the sqlserver instance with parameters -m, after start Sql Server Management Studio with windows authentication.
Now you are a sysadmin, assign the sysadmin role to your user, exit and remove the -m parameter and restart sql server.
The problem is that the user in the database is an "orphan". This means that there is no login id or password associated with the user. This is true even if there is a login id that matches the user, since there is a GUID (called a SID in Microsoft-speak) that has to match as well.
This used to be a pain to fix, but currently (SQL Server 2000, SP3) there is a stored procedure that does the heavy lifting.
All of these instructions should be done as a database admin, with the restored database selected.
First, make sure that this is the problem. This will lists the orphaned users:
EXEC sp_change_users_login 'Report'
If you already have a login id and password for this user, fix it by doing:
EXEC sp_change_users_login 'Auto_Fix', 'user'
If you want to create a new login id and password for this user, fix it by doing:
EXEC sp_change_users_login 'Auto_Fix', 'user', 'login', 'password'
this text was obtained at http://www.fileformat.info/tip/microsoft/sql_orphan_user.htm in Dez-13-2017
Really stupid solution but I'll add it here in case anyone gets here from a Google search.
I'd just restarted the SQL service and was getting this error and in my case, just waiting 10 minutes was enough and it was fine again. Seems this is the error you get when it is just starting up.
If you are using Sql Management Studio, just start it as Administrator.
Right click->Run as Administrator
This is what led me to this issue and how I fixed it:
Restored my database to another SQL server instance from a .bak file, which included a preexisting user.
Tried to access the restored database from my app as usual using the same connection string but updated server instance.
Received error.
Deleted user as the DBowner, then readded with exact same credentials, mappings, login, etc.
Was able to login as the user after readding the user after the restore.
This is caused when the user's default database is set to a database they don't have permissions or its offline.
Just try to re add the user.Pleae have a look here too.
I had twoo users: one that had the sysadmin role, the other one (the problematic one) didn't.
So I logged in with the other user(you can create a new one) and checked the ckeck box 'sysadmin' from: Security --> Logins --> Right ckick on your SQL user name --> Properties --> Server Roles --> make sure that the 'sysadmin' checkbox has the check mark.
Press OK and try connecting with the newly checked user.
In my case it worked when I had opened SQL Server Management Studio with Administrator credentials and I right-clicked on the database and select "Go online" or something like this.
Please try this script.. What this script does is it looks at the active sessions of the database and kills them so you can bring the database back online.
CREATE TABLE #temp_sp_who2
(
SPID INT,
Status VARCHAR(1000) NULL,
Login SYSNAME NULL,
HostName SYSNAME NULL,
BlkBy SYSNAME NULL,
DBName SYSNAME NULL,
Command VARCHAR(1000) NULL,
CPUTime INT NULL,
DiskIO INT NULL,
LastBatch VARCHAR(1000) NULL,
ProgramName VARCHAR(1000) NULL,
SPID2 INT
, rEQUESTID INT NULL --comment out for SQL 2000 databases
)
INSERT INTO #temp_sp_who2
EXEC sp_who2
declare #kill nvarchar(max)= ''
SELECT #kill = #kill+ 'kill '+convert(varchar,spid) +';'
FROM #temp_sp_who2
WHERE DBName = 'databasename'
exec sp_executesql #kill
ALTER DATABASE DATABASENAME SET ONLINE WITH IMMEDIATE ROLLBACK
In my case, I simply had to start the application with "Run as administrator" in order to access anything. Otherwise I'd get the error you mentioned.
Get this error in this steps:
Run "Get offline".
"Get offline" was running too long, so i closed this window.
Then i got this error.
Steps to fix:
Go to "Activity monitor" and delete all connections to this db. Then DB became really offline and all is ok.
This fixed it for me:
Use [dbName]
GO
EXEC sp_change_users_login 'Auto_Fix','Manoj', null, 'Manojspassword'
GO
In my case, restarting SQL Server Service was enough to resolve the issue.
I experienced a similar problem after running a few jobs of bulk insert through a Python script on a separate machine and a separate user from the one I am logging in to SSMS.
It appears that if the Python kernel (or possibly any other connection) is interrupted in the middle of a bulk insert job without properly 'cleaning up' the mess, some sort of hanging related to user credentials and locks may happen on the SQL Server side. Neither restarting the service nor the whole machine worked for me.
The solution in my case was to take the DB offline and online.
In the SQL Server Management Studio, that is a right click on DB > tasks > take offline and then right click on DB > tasks > bring online.
My issue got resolved by restarting the MS SQL server service, simple.
I had a similar problem, for me I had to create a new user with name that I needed, in your case you should create some like this:
USE [master]
GO
/****** Object: Login [Manoj_2] Script Date: 9/5/2019 12:16:14 PM ******/
CREATE LOGIN [Manoj_2] FROM WINDOWS WITH DEFAULT_DATABASE=[master],
DEFAULT_LANGUAGE=[us_english]
GO
ALTER SERVER ROLE [sysadmin] ADD MEMBER [Manoj_2]
GO
Execute the following sentence:
EXEC rdsadmin.dbo.rds_set_database_online dbname
I performed the below steps and it worked for me:
1) connect to SQL Server->Security->logins->search for the particular user->Properties->server Roles-> enable "sys admin" check box
I just restarted my SQL Server (MSSQLSERVER) with which my SQL Server Agent (MSSQLSERVER) also got restarted. Now am able to access the SQL SERVER 2008 R2 database instance through SSMS with my login.
Issue: The database [dbName] is not accessible. (ObjectExplorer) got the error when expanding the database.
Solution: Deattach the database > Drop Option
Attach the database again with the mdf file under the mssql data folder
Go to
Security >> Logins >>
Right click to the user >> Properties >>
On the left navigation move to >> User Mapping >> Check the database and in the "Database role membership for: <>" check "db_owner" for user that you are experience the issue.
PROBLEM SOLVED...
My requirement is that user performing alter CANNOT be sysadmin (it can have all other rights but not sysadmin).
I am running a query from local server which should modify a remote one
EXEC ('ALTER DATABASE REMOTEDB MODIFY FILEGROUP ftfg_REMOTEDB NAME=ftfg_REMOTEDB') at [REMOTESERVER]
This query works once I add sysadmin right to the user but without the right, it give the following error:
The server principal "USERWITHOUTSYSADMIN" is not able to access the database "REMOTEDB" under the current security context.
I am on SQL Serve 2008.
Please Help!
After much research: This is not possible:(
Put the EXEC command in a stored procedure and grant execute on the procedure to the user. It won't STOP a sysadmin from executing it, but it will allow others to execute it as well. Be VERY, VERY careful with this!
Can you allow the user to impersonate someone with the appropriate permissions?
EXEC ('ALTER DATABASE REMOTEDB MODIFY FILEGROUP ftfg_REMOTEDB NAME=ftfg_REMOTEDB')
AS USER = 'UserWithAppropriatePermissions'
AT [REMOTESERVER]
I tried to create a database diagramm with SQL Server 2008, but an error occurs:
Database diagram support objects
cannot be installed because this
database does not have a valid owner.
To continue, first use the Files page
of the Database Properties dialog box
or the ALTER AUTHORIZATION statement
to set the database owner to a valid
login, then add the database diagram
support objects.
Then I tried the following:
EXEC sp_dbcmptlevel 'Ariha', '90';
GO
ALTER AUTHORIZATION ON DATABASE::Ariha TO [WIN-NDKPHUPPNFL\Administrator]
GO
USE Ariha
GO
EXECUTE AS USER = N'dbo' REVERT
GO
Next erorr pops up:
Msg 15404, Level 16, State 11, Line 1
Could not obtain information about
Windows NT group/user
'WIN-NDKPHUPPNFL\Administrator', error
code 0x534.
The Problem is the name of the PC has changed into "DevPC" I also changed this in the update script, but still the same error 15404.
What can I do to fix this annoying error?
In SQL Server Management Studio do the following:
Right Click on your database, choose properties
Go to the Options Page
In the Drop down at right labeled "Compatibility Level" choose "SQL Server 2005(90)"
3-1. choose "SQL Server 2008" if you receive a comparability error.
Go to the Files Page
Enter "sa" in the owner textbox.
5-1 or click on the ellipses(...) and choose a rightful owner.
Hit OK
after doing this, You will now be able to access the Database Diagrams.
You should consider SQL authentication account for database ownership; then you don't have to worry about accounts coming and going, databases or instances moving to different servers, and your next PC name change. I have several systems where we use:
ALTER AUTHORIZATION ON DATABASE::Ariha TO [sa];
Or if you want to change the owner to that local Administrator account, then it should be:
ALTER AUTHORIZATION ON DATABASE::Ariha TO [DevPC\Administrator];
Because renaming the machine to DevPC has eliminated the local account that used to be named WIN-ND...\Administrator and this has also invalidated the current owner of the database.
If SELECT ##SERVERNAME; is not accurate (it should say DevPC), then in order to ensure that your server rename has taken hold within SQL Server, you may also want to issue the following:
EXEC sys.sp_dropserver #server = N'old server name';
GO
EXEC sys.sp_addserver #server = N'DevPC', #local = N'local';
GO
USE [ECMIS]
GO
EXEC dbo.sp_changedbowner #loginame = N'sa', #map = false
GO
It works.
Enter "SA" instead of "sa" in the owner textbox. This worked for me.
I had the same problem.
I wanted to view my diagram, which I created the same day at work, at home. But I couldn't because of this message.
I found out that the owner of the database was the user of my computer -as expected. but since the computer is in the company's domain, and I am not connected to the company's network, the database couldn't resolve the owner.
So what I did is change the owner to a local user and it worked!!
Hope this helps someone.
You change the user by right-click on the database, properties, files, owner
Select your database - Right Click - Select Properties
Select FILE in left side of page
In the OWNER box, select button which has three dots (…) in it
Now select user ‘sa and Click OK
This fixed it for me. It sets the owner found under the 'files' section of the database properties window, and is as scripted by management studio.
USE [your_db_name]
GO
EXEC dbo.sp_changedbowner #loginame = N'sa', #map = false
GO
According to the sp_changedbowner documentation this is deprecated now.
Based on Israel's answer. Aaron's answer is the non-deprecated variation of this.
I just experienced this. I had read the suggestions on this page, as well as the SQL Authority suggestions (which is the same thing) and none of the above worked.
In the end, I removed the account and recreated (with the same username/password). Just like that, all the issues went away.
Sadly, this means I don't know what went wrong so I can't share any thing else.
1.Right click on your Database ,
2.Then select properties .
3.Select the option in compatibility levels choose sql 2008[100] if you are working with Microsoft sql 2008.
4.Then select the file and write ( sa ) in owner`s textbox
100% works for me.
An easier way to solve this issues would be to right click the name of your database, choose "New Query", type " exec sp_changedbowner 'sa' " and execute the query. Then you'll be good to go.
you must enter as administrator right click to microsofft sql server management studio and run as admin
Only need to execute it in query editor
ALTER AUTHORIZATION ON DATABASE::YourDatabase TO [domain\account];
The real problem is that the default owner(dbo) doesn't have a login mapped to it at all.As I tried to map the sa login to the database owner I received another error stating "User,group, or role 'dbo' already exists...".However if you try this code it will actually works :
EXEC sp_dbcmptlevel 'yourDB', '90';
go
ALTER AUTHORIZATION ON DATABASE::yourDB TO "yourLogin"
go
use [yourDB]
go
EXECUTE AS USER = N'dbo' REVERT
go
right click on your Database , then select properties .
select the option in compatibility levels choose sql 2005[90] instead of 2008 if you are working with Microsoft sql 2008.
then select the file and write ( sa ) in owner`s textbox.
it will work probably