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.
Related
I'm currently trying to answer a problem that can only be answered by combining the datasets of two different Azure SQL databases (different servers, if that matters).
When using user+password authentication, there was a way to do cross-database queries like this (Azure SQL Database Elastic Queries):
CREATE DATABASE SCOPED CREDENTIAL RemoteCredential WITH
IDENTITY = '<remote database user name>',
SECRET = '<remote database user password>'
CREATE EXTERNAL DATA SOURCE RemoteDatabase WITH (
Location = '<database server URL>',
DATABASE_NAME = '<database name>',
CREDENTIAL = RemoteCredential,
TYPE = RDBMS
)
CREATE EXTERNAL TABLE [dbo].[RemoteTable] (
<Remote table definition>
)
SELECT TOP(1) * FROM [RemoteTable]
That worked very well before but we have since migrated to using only managed-identity logins, and user + password authentication is no longer an option.
I've found below snipped to change the credential for managed identity in the context of accessing Azure Storage Accounts here:
CREATE DATABASE SCOPED CREDENTIAL RemoteCredential
WITH IDENTITY = 'Managed Identity'
But this results in the following error message:
Msg 33047, Level 16, State 5, Line 47
Fail to obtain or decrypt secret for credential 'RemoteCredential'.
I've also tried to provide my personal username or the source database server's name, but with the same result.
Some more details:
Both database servers are part of the same tenant and subscription
I've enabled system-assigned identity on the source database server that I am querying.
I've also created an external source user in the target database for the use with managed identity and granted it the required roles.
My user has the required permissions on both databases.
Access with managed identity from my Management Studio works fine for both databases.
The final solution would have to work with Azure SQL databases in Azure China, but I would be grateful for a solution in Azure Global as well.
My current assumption is that managed identity authentication towards other Azure SQL databases from within a SQL query is not yet supported. But maybe someone else has found a way to make this work.
Have you tried Azure SQL Database elastic query.
Is buggy and slow and it's in preview since 2 years now, but it's the closest thing I could find.
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
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.
Let me describe the problem, my current portal is using AD login and pwd details to authenticate external users. I will have the new portal which will keep logins and pwds in SQL Server in a table. I need to migrate logins/pwds from AD domain to the sql database so external users can use their old password. Is it possible? How should i approach that?
Thank you for any help,
Rafal
Gathering the list of usernames should not be a problem. However SQL Server stores hashed versions of passwords, and presumably Active Directory does this differently. I don't see any solution except to create a bridge application under Active Directory that logs them into SQL Server under a temporary password and let's them assign a new password.
The permissions should be with the databases. Perhaps you've lost the association between the server logins and the database users. See if their SIDs are different. If so you can fix them with
ALTER USER with login =
or
exec sp_change_users_login (check books online for how to use this)
http://technet.microsoft.com/en-us/library/ms174378.aspx
I am trying to give all the permissions to a user in the User Mapping section of a database. But, I am encountering this error:
"Cannot use special principal dbo"
Server roles of the user:
This is happening because the user 'sarin' is the actual owner of the database "dbemployee" - as such, they can only have db_owner, and cannot be assigned any further database roles.
Nor do they need to be. If they're the DB owner, they already have permission to do anything they want to within this database.
(To see the owner of the database, open the properties of the database. The Owner is listed on the general tab).
To change the owner of the database, you can use sp_changedbowner or ALTER AUTHORIZATION (the latter being apparently the preferred way for future development, but since this kind of thing tends to be a one off...)
Fix: Cannot use the special principal ‘sa’. Microsoft SQL Server, Error: 15405
When importing a database in your SQL instance you would find yourself with Cannot use the special principal 'sa'. Microsoft SQL Server, Error: 15405 popping out when setting the sa user as the DBO of the database. To fix this,
Open SQL Management Studio and Click New Query. Type:
USE mydatabase
exec sp_changedbowner 'sa', 'true'
Close the new query and after viewing the security of the sa, you will find that that sa is the DBO of the database. (14444)
Source:
http://www.noelpulis.com/fix-cannot-use-the-special-principal-sa-microsoft-sql-server-error-15405/
This answer doesn't help for SQL databases where SharePoint is connected. db_securityadmin is required for the configuration databases. In order to add db_securityadmin, you will need to change the owner of the database to an administrative account. You can use that account just for dbo roles.