SQL Server (RDS instance) - Master user lost read permissions to a db - sql-server

I have a SQL Server instance (AWS RDS). The master user lost access to one of the databases (able to access others). I might have accidentally given the master user denyreader or something similar. Tried resetting the master password on the AWS console, still no use.
Does anyone know how I can get the privileges back for the master user?
Thanks in advance
grav77

Related

How to set password for SQL Server DB

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.

Unable to access Linked server tables via job in SQL Server

I have a job which tries to access data from a remote server. I have created linked server which is connected successfully. When I try to access tables by directly running the query it works fine. But when I run same query via job it throws an error "login failed for user".
Job is assigned owner 'sa' and running with ssis proxy with sysadmin and public roles. In security tab of linked server properties I have no mappings and "be made using the login's current security context" selected.
I am not sure how should I correct it. If I should add mappings then what should be mapped? Please help me as I already spend whole day exploring possible options but couldn't find anything useful.
It does not matter who is the owner of package. Only the user under whom the packet is launched is important.
If this user is Windows (Windows domen) user, read this link.
If your user is sql-user, check it password and permissions on linked server.
If all from previous step are correct, try to add this user to mapping with checked Impersonate checkbox.

SQLServer 2014 - have user access only one database

I am new to sql server so need help with this... Though I have added a user and under user mapping I have only one database that user can access, from within my application I can see he can access :master,msdb and tempdb (as well as the database I have granted him the access to).Not only from my application but also using managment studio as well. How comes he can access these first three options (databases) ? How can I have him access only designated database and nothing else?
Logins with CONNECT privilege can also access databases with the guest user enabled. The master and tempdb system databases require the guest user to be enabled for SQL Server to be functional. Enabling the guest user in msdb is optional, but some applications may not operate correctly without it enabled.
Note that access to these system databases is not normally a security concern due to meta-data visibility restrictions.

The need of user with out log in SQL Server

what is the need of user with out log in in SQL Server?
There is a contained database. I have created a user who can log into the contained database.
How to port the database to another server without additional user configuration?
Is the "user with out log" is going to help in this context?
Want to know more about users with out log in
Experts..please share your views
Users that don't have a login are users that exist only at the database level and therefore you cannot log in to the server with them.
They can however be assigned permissions and can be used to sign modules within those databases.
The most common uses I see for them during my day to day work are either loginless users that are created from a certificate which is then used to sign stored procedures, this means that the user actually logging in to SQL server requires very few permissions in the database and all the work is done in the context of the loginless user, helping to increase security.
I also see loginless users that are not created from certificates, but are made owners of schemas or procedures which then execute as owner, similar to the above, this means that the user lgging in only needs execute rights on the procedure, no table access at all.

Allow remote connection only for specific users

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.

Resources