This topic has 13 replies, 5 voices, and was last updated 6 years, 1 month ago by [email protected].
-
AuthorPosts
-
June 23, 2016 at 12:38 pm #11522
[email protected]
ParticipantHi,
In managedUser_sourceLdapopendjAccount mapping, I have mapped accounStatus(source) to disabled(target) attribute.
The use case is, when user account is disabled in OpenIDM, it should be disabled from OpenDJ as well.
But this doesn’t work. The value for disabled is blank.Since accountStatus holds values like ‘active’ and ‘inactive’ and disabled is a boolean field, I wrote a transform script:
if ( source == 'inactive') { true; } else { false; }
But this doesn’t seem to work.
Can anyone help?Regards,
AshwiniJune 23, 2016 at 2:13 pm #11525Bill Nelson
Participant“source” is an object that contains all attributes – of which the accountStatus is just one. Depending on the object you are using (I assume it is managed/user) then you probably have others like mail, sn, sn, or other. You need to specify the attribute you are referring to in your comparison (such as source.cn). You should also use the exact match operator (“===”) instead of the “==” when making string comparisons.
June 23, 2016 at 2:40 pm #11526[email protected]
ParticipantHi Bill,
I have selected the source as accountStatus and not complete user object. So the source would be accountStatus right?
We get all other attributes like mail, sn, givenName only when we select the complete user object.June 23, 2016 at 4:04 pm #11527Bill Nelson
ParticipantNot knowing how you are implementing this I would give something like source.accountStatus a try.
June 24, 2016 at 6:57 am #11545[email protected]
ParticipantI tried using the following code:
if ( source.accountStatus === 'inactive' ) { true; } else { false; }
It still doesn’t work.
Ideally ‘ds-pwp-account-disabled’ field should be set to true in OpenDJ.Am I missing something here?
Regards,
AshwiniJune 24, 2016 at 10:17 am #11558[email protected]
ParticipantYou can always use logging to examine the source-object you are referring to.
Something along the lines of “logger.error(“this is source: {}”,source);” should be easy to spot in openidm.logJune 24, 2016 at 10:28 am #11559[email protected]
Participantlogger.error(“this is source: {}”,source); prints ‘inactive’ in the logs.
It goes inside the if statement, but in OpenDJ true value is not set in ds-pwp-account-disabled attribute.
This is what I get in the logs:
Method: update
org.identityconnectors.framework.common.exceptions.InvalidAttributeValueException-
This reply was modified 6 years, 1 month ago by
[email protected].
June 24, 2016 at 11:39 am #11561[email protected]
ParticipantSo using “source” instead of source.accountStatus is correct.
Ignore the mapping for a moment and read the system object directly via system/opendj/account….
does it report ds-pwp-account-disabled? Can you modify it by modifying the system object?June 24, 2016 at 5:01 pm #11569bgallantfr
ParticipantYou can also check the logs for clues during reconciliation.
I gave it a quick try and used the following transform for accountStatus(source) and disabled(target):
if ( source === 'inactive' ) { true; } else { ; }
I got an error message when trying “Single Record Reconciliation” (which is an easy way to test reconciliation using one entry):
Attribute value conflicts with the attribute’s schema definition on operation UPDATE for system object:…
accountStatus
is a string in the user managed object and thedisabled
property in the connector is a boolean. At least it is in my lab.I’m not sure what the right solution is for your use case, but at least you now have another avenue to pursue.
June 26, 2016 at 8:15 am #11581[email protected]
ParticipantHi bgallantfr,
Since the disabled attribute is boolean, I had to write the transform script.
I tried your approach as well, but still no luck.
The disabled attribute gets a value of either true or false through this script. But it is not updated in OpenDJ due to schema violation.
I also tried returning 1 instead of true and 0 instead of false considering the boolean values, but no luck.June 27, 2016 at 3:35 pm #11598[email protected]
ParticipantYou try fiddling around with the mapping to solve you issue. I consider it to be quite unlikely, perhaps technically impossible, to solve your issue that way.
For the mapping to work, the configuration of the provisioner has to be correct, for the provisioner to work, the proxy-accounts needs the correct capabilities, etc.
Can you perform the modification using LDAP and the proxy-account you configured in OpenIDM?
What is the LDAP-schema of the attribute?If you succeed using LDAP:
what’s the mapping in provisioner.openicf-opendj.json for the specific attribute? Does it conform to the LDAP-schema?
Can you toggle the attribute using REST-calls at system/opendj/….?Check your mapping only after checking all those preconditions.
June 29, 2016 at 8:41 am #11701[email protected]
ParticipantWhat all operators are allowed in the transform script apart from ===?
Can we use something like string.includes() or string.contains()?June 29, 2016 at 12:39 pm #11713migel
ParticipantHi.
I have been trying disabled users with the same attribute ‘ds-pwp-account-disabled’ but OpenIDM can handle it delete it but never merge or replace. I think was a bug.
June 29, 2016 at 12:49 pm #11714[email protected]
ParticipantYes this seems to be a bug. Confirmed this with Forgerock.
The disable functionality is not supported by the DJ LDAP connector -
This reply was modified 6 years, 1 month ago by
-
AuthorPosts
You must be logged in to reply to this topic.