I have RLS implemented in Azure SQL2016 DB, and it works fine when using UserID and Password in connection string. However, When I use Token authentication (which works without RLS) instead of u/p, RLS doesn't work.
I get the expected error when inserting:
The attempted operation failed because the target object 'server.dbo.mytable' has a block predicate that conflicts with this operation. If the operation is performed on a view, the block predicate might be enforced on the underlying table. Modify the operation to target only the rows that are allowed by the block predicate.The statement has been terminated
Integrated security still works in my instance if I include an initial catalog with the connection string
<!-- Does not work -->
ConnectionString="Data Source=(localdb)\MSSQLLocalDB;Integrated Security=True;Persist Security Info=False;Pooling=False;MultipleActiveResultSets=False;Connect Timeout=60;Encrypt=False;TrustServerCertificate=True"
<!-- Works -->
ConnectionString="Data Source=(localdb)\MSSQLLocalDB;Integrated Security=True;initial catalog=MyDatabase;Persist Security Info=False;Pooling=False;MultipleActiveResultSets=False;Connect Timeout=60;Encrypt=False;TrustServerCertificate=True"
Related
I want to create a user from JDBC (if possible) in an ORACLE Express database. That user can't have the ORACLE_MAINTAINED flag in the DBA_USERS view.
Trying CREATE USER newuser IDENTIFIED BY xxx, but it throws a ORA-65096: invalid common user or role name. To avoid it, I had to set the flag ALTER SESSION SET "_ORACLE_SCRIPT"=TRUE, as other posts recommend. But that way, it's marked as ORACLE_MAINTAINED.
I'm connecting to the xe default database.
Context:
I'm working with the Oracle Docker image; it's for integration testing purposes. The metadata queries the app uses exclude ORACLE_MAINTAINED='Y' users/tables, and I'm not able to list them (not working with data, just metadata). I could remove the WHERE from the queries, but I would prefer to avoid it, and keep the app queries untouched.
Thanks!
I have a stored proc that uses a synonym to pull data from another SQL Server 2016 database.
This is the connection string that EF is using:
<add name="ConnectionString_CSAdminEF_RO" connectionString="Data Source=myserver;initial catalog=csadmin;user=tcrpAdminTool;password=XXXX;applicationintent=readonly" providerName="System.Data.SqlClient" />
It throws this error:
The OLE DB provider "SQLNCLI11" for linked server "MYSERVER.CORP.COMPANY.COM" does not contain the table "otherserver"."dbo"."mysynonym"". The table either does not exist or the current user does not have permissions on that table.
When I try it in ADO.NET it throws this error:
Procedure usp_get_Data has no parameters and arguments were supplied.
Here is the synonym:
CREATE SYNONYM [dbo].[mysynonym] FOR [OTHERSERVER.CORP.COMPANY.COM].[mydb].[dbo].[eDocsEntity]
The problem only started when I added applicationintent=readonly. This additional parameter works fine when no parameter is involved.
Any ideas as to what could be causing this? I've seen nothing in the forums about it
Thanks
Carl
From our DBA:
I was working on a linked server on primary not realizing that when you read only route to secondary you have to check the secondary servers linked server and in secondary which is a DMS primary they are using a server which did not have read rights to the database referenced by the synonym
I gave it read permissions and that's it
The original owner of the Database has left the company, so I want to change the owner to myself, however, it failed.
When I tried through SSMS: Database properties->Files->Owner, it give the error message like:
Set owner failed for Database XYZ.
An exception occurred while executing a Transact-SQL statement or batch.
Lock request time out period exceeded. (Microsoft SQL Server, Error: 1222)
And when I tried through script with the query:
ALTER AUTHORIZATION ON DATABASE::XYZ TO [MyUserName]
The query seems blocked and run forever without success.
Can anybody give some help?
Queries using dbo-owned objects will acquire a schema stability lock on the existing database owner principal. The ALTER AUTHORIZATION will need a schema modification lock on the same principal, and are thus blocked due to the incompatible lock. You can query sys.dm_tran_locks to identify the blocking sessions.
I created a simple page with HTML/PHP for the sole purpose of getting unsanitized user input.
It is located here: http://109.201.140.29/mssql/
I did this just for fun, I use this windows server for nothing else currently.
Is there any risk when the user ONLY has (readonly) access to the database test_db?
It also logs failed/successful queries, sample of error log (as you can see, drop table does not work):
[2014-07-08 14:27:41] (query) Execution of query: "DROP TABLE users;" Failed.
src IP: <snip>
err: SQLSTATE[42S02]: [Microsoft][SQL Server Native Client 11.0][SQL Server]Cannot drop the table 'users', because it does not exist or you do not have permission.
sample from successful queries log:
[2014-07-08 14:17:38] (query) Executed: "select * from users;".
src IP: <snip>.
Returned rows: 100.
[2014-07-08 14:17:45] (query) Executed: "select ##version;".
src IP: <snip>.
Returned rows: 1.
[2014-07-08 14:19:12] (query) Executed: "SELECT * FROM information_schema.tables".
src IP: <snip>.
Returned rows: 1.
Simple question I suppose; but is there any risk here? Besides the obvious flaw of taking user input as queries..
The user has as I said read-only access and is not a owner of any databases.
I ask because this is my first experience with SQL Server, but from my testing at least the queries seem to only allow reading (SELECT) which is OK for this purpose.
Feel free to test queries of course - as there may be some queries possible that I am not aware of.
Security is built from confidentiality, availability and integrity.
Confidentiality is obviously compromised as you just give any access.
Availability is compromised as Damien showed, and other methods can be also used.
Integrity is the only thing the the "read-only" permissions actually helps to protect, but it is also limited.
Your DB Version is Microsoft SQL Server 2012 - 11.0.2100.60, there are always new exploits that can give total server takeover, and if you give direct access to the DB an attacker can always perform brute force attack to guess and impersonate another stronger user or even admin user (EXECUTE AS LOGIN... for example).
You can never close all of the potential vulnerabilities and you should never allow any direct access to your DB.
I have a SQL Server 2008 R2 implementation with Service Broker turned on for a .Net/IIS website running on the same box.
It doesn't throw an error when the global.asax application_startup event fires, however the event log is spammed every second with:
[dbo].[SqlQueryNotificationStoredProcedure-e6946263-93b8-445e-9d92-6fbd49a4b089]'
running on queue
'XXXXXX.dbo.SqlQueryNotificationService-e6946263-93b8-445e-9d92-6fbd49a4b089'
output the following: 'The database owner SID recorded in the master
database differs from the database owner SID recorded in database
'XXXXXXX'. You should correct this situation by resetting the owner of
database 'XXXXXXX' using the ALTER AUTHORIZATION statement.'
Also, the Service Broker is not correctly sending messages (for a SqlCacheDependency) - it basically doesn't work.
I have run the following query and determined there is an ownership mismatch:
SELECT
SUSER_SNAME(d.owner_sid) AS OwnerName
,d.owner_sid AS OwnerSID
,dp.sid AS DboUserSID
,SUSER_SNAME(dp.sid) AS DboUserMapping
FROM sys.databases AS d
JOIN sys.database_principals AS dp ON
dp.name = 'dbo'
WHERE d.database_id = DB_ID();
OwnerName: usrAAAAA
OwnerSID: 0xAAAAA
DboUserMapping: sa
DboUserSID: 0x01
Most places I have seen suggest that I should use ALTER AUTHORIZATION to explicitly set "sa" as the database owner. However, I am unsure if it should be set to sa or usrAAAAA, and I'm not sure if there are any likely implications (what other things could I break? if any).
Any help on this would be greatly appreciated.
Setting the database owner to 'sa' is the most likley to work without causing other problems, but there can be some security related issues with it as explained here: are there reasons I should not set my db owner to sa?.
Note also that, depending on your application requirements and how the accounts are used, if you remove 'usrAAAAA' as the dbo, you may need to add them back in to the DB as a user, and you may also need to give them permissions (such as 'db_owner'). If this is the case, and you have set your database to TRUSTWORTHY (as is often required by Service Broker related usages), then you should probably set the owner to 'usrAAAAA' instead and try to get that to work.