Today I’m working hard in a FIM test lab for a customer. I’m building a proof of concept as it happens. I’m doing several things at once and have been for a couple of hours. I spin up the FIM portal as an administrative user in AD but a normal user in FIM and I get the standard “You do not have permission to access this site” error, which is weird because that same user registered for self-service password reset (SSPR) over the weekend (the real reason I’m accessing the site is to re-register for SSPR because I’ve forgotten my answers J).
I proceed to waste about an hour inspecting various things, e.g. are the MPRs enabled, is the objectSid value still present, etc. and bounce the system for good measure too. What’s perplexing me is the lack of error in the event log so I enable verbose tracing and I’m still getting no error. I skim through the trace log and don’t notice anything glaringly obvious, reproduce the error again and then it happens, light bulb moment. What changes have I made today? None right? One suddenly sticks out. I updated the criteria-filter for the All Active People set. And the person resource I’m using at the moment isn’t really an active person – it’s an administrative user totally outside of the scope of synchronisation.
A quick check of the out of the box MPRs:
- General: Users can read non-administrative configuration resources
- User management: Users can read attributes of their own
And guess what? General: Users can read non-administrative configuration resources is configured with All Active People (not All People) as the principal set. Quandary over, I’m humbly left thinking about change control processes and why documentation is evidently a good thing…
…and how to make up fifty five minutes of lost time…