Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-12401

DJLDAPv3Repo - insufficient debug logging to troubleshoot membership issues

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 11.0.0, 11.0.1, 11.0.2, 11.0.3, 12.0.0, 12.0.1, 12.0.2, 12.0.3, 12.0.4, 13.0.0, 13.5.0, 13.5.1, 14.0.0, 14.1.0, 14.1.1, 14.5.0, 14.5.1, 5.5.1
    • Fix Version/s: 13.5.3, 6.5.0, 6.0.1, 5.5.2
    • Component/s: idrepo
    • Labels:
    • Target Version/s:
    • Sprint:
      AM Sustaining Sprint 54, AM Sustaining Sprint 55
    • Story Points:
      2
    • Needs backport:
      Yes
    • Support Ticket IDs:
    • Needs QA verification:
      No
    • Functional tests:
      No
    • Are the reproduction steps defined?:
      Yes and I used the same an in the description

      Description

      Bug description

      The search base and used search filter of search operations are not shown in IdRepo debug log. Also the results of the query (at least the DN of entriesor the numbers of entries) are not shown in IdRepo debug logs. This makes it impossible to troubleshoot issues when there is no LDAP access log aivalable, i.g. it's the case when AD is used as user data store.

      How to reproduce the issue

      1. Configure AM
      2. configure AD as user data store
      3. configure 'realm admin privileges' for a group identity subject
      4. authenticate as 'realm admin'
      5. use REST API to query users
      6. use IdRepo debug log to find out why a user is allowed or not allowed to query users.
      Expected behaviour
      helpful debug log statements should be printed out in IdRepo debug logs
      
      Current behaviour

      the following show up in Policy debug log in message level

      AMIndentitySubject.isMember(): entering with userDN = id=sa_admin,ou=user,dc=moneyou,dc=nl
      amPolicy:12/19/2017 01:39:38:784 PM CET: Thread[catalina-exec-13,5,main]: TransactionId[823d375e-7912-4afd-be5f-f01a0cd8131f-2121017]
      AMIndentitySubject.isMember(): checking membership with userDN = SOME_USER_UUID, subjectValue = SOME_GROUP_UUID
      amPolicy:12/19/2017 01:39:38:784 PM CET: Thread[catalina-exec-13,5,main]: TransactionId[823d375e-7912-4afd-be5f-f01a0cd8131f-2121017]
      AMIdentitySubject:isMember():entry for SOME_GROUP_UUID not in subject evaluation cache, so compute using IDRepo api
      amPolicy:12/19/2017 01:39:38:784 PM CET: Thread[catalina-exec-13,5,main]: TransactionId[823d375e-7912-4afd-be5f-f01a0cd8131f-2121017]
      AMidentitySubject.isMember():user uuid = SOME_USER_UUID, subject uuid = SOME_GROUP_UUID
      amPolicy:12/19/2017 01:39:38:785 PM CET: Thread[catalina-exec-13,5,main]: TransactionId[823d375e-7912-4afd-be5f-f01a0cd8131f-2121017]
      AMIdentitySubject.isMember():userIdentity type IdType: user can be a member of subjectIdentityType IdType: group:membership=false
      

      the following is logged into IdRepo debug log in "message" debug level

      DJLDAPv3Repo:12/19/2017 01:39:38:785 PM CET: Thread[catalina-exec-13,5,main]: TransactionId[823d375e-7912-4afd-be5f-f01a0cd8131f-2121017]
      getMemberships called
      

        Attachments

          Activity

            People

            • Assignee:
              lawrence.yarham Lawrence Yarham
              Reporter:
              bthalmayr Bernhard Thalmayr
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: