I've updated tolven on Friday and could not login after that. It complained about null parameter in ObjectName class.
Today I've re-install tolven completely and got the following exception while login:
javax.security.auth.login.LoginException: Failed to decode password: null
org.jboss.resource.security.JaasSecurityDomainIdentityLoginModule.commit(JaasSecurityDomainIdentityLoginModule.java:153)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
in log files I found the following
2006-11-20 14:51:05,031 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@12c55e4, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@1124642{ url=null ,addedOrder=0}
2006-11-20 14:51:05,031 DEBUG [org.jboss.resource.security.JaasSecurityDomainIdentityLoginModule] Failed to decode password
javax.management.MBeanException
at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:180)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:163)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
Caused by: javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher
at com.sun.crypto.provider.SunJCE_h.b(DashoA12275)
at com.sun.crypto.provider.SunJCE_h.b(DashoA12275)
at com.sun.crypto.provider.SunJCE_af.b(DashoA12275)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Joe provides a hint that may help while we diagnose this further:
"It's likely the ldapserver.password file in JBoss' conf directory does not match the entry in tolvenApplicationLDAP [in file tolven-ldap-service.xml] i.e. the ldapserver.password could not be decoded, and therefore returned null. They might want to cross-reference that ldapserver.passsword with the one in the stage."
John.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am not sure what configuration caused this error. But, I synchronized with the CVS HEAD, created a demo user and logged into the application, and there were no errors, indicating that the HEAD is fine. From that configuration, I went to the tolvenApplicationLDAP application policy located in server/conf/login-config.xml, and changed one letter of the password. This resulted in the identical error reported. Again, not knowing the configuration in which the error occurred, I would suggest, comparing or replacing your login-config.xml with the one in your stage directory (simply replacing the password may be enough). I would also replace the server/conf/ldap.password with the one in stage, since these two must be in synch for the password to succesfully decode.
Joe
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
strange but it not works for me ;(
I've updated from HEAD, deleted stage directory and made step-by-step what described in http://tolven.org/setup/developer-install.html but had this error again ;(
in tolven-ldap-service.xml
<attribute name="KeyStorePass">
{CLASS}org.jboss.security.plugins.FilePassword:${jboss.server.home.dir}/conf/ldapserver.password
</attribute>
and I checked that this file is processed while starting service so it couldn't be any missmatch
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have added two targets to the security build.xml, which allow the LDAP and DB credentials to be tested for validity. The main targets are: <validate-jboss-ldap-credentials> and <validate-jboss-db-credentials>. Be sure to enter the correct values (I would suggest cut and paste for the hashes). Let me know what the result of both the LDAP and DB tests are.
Joe
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks for such great support!
strange but validation test said that everything ok
I've solved this problem by copying content from pgserver.password to ldapserver.password and updating solt and hashes
after that password to database and ldap became identical and login performs without problems
so the problem is only ldap. if you want I can send you any config files
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The ldapserver.password and pgserver.password currently have the same master password and iterations by default, but the salt is different. The salt and iterations can be changed in ant-build.properties. But copying pgserver.password to ldapserver.password should not work, if that's all that was done, unless both the salt and iterations are the same (and the keystore password too), and that would mean that they would have had to have been changed from the defaults. However, if your system is working now, then there is no need to send any config files.
Joe
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi!
have again problem with authentication ;)
I've updated tolven on Friday and could not login after that. It complained about null parameter in ObjectName class.
Today I've re-install tolven completely and got the following exception while login:
javax.security.auth.login.LoginException: Failed to decode password: null
org.jboss.resource.security.JaasSecurityDomainIdentityLoginModule.commit(JaasSecurityDomainIdentityLoginModule.java:153)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
in log files I found the following
2006-11-20 14:51:05,031 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@12c55e4, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@1124642{ url=null ,addedOrder=0}
2006-11-20 14:51:05,031 DEBUG [org.jboss.resource.security.JaasSecurityDomainIdentityLoginModule] Failed to decode password
javax.management.MBeanException
at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:180)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:163)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
Caused by: javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher
at com.sun.crypto.provider.SunJCE_h.b(DashoA12275)
at com.sun.crypto.provider.SunJCE_h.b(DashoA12275)
at com.sun.crypto.provider.SunJCE_af.b(DashoA12275)
Joe provides a hint that may help while we diagnose this further:
"It's likely the ldapserver.password file in JBoss' conf directory does not match the entry in tolvenApplicationLDAP [in file tolven-ldap-service.xml] i.e. the ldapserver.password could not be decoded, and therefore returned null. They might want to cross-reference that ldapserver.passsword with the one in the stage."
John.
I am not sure what configuration caused this error. But, I synchronized with the CVS HEAD, created a demo user and logged into the application, and there were no errors, indicating that the HEAD is fine. From that configuration, I went to the tolvenApplicationLDAP application policy located in server/conf/login-config.xml, and changed one letter of the password. This resulted in the identical error reported. Again, not knowing the configuration in which the error occurred, I would suggest, comparing or replacing your login-config.xml with the one in your stage directory (simply replacing the password may be enough). I would also replace the server/conf/ldap.password with the one in stage, since these two must be in synch for the password to succesfully decode.
Joe
strange but it not works for me ;(
I've updated from HEAD, deleted stage directory and made step-by-step what described in http://tolven.org/setup/developer-install.html but had this error again ;(
in tolven-ldap-service.xml
<attribute name="KeyStorePass">
{CLASS}org.jboss.security.plugins.FilePassword:${jboss.server.home.dir}/conf/ldapserver.password
</attribute>
and I checked that this file is processed while starting service so it couldn't be any missmatch
I have added two targets to the security build.xml, which allow the LDAP and DB credentials to be tested for validity. The main targets are: <validate-jboss-ldap-credentials> and <validate-jboss-db-credentials>. Be sure to enter the correct values (I would suggest cut and paste for the hashes). Let me know what the result of both the LDAP and DB tests are.
Joe
thanks for such great support!
strange but validation test said that everything ok
I've solved this problem by copying content from pgserver.password to ldapserver.password and updating solt and hashes
after that password to database and ldap became identical and login performs without problems
so the problem is only ldap. if you want I can send you any config files
The ldapserver.password and pgserver.password currently have the same master password and iterations by default, but the salt is different. The salt and iterations can be changed in ant-build.properties. But copying pgserver.password to ldapserver.password should not work, if that's all that was done, unless both the salt and iterations are the same (and the keystore password too), and that would mean that they would have had to have been changed from the defaults. However, if your system is working now, then there is no need to send any config files.
Joe