For users to be able to log in to the MIM portal and authenticate to MIM Service, we need three attributes populated for the user: AccountName, Domain, and ObjectSID.
But even if we have populated these attributes in MIM Service, and a standard user tries to log in to the portal (https://MIMPortal/IdentityManagement), the person will get the message shown in the following screenshot:
Why? Well, because there is no MPR enabled by default to allow users to access MIM Portal and/or MIM Service. The MPRs required to allow access to users are disabled by default. We just need to enable them in order for users to have access.
The MPRs we need to enable are as follows:
- General: Users can read non-administrative configuration resources
- User management: Users can read attributes of their own
Moreover, if you look back, you might recall that we had some options during installation talking about user access as well. There was a checkbox that said Grant Authenticated Users access to the MIM Portal Site. If you forgot to allow that during setup, don't panic. This setting is only to allow SharePoint access, and we can fix this now if we forgot to do so earlier.
If you start MIM Portal as the administrator, you will find Site Actions in the upper-right corner, and from there you can access Site Settings. In Site Settings, below Users and Permissions, you have Site permissions:
Follow that link into Permissions and add Authenticated Users with Read permissions, as shown in the following screenshot:
After fixing the MPRs and verifying that users have SharePoint permissions, the user will be able to access Portal:
Compared to the view that the administrator has, the user's view is quite limited. If the user tries to do something, they will find that they are unable to do anything except look at some of their own attributes. They cannot modify anything, or see any other users. For that to be possible, we need to enable some other MPRs, and maybe configure new ones in order for the user to be able to work in the portal.
Let's walk through the creation of a new MPR allowing managers to read information about their direct reports:
- This MPR is of type Request. If you are going to use MIM for self-service, you will likely end up with quite a few MPRs. Make sure you give them good descriptive names, and also a good description so that it will be easy to understand the purpose just by looking at them in the future:
- You will now start to see the beauty of using MIM to manage users. We can define the Requestor as Relative to Resource. What we are saying is that the Requestor should be the user referenced in the Manager attribute of the user that we try to look at or modify. The Operation in this case is just Read resource, but you can easily see how a similar MPR might allow a manager to modify some attributes as well. Finally, we need to check Grants permission:
- The target resource in this case could be All People, or some other set containing the users we want the managers to see. In this case, we allow the managers to see all the attributes of their direct reports:
- If you want to limit the attributes read by managers in this example, just select Select specific attributes and type (separated by semicolons)—or search and select—attributes in the list of available attributes. Just remember that you will have to update this MPR as soon as there is a new attribute you would like the managers to see:
- The result of this MPR will be that when a manager searches for users in MIM Portal, they will only find themselves and any of their direct reports.
Another typical scenario is that we want users to manage some attributes of their own. This could, for example, be information such as a mobile phone number.
In order for this to work, we need to create a new MPR that gives the users permission to change selected attributes. This MPR is of type Request. If you are going to use MIM for self-service, you will likely end up with quite a few MPRs:
- This time, we set the Requestor as Relative to Resource, based on Resource ID. This is the same as saying self. We want to allow Modify a single-valued attribute. If you are to allow the users in this scenario to manage a multi-value attribute, you will need to also allow both adding and removing a value in multi-valued attributes:
- If you would like, say, only contractors to have this ability, you could set the target to All Contractors rather than All Users. And in this case, when we talk about modifying, we always define the attributes. You should not allow administrators to modify All Attributes:
For some scenarios, you might want to also kick off some workflows as the request is made. It could, for example, be an authorization workflow requesting that the change be approved by a manager before being applied, or maybe an action workflow sending a notification to the user about the change.
- Importing an attribute from the MIM MA (allowing an attribute to be changed using the MIM portal or MIM Service) might cause a problem with Attribute Flow Precedence in the Metaverse. We need to decide how we are going to handle this. In our example, we now have both the MIM Service and the phone system trying to populate the mobile attribute in the Metaverse. If a conflict occurs, we need to decide who will be the winner. Or maybe, we can just decide that the mobile attribute is no longer managed by the phone system, remove the attribute from the inbound flow, and add it to the outbound flow in the Phone system synchronization rule:
The authors suggest avoiding the use of the Use equal precedence setting. Checking that box would mean the last writer wins, meaning multiple systems associated with the attribute can overwrite one another within the Metaverse. From an operational perspective, if you were to use an equal precedence attribute to trigger a workflow, and the systems had different values, you would see the workflow re-trigger every time a synchronization is performed. Microsoft has announced that equal precedence will eventually be removed from the product, so you might as well not use it.