We have installed the FIM 2010 on our Windows 2008 R2 Server. The server acts as the Domain Controller as well. We have created the Inbound Sync Rules for AD MA as well as the FIM MA. We have created a domain user in the AD and when we try to login to the FIM Portal we get an error that the "You do not have permission to make this request". We have not created any seperate account for the FIM MA we use the administrator account for every thing. In the Logs on the Server I get the error "GetCurrentUserFromSecurityIdentifier:No Such UserCan any one help how I can overcome this error

In order for a user to access the portal it must exist within the FIM DB so you'll have to sync users from AD to FIM. When the users are in place you must give the user rights using MPR's. //henrik Henrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se)

Thanks for the reply .As per my understanding the FIM database as well as the Sync Database is the same thing , pls correct me if I am wrong. When we try to sync the AD with the FIM , then we don't see the user in the FIM. Could the inbound AD Sync Rule be incorrectly configured.

The FIM DB is not the same as the Sync DB, you'll have to create rules for getting your users into Sync DB and then into FIM DB. I recommend you to read the getting started documents to get more understanding of the product.Henrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se)

I have referred the document earlier and configured as mentioned , however we are able to see the user in the Sync DB but not into FIM DB.I will recheck once again.

Have you made an export to the FIM DB using FIM MA and have you ticked the "Create Resource in FIM" checkbox? //HenrikHenrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se)

Can you guide how I can check this.

Hi...This text was cutted from InstallationGuide.docx FIM Portal Access Every user who accesses the FIM Portal must have an Account in Active Directory and a resource in the FIM Service database with the ObjectSID, Domain, and Accountname attributes representing the user in Active Directory. Also you must enable two MPRs as administrator: General people can read non-administration configuration objects User Management: User cas read attributes of their owntext from Introducion to configuring the FIM Portal.docx Permission Required for a User to See the Basic Portal Administrator needs to enable two Management Policy Rules (MPRs) to grant an end user permission to view the portal in addition to the steps outlined in the Install Guide section FIM Portal Access. This is a one-time task. For more information about MPRs and how to use it to grant permission to resources please see Introduction to Management Policy Rules document. To enable the User management: Users can read attributes of their own and General: Users can read non-administrative configuration resources MPRs 1. Log on to the FIM Portal as Administrator. 2. On the Navigation Bar, click Management Policy Rules. 3. On the Management Policy Rules page, enter User management in the search box and click search icon. 4. In the results page from above search, click User management: Users can read attributes of their own. 5. In the General tab, make sure to uncheck Disabled. 6. Click OK, then click Submit. Repeat these steps for the General: Users can read non-administrative configuration resources MPR. Notes The User management: Users can read attributes of their own MPR gives the end user rights to read their own attributes. An end user needs this rule to grant them permission to read attributes that are important for their authentication. Attributes such as Domain and AccountName are important for them to see FIM Portal functionalities. The General: Users can read non-administrative configuration resources MPR gives the end user rights to see basic Portal configurations mentioned in this document. If these rights are not granted, when the attempts to view the configurations they will see an empty Portal with no content. I hope I've helpedPaulo H. Campos

I've run into the same error you're seeing for my personal account, and it's added to the Administrators set so the MPR updates don't apply here. The root cause of the problem is your portal object does not the ObjectSID populated with the ObjectSID of the AD user.In RC1 the requirements for logging into the portal changed from matching the domain\accountname values to actually matching on the SID.Now, since you own all attribute flow with the FIM MA, I'm not entirely clear how this would ever get populated without direct flows for this value - and yet I have objects in the portal that somehow have ObjectSID populated (shows up as Resource SID in Advanced View/Extended Attributes). You can't easily set this value manually either, so what I did to work around this issue is the following:ADDS MA: cs:objectsid -> mv:objectsidFIM MA: cs:objectsid <- mv:objectsidChange the precedence on this attribute to be your ADDS MA and then Full Sync your ADDS MA - this should contribute the SID into the portal and allow you and your users to logon. This worked for me, but I don't know if this is how it's supposed to work or if there is another mechanism that is supposed to do this automatically - as I indicated, somehow this populated for some of my users but not others.I currently do not have an Inbound Sync Rule from AD which may be the cause of this, but I haven't experimented with adding one to see if it resolves it.Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com

HiI had the same experience when I followed the documentation. After I installing the portal the second time I reviewed the sync steps in more detail and I found out that the SID of the administrator is synced to the metaverse in the first step and the while pushingback the values from the metaverse to the portal the SID is deleted in the portal database. This is why your admin accountcannot logon anymore.I fixed it in my case by joining first to the AD administrator account. After this step, a SID value isstored in the metaverse and no empty SID sync will occure into the portal.My recommendation is to review your exports to the portal and keep an eye on the SID attribute of your admin account.Henry

This worked for me, but I don't know if this is how it's supposed to work or if there is another mechanism that is supposed to do this automatically - as I indicated, somehow this populated for some of my users but not others. The only SID attributes that are auto-populated should be for accounts specified at setup. For example, the admin account and the sync account. All other SIDs should be flowed in as Brad described using the sync engine.

This is all correct.There is no need to modify the flow precedence as long as there is no inbound flow on the FIM MA.Please see the Introduction to User and Group Management for more details.Cheers,MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Every user who accesses the FIM Portal must have an Account in Active Directory and a resource in the FIM Service database with the ObjectSID, Domain, and Accountname attributes representing the user in Active Directory. Does it mean that we can create another class (we do not want to use the predefined user class, but create another one), add these three attributes to our new class, modify the MPR accordingly to allow to read the own resource and afterwards the user may login too?

bump up to msft? this is a very good question.Anu

My understanding is that this doesn't work, the person accessing the portal must have an object of type 'person' in the portal. I haven't tried this myself but have heard of other attempts for this. If you need definitive answer, you could open case with PSS.

that's absolutely true. save one PSS ticket :) only Person objects are login-able

that's absolutely true. save one PSS ticket :) only Person objects are login-able

Thanks Glenn and nTony.Anu