Code map refresh - invalid request 641

Hi!

I have a problem with code map refresh. This occurs on all drivers (and yes, they are up and running, nothing shows in the driver traces).

IDM 4.7.1

The main error I see in catalina is:
LDAP: error code 80 - invalid request (-641)]

But I cannot figure out what causes this.

Any ideas to help me is appreciated.


2019-05-02 16:22:31,257 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataModel] (https-jsse-nio-8443-exec-10) [RBPM] VDM.getEntityDefinition(String, Locale):sys-nrf-entitlement
2019-05-02 16:22:31,257 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] VDA.getEntity: cn=useraccount,cn=activedirectory,cn=driverset1,o=system
2019-05-02 16:22:31,258 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] VDA.getLdapAttributes Attributes and values
2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] Attribute ID: modifyTimestamp
2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] 20180419124321Z
2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] Attribute ID: objectClass
2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] Top
2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] DirXML-Entitlement
2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] DirXML-PkgItemAux
2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] Attribute ID: XmlData
2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] <?xml version="1.0" encoding="UTF-8"?><entitlement conflict-resolution="union" description="The User Account entitlement grants or denies an account in Active Directory for the user. When granted, the user is given an enabled logon account. When revoked, the logon account is either disabled or deleted depeding on how the drive is configured." display-name="User Account Entitlement">
<values multi-valued="false">
<query-app>
<query-xml>
<nds dtdversion="2.0">
<input>
<query class-name="ADDomain" scope="subtree">
<search-class class-name="ADDomain"/>
<read-attr attr-name="ADDomainValue"/>
<read-attr attr-name="ADDomainDisplayName"/>
<read-attr attr-name="ADDomainDescription"/>
</query>
</input>
</nds>
</query-xml>
<result-set>
<display-name>
<token-attr attr-name="ADDomainDisplayName"/>
</display-name>
<description>
<token-attr attr-name="ADDomainDescription"/>
</description>
<ent-value>
<token-attr attr-name="ADDomainValue"/>
</ent-value>
</result-set>
</query-app>
</values>
</entitlement>
2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] VDA.checking if object instance contains the required objectClass per DAL definition: sys-nrf-entitlement
2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] VDA.does contain required (search=true or auxilliary=false) objectClass:DirXML-Entitlement
2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] VDA.object instance is correct type
2019-05-02 16:22:31,270 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] VDA.getEntityResultList
2019-05-02 16:22:31,270 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataModel] (https-jsse-nio-8443-exec-10) [RBPM] VDM.getEntityDefinition(String, Locale):sys-nrf-idmresource
2019-05-02 16:22:31,270 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataModel] (https-jsse-nio-8443-exec-10) [RBPM] VDM.getEntityDefinition(String, Locale):sys-nrf-idmresource
2019-05-02 16:22:31,270 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] VDA.getEntityResultList query filter: (
  • On 5/2/2019 10:34 AM, marcus jonsson wrote:
    >
    > Hi!
    >
    > I have a problem with code map refresh. This occurs on all drivers (and
    > yes, they are up and running, nothing shows in the driver traces).
    >
    > IDM 4.7.1
    >
    > The main error I see in catalina is:
    > LDAP: error code 80 - invalid request (-641)]
    >
    > But I cannot figure out what causes this.
    >
    > Any ideas to help me is appreciated.
    >
    >
    > Code:
    > --------------------
    >
    > 2019-05-02 16:22:31,257 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataModel] (https-jsse-nio-8443-exec-10) [RBPM] VDM.getEntityDefinition(String, Locale):sys-nrf-entitlement
    > 2019-05-02 16:22:31,257 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] VDA.getEntity: cn=useraccount,cn=activedirectory,cn=driverset1,o=system
    > 2019-05-02 16:22:31,258 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] VDA.getLdapAttributes Attributes and values
    > 2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] Attribute ID: modifyTimestamp
    > 2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] 20180419124321Z
    > 2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] Attribute ID: objectClass
    > 2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] Top
    > 2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] DirXML-Entitlement
    > 2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] DirXML-PkgItemAux
    > 2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] Attribute ID: XmlData
    > 2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] <?xml version="1.0" encoding="UTF-8"?><entitlement conflict-resolution="union" description="The User Account entitlement grants or denies an account in Active Directory for the user. When granted, the user is given an enabled logon account. When revoked, the logon account is either disabled or deleted depeding on how the drive is configured." display-name="User Account Entitlement">
    > <values multi-valued="false">
    > <query-app>
    > <query-xml>
    > <nds dtdversion="2.0">
    > <input>
    > <query class-name="ADDomain" scope="subtree">
    > <search-class class-name="ADDomain"/>
    > <read-attr attr-name="ADDomainValue"/>
    > <read-attr attr-name="ADDomainDisplayName"/>
    > <read-attr attr-name="ADDomainDescription"/>
    > </query>
    > </input>
    > </nds>
    > </query-xml>
    > <result-set>
    > <display-name>
    > <token-attr attr-name="ADDomainDisplayName"/>
    > </display-name>
    > <description>
    > <token-attr attr-name="ADDomainDescription"/>
    > </description>
    > <ent-value>
    > <token-attr attr-name="ADDomainValue"/>
    > </ent-value>
    > </result-set>
    > </query-app>
    > </values>
    > </entitlement>
    > 2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] VDA.checking if object instance contains the required objectClass per DAL definition: sys-nrf-entitlement
    > 2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] VDA.does contain required (search=true or auxilliary=false) objectClass:DirXML-Entitlement
    > 2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] VDA.object instance is correct type
    > 2019-05-02 16:22:31,270 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] VDA.getEntityResultList
    > 2019-05-02 16:22:31,270 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataModel] (https-jsse-nio-8443-exec-10) [RBPM] VDM.getEntityDefinition(String, Locale):sys-nrf-idmresource
    > 2019-05-02 16:22:31,270 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataModel] (https-jsse-nio-8443-exec-10) [RBPM] VDM.getEntityDefinition(String, Locale):sys-nrf-idmresource
    > 2019-05-02 16:22:31,270 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] VDA.getEntityResultList query filter: (
  • geoffc;2499156 wrote:
    On 5/2/2019 10:34 AM, marcus jonsson wrote:
    >
    > Hi!
    >
    > I have a problem with code map refresh. This occurs on all drivers (and
    > yes, they are up and running, nothing shows in the driver traces).
    >
    > IDM 4.7.1
    >
    > The main error I see in catalina is:
    > LDAP: error code 80 - invalid request (-641)]
    >
    > But I cannot figure out what causes this.
    >
    > Any ideas to help me is appreciated.
    >
    >
    > Code:
    > --------------------
    >
    > 2019-05-02 16:22:31,257 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataModel] (https-jsse-nio-8443-exec-10) [RBPM] VDM.getEntityDefinition(String, Locale):sys-nrf-entitlement
    > 2019-05-02 16:22:31,257 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] VDA.getEntity: cn=useraccount,cn=activedirectory,cn=driverset1,o=system
    > 2019-05-02 16:22:31,258 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] VDA.getLdapAttributes Attributes and values
    > 2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] Attribute ID: modifyTimestamp
    > 2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] 20180419124321Z
    > 2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] Attribute ID: objectClass
    > 2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] Top
    > 2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] DirXML-Entitlement
    > 2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] DirXML-PkgItemAux
    > 2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] Attribute ID: XmlData
    > 2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] <?xml version="1.0" encoding="UTF-8"?><entitlement conflict-resolution="union" description="The User Account entitlement grants or denies an account in Active Directory for the user. When granted, the user is given an enabled logon account. When revoked, the logon account is either disabled or deleted depeding on how the drive is configured." display-name="User Account Entitlement">
    > <values multi-valued="false">
    > <query-app>
    > <query-xml>
    > <nds dtdversion="2.0">
    > <input>
    > <query class-name="ADDomain" scope="subtree">
    > <search-class class-name="ADDomain"/>
    > <read-attr attr-name="ADDomainValue"/>
    > <read-attr attr-name="ADDomainDisplayName"/>
    > <read-attr attr-name="ADDomainDescription"/>
    > </query>
    > </input>
    > </nds>
    > </query-xml>
    > <result-set>
    > <display-name>
    > <token-attr attr-name="ADDomainDisplayName"/>
    > </display-name>
    > <description>
    > <token-attr attr-name="ADDomainDescription"/>
    > </description>
    > <ent-value>
    > <token-attr attr-name="ADDomainValue"/>
    > </ent-value>
    > </result-set>
    > </query-app>
    > </values>
    > </entitlement>
    > 2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] VDA.checking if object instance contains the required objectClass per DAL definition: sys-nrf-entitlement
    > 2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] VDA.does contain required (search=true or auxilliary=false) objectClass:DirXML-Entitlement
    > 2019-05-02 16:22:31,259 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] VDA.object instance is correct type
    > 2019-05-02 16:22:31,270 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] VDA.getEntityResultList
    > 2019-05-02 16:22:31,270 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataModel] (https-jsse-nio-8443-exec-10) [RBPM] VDM.getEntityDefinition(String, Locale):sys-nrf-idmresource
    > 2019-05-02 16:22:31,270 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataModel] (https-jsse-nio-8443-exec-10) [RBPM] VDM.getEntityDefinition(String, Locale):sys-nrf-idmresource
    > 2019-05-02 16:22:31,270 DEBUG [com.novell.srvprv.impl.vdata.model.VirtualDataAccess] (https-jsse-nio-8443-exec-10) [RBPM] VDA.getEntityResultList query filter: (
  • >> (https-jsse-nio-8443-exec-10) [RBPM] VDA.getEntityResultList query
    >> filter:
    >> (
  • geoffc;2499188 wrote:
    >> (https-jsse-nio-8443-exec-10) [RBPM] VDA.getEntityResultList query
    >> filter:
    >> (
  • >> So in the AD trace if it worked, you would see Injecting XDS... and >> then>> the query. Do you have any other entitlements in other
    drivers, and are>> they working?
    > Yes, there are about 15 entitlements in this environment, and 5 of them
    > are actually working. The other has worked before, but I have no clue on
    > what has caused them to stop working.


    so can you see the query for ADDomain in your AD driver? This is the
    User Account entitlement and there is policy to convert it to a
    __driver__identification__ object class response, since we do not really
    need an answer, just any answer and that is harmless.


    15 entitlements in the environment, how about on the AD driver?

    Also, look at your entitlementConfiguration for your AD driver, and see
    if the XML there looks any different from the others. UA queries that
    object to parse the XML to understand the Entitlement Queries it needs
    to submit,



  • geoffc;2499200 wrote:
    >> So in the AD trace if it worked, you would see Injecting XDS... and >> then>> the query. Do you have any other entitlements in other
    drivers, and are>> they working?
    > Yes, there are about 15 entitlements in this environment, and 5 of them
    > are actually working. The other has worked before, but I have no clue on
    > what has caused them to stop working.


    so can you see the query for ADDomain in your AD driver? This is the
    User Account entitlement and there is policy to convert it to a
    __driver__identification__ object class response, since we do not really
    need an answer, just any answer and that is harmless.


    15 entitlements in the environment, how about on the AD driver?

    Also, look at your entitlementConfiguration for your AD driver, and see
    if the XML there looks any different from the others. UA queries that
    object to parse the XML to understand the Entitlement Queries it needs
    to submit,


    Hi!

    No, there is nothing logged in the AD-driver upon code refresh. Nada, zip, zero ;)

    If I had a query that is not working, it would be easy, but there is nothing being sent on the AD-driver.

    AD driver has 5 entitlements, all not working.

    The entitlementConfiguration object is identical to the AD-driver in production where it is working. As I understand it, the entitlementConfiguration object points to the entitlement object, and that object contains the actual query. Both entitlementConfiguration and the entitlement it self is identical to prod.

    Time to open an SR? :(

    Best regards
    Marcus
  • On 5/3/2019 9:56 AM, marcus jonsson wrote:
    >
    > geoffc;2499200 Wrote:
    >>>> So in the AD trace if it worked, you would see Injecting XDS... and
    >>>> then>> the query. Do you have any other entitlements in other

    >> drivers, and are>> they working?
    >>> Yes, there are about 15 entitlements in this environment, and 5 of

    >> them
    >>> are actually working. The other has worked before, but I have no clue

    >> on
    >>> what has caused them to stop working.

    >>
    >> so can you see the query for ADDomain in your AD driver? This is the
    >> User Account entitlement and there is policy to convert it to a
    >> __driver__identification__ object class response, since we do not
    >> really
    >> need an answer, just any answer and that is harmless.
    >>
    >>
    >> 15 entitlements in the environment, how about on the AD driver?
    >>
    >> Also, look at your entitlementConfiguration for your AD driver, and see
    >> if the XML there looks any different from the others. UA queries that
    >> object to parse the XML to understand the Entitlement Queries it needs
    >> to submit,

    >
    > Hi!
    >
    > No, there is nothing logged in the AD-driver upon code refresh. Nada,
    > zip, zero ;)
    >
    > If I had a query that is not working, it would be easy, but there is
    > nothing being sent on the AD-driver.
    >
    > AD driver has 5 entitlements, all not working.
    >
    > The entitlementConfiguration object is identical to the AD-driver in
    > production where it is working. As I understand it, the
    > entitlementConfiguration object points to the entitlement object, and
    > that object contains the actual query. Both entitlementConfiguration and
    > the entitlement it self is identical to prod.


    Post the object XML from entitlementConfiguration for the UserAccount
    entitlement? (Edit out the other 4 but leave the header node).

    Do you have Console2? It has a GUI to inject XDS into a driver via LDAP.
    Be interestsing to try it against AD and a working driver, see if that
    has any issues. I.e. Is it specific to AD shim/driver/policies or not.


  • geoffc;2499203 wrote:
    On 5/3/2019 9:56 AM, marcus jonsson wrote:
    >
    > geoffc;2499200 Wrote:
    >>>> So in the AD trace if it worked, you would see Injecting XDS... and
    >>>> then>> the query. Do you have any other entitlements in other

    >> drivers, and are>> they working?
    >>> Yes, there are about 15 entitlements in this environment, and 5 of

    >> them
    >>> are actually working. The other has worked before, but I have no clue

    >> on
    >>> what has caused them to stop working.

    >>
    >> so can you see the query for ADDomain in your AD driver? This is the
    >> User Account entitlement and there is policy to convert it to a
    >> __driver__identification__ object class response, since we do not
    >> really
    >> need an answer, just any answer and that is harmless.
    >>
    >>
    >> 15 entitlements in the environment, how about on the AD driver?
    >>
    >> Also, look at your entitlementConfiguration for your AD driver, and see
    >> if the XML there looks any different from the others. UA queries that
    >> object to parse the XML to understand the Entitlement Queries it needs
    >> to submit,

    >
    > Hi!
    >
    > No, there is nothing logged in the AD-driver upon code refresh. Nada,
    > zip, zero ;)
    >
    > If I had a query that is not working, it would be easy, but there is
    > nothing being sent on the AD-driver.
    >
    > AD driver has 5 entitlements, all not working.
    >
    > The entitlementConfiguration object is identical to the AD-driver in
    > production where it is working. As I understand it, the
    > entitlementConfiguration object points to the entitlement object, and
    > that object contains the actual query. Both entitlementConfiguration and
    > the entitlement it self is identical to prod.


    Post the object XML from entitlementConfiguration for the UserAccount
    entitlement? (Edit out the other 4 but leave the header node).

    Do you have Console2? It has a GUI to inject XDS into a driver via LDAP.
    Be interestsing to try it against AD and a working driver, see if that
    has any issues. I.e. Is it specific to AD shim/driver/policies or not.


    Hi.

    Sorry for the late response, I was on vacation last week.

    Using C2 and the option to "Submit command to IDM, bypass cache (starts at subscriber command transformation) - direct mode - Driver must be running" and injecting:
    <nds dtdversion="2.0">
    <input>
    <query class-name="ADDomain" scope="subtree">
    <search-class class-name="ADDomain"/>
    <read-attr attr-name="ADDomainValue"/>
    <read-attr attr-name="ADDomainDisplayName"/>
    <read-attr attr-name="ADDomainDescription"/>
    </query>
    </input>
    </nds>


    This works fine, and I can see the query in the driver trace, and I receive the expected output in C2.

    Entitlement object:
    <?xml version="1.0" encoding="UTF-8"?><entitlement-configuration modified="20180504094235">
    <entitlements>
    <entitlement cprs-supported="true" data-collection="false" dn="cn=useraccount,cn=activedirectory,cn=driverset1,o=system" parameter-format="idm4" resource-mapping="true" role-mapping="true">
    <type category="security account" id="user" name="account">
    <display-name>
    <value langCode="de">Benutzer</value>
    <value langCode="en">User</value>
    </display-name>
    </type>
    <parameters>
    <parameter mandatory="true" name="ID" source="read-attr" source-name="ADDomainValue"/>
    </parameters>
    <member-assignment-query>
    <query-xml>
    <nds dtdversion="2.0">
    <input>
    <query class-name="User" scope="subtree">
    <search-class class-name="User"/>
    <read-attr/>
    </query>
    </input>
    </nds>
    </query-xml>
    </member-assignment-query>
    <query-extensions>
    <query-xml>
    <read-attr attr-name="dirxml-uACAccountDisable"/>
    <read-attr attr-name="userPrincipalName"/>
    <read-attr attr-name="sAMAccountName"/>
    <operation-data data-collection-query="true"/>
    </query-xml>
    </query-extensions>
    <account>
    <account-id source="read-attr" source-name="sAMAccountName"/>
    <account-id source="read-attr" source-name="userPrincipalName"/>
    <account-id source="src-dn"/>
    <account-id source="association"/>
    <account-status active="false" inactive="true" source="read-attr" source-name="dirxml-uACAccountDisable"/>
    </account>
    </entitlement>
    </entitlements>
    </entitlement-configuration>


    Best regards
    Marcus
  • >> Do you have Console2? It has a GUI to inject XDS into a driver via
    >> LDAP.
    >> Be interestsing to try it against AD and a working driver, see if that
    >> has any issues. I.e. Is it specific to AD shim/driver/policies or not.

    >
    > Hi.
    >
    > Sorry for the late response, I was on vacation last week.
    >
    > Using C2 and the option to "Submit command to IDM, bypass cache (starts
    > at subscriber command transformation) - direct mode - Driver must be
    > running" and injecting:
    >
    > Code:
    > --------------------
    > <nds dtdversion="2.0">
    > <input>
    > <query class-name="ADDomain" scope="subtree">
    > <search-class class-name="ADDomain"/>
    > <read-attr attr-name="ADDomainValue"/>
    > <read-attr attr-name="ADDomainDisplayName"/>
    > <read-attr attr-name="ADDomainDescription"/>
    > </query>
    > </input>
    > </nds>
    > --------------------



    So in short, directly submitting to the AD shim is working. But alas,
    UA does it with a minor twist, in that it does the submit from the UA
    driver to the AD driver which is a tiny bit different, so I wonder if
    the issue is there.

    Thing is, this is mostly an engine function, not really a Shim JAR
    function.

    Still not sure but this rules out one possibility. Perhaps an SR is in
    order at this point?


    >
    > This works fine, and I can see the query in the driver trace, and I
    > receive the expected output in C2.
    >
    > Entitlement object:
    >
    > Code:
    > --------------------
    > <?xml version="1.0" encoding="UTF-8"?><entitlement-configuration modified="20180504094235">
    > <entitlements>
    > <entitlement cprs-supported="true" data-collection="false" dn="cn=useraccount,cn=activedirectory,cn=driverset1,o=system" parameter-format="idm4" resource-mapping="true" role-mapping="true">
    > <type category="security account" id="user" name="account">
    > <display-name>
    > <value langCode="de">Benutzer</value>
    > <value langCode="en">User</value>
    > </display-name>
    > </type>
    > <parameters>
    > <parameter mandatory="true" name="ID" source="read-attr" source-name="ADDomainValue"/>
    > </parameters>
    > <member-assignment-query>
    > <query-xml>
    > <nds dtdversion="2.0">
    > <input>
    > <query class-name="User" scope="subtree">
    > <search-class class-name="User"/>
    > <read-attr/>
    > </query>
    > </input>
    > </nds>
    > </query-xml>
    > </member-assignment-query>
    > <query-extensions>
    > <query-xml>
    > <read-attr attr-name="dirxml-uACAccountDisable"/>
    > <read-attr attr-name="userPrincipalName"/>
    > <read-attr attr-name="sAMAccountName"/>
    > <operation-data data-collection-query="true"/>
    > </query-xml>
    > </query-extensions>
    > <account>
    > <account-id source="read-attr" source-name="sAMAccountName"/>
    > <account-id source="read-attr" source-name="userPrincipalName"/>
    > <account-id source="src-dn"/>
    > <account-id source="association"/>
    > <account-status active="false" inactive="true" source="read-attr" source-name="dirxml-uACAccountDisable"/>
    > </account>
    > </entitlement>
    > </entitlements>
    > </entitlement-configuration>
    > --------------------
    >
    >
    > Best regards
    > Marcus
    >
    >


  • On 13.05.19 10:26, marcus jonsson wrote:
    >
    > geoffc;2499203 Wrote:
    >> On 5/3/2019 9:56 AM, marcus jonsson wrote:
    >>>
    >>> geoffc;2499200 Wrote:
    >>>>>> So in the AD trace if it worked, you would see Injecting XDS...

    >> and
    >>>>>> then>> the query. Do you have any other entitlements in other
    >>>> drivers, and are>> they working?
    >>>>> Yes, there are about 15 entitlements in this environment, and 5 of
    >>>> them
    >>>>> are actually working. The other has worked before, but I have no

    >> clue
    >>>> on
    >>>>> what has caused them to stop working.
    >>>>
    >>>> so can you see the query for ADDomain in your AD driver? This is

    >> the
    >>>> User Account entitlement and there is policy to convert it to a
    >>>> __driver__identification__ object class response, since we do not
    >>>> really
    >>>> need an answer, just any answer and that is harmless.
    >>>>
    >>>>
    >>>> 15 entitlements in the environment, how about on the AD driver?
    >>>>
    >>>> Also, look at your entitlementConfiguration for your AD driver, and

    >> see
    >>>> if the XML there looks any different from the others. UA queries

    >> that
    >>>> object to parse the XML to understand the Entitlement Queries it

    >> needs
    >>>> to submit,
    >>>
    >>> Hi!
    >>>
    >>> No, there is nothing logged in the AD-driver upon code refresh. Nada,
    >>> zip, zero ;)
    >>>
    >>> If I had a query that is not working, it would be easy, but there is
    >>> nothing being sent on the AD-driver.
    >>>
    >>> AD driver has 5 entitlements, all not working.
    >>>
    >>> The entitlementConfiguration object is identical to the AD-driver in
    >>> production where it is working. As I understand it, the
    >>> entitlementConfiguration object points to the entitlement object, and
    >>> that object contains the actual query. Both entitlementConfiguration

    >> and
    >>> the entitlement it self is identical to prod.

    >>
    >> Post the object XML from entitlementConfiguration for the UserAccount
    >> entitlement? (Edit out the other 4 but leave the header node).
    >>
    >> Do you have Console2? It has a GUI to inject XDS into a driver via
    >> LDAP.
    >> Be interestsing to try it against AD and a working driver, see if that
    >> has any issues. I.e. Is it specific to AD shim/driver/policies or not.

    >
    > Hi.
    >
    > Sorry for the late response, I was on vacation last week.
    >
    > Using C2 and the option to "Submit command to IDM, bypass cache (starts
    > at subscriber command transformation) - direct mode - Driver must be
    > running" and injecting:
    >
    > Code:
    > --------------------
    > <nds dtdversion="2.0">
    > <input>
    > <query class-name="ADDomain" scope="subtree">
    > <search-class class-name="ADDomain"/>
    > <read-attr attr-name="ADDomainValue"/>
    > <read-attr attr-name="ADDomainDisplayName"/>
    > <read-attr attr-name="ADDomainDescription"/>
    > </query>
    > </input>
    > </nds>
    > --------------------
    >
    >
    > This works fine, and I can see the query in the driver trace, and I
    > receive the expected output in C2.
    >
    > Entitlement object:
    >
    > Code:
    > --------------------
    > <?xml version="1.0" encoding="UTF-8"?><entitlement-configuration modified="20180504094235">
    > <entitlements>
    > <entitlement cprs-supported="true" data-collection="false" dn="cn=useraccount,cn=activedirectory,cn=driverset1,o=system" parameter-format="idm4" resource-mapping="true" role-mapping="true">
    > <type category="security account" id="user" name="account">
    > <display-name>
    > <value langCode="de">Benutzer</value>
    > <value langCode="en">User</value>
    > </display-name>
    > </type>
    > <parameters>
    > <parameter mandatory="true" name="ID" source="read-attr" source-name="ADDomainValue"/>
    > </parameters>
    > <member-assignment-query>
    > <query-xml>
    > <nds dtdversion="2.0">
    > <input>
    > <query class-name="User" scope="subtree">
    > <search-class class-name="User"/>
    > <read-attr/>
    > </query>
    > </input>
    > </nds>
    > </query-xml>
    > </member-assignment-query>
    > <query-extensions>
    > <query-xml>
    > <read-attr attr-name="dirxml-uACAccountDisable"/>
    > <read-attr attr-name="userPrincipalName"/>
    > <read-attr attr-name="sAMAccountName"/>
    > <operation-data data-collection-query="true"/>
    > </query-xml>
    > </query-extensions>
    > <account>
    > <account-id source="read-attr" source-name="sAMAccountName"/>
    > <account-id source="read-attr" source-name="userPrincipalName"/>
    > <account-id source="src-dn"/>
    > <account-id source="association"/>
    > <account-status active="false" inactive="true" source="read-attr" source-name="dirxml-uACAccountDisable"/>
    > </account>
    > </entitlement>
    > </entitlements>
    > </entitlement-configuration>
    > --------------------
    >
    >
    > Best regards
    > Marcus
    >
    >


    Hi,

    As far as I remember the following class should give a bit more
    information about this:

    * com.novell.idm.nrf.service


    The -641 is an LDAP error from the injection of the query into the
    driver. Sometimes to see what it going wrong (if it has to do with an
    exception) you need to use ndstrace to see the exact error coming from
    the driver.


    Casper