In my SQL MI i have a ad group (called Group A) which was already assigned to the Active Directory Admin through Portal. I'm trying to update/replace that with a new group called Group B.
When I tried I get the error like
{"error":{"code":"ServerPrincipalAlreadyExists","message":"The
requested server principal already exists on Managed Instance.
Consider dropping the server principal and retrying operation."}}.
When I tried to add another new group called Group C it works. But the issue with Group B still exist
Questions:
How come the new group B has been already exists on the MI ?
How to remove the service principal ?
P.S I tried by removing the existing group from the active directory admin and add the new group B still the same issue
You need to check whether group B exists among service_principals and drop it. You can check that by looking at server_principals table https://learn.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-server-principals-transact-sql?view=sql-server-ver15. If it exist you need to drop sp(probably you added it as a login and thus it is server principal).
Related
thank for taking the time to try answer/understand this question.
I am using AWS Aurora Postgres (Engine version: 13.4) database.
I referred to this document for creating readwrite and readonly roles for 2 new rdsiam users -> "dev_ro" and "dev_rw". I have granted readwrite role to "dev_rw" and readonly to "dev_ro". The additional changes are:
myschema is "public" - which is my default schema
I add the same permissions as "myschema" to another schema called "graphile_worker" (from graphile/worker - which is a job queue).
With this in mind, here is what I have done:
I run my application which adds some repeating jobs (jobs schedule itself), implying that the jobs table can never be empty
Connect to RDS using the IAM user (doesn't matter dev_ro or dev_rw)
I run SELECT * FROM graphile_worker.jobs in my IDE (dbeaver - shouldn't matter, I think)
The table shows up empty
Disconnect and Re-connect to RDS using superuser credentials (which are created when server is created)
Run same query as above
See data in the table
I don't know why this is happening.
I double-checked, both "dev_ro/w" (through the roles) and superuser, have:
CONNECT to database (without doubt)
SELECT on all tables of graphile_worker schema
USAGE on the graphile_worker schema
Moreover, I can query graphile_worker.migrations and the migration records show up as expected (on both devro/w and superuser)!
Please let me know if there is any more information that I can provide to help debug this issue.
Removing Row-Level Security (RLS) solved this issue.
Thanks #Hambone for asking the right question.
RLS is removed by executing
ALTER ROLE <username> WITH BYPASSRLS
I'm unsure what I'm missing here, but I cannot connect from Logic App to Azure SQL. Any help is appreciated.
Steps performed:
1. Enabled System Assigned Managed Identity (SAMI) for the Logic App
2. Added the SAMI in a Contributor role for the SQL Server (its in another resource group)
3. Verified the SAMI role by clicking the Azure role assignments button
4. Added the SAMI in both the db_datareader and db_datawriter roles within the SQL Server itself using:
CREATE USER [SAMI Name] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [SAMI Name]
ALTER ROLE db_datawriter ADD MEMBER [SAMI Name]
5. Verified the internal roles were successful with:
SELECT DP1.name AS DatabaseRoleName,
isnull (DP2.name, 'No members') AS DatabaseUserName
FROM sys.database_role_members as DRM
RIGHT OUTER JOIN sys.database_principals as DP1
ON DRM.role_principal_id = DP1.principal_id
LEFT OUTER JOIN sys.database_principals as DP2
ON DRM.member_principal_id = DP2.principal_id
WHERE DP1.type = 'R'
ORDER BY DP1.name;
6. Add the Get Rows (V2) Azure SQL action in the Logic Apps Designer and create the connection
7. I can see that no server is found, so I enter the SQL server name as a custom value
8. After letting the Database Name load for a few mins, the action errors-out with:
Error text:
Could not retrieve values. Error code: 'Unauthorized', Message: 'Credentials are missing or not valid.
inner exception: The credentials provided for the SQL source are invalid. (Source at xxx.database.windows.net.)
clientRequestId: da158fe9-xxx'. More diagnostic information: x-ms-client-request-id is 'B1CBF136-xxx'.
I have allowed Azure Services on the SQL Server, so I don't get why this is happening
I'm not sure of the cause of this, but I found that if you also enter the database name as a custom value then the connection works.
I experienced exactly the same symptoms as you. After manually entering the database name, the list of table names populates automatically.
I also found that it's not necessary to add the SAMI as a contributor to the SQL Server (at least, not for this particular workaround).
Before entering custom database name:
After entering custom database name:
I'm using oracle database 12c. 1 database with two schemas (users) one user is called PROD the second one CREDIT. I'm connected to database, using ojdbc (simple java application) as user PROD when i try to execute SQL query, which selects data from table owned by second user CREDIT.
I'll get error
PL/SQL: ORA-00942
Now when i connect to database using SQL Developer and run this query it works fine.
Select looks like this
SELECT C.USER FROM CREDIT.USERS C
In view "all_objects" I did found this table owned by user CREDIT and user PROD(both users have same structure but different data). Why am I getting this error?
I have created a group in AD called 'Domain\SQL Admins', containing 3 high level employees and 2 generic usernames (with very strong passwords). This group has been added to the various SQL servers and given god rights.
My question - Is there a way to downgrade one of the generic usernames to read only on one particular server?
Example:
Desired results - within in this 'Domain\SQL Admins' group:
Domain\JDoe (sysadmin)
Domain\JSmith (sysadmin)
Domain\DJones (sysadmin)
Domain\ServerUser (sysadmin)
Domain\JobRunner (read only)
I am thinking i may need to remove the read only user and create a new group / add this user specifically to each server in question.
Thanks.
SQL 2008 R2
Since you have used AD Groups to create logins and give permission/ assigned roles. If a user is a member of a group and he/she will have all permissions/Roles assigned to that group. Even if you create a separate login for that user and take away permissions on that individual login level, that user will still have permissions since he/she is member of a group who has all the permission.
You will need to remove that user from the AD group. Create another group for read-only permission or use that user's account to create a login an give read-only permission to that user.
I have a web application running with a SQL server 2005 DB as back end.I took the db back of the production site and restored in my development machine.Then i tried to query this database using the login "sa".When trying to execute the "select * from Customers" query, i am getting a message like "Invalid object name 'Customers"
But when i run "SELECT * FROM [352974_mg4l1].[Customers]", It is returning records.
352974_mg4l1 is a user for this database present when i restored the db backup from production.
What i have to do for getting the records using with simple select query which i used initially("select * from Customers" ). I know it is something related to login issue.Can any one tell me how to solve this ?
The Customers database object is not owned by the dbo schema.
And by referencing Customers as 'sa' you are looking for [dbo].[Customers] ?
I would suggest to:
either provide the object's full name
either change it's schema
Edit:
To alter the schema of said table try this:
ALTER SCHEMA dbo TRANSFER [352974_mg4l1].Customers;
Reference: http://msdn.microsoft.com/en-us/library/ms173423.aspx
Look up sp_changeobjectowner in Books on line. That will help you change the owner. The real question is how the object got created to a specific owner to begin with. If this is true on prod, you could have some major issues with other people accesssing the database.