none
Cannot Create Criteria-Based Sets RRS feed

  • Question

  • I cannot create criteria-based sets in either of my FIM Environments.  In production I get a permissions error even though I am a member of the Administrators set.

    In the development environment we get the following detailed error description

    Error processing your request: The operation was rejected because of access control policies.
    Reason: The supplied request content violates system rules.
    Attributes:
    Correlation Id: c949132e-75a0-474c-9534-de4d1154b39b
    Request Id: a7c43448-548b-4fec-a950-fb6c9584596d
    Details: The Request contains changes that violate system constraints.

    I have looked through everything to do with the sets and Attribute Filters and all seem to be in order.  I have seen similar items before, but they were related to SPNs and AppPool permissions, which are not the case here.  Anything that can be done to point me in the correct direction is greatly appreciated.

    Thanks,

    DW


    The early bird gets the worm. The second mouse gets the cheese.

    Monday, June 8, 2015 10:44 PM

Answers

  • One of the general workflows had a couple of AuthN workflows enabled (which should not have been).  After disabling the AuthN workflows (related to password reset) I was able to create sets again.  Posting the answer so that hopefully someone else will figure out to look there.


    The early bird gets the worm. The second mouse gets the cheese.

    • Marked as answer by David K Welch Friday, June 12, 2015 1:40 PM
    Friday, June 12, 2015 1:40 PM

