I'm looking for a way to create a user with password for PostgreSQL >= 8.4 using SQL statement, but the password must match the windows password policy.
At MSSQL I can create a LOGIN and set CHECK_POLICY=ON
CREATE LOGIN [xy] WITH PASSWORD='pass', DEFAULT_DATABASE=[mydb], CHECK_POLICY=ON
and later create the user for this login.
Is there something similar for PostgreSQL? I have to support all versions beginning at 8.4.
Thank you
There is a module for that:
http://www.postgresql.org/docs/9.3/static/passwordcheck.html
Think this works since Version 9.0.
Related
I am trying to create a contained user for just one database in Azure SQL Server,
I have tried using the sp_configure keyword, it says it is not available in the version of the SQL Server I am using.
Also, I used the Alter database statement, I got the error below:
ALTER DATABASE statement failed; this functionality is not available
in the current edition of SQL Server.
Please, how can I solve this problem???
You do not need to run the ALTER DATABASE ... SET CONTAINMENT command on Azure SQL DBs to accept contained users - it is already enabled by default. You simply need to create the user with just a login and password. A simple example of a contained user with password:
CREATE USER yourUser WITH PASSWORD = 'yourPassword';
See the official documentation for more examples:
https://learn.microsoft.com/en-us/sql/t-sql/statements/create-user-transact-sql?view=sql-server-ver15#e-creating-a-contained-database-user-with-password
https://learn.microsoft.com/en-us/sql/t-sql/statements/create-user-transact-sql?view=sql-server-ver15#f-creating-a-contained-database-user-for-a-domain-login
sp_configure is not supported in Azure SQL database, even use the Alter database:
In Azure SQL database, login is used to login the Azure SQL server, user is to connect to the database. User is database level, and login is server level.
Create login in master DB(( Login must be created in master DB)):
CREATE LOGIN AbolrousHazem
WITH PASSWORD = '340$Uuxwp7Mcxo7Khy';
Then we can create user in user DB( create the database contained user in user DB):
CREATE USER AbolrousHazem FOR LOGIN AbolrousHazem;
GO
For more details, please ref: https://learn.microsoft.com/en-us/azure/azure-sql/database/logins-create-manage
I use different username & password to connect SQL database & log in windows. I'm using trigger to track database insert, Update & Delete. For this purpose I use SUSER_NAME. Its show SQL login name. I want to get windows login name instead of SQL login name.
Use SUSER_NAME() or SUSER_SNAME()
If neither of these are returning your AD account you logged in via, check you are using AD trusted connections and not SQL auth.
https://learn.microsoft.com/en-us/sql/t-sql/functions/suser-sname-transact-sql?view=sql-server-2017
I want to reference app_user in query
(where username=(:APP_USER))
Now my query returns null values, I guess it's happening because my username col is varchar2. How to reference app_user in this situation?
you can use below:
where username=v('APP_USER')
Edit1:
for performance constraints, it is always recommended that you do it like this:
where username=(select v('APP_USER') from dual)
:APP_USER value depends upon the authentication model set in your application. If application is running using database authentication then the value of the user is the same as the database pseudo column USER. If the application uses an authentication scheme that requires the user to authenticate, the value of APP_USER is set by the authentication scheme, usually to the user name used during authentication.
Reference : Oracle documentation
apex make username uppercase try (where UPPER(username)=(:APP_USER))
I wrote an installation script to change the root password with this SQL command:
UPDATE user SET password='*C563415623144561...' WHERE user='root';
This doesn't work on Mysql 5.7:
http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-6.html#mysqld-5-7-6-account-management
My question is: how to change this command with another one compatible with 5.6 and 5.7 version of Mysql? I would like to update the password with a hashed string and not with a clear password.
This is no more password field in the user table as of mysql 5.7. It's now called authentication_string. You can change or set the password like this:
set password for 'jeff'#'localhost' = PASSWORD('mypass'); // this automatically hashes the password
If you you want to use your query , just change password to authentication_string,and it will work.
UPDATE user SET authentication_string='*C563415623144561...' WHERE user='root#localhost';
Hope this help.
I've used this command to reset to empty password in Mysql 5.7.22
ALTER USER 'root'#'localhost' IDENTIFIED WITH mysql_native_password BY '';
Given that 'SET PASSWORD FOR = PASSWORD('')' is deprecated as on mysql 5.7. If not done correctly you could even end up with below error in syslog.
The plugin 'auth_socket' used to authenticate user 'root'#'localhost' is not loaded. Nobody can currently login using this account.
I suggest to use below command.
ALTER USER 'root'#'localhost' IDENTIFIED WITH mysql_native_password BY 'mypass';
https://www.percona.com/blog/2016/03/16/change-user-password-in-mysql-5-7-with-plugin-auth_socket/
On Ubuntu 19.10 with mysqld version 8.0.19, none of the above worked for me. The instructions given here https://linuxconfig.org/how-to-reset-root-mysql-mariadb-password-on-ubuntu-20-04-focal-fossa-linux worked. It's for MariaDB, but it's the same if don't use MariaDB. The two key points are : the function password() is removed in mysqld 8.0+ and, for some reason, the unix socket for mysqld is not created with the --skip-grant-tables options. So, you must use these modified instructions:
$ sudo systemctl stop mysql
$ sudo mkdir -p /var/run/mysqld
$ sudo chown mysql:mysql /var/run/mysqld
$ sudo /usr/sbin/mysqld --skip-grant-tables --skip-networking &
Check that the daemon mysqld is running:
$ ps aux | grep mysqld
If it is running, then start mysql and change the password
$ mysql -u root
> FLUSH PRIVILEGES;
> USE mysql;
> ALTER USER 'root'#'localhost' IDENTIFIED BY 'N3w_p#ssw0rD.';
> quit
Important: before you (re)start mysqld, you need to kill the current process. Just stopping it the normal way does not work.
$ sudo pkill mysqld
$ sudo systemctl start mysql
Then you can test:
$ mysql -u root --password='N3w_p#ssw0rD.'
First of all look your specified mysql version security policies.
show variables like '%validate_password%';
you can change this policy if you like with
set variable_name=new_value;
Changing appropriate user password.
MySQL 5.7.5 and earlier version:
SET PASSWORD FOR 'user_name' = PASSWORD('new_password');
MySQL 5.7.6 and later version:
alter user 'user_name' identified by 'new_password';
For Server version: 5.7.25 - MySQL Community Server (GPL). Use below query as password is no more valid and replaced by authentication_string
UPDATE user SET authentication_string = PASSWORD('yourpassword'), password_last_changed = NULL
WHERE user.Host = 'localhost' AND user.User = 'username';
I'm no MySQL authority, but based on MySQL's current 5.7 documentation, the suggestions in the currently accepted and most upvoted answer strike me as inadvisable. (This is likely due to the passage of time -- the question and #mdamia's answer were both posted in 2015.)
The MySQL 5.7.6 (2015-03-09, Milestone 16) release notes linked by #Tobia's question say "ALTER USER is now the preferred statement for assigning passwords."
The question did ask if a single command could be used for both MySQL 5.6 and 5.7, but given that the ALTER USER syntax implemented by MySQL >= 5.7.6 offers a security enhancement, I would use the newer syntax when it is available. If I still had to operate a MySQL < 5.7.6 installation, I would limit my use of older and deprecated/discouraged password-updating syntax to those circumstances.
The ALTER USER statements suggested by #Carlos Alberto García Guardia and #Venkat Kotra in their answers thus seem to me like the right syntax to use for MySQL >= 5.7.6. Two examples (adapted from their answers and the ALTER USER documentation for MySQL 5.7): :
ALTER USER '<username>'#'localhost'
IDENTIFIED BY '<new_cleartext_password>';
ALTER USER '<username>'#'localhost'
IDENTIFIED WITH <auth_plugin>
BY '<new_cleartext_password>';
The second example above contains an optional WITH clause to specify an authentication plugin. The plugin specified gets written to the "plugin" field of the mysql.user table. For background on the history and future of MySQL authentication plugins, I found these MySQL Server Team blog posts helpful:
"Protecting MySQL Passwords With the sha256_password Plugin"
"New Default Authentication Plugin: caching_sha2_password"
In answer to #Tobia's question how to pass the new password to MySQL in hashed format rather than cleartext, the MySQL ALTER USER documentation indicates that this is done by using AS in place of BY in the ALTER USER statement:
ALTER USER '<username>'#'localhost'
IDENTIFIED WITH <auth_plugin>
AS '<new_hashed_password_value>';
When using AS instead of BY, the ALTER USER documentation says, the password string "is assumed to be already in the format the authentication plugin requires, and is stored as is in the mysql.user table." If a plugin requires a hashed value, "the value must be hashed in a format appropriate for the plugin. Otherwise, the value is not usable by the plugin and correct authentication of client connections will not occur." Id.
The currently accepted answer suggests using either a SET PASSWORD ... PASSWORD() statement or an UPDATE statement (the former for passing the new password in cleartext and the latter for passing it in hashed format):
SET PASSWORD
FOR '<username>'#'localhost' =
PASSWORD('<mypass_in_cleartext>');
or
UPDATE mysql.user
SET authentication_string='<mypass_as_hash>'
WHERE User='<username>';
These statements are deprecated and/or discouraged in relation to the currently preferred ALTER USER statement.
SET PASSWORD ... = PASSWORD(<cleartext>) "is deprecated as of MySQL 5.7.6 and will be removed in a future MySQL release", according to the SET PASSWORD documentation.
The SET PASSWORD ... = 'auth_string' syntax (i.e., leaving out the PASSWORD(str) encryption function) "is not deprecated, but ALTER USER is the preferred statement for account alterations, including assigning passwords." Id. See also Removal and Deprecation in MySQL 5.7:
We have deprecated the SET PASSWORD syntax and the PASSWORD() function. The existing ALTER USER statement is modified to cover the deprecated functionality. The PASSWORD() function was originally introduced as a way to manually update the mysql.user table. This is generally a bad idea and we want to leave the task of managing user authentication properties exclusively to using the ALTER USER statement which automatically determines which authentication plugin should be used and then adjusts the password algorithm accordingly.
As described by the manual, it also appears that UPDATE is less secure than ALTER PASSWORD with respect to logging. The manual indicates that UPDATE statements are written to logs as is, becoming visible to anyone with read access to the logs.[1] In contrast, the manual indicates, when MySQL writes ALTER USER ... IDENTIFIED BY ... statements (and also SET PASSWORD statements) to logs, it rewrites the contained passwords so they do "not appear literally".[1]
At least in most circumstances. The documentation for SET PASSWORD and ALTER USER warns that these statements too can be logged with visible passwords "under some circumstances",[2] although presumably not in all circumstances as apparently is the case with UPDATE.
1: See MySQL 5.7 manual on password logging ("In particular, INSERT or UPDATE statements for the mysql.user system table that refer to literal passwords are logged as is, so you should avoid such statements. (Direct modification of grant tables is discouraged, anyway.)")
2: See MySQL 5.7 SET PASSWORD documentation and MySQL 5.7 ALTER USER documentation
Disclaimer: I'm just sharing my interpretation upon reading the MySQL manual today. I haven't tested MySQL's behavior with respect to what password-altering statements it logs where in what format.
This is the only way to me in: mysql Ver 14.14 Distrib 5.7.30
UPDATE user SET authentication_string = PASSWORD('YourPassword'), password_last_changed = NULL
WHERE user.Host = 'localhost' AND user.User = 'YourUsername';
First of all, I use:
Windows 7 x64
Oracle Enterprise 11g R2 x32
I have some basic experience with SQL Server and MySQL (more with MySQL). Today I started working with Oracle, and I've been bumping a lot on the way.
The problem I'm having now is that, for some reason, I can't connect to any sys user (sysdba or sysoper). Probably I made a mistake writing the password when creating the database, but I'm not sure, so I'm trying to change it.
I've been trying, as some searches had led me to try, to use
sqlplus /nolog
connect / as sysdba
alter user sys identified by new_pass;
And it seems to work. I mean, it says "User altered". However, I still can't log in sqlplus with the new password. It's a little weird, since I can connect to "sysman" with my original password, but it doesn't have the privileges I need.
I'd appreciate any help I could get, and I thank you beforehand.
After you log in with 'sqlplus / as sysdba', try changing the password for system by issuing
ALTER USER system IDENTIFIED BY abcdef;
Then, to make sure, without quitting sqlplus:
CONN system/abcdef
That should work. After that, you can log on with system/abcdef when you start sqlplus.
The ORA-01994 error happens when you forget to use the orapwd command, and it critical to note that the name of the file must be orapwsid, and you must supply the full path name when using the orapwd command. 'orapwsid' sid is case sensitive.
A No Root password installation's the default. Now you were logged in as root#'%', but a bug exists. Compare how two SQL statements react:
ALTER USER CURRENT_USER() IDENTIFIED BY 'mariadb';
Always outputs mysql_native_password | |
alter user root#'%' identified by 'mariadb';
Job works and the root's identified by new password.
mysql_native_password | *54958E764C
I faced same problem in my server and I resolved them by following solution.
steps of solution.
1) change sys password from database connect with /as sysdba
2) down application and database and restart both 1 database 2 application
3) start listener and database then application.
now both are working fine.