(2012-07-18) Misspelled Resource Attribute In MPR In FIM 2010 (R2) May Result In Access Denied
Posted by Jorge on 2012-07-18
When you want to use workflow activities in FIM 2010 (R2) you need to create an ActivityInformationConfiguration object in the FIM portal, copy the DLL to the FIM Service directory and restart IIS and the FIM service.
Normally when creating the object in the Common Attributes tab you would provide a display name and a description.
Figure 1: Creating A New ActivityInformationConfiguration Object – Common Attributes
In the Extended Attributes tab you would provide an activity name, an assembly name and a type name. In addition and that really depends on what your activity does or is used for, you would need to specify if it can be used within an action activity, an authentication activity, an authorization activity and/or if it is a configuration type.
Figure 2: Creating A New ActivityInformationConfiguration Object – Extended Attributes
Now as long as you did not check “Is Authorization Activity” everything would be fine!. However, if you do check “Is Authorization Activity”, you will get an access denied as shown below.
Figure 3: Access Denied When Creating An ActivityInformationConfiguration Object Which Configured As An “Is Authorization Activity”
Basically the screen above is telling you that no MPR exists that gives you permission to commit the transaction into the database. When you write multiple attribute values in one transaction you must have permissions for all attributes being written in that transaction. If you lack permissions for one or more attributes in that transaction, the transaction will fail as it results in an access denied.
Now looking at the request object for this transaction you will see the following.
In the general tab you see some basic high level information like who was doing what at what time and what the result was.
Figure 4: Analyzing A Request Object After An Access Denied – General TAB
In the detailed content tab you see the full transaction being written, in other words the attributes you were writing values into.
Figure 5: Analyzing A Request Object After An Access Denied – Detailed Content TAB
In the applied policy tab you see which MPRs applied, if any, when performing the action.
Figure 6: Analyzing A Request Object After An Access Denied –Applied Content TAB
The analysis here is quite easy, as long as you know where to look!
At a high level, you did something and one or more MPRs applied and the result is access denied. You can now assume that all MPRs that applied do not cover all the attributes in the transaction. How do you know which attribute or attributes? You have to compare the list of attributes as shown in figure 5 with the list of attributes of all MPRs that applied. If NO MPR applied, then you are definitely doing something that’s not allowed! .
For this specific scenario we have to compare the list of attributes as shown in figure 5 with the list of resource attributes of the MPR that applied (“Administration: Administrators control configuration related resources”).
Figure 7: Resource Attributes Of The MPR That Applied
To make it easy to read I copied all the values here:
Description;Display Name;Expiration Time;Activity Name;Applies to Create;Applies to Edit;Applies to View;Assembly Name;Attribute Type;Resource Type;Branding Center Text;Branding Left Image;Branding Right Image;Configuration Data;Constant Value Key;Contact Set;Resource Count;Distribution Group Domain;Domain;Body;Subject;Template Type;Foreign Security Principal Set;Forest Configuration;Image Url;Is Action Activity;Is Authentication Activity;Is Configuration Type;Navigation Page;Navigation Url;Resource Type;Order;Parent Order;Region;Search Scope Filter;Attribute;Attribute Searched;Resource Type;Redirecting URL;String Resources;Supported Language Code;Target Resource Type;Time Zone;Time Zone Id;Trusted Forest;Type Name;Global Cache Duration;Navigation Bar Resource Count Cache Duration;Per User Cache Duration;Usage Keyword;ListView Cache Time Out;ListView Items per Page;ListView Pages to Cache;Request Maximum Active Duration;Request Maximum Canceling Duration;System Throttle Level;Reporting Logging Enabled;Advanced Filter
If you look at the yellow section you will see that the “Is Authorization Activity” attribute is not included/listed. Let’s have a look at the advanced view of the MPR and check that.
Figure 8: Advanced View Of The MPR That Applied – Extended Attributes
If you look at the “Action Parameter” section/attribute and scroll until you see the “IsActionActivity” attribute you will notice the “IsAuthorizationActivity” attribute is listed! So, what’s going on???
LOOK AGAIN! Look at the spelling of “IsAuthorizationActivity”. If you look carefully you will the attributename is missing an “a”. Funny enough, the “IsAuthoriztionActivity” attribute does not exist, but the “IsAuthorizationActivity” does exist. The really easy solution is to type the missing “a” and clicking on OK and SUBMIT afterwards.
Figure 9: Fixing The Misspelling Of The Attribute Name
This is a bug that existed in FIM 2010 and you had to fix this yourself. I recently upgraded my test/demo environment from FIM 2010 to FIM 2010 R2 and I never noticed it, because I already had fixed it in FIM 2010. However, I was working with a brand new FIM 2010 R2 installation and was trying to create an ActivityInformationConfiguration object and got the access denied as explained above.
With FIM 2010 R2 I expected this to be solved as it is a very easy fix. I’m even wondering if any of the hotfixes for FIM 2010 correct this issue. In both cases. apparently not, which is a shame!
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########