Return to Table of Contents of the article series
↑ Back to top
The purpose of this document to provide an overview of security best practices to secure your FIM and MIM infrastructure. This document is not a detailed step-by-step guide but a security guideline.
It does not provide detailed hands-on guidance and screenshots to configure your environment, but you'll have practical guide to secure your FIM infrastructure.
This document is focused on the implementing the security best practices of the FIM server components.
FIM requires SharePoint Foundation to support the FIM Portal. This document is scoped to an infrastructure with a single server running SharePoint Foundation.
This document excludes a setup with a SharePoint Foundation farm. But in the additional references section (See page: paragraph 57, paragraph 12.4 SharePoint) you will find links to plan for a SharePoint farm configuration.
This security configuration baseline does not cover detailed description on configuring secondary services, a.k.a the FIM backend, like
It’s essential to secure these platforms, work with technical platform experts.
As far as possible, the document provides pointers to detailed documentation.
All references used in the documents are in the format [<reference nr.>].
The complete collection of references is listed in the document you can download: paragraph 12, References & Authoritative resources on page 54.
Online:
In general, the current document applies to both FIM 2010, FIM 2010 R2 as MIM 2016. If a configuration item is particular for a version, it will be mentioned explicitly.
Figure 1: FIM components overview
Source: [9.] FIM 2010 Technical Overview
Figure 2: Typical FIM Infrastructure view
“/../ As the central component necessary to synchronize data across multiple connected data sources, the synchronization service aggregates information about identities into the metaverse and provides an agentless method for connecting to each data source. The FIM Synchronization Service is the fulfillment mechanism, creating and maintaining identities in other systems /../
“/../ The FIM Service presents the Web service request pipeline and is responsible for /../:
The FIM Portal is mainly the user and administration interface with the FIM service:
“/../ In the earlier figure, several clients to the FIM Service are shown: The FIM Add-in for Outlook, the Password Reset Add-in, and the FIM Portal as well as custom clients. In addition, the FIM Synchronization Service and Exchange 2007 can be considered clients of the FIM Service.
/../
Users are allowed to interact with the FIM Portal directly by using a Web browser and, depending upon permissions, allowed to make requests, respond to approval requests, or cancel existing pending requests./../”
As you noticed in the image above, there is an essential difference in functionality between the FIM Portal (as an administrative interface for the FIM Service), the FIM Password Registration portal and the FIM Password reset portal.
Essentially the FIM Portal must be hosted on SharePoint Foundation, while both FIM SSPR portals (Registration and Reset) only require IIS.
The difference in behavior and the functionality of the FIM components, require a clear convention and understanding of the naming of the components to avoid any issues in the configuration.
Following product abbreviations are frequently used.
For a detailed list see the at the end of the document, please refer to page 62, Chapter 14, Glossary, abbreviations & acronyms.
Acronym (alphabetically)
FIM Synchronization engine, or
FIM Synchronization Service
Also applies to MIM Sync engine, ILM Sync Engine, MIIS Sync engine
This also means that:
The “FIM service - Service Account” is NOT the “FIM Sync Service – Service Account”
IMPORTANT
It’s critical to use the proper terminology in your documentation and communication, as a mix up of the naming is a very common mistake which results in highly critical configuration issues in your FIM environment.
In most of the cases it’s nearly impossible to fix these issues without impact to your production environment.
To properly setup your environment, you’ll need to use different accounts.
According the use of these accounts we’ll define 4 account types
Account Type
Task type
Service Account
Technical Account
Functional Account
Personal Account
Run Background Service
YES
NO
Only run Specific Program
Specific Task or script
Interact with desktop/Physical Logon
Highly Privileged Rights
Direct Link to physical person (link to HR)
(1)
(2)
(3)
(4)
FIM Installer with admin access to Local Server & SQL, not used to manage daily operations
A service account is
a user account that is created explicitly to provide a security context for services running on Microsoft® Windows® Server.
This service account typically runs the services in the background, with no user interaction.
Interaction with the user desktop is minimized, and should be none.
CAUTION
Until further notice, FIM and MIM (any version) DO NOT SUPPORT virtual or managed accounts.
You cannot even complete the installation if you try.
These service account run a specific service, not scheduled tasks. For scheduled tasks a technical account is used.
Security
Due to the fact that these accounts run in the background, the rights & permissions of these accounts must be reduced to the absolute minimum. Service account must not run as a Highly Privileged Account (HPA).
Although service accounts are usually exempted from the password policy for personal user accounts, it’s highly advised to change the password on a regular base (eg, 1-2 times a year).
Please consider, changing a service account password might break the application functionality.
Service account require complex passwords.
Audit & Monitoring
Due to the specific target of a service account, it does require monitoring for abnormal activity (outside the scope of the account).
Inappropriate use
Do NOT use the service account for any other purpose like
A technical account is
In the FIM context, for example technical accounts will be used for:
Do NOT use the technical account for any other purpose like
…
A functional account is NOT directly linked to a physical person. But it does require physical logon, it’s linked to tasks a physical person must execute with desktop interaction.
In some cases, a functional account is required to install programs or to configure the root application administrator account. An administrative functional account usually is a highly privileged account (HPA), with elevated rights on the IT infrastructure.
This type of account must never be used for normal, daily, operational tasks.
It’s best practice to remove rights & permission when the account is not use, and only add the privileges when needed, removing them when the required task is completed.
For example:
Security risk
Functional accounts are highly susceptible to hacks or security issues as these accounts are not linked to daily operations of a physical person.
The use of these account needs to be monitored closely.
Furthermore, the passwords of these account must be managed under the 4-eyes principle, and changed after use.
Advisory
Typical use
Primarily a personal account is directly linked to a physical person.
As a consequence, it is directly linked to a person lifecycle.
This means it is created when a person joins the company and it gets (or must get) deprovisioned when a person leaves the company.
Also, it needs to comply to the password management rules, changing passwords on a regular basis.
An administrative personal account usually is a highly privileged account (HPA), with elevated rights on the IT infrastructure.
Personal accounts are highly susceptible to hacks or security issues as these accounts can be easily found based on the social engineering.
Due to the link to the personal lifecycle, these personal accounts must not be used for automated operations, scheduled tasks or repeated installation tasks (ref. use of functional accounts).
Following authoritative references are used in this section.
In the Microsoft Security Intelligence Report (SIR) you find a section on Managing Risk.
The report addresses a set of security threats and risks with related countermeasures.
This document has a particular focus on prevention and limiting the impact of security breaches.
From the SIR: section Protecting Your Organization, Prevent and Mitigate Security Breaches
“Enforce the idea of least privilege, wherein computer accounts are given only those permissions required to perform a job function.
Develop and implement plans to reduce the likelihood of common types of breaches to mitigate their impact should they occur and to respond if the mitigations are not fully effective.
As explained in the “SQL Server 2012 Security Best Practices - Operational and Administrative Tasks”:
“When choosing service accounts, consider the principle of least privilege.
The service account should have exactly the privileges that it needs to do its job and no more privileges.
You also need to consider account isolation; the service accounts should not only be different from one another, they should not be used by any other service on the same server. “
And more:
Making the “service account an administrator, at either a server level or a domain level, or using Local System, bestows too many unneeded privileges. “
As explained on WikiPedia:
“The principle means giving a user account only those privileges which are essential to that user's work.
For example, a backup user does not need to install software: hence, the backup user has rights only to run backup and backup-related applications. Any other privileges, such as installing new software, are blocked.
The principle applies also to a personal computer user who usually does work in a normal user account, and opens a privileged, password protected account (that is, a superuser) only when the situation absolutely demands it.
When applied to users, the terms least user access or least-privileged user account (LUA) are also used, referring to the concept that all user accounts at all times should run with as few privileges as possible, and also launch applications with as few privileges as possible. Software bugs may be exposed when applications do not work correctly without elevated privileges.
The principle of least privilege is widely recognized as an important design consideration in enhancing the protection of data and functionality from faults (fault tolerance) and malicious behavior (computer security).”
Considering security, the principle of least privilege is applied to achieve following targets:
That also implies to use another account if different, unrelated tasks must be configured.
Source: [7.] Privilege separation
“In computer programming and computer security, privilege separation is a technique in which a program is divided into parts which are limited to the specific privileges they require in order to perform a specific task. This is used to mitigate the potential damage of a computer security attack.”
To implement the PoLP or privilege separation, you can use SoD (Segregation of Duties a.k.a Separation of Duties).
The FIM documentation on TechNet clearly references to use separate accounts with separate rights and permissions to protect the various functional FIM components and platforms, related functional processes and data flows.
SoD (Segregation of duties) is also known as ‘separation of duties’.
SoD is tightly related to the principle of least privilege, explained in the previous chapters.
While privilege separation handles the split of rights and permissions, SoD rather handles the separation of duties and tasks.
Although SOD essentially is targeted at the tasks of physical persons, it should be applied to other account types too, for similar reasons.
In that case it’s referenced as account isolation.
The focus on the task, is really helpful to define the required accounts and groups to execute specific task in your environment.
When focusing on FIM functionality, the different FIM components serve a different purpose, executing different tasks thus you need different accounts.
As mentioned before, the FIM documentation on TechNet clearly references to separate accounts and separate groups with separate rights and permissions to protect the various FIM components, related processes and data flows.
Reference:
Reference: [8.] http://whatis.techtarget.com/definition/four-eyes-principle
“The four eyes principle is a requirement that two individuals approve some action before it can be taken. The four eyes principle is sometimes called the two-man rule or the two-person rule.”
Only configure the required accounts related to the FIM feature you need to implement. Not more, but also not less. The more you install, the more attack surface you expose. For example, if you only implement FIM Sync, there is not need to implement the FIM Service required accounts.
But IF you implement a certain component, like FIM sync, you MUST implement ALL required accounts to guarantee security best practices like account isolation, SoD, PoLP. Violation of security best practices also increases the attack surface to your environment.
For example, if you implement FIM Sync and FIM Service, it’s very a bad practice to use one single account for multiple services, management agents, technical and functional accounts and/or administrative accounts.
You don’t need a lot of imagination to estimate the impact of breaching a single account, compared to the effort of managing multiple accounts or the effort required to breach multiple isolated accounts.
Download the entire guide at once, in PDF version from Github (moved from Gallery).
This document has some additional content, which is not available online.
Return to Table of Contents of the article series.