We can do it however we want to achieve it. But what I did and worked for me is:
As usual, I am passing a -1 value to the ipaNTSecurityIdentifier attribute in the Create Provisioning Policy form in the first step because it requires for one of objectClasses.
I have created a role that contains a match list. The ipaNTSecurityIdentifier should be -1 (You can add more if you want). Besides this, this role contains a role provisioning policy. I have added the attribute (ipaNTSecurityIdentifier) to pass the value (I have to write a logic to return the value based on our requirement).
So, in the next refresh after aggregation is run, the role will be assigned and the value will also be updated. Later, the schedule aggregation runs, and the ipaNTSecurityIdentifier value will be updated with the actual value, and the role will be unassigned in the next scheduled refresh task. Here is one small workaround we have: once the role is unassinged, whatever the attributes we have in the role provisioning policy form, those values will be removed from the account, which should not happen. So for that, we have to write a snippet code to check if the ipaNTSecurityIdentifier’s remove request, then don’t do that in the before provisioning rule.
