641 means, you tried a DirXML related action that is 'illegal' or notallowed at this time.

So on the first hand you would expect the AD driver to not be running,which is needed to Inject XDS driver to driver which is how the query isinjected.

Silly question, is your User App driver running? It is injected via theUA driver into the AD driver, and both need to be running. This is oneof the few actual uses of the UA driver in terms of actual 'work'.

641 means, you tried a DirXML related action that is 'illegal' or notallowed at this time.

So on the first hand you would expect the AD driver to not be running,which is needed to Inject XDS driver to driver which is how the query isinjected.

Silly question, is your User App driver running? It is injected via theUA driver into the AD driver, and both need to be running. This is oneof the few actual uses of the UA driver in terms of actual 'work'.

Hi Geoff!

There is no such thing as a silly question 🙂

Yes, User App driver is running and the AD driver is running. I see no activity on User App driver (trace lvl 10) when I try code map refresh (maybe not expected?), and no activity on the AD driver either.

The error does seem to imply an error returned on the LDAP-call, is that routed somehow to the User App driver witch in turn sends the query to the connected system driver (AD driver in this case)?

I also verified that the AD driver is fully up by changing an attribute in IDV and verify in AD, and it is all good.

As this is a test environment I have also tried restarting all services (eDir and Identity Applications) and also clearing out work and temp in Tomcat. Should probably not make a difference, but worth a try.

So in the AD trace if it worked, you would see Injecting XDS... and thenthe query. Do you have any other entitlements in other drivers, and arethey working?

Hi.

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.

Also, this is the test environment, and the same drivers/entitlements are working in production. It is the same version of IDM also.

I have compared between production and test, but I cannot find any odd difference (GCV's and such diffs of course) on the driver level.

I have also verified that Identity Applications is using the same IDVault server as the User App driver is running. It makes no difference if the AD-driver is running on the same server as the User App driver or not.

Re: Code map refresh - invalid request 641

>> So in the AD trace if it worked, you would see Injecting XDS... and >> then>> the query. Do you have any other entitlements in otherdrivers, 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 theUser Account entitlement and there is policy to convert it to a__driver__identification__ object class response, since we do not reallyneed 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 seeif the XML there looks any different from the others. UA queries thatobject to parse the XML to understand the Entitlement Queries it needsto submit,

Re: Code map refresh - invalid request 641

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 otherdrivers, 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 theUser Account entitlement and there is policy to convert it to a__driver__identification__ object class response, since we do not reallyneed 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 seeif the XML there looks any different from the others. UA queries thatobject to parse the XML to understand the Entitlement Queries it needsto 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.

Re: Code map refresh - invalid request 641

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 UserAccountentitlement? (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 thathas any issues. I.e. Is it specific to AD shim/driver/policies or not.

Re: Code map refresh - invalid request 641

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 UserAccountentitlement? (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 thathas 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:

Re: Code map refresh - invalid request 641

>> 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 UAdriver to the AD driver which is a tiny bit different, so I wonder ifthe issue is there.

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

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

Re: Code map refresh - invalid request 641

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 moreinformation about this:

* com.novell.idm.nrf.service

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

Re: Code map refresh - invalid request 641

cpedersen;2499711 wrote: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 moreinformation about this:

* com.novell.idm.nrf.service

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

Re: Code map refresh - invalid request 641

On 14.05.19 11:34, marcus jonsson wrote:>> cpedersen;2499711 Wrote:>> 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>> Hi!>> I managed to get more information using dstrace with DirXML enabled:>> Code:> --------------------> 11:19:42 D99EC700 Drvrs: ENG ET:> DirXML Log Event -------------------> Status: Error> Message: Code(-9137) In invalid timeout period value (20) was found in the wire data for the DirXML sub-verb DSVR_OPEN_DRIVER_ACTION.> 11:19:42 D99EC700 Drvrs: ENG ET:> DirXML Log Event -------------------> Status: Error> Message: Code(-9140) Error processing DirXML sub-verb DSVR_OPEN_DRIVER_ACTION: com.novell.nds.dhutil.DSErr: invalid request (-641)> ***at com.novell.nds.dirxml.engine.verb.OpenDriverAction.processSubVerb(OpenDriverAction.java:97)> ***at com.novell.nds.dirxml.engine.verb.DirXMLVerbs$SetVerbHandler.processVerb(DirXMLVerbs.java:658)> ***at com.novell.nds.dhutil.VerbProcessor$HandlerThread.run(VerbProcessor.java:507)> ***at java.lang.Thread.run(Thread.java:748)> -------------------->>> Question is, what is DSVR_OPEN_DRIVER_ACTION and where is it defined?> And what should it be set to?>> Best regards> Marcus>>

"DSVR_OPEN_DRIVER_ACTION" is the action of sending the operation to theDriver which is done via an LDAPExtended Operation.

"Message: Code(-9137) In invalid timeout period value (20) was found inthe wire data for the DirXML sub-verb DSVR_OPEN_DRIVER_ACTION."

Have you reviewed your timeout settings - it could look like somethingis wrong in that corner?

Re: Code map refresh - invalid request 641

cpedersen;2499719 wrote:On 14.05.19 11:34, marcus jonsson wrote:>> cpedersen;2499711 Wrote:>> 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>> Hi!>> I managed to get more information using dstrace with DirXML enabled:>> Code:> --------------------> 11:19:42 D99EC700 Drvrs: ENG ET:> DirXML Log Event -------------------> Status: Error> Message: Code(-9137) In invalid timeout period value (20) was found in the wire data for the DirXML sub-verb DSVR_OPEN_DRIVER_ACTION.> 11:19:42 D99EC700 Drvrs: ENG ET:> DirXML Log Event -------------------> Status: Error> Message: Code(-9140) Error processing DirXML sub-verb DSVR_OPEN_DRIVER_ACTION: com.novell.nds.dhutil.DSErr: invalid request (-641)> ***at com.novell.nds.dirxml.engine.verb.OpenDriverAction.processSubVerb(OpenDriverAction.java:97)> ***at com.novell.nds.dirxml.engine.verb.DirXMLVerbs$SetVerbHandler.processVerb(DirXMLVerbs.java:658)> ***at com.novell.nds.dhutil.VerbProcessor$HandlerThread.run(VerbProcessor.java:507)> ***at java.lang.Thread.run(Thread.java:748)> -------------------->>> Question is, what is DSVR_OPEN_DRIVER_ACTION and where is it defined?> And what should it be set to?>> Best regards> Marcus>>

"DSVR_OPEN_DRIVER_ACTION" is the action of sending the operation to theDriver which is done via an LDAPExtended Operation.

"Message: Code(-9137) In invalid timeout period value (20) was found inthe wire data for the DirXML sub-verb DSVR_OPEN_DRIVER_ACTION."

Have you reviewed your timeout settings - it could look like somethingis wrong in that corner?

-641 FFFFFD7F INVALID REQUEST <== sometime is wrong with the request.

Casper

Hi Casper.

Yes, probably, but what timeout setting is it I should check? Where can I find it?

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.