I have created a Security Policy to implement Row Level Security (RLS) in SQL Server 2016. There is some specific time in a month when the security policy will be applicable. I am planning to write a job which will enable or disable the Security Policy, but I am not getting the SQL command to disable or enable it.
I know that I need to set the check_policy to OFF
CHECK_POLICY = { OFF }
Visually I am able to do it using Sql Server Management Studio by right clicking on the Security Policy.
Won't this work..
ALTER SECURITY POLICY <<your security policy>>
WITH (STATE = OFF);
Using TheGameiswar's answer works I wanted to add that if you get an error saying
Cannot find the object "[security filter name]" because it does not exist or you do not have permissions.
Append [security] before the filter name
For example if your filter name is "ProfilesFilter"
ALTER SECURITY POLICY [security][ProfilesFilter] WITH (STATE=OFF)
This is probably a given for some but I am less fluent with SQL/SQL Server
Related
I'm doing some ETL, using the standard "Pre-Load" partition pattern: Load the data into a dated partition of a loading table, then SWITCH that partition into the live table.
I found these options for the SWITCH command:
ALTER TABLE [myLoadingTable] SWITCH PARTITION #partNum TO [myLiveTable] PARTITION #partNum -- Move the New Data in.
WITH ( WAIT_AT_LOW_PRIORITY ( MAX_DURATION = 1 MINUTES, ABORT_AFTER_WAIT = BLOCKERS ))
Those options seem like valuable things to define (even if they wouldn't be needed during normal operation).
Unfortunately, when I try to run that, I get:
Sql error number: 11423.
Error Message: User does not have permission to use the ABORT_AFTER_WAIT = BLOCKERS option.
Further reading confirms that this is appropriate: (link)
BLOCKERS
Kill all user transactions that currently block the SWITCH or online index rebuild DDL operation so that the operation can continue.
Requires ALTER ANY CONNECTION permission.
But when I try to GRANT the relevant user that permission I get an error:
GRANT ALTER ANY CONNECTION TO [myAdfUser]
Securable class 'server' not supported in this version of SQL Server.
I'm using (AFAIK) a normal Azure SQL Server database.
Is there any work around for this? Or is it just not possible for me to use these options on this Database?
Looks the question was solved by #Larnu's comment, just add it as an answer to close the question.
If you are using Azure SQL Database, then what the error is telling you is true. Azure SQL Databases are what are known as Partially Contained databases; things like their USER objects have their own Password and the LOGIN objects on the server aren't used for connections. The CONNECTION permission is a server level permission, and thus not supported in Azure SQL Databases.
We are in the process of moving a database from on-premise into Azure SQL. The software that will consume this database has a database username and password hard coded, so we are unable to change it. Unfortunately the hard coded password does not meet the password policy for Azure SQL.
I have looked around and found the CHECK_POICY option I can add to the query, however I receive an error telling me that option is not supported in this version of SQL.
Keyword or statement option 'check_policy' is not supported in this version of SQL Server.
I am also unable to find any documentation that specifically says "You cannot change the password policy in Azure SQL" - Does anyone know how I can either disable the password policy, or find documentation stating that we are unable to do so?
Azure sql database doesn't support CHECK_POICY. So you could not set CHECK_POLICY = ON or OFF.
For more details, please see: Syntax for Azure SQL Database and Azure SQL Data Warehouse:
ALTER LOGIN login_name
{
<status_option>
| WITH <set_option> [ ,.. .n ]
}
[;]
<status_option> ::=
ENABLE | DISABLE
<set_option> ::=
PASSWORD ='password'
[
OLD_PASSWORD ='oldpassword'
]
| NAME = login_name
Only local SQL server and Azure SQL managed instance support set CHECK_POLICY.
You also can get this from Password Policy.
SQL Database enforces password complexity. The password expiration and policy enforcement sections do not apply to SQL Database.
Hope this helps.
I've get a fresh install of SQL Server 2012 and do not want to use integrated security. Instead I'd like to use SQL Server authentication, where I create logins in SQL server and assign passwords. However, this option doesn't seem to be available (see screen snapshot below). Every option available to me under "User Type" (other than those that aren't related to accounts at all) want me to map to existing Windows Domain accounts.
In the old days, I'd specify a desired login name and be prompted for a password to go along with it, and I'd be done. Now there's no option to specify a password--I'm forced to map my new login to an existing
windows domain account. Not what I want. What am I missing here? Thanks in advance.
** edit ** New screen snapshots added after RB's comment. I did indeed have an option disabled that would allow BOTH Windows and SQL Server authentication modes, but it's turned on now. After doing so and restarting SQL Server, it is NOT making a difference:
Here is what I am presented with when I try to create a new user. None of these options simply allow me to create a login and password in the context of SQL server (well, one allows creation of a login with no password at all... useless!) All others are linked to existing Windows logins. Ideas?
Let's do this in a way that doesn't require pictures and right-clicking.
CREATE LOGIN [yourUserName] WITH PASSWORD = 'someStrongPassword';
CREATE USER [yourUserName];
Is it possible to pass-through Windows User logins from Datazen through to SQL Server?
Scenario:
I created a Dashboard which uses a SQL Query as a data source.
The data source is of type "SQL Server" and the flag Integrated Security is set to YES.
I've also configured the data source to be "Real Time," to avoid any issues with caching.
I'm expecting the data view to execute on SQL Server with the credentials of the user which is browsing the final dashboard, unfortunately this is not the case.
Problem:
In this scenario the authentication against SQL Server is now done with the Windows user account, under which the Service "Datazen Server Data Acquisition Service" is running. I would expect that the "Acquisition Service" will delegate the effective user. Is this possible? Or will the authentication always be done with the service account?
I know about the "personalize for each member" setting, which passes-through the username to a data view query, but this is not the same as my requirement (leverage existing MSSQL-DB-Security for effective windows-users).
Your observations are correct that by default, the service account will be recognized as being logged into SQL Server.
There's no way to get around that with settings, but you can use some T-SQL magic to switch users at runtime. You have to lead your queries with an EXECUTE AS statement, like so:
EXECUTE AS USER = 'DomainName\' + '{{ username }}'
SELECT TOP 1 login_name -- This is just a nice quick test to echo the username.
FROM sys.dm_exec_sessions -- You can swap it out for your real query.
WHERE session_id = ##SPID
This, of course, also requires the "Personalize for each Member" setting to be turned on, so that the username is passed through.
It's pretty self-explanatory what's going on here, but basically you have to explicitly impersonate the request via your service account, as SQL Server will be connected to via the database using that account. Once you run this EXECUTE AS statement, it will use that user account for the remainder of the session.
Note that your service account will need permission the IMPERSONATE permission set, or else this will fail. It will also fail, of course, for any users that exist in your Datazen Server but do not have permissions against your SQL Server, and vice-versa. That's definitely the desirable behavior, but it's worth keeping in mind if you ever add users to one, you'll also have to add them to the other.
Disclaimer: I'm a Microsoft Support professional, paid to support Datazen.
ALTER LOGIN allows one to change the CHECK_EXPIRATION property associated with an account, but how does one get the existing value of this property for an arbitrary user?
You can get this data through the LOGINPROPERTY() system function:
select loginproperty('your_login_name', 'daysuntilexpiration');
If you want to see if the SQL logins is subject to expiration, just check sys.sql_logins:
select name, is_expiration_checked
from sys.sql_logins;
Note: As per the documentation on CHECK_EXPIRATION, this only applies to SQL logins, not Windows logins. If you need to get this expiration for Windows accounts, then I recommend you create programmatic logic (outside of SQL Server) to grab the login(s) from SQL Server, and then make AD calls to get expiration date. To do this with PowerShell, this seems to be a good blog post on a quick methodology.