I am following this guide to make remote JMS listener, it works fine.
I need to use the hashed password value in the pooled-connection-factory.
But I don't want to use the plain password in the password param, I tried with hashed password value it is not allowing to connect.
Is there any way to use the management user encrypted password ?
Exception:
org.jboss.resteasy.spi.UnhandledException:
javax.jms.JMSSecurityException: AMQ229031: Unable to validate user
from /127.0.0.1:61662. Username: testuser; SSL certificate subject DN:
Code:
<pooled-connection-factory name="remote-artemis" entries="java:/jms/remoteCF" connectors="remote-artemis" user="testuser" password="16b322f4cfe1023d67ecc13d626cb32c"/>
If you are using elytron you can use:
https://wildfly-security.github.io/wildfly-elytron/blog/wildfly-encrypted-expressions/
For older WildFly there is the vault, which is removed now:
https://subscription.packtpub.com/book/networking-and-servers/9781784392413/11/ch11lvl1sec97/securing-and-protecting-passwords-using-a-vault
Related
Below is my pg_hba.conf entry.
host dbname username 0.0.0.0/0 radius radiusserver=xyz radiussecret=xyz
My understanding here is that when client is trying to establish connection to postgres, the password is sent to postgres which in turns passes it to radius to perform authentication. Once okayed from Radius, the connection will be established. Please correct me if this is not right.
Now when the password is sent to db, will it be unencrypted? I think so.
When password is sent to Radius, is it encrypted?
If I covert host entry to hostssl, then when the client sends the password it would be encrypted correct?
Yes, the password is plain text to the PostgreSQL server, provided the connection itself is unencrypted.
Yes, apparently it is encrypted/hashed between the PostgreSQL server and the radius server, but apparently just with a md5 hash, so not the greatest. There might be additional ways to protect it, but I think that would be a radius question, not a postgresql question.
Yes, ssl will protect it between the client and PostgreSQL, but using hostssl in pg_hba is the wrong way to do it if you are worried about sending the plain-text password to a compromised server. The person who compromised the server will just change "hostssl" back to "host", if they are any good. Instead, you want to enforce this on the client end, with PGSSLMODE=verify-full or the equivalent. (Actually they don't need to turn ssl off, as it will be encrypted for them to decrypt anyway)
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.
Getting the following error while trying to set the new password:
Current password must be provided and be valid when setting a new password.
Since it asks for old password too, I am providing the Bluemix password as the old password. Unable to find a was to set the password in the first place.
You can find the current password in the service credentials section in Bluemix. E.g.
Attribution: http://support.datascientistworkbench.com/knowledgebase/articles/826020-getting-credentials-to-access-a-dashdb-db2-wareho
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.
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