This content has been marked as final. Show 12 replies
I am not 100% sure I understand your question but in general the thing you are looking for is supported as a part of the policy.
There is a setting on the policy that controls if a change to the access policy should be reflected to the users that are currently impacted by the policy. It sounds like you didn't find that check box. Please take another look at the policy definition screens.
Hope this helps
At first,Thanks for your suggestion.
I had run the scheduled tasks just according to your above description,I found that if I added or removed resource from the Access Policy,it would be applyed to the provisioned users in the group. But if I only modified some attribute value(such as department) of the current Resource's process form,there was no change occured, even if the scheduled tasks had been run.But if I modified the attribute value of current Resource's child form,the info would be updated.I don't know why?Maybe the config is different between process form and its child form?
For your information,the resource I mentioned above is OID,and the child form is OID UserGroup.
I'm trying to do exactly the same. My resource is SunOne LDAP server.
I'm trying to include a LDAP user into a LDAP group by access policies. The users already exists in OIM, and all of them have an account in the LDAP server. So, I'm trying ti inlude some of them into an OIM grupo, and then with access policies include their correspondent LDAP acount into one group.
But it does not work.
LDAP groups are configured as in OID or AD resource, in a child table.
Yes, the user is applying the policy (the OIM user is member of the OIM group which fires the policy).
I have no errors in the log. It seems that the Access Policy is doing nothing. Maybe Access Policies does not work with child tables... so it is not possible to provision groups in resources by access policies.
I was surfing metalink, and I've found something that solves my problem
Subject: Access Policy Does not Appear to Fire
Doc ID: 763317.1
My problem was that the child table active version wasn't the same version that the child table configured in the parent form. The steps I've followed are:
1.-Logon to the Design Console as xelsysadm.
2.-Open the Form Designer and open the parent form for this use case.
3.-Click on the Child Tables tab.
4.-Take note of the version number shown for the child entry.
5.-Now open the child form previously listed in the Child Tables tab of the parent form.
6.-Take note of the version of this form that is shown as the active version.
7.-Ensure that the version of the child form listed in the Child Tables tab of the parent form is the current active version of the child.
8.-Retest the issue.
9.-Migrate the solution as appropriate to other environments.
Making both the same version solves the problem.
Thanks a lot!!
Access policies work with child tables, to add users to group or roles in resources.
But, does it work also for modifying resource attibutes? I mean, an access policy that writes a custom value to an attribute, in the resource form. So, this value is written to the resource by the connector.
Is it possible?
I've tryied it in my enviromnent but it does not work. It works for groups, but not for attributes in the resource form (parent form, not child form).