Greetings,
Please open a Service Request for this case. We will be able to work with you and capture different data from your environment.

Sincerely,
Steven Williams
Principal Enterprise Architect
Micro Focus

So that log calls out specific Resources.  WHat I would do is look at those objects in LDAP (Under the UA Driver object, AppConfig. RoleConfig, Request Defs, look for the LDAP object).

Then look at the nrfEntitlementRef.

The value is a Path syntax attribute, in LDAP this looks like dnt#integer#string

The DN is a pointer to the Entitlment object, for whom this resource is being granted.  The integer is usually 0,1,or 2 representing the state.  1 is usually assigned, 0 is revoked.  The string is fun.

It is XML, and inside that, there is a <param> node.  That is now supposed to have JSON.  (So to be clear, it is JSON inside XML, inside an LDAP attribute.  Confused yet?)

I know Steve says open a ticket and maybe that is what is needed, but I think you are running into a probelm with older entitlement values vs newer ones. 

There are two kinds of Entitlement values, (three techincally, but the second is a special caae of the first).

Original entitlements were basically a string value inside the <param> node.

Then when SAP fanout came around, they needed  a way to specify multiple values, with multiple parts. (ie ONe Entitlement granted with a system name, and a value). and now I cannot quite recall if it was 2 parameters or two values whatever.  This was done with a | (pipe) delimiter.

These two cases, are what is known as "legacy".  They are strings, regardless of content.

Then new version, called "idm4" requires it to be JSON.

This works very well.  But has a fundamental flaw that it kind of frustrates me a bit, since it has a problem when you wish to have an entitlement with no values. What is an empty value?  Well in Legacy, blank was allowed as an empty value.

In idm4 mode, it is not, since that is not valid JSON.  And the frustration is that it is not clear, nor simple to set the proper empty value as {} which is a JSON empty string.

So in the end, I expect, that you have nrfEntitlementRef values on nrfResource objects, (or possibly DirXML-EntitlementRef attributes on User objects, the two attributes are identical in values, usually (minus the state, nrfEntitlementRef is copied to the user into DirXML-EntitlementRef when RRSD grants a resource to a user)) where the XML <param> node of the path component is blank, or simply a string...

Fixing this... I will argue that the collector needs to be tolerant of these not being valid JSON and possibly parsing them as strings.  Or if the argument is, bad data should be fixed, not imported bad, then at least the empty string case, should simply be transformed to JSON of {} as close enough and a special case.

Now you might think, ldap query for alll th evalues, do some digging, find all the 'bad' empty values and fix them...

The problem with fixing the data, is two fold.  If the values are assigned, this will cause issues, since on a revoke, I am pretty sure it tries to revoke the current (nrfEntitlementRef) value of the path, changing the 1 to a 0 in the state.  So now it will try and remove a <param>{}</param> inside that XML, instead of what is really there <param/> (or <param></param>) and fail to remove the old entitlement, stranding it on the user.

So it is a bit tricky to get out of this issue.  Oh ya, and you for these reasons the GUI won't let you modify the nrfEntitlementRef on a  Resource after it is created and assigned.  But we can always do it direct in LDAP, so please don't.

Really the proper way is find them all. Create replacement Resources that have the proper values, add to roles using them, let it settle down, remove old resource.  (Depending on what your entitlement processor does for each one you might want to remove the old one and add the new one seperate)