I use pg_ident.conf (PostgreSQL 12, OS Windows Server 2019) file to map users for SSPI this way:
# MAPNAME SYSTEM-USERNAME PG-USERNAME
MapForSSPI someone#COMPANY someone
Recently I had to add new user, which I did exactly the same way as usual. I have created role "newsomeone" via pgAdmin, added membership properly, and added user into pg_ident.conf as:
MapForSSPI newsomeone#COMPANY newsomeone
But when this user tried to connect:
FATAL: role "NewSomeone" does not exist
Please be aware of CASE. With further testing I realized the OS login is really set up as NewSomeone#COMPANY, but what I really do not understand is why is this login with capital letters not mapped to my lowercase login "newsomeone". When I've created new role "NewSomeone" via pgAdmin without any change to pg_ident.conf, the connection is successful.
How is it possible that with PG-USERNAME "newsomeone" specified in lowercase in pg_ident.conf it looks for role "NewSomeone" (as in OS login)?
pg_ident.conf is there to allow the system-authenticated user to login as a specific requested database user, when the spelling of the two doesn't match. It is not there to rewrite the requested database user into a different database user.
As long as your client is demanding to login as database user "NewSomeone", either it will succeed as that user, or it will fail as that user. It will not pick a different name to log in as.
You need to fix your client connection code (which you didn't show) so that it attempts to log in with the correct spelling.
Related
I stumbled upon PostgreSQL installations, where there is a PostgreSQL user with the same name as an operating system (Linux) user. If you are logged into the operating system as such a user, you can usually login to psql without specifying a username and password as this user.
How does this work? Is this a pure convention, or is there a special mechanism in PostgreSQL for this kind of behavior?
There are cases, where no corresponding PostgreSQL user is present for an operating system user. In this case, how do I create one, that can be logged into without having to specify username and password once I am logged into the operating system as this user?
There are several mechanisms. I don't know what makes a mechanism a special one, though.
The client always sends a username to the server. If you don't specify one to use then libpq-based clients look up the operating system name and use that. Some non-libpq-based clients might adopt the same convention.
For not requiring a password, maybe local connections are set to 'trust' in pg_hba.conf, in which case anyone else on the same machine can also log in to PostgreSQL as you, just by specifying your username to use, such as with -U martinw. Or maybe a password is required, but it is provided automatically via .pgpass file or via PGPASSWORD env variable, but if you set that up presumably you would remember doing so. Or maybe you have local connections set to peer in pg_hba, in which case the db server asks the OS "who is on the other end of this socket?" and verifies the answer matches the requested username (this is a common default setup, for example on Ubuntu Linux) or if a pg_ident map is in use, then it verifies the response system username is allowed to log in as the specified db username.
https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNECT-PASSFILE
create a pgpass file: vim ~/.pgpass
fill your credentials: hostname:port:database:username:password
exit file. and change ~/.pgpassfile access permission:
https://www.postgresql.org/docs/current/libpq-pgpass.html
chmod 0600 ~/.pgpass
If your linux user is the same as one of the pgpassfile user, then just type psql to connect to database.
Changing the password is easily done through the console. Is there any way to change the master username after creation on RDS for PostgreSQL? If so, how?
You can't change username. You can check the following links that describe how to change master password and if Amazon adds the ability to change username you will find there:
Try to find at AWS CLI for RDS:
modify-db-instance --db-instance-identifier <value> --master-user-password (string)
--master-user-password (string)
The new password for the DB instance master user. Can be any printable
ASCII character except "/", """, or "#".
Changing this parameter does not result in an outage and the change is
asynchronously applied as soon as possible. Between the time of the
request and the completion of the request, the MasterUserPassword
element exists in the PendingModifiedValues element of the operation
response. Default: Uses existing setting
Constraints: Must be 8 to 41 alphanumeric characters (MySQL, MariaDB,
and Amazon Aurora), 8 to 30 alphanumeric characters (Oracle), or 8 to
128 alphanumeric characters (SQL Server).
The Amazon RDS Command Line Interface (CLI) has been deprecated. Instead, use the AWS CLI for RDS.
Via the AWS Management Console, choose the instance you need to reset the password for, click ‘Modify’ then choose a new master password.
If
you don’t want to use the AWS Console, you can use the
rds-modify-db-instance command (as per Amazon’s documentation for RDS)
to reset it directly, given the AWS command line tools:
rds-modify-db-instance instance-name --master-user-password
examplepassword
No. As of April 2019 one cannot reset the 'master username'.
You cannot do it directly. However you can use the database migration service from AWS:
https://aws.amazon.com/dms/
Essentially you define the current database instance as your source and the new database with the correct username as your target of the migration.
This way you migrate the data from one to another database instance. As such you can change all properties including the username.
This approach has some drawbacks:
You need to configure the migration. Which takes a bit of time.
The data is migrated. This may lead unexpected behavior since not everything is eventually migrated (e.g. views etc.)
It depends how you setup everything you may experience a downtime.
Though this may not be ideal for every use-case, I did find a workaround that allows for changing the username of the master user of an AWS RDS DB.
I am using PgAdmin4 with PostgreSQL 14 at the time of writing this answer.
Login with the master user you want to change the name of
Create a new user with the following privileges and membership
Privileges and Membership
Can login - yes
Superuser - no (not possible with a managed AWS RDS DB instance, if you need complete superuser access DO NOT use a managed AWS RDS DB)
Create roles - yes
Create databases - yes
Inherit rights from the parent roles - yes
Can initiate streaming replication and backups - no (again, not possible directly without superuser permission)
Be sure to note the password used, as you will need to access this new account at least 1 time to complete the name change
Register a server with the credentials created in step 2. Disconnect from the server but do NOT remove it! Connect to the new server created
Expand Login/Group Roles and click on the master user whom you are changing the name
Click the edit icon, edit the name, and save.
Right click the server with the master username, select Properties
Update the name under the General tab if desired
Update the username under the Connection tab to whatever you changed the master username above
Save and reconnect to the server with the master user
You have successfully updated the master user's name on a managed AWS RDS DB instance, proud of you!
As #tdubs's answer states, it is possible to change the master username for a Postgres DB instance in AWS RDS. Whether it is advisable – probably not.
Here are the SQL commands you need to issue:
Create a temporary user with the CREATEROLE privilege (while being logged in with the old master user)
CREATE ROLE temp_master PASSWORD '<temporary password>' LOGIN CREATEROLE;
Now connect to the database with the temp_master user
ALTER ROLE "<old_master_username>" RENAME TO "<new_master_username>";
-- NOTICE: MD5 password cleared because of role rename
ALTER ROLE "<new_master_username>" PASSWORD '<new password>';
Now connect to the database with the <new_master_username> user in order to clean up the temporary role
DROP ROLE temp_master;
And you're done!
Warning
AWS RDS does not know that the master username has been changed, so it will keep displaying the old one and assumes that is still the master username.
This means that if you use the AWS CLI or website to update the master password, it will have no effect.
And when connecting to the database with psql you'll see:
WARNING: role "<old_master_username>" does not exist
While running the server, I am unable to view the layers in GeoServer. I checked the Enabled checkbox, and still I am unable to view the map.
If I login once again into GeoServer, the Enabled checkbox is unchecked.
The below error which I got in logs after starting the Apache Tomcat Server:
Caused by: java.lang.RuntimeException: Unable to obtain connection: Cannot create PoolableConnectionFactory (FATAL: password authentication failed for user "postgres")
Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (FATAL: password authentication failed for user "postgres")
Caused by: org.postgresql.util.PSQLException: FATAL: password authentication failed for user "postgres"
ERROR [geotools.jdbc] - There's code using JDBC based datastore and not disposing them. This may lead to temporary loss of database connections. Please make sure all data access code calls DataStore.dispose() before freeing all references to it.
The one thing that can cause this suddenly is password expiration in PostgreSQL, though this is not typical. Most likely the password changed on one of the sides, so check that first.
PostgreSQL allows you to specify that a password expires at a specific timestamp. So you can:
ALTER USER foo WITH PASSWORD 'bar' VALID UNTIL 'tomorrow';
And foo will be able to log in with the password 'bar' until the next day at system time....
So if you can verify that the password did not change on both sides, try this:
ALTER USER foo WITH VALID UNTIL 'infinity';
Of course substitute your real user for foo. This will clear any expiration, or rather move the expiration time indefinitely into the future.
I think this is likely to be that the postgres user is configured to only accept logins from the local machine. You will need to configure it to accept logins from the machine name or ip address you are logining in from or even better create a new user that has only the required permissions to login rather than using the deffault admin postgres user. Even if you are on the same machine using eclipse may be making it look as though you are coming from a different machine depending on your configuration.
Please see here and here about configuring this type of access
I am working on an open source application that has PostgreSQL as its default DBMS. Now when I install it on my system, its configuration is so that PostgreSQL also gets installed with it.
My problem is with getting access to the installed PostgreSQL database. The database that gets created during installation is named iviewdb.
I read at many forums that the default superuser is postgres, but when I try to get access to the database using this username through a command prompt, it prompts me for password that I don't have.
I wanted to know from where in the PostgreSQL installation directory
the default username and password with the port number to access the database is stored. I have even tried changing the pg_hba.conf file, but that creates a problem with the application and it won't start then.
How can I find the password for this database? I am working in a Windows environment.
The password isn't stored in an easily recoverable manner, and if you change the password, the application may not be able to access the database properly. You may find the password in the application settings or documentation, though.
If you decide to risk changing the postgres user's password, stop the application and PostgreSQL service, and then edit pg_hba.conf. Add (or change if it already exists) a line (if it doesn't exist, add it before any other "host...." lines):
host all all 127.0.0.1/32 trust
And restart the PostgreSQL service. That should give you access from localhost, where you could change the postgres user's password, or add yourself another user with the permissions you want. Then set the pg_hba.conf file back the way it was and restart.
I've encountered this similar problem, and I noticed that the default being set for PostgreSQL upon installation in my case is as follows:
username = postgres
password = ' '
I stopped my db using db2stop force. The started did a backup restarted and after that
i cannot connect to db from the a client anymore i get:
using the command
db2 connect to "dbname" using "user"
SQL30082N Security processing failed
with reason "42" ("ROOT CAPABILITY
REQUIRED"). SQLSTATE=08001
password and username are correct. When im on the server connecting using command
db2 connect to "dbname"
or
db2 connect to "dbnmae" user "user"
or
db2 connect to "dbname" user db2inst1
works just fine.
I m really confused. Any help is much appreciated
Thanks.
What i tried so far :
db2 get dbm cfg | grep -i auth GSS
Plugin for Local Authorization
(LOCAL_GSSPLUGIN) = Server
Connection Authentication
(SRVCON_AUTH) = NOT_SPECIFIED
Database manager authentication
(AUTHENTICATION) = SERVER Cataloging
allowed without authority
(CATALOG_NOAUTH) = NO Trusted client
authentication
(TRUST_CLNTAUTH) = CLIENT Bypass
federated authentication
(FED_NOAUTH) = NO
switched to client but did not using
db2 update dbm cfg using
authentication client
Update:
Despite the age of this question, it would be wonderful to have a solid answer to this question. Hi locojay, how did you manage? :-)
I'm having the SQL30082N reason code 24 issue in my Windows PC, and today we experienced the same issue in an AIX server.
I googled for a couple hours and didn't find but one happy answer, related to having users with the same name both in the server and the client.
IMO it does not apply to me, as I'm running into a VBox that´s isolated from the domain (no network).
My case: I installed DB2 as user db2admin, no security. Then I granted DBADM to VIRTUALUSR01 and gave this user a password.
db2 connect to TheBase
works fine. But
db2 connect to TheBase user VIRTUALUSR01 using TheRightPassword
returns SQL30082N with reason code 24.
Using client authentication is generally a Bad Idea(TM). That's because you now rely on machines that you may not control for authentication. If I wanted to subvert your system, I could create a new user locally, say, db2inst1 or VIRTUALUSR01 or Administrator, with a password I know, and then, use that to wreak havoc on the database. If, however, no one in your organisation has root/administrator authority over their own machines, client authentication can be made to work. But all it takes is someone plugging in their own personal laptop, and your database could be at risk.
Instead, check the permissions of the files. If you've installed as root, ~db2inst1/sqllib/security/db2c[hk]pw (assuming instance ID of db2inst1) should be setuid root. If not, run db2iupdt against your instance (./db2iupdt db2inst1) which should fix the permissions.
If you've installed without root authority ("non-root install"), which I doubt, since you seem to have had this working, you would need to read the DB2 documentation on non-root installations and their limitations - I don't use non-root installs myself, so I'm not so familiar with them. However, there should be a set-root script that you can use to enable setuid root which, of course, you have to run as root.
I had the same problem and solved with the following way.
Problem occurs because of /etc/shadow file. If the user's password hash is created with SHA then DB2 cannot authenticate or authorize that user. You need MD5 for hashing that user's password.
If you are using Fedora or RedHat Linux, first change hashing method of passwords with:
# authconfig –-passalgo md5 –-update
Then drop and recreate the user:
# userdel userName
# useradd userName
# passwd userName
If you are using AIX or any other linux distros, authconfig won't work. So instead of passwd userName, issue this command:
# usermod --password `openssl passwd desiredPassword`
After that, your password hash belonging to userName will be generated with MD5.
Now grant user privilege to that user:
# su - db2inst1
(db2inst1)$ db2 connect to databaseName
(db2inst1)$ db2 GRANT DBADM with dataaccess with accessctrl on database to user userName
I hope it works for you too.
Thanks to Honza for his solution
Solutions to specific problem causes described previously in
this message are:
1. Run DB2IUPDT <InstName> to update the instance.
2. Ensure that the username created is valid. Review the DB2
General Naming Rules.
3. Ensure that catalog information is correct.