I am installing geoportal 1.2.4 on CentOS from the command line terminal...during my installation I am receiving a fatal ident error message for my user geoportal. The pg_hba.conf file has been altered to follow my credentials accordingly, yet I am consistently receivng this error for both the default user postgres and my created user geoportal.
I have created a geoportal db with geoportal user with a password. Trust and md5 authentication methods have been explored in this configuration. I have also installed the ident server, with no avail.
I am able to connect to the geoportal db as postgres user. Below is a screen shot of the error which is returned for both the postgres and geoportal user.....
A look at the PostgreSQL user manual would be well advised here, particularly pg_hba.conf and the rest of the client authentication chapter.
You're trying to use ident authentication but the user ID doesn't match or the ident daemon isn't running.
You probably want md5 password authentication instead.
Related
I have been using Postgres 12 with MD5 as authentication method and have not faced any issues when trying to connect to a database with password. Nor have I faced issues with user authentication when supplying user password.
However, since I have installed Postgres 13 , I have been blocked by this error client password must be a string. This is a fresh installation of Postgres. Please note that there are solutions which talk about how to migrate from MD5 authentication to scram-sha-256 by making changes to postgresql.conf and pg_hba.conf files. But none of them speak about this issue for a fresh installation of Postgres 13.
What should I be looking for to get rid of this error?
Today I set up pgpool-II on one of my company servers for database replication purposes and I'm trying to connect to it from my application located on another server. Previously it connected to database on the same server where pgpool is now installed without problems - I just needed to provide something like this link in config file:
database: postgresql://user:password#host:port/db_name
I have changed port to the one on which pgpool listens for connections and provided user and password from pcp.conf, but then I get a list of errors after starting app, all of them of the same type:
OperationalError: (OperationalError) unable to open database file None None
Doesn't matter if I'm authenticating as postgresql or pgpool user and if I provide md5 encrypted or plaintext password, errors are the same. How can I properly connect to my database then?
Problem solved days ago, needed to change administrative database in pgpool config from "template1" to "postgres". IDK why it doesn't default to that.
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 am trying to setup PostgreSQL and allow only certain Windows users to access the data from the database. Setting up Windows Authentication is Quite easy with MS SQL, but I can't figure out how to set it up in PostgreSQL.
I have gone through the documentation at http://www.postgresql.org/docs/current/static/auth-methods.html
and edited the pg_hba file. But after doing so, the PostgreSQL service fails to start.
Is the Postgresql server running on Windows as well as the clients then you might test with this to see if this works:
host all all 0.0.0.0/0 sspi
Magnus Hagander, a Postgresql developer, elaborates on this:
"All users connecting from the local machine, your domain, or a trusted domain will be automatically authenticated using the SSPI configured authentication (you can enable/disable things like NTLMv2 or LM using Group Policy - it's a Windows configuration, not a PostgreSQL one). You still need to create the login role in PostgreSQL, but that's it. Note that the domain is not verified at all, only the username. So the user Administrator in your primary and a trusted domain will be considered the same user if they try to connect to PostgreSQL. Note that this method is not compatible with Unix clients."
If you mix Unix-Windows then you have to resort to kerberos using GSSAPI which means you have to do some configuration. This article on deploying Pg in Windows environments may perhaps lead you in the right path.
If anyone else encouters this like I did so starting from 9.5 you wil need to add an optional parameter both to the ipv4 and ipv6 in order for this to work
include_realm=0
so the whole thing will look like
host all your_username 127.0.0.1/32 sspi include_realm=0
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.