During migration to wildfly 26 in order to encrypt dbpassword of datasource I must use Elytron instead of Picketbox.
what is the best way to show database password encrypted in standalone.xml?
is it possible to get it working only by using elytron.bat?
a working example appreciated!
The Problem was because of a bug in elytron.bat in Wildfly 26.0.0 (JBEAP-23015)
By using Wildlfy 25.0.1.Final Version it was possible to create a credentialstore and add a password credential in a batch file.
elytron-tool.bat credential-store --create --
location="%appserver_home%/standalone/data/mycredstore.cs" --password StorePass
elytron-tool.bat credential-store --
location="%appserver_home%/standalone/data/mycredstore.cs" --password StorePass
--add=database-pw --secret=myDBPassword
To refer this credential store in standalone.xml
<credential-stores>
<credential-store name="mycredstore" relative-to="jboss.server.data.dir"
path="mycredstore.cs" create="true">
<credential-reference clear-text="StorePass"/>
</credential-store>
</credential-stores>
Related
I am attempting to upgrade EJBCA.
I attempted to run this on ubuntu 20.04, locally, using wildfly 18. Wildfly 18 results in this error: "CAUSE: Client certificate or OAuth bearer token required."
I have tried this two ways, by importing the keystore, truststore and superadmin from another instance and by creating the CA fresh and using the resulting superadmin.p12.
The home page loads, but the administration gives me the following error:
"AUTHORIZATIONDENIED
CAUSE: Client certificate or OAuth bearer token required. "
I can really use some help with this.
Things I have tried:
(1) I have downloaded superadmin.p12 and imported it into my browsers
(2) I have attempted to upload the superdmin cert:
bin/ejbca.sh ca importcacert ${NAME} ${NAME}.cacert.pem -initauthorization -superadmincn SuperAdmin
This results in The CA certificate is already imported.
(3) Both my keystore.jks and truststore.jks are moved into /ejbca/p12 and /opt/wildfly/standalone/configuration/keystore
(4) I did set "web.reqcertindb=false"
(6) I did try to enable ssl on wildfly 14 (https://docs.bitnami.com/bch/infrastructure/wildfly/administration/enable-ssl-wildfly/)
(7) I have tried a fresh Management_CA as well
The log of /ejbca/adminweb:
"08:20:01,270 ERROR [org.ejbca.ui.web.admin.configuration.EjbcaJSFHelperImpl] (default task-4) org.cesecore.authentication.AuthenticationFailedException: Client certificate or OAuth bearer token required.
08:20:01,279 WARN [org.ejbca.ui.web.admin.configuration.EjbcaWebBeanImpl] (default task-4) Language was not initialized for this session
08:20:01,279 WARN [org.ejbca.ui.web.admin.configuration.EjbcaWebBeanImpl]
I can provide more information if needs be.
Thank you
So, I have it running today. Here is what I learned:
It seems that if you set wildfly up as a service (per instructions) it is going to set up wildfly to run with launch.sh. Launch.sh is going to result in a cipher mistmatch. I needed to run the standalone.sh file instead
Adminweb must be contacted on 8443
if you need to run this thing on domain setup your going to need to post another question
Best,
I was able to configure mbsync and mu4e in order to use my gmail account (so far everything works fine). I am now in the process of using mu4e-context to control multiple accounts.
I cannot retrieve emails from my openmailbox account whereas I receive this error
Reading configuration file .mbsyncrc
Channel ombx
Opening master ombx-remote...
Resolving imap.ombx.io... ok
Connecting to imap.ombx.io (*.*.10*.16*:*9*)...
Opening slave ombx-local...
Connection is now encrypted
Logging in...
IMAP command 'LOGIN <user> <pass>' returned an error: NO [AUTHENTICATIONFAILED] Authentication failed.
In other posts I've seen people suggesting AuthMechs Login or PLAIN but mbsync doesn't recognizes the command. Here is my .mbsyncrc file
IMAPAccount openmailbox
Host imap.ombx.io
User user#openmailbox.org
UseIMAPS yes
# AuthMechs LOGIN
RequireSSl yes
PassCmd "echo ${PASSWORD:-$(gpg2 --no-tty -qd ~/.authinfo.gpg | sed -n 's,^machine imap.ombx.io .*password \\([^ ]*\\).*,\\1,p')}"
IMAPStore ombx-remote
Account openmailbox
MaildirStore ombx-local
Path ~/Mail/user#openmailbox.org/
Inbox ~/Mail/user#openmailbox.org/Inbox/
Channel ombx
Master :ombx-remote:
Slave :ombx-local:
# Exclude everything under the internal [Gmail] folder, except the interesting folders
Patterns *
Create Slave
Expunge Both
Sync All
SyncState *
I am using Linux Mint and my isync is version 1.1.2
Thanks in advance for any help
EDIT: I have run a debug option and I have upgraded isync to version 1.2.1
This is what the debug returned:
Reading configuration file .mbsyncrc
Channel ombx
Opening master store ombx-remote...
Resolving imap.ombx.io... ok
Connecting to imap.ombx.io (*.*.10*.16*:*9*)...
Opening slave store ombx-local...
pattern '*' (effective '*'): Path, no INBOX
got mailbox list from slave:
Connection is now encrypted
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=LOGIN] Openmailbox is ready to
handle your requests.
Logging in...
Authenticating with SASL mechanism PLAIN...
>>> 1 AUTHENTICATE PLAIN <authdata>
1 NO [AUTHENTICATIONFAILED] Authentication failed.
IMAP command 'AUTHENTICATE PLAIN <authdata>' returned an error: NO [AUTHENTICATIONFAILED] Authentication failed.
My .msyncrc file now contains these options instead
SSLType IMAPS
SSLVersions TLSv1.2
AuthMechs PLAIN
At the end, the solution was to use the correct password. Since openmailbox uses an application password for third-party e-mail clients I was using the wrong (original) password instead of the application password.
I am using a Tomcat 7.0.52 server and using a hashed password in the tomcat-users.xml.
My server is accepting logins using the plain-text password and hashed password both.
How do I prevent / block users from logging in using the hashed password and force them to use the plaintext password?
Snippet of the following files
web.xml :
<login-config>
<auth-method>DIGEST</auth-method>
<realm-name>testvalue</realm-name>
</login-config>
server.xml
<Realm className="org.apache.catalina.realm.MemoryRealm" digest="SHA"/>
tomcat-users.xml
<user username="testuser" password="xxxx--------------yyyy" roles="testrole"/>
I know this isn't strictly the answer to what you asked but I would recommend upgrading tomcat to at least the latest version of 8.0 (8.0.48 at the time of posting). It's been a while since I made the upgrade from 7 to 8 but if memory serves it was pretty painless. This link should have everything you need to know about migrating up. Only thing that comes to mind that you'll really need to look out for is it requires java 7 or higher and even that shouldn't be a big issue unless you have a particularly particular setup going.
Tomcat 8.0.x Instructions Below
This is how I have mine set up and I cannot login by pasting my hashed password into the password field. I opted for sha-512 and arbitrarily picked 512 for my salt-length as well. You don't have to but why not?
Tomcat 8 - server.xml
<Realm className="org.apache.catalina.realm.LockOutRealm">
<!-- Tomcat comment stuff trimmed out here -->
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase">
<CredentialHandler className="org.apache.catalina.realm.MessageDigestCredentialHandler" algorithm="sha-512" saltLength="512" />
</Realm>
</Realm>
Tomcat 8 - tomcat-users.xml:
<role rolename="yourrolehere"/>
<user username="yourusername" password="yourhashedpasswordhere" roles="yourrolehere"/>
I'm sure you already know how to use digest.bat (or digest.sh if that's your thing) but for anyone else tuning in open a command prompt and navigate to your tomcat installation and into the bin directory. Then enter the following:
digest -a sha-512 -s 512 youRcl3artextpa$sword
This will produce a very long password hash in the format of:
youRcl3artextpa$sword:hashedpasswordforalongtime
Copy everything after the semi-colon and make sure it has no line breaks. (clean it up in notepad if you need to)
That's your new hashed password.
Tomcat 8 Digested Passwords Documentation
My setup consists of
Documentum Content Server 7.3 (dctm-cs) running in a docker container (from EMC)
Documentum REST Services 7.3 (dctm-rest) running in a docker container (from EMC)
I am definitively able to get information from within dctm by running queries against it with iapi, for example:
API> ?,c,select user_name from dm_user enable (return_top 5)
user_name
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
docu
ubuntudb
dm_superusers
dm_superusers_dynamic
dm_browse_all
(5 rows affected)
I am also able to $ curl http://localhost:8080/dctm-rest/repositories.json from both the dctm-rest container as well as its host container and get the results:
{"id":"http://localhost:8080/dctm-rest/repositories","title":"Repositories","author":[{"name":"EMC Documentum"}],"updated":"2017-08-16T21:42:44.177+00:00","page":1,"items-per-page":1000,"total":1,"links":[{"rel":"self","href":"http://localhost:8080/dctm-rest/repositories.json"}],"entries":[{"id":"http://localhost:8080/dctm-rest/repositories/ubuntudb","title":"ubuntudb","summary":"ubuntudb","updated":"2017-08-16T21:42:44.178+00:00","published":"2017-08-16T21:42:44.178+00:00","links":[{"rel":"edit","href":"http://localhost:8080/dctm-rest/repositories/ubuntudb.json"}],"content":{"type":"application/json","src":"http://localhost:8080/dctm-rest/repositories/ubuntudb.json"}}]}
Attempting to $ curl http://localhost:8080/dctm-rest/repositories/ubuntudb.json, however hangs indefinitely.
I have attempted to provide the default username and password via basic HTTP authentication, also with the same results.
The contents of the dfc.properties file in dctm-cs:
dfc.data.dir=/opt/dctm
dfc.tokenstorage.dir=/opt/dctm/apptoken
dfc.tokenstorage.enable=false
dfc.docbroker.host[0]=ubuntustateless
dfc.docbroker.port[0]=1489
dfc.crypto.repository=ubuntudb
dfc.session.secure_connect_default=try_secure_first
dfc.globalregistry.repository=ubuntudb
dfc.globalregistry.username=dm_bof_registry
dfc.globalregistry.password=AAAAEL9wp8c6k3K2UTQJwTYO5kMnE3rDrHJVDL+LijAg+zLk
The contents of the dfc.properties file in dctm-rest:
dfc.docbroker.host[0]=172.18.0.1
dfc.docbroker.port[0]=1489
#Add the global registry repository name to the following key.
dfc.globalregistry.repository=ubuntudb
#Add the username of the global registry user to the following key.
dfc.globalregistry.username=dmadmin
#Add an encrypted password value for the following key.
dfc.globalregistry.password=password
dfc.exception.include_id=false
dfc.exception.include_decoration=false
I have attempted to change the value of dfc.globalregistry.username to be the same as in dctm-cs, to no avail and same hang on request.
I have also attempted to use both encrypted and decrypted values for dfc.globalregistry.password, in both dctm-cs and dctm-rest also with no luck.
I am writing an automated Jenkins machine creation script, and I have encountered a problem with SSH credentials, namely:
In Jenkins there is a file called credentials.xml (in /var/lib/jenkins) which stored credentials for the nodes. Mine looks like so:
<?xml version='1.0' encoding='UTF-8'?>
<com.cloudbees.plugins.credentials.SystemCredentialsProvider plugin="credentials#1.18">
<domainCredentialsMap class="hudson.util.CopyOnWriteMap$Hash">
<entry>
<com.cloudbees.plugins.credentials.domains.Domain>
<specifications/>
</com.cloudbees.plugins.credentials.domains.Domain>
<java.util.concurrent.CopyOnWriteArrayList>
<com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl>
<scope>GLOBAL</scope>
<id>8743cc14-bc2c-44a6-b6bb-c121bef4ae2d</id>
<description>root_with_secret</description>
<username>root</username>
<password>2Xd4i7+8tjVXg2RHP6ggl/ZtWJp177ajXNajJxsj80o=</password>
</com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl>
</java.util.concurrent.CopyOnWriteArrayList>
</entry>
</domainCredentialsMap>
There is (are) also nodes (slaves) configuration file(s) (stored in /var/lib/jenkins/nodes/HOSTNAME/config.xml for each slave) which look(s) like:
<?xml version='1.0' encoding='UTF-8'?>
<slave>
<name>HOSTNAME_OF_MY_SECRET_MACHINE</name>
<description>HOSTNAME_OF_MY_SECRET_MACHINE</description>
<remoteFS>/root</remoteFS>
<numExecutors>1</numExecutors>
<mode>NORMAL</mode>
<retentionStrategy class="hudson.slaves.RetentionStrategy$Always"/>
<launcher class="hudson.plugins.sshslaves.SSHLauncher" plugin="ssh-slaves#1.9">
<host>10.0.10.1</host>
<port>22</port>
<credentialsId>8743cc14-bc2c-44a6-b6bb-c121bef4ae2d</credentialsId>
<maxNumRetries>0</maxNumRetries>
<retryWaitTime>0</retryWaitTime>
</launcher>
<label></label>
<nodeProperties/>
<userId>anonymous</userId>
</slave>
The problem is that after I create the jenkins machine, copy credentials.xml and config.xmls for each slave then the credentials wouldn't work. I get
[07/26/15 16:00:39] [SSH] Opening SSH connection to 10.0.10.1:22.
ERROR: Failed to authenticate as root. Wrong password. (credentialId:8743cc14-bc2c-44a6-b6bb-c121bef4ae2d/method:password)
[07/26/15 16:00:41] [SSH] Authentication failed.
hudson.AbortException: Authentication failed.
at hudson.plugins.sshslaves.SSHLauncher.openConnection(SSHLauncher.java:1178)
at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:701)
at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:696)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
[07/26/15 16:00:41] Launch failed - cleaning up connection
[07/26/15 16:00:41] [SSH] Connection closed.
To solve this issue I can go to Jenkins -> Credentials -> and then update the credential with the same password that I would use anyway and it will work.
So the question is whether Jenkins uses kind of salting/hashing per installation so that the credentials.xml will not work if copied to a new machine?
OK, I have managed to solve this with (I believe) a workaround-ish solution, namely:
To store a password in plain text in credentials.xml, copy it over to the Jenkins machine after installing and starting the service. Then Jenkins will encrypt it with its new secret (or whatever it uses for that purpose) and it will work :)
EDIT
A second option is to install Jenkins, start it, and then copy the credentials.xml with encrypted passwords together with secrets directory and secret.xml from previous installation. This will copy both encryption master key and the encrypted credentials that have been created using this master key.