All replies

  • David,

    The criteria you are using for your filter definition........if you are including a custom attribute, did you add it to the administrative filter configuration? This is located under All Resources->Filter Permission->Administrator Filter Permission.

    • Proposed as answer by Nosh Mernacaj Tuesday, June 9, 2015 3:56 PM
    Tuesday, June 9, 2015 3:35 AM
  • In addition to Glenn's question can you provide us with the criteria you are trying to implement ?

    /Peter


    Peter Stapf - ExpertCircle GmbH - My blog: JustIDM.wordpress.com

    Tuesday, June 9, 2015 10:55 AM
  • David,

    The criteria you are using for your filter definition........if you are including a custom attribute, did you add it to the administrative filter configuration? This is located under All Resources->Filter Permission->Administrator Filter Permission.


    All custom attributes have been added to the Administrator Filter Permission.  I am only trying the attribute 'Domain" =customerdomain and  "FirstName" = David in my testing to eliminate custom attribute issues.  Great questions, hope that they get you closer.
    Tuesday, June 9, 2015 1:31 PM
  • If you have done what my colegues suggested,

    You need to update the MPR "Adminsitration: Administrators can real attributes of users" (The name of this MPR may be slightly different, please check the syntax, because I don't have FIM in front of me and I don't remember the exact name.  Basically, this MPR allows administrators to read the attributes of user. Since your attribute is a custom one, most likely is not included in the read access for admins.

    In the attribute list, select the 2 attributes you need. Most likely Firstname is in there, customDomain may not.


    Nosh Mernacaj, Identity Management Specialist



    Tuesday, June 9, 2015 3:06 PM
  • Second, your DEV and PROD are not the same.
    CAREFUL: It is not recommended to have DEV and PROD with different configurations. In case you need to migrate from DEV to PROD.

    Nosh Mernacaj, Identity Management Specialist

    • Proposed as answer by Nosh Mernacaj Tuesday, June 9, 2015 3:56 PM
    • Unproposed as answer by Nosh Mernacaj Tuesday, June 9, 2015 3:56 PM
    Tuesday, June 9, 2015 3:08 PM
  • If you have done what my colegues suggested,

    You need to update the MPR "Adminsitration: Administrators can real attributes of users" (The name of this MPR may be slightly different, please check the syntax, because I don't have FIM in front of me and I don't remember the exact name.  Basically, this MPR allows administrators to read the attributes of user. Since your attribute is a custom one, most likely is not included in the read access for admins.

    In the attribute list, select the 2 attributes you need. Most likely Firstname is in there, customDomain may not.


    Nosh Mernacaj, Identity Management Specialist




    I am not using custom attributes in my filter.  I will check the MPR, because attribute filtering is not the problem.  It will be tomorrow before I get to it.  I will let you know then if the MPR was the issue.  It might be because I am having the same issue in both DEV and PROD. 
    Tuesday, June 9, 2015 4:10 PM
  • Second, your DEV and PROD are not the same.
    CAREFUL: It is not recommended to have DEV and PROD with different configurations. In case you need to migrate from DEV to PROD.

    Nosh Mernacaj, Identity Management Specialist

    I am quite familiar with the proper procedures for migrating policy and schema between DEV and PROD. I assure you that this not the issue because I have what I feel is the exact same issue in both environments.
    Tuesday, June 9, 2015 4:12 PM
  • My bad, Domain is not custom. But I am not sure it is included, though.

    Another thing, please do an IISreset because the filter change may not have applied. (NOTE: This is technically not required, but at times it happens)


    Nosh Mernacaj, Identity Management Specialist

    Tuesday, June 9, 2015 4:12 PM
  • Just occurred to me, You may not have access to create SETS.

    Create a new MPR, where you allow Administrators full access to "All Objects" on all attributes.  That will take care all your issues with access. 


    Nosh Mernacaj, Identity Management Specialist

    Tuesday, June 9, 2015 4:20 PM
  • Just occurred to me, You may not have access to create SETS.

    Create a new MPR, where you allow Administrators full access to "All Objects" on all attributes.  That will take care all your issues with access. 


    Nosh Mernacaj, Identity Management Specialist


    That has already been tried.  :-)

    The early bird gets the worm. The second mouse gets the cheese.

    Tuesday, June 9, 2015 7:44 PM
  • I assume you will try the other suggestions tomorrow then, and I don't see why it will not work anymore if you have done all of the above.

    Nosh Mernacaj, Identity Management Specialist

    Tuesday, June 9, 2015 8:18 PM
  • All suggestions have been tried.  I am going to dig into SharePoint and see if maybe it is the culprit.  I can create sets with manual members only sets with criteria-based members give me this problem.

    The early bird gets the worm. The second mouse gets the cheese.

    Wednesday, June 10, 2015 2:51 PM
  • Did you do any restore recently or had any issues?

    Can you copy the XOML of an existing SET (Criteria based) and apply it to this set.

    I am inclined to say that you have a DB issue.


    Nosh Mernacaj, Identity Management Specialist

    Wednesday, June 10, 2015 4:30 PM
  • Did you do any restore recently or had any issues?

    Can you copy the XOML of an existing SET (Criteria based) and apply it to this set.

    I am inclined to say that you have a DB issue.


    Nosh Mernacaj, Identity Management Specialist


    I tried copying the XOML and applied it.  The operation failed with the same message.  I am inclined to agree that there is a DB issue.  Tracking it down will be a challenge as the SQL Logs are squeaky clean.
    Wednesday, June 10, 2015 5:01 PM
  • 1. I would say, try rebooting (Maybe you have already done so)

    2. Can you check if the DB Permissions are Ok on the service accounts?

    3. Delete and recreate the MPR I mentioned above (Admins have access to all)


    Nosh Mernacaj, Identity Management Specialist

    Wednesday, June 10, 2015 5:20 PM
  • 1. I would say, try rebooting (Maybe you have already done so)

    2. Can you check if the DB Permissions are Ok on the service accounts?

    3. Delete and recreate the MPR I mentioned above (Admins have access to all)


    Nosh Mernacaj, Identity Management Specialist


    Rebooted the portal and SQL Servers, gave the service and app pool accounts dbo privileges.  Recreated MPR.  Same result.  Waiting on the nice folks at Support to call back.  Pretty sure it is a DB issue or maybe something caused by Windows Updates as this was working just fine a few weeks ago.

    The early bird gets the worm. The second mouse gets the cheese.

    Wednesday, June 10, 2015 5:47 PM
  • One of the general workflows had a couple of AuthN workflows enabled (which should not have been).  After disabling the AuthN workflows (related to password reset) I was able to create sets again.  Posting the answer so that hopefully someone else will figure out to look there.


    The early bird gets the worm. The second mouse gets the cheese.

    • Marked as answer by David K Welch Friday, June 12, 2015 1:40 PM
    Friday, June 12, 2015 1:40 PM