Return to Table of Contents of this article series
↑ Back to top
Although FIM and MIM heavily rely on SQL Server, SQL security configuration is out of scope for FIM configuration. Nevertheless, proper configuration of these accounts is key and it should be handled in cooperation with an SQL expert.
Please check the reference below to properly secure your SQL infrastructure you use to support FIM.
The Section “Service Account selection and management”, says:
"/../The Local System account is not only an account with too many privileges, but it is a shared account and might be used by other services on the same server. Any other service that uses this account has the same set up privileges as the SQL Server service that uses the account.
Although Network Service has network access and is not a Windows superuser account, it is a shareable account. This account is useable as a SQL Server service account only if you can ensure that no other services that use this account are installed on the server.
Using a local user or domain user that is not a Windows administrator is the best choice.
If the server that is running SQL Server is part of a domain and must access domain resources such as file shares or uses linked server connections to other computers running SQL Server, a domain account is the best choice.
If the server is not part of a domain (for example, a server running in the perimeter network (also known as the DMZ) in a Web application) or does not need to access domain resources, a local user that is not a Windows administrator is preferred.
Creating the user account that will be used as a SQL Server service account is easier in SQL Server 2005 than in previous versions. When SQL Server 2005 is installed, a Windows group is created for each SQL Server service, and the service account is placed in the appropriate group. To create a user that will serve as a SQL Server service account, simply create an "ordinary" account that is either a member of the Users group (non-domain user) or Domain Users group (domain user). During installation, the user is automatically placed in the SQL Server service group and the group is granted exactly the privileges that are needed.
If the service account needs additional privileges, the privilege should be granted to the appropriate Windows group, rather than granted directly to the service user account. This is consistent with the way access control lists are best managed in Windows in general. /../"
The FIM 2010 deployment guide also discusses the SQL security requirements.
Source: [12.] Before You Begin
Before you install the FIM Service, certain tasks should be completed and verified on the server that is running SQL Server.
If you are using FIM Reporting, you will need to create two additional service accounts:
Ensure that the service accounts used by SQL Server Database and SQL Server Agent are either domain accounts or built-in service accounts (for example, Network Service). You cannot use local computer accounts.
When you configure the service accounts for SQL Server, consult the following articles:
Please check full details in the reference below to properly secure your IIS infrastructure you use to support FIM.
Please find below a list of configuration items relevant to FIM, but do remember the complete list has more actions to achieve an IIS lock down.
Separate different applications into different sites with different application pools.
Implement the principle of least privilege.
Run your worker process as a low privileged identity (virtual application pool identity) that is unique per site.
For maximum security, application pools should run under the application pool identity that is generated when the application pool is created. The accounts that are built in to IIS are ApplicationPoolIdentity, NetworkService, LocalService, and LocalSystem. The default (recommended) and most secure is ApplicationPoolIdentity.
Reference:
Essentially the SharePoint configuration is out-of-scope for this document, but proper configuration of the SharePoint environment is essential. Please work with a SharePoint expert to secure your environment.
This section only has informational purposes, but has been added as a reminder to secure the FIM Portal back-end services.
Please check the reference below to properly secure your SQL infrastructure you use to support FIM.7
The SQL Server service account is used to run SQL Server. It is the service account for the following SQL Server services:
If you do not use the default SQL Server instance, in the Windows Services console, these services will be shown as the following:
Use either a Local System account or a domain user account.
If you plan to back up to or restore from an external resource, permissions to the external resource must be granted to the appropriate account. If you use a domain user account for the SQL Server service account, grant permissions to that domain user account. However, if you use the Network Service or the Local System account, grant permissions to the external resource to the machine account (domain_name\SQL_hostname$).
The instance name is arbitrary and was created when Microsoft SQL Server was installed.
Setup user account
The Setup user account is used to run the following:
If you run Windows PowerShell cmdlets that affect a database, this account must be a member of the db_owner fixed database role for the database.
Additional permissions are automatically granted for the server farm account on Web servers and application servers that are joined to a server farm.
The server farm account is automatically added as a SQL Server login on the computer that runs SQL Server. The account is added to the following SQL Server security roles:
Please check the reference below to properly secure the require SPN entries.
Please refer to the references section at the end of the guide, for more details on Kerberos settings.
From: [16.] FIM 2010 R2 Kerberos Settings (SPN Configuration):
”/../ Service principal names (SPNs) are unique identifiers for services running on servers. Every service that uses Kerberos authentication needs to have an SPN set for it so that clients can identify the service on the network. If an SPN is not set for a service, clients have no way of locating that service. Without correctly set SPNs, Kerberos authentication is not possible.
An SPN is registered in Active Directory under a user account as an attribute called Service-Principal-Name. The SPN is assigned to the account under which the service the SPN identifies is running. Any service can look up the SPN for another service. When a service wants to authenticate to another service, it uses that service's SPN to differentiate it from all of the other services running on that computer.
Because multiple services can run simultaneously under the same account, setting an SPN requires four unique pieces of information. These four pieces of information uniquely identify any service running on a network and can be used to mutually authenticate to any service.
For each SPN that is set, the following information is required:
1. The type of service, formally called a service class. This enables you to differentiate between multiple services running under the same account.
2. The account under which the service is running.
3. The computer on which the service is running, including any aliases that point to that computer.
4. The port on which the service is running (optional if the default port for the service of that type is used such as port 80 for HTTP).
Syntax configuration examples have been omitted in this guide.
This is a requirement because SharePoint runs as a "farm" - even in single-server configurations - you have to run the site and authentication under the app pool account... AND still set up your SPN's.
“In a deployment with multiple FIMServices, ensure that each FIMService has constrained delegation configured so that each FIMService can successfully communicate to each other in order for Workflow Approvals to work properly. Approval Responses from users can come from any Portal or if Exchange is enabled from the FIMService that is polling. In all cases, the Approval Response will be directed to the FIMService machine that processed the original Request so cross-server communication: FIMPortal -> FIMService AND FIMService -> FIMService must work properly.”
Source: [11.] Change the Forefront Identity Manager 2010 R2 Synchronization Service Account
The procedure is described in detail in the reference TechNet page.
Before you change the account of any of the FIM Services, make sure you can roll-back, so you need to have a DRP plan in place (and a working backup-restore…)
See the Account security requirement of the FIM Sync service account, section below.
Local Security Policy
No additional lock-down procedures are needed to secure the Microsoft Forefront Identity Manager 2010 R2 service account in a domain. By default, you cannot log on locally with the Microsoft Forefront Identity Manager 2010 R2 service account.
You must create a user account to run installation of the FIM components.
This installer account must be a domain user account.
The most important reason is that the FIM installer account is assigned root administrator in the FIM service and portal, during the installation you need SQL sysadmin (SA) rights, which is by preference a domain joined SQL server with Windows authentication.
To be able to install FIM Synchronization Service or FIM Service, the account must be a SQL sysadmin.
The account that you use does not have to be a SQL sysadmin after the installation is complete.
The user account used to install the FIM Service must be granted the sysadmin role in SQL Server.
By default, members of the Local Administrators group do not have the necessary permissions.
Unless the user account is either the built-in administrator account, or the user account used to install SQL Server, then the user account must be granted the sysadmin role in SQL Server.
To be able to install the FIM Portal, it is assumed that SharePoint is installed with the default settings, that the default SharePoint site can be reached using the address specified in the user interface, and that the user who is installing the FIM Portal is authorized as an administrator of that SharePoint site.
This account should be a local administrator account.
The FIM installer accounts should be member of the local administrators group.
DO NOT
As other services require other privileges, the PoLP demands to use separate accounts.
The FIM Sync Service account has HPA access to the FIM Sync Service operations, using the same account bestows too many unneeded privileges to the FIM Sync service account
You must create a service account to run the FIM Synchronization Service.
This service account must be a domain service account.
On the server running the FIM Service, you must only restrict the FIM Service service account, and not the FIM Synchronization Service service account.
Use the following restrictions on the service accounts:
The FIM Service SVCA must be part of the FIM Sync Admins security group. (See Ref. 4)
This requirement excludes the use of 1 single account for both the FIM Service and the FIM Synchronization service.
If you are deploying password reset, do not use the Deny access to this computer from the network restriction option.
If you choose to use the same account for both service accounts and you separate the FIM Service and the FIM Synchronization Service, you cannot set Deny access to this computer from the network on the FIM Synchronization Service server.
If access is denied, that action prohibits the FIM Service from contacting the FIM Synchronization Service to change configuration and manage passwords.
During installation/reconfiguration FIM will need 5 groups to manage security in FIM Sync.
3 Groups are used to control which tasks that users can perform in Synchronization Service Manager.
Members of this group have access to Operations in the Synchronization Service Manager only.
FIMSyncOperators can run management agents, view synchronization statistics for each run, and save the run histories to a file. Members of the FIMSyncOperators group must also be members of the FIMSyncBrowse group to open links in synchronization statistics.
FIM also needs 2 security groups for authentication during password management operations, these do not have access to Synchronization Service Manager:
Can gather information about a user's lineage when resetting passwords by using Windows Management Instrumentation (WMI) queries.
For more information about setting passwords by using WMI, see the FIM Developer Reference.
By default, FIM setup creates these groups as local computer groups, rather than domain local groups.
But local computer groups are known only to that server, whereas domain local groups can be recognized throughout the domain.
There might be cases where you need to use domain local groups for these roles. For example:
If you specify a preexisting group during setup, the user account that is running the installation will not be added to the preexisting group.
If you do not create the groups in advance, FIM setup will suggest to create these groups as local computer groups, rather than domain local groups.
Source: [13.] Using Security Groups
Important
If you plan to use domain local groups, create the groups before installing FIM.
You must create a service account to execute the FIM Task scheduler jobs.
Due to the fact the FIM Security groups should be hosted on AD, this service account must be a domain user account.
Use the following restrictions on the FIM task scheduler account:
<To be completed>
The service accounts should not be members of the local administrators group.
For SSPR
The FIM Sync service SVCA must not be part of the FIM Sync Security Groups
The FIM Service account has HPA access to the FIM Service operations, using the same account bestows too many unneeded privileges to the FIM Sync service account
There are three service accounts that are used to run the FIM server components. They are called the FIM Service service account, the FIM Synchronization Service service account, and the FIM Password service account in this guide.
The FIM MA account is not considered a service account, and it should be a regular user account.
For the FIM Synchronization Service service account to be able to impersonate the FIM MA account, the FIM MA must be able to log on locally.
The purpose of this account is to make it possible for the FIM Service to be able to identify the FIM Synchronization Service when it is exporting to the FIM Service through the Web services. When the FIM Synchronization Service engine is exporting, all authentication (AuthN) and authorization (AuthZ) workflows are ignored and only action workflows run.
If you later change this account in the FIM Synchronization Service, you must also run a change install on the FIM Service to update the service with the new account information.
Due to the fact that the SSPR portals for the Password registration and Password Reset are hosted on IIS, the security mainly focusses on IIS.
The FIM configuration part is rather applying on the installation or reconfiguration.
Reference: [54.]: Security Best Practices for IIS 8
General: http://aka.ms/FIM_PortsRightsPersmissions
FIM MA Acocunt security
How to grant the"Replicating Directory Changes" permission for the Microsoft Metadirectory Services ADMA service account: hhttp://support.microsoft.com/kb/303972
See:
“The following table summarizes the accounts and permissions required by FIM CM. You can allow the FIM CM create the following accounts automatically, or you can create them prior to installation. The actual account names can be changed. If you do create the accounts yourself, consider naming the user accounts in such a way that it is easy to match the user account name to its function.”
Provides the following services:
Domain account
Description
Account Security: Local Rights
After installation, the account access can be lowered or the account can be disabled and re-enabled if updates need to be installed.
· The group is added to the Service Manager Administrators role automatically.
· The group is added to the Data Warehouse Administrators role automatically.
After installation becomes the Operational System Account, is assigned to logon account for both System Center Data Access Service and System Center Management Configuration Service
After installation, becomes the data warehouse run as account, is assigned to the Service Manager SDK account and Service Manager Config account.
Member of the local Users security group.
See: [38.] FIM 2010: Quick Guide to installing BHOLD Core
Items
Password never expires
Use the following restrictions on the FIM installer account:
Due to the fact that the FIM installer account is only used to install FIM component, during initial setup or during application of an hotfix, do not use this account for other purposes.
The FIM configuration part is rather applying on the installation or reconfiguration of the FIM SSPR portals for assword registration or password reset.
From: [34.] Password Registration and Reset Portal Deployment
“The following is a note on doing a change mode install.
If you do a change mode install to change the account that runs the FIM Password Registration and Password Reset portals you must also run a change mode install on the server that is running the FIM Service and specify the application pool account or accounts.
This should be done first.
That is, prior to running the change mode install on the Registration and Reset portal server, run a change mode install on the server that is running the FIM Service and associate it with the new application pool account or accounts.”
Account type: domain account
Configuring the FIM Service Service Exchange mailbox
Change the SharePoint Application Pool Account to Use CORP\SPService
See, page 57, paragraph 12.4, SharePoint .
There are different ways of creating accounts in the FIM portal:
The account that installs the FIM Service / FIM portal will be assigned as primary portal administrator, as it will be added to the Administrators set in the FIM Portal.
Additional administrators must be added to the 'Administrators' set
For more information see: How to Use PowerShell to Fix an ObjectSID on an FIM Portal Object
The account that installs the FIM Service / FIM portal will be assigned as primary portal administrator, as it will be added to the Administrators set in the FIM Portal
Download the entire guide at once, in PDF version from Technet Gallery .
This document has some additional content, which is not available online.
Return to Table of Contents of the article series