Deprovisioning AD Group Assignment fails when setting MX_INACTIVE

Question

Hi,
IdM 7.1 SP5 Patch Level 2
We have an Identity which has some AD Group privileges assigned to it via a role. So these privileges exist as MX_AUTOPRIVILEGE attributes on the identity.
If we remove the role, the privileges are removed and the SAP provisioning framework task DeprovisionADSGroupAssignment works ok.
If we set MX_INACTIVE, de-provisioning is triggered for each repository but the task DeprovisionADSGroupAssignment fails because it cannot determine the DN for the AD groups from the privilege master records.
My analysis so far has deduced the following:
The SAP provisioning framework task DeprovisionADSGroupAssignment uses a javascript sap_getGroupDN to determine the DN value for the ad group. It uses the audit record's UserId field to determine which old_id to read from the MXIV_OENTRIES table. The audit record UserId has the format: e.g. #15:DELETE;0;205081 i.e. attribute 15 on our system is (MX_AUTOPRIVILEGE), the operation is DELETE, the checksum is 0 and the OldValuesId is 205081.
From there the script uses the mskey of the privilege to look up the DN<repository name> attribute on the privilege master. This DN is then used in the To LDAP pass to remove the identity from the AD group.
So unless you actually remove the privileges from the identity, the values don't exist in the MXIV_OENTRIES table and therefore, the script cannot find the mskey for the privilege and therefore cannot get the DN.
Does anyone know if setting MX_INACTIVE is supposed to remove roles and privileges before triggering de-provisioning or how this is designed to work?
Has anyone else de-provisioned AD accounts and groups by just setting MX_INACTIVE?
Edited by: Paul Abrahamson on Dec 3, 2010 5:54 PM

Answer 1

We've now set up a scheduled job to pick up all users which should be made inactive on a given day and this job first removes roles and privileges (triggering de-provisioning of AD groups because the privileges are removed) and then after a while sets the MX_INACTIVE attribute.
Incidentally I also found this [SAP Note 1540835 - LDAP group assignment fails due to ambiguous bchecksum |https://service.sap.com/sap/support/notes/1540835] which 'corrects' some logic in the sap_getGroupDN global script - it now uses context variables instead of reading the MXIV_OENTRIES table etc...