Working on a case where a FIM configuration has moved from development to production.
The customer’s production environment is a highly secured environment with a server security lockdown. The customer is using a custom tool for server profiling and local security lockdown.
After installing and configuring FIM, the FIM portal was loading blank.
The Application Pool account had changed. When adding the Application pool account to the local administrators group, the portal loaded again…
So we needed to investigate what was going wrong.
Some references we got from our Sharepoint colleagues…
Plan for administrative and service accounts (Office SharePoint Server)
http://technet.microsoft.com/en-us/library/cc263445(v=office.12).aspx
How to change service accounts and service account passwords in SharePoint Server 2007 and Windows SharePoint Services 3.0
http://support.microsoft.com/kb/934838/en-us.
They also advised to run a security reset on the SharePoint portal, see: Command-line reference for the SharePoint Products and Technologies Configuration Wizard (Office SharePoint Server)http://technet.microsoft.com/en-us/library/cc263093(v=office.12).aspx
secureresources |
Performs SharePoint Products and Technologies resource security enforcement on the server. For example, security is enforced on files, folders, and registry keys.
Example
|
Although very useful to reset the security, it didn’t change the behaviour on the portal (still loading blank page).
Using procmon (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx), we found out that we had quite some errors.
Just a hint: exclude ‘success’ messages and filter on the targeted application pool account.
We first checked the default WSS group memberships for the AppPoolAccount.
For reference: http://technet.microsoft.com/en-us/library/cc678863(v=office.15).aspx
Just to double check, during troubleshooting we removed the WSS_WPG group from the FIM Portal application pool (default Sharepoint Application pool).
This is the result:
HTTP Error 500.19 – Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.
So that made the situation even worse.
Back to the procmon results, as procmon threw errors on the impersonation of the application pool account we checked the local security policy. And the AppPool account appeared to be removed from the setting or was not member of the groups referenced in the setting.
Solution:
Do not make the Application pool account member of the local admins.
Make sure the Application Pool account has the “Impersonate a client after authentication” right in the local Security Policy.
Need more information? Check these articles …
Account permissions and security settings in SharePoint 2013
http://technet.microsoft.com/en-us/library/cc678863(v=office.15).aspx)
Plan for administrative and service accounts (Office SharePoint Server)
http://technet.microsoft.com/en-us/library/cc263445(v=office.12).aspx
Identity Underground 