We have a system that uses a SQL server 2005 database with a number of views these are automatically run daily and the result sets emailed to the client.
I dont really know much about the system as a colleague of mine looks after it all but apparently its been working fine. We recently changed the admin password on the server SQL is installed on. Since then apparently a number of the views have stopped working. My colleague has said hes fixed the problem by dropping the views and recreating them.
As far as Im concerened the server admin password should have nothing to do with the views, as the application that runs them is using SQL authentication with its own login.
Any ideas what could have caused this? All the views seem to be in the DBO schema and not tied to any particular user account. I'm not convinced its anything to do with the server admin login password changing but just wanted to hear your thoughts.
Thanks.
The views should continue to work. Perhaps you have the sa password hardcoded somewhere in your process.
Related
How do I set up a database so that one does not have access to it? Even with installing SQL Server Management Studio on local machine.
In SQL Server with Windows user or sa can access all databases. How do you limit the access DB of the users?
For assuming that SQL Server is installed on the local machine, not on the server
You can try Single User Mode.
From the linked MSDN article:
Single-user mode specifies that only one user at a time can access the database and is generally used for maintenance actions.
Edit: You edited your question. Now it sounds more like you're asking about Security instead of how to limit the database to one user.
You can edit a user's security in SQL Server Management Studio by drilling down into Security > Logins. There you will see all logins to your instance. You can right click these entries and select Properties to made updates. The easiest way to completely bar a user from accessing any of the databases on the server is by selecting "Disabled" from the "Status" tab.
Well, if you really want to limit this to just one user, there is a simple way (but a bit risky).
Your Windows user is included in the group BuiltinAdministrators. If you really want to remove your Windows user, rerun the installation process and during the setup just change the users in those group.
But beware, you should provide another user, which has access to your database otherwise you end up with a database server without access to it.
Ater that, setup a database login and grant him access to the database you desire.
In the end, you can disable the sa login. This will prevent access with the sa account. But you should have a user which can manage logins and more. Otherwise you have no chance to recreate the password or any other administrative tasks.
I just enabled remote connections on my SQL Server Express 2012 installation. Now I am a little bit worried about the server security because allowing connections to everybody sounds like a big security hole for me.
Is it possible to tell the SQL Server to disconnect if the user is trying to authenticate with a user which is not on my "allow" list? If so, I could add my monitoring user to this list and don't have to worry that my administration accounts are accessible.
First of all, this is probably a question that should be asked in the DBA site. Anyway, you can set up the security of the server so that only certain users are allowed to login.
When you set up the server, you add Logins to the Server Level and then Users at the database level. Only the users that are setup can, obviously, use a particular database. You can place users into roles, so, for example, they will have read-only access to a database. You can control, down to the object level, who has access to what.
There is a good article on what SQL Server security is about here
Having said that, sometimes, after, you have setup your security, you need to disallow certain users to not be allowed to Logon. Perhaps you are doing some major upgrade to the database. One option in this case is to create a Logon trigger.
A Logon Trigger will fire every time a user Logs in. You could create a table of "allowed" users and, in the trigger, if they are not in the table you ROLLBACK, effectively disallowing the Logon.
Here is information about creating a Logon trigger
You should be able to set up the db server to only accept connections from certain IP addresses, rather than to all of them. I'm unsure of the T-SQL syntax, but someone will surely chime in with the correct one.
If you really mean business, that being said, you'll want to authenticate clients using certificates that you give them. See this and the various articles it links to:
https://security.stackexchange.com/questions/14589/advantages-of-client-certificates-for-client-authentication
Being able to connect remotely to a SQL Server instance does not mean that they can Login to it. If they are not authorized properly, they should still get kicked-off by the SQL Server Login Authentication sequence.
This is silent/invisible for "Trusted Logins" (where the authorization comes from their Windows Login/Domain Account), but it still happens.
If you look under the "Security" folder of your Server (in SSMS), you will see the list of authorized Logins to you SQL Server. By adding or removing these you can control who can actually create a session on your SQL Server.
how do I limit the user access to the database I installed to the management studio for only certain people(probably me alone) to access?
But I got a surprise when I saw the database I installed to my client pc was able to be opened using window authentication. I thought it is only able to be opened by the new user I created for that database.
so how do I remove the database from being viewed by those login using window authentication.
In the SQL management studio go to "Security". Its quite possible that you will find some Windows accounts in there. This is normal behavior and they are put there on installment of the SQL instance.
What you can do is delete the ones you don't want poking around in the DB. Make sure that you at least keep 1 db administrator.
You can also restrict their access to read_only. Read this article on creating/editing users. Goto the properties of the user you want to edit and goto "Manage Server Roles". Learn more about server roles here
By default if you connect to a remote SQL Server via an account that has access to say 1 of the 10 databases. You will still see in the Object Explorer all other databases, obviously due to permissions you cannot actually query them, but you can see their names.
I have heard that there is a method that disable this behavior, but I've been unable to find the answer, does anyone know how to do this? To give an example I have a SQL Server called MyDbServer, it has 4 databases,
MyDatabase
YourDatabse
PrivateDatabase
ReallyPrivateDb
If you connect via an account that only has permissions to "YourDatabse" you will still see a listing of all other databases, attempts to query will grant "select" permission denied or a similar error.
For security resons, we DO NOT want users to see any database other than the ones they are mapped to.
This blog talks about methods for hiding DBs for both SQL 2000 and SQL 2005.
After having my client struggle with the identified resources I did some testing and created this blog posting with a bit more context and instruction on how to get this working.
The short of it is:
use master
go
deny VIEW any DATABASE to login1
go
where login1 is the login account that you want to limit.
When I try to create a SQL Server Login by saying
CREATE LOGIN [ourdomain\SQLAccessGroup] FROM WINDOWS;
I get this error
The server principal 'ourdomain\SQLAccessGroup' already exists.
However, when I try this code
DROP LOGIN [ourdomain\SQLAccessGroup]
I get this error
Cannot drop the login 'ourdomain\SQLAccessGroup', because it does not exist or you do not have permission.
The user that I am executing this code as is a sysadmin. Additionally, the user ourdomain\SQLAccessGroup does not show up in this query
select * from sys.server_principals
Does anyone have any ideas?
We are still struggling to understand the HOW of this issue, but it seems that [ourdomain\SQLAccessGroup] was aliased by a consultant to a different user name (this is part of an MS CRM installation). We finally were able to use some logic and some good old SID comparisons to determine who was playing the imposter game.
Our hint came when I tried to add the login as a user to the database (since it supposedly already existed) and got this error:
The login already has an account under a different user name.
So, I started to examine each DB user and was able to figure out the culprit. I eventually tracked it down and was able to rename the user and login so that the CRM install would work. I wonder if I can bill them $165.00 an hour for my time... :-)
is this when you are restoring from a backup or something? I've found that the following works for me in situations when I'm having problems with user accounts in sql
EXEC sp_change_users_login ‘Auto_Fix’, ‘user_in_here’
This happened to me when I installed SQL Server using a Windows username and then I renamed the computer name and the Windows username from Windows. SQL server still has the old "Computername\Username" in its node of Server->Security->Logins.
The solution is to go to Server->Security->Logins and right-click -> rename the old Windows user and use the new MachineName\Username.
I faced similar issue and i believe the issue was as a result of trying to recreate a login account after deleting an existing one with same name.
Just go through the various databases on the server using SQL Studio.
Example steps:
DBName ->Security->users
at this level for each of the databases, you may see the name of the user account there. Delete all occurrence in each Database as well as its occurrence in the top level Security settings at
Security->Logins
When done, try recreating the login account again and you should be fine.
I had the same story as Shadi.
On the top I can add that it can be also done by query:
ALTER LOGIN "oldname\RMS" WITH name="currentname\RMS"