Environment :
Server : Windows Server 2012
SQL Server : SQL Server 2012
I want to use openrowset in my production environment without granting sysadmin to the user. saw a lot of posts about this issue but non seem to provide a solution to mine.
I performed the following steps:
Created a non administrator windows account
Created a windows authentication login in my database (not sysadmin)
Enabled 'show advanced options','ad hoc distributed queries'
Verified 'Disallow adhoc access' is disabled in the provider (key does not exist in the registry)
Enabled driver
USE [master]
GO
EXEC master.dbo.sp_MSset_oledb_prop N'Microsoft.ACE.OLEDB.12.0', N'AllowInProcess', 1
GO
EXEC master.dbo.sp_MSset_oledb_prop N'Microsoft.ACE.OLEDB.12.0', N'DynamicParameters', 1
GO
Changed the user running the SQL server service to be Administraor
Granted full permissions on the TEMP , TMP directory of the Administrator to the user created on Step1.
Whenever I run the query:
SELECT *
FROM OPENROWSET('MICROSOFT.ACE.OLEDB.12.0','Excel 8.0;Database=c:\temp\xxx.xls;','SELECT * FROM [xxx$]')
I get:
Ad hoc access to OLE DB provider 'MICROSOFT.ACE.OLEDB.12.0' has been denied. You must access this provider through a linked server.
It does not seem to even try to access the file because whether it is there or not I get the same error. When I run it with the sysadmin user it works and when I try to query a non existing file I get error it can't find it in oppose to the non sysadmin user.
Maybe I am missing a permission on different directory or the the non sysadmin user is missing other permission.
Can you please advise?
Thanks
Doron
Related
On my test environment (Windows Server 2016 with SQL Server 2017), I have a working Powershell DSC configuration in push mode using SqlServerDsc, in which I add logins to the server, add database users to database roles etc. I don't use PsDscRunAsCredential so the Local Configuration Manager on the server uses SYSTEM to connect to the SQL Server instance. In SQL Server, I can see the connection coming in as domainname\computername$. No surprises there.
What I don't understand is how this can work, as domainname\computername$ is not configured as a login, nor are 'NT AUTHORITY\SYSTEM' and 'BUILTIN\Administrators'. EXEC xp_logininfo 'domainname\computername$', 'all';, EXEC xp_logininfo 'NT AUTHORITY\SYSTEM', 'all'; and EXEC xp_logininfo 'BUILTIN\Administrators', 'all'; return empty. I've also run a bunch of security report scripts I've found online, but none of them include useful information.
The SQL Server service runs under a low-privileged domain account.
Does 'NT AUTHORITY\SYSTEM' have some kind of implicit sysadmin permissions in SQL Server? I've been working with SQL Server for quite a few years now, but I can't figure this one out. The only way I can make DSC stop working ('Failed to connect to SQL instance') is by creating a login for 'NT AUTHORITY\SYSTEM' and disabling it, which somehow overrides the implicit permissions (if that's what it is).
Any ideas or pointers? Thanks!
Update: The behavior is the same on a freshly installed instance.
I am installing Sitecore9.1 with powershell using Azure SQL server and databases. While running script, it creates databases and while creating/updating MarketingAutomation databases it is giving error about 'contained database authentication'
error is - The command started with the following:
"exec sp_configure 'contained database authenticati"
Could not find stored procedure 'sp_configure'.
Install-SitecoreConfiguration : Command C:\Program Files\iis\Microsoft Web Deploy V3\msdeploy.exe returned a non-zero exit code - (-1)
I am running below command to Azure SQL server for this issue:
sp_configure 'contained database authentication', 1;
GO
RECONFIGURE;
GO
but while executing it throws error about syntax.
I could not find commands for AzureSQL or SQL2017 for contained database authentication.
I want commands for contained database authentication for Azure SQL.Please help.
sp_configure is not available on Azure SQL Database and you should use ALTER DATABASE SCOPED CONFIGURATION instead to configure Azure SQL Database options and parameters.
The following query should tell which databases have contained database authentication enabled.
select [name] as databasename, containment, containment_desc from sys.databases
As you can read on this documentation, the containment value of zero applies to Azure SQL Database, but value1 cannot be set on Azure SQL Database. However you can create contained database users on Azure SQL Database without the need to enable containment, and the contained database user model is the recommended model instead of the traditional connection model as mentioned here.
I have a Windows 2012 Server running SharePoint 2010 using an SQL Server Express locally installed. Unfortunately my logs are currently flooding with message "An exception occurred while enqueueing a message in the target queue. Error: 15404, State: 19. Could not obtain information about Windows NT group/user 'DOMAIN\user', error code 0x5." It can be 20 such messages every second!
(...and the 'DOMAIN\user' happens to be my personal account.)
Are there a job running that has missing rights? "Qoute from https://serverfault.com/questions/277551/mssqlserver-exception-occurred-while-enqueueing-a-message-in-the-target-queue-e "Try to changing the owner of the jobs to the sa account, on the properties of the job." If I'm correct the express version of SQL server cannot run jobs? Or is there someone/something that wants access to our AD? Why do that account wants to obtain information about my account 20 times every second?
I do find lot's of blogs and hints about this task, but I just dont understand the solutions. One says "To repair this, login as one of the SA accounts and grant SA access for the account that needs it." But what account needs sa access?
Change the owner to sa. Here are the steps I took to solve this issue:
Right-Click on the database and select properties
Click on Files under the Select a page
Under the Owner, but just below the Database Name on the right-hand pane, select sa as the owner.
In my case, sa was not the owner of the DB, I was. When I tried to execute CLR configuration that required sa privileges, I got the error too.
The solution:
USE MyDB
GO
ALTER DATABASE MyDB set TRUSTWORTHY ON;
GO
EXEC dbo.sp_changedbowner #loginame = N'sa', #map = false
GO
sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'clr enabled', 1;
GO
RECONFIGURE;
GO
I used help from the db team at work and this post to find the answer.
In my case the owner of the database was a domain account Domain\Me.
The error message was
Error: 15404, State: 19. Could not obtain information about Windows NT
group/user 'Domain\MyAccount'
The problem was that the database didn't know what to do with the domain account - so the logical thing to do was to use a local account instead.
I tried changing the owner of the database, but things still wouldn't work correctly.
In the end I dropped and recreated the entire database MAKING SURE THAT THE OWNER WAS SA
I also set the Broker to Enabled in the settings
Thing started magically working after this
No Domain Authentication
Failure was ultimately due to the fact that it was not able to authenticate when I was not vpn-ed into the corporate network.
For I was connecting to a local db on my work laptop, however the User 'DOMAIN\user' needed to be authenticated by AD on the corporate network.
Error was resolved as soon as I reconnected and refreshed; the error disappeared.
I had this error from a scheduled job in sql Server Agent, in my case, just after I changed the hostname of the Windows Server. I had also ran sp_dropserver and sp_addserver. My database was owned by "sa", not a Windows user.
I could login into SQL as the Windows user NEWHOSTNAME\username (I guess after a hostname change, the SID doesn't change, that's why it worked automatically?).
However, in SQL, in Security/Logins node, I had SQL logins defined as OLDHOSTNAME\username. I connected to SQL using "sa" instead of Windows Integrated, dropped the old logins, and create new ones with NEWHOSTNAME\username.
The error disappeared.
to do a bulk update for all databases, run this script and then execute its output:
SELECT 'ALTER AUTHORIZATION ON DATABASE::' + QUOTENAME(name) + ' TO [sa];'
from sys.databases
where name not in ('master', 'model', 'tempdb')
I was having the same problem. In my case it was due to the fact that my machine was part of a domain, but I was not connected to the company VPN. The problem was solved after connecting to the VPN (so the domain user could be resolved by the SQLAgent).
I had the same issue where my domain login was not being recognized. All I did was go into the SQL Server configuration manager and start the services as Network Services instead of a local service. The sql server / agent was then able to recognize the AD logins for the jobs.
In my case, it was VPN issue. When I turned on the VPN to connect with my office network & then tried to start the snapshot agent again, it started successfully.
I was facing the same issue.
Fix for me was changing the log-on from NT User to global user in Sql Server Configuration Manager => Sql Server Service => Sql Server Agent => Properties => Account name.
You should be connected with your domain. (VPN)
I would like to query data in Management Studio from a Microsoft Access 2007 database located on the same machine as my SQL Server 2012 instance. I do NOT want to use a linked server to do this as different Access databases can be chosen by the user. I am following the directions found on technet and other sources I have read said to use OPENROWSET as the proper way to do what I want, but when I execute this in Management Studio...
SELECT *
FROM OPENROWSET('Microsoft.Jet.OLEDB.4.0',
'C:\Users\oliver.klosoff\Desktop\New folder\41000-13-0085 Consolidated Killers LLC.mdb';
'admin';'',tblTtlHrsFringes);
...I get the error below:
Msg 7302, Level 16, State 1, Line 1
Cannot create an instance of OLE DB provider "Microsoft.Jet.OLEDB.4.0" for linked server "(null)".
The database does not have a password set for the admin user, and the admin user has permissions to read this table. Access 2007 32bit is installed on the machine, which is 64 bit, as well as the SQL Server instance. I believe that SQL Server can access the database file because when I get 1 when I execute this:
DECLARE #out INT
EXEC master.dbo.xp_fileexist 'C:\Users\oliver.klosoff\Desktop\New folder\41000-13-0085 Consolidated Killers LLC.mdb', #out OUTPUT
SELECT #out`
Is there a way to do what I am trying to accomplish?
Finally, after several unsuccessful attempts to have SQL Server "talk to" an Access database – either as a "Linked Server" in SSMS or via OPENROWSET() in T-SQL – I found this blog post that offered the following three (3) suggestions.
Tweak #1: OLE DB Provider settings
The OLE DB Provider for ACE (or Jet) must have the "Dynamic parameter" and "Allow inprocess" options enabled. In SSMS, open the
Server Objects > Linked Servers >Providers
branch, right-click "Microsoft.ACE.OLEDB.12.0" (or "Microsoft.Jet.OLEDB.4.0"), choose "Properties", and ensure that those options are selected:
Tweak #2: Temp folder permissions
This is the one that was stumping me.
Apparently SQL Server needs to write information into a temporary file while running an OLE DB query against an Access database. Because SQL Server is running as a service it uses the %TEMP% folder of the account under which the service is running.
If the SQL Server service is running under the built-in "Network Service" account then the temp folder is
%SystemRoot%\ServiceProfiles\NetworkService\AppData\Local\Temp
and if it is running under the built-in "Local Service" account then the temp folder is
%SystemRoot%\ServiceProfiles\LocalService\AppData\Local\Temp
My problem was that SSMS was running under my account (not NETWORK SERVICE) so I only had Read access to the Temp folder
Once I granted myself Modify permissions on that folder
and enabled OPENROWSET queries as documented in another question here, namely ...
EXEC sp_configure 'show advanced options', 1
RECONFIGURE
GO
EXEC sp_configure 'ad hoc distributed queries', 1
RECONFIGURE
GO
... my query worked fine:
Tweak #3: memory_to_reserve
Although I didn't need to use it in my case, the aforementioned blog also claims that adjusting the "-g memory_to_reserve" startup parameter for the SQL Server service can also help avoid similar errors. To do that:
launch SQL Server Configuration Manager
right-click the SQL Server service ("SQL Server Services" tab) and choose "Properties"
on the "Advanced" tab, prepend -g512; to the "Startup Parameters" setting
restart the SQL Server service
For more details on the "memory_to_reserve" setting see the MSDN article here.
This should work
EXEC sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
EXEC sp_configure 'Ad Hoc Distributed Queries', 1;
GO
RECONFIGURE;
GO
USE [DatabaseName]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SELECT * FROM OPENDATASOURCE('Microsoft.ACE.OLEDB.12.0','Data Source="C:\Employees.accdb"')...tblEMPS;
Assuming you have the 'Northwind' sample installed (and in folder mentioned below), will the following run?
SELECT CustomerID, CompanyName
FROM OPENROWSET('Microsoft.Jet.OLEDB.4.0',
'C:\Program Files\Microsoft Office\OFFICE11\SAMPLES\Northwind.mdb';
'admin';'',Customers);
GO
Unfortunately I have not reinstalled SQL Server since my last reimage
Microsoft.Jet.OLEDB.4.0 may not work now(in 2018). Need to download AccessDatabaseEngine_X64.exe or AccessDatabaseEngine.exe to SQL server and intall it. Then use Microsoft.ACE.OLEDB.12.0.
OBJECTIVE
Use the OPENROWSET feature to JOIN data in a query against a text file.
ERROR
Leveraging the answer from #gbn on this question I am trying to open a row set just like the OP; though the format of the file is a bit different. However, I'm getting the following error trying to access a shared folder:
Msg 4861, Level 16, State 1, Line 1
Cannot bulk load because the file "\MACHINENAME\Share\EC04.txt" could not be opened. Operating system error code 5(Access is denied.).
BACKGROUND
Please understand, I do not and will not have access to the SQL server and so I cannot place a file there.
The file resides on a Windows 7 x64 machine.
The folder has been shared as Read/Write with Everyone.
QUESTION
Can somebody help me understand what other security I need to give to allow the SQL server to access this folder?
If you are logged in as a SQL login then you must create a credential for this login and this credential must have sufficient privileges to read the share.
If you are logged in as a Windows login then you must enable Kerberos constrained delegation for the SQL Server service account.
Right now it seems you're using a Windows login and because the impersonated context cannot flow through the 'double hop' the authentication resolves to ANONYMOUS LOGON, which is not member of Everyone, hence the access denied. All this is exactly the expected behavior. Consult your network administrator about how to setup constrained delegation for the SQL Server service account targeting your desired share.
I had the same issue which was caused by using a SQL DNS-Alias. With Servername\Instance it worked, with ServerAlias\Instance I get Operating system error code 5(Access is denied.).
These steps are required on SQL Server 2017 to make OPENROWSET ('Microsoft.ACE.OLEDB.16.0','Excel 12.0;..) working with a Shared Folder (UNC file-share):
Install Microsoft Access Database Engine 2016 Redistributable
Configure the Service Principal Name (SPN) in Active Directory (as we use Kerberos authentication):
Configure Computer object Security rights (of the Database Server)
Configure Service account Security rights (the user running the SQL-server process)
Check the SQL Server Log for a message like: The SQL Server Network Interface library successfully registered the Service Principal Name (SPN) [ MSSQLSvc/SRV-DB-01.domain.local:58089 ] for the SQL Server service.
Allow Ad Hoc Distributed Queries
EXEC sp_configure 'show advanced options', 1
RECONFIGURE
GO
EXEC sp_configure 'ad hoc distributed queries', 1
RECONFIGURE
GO
Configure the Driver "Microsoft.ACE.OLEDB.16" with AllowInProcess and DynamicParameters
USE [master]
GO
EXEC master.dbo.sp_MSset_oledb_prop N'Microsoft.ACE.OLEDB.16.0', N'AllowInProcess', 1
GO
EXEC master.dbo.sp_MSset_oledb_prop N'Microsoft.ACE.OLEDB.16.0', N'DynamicParameters', 1
GO
Because we enabled AllowInProcess, the service-account and the actual user must have modify-permission to the Temp-Folder on C:\Users\service-account\AppData\Local\Temp. Otherwise you may recieve The provider reported an unexpected catastrophic failure.
Ensure you have proper permissions on the UNC share itself.
Reboot the server to ensure all changes in AD and temp-folder permissions were applied!
Use the actual Database-Server-Name to connect. Don't use an SQL-Alias name.