DB2 is our Application DB and we are connecting from our application using the DB2 libraries.
However, we store the credentials in an encrypted format and use that for connecting.
If DB2 has an option to connect using a trusted user (like Informix), we could remove the password stored, though it is encrypted.
Anyone knows, is it possible with DB2?
Any help is much appreciated.
Thanks
You may try the Client authentication method or Kerberos Authentication.
Authentication methods for servers.
Kerberos authentication.
Related
Following the instructions here, I'm having problem connecting to the DB from Azure Data Studio using the token I generate. It connects to the DB successfully, but as soon as I want to run a simple query ( I already gave my user read access there), it gives me this connection error, and I need to connect using the token again and the disconnection happens again randomly after a short while:
FATAL: Cloud SQL IAM user authentication failed for user
"user#company.com" FATAL: pg_hba.conf rejects connection for host
"...", user "user#company.com", database "db-name",
SSL off
I did some search and found there is also a way of logging in with IAM database authentication using the Cloud SQL Auth proxy but the documentation is limited to Postgress command line and not a GUI database tool like Azure Data Studio. Can anyone shed some light on this about what's needed if you want to connect with a GUI tool in this case?
And about changing the pg_hba.conf file, since I work with a cloud SQL instance, I'm not sure how to turn sslmode off on the cloud instance. I checked the connection tab of my instance and SSL encryption wasn't checked there (not sure if that's the same),and I changed the sslmode to disable on my Azure Data Studio for the connection but it won't allow me to connect after this change:
FATAL: pg_hba.conf rejects connection for host "*.*.*.*", user "user#company.com", database "database", SSL off
Help, anyone?
I've found the answer: we can connect using IAM database authentication using the Cloud SQL Auth proxy. The only step after to be done from the GUI DB tool (mine is Azure Data Studio) would be, to connect to the IP (127.0.0.1 in my case)the Cloud SQL Auth proxy listens on(127.0.0.1 is the default) after starting the Cloud SQL Auth proxy using:
./cloud_sql_proxy -instances=<GCPproject:Region:DBname>=tcp:127.0.0.1:5432
I have two databases set up as part of the same Postgresql 9.4 database cluster, and I'm trying to access a table in one of them from the other using a postgres_fdw. I have it all set up and working as a superuser, however when I try to access the foreign table as a normal user, I get the following error:
ERROR: password is required
DETAIL: Non-superuser cannot connect if the server does not request a password.
HINT: Target server's authentication method must be changed.
Now I understand that this is because I have the server set up with trust authentication for certain subnets, including Its own. However, in the 1 USER MAPPING I created, I did specify a password, with the hope that doing so would force it to use password authentication. No such luck apparently.
As such, my question is if there is any way around this somewhat onerous requirement? Is there a way to force this connection, or a specific user, or the like to use password authentication? Or some way to disable the requirement? Or is my only option to change the configuration to require passwords, and deal with whatever that breaks?
As Nick Barnes pointed out in a comment, pg_hba allows different authentication rules for specific users. As such, the solution to this issue was to simply create a user specifically for these FDW connections, and set that user in the pg_hba.conf to require a password. That way my trusted web apps on the trusted network can continue connecting as usual, but the FDW can get the password request it requires.
You can't force FDW to use a password: the server on the other end must request the password. the usual default for local socket connections is no password.
Try connecting via TCP instead of using local sockets: add host=localhost to the connection parameters, that will usually fix it.
Does anyone know in DB2 if you can run any SQL that shows if you are connecting using a kerberos connection ?
The following might work for; it doesn't say explicitly that the connection was authenticated via Kerberos but it implies authentication via Kerberos.
SELECT 1 FROM SYSIBMADM.DBMCFG
WHERE NAME='authentication'
AND VALUE IN('KERBEROS','KRB_SERVER_ENCRYPT') FETCH FIRST ROW ONLY
I have a mongodb running in my server, for local connections to the db I don't need any password to protect it(that is within the same physical machine, meaning connect to the server thru the 127.0.0.1 ip address).
But I don't want other people in the network be able connect to my database without password, only the authorized user. So I want to do password protection for the remote user.
How to do it?
Right now monogdb does not support authentication mode based on the user location. So that means if you run mongod with --auth that will apply to everyone.
There are no (yet) advanced authentication schemas like IP, protocol source, etc. For now you can only define if the user has read only or write permissions on a database. So basically the only thing mongodb cares is if you typed the right password for the right user.
Personally in all production environment I would recommend to use the secure mode, because even if you allow only connection from a localhost any users who has access to the local server or any malicious script on the host can easily wipe all your data.
The MongoDB Security and Authentication page has information on configuring user authentication and firewall settings.
Note that when you enable password authentication for a database, the authentication requirement will apply to both local and remote users (so you will also need to connect with a password through the local IP).
MongoDb does not offer an easy way to protect the database. I assume this is the reason why there are tens of thousands of mongodb instances on the net that are unprotected for hackers
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.