I have created a new sql account and assigned it dbmanager and loginmanager roles. It can be used to create new databases but I am not able to access the database afterwards with that user. When right clicking the new database to run a query, the login prompt apears and says that the security principal %user% can access the database under the current security context.
I am not able to alter or grant user any access to the DB now that I can't even run any queries.
The purpose here is that I have a powershell script that creates the databases and handles the automation under a spesific SQL user. What am I missing?
The login might lacks the necessary permissions to connect to the specified database. Logins that can connect to this instance of SQL Server but do not have particular database rights inherit the guest user's permissions. This is a security feature that prevents users from connecting to databases where they do not have permissions. When the guest user does not have CONNECT permission to the identified database and the trustworthy attribute is not set, this error message appears. When the guest user does not have CONNECT authorization to the listed database, this error message appears.
You can connect to the database in one of the following ways:
Grant the specific login access to the named database.
Grant the CONNECT permission to the database named in the error message for the guest user.
Enable the TRUSTWORTHY property on the database that has authenticated the user.
Please refer to the Microsoft Document for this error: MSSQLSERVER_916
Related
is it possible to create PostgreSQL user so that he can connect and see only one specific database? So that he could only see one database (he couldn't see the others). Ideally, I could also set the visibility of the tables in the database.
I create user like this:
create user user with encrypted password 'password';
GRANT CONNECT ON DATABASE db TO user;
although I have given the user connect privilege to only one database, he can see all other databases :(
By default the connect privilege to every database is granted to the role public, so you need to run:
revoke connect on database ... from public;
for all other databases. Make sure you grant connect back to existing users.
Another option is to restrict connections for this specific user through pg_hba.conf
So, I've been looking around for more details, but can't find it.
I have a AWS RDS Postgresql cluster. In the typical sense, when I want to add a login to my database, I use the
create user xxxx with password 'yyy'
then I grant that user access to the tables and other rights.
Now, I tried to add another user with secrets manager linked to this RDS database.
I'm not sure what to do next....should that new user I only created in secrets, appear in the login for the database, because I don't see it? How would we grant access to the tables and other things for that user?
I created a new connection in Oracle SQL Developer. Under this new connection, I created a new user. Now, I'm trying to grant roles and System privileges to this new user. I get the following error while trying to grant system privileges to the new user:
The new user has been granted all the roles successfully. However, I'm unable to grant all system privileges to it.
UPDATE:
I followed this and this links to grant sysdba privilege to the new user using the command prompt. I'm able to grant sysdba to this new user. However, when I try to grant all system privileges from the Oracle sql Developer, I get the same error (specified in the screenshot above). I am trying to grant all the system privilege to the new user because I'm getting following error while trying to access the tables of the database.
Recently I had to change my OS to Windows 10. Earlier I had Windows 7 and I didn't have any of this issues. Is this issue related to OS? Is there any problem to use Oracle SQL Developer in Windows 10?
Please refer to this blog
The ORA-01031: "insufficient privileges" error occurs when you attempt
to execute a program or function for which you have not been granted
the appropriate privileges.
For the DBA, the ORA-01031 can happen if the target OS executables do
not have read and execute permissions (e.g. (770) in UNIX/Linux), and
ensure that the oracle user is a member of the dba group (e.g.
/etc/group). There are similar permission in the Windows registry.
Inside Oracle, the "ORA-01031: insufficient privileges" error can be
avoided by signing on "as sysdba" with unlimited database privileges.
The oerr utility notes this on the ORA-01031 error:
ORA-01031: insufficient privileges
Cause: An attempt was made to change the current username or password
without the appropriate privilege. This error also occurs if
attempting to install a database without the necessary operating
system privileges. When Trusted Oracle is configure in DBMS MAC, this
error may occur if the user was granted the necessary privilege at a
higher label than the current login.
Action: Ask the database administrator to perform the operation or
grant the required privileges. For Trusted Oracle users getting this
error although granted the appropriate privilege at a higher label,
ask the database administrator to re-grant the privilege at the
appropriate label.
You should be connected as SYS or SYSTEM in order to grant SYSDBA. Are you?
For example:
connect sys/pwd#db as sysdba
grant sysdba to santobedi;
Connect as sysdba
bash-4.2$ $ORACLE_HOME/bin/sqlplus / as sysdba
show user will show user as 'SYS'
show con_name will display CDB$ROOT
SQL> alter session set container=PDB19;
Session altered.
SQL> grant sysdba to ggadmin;
Grant succeeded.
On this site SQLDude talks about Application roles for MSSQL Server.
A more secure approach you could use for this is called "Application Roles". When connecting from an application you assume a particular role and only that role is granted privileges required in the database. So all apps connect via this mechanism and don’t give out SQL or NT logins for any unauthorised use. You will have to call sp_setapprole in your application with a password, once the connection is established. Once this call succeeds then the connection gets the privileges of the application role and loses privileges of the actual user, which is what we want. So if someone tried to connect to the database from SSMS or SQLCMD, they will access the DB using their credentials, which won’t have the required permissions on the tables, since only the application role has the rights on the tables. This is more secure & reliable approach, but one that requires application code change and as a DBA you will have to create the application role in SQL Server.
However i can't find the equivalent for PostgreSQL?
Is there something like this available in PostgreSQL?
I'm not a DBA and I have got some questions around access controls for schemas. Let's say I have a Postgres server running a several databases. The admin user is postgres. I have another user tmpUser with which I could log in to the remote server using pgadmin3 client.
I now create a database called myDatabase which is by default owned by the postgres user. I then use my admin client to remotely log in to this myDatabase using the tmpUser account.
I now create a new schema inside this myDatabase called myDbSchema. I created a new role called myDbRole and did a grant usage, grant all on myDatabase, myDbSchema to the myDbRole.
The question now is how should I control access to this myDatabase. I tried to log in to the remote server using the tmpUser and when I tried to execute select * from myTable where myTable is a table in myDatabase, it came back with a permission denied sql message. So I changed the owner of the table to the tmpUser which I really do not want to!
Is there a guide or something on how I should go about creating and organizing roles with schemas in postgres?
It is not entirely clear what your problem is (for instance, what is role "myDbRole" for, is that a group role (NOLOGIN) or a user role (LOGIN)?) but in general you could follow this pattern of permission management:
Create a specific role to own a database and all or most of the objects in it. This should be a group role (NOLOGIN) for security reasons. Do not use the postgres user; if you need to login as that role often to do regular database work, you are doing something wrong. Any superuser (or other user role that has that role granted to it) can "impersonate" that owner role using SET SESSION AUTHORIZATION to do necessary maintenance. In a production environment this should be hardly ever necessary; during development you might want to consider making the role with LOGIN permission for ease of use.
The owner creates all the schemas, tables, views, functions, etc. that you need for your application. By default, all of those objects are only available to the database owner, with the exception of functions.
Define a number of group role profiles, each having specific requirements of the database. You could have, for instance sales_staff, product_managers, accounting and senior_management for a company, or web_user, web_admin, app_developer and app_manager for a web site. The database owner then GRANTs access to the database (CONNECT), schemas (USAGE), tables, views and functions (EXECUTE), as needed. I usually REVOKE ALL ON FUNCTION x() TO public, for security reasons.
Assign group role membership to user roles, as needed: GRANT sales_staff TO jane. The user roles should have LOGIN INHERIT such that they can log in and inherit the permission of group roles that they are a member of. That includes the permission to connect to a database and usage rights on schemas. Note that a single user role can have membership in multiple group roles.
Lastly, update your pg_hba.conf file to enable remote access to the database.