I have configured Websphere Liberty to use LDAP to authenticate user. I have enabled security trace -
com.ibm.ws.security.=all:com.ibm.ws.webcontainer.security.=all:com.ibm.oauth.=all:com.ibm.wsspi.security.oauth20.=all:com.ibm.ws.transport.http.=all:org.apache.http.client.=all
I have following feature list enabled in WebSphere Liberty v17.0.0.3,
webProfile-7.0, javaMail-1.5, ldapRegistry-3.0 and localConnector-1.0.
However, secure content is failing with error HTTP 401 (Unauthenticated).
In trace file, I can see that LDAP is able to return logged in user data. But WebSphere Liberty is failing with error -
com.ibm.wsspi.security.wim.model.Entity incompatible with com.ibm.wsspi.security.wim.model.LoginAccount
java.lang.ClassCastException: com.ibm.wsspi.security.wim.model.Entity incompatible with com.ibm.wsspi.security.wim.model.LoginAccount
at com.ibm.ws.security.wim.registry.util.SecurityNameBridge.getUserSecurityName(SecurityNameBridge.java:203)
at com.ibm.ws.security.wim.registry.WIMUserRegistry.getUserSecurityName(WIMUserRegistry.java:316)
at com.ibm.ws.security.authentication.internal.jaas.modules.ServerCommonLoginModule.getSecurityName(ServerCommonLoginModule.java:104)
Please help guide if this error is due to any configuration problem.
The problem was resolved after correcting configuration of registry used. I was using LDAP registry and had mentioned LDAP server type as Tivoli. This was causing the problem in Subject class being returned from LDAP not matching expected class in Liberty. Once I changed LDAP service type to Custom, this error got resolved. Below is the tag for LDAP registry I used in server.xml
<ldapRegistry baseDN="ou=xxxxxxxx,o=xxxxxx" host="xxxxxxxxxxxxxxx" id="xxxxxxxxxxx" ldapType="Custom" port="636" realm="xx" recursiveSearch="true" sslEnabled="true" sslRef="sslrepo1">
<customFilters userFilter="(&(mail=%v)(objectclass=ePerson))" userIdMap="*:mail"/>
</ldapRegistry>
Related
I get below error when I consume message in a Jboss ejb container
2022-05-18 22:37:24,699 ERROR [org.jboss.resource.adapter.jms.inflow.JmsActivation] Unable to reconnect org.jboss.resource.adapter.jms.inflow.JmsActivationSpec#8315a9(ra=org.jboss.resource.adapter.jms.JmsResourceAdapter#10a62f0 destination=queues/Subscriber.global.globalvirtual.e2e.cmdm.changepub.Virtual destinationType=javax.jms.Queue tx=true durable=false reconnect=10 provider=java:/ACTIVEMQJMSNONXAProviderAsync user=ldcp.cmdm pass= )
javax.jms.JMSException: Please enable transactions on PulsarConnectionFactory with enableTransaction=true
After getting this error - I set enableTransaction=true and started getting different error
javax.jms.JMSException: not supported
at com.datastax.oss.pulsar.jms.PulsarConnection.createConnectionConsumer(PulsarConnection.java:685)
the error is in createConnectionConsumer.
This is the method called by the JBoss container.
This method is currently not implemented
https://github.com/datastax/pulsar-jms/blob/96606d0f22a1af8fdde0c5eff0f5dde086d9862c/pulsar-jms/src/main/java/com/datastax/oss/pulsar/jms/PulsarConnection.java#L685
the implementation should be quite straighforward.
There are integration tests for Payara and Apache TomEE but JBoss is still not covered.
Please open an issue on github.
I am using alfresco 5.2.3 enterprise with solr6 search services.
Everything works fine when I deploy our application custom code inside the alfresco-platform jar and alfresco-share jar.
Now, when I install alfresco records management amp file, the search stops working. I am not able to search even a single document or folder.
RM amp version: alfresco-rm-enterprise-repo-2.7.0.amp and alfresco-rm-enterprise-share-2.7.0.amp
There are three different instances: repo (where alfresco.war sits), share (where share.war and ADF sits) and index server (where indexes are maintained).
I install alfresco-rm-enterprise-repo-2.7.0.amp on repo, and alfresco-rm-enterprise-share-2.7.0.amp on share. And restart the servers. RM installation is successful without any errors. But search is not at all working after this.
Is it possible that after RM installation, some indexes are corrupted, and we need to conduct reindexing ? Can that resolve this issue ?
NOTE: The versions of alfresco and RM are already in the supported stack as per the alfresco documentation link: https://docs.alfresco.com/5.2/concepts/supported-platforms-ACS.html
Any help would be appreciated.
Finally, the problem is resolved.
The keystore, truststore certificate files were the culprit.
New keystore, truststore files were required to be generated as the communication between ACS and Index server was not happening and resulting into GetModelsDiff 403 error in the logs.
Additionally, we ensured the following settings were put up in ACS and index server files:
ACS alfresco-global.properties:
alfresco.host=alfresco-dev-repo.domain.com
alfresco.port=443
alfresco.protocol=https
share.host=alfresco-dev-repo.domain.com
share.port=443
share.protocol=https
db.ssl_params=&useSSL=true&requireSSL=true&verifyServerCertificate=true&trustCertificateKeyStoreUrl=file:///opt/alfresco-content-services/alf_data/keystore/ssl.truststore&trustCertificateKeyStoreType=JCEKS&trustCertificateKeyStorePassword=kT9X6oe68t
db.url=jdbc:mysql://${db.host}/${db.name}?${db.params}${db.ssl_params}
index.subsystem.name=solr6
dir.keystore=${dir.root}/keystore
solr.host=alfresco-dev-index.domain.com
solr.port.ssl=8983
solr.port=80
solr.secureComms=https
#ssl encryption
encryption.ssl.keystore.location=${dir.keystore}/ssl.keystore
encryption.ssl.keystore.type=JCEKS
encryption.ssl.keystore.keyMetaData.location=${dir.keystore}/ssl-keystore-passwords.properties
encryption.ssl.truststore.location=${dir.keystore}/ssl.truststore
encryption.ssl.truststore.type=JCEKS
encryption.ssl.truststore.keyMetaData.location=${dir.keystore}/ssl-truststore-passwords.properties
Solr Configuration:
solr.in.sh file:
SOLR_PORT=8983
SOLR_SSL_KEY_STORE=/opt/alfresco-search-services/solrhome/keystore/ssl.keystore
SOLR_SSL_KEY_STORE_PASSWORD=kT9X6oe68t
SOLR_SSL_TRUST_STORE=/opt/alfresco-search-services/solrhome/keystore/ssl.truststore
SOLR_SSL_TRUST_STORE_PASSWORD=kT9X6oe68t
SOLR_SSL_NEED_CLIENT_AUTH=true
SOLR_SSL_WANT_CLIENT_AUTH=false
alfresco core > solrcore.properties AND archive core > solrcore.properties
alfresco.secureComms=https
data.dir.root=/opt/alfresco-search-services/solrhome/
alfresco.port.ssl=8443
alfresco.encryption.ssl.keystore.passwordFileLocation=ssl-keystore-passwords.properties
alfresco.encryption.ssl.truststore.passwordFileLocation=ssl-truststore-passwords.properties
alfresco.baseUrl=/alfresco
alfresco.host=alfdevhostname.domain.com
alfresco.encryption.ssl.keystore.provider=
alfresco.encryption.ssl.truststore.type=JCEKS
alfresco.encryption.ssl.truststore.provider=
alfresco.encryption.ssl.keystore.type=JCEKS
alfresco.encryption.ssl.keystore.location=ssl.keystore
alfresco.port=80
alfresco.version=5.2.3
alfresco.encryption.ssl.truststore.location=ssl.truststore
No need of touching the files under this location:
/opt/alfresco-search-services/solrhome/templates/rerank/conf
And finally the most important part:
Latest/Updated Certificate files placed under:
/opt/alfresco-search-services/solrhome/keystore
And the same certificate files placed under:
/opt/alfresco-search-services/solrhome/alfresco/conf
and
/opt/alfresco-search-services/solrhome/archive/conf
and on ACS server:
/opt/alfresco-content-services/alf_data/keystore
On top of it, if the issue is still not getting resolved, you can try the following:
Set solr.secureComms=none in alf-global, and alfresco.secureComms=none in archive core and alfresco core, and restart both entities to see if the normal HTTP connection is working without SSL or HTTPS
Validate with infra/netwk team is certificates installed r correct or not
Try pointing directly the IP address of alfresco and solr to each other, instead of host name –as it might be coming through LB
Try Telnet solr host from alfresco repo server, and also vice-versa
Put -Djavax.net.debug=all under alfresco > tomcat/scripts/ctl.sh and see if you get any useful information
Check not just the alfresco.log, solr.log, see access-logs if you can find 404 or 200 status responses. OR curl on solr machine against the URL that is logged in localhost-access logs.
Starting/stopping solr with root user – ideally should be another dedicated user for solr
Ideally certificates should be copied from alfresco (alf_data/keystore) to solr server, not from solr to alfresco server. But if not working, you can try the other way around.
The alfresco.host, share.host, alfresco.port, share.port in alf-global should match with properties in solrhome/alfresco/conf/solrcore.properties + solrhome/archive/conf/solrcore.properties
Try putting debugger on i.e debug statements on from alfresco repo side as well as solr side to capture any unknown or hidden exceptions/errors.
You can also check the solr-admin console page from browser and check the logs from there.
I faced similar issue on Alfresco 6.2.2 with alfresco-insight-engine 2.0.0. Multiple errors like below I had faced one by one after changing the configurations :-
If certificates are not matching between ACS, Solr OR between ACS, Solr and AWS OR certificates generated are incorrect OR certificates compatible only with particular java version OR certificates not added to truststore correctly, then you may get:
javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException ,
unable to find valid certification path to requested target ,
Caused by: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
I checked the configuration (certificate) was imported correctly at AWS side. And no restriction was applied at AWS side.
But, finally I was able to resolve with the following combination:
Alfresco side
Server.xml:
<Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol"
SSLEnabled="true" maxThreads="150" scheme="https"
keystoreFile="/app/tomcat/keystores/ssl.keystore"
keystorePass="pwd" keystoreType="JCEKS"
secure="true" connectionTimeout="240000"
truststoreFile="/app/tomcat/keystores/ssl.truststore"
truststorePass="pwd" truststoreType="JCEKS"
clientAuth="false" sslProtocol="TLS" />
alfresco-global.properties:
index.subsystem.name=solr6
solr.secureComms=https
solr.port=8984
solr.port.ssl=8984
solr.host=domainname
alfresco.context=alfresco
alfresco.host=host
alfresco.port=8443
alfresco.protocol=https
#
share.context=share
share.host=host
share.port=8443
share.protocol=https
#ssl encryption
encryption.ssl.keystore.location=/app/tomcat/keystores/ssl.keystore
encryption.ssl.keystore.type=JCEKS
encryption.ssl.keystore.keyMetaData.location=/app/tomcat/keystores/ssl-keystore-passwords.properties
encryption.ssl.truststore.location=/app/tomcat/keystores/ssl.truststore
encryption.ssl.truststore.type=JCEKS
encryption.ssl.truststore.keyMetaData.location=/app/tomcat/keystores/ssl-truststore-passwords.properties
solr side
solr.in.sh
SOLR_SOLR_HOST=domainname
SOLR_ALFRESCO_HOST=domainname
SOLR_SSL_CUSTOM="-Dsolr.ssl.checkPeerName=false -Dsolr.allow.unsafe.resourceloading=true"
SOLR_OPTS="$SOLR_SSL_CUSTOM"
SOLR_PORT=8984
SOLR_HOST=domainname
SOLR_SSL_KEY_STORE=/app/alfresco-insight-engine/solrhome/keystore/ssl.repo.client.keystore
SOLR_SSL_KEY_STORE_PASSWORD=pwd
SOLR_SSL_KEY_STORE_TYPE=JCEKS
SOLR_SSL_TRUST_STORE=/app/alfresco-insight-engine/solrhome/keystore/ssl.repo.client.truststore
SOLR_SSL_TRUST_STORE_PASSWORD=pwd
SOLR_SSL_TRUST_STORE_TYPE=JCEKS
SOLR_SSL_NEED_CLIENT_AUTH=false
SOLR_SSL_WANT_CLIENT_AUTH=true
solrcore.properties (both cores)
alfresco.encryption.ssl.truststore.location=ssl.repo.client.truststore
alfresco.encryption.ssl.keystore.provider=
alfresco.encryption.ssl.truststore.type=JCEKS
alfresco.host=ip-10-233-4-126.ap-east-1.compute.internal
alfresco.encryption.ssl.keystore.location=ssl.repo.client.keystore
alfresco.encryption.ssl.truststore.provider=
alfresco.port.ssl=8443
alfresco.encryption.ssl.truststore.passwordFileLocation=ssl-truststore-passwords.properties
alfresco.port=8080
alfresco.encryption.ssl.keystore.type=JCEKS
alfresco.secureComms=https
alfresco.encryption.ssl.keystore.passwordFileLocation=ssl-keystore-passwords.properties
solrcore.properties (under rerank/conf)
alfresco.host=domainname
alfresco.port=8080
alfresco.port.ssl=8443
alfresco.secureComms=https
alfresco.encryption.ssl.keystore.type=JCEKS
alfresco.encryption.ssl.keystore.provider=
alfresco.encryption.ssl.keystore.location=ssl.repo.client.keystore
alfresco.encryption.ssl.keystore.passwordFileLocation=ssl-keystore-passwords.properties
alfresco.encryption.ssl.truststore.type=JCEKS
alfresco.encryption.ssl.truststore.provider=
alfresco.encryption.ssl.truststore.location=ssl.repo.client.truststore
alfresco.encryption.ssl.truststore.passwordFileLocation=ssl-truststore-passwords.properties
The alfresco keystore files (used/pointed to by Alfresco) are under /app/tomcat/keystores.
And solr keystore files (used/pointed to by solr) are under /app/alfresco-insight-engine/solrhome/keystore.
NOTE: We have copied the solr keystores files to following locations also: /app/alfresco-insight-engine/solrhome/alfresco/conf , /app/alfresco-insight-engine/solrhome/archive/conf , /app/alfresco-insight-engine/solrhome/templates/rerank/conf
NOTE: If it's just a certificate not added to truststore cacerts, then you can add the certificate to the cacerts using this link: Error - trustAnchors parameter must be non-empty
Other points which can be checked if above does not work:
Check if java version is a supported one (in supported stack) and certificates are correctly getting added to the truststore.
Check the java version from alfresco's admin summary page and verify if certificates get added into the correct java
Check if solr host, port and ssl port is correctly picked up. Verify this location - http://domainname/alfresco/s/enterprise/admin/admin-searchservice , as port might be picked up from here which might not match with the one in alfresco-global.properties file. In case of mismatching properties between alf-global and admin-searchservice URL, you may get “Connection refused” error in alfresco logs when alfresco tries to connect to solr.
If JKS type of certi has become obsolete, try generating PKCS12 or JCEKS type certi.
When solr is running on 8983 (http) as well as 8984 (https/ssl), you may get error "Unsupported or unrecognized SSL message". Try stopping one which is not used.
If https with 8984 solr url is not accessible from browser, then try importing the correct certificate at AWS, and also try adding following entry in /app/alfresco-insight-engine/solr/server/etc/jetty-ssl.xml file: FALSE
We're facing an issue where Jetty SPNEGO gives an NPE inside SpnegoLoginService.login()
The gssContext.getSrcName() call returns null.
The SPN is: HTTP/machine.dd.aa.net#EE.AA.NET
Must there be a special setup in the KRB5.INI file when dd.aa.net != EE.AA.NET ?
The only clue i found with Google is this warning message from some online source code:
if (gssContext.isEstablished()) {
if (gssContext.getSrcName() == null) {
log.warn("GSS Context accepted, but no context initiator recognized. Check your kerberos configuration and reverse DNS lookup configuration");
return false;
}
Our client-setup is
Internet-explorer browser, setup for negotiate/spnego
login using Windows SmartCard
Our server-setup is
Java 8u45
Jetty 9
using org.eclipse.jetty.security.SpnegoLoginService
We used java kinit on the server to validate against the keytab and also against the DC. which went ok. Also the reverse DNS zones are working.
is there a possibility that the 'service request token' generated by the client browser (logged in with smartcard) doesn't supply the context initiator / client principle name ?
Thanks
The nullpointer was gone when we went from Java 1.8u45 to Java 1.8u60
Turns out the server side didn't check all tickets provided by the client, so didn't find the correct one.
Below the bug entry:
[JDK-8078439] SPNEGO auth fails if client proposes MS krb5 OID
am using Jboss 6, my problem is that when I want to view my admin console it will give me this>>>
HTTP Status 404 - /admin-console/
type Status report
message /admin-console/
description The requested resource (/admin-console/) is not available.
JBoss Web/3.0.0-CR2
and it goes the same if I want to view my Jboss Web Services Console,>>
HTTP Status 404 - /jbossws/
type Status report
message /jbossws/
description The requested resource (/jbossws/) is not available.
JBoss Web/3.0.0-CR2
what is the problem actually? is there anything to do with admin console.war?
You seem to have corrupted the JBoss installation, highly reccomended to use a fresh installation and deploy your application rather than debug this.
I'm trying to ammend an existing SOAP Webservice that uses Spring-WS and JAXB on Tomcat. I've created the new WAR file with my changes and deployed it in the webapps foder under Tomcat installation.
When calling the original (already existing) methods of the service, the service SOAP request and response is fine. But when calling the service on the new method, I get service SOAP response of service unavailable and not found [404]
2011-07-25 12:58:23,365 DEBUG [org.springframework.ws.client.core.WebServiceTemplate] - Opening [org.springframework.ws.transport.http.HttpUrlConnection#12b9f14] to [http://<service URL>]
2011-07-25 12:58:23,521 DEBUG [org.springframework.ws.soap.saaj.support.SaajUtils] - SOAPElement [com.sun.xml.internal.messaging.saaj.soap.ver1_1.Envelope1_1Impl] implements SAAJ 1.3
2011-07-25 12:58:23,552 DEBUG [org.springframework.ws.soap.saaj.support.SaajUtils] - SOAPElement [com.sun.xml.internal.messaging.saaj.soap.ver1_1.Body1_1Impl] implements SAAJ 1.3
2011-07-25 12:58:23,896 DEBUG [org.springframework.ws.client.MessageTracing.sent] - Sent request [<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Header/><SOAP-ENV:Body><ns2:DelRequest xmlns:ns2="http://<changed_address>"><ns2:userId>ncc1#%</ns2:userId><ns2:dateFromMillis>1308956400000</ns2:dateFromMillis><ns2:dateToMillis>1311634800000</ns2:dateToMillis></ns2:DelRequest></SOAP-ENV:Body></SOAP-ENV:Envelope>]
2011-07-25 12:58:25,318 DEBUG [org.springframework.ws.client.core.WebServiceTemplate] - Received error for request [SaajSoapMessage {http://<changed_address>}DelRequest]
2011-07-25 12:58:25,318 ERROR [net.msgplugin.controller.DeleteController] - Conversation service unavailable at: http://, Not Found [404] , null
I've imported the project into Eclipse and have made the following changes to the project properties:
1) With in Project Facets, I've checked the 'Dynamic Web Module' and 'Java' Facets.
2) In Java EE Module Dependencies, I've checked Maven Dependencies.
Two things which are to be noted here are:
a) The developer was using JBoss when developing the Webservice but recently the project was chagned to Tomcat.
b) The project has a MAVEN folder structure, hence the web.xml file is in src/main/webapp/WEB-INF folder rather than WebContent/WEB-INF, taht got created when I selected the 'Dynamic Web Module' facet.
Any suggestions wld be hugely appreciated?
Thanks
========================================================================
HI
I managed to fix the Not Found [404] error but am now getting another error.
Upon further investigation and debuggin into WebServiceTemplate and MessageDispatcher classes, I found that following output on the console:
DEBUG [org.springframework.ws.transport.http.WebServiceMessageReceiverHandlerAdapter] - Accepting incoming [org.springframework.ws.transport.http.HttpServletConnection#11f05a1] to [http://<Service_URL>]
TRACE [org.springframework.ws.server.MessageTracing.received] - Received request [<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Header/><SOAP-ENV:Body><ns2:DelRequest xmlns:ns2="http://<changed_address>"><ns2:userId>ncc1#%</ns2:userId><ns2:dateFromMillis>1309042800000</ns2:dateFromMillis><ns2:dateToMillis>1311721200000</ns2:dateToMillis></ns2:DelRequest></SOAP-ENV:Body></SOAP-ENV:Envelope>]
DEBUG [org.springframework.ws.server.endpoint.mapping.PayloadRootAnnotationMethodEndpointMapping] - Looking up endpoint for [{<changed_address>}DelRequest]
DEBUG [org.springframework.ws.soap.server.SoapMessageDispatcher] - Endpoint mapping [org.springframework.ws.server.endpoint.mapping.PayloadRootAnnotationMethodEndpointMapping#6ee035] maps request to endpoint [public final net.org.messagehistory.schema.GetDelResponse net.org.messagehistory.service.endpoint.MessageHistoryEndpoint.delHistory(net.org.messagehistory.schema.GetListRequest) throws javax.xml.datatype.DatatypeConfigurationException]
DEBUG [org.springframework.ws.soap.server.SoapMessageDispatcher] - Testing endpoint adapter [org.springframework.ws.server.endpoint.adapter.GenericMarshallingMethodEndpointAdapter#1a23f67]
DEBUG [org.springframework.ws.server.endpoint.adapter.GenericMarshallingMethodEndpointAdapter] - Unmarshalled payload request to [net.org.messagehistory.schema.DelRequest#c76003]
The end error message is now 'Argument type Mismatch' which I found was generated from one of the methods from within WebServiceTemplate.class
Can somebody suggest what coudl be the problem here?
Managed to get this sorted. So, just wanted to share the solution that somebody might find helpful.
Make sure that the Endpoint method is annotated with the following
#PayloadRoot(localPart = MESSAGES_TO_DELETE, namespace = MESSAGE_NAMESPACE)
where localpart is the same as the your payload request in the schema.xsd
Thanks