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.
Related
How can I copy file from 1 server computer to another using xp_cmdshell with credentials.I have an application server and database server.I want to transfer a file from data server to application server by executing the xp_cmdshell command by using the network credentials of the application server. Iam using sql server 2012 and I have configured xp_cmdshell in the SQL Server.
I got "Access is denied" error when I tried to transfer file from my local computer to a specific folder in my shared network.
Please help me...
It's a guess of course.
From this MSDN article you can find that
The Windows process spawned by xp_cmdshell has the same security
rights as the SQL Server service account
that means that this windows service account should have rights to the shared folder - which is not true I believe in your case.
So, to fix this you can specify a xp_cmdshell Proxy Account and then xp_cmdshell will execute commands under this specified account
Example:
EXEC sp_xp_cmdshell_proxy_account 'SHIPPING\KobeR','sdfh%dkc93vcMt0';
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)
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
In SSMS 2008, I am trying to execute a stored procedure in a database on another server. The call looks something like the following:
EXEC [RemoteServer].Database.Schema.StoredProcedureName
#param1,
#param2
The linked server is set up correctly, and has both RPC and RPC OUT set to true. Security on the linked server is set to Be made using the login's current security context.
When I attempt to execute the stored procedure, I get the following error:
Msg 18483, Level 14, State 1, Line 1
Could not connect to server 'RemoteServer' because '' is not defined as a remote login at the server. Verify that you have specified the correct login name.
I am connected to the local server using Windows Authentication. Anyone know why I would be getting this error?
'Be made using the login's current security context' translates as impersonation (aka. as 'self-mapping' in SQL Server linked in terms). Access a remote server under an impersonated context means delegation. So you need to set up the constraint delegation, see Configuring Linked Servers for Delegation:
Requirements for the Client
The Windows user must have access permissions to SQLSERVER1 and
SQLSERVER2.
The user AD property Account is sensitive and cannot be delegated must not be
selected.
The client computer must be using TCP/IP or named pipes network connectivity.
Requirements for the First/Middle Server (SQLSERVER1)
The server must have an SPN registered by the domain administrator.
The account under which SQL Server is running must be trusted for delegation.
The server must be using TCP/IP or named pipes network connectivity.
The linked server logins must be configured for self mapping.
Requirements for the Second Server (SQLSERVER2)
If using TCP/IP network connectivity, the server must have an SPN registered by the domain administrator.
The server must be using TCP/IP or named pipes network connectivity.
run the following command, and it may fix it for you
exec sp_AddRemoteLogin 'YourServerName','LoginName'
I think (not sure) that the passwords have to be the same on both machines.
I have an asp.net website on a server and the db MS SQL 2005 on another server, the last few days the website show me this error message:
"A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)"
When i opened the DB server i found in the event viewer i found that there is a lot of fail login to the sql server from strange IPs, which are not ours, i think they are trying to hack the db,
Note the db is window authentication.
My Question is, how to stop that?
The best thing you can do is deny access to your server's SQL port on your firewall. The request will never reach your sever and you'll be good to go. You probably want to deny 1433 and 1444.
You'll want to setup your firewall to deny any access to the SQL Server from the outside world. You'll probably also want to deny access to your webserver from the outside world on any port other than 80 and 443 (is SSL is used). Otherwise you are just asking for your servers to be broken into (if they haven't been already).
If your servers are at a different site than you or your office setup a site to site VPN between your office and the servers so that you can access then directly.
Restrict IP's or allow only some Mac's , look for a good firewall that can provide you with this functionality
Sounds like a compromise or someone at the very least "tinkering about" with either the Web/Apps tier or database. The latter manisfests itself if you've exposed a database instance directly to the Internet - I sincerely hope that you've not done that. If yes (drop a comment and I'll follow up off line) ..... appears that someone has initiated mulitple connect requests to brute force logon accounts. If you've a Password Policy that implements lockout then they've more than likely knocked it out. SQL Accounts? Hmm, if was me I'd try "sa" to begin with. Isn't it the web instance that can't find the database?
Checkout the principles from Chip Andrews site http://sqlsecurity.com. Also, is the IIS Config and underlying Windows O/S locked down?
Next Steps .....
How does your ASP App/Web Tier hook into SQL back-end? Via stored procedures or SQL on the fly? There is still opportunity for mis-use in either case.
For instance, in SQL2005 onwards, the more interesting Stored Procedures such as xp_cmdshell are disabled. If you have not removed the dll from the system you can still enable them i.e.
exec sp_configure 'show advanced options', 1
exec sp_configure reconfigure
exec sp_configure 'show advanced options', 1
exec sp_configure 'xp_cmdshell', 1
exec sp_configure reconfigure
And if you have SQL on the fly, then look through Input Validation Techniques recommended on this site.
Are there any areas of upload provided by the site?
If you've implemented Windows Integrated Auth, if someone has gotten to your SQL server by an interface presented indirectly via Web/App, they can then set themselves up as a Domain Admin and own your entire Windows estate.
Cheers.
BTW On the IP front .....
FYI http://www.ripe.net/ in Europe and ARIN in the US (also samspade.org) may help determine those rogue source IP addresses. You may not be able to do an awful lot with the info if those IP's are registered with 1 of the big Service Providers like BT in the UK but you never know