Uploaded image for project: 'Grouper'
  1. Grouper
  2. GRP-392

JNDISourceAdapter errors when handling certain types of LDAP attribute values

    XMLWordPrintable

Details

    • Bug
    • Resolution: Unresolved
    • Minor
    • None
    • None
    • subject API
    • None

    Description

      > According to one of its former developers, the issue appears to be a bug in the JNDISourceAdapter. Essentially, there's something about how it uses JNDI to deal with encrypted values such as userPassword that is buggy.
      >
      > Lutz, although it's probably best practice to use <attribute> statements in a production system anyway, I wonder if another way to cure the problem is to change the ACL on the ldap server so that it doesn't allow READ of the userPassword attribute for the DN in the sources.xml file.
      Tom, you are right !

      I checked it out by removing all attribute-elements from the source.xml and changing the ACL of the admin-DN for userPassword from "write" to "auth" in the /etc/slapd.conf. Everything was working as expected.
      Turning back by resetting the userPassword-ACL to "write", the formerly observed "Error" occures again.

      So, it appears that's really a JNDI-bug handling encrypted values.

      Lutz

      >
      > Tom
      >
      > Lutz has
      >
      > Lutz Suhrbier wrote:
      >> Hello,
      >>
      >> meanwhile, I found a solution to that error.
      >> Within the sources.xml, I have had to include at least those LDAP elements within "attribute" elements, which are requested in the subject, subjectId and description items of the source. If not, then the error described in my last posting (see below) occures.
      >>
      >> As the wiki documentation states, that NOT including "attribute" elements just leads to requesting all available attributes from the given LDAP-source, this would mean that there is a bug in the implementation, or not ?
      >> Or, is it a feature of the implementation, since looking through the documentation, I did not found a hint that Grouper-UI can be configured somewhere else as in sources.xml to define those attributes from the sources, which shall be presented to the user in the UI ?
      >>
      >> best regards
      >> Lutz
      >>
      >>
      >>> Hi,
      >>>
      >>> I configured grouper to use LDAP as source for member.
      >>> Meanwhile, I can search for members, and I get a complete list of their names when searching for "*"
      >>>
      >>> Now, when I am clicking any item on that list, I only get an error page. Also, when logging in, then instead of the login name, I see only "Error", but, as I configured a wheel group, I can change between myself and the admin role.
      >>>
      >>> I get the following in grouper-ui.log:
      >>> 2008-11-07 01:40:50,396 ERROR actions.GrouperCapableAction: < l.suhrbier A4D166A577715C4EDA80085103C1F6DA-0055 ec
      >>> 33e9bc-c490-469b-964a-a56aa10548d2 l.suhrbier edit-dev > java.lang.ClassCastException: [B
      >>> at edu.internet2.middleware.subject.provider.JNDISourceAdapter.loadAttributes(Unknown Source)
      >>> at edu.internet2.middleware.subject.provider.JNDISubject.getAttributes(Unknown Source)
      >>> at edu.internet2.middleware.grouper.ui.actions.PopulateSubjectSummaryAction.grouperExecute(PopulateSubjec
      >>> tSummaryAction.java:362)
      >>> at edu.internet2.middleware.grouper.ui.actions.GrouperCapableAction$1.callback(GrouperCapableAction.java:
      >>> 206)
      >>> at edu.internet2.middleware.grouper.internal.dao.hib3.Hib3TransactionDAO$1.callback(Hib3TransactionDAO.ja
      >>> va:46)
      >>> at edu.internet2.middleware.grouper.hibernate.HibernateSession.callbackHibernateSession(HibernateSession.
      >>> java:211)
      >>> at edu.internet2.middleware.grouper.internal.dao.hib3.Hib3TransactionDAO.transactionCallback(Hib3Transact
      >>> ionDAO.java:39)
      >>> at edu.internet2.middleware.grouper.hibernate.GrouperTransaction.callbackGrouperTransaction(GrouperTransa
      >>> ction.java:54)
      >>> at edu.internet2.middleware.grouper.hibernate.GrouperTransaction.callbackGrouperTransaction(GrouperTransa
      >>> ction.java:73)
      >>> at edu.internet2.middleware.grouper.ui.actions.GrouperCapableAction.grouperTransactionExecute(GrouperCapa
      >>> bleAction.java:203)
      >>> at edu.internet2.middleware.grouper.ui.actions.GrouperCapableAction.execute(GrouperCapableAction.java:258
      >>> )
      >>> at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:421)
      >>> at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:226)
      >>> at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
      >>> at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:397)
      >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
      >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
      >>> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
      >>> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
      >>> at edu.internet2.middleware.grouper.ui.LoginCheckFilter.doFilter(LoginCheckFilter.java:148)
      >>> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
      >>> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
      >>> at edu.internet2.middleware.grouper.ui.ErrorFilter.doFilter(ErrorFilter.java:134)
      >>> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
      >>> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
      >>> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:204)
      >>> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
      >>> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
      >>> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
      >>> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
      >>> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
      >>> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
      >>> at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:199)
      >>> at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282)
      >>> at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
      >>> at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
      >>> at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
      >>>
      >>>
      >>> I already set ACL in my slapd.conf to allow write access to everybody. So, I guess, that LDAP access rights could not be the cause, why attributes are not loaded.
      >>> Does the LDAP Dir has to provide any specific attributes for members (besides those I defined in sources.xml), which perhaps I do not offer ?
      >>>
      >>> Does anybody any hint what could cause that error ?
      >>>
      >>> Thanks
      >>> Lutz

      Attachments

        Activity

          People

            tom.barton.2@at.internet2.edu Tom Barton (internet2.edu)
            tom.barton.2@at.internet2.edu Tom Barton (internet2.edu)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated: