[Security & JAAS/JBoss] - Re: JBOSS Negotiate using AdvancedLdapLoginModule throws bin
by dufferdo25
OK I solved the bind issue by setting a value in adsiedit dcHeuristics 0000002 which allows anonymous access to read or list AD. I would have thought that the UPN would be reading the AD and not an anonymous conn.
I now have a new error:
2009-07-02 15:56:29,763 DEBUG [org.jboss.security.negotiation.spnego.AdvancedLdapLoginModule] (http-0.0.0.0-8080-1) Obtained LdapContext
| 2009-07-02 15:56:29,768 INFO [STDOUT] (http-0.0.0.0-8080-1) [Krb5LoginModule]: Entering logout
| 2009-07-02 15:56:29,768 INFO [STDOUT] (http-0.0.0.0-8080-1) [Krb5LoginModule]: logged out Subject
| 2009-07-02 15:56:29,768 TRACE [org.jboss.security.negotiation.spnego.SPNEGOLoginModule] (http-0.0.0.0-8080-1) abort
| 2009-07-02 15:56:29,768 TRACE [org.jboss.security.negotiation.spnego.AdvancedLdapLoginModule] (http-0.0.0.0-8080-1) abort
| 2009-07-02 15:56:29,768 TRACE [org.jboss.security.plugins.auth.JaasSecurityManagerBase.SPNEGO] (http-0.0.0.0-8080-1) Login failure
| javax.security.auth.login.LoginException: Unable to find user DN
| at org.jboss.security.negotiation.AdvancedLdapLoginModule.findUserDN(AdvancedLdapLoginModule.java:528)
| at org.jboss.security.negotiation.AdvancedLdapLoginModule.innerLogin(AdvancedLdapLoginModule.java:343)
| at org.jboss.security.negotiation.AdvancedLdapLoginModule$AuthorizeAction.run(AdvancedLdapLoginModule.java:734)
| at java.security.AccessController.doPrivileged(Native Method)
| at javax.security.auth.Subject.doAs(Unknown Source)
| at org.jboss.security.negotiation.AdvancedLdapLoginModule.login(AdvancedLdapLoginModule.java:279)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
| at java.lang.reflect.Method.invoke(Unknown Source)
| at javax.security.auth.login.LoginContext.invoke(Unknown Source)
| at javax.security.auth.login.LoginContext.access$000(Unknown Source)
| at javax.security.auth.login.LoginContext$4.run(Unknown Source)
| at java.security.AccessController.doPrivileged(Native Method)
| at javax.security.auth.login.LoginContext.invokePriv(Unknown Source)
| at javax.security.auth.login.LoginContext.login(Unknown Source)
| at org.jboss.security.plugins.auth.JaasSecurityManagerBase.defaultLogin(JaasSecurityManagerBase.java:552)
| at org.jboss.security.plugins.auth.JaasSecurityManagerBase.authenticate(JaasSecurityManagerBase.java:486)
| at org.jboss.security.plugins.auth.JaasSecurityManagerBase.isValid(JaasSecurityManagerBase.java:365)
| at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:160)
| at org.jboss.web.tomcat.security.JBossWebRealm.authenticate(JBossWebRealm.java:384)
| at org.jboss.security.negotiation.NegotiationAuthenticator.authenticate(NegotiationAuthenticator.java:127)
| at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:491)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
| at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
| at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
| at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
| at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
| at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
| at java.lang.Thread.run(Unknown Source)
| Caused by: javax.naming.NameNotFoundException: [LDAP: error code 32 - 0000208D: NameErr: DSID-03151EFD, problem 2001 (NO_OBJECT), data 0, b
| est match of:
| 'DC=base,DC=myco,DC=com'
| ]; remaining name 'OU=Clients,DC=base,DC=myco,DC=com'
| at com.sun.jndi.ldap.LdapCtx.mapErrorCode(Unknown Source)
| at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
| at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
| at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source)
| at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source)
| at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source)
| at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown Source)
| at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
| at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
| at javax.naming.directory.InitialDirContext.search(Unknown Source)
| at org.jboss.security.negotiation.AdvancedLdapLoginModule.findUserDN(AdvancedLdapLoginModule.java:505)
| ... 34 more
|
In the logs I see that I get an Identity
| TRACE [org.jboss.security.negotiation.spnego.AdvancedLdapLoginModule] (http-0.0.0.0-8080-1) Identity - test01(a)BASE.MYCO.COM
|
I am using the nested config:
| <application-policy name="SPNEGO">
| <authentication>
| <login-module code="org.jboss.security.negotiation.spnego.SPNEGOLoginModule" flag="requisite">
| <module-option name="password-stacking">useFirstPass</module-option>
| <module-option name="serverSecurityDomain">host</module-option>
| </login-module>
|
| <login-module code="org.jboss.security.negotiation.spnego.AdvancedLdapLoginModule" flag="required">
| <module-option name="password-stacking">useFirstPass</module-option>
| <module-option name="bindAuthentication">GSSAPI</module-option>
| <module-option name="jaasSecurityDomain">host</module-option>
| <module-option name="java.naming.provider.url">ldap://dc.base.myco.com:389</module-option>
| <module-option name="baseCtxDN">CN=Clients,DC=base,DC=myco,DC=com</module-option>
| <module-option name="baseFilter">(userPrincipalName={0})</module-option>
| <module-option name="roleAttributeID">memberOf</module-option>
| <module-option name="roleAttributeIsDN">true</module-option>
| <module-option name="roleNameAttributeID">cn</module-option>
| <module-option name="recurseRoles">true</module-option>
| </login-module>
| </authentication>
| </application-policy>
|
Anybody see anything wrong? I tried CN=Clients and CN=Users I also left out the CN to do a full search of the entire domain. Still no luck.
Thanks!
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241544#4241544
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241544
16 years, 9 months
[JBoss jBPM] - Asynchronous continuations in Weblogic 10.x using MDB (jBPM
by Clod
After struggling for a few days with asynchronous continuations with the following configuration:
Weblogic 10.3
jBPM 3.3.1.GA
we could finally make them work.
Although we followed configuration instructions from the manual thoroughly, things didn't work as expected. The most weird thing was that the very same configuration worked fine in JBoss 4.2.3.GA. We finally detected that the problem was that the messages sent to JobListenerBean were not being commited. The reason for this is that JBoss and Weblogic handle Non-transacted JMS sessions within a JTA transaction just in the opposite way.
For details please read:
Weblogic
http://e-docs.bea.com/wls/docs103/jms/trans.html#wp1025537
and
JBoss
http://www.odi.ch/prog/jms-tx.php
Unfortunately the kind of session (transacted vs. non-transacted) that jBPM uses is not configurable: it is hardcoded in JmsMessageService.java
| /*
| * If the connection supports XA, the session will always take part in the global transaction.
| * Otherwise the first parameter specifies whether message productions and consumptions
| * are part of a single transaction (TRUE) or performed immediately (FALSE).
| * Messages are never meant to be received before the database transaction commits,
| * hence the transacted is preferable.
| */
| session = connection.createSession(true, Session.SESSION_TRANSACTED);
|
so we had to change that line to:
| session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE) ;
|
Let me emphasize that the change in the first parameter value (true -> false) is NOT meant to achieve different behaviors in both application servers. It's just that they both interpret it in the opposite way. (If you don't trust me read the above links :-) )
Hope that this can save other people's time ;-)
BTW: I don't know if future releases of jBPM are going to deal with asynchronous continuations in the same way, but if they are, it could be good idea to make this behavior configurable.
Best regards,
Claudio
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241543#4241543
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241543
16 years, 9 months