I'm having some trouble understanding SQL Azure password validation (in local SQL it works, just not CREATE USER command, but CREATE LOGIN command). Anyway this is user creation statement:
This one works:
CREATE USER [test1] WITH PASSWORD = 'testicus2019!'
This one failes with "Msg 40632, Level 16, State 3, Line 6
Password validation failed. The password does not meet policy requirements because it is not complex enough.":
CREATE USER [test_1] WITH PASSWORD = 'testicus2019!'
I understand that passwords must not contain usernames, but this is not the case in any of the statements. Does SQL on Azure break usernames with underscore in it? Where could I find such information?
As mentioned the second case works with local SQL, just using CREATE LOGIN command.
print ##version on Azure SQL returns "12.0.2000.8", if it's relevant.
You mentioned correctly here 'Passwords cannot contain single quotes, or the login_name.'.
So there is a catch in your case.
In the first statement, the username is entire 'test1' which cannot be exactly found in password 'testicus2019!', so it would allow us to create it.
However in 2nd statement, the username is anything before or after underscore. In your case 'test_1' is checked just for 'test' in password 'testicus2019!'.
As another example, if we try creating '[test_demo]' user with any of passwords 'testicus2019!' or 'demoicus2019!', it would not work. However if creating a password like 'password2019!', then it will work.
Related
I am trying to create a database and each time I run the createdb [databasename], and enter the "incorrect" password, command I get the following error, createdb: error: could not connect to database template1: FATAL: password authentication failed for user "[username]".
However, the user that says the authentication has failed for doesn't exist. I can run psql -U postgres and enter the password I provided previously and log in just fine. Once logged in as Postgres user I run \du and only see the Postgres user in the table. Any reason this would be happening? I uninstalled and reinstalled and still have the same issue. Why is the default user something other than the original postgres user?
Here is the result of the \du command
List of roles
Role name | Attributes | Member of
-----------+------------------------------------------------------------+-----------
postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
The error message does not tell you the exact reason why authentication failed on purpose, to give attackers as little information as possible.
The cause of your problem might be that your username contains upper case letters on the operating system, but you created the database user without using double quotes, so that the upper case letters got translated to lower case.
If you want more than guessing, you have to tell us the exact command line and the output from \du.
I guess I had to add the username from my OS because that is what Postgresql defaults to, as well as add a DB with the same name.
We are trying to install a release for our application. The program uses 2 SLQ Accounts: SA and SAA2.
SAA2 should be a standard user which can run some Select Statement. SA is a super admin (Captain Obvious).
However we are stuck in 2 different ways:
1) If we grant sysadmin right to SAA2, our scripts could not run because it refers to to the defined schema implemented in login page of the account. As we understood, since it's associated to sysadmin, the default schema change to dbo.
But, the account can login successfully
If we want to resolve it by this way, we have to implements these workaround :
Force account to use his own default schema
Change our scripts with a full name without using schema (not possible)
Invalid object name ...
2) If we want to use SAA2 as a standard accounts (because script are mainly focus on SELECT), MSSSQL refuse the account to connect. Indeed, if we try to simply login using SQL Credentials, as a sysadmin it works, as a standard user, it wont. (like this https://social.msdn.microsoft.com/Forums/sqlserver/en-US/23952fef-7ad7-4374-b7e9-89476a62adc9/users-unable-to-access-their-database-unless-they-are-given-sysadmin-permission?forum=sqlsecurity)
Error number 18456, Severity 14, State 1
We just want to find a way to execute our query, as a sysadmin or not.
I did create an External Datasource, identical to the guide described here .The process is pretty simple, so just for illustration.
CREATE MASTER KEY ENCRYPTION ...
CREATE DATABASE SCOPED CREDENTIAL ...
Not covered in the article is how to create login and user. On the master database I did execute
CREATE LOGIN <externaldbname> WITH PASSWORD = '<somepassword1>';
CREATE USER externaldbname FOR LOGIN externaldbname;
And on the externaldb
CREATE USER externaldbname FOR LOGIN externaldbname;
Then continued with the guide
CREATE EXTERNAL DATA SOURCE ...
CREATE EXTERNAL TABLE ..
All executed successfully. Now when I try to select something from the external database, this error is raised
Msg 46823, Level 16, State 2, Line 10 Error retrieving data from one
or more shards. The underlying error message received was: Cannot
open database externaldb requested by the login. The login failed.
Login failed for user externaldbname.
I am able to login with the given credential to the externaldb if using Visual Studio. Is there any special permission that needs to be granted or what might be wrong?
Issue resolved. The database name in the external data source definition was not the same (typo) as actual database name.
The credentials you created, do they have read access to the remote database that you are trying to access?
If the permissions are all fine, then can you email me your setup details along with the T-SQL statements you used at SDoomra(at)Microsoft(dot)com?
Thanks
Silvia Doomra
I'm trying to write a script for a web portal (APEX) that allows a user to change their password on the associated database that they select
I'm trying to write a pl/sql procedure that I can execute over a database link to change the password on that database.
I guess what I am asking is can I connect as a different user within a PL/SQL block and run alter user identified by from within that block?
CREATE OR REPLACE PROCEDURE CHPWD
(
Database IN VARCHAR2
, Username IN VARCHAR2
, old_pw IN VARCHAR2
, new_pw IN VARCHAR2
) AS
BEGIN
/* Something like conn Username/old_pw here
then
alter username identified by new_pw */
END CHPWD;
Thanks!
The standard approach would be to have the procedure owned by a highly privileged user who can change any password, grant execute on the procedure to the users who should be able to execute it, and place logic in the procedure to implement security restrictions.
I believe the main issue is authenticating the user's password before changing it. I do not think there is a secure method to do this though - the best way to confirm the password would be to, as in your comment, login to the database with it. That requires passing the password to an external script though which would reveal your plain text password to anyone with access to the system.
The other method would be to take the algorithms that people have used to duplicate Oracle's password hashing algorithm - but this is effectively hacked together and liable to be changed:
http://www.petefinnigan.com/weblog/archives/00001097.htm
Consider this T-SQL:
CREATE USER my_test_user WITHOUT LOGIN;
SELECT USER_NAME(), USER, SUSER_SNAME(),SYSTEM_USER, suser_name();
EXECUTE AS USER = 'my_test_user' WITH NO REVERT;
SELECT USER_NAME(), USER, SUSER_SNAME(),SYSTEM_USER, suser_name();
I'm looking at using these accounts WITHOUT LOGIN for auditing purposes. Basically, my "get a database connection" code returns a connection on which the EXECUTE AS USER...WITH NO REVERT has already been executed.
The problem is that I can't get consistent results from any of these user name functions. The two lines of output are:
dbo dbo original_user original_user original_user
my_test_user my_test_user S-1-9-3-XXXXX.. S-1-9-3-XXXXX.. S-1-9-3-XXXXX..
The USER functions produce correct output AFTER the 'EXECUTE AS', but beforehand they're showing dbo rather than the user name
The SUSER functions are just the opposite -- they're correct initially but after impersonation they're showing some sort of ID
The MSDN docs for SUSER_SNAME explicitly give an example where this is supposed to work.
UPDATE: What I'm looking for is a function that will produce 'original_user' in the first case and 'my_test_user' in the second.
Update: you need the ORIGINAL_LOGIN fn here too
Original:
Afterwards, there is no matching system level user. So, it can't resolve the database level sid, so it simply returns the sid from sys.database_principals
CREATE USER my_test_user WITHOUT LOGIN;
SELECT USER_NAME(), USER, SUSER_SNAME(),SYSTEM_USER, suser_name();
EXECUTE AS USER = 'my_test_user' WITH NO REVERT;
SELECT USER_NAME(), USER, SUSER_SNAME(),SYSTEM_USER, suser_name(),
SUSER_SID();
SELECT * FROM sys.database_principals WHERE sid = SUSER_SID();
I don't know if this is by design, but it explains where the number comes from. The rest is as expected as explained below
Notes:
You'll get dbo for USER_NAME() because you are logged on with sysadmin rights. Everyone with "sysadmin" is dbo when using db level user functions.
After changing user context, db level user functions resolve to the database user context
For system level user functions, you'll get the login you used before
Users without login are a special case used exclusively for service broker security (remote service bindings) or for code signing. They represent identity, not impersonation. Do not use users without login for EXECUTE AS. You'll run into all sort of edge cases because they explicitly don't have a user to login mapping and almost everywhere a mapping is expected.
Just a guess here, but it looks like to me that the first select is being run as the user you're currently logged into as with the connection, and in the second select you are then telling sql server to execute as the newly created user.