yuuvis® RAD Q&A

0 votes
by (120 points)

Hi dear OS Team,

we have configured active directory synchronization via ad groups with help of the provided xml-template.
The synchronization works fine - groups as well as accounts and their properties are synchronized correctly.
We also configured the 'dangling' and 'deactivated' objects like so:

  <danglingobjectsparent name="benutzer_inaktiv" />
  <deactivatedobjectsparent name="benutzer_inaktiv" />

Our expectation was, that if AD account is deleted, it'll simply be moved into the 'benutzer_inaktiv' group in yuuvis.

However, if a person's account in AD is deleted, we observe inkonsistent behavior.
Sometimes accounts stay 'active' and 'present', in the system and are moved to the group 'benutzer_inaktiv' (which is kind of what we want)
Sometimes they are marked as 'not active' but 'present' in the system and are moved to the group 'benutzer_inkativ' and the management console displays the message 'No user account available.' This causes some issues with object dependencies in the system.

Could you tell us, what is the designed behavior for deletion of the AD Account?
Can we somehow solve the issue with 'no user account available'?

Thank you!

1 Answer

0 votes
by (18.3k points)

Hi Umar,

if an AD account is deleted the ad-sync operation first checks if this user can be deleted in yuuvis RAD as well. If there are no constraints that make deletion impossible (for example history entries that would otherwise point to an unknown user), i.e. if the user was interacting with the system in a read-only manner, then the user is deleted. If there are such constraints, the user cannot be deleted but will be deactivated and moved to the deactivatedobjectsparent (here "benutzer_inaktiv"). Also the users account is deleted, so that (manual) re-enabling and logging in becomes impossible.
If, due to changes in the AD group structure, a user has no parent group / OU anymore that is part of the synced structure, the user becomes dangling. To prevent it from floating it is moved to the danglingobjectsparent group (which you defined to be "benutzer_inaktiv" as well). In this case the user stays active and present because the user itself was not deleted.

Best regards