Error loading roles and groups information through Userapp

Hi, I have a couple of errors on the UserApplication when I try to get information on the user dashboard and on the groups pages

Error loading roles dashboard:

When we are trying to load the roles of the user on the dashboard we have this response on the user app:

When we use the dev tools we get this response from the application:

And after that we have another error on the catalina.out.

14:45:47.462 [https-jsse-nio-8543-exec-115] ERROR com.netiq.idm.rest.access.PermissionAssignmentService - [RBPM] Internal exception occurred processing REST service
java.lang.NullPointerException: null
        at com.netiq.idm.rest.access.PermissionAssignmentService.getAllUserPermissions(PermissionAssignmentService.java:2144) ~[IDMAccessRest.jar:?]
        at com.netiq.idm.rest.access.PermissionAssignmentService.getLoggedInUserPermissionAssignmentsBasedOnFilter(PermissionAssignmentService.java:1989) ~[IDMAccessRest.jar:?]
        at sun.reflect.GeneratedMethodAccessor1004.invoke(Unknown Source) ~[?:?]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_342]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_342]
        at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:168) ~[jersey-bundle-1.1.5.jar:1.1.5]
        at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:67) ~[jersey-bundle-1.1.5.jar:1.1.5]
        at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:259) ~[jersey-bundle-1.1.5.jar:1.1.5]
        at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:133) ~[jersey-bundle-1.1.5.jar:1.1.5]
        at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:83) ~[jersey-bundle-1.1.5.jar:1.1.5]
        at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:133) ~[jersey-bundle-1.1.5.jar:1.1.5]
        at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:71) ~[jersey-bundle-1.1.5.jar:1.1.5]
        at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:990) ~[jersey-bundle-1.1.5.jar:1.1.5]
        at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:941) ~[jersey-bundle-1.1.5.jar:1.1.5]
        at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:932) ~[jersey-bundle-1.1.5.jar:1.1.5]
        at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:384) ~[jersey-bundle-1.1.5.jar:1.1.5]
        at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:451) ~[jersey-bundle-1.1.5.jar:1.1.5]
        at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:632) ~[jersey-bundle-1.1.5.jar:1.1.5]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:764) ~[servlet-api.jar:4.0.FR]
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227) ~[catalina.jar:9.0.65]
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162) ~[catalina.jar:9.0.65]
        at com.novell.common.auth.JAASFilter.doFilter(JAASFilter.java:149) ~[IDMfw-bin.jar:?]
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189) ~[catalina.jar:9.0.65]

Error loading groups:

we have a similar problem when we try to load the group list on the user app:

When we use the dev tools we get this response from the application:

And the error in the catalina.out

14:33:51.482 [https-jsse-nio-8543-exec-116] ERROR com.novell.srvprv.impl.vdata.model.VirtualDataAccess - [RBPM] Operation not supported. Compound Indexes not found for the sorting attribute : javax.naming.OperationNotSupportedException: [LDAP: error code 53 - Unwilling To Perform]; remaining name 'ou=System_Groups,o='
javax.naming.OperationNotSupportedException: [LDAP: error code 53 - Unwilling To Perform]
        at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3338) ~[?:1.8.0_342]
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3211) ~[?:1.8.0_342]
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3002) ~[?:1.8.0_342]
        at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1875) ~[?:1.8.0_342]
        at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1798) ~[?:1.8.0_342]
        at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392) ~[?:1.8.0_342]
        at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358) ~[?:1.8.0_342]
        at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:341) ~[?:1.8.0_342]
        at com.novell.srvprv.impl.vdata.model.VirtualDataAccess.getPaggedResultFromVlV(VirtualDataAccess.java:2384) ~[IDMfw-bin.jar:?]
        at com.novell.srvprv.impl.vdata.model.VirtualDataAccess.getPaggedResultlist(VirtualDataAccess.java:711) ~[IDMfw-bin.jar:?]
        at com.novell.srvprv.impl.vdata.model.VirtualDataAccess.getEntityResultList(VirtualDataAccess.java:615) ~[IDMfw-bin.jar:?]
        at com.novell.srvprv.impl.vdata.model.VirtualDataModel.getEntityResultList(VirtualDataModel.java:441) ~[IDMfw-bin.jar:?]
        at com.netiq.idm.rest.access.util.RestUtil.getGroupsFromIDVwithPagination(RestUtil.java:1014) ~[IDMAccessRest.jar:?]

  • 0  

    So the first error is odd.  The function call is just failing and I do not see anything obvious.

    The second error is different. It is telling you that you are missing the Compound INdexes

    They are listed in the docs and are needed for any field that can sort fields. What is interesting is if the Compound index is not there, it is not just slower, it actually fails.

    Compound index is when 2 or more attributes are indexed together. The way an index works in eDir is in a multi part LDAP query, only one predicate (Usually the first) can use a Query.  With a compound index, you can specify the index to use and it queries against the multiple attributes in the index.

  • 0   in reply to   

    Ah found it...

    Enabling Compound Index on Identity Vault Attributes - NetIQ Identity Manager - Administrator’s Guide to the Identity Applications

    0$GnSnIndex$0$0$0$1$Given Name$Surname 
    0$SnGnIndex$0$0$0$1$Surname$Given Name 
    0$CnSnIndex$0$0$0$1$CN$Surname 
    0$TitleSnIndex$0$0$0$1$Title$Surname 
    0$OuSnIndex$0$0$0$1$OU$Surname 
    0$LSnIndex$0$0$0$1$L$Surname 
    0$mailSnIndex$0$0$0$1$Internet EMail Address$Surname 
    0$telephoneNumberSnIndex$0$0$0$1$Telephone Number$Surname

    Make sure you have all of these.  For Groups none of those seem to apply directly.  Those are all user indexes.

  • 0 in reply to   

    Yeah, the first error is very strange, what I can tell is that this seems to be happening only for the uaadmin user, other users can load the dashboard and the permissions page without any issue, I tried to recreate the RBPM but the result was the same.

    In regards of the indexes I can try to check them again tomorrow but all the index that you mentions seems to be included on the eDir and no one of them to me point to a group entry, I also checked the indexes that point to the nrf structure but they are all on the edir replica, Im going to try to check the configured indexes on the testing env to see if I can find anything different but is weird that they only have like 20 groups on the env with the problem.

  • 0   in reply to 

    As for the index issue, watch ndstrace with +LDAP it will tell you if a bind is done with a compound index required.  Then add the missing index, if the error is not itself an error.

  • 0  

    This could be your problem:

    javax.naming.OperationNotSupportedException: [LDAP: error code 53 - Unwilling To Perform]; remaining name 'ou=System_Groups,o='
    javax.naming.OperationNotSupportedException: [LDAP: error code 53 - Unwilling To Perform]

    This is not a valid DN, look at your entitlement on how it is configured and make sure that it has a valid Search Base DN (slash notation).

  • 0 in reply to   

    Ah, the log is edited so does not contain the real DN that we are pointing at, the DN do exist and is a valid DN.

  • 0 in reply to   

    Does the +LDAP option suppose tell you that detail? I tried before that option (Also the +SCHEME) to identity errors with the LDAP scheme like what attribute is not on a class or if an attribute length is to short to fit a long string but dont seems to show that info, on AD or TDS is kinda easy to find the root cause of those problems.

  • 0 in reply to   

    Hi Geoff, I manage to take the ndstrace but the error dont point to any index, in other enviroment I did found that it uses the "CN" index but that index is created on the server

    This is the error log:

    [2024/09/06  9:02:07.886] BIO ctrl called with unknown cmd 7
    [2024/09/06  9:02:07.900] nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
    [2024/09/06  9:02:07.910] nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
    [2024/09/06  9:02:07.927] nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
    [2024/09/06  9:02:07.949] nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
    [2024/09/06  9:02:07.954] nds_back_search: Search Control OID 2.16.840.1.113730.3.4.18
    [2024/09/06  9:02:07.954] nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
    [2024/09/06  9:02:07.954] nds_back_search: Search Control OID 1.2.840.113556.1.4.473
    [2024/09/06  9:02:07.954] nds_back_search: Search Control OID 2.16.840.1.113730.3.4.9
    [2024/09/06  9:02:07.954] nds_back_search: Search Control OID 2.16.840.1.113719.1.27.101.57
    [2024/09/06  9:02:07.957] controlSortSetup: Setting duplicate context for proxy authorization.
    [2024/09/06  9:02:07.959] SearchWithControls: subtree not local -631
    [2024/09/06  9:02:09.882] nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
    [2024/09/06  9:02:09.887] nds_back_search: Search Control OID 2.16.840.1.113730.3.4.18
    [2024/09/06  9:02:09.887] nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
    [2024/09/06  9:02:09.887] nds_back_search: Search Control OID 1.2.840.113556.1.4.473
    [2024/09/06  9:02:09.887] nds_back_search: Search Control OID 2.16.840.1.113730.3.4.9
    [2024/09/06  9:02:09.889] controlSortSetup: Setting duplicate context for proxy authorization.
    [2024/09/06  9:02:09.890] SearchWithControls: subtree not local -631
  • 0   in reply to 

    You need to go to the LDAP Server object and in tracing enable all the options.  Even Hex Dump but it won't actually do that.  The flags are re-interpreted to basically be detailed or not.  Enable all to get detailed and try again.

    PS: Subtree not local probably means replicas here do not contain the OU being searched for.

  • 0 in reply to   

    Hi Geoff, I tried that but the error was the same did not have more details than that, I also checked all the replicas status with the ndsrepair and everything seems ok, a direct connection through ldap browser shows the entries with out problem on every node.