I have embedded activemq broker. I want to use simpleAuthenticationPlugin. I added dependency activemq-jaas for the embedded broker.
I have added setup for simpleAuthenticationPlugin but it seems trying to use my desktop username to authenticate or eclipse username (because it is the same username).
The following are the warnings:
[WARNING] Failed to add Connection ID:JACTXML00124548-57386-1499699996538-1:1 due to java.lang.SecurityException: User name [MY DESKTOP USERNAME] or password is invalid.
[WARNING] Security Error occurred on connection to: tcp://127.0.0.1:57387, User name [MY DESKTOP USERNAME] or password is invalid.
I cannot find anything suggesting that I need other configurations in the eclipse environment variables for the embedded broker.
Thanks a lot for any help or suggests.
Ok. It was due to spring's context:property-placeholder in my JmsClient's application-context.xml, I had ${USERNAME},${PASSWORD} which was trying to use environment variable instead of my client.properties file.
To avoid the issue, in both application-context.xml and client.properties, instead of having${USERNAME} and ${PASSWORD}, I changed to ${CONSUMER_USERNAME} and ${CONSUMER_PASSWORD}. It worked fine.
Related
I'm going to describe an odd situation.. We have a product with a properly working CAS and LDAP integration. The problem is that not all of our clients use LDAP, which is fine, EXCEPT that the integration is still in place and so CAS is actively attempting to connect to the ldap server (and failing of course). It attempts to connect every five minutes, which creates a very bloated Tomcat log. My goal is to prevent it from attempting to connect without gutting the integration. I'm hoping someone knows of a way to prevent or manage when/how CAS attempts to connect to the defined LDAP server.
I've attempted to remove key components of the CAS property file as well as the deployerConfigContext.xml but the integration has too many dependencies, and I haven't been successful.
Here are some of the properties that are used in the cas.properties file. Setting the ldap.auth.enabled to false allows our integration to not use LDAP when authenticating the user but doesn't prevent CAS from attempting to connect to the LDAP server:
ldap.auth.enabled=false
ldap.url=ldap://xyz.customurl.com
ldap.useStartTLS=false
ldap.rootDn=DC=xyz,DC=xyz,DC=com
ldap.baseDn=DC=xyz,DC=xyz,DC=com
ldap.connectTimeout=3000
ldap.managerDn=CN=xyz,CN=Users,DC=xyz,DC=xyz,DC=com
ldap.managerPassword=xyz
ldap.authn.searchFilter=(&(sAMAccountName={user})(objectClass=user))
ldap.domain=123.456.7.890
ldap.pool.minSize=1
ldap.pool.maxSize=10
ldap.pool.validateOnCheckout=false
ldap.pool.validatePeriodically=true
ldap.pool.blockWaitTime=3000
ldap.pool.validatePeriod=300
ldap.pool.prunePeriod=300
ldap.pool.idleTime=600
ldap.usePpolicy=false
ldap.allowMultipleDns=true
This is the relevant section from the deployerConfigContext.xml. I've tried commenting the entire ldap section but have received various other errors that caused TomCat to crash:
<bean id="ldapAuthenticationHandler"
class="org.jasig.cas.authentication.LdapAuthenticationHandler"
p:principalIdAttribute="sAMAccountName"
c:authenticator-ref="authenticator" lazy-init="true"/>
<ldaptive:ad-authenticator id="authenticator"
ldapUrl="${ldap.url}"
userFilter="${ldap.authn.searchFilter}"
bindDn="${ldap.managerDn}"
bindCredential="${ldap.managerPassword}"
allowMultipleDns="${ldap.allowMultipleDns:false}"
connectTimeout="${ldap.connectTimeout}"
validateOnCheckOut="${ldap.pool.validateOnCheckout}"
failFastInitialize="false"
blockWaitTime="${ldap.pool.blockWaitTime}"
idleTime="${ldap.pool.idleTime}"
baseDn="${ldap.baseDn}"
maxPoolSize="${ldap.pool.maxSize}"
minPoolSize="${ldap.pool.minSize}"
validatePeriodically="${ldap.pool.validatePeriodically}"
validatePeriod="${ldap.pool.validatePeriod}"
prunePeriod="${ldap.pool.prunePeriod}"
useSSL="${ldap.use.ssl:false}"
subtreeSearch="${ldap.subtree.search:true}"
useStartTLS="${ldap.useStartTLS}"/>
The stack trace for the CAS to LDAP server connection is huge. Here is a small snippet. I can attach the whole thing if that is useful.
org.ldaptive.provider.ConnectionException:
javax.naming.CommunicationException: ldap.url.com:389 [Root exception
is java.net.UnknownHostException: ldap.url.com
I toggle between JDBC and LDAP/AD Handlers. Ensure that you comment out your ldap handler under:
deployerConfigContext.xml
xpath:
/beans
/bean[class=org.jasig.cas.authentication.AuthenticationManagerImpl]
/property[name=authenticationHandlers]
/list/
We satisfactorily resolved this by disabling this log4j property in the log4j configuration file in CAS:
<Logger name="org.ldaptive.pool.BlockingConnectionPool" level="debug">
<AppenderRef ref="console" />
</Logger>
Another option may have been to create a log4j filter and target the particular message that was causing the tomcat file to become huge.
I am trying to set up jira as a task server in IDEA IntelliJ.
I am getting handshake_failure error when I try to test my connection.
Reading about it in SO and Atlassion forums, I tried several things but none worked:
downloading the certificate from jira server and installing it in intellij
adding -Dhttps.protocols="TLSv1" to my .vmoptions IDEA startup config file
It happens both to my corporate jira instance and to external public jira servers.
In addition, it also happened with IntelliJ 2016.
Has anyone managed to get this working?
The problem was that the server used a cipher that was disabled in my jvm.
In order to fix, I uncommented
crypto.policy=unlimited
in my jre <jre-home>\lib\security\java.security
see this SO question or this one for more details about security policies
SQ 5.6, LDAP plugin 2.0.
I've successfully installed the LDAP plugin and restarted the SQ server. In the log (/opt/sonar/logs/sonar.log) the plugin is apparently deployed, but seemingly no attempt is made to initialize/enable it or connect to the LDAP server.
INFO web[o.s.s.p.ServerPluginRepository] Deploy plugin LDAP / 2.0 / 2910f3981167a70a201ccfae01471dfd26c794b7
.
.
INFO web[o.s.s.p.RailsAppsDeployer] Deploying app: ldap
These are the only mentions of ldap/LDAP in the log.
Relevant part of the conf/sonar.properties file:
sonar.security.realm=LDAP
ldap.url=ldap://myldap:389
ldap.user.baseDn=ou=mycompany,ou=People,dc=myurl,dc=com
I believe I've verified ldap.url and ldap.user.baseDn via JXplorer (an LDAP browser).
What really puzzles me is that I don't see anything like the following in the logs, which is what I'd expect from the SQ docs:
INFO org.sonar.INFO Security realm: LDAP ...
INFO o.s.p.l.LdapContextFactory Test LDAP connection: OK
No errors of any kind are noted in the log.
Any idea why SQ is not even apparently trying to kick off LDAP authentication on a restart?
I had the same problem. I'm running Sonarqube using docker. It did not pick up on changes when I restart the server from the Sonarqube UI. Only after restarting the docker image it could pick up the changed file.
Well, now it just started working. I don't have an answer as to why though. Maybe something changed with my LDAP server, or there was some latency that needed to be overcome. I didn't change anything on my end that I'm aware of. In any case, thanks to those that responded.
I have an application running on Worklight 6.1 and I am seeing this messages on the log.
CWWKS3005E: A configuration exception has occurred. No UserRegistry implementation service is available
I don't need to authenticate the users on my application, can I ignore this message?
I'm not sure, but you can try to cancel logging for this specific package using following log configuration in server.xml:
<logging traceSpecification="XXX.XXX.*=off=disabled"/>
where XXX.XXX.* is the package where the error was occurred.
Here is a list of all available log levels: http://www-01.ibm.com/support/knowledgecenter/SSCKBL_8.5.5/com.ibm.websphere.nd.doc/ae/utrb_loglevel.html
I understand that you are not asked how to remove these messages from the log file, but you asked should you worry about these messages.
Anyway this log is not of Worklight server, it generated by Liberty server. It means you have something wrong in server configuration.
I found that this messages is because my server.xml configuration file of WebSphere Liberty Profile contains this feature
appSecurity-1.0
And I am not defining any User Registry.
http://pic.dhe.ibm.com/infocenter/rsahelp/v8r5/topic/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/rwlp_feat.html
I am not running the Application Center in this profile and I am securing the Worklight console using properties in the worklight.properties file.
So, the question is can I remove the appSecurity feature?
Add <basicRegistry></basicRegistry> to your server.xml.
This is expanded version of another login module problem I had. I diagnosed some more important details which encouraged me to start new thread. It occurres that after Glassfish reboot all login modules stopped working. What is even funnier, Glassfish reports that modules where loaded correctly.
[#|2012-09-05T16:40:59.698+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.RealmsManager;MethodName=createRealms;|Initializing configured realms from SecurityService in Domain.xml....|#]
[#|2012-09-05T16:40:59.710+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.file.FileRealm;MethodName=init;|FileRealm : file={glass_home}/glassfish/domains/domain1/config/admin-keyfile|#]
[#|2012-09-05T16:40:59.710+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.file.FileRealm;MethodName=init;|FileRealm : jaas-context=fileRealm|#]
[#|2012-09-05T16:40:59.711+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.file.FileRealm;MethodName=loadKeyFile;|Reading file realm: {glass_home}/glassfish/domains/domain1/config/admin-keyfile|#]
[#|2012-09-05T16:40:59.713+0200|INFO|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;|SEC1115: Realm [admin-realm] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.|#]
[#|2012-09-05T16:40:59.713+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.RealmConfig;MethodName=createRealms;|Configured realm: admin-realm|#]
[#|2012-09-05T16:40:59.714+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.file.FileRealm;MethodName=init;|FileRealm : file={glass_home}/glassfish/domains/domain1/config/keyfile|#]
[#|2012-09-05T16:40:59.714+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.file.FileRealm;MethodName=init;|FileRealm : jaas-context=fileRealm|#]
[#|2012-09-05T16:40:59.715+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.file.FileRealm;MethodName=loadKeyFile;|Reading file realm: {glass_home}/glassfish/domains/domain1/config/keyfile|#]
[#|2012-09-05T16:40:59.715+0200|INFO|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;|SEC1115: Realm [file] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.|#]
[#|2012-09-05T16:40:59.715+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.RealmConfig;MethodName=createRealms;|Configured realm: file|#]
[#|2012-09-05T16:40:59.717+0200|INFO|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;|SEC1115: Realm [certificate] of classtype [com.sun.enterprise.security.auth.realm.certificate.CertificateRealm] successfully created.|#]
[#|2012-09-05T16:40:59.718+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.RealmConfig;MethodName=createRealms;|Configured realm: certificate|#]
[#|2012-09-05T16:40:59.757+0200|FINEST|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm;MethodName=init;|JDBCRealm : jaas-context= jdbcRealm, datasource-jndi = jdbc/mysql-zus, db-user = null, digest-algorithm = MD5, encoding = Hex, charset = UTF-8|#]
[#|2012-09-05T16:40:59.758+0200|INFO|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;|SEC1115: Realm [ShibUserPassAuth] of classtype [com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm] successfully created.|#]
[#|2012-09-05T16:40:59.758+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.RealmConfig;MethodName=createRealms;|Configured realm: ShibUserPassAuth|#]
[#|2012-09-05T16:40:59.758+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.RealmConfig;MethodName=createRealms;|Default realm is set to: ShibUserPassAuth|#]
[#|2012-09-05T16:40:59.762+0200|INFO|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security|_ThreadID=1;_ThreadName=Thread-2;|SEC1011: Security Service(s) Started Successfully|#]
But I am unable to use any of secure realms, during basic authentication.
I tried both custom jdbcRealm and preconfigured fileRealm with new user
It ends up with this:
javax.security.auth.login.LoginException: No LoginModules configured for jdbcRealm
at javax.security.auth.login.LoginContext.init(LoginContext.java:273)
and this
javax.security.auth.login.LoginException: No LoginModules configured for fileRealm
at javax.security.auth.login.LoginContext.init(LoginContext.java:273)
More over I can't even use more sophisticated asadmin commands, because I received "unauthorised wrong login or password" and in server.log
No LoginModule configured for fileRealm
I checked LoginContext implementation and it looks like that
AppConfigurationEntry[] entries = config.getAppConfigurationEntry (name);
is constantly going wrong way, and null is returned.
I don't manipulate config files by hand. Can I somehow corrupt on of them in a way that block LoginModules?
Which configuration file is being read by ConfigurationEntry above?
Before this unfortunate reboot problem with the MySQL database occurred. There were more available for the Glassfish connection pool, than database permits. After killing connections from database, changing connection numbers for appropriate I rebooted container and everything collapsed.
login.conf exist in domain dir and looks ok.
Hope for help
Paraphrasing Catherine Zeta Jones and Liza Minnelli before her i will say
"and All that JAAS...".
It occurs that one of third party aplications was loading it's own login.conf file for JAAS module, which destroyed all Glassfish login modules. This situation occurs after container reboot when secondary configuration file was being loaded. Funny thing, Glassfish was able to load it's own file properly, show off in logs... and then overwrite it malicious configuration. Watch your configuration files!