I have a scheduled task on my warehouse server that runs a batch file, which triggers a command that runs a sproc on my SQL server. The task is set up to run as ACCOUNTS\sqlservice.
I recently made some updates to my linked server objects to avoid warehouse users querying data from them by mapping just the user(s) that should have query access in the linked server security. While mapping the local sql server login to sql server login works, I can't seem to map a domain account between the two servers successfully, that is, the ACCOUNTS\sqlservice, who has sa on both servers.
Any ideas on how I can give the sqlservice account access to query the linked server object? Thank you!
One solution: use an appropriate alternative user for the remote mapping that is a local sql server login rather than a domain account.
There may be another way to do this between domain accounts, but haven't the time for that.
Related
I have a Cloud hosted Database, maintained by a different company. Here is my scenario:
I would like to bring down the entire database, schema and data, and keep my Local database updated real-time(sql server 2008r2).
I cannot setup replication inside SQL server, I do not have permissions on the cloud server.
I cannot use triggers.
I cannot use linked servers
They would provide me a copy of backup (nightly)and access to the transacrion logs every 1 hour
How can I use these to update my entire database.
Thanks in advance
I backed up a database from a SQL Server 2008 and restored it to my local machine using SQL Server 2012, now I'm trying to login to the server with the copied database user account and I wasn't able to do so.
After googling the issue I found that I have to change the user type from SQL User Without Login to SQL User with Login but the drop-down list is disabled as you can see in the picture below, how can I fix this and is this is the best way of doing what I need to accomplish or do I need to add this user to the server level?
I remember running into this before when doing backup / restore across servers. Basically it comes down to how SQL Server works. There's SQL Server users & there's database users (SQL Server users who are database users are represented via mappings). They are however not the same thing.
A SQL Server user belongs to the SQL Server, a database user ONLY belongs to the associated database. What happens when you have a database user, but not a SQL Server user? You can't login to SQL Server non-obviously.
Thereby what I do is after moving the database, I add the user I need to login as to SQL Server users using SSMS, remove the old database user (it's got dependencies associated w it that prevent mapping to it) & lastly make a new user on the database by mapping my SQL user to the database w appropriate permissions.
This approach is by no means elegant, but it works 100% of the time w no code needed, & you should consider a more permanent system if you have automated backup / restores happening. For the one off, this is how I've always done it.
I am trying to audit our security for our SQL Servers. I am trying to run a trace on a database to get the users that logon and access the database. However if the query is ran from a different database there are no logon events generated.
Example: I am trying to trace logons for [Database2]
Use [Database1];
Go
SELECT * FROM [Database2].[dbo].[Table]
But there are no events logged in the trace under Database2.
Our environment is SQL Server 2008 R2 Standard Edition. Any suggestions would be appreciated.
This is because database users don't login to SQL Server. SQL Server has security entities called "logins" that are used to login to an instance of SQL Server. These logins are either Windows logins from Active directory or SQL Server logins, that you can define and specify user name and a password. Database "users" are defined at database level. Users don't login to anywhere, they don't even have a password. The idea is that SQL Server "login" is mapped to a specific database "user" when connecting to a specific database.
Your query to a different database doesn't generate a login, because logon is a server-wide event, not a database-wide.
For example see here
My requirement is to retrieve data from a local SQL server and store that data in remote server. I would like to get the data from the local SQL Server and use that data in my application to proceed further.
Yes, see Create linked server with SQL command.
You can create the linked server either locally (I'd recommend that) or remotely
If you mean you want your remote server to execute queries on the local one then yes, but...
Setting this up is a fair bit of work and if I remember rightly needs a hefty amount of privileges on the remote server.
Might be easier to set up the linked server locally. NB assumes the account the local server is running as can reach the remote machine, and can access it.
I'd be a bit nervous about doing this, internally for fear of some admin type breaking it, if it's over the internet, then securing it will be a nightmare even if they allowed their server to be accessed directly..
You might find it easier to do it via the client, though that will dpend on how much data you want to synchronise, and then perhaps a briefcase approach might do the job better.
You can set up linked servers either via the GUI in SSMS, or via scripts. A couple of things to look out for though - first make sure you create a login account on each server that is mapped to the appropriate database on each server, with the least possible permissions. Then verify the mapping after you've set it up. Be aware that you are opening up the attack surface via this solution, so you may want to have your admin set up auditing too.
Problem
Is it somehow possible to create a Windows Authentication login for a SQL database without performing a check for the user at creation time?
Example
Consider ServerA that exists in our DomainA, and ServerB that exists in the customer's DomainB. Being separate companies, DomainA and DomainB never share resources. But, if we backup from ServerB and restore to ServerA, we are able to see the existing SQL logins for users from DomainB, and even modify and code against these logins. This is good, because we are able to develop the database schema on ServerA and then publish to ServerB.
But, if I want to add a new user for this database, and am working on ServerA in DomainA, the following command produces an error:
CREATE USER [DomainB\User];
Windows NT user or group 'DomainB\User' not found. Check the name again. (Microsoft SQL Server, Error: 15401)
This is bad, because we're no longer able to develop on ServerA using the same schema as ServerB.
Backstory
I'm attempting to bring our database-driven application's database schema into source control using a Visual Studio 2010 Database Project. It's important to me to make this work well enough to convince the boss not to continue using 60-GB database backups in a zip file as a means of 'Version Control' (especially since this is just for schema, and not a backup routine). VS2010 DB Projects use scripting to create/modify databases, and so they can't create WinNT users for an unknown domain. In order to get the boss's buy-off, we're going to have to be able to match the capabilities of restoring a backup, and that means being able to re-create users for domains that we don't have access to.
Using SQL Server 2008 in my case.
Note - DBProjects are best suited to managing and versioning your SCHEMA, not your data.
If you want to keep rolling backups of your SQL databases as a whole, then I'd recommend a decent backup strategy.
If you want to better manage your databases' evolving schemas, then using DBProjects may well be your best bet.
FWIW, if you reverse-engineer a DB into a DBProj, you could then run a script to replace DomainB\known-user with DomainA\known-user prior to deploying within DomainA, no?
No, because SQL needs to know the windows SID (ugly GUID) of the user at the time it's created.
Note that you can, however create a SQL or Windows User with the same name and password as your remote SQL, Machine, or Domain user, and it will be able to log in.