• State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 94 subscribers
  • Views 4959 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

LDAP provisioning: "discarded due to an invalid combination of attribute and object class"

sayed.ashhad
over 6 years ago

Hi

 

I am getting this error in a RACF sync project when trying to update racfAddressLine1, racfAddressLine2 and racfAddressLine3 attributes. The error also appears if I try to make the change in Target System Browser and hit save.

If I log into an LDAP browser using the exact same credentials, and go to the user object to be updated, I cannot see these attributes but if I add a new attribute for racfAddressLine1 and populate it, then hit save, it saves.

And if I then attempt the sync again, those attributes do get populated - but only for that one row. The next account in the sync also needs these attributes refreshed but it throws the same error.

What could be causing this?

Thanks in advance

  • 0 over 6 years ago
    Hi

    I am still having this issue (error code 1777004) and cannot find any resources in any documentation that explains the error "the update for attribute <text attribute> has been discarded due to an invalid combination of attribute and object class".

    I cannot update any attribute from any LDAPAccount object on the target system side onto its corresponding RACFUSER account without this error being thrown.

    If I simulate it, everything checks out. If I execute the sync workflow into One Identity Manager, that works too. The project verifies OK.

    This is for a workflow step that has a mapping which only covers specific FREE TEXT attributes we want to update inside RACF - it's not updating the object classes, MVPs or RACF managed attributes.

    Object matching rules are firing correctly and consistently so it's something to do with the UPDATE method I think.

    Thanks
  • +1 over 6 years ago

    Hi,

    The error message you are getting is my fault!!!! It used to be the case that if you attempted an update on an attribute that was not part of the current objectclass combination, your update would succeed but actually fail silently!

    So I asked the developer to throw this error in those circumstances so that you at least had a chance of knowing that an error had occurred.

    In short, you have to ensure that the attribute you are updating is part of the objectclass heirarchy you have defined on the object (in 1IM and 'to' the TS). If it's not, you'll get this error.

    Now the bit I can't 100% remember is the correct mapping configuration in this scenario so you'll have to experiment I'm afraid ...... I think you just need objectclass from LHS mapped to objectclass on RHS with direction 'to' target system. As well as your other mapping(s).

    HTH, Barry.

  • +1 over 6 years ago
    Hi,

    I just tried this out and got exactly the same error as you!

    I created a mapping for LDAPAccount.DestinationIndicator (Location ID) to racfBuilding.

    I set a value in Manager, hit save, the provision job fired and froze …… so ……

    Looking here: support.oneidentity.com/.../9

    We can see that racfBuilding is part of the auxiliary class racfWorkAttrSegment. After the sync, my LDAPAccount(s) have these objectclasses:

    TOP;RACFBASECOMMON;RACFUSER;SAFTSOSEGMENT

    So if I edit the OBJECTCLASS and add RACFWORKATTRSEGMENT and then update the DestinationIndicator (Location ID) field ….. the provision works!!!

    Because I now have a valid attribute/objectclass combination.

    The appendices in the 1IM doc tell you all the attribute/objectclass combinations.

    The moral of the story is that just because you see the attribute on the RHS in the TS schema ….. it doesn’t mean you can just use it ….. you have to make sure you have the associated objectclass for the attribute(s).

    HTH, Barry.
  • 0 over 6 years ago
    Fantastic! Thanks so much for that.

    I imagine this safeguard in the code could get quite complicated to manage if a customer's provisioning project needs optional attributes from several auxiliary classes to be included in the provisioning.

    So do I just need a read-only script property on the OI side to append racfWorkAttrSegment to objectclass if it's not already in the list, like this perhaps -

    if ($SeeAlso$<>"") AND NOT ( $objectClass$.Contains("racfWorkAttrSegment"))
    Then
    return $objectClass$.concat(("racfWorkAttrSegment"c))
  • 0 over 6 years ago
    Hi,

    As an update I did get this to work eventually, by setting up a two step sync process one which parses the attributes from a memo field into their respective OI fields and another which provisions those attributes back into the target system subject to a sanity check that the auxiliary object class is already contained in ObjectClass on the target system side. If the ObjectClass does not have that value, then we add it, and populate the auxiliary attributes on the next sync run.

    Since the fields we are provisioning are not used by the customer (they're only used by IAM), their values will only change as a consequence of OI write. The use case is, eventually the customer will need to move away from having a single unstructured memo attribute containing personnel number,

    There is one remaining glitch but it isn't related to this issue, and I think it's covered by a hot fix.

    (Target System Browser can see all objects of objectclass=racfuser and objectclass=racfgroup in all containers in the directory tree, but retrievals of objectclass=racfresource only sees resource objects in the first container).