Identity Manager (FIM/MIM): Planning security setup for accounts, groups and services - Part 1. Introduction
https://msdnshared.blob.core.windows.net/media/2016/05/0640_NinjaAwardTinyGold.pngGold Award Winner
Return to Table of Contents of the article series
Purpose & Scope
Purpose
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.
In scope
This document is focused on the implementing the security best practices of the FIM server components.
SharePoint
FIM requires SharePoint Foundation to support the FIM Portal. This document is scoped to an infrastructure with a single server running SharePoint Foundation.
Out of scope
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
- IIS
- SharePoint
- SQL
- …
It’s essential to secure these platforms, work with technical platform experts.
As far as possible, the document provides pointers to detailed documentation.
Document & Naming Conventions
References
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:
- FIM 2010: Planning security setup for accounts, groups and services - Part 6. References & authoritative resources, and
- FIM 2010: Planning security setup for accounts, groups and services - Part 7. Additional resources
FIM vs MIM
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.
FIM components
Figure 1: FIM components overview
Source: [9.] FIM 2010 Technical Overview
Figure 2: Typical FIM Infrastructure view
FIM Synchronization
“/../ 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 /../
FIM Service
“/../ The FIM Service presents the Web service request pipeline and is responsible for /../:
- Request processing
- All requests submitted to the Web service endpoint are processed by the FIM server and the built-in policy engine. /../”
FIM Portal
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./../”
FIM SSPR Portals: Password registration and reset portals
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.
Naming conventions
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.
Abbreviations Used
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) |
Refers to |
| FIM | Forefront Identity Manager, a.k.a. FIM 2010, FIM 2010 R2 |
| FIM Sync, FIMSync | FIM Synchronization engine, or FIM Synchronization Service Also applies to MIM Sync engine, ILM Sync Engine, MIIS Sync engine |
| ILM | ILM 2007 FP1 |
| MIIS | MIIS 2013 |
| MIM | Microsoft Identity Manager 2016, MIM 2016 |
| Sync | FIM Sync |
This also means that:
“FIM Service” IS NOT “FIM Sync”
“FIM Service” IS NOT “FIM Sync Service”
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. |
Account types
To properly setup your environment, you’ll need to use different accounts.
According the use of these accounts we’ll define 4 account types
- Service account (SVCA)
- Technical account (TA)
- Functional account (FA)
- Personal account (PA)
Core account differentiators
Account Type |
||||
Task type |
Service Account |
Technical Account |
Functional Account |
Personal Account |
Run Background Service |
YES |
NO |
NO |
NO |
Only run Specific Program |
YES |
NO |
NO |
NO |
Specific Task or script |
NO |
YES |
NO |
NO |
Interact with desktop/Physical Logon |
NO |
NO |
YES |
YES |
Highly Privileged Rights |
NO |
NO |
YES |
YES |
Direct Link to physical person (link to HR) |
NO |
NO |
NO |
YES |
| Example of typical use | (1) |
(2) |
(3) |
(4) |
Examples of typical use
| Example | Type of use |
| (1) | ‘FIM Service’ service, ‘FIM Sync’ Service, ‘SQL Database server’ service, … |
| (2) | Task Scheduler account to run FIMSync scripts on an automated schedule |
| (3) | FIM Installer with admin access to Local Server & SQL, not used to manage daily operations |
| (4) | Personal Administrator account to manage daily operations |
Detailed description & definition
Service account (SVCA)
A service account is
not linked to a physical person.
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
- Running scheduled task
- Installation of applications
- Administrative tasks
- HPA
- Daily administrative operational tasks
- …
Technical account (TA)
A technical account is
- NOT linked to a physical person.
- NOT a service account as it is not used to run services,
- Used to run a specific task (or a combination of tasks) on a regular, non-continuous base.
In the FIM context, for example technical accounts will be used for:
- Running scheduled tasks (using the account in the scheduled task configuration)
- Running PowerShell scripts
- MA (Management Agent) configuration
- …
Inappropriate use
Do NOT use the technical account for any other purpose like
Running Windows services
Installation of applications
Administrative tasks
HPA
Daily administrative operational tasks
…
Functional account (FA)
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:
- During installation of FIM Sync/FIM service, you need local admin rights on the Windows server and you need SA rights on SQL, which are highly sensitive.
- After installation of FIM you remove the privileges
- Before installing a hotfix, you elevate the account. Then you install the hotfix and after installation you remove the account form the elevated rights.
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
- Apply the 4-eyes-principle,
- Split the password,
- Store the password components separately in a secured location guarded by 3rd person like CISO
Typical use
- Application installation
- Installation of hotfixes
Personal Account (PA)
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.
Security risk
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).
Generic security principles
References
Following authoritative references are used in this section.
- [1.] Microsoft Security Intelligence Report
- [19.] SQL Server 2012 Security Best Practice Whitepaper
Threats
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.
Principle of least privilege (PoLP)
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:
- Minimizing risk
- Better security
- Better system stability
- Ease of deployment
Rule of thumb
The service account should have exactly the privileges that it needs to do its job and no more privileges.
That also implies to use another account if different, unrelated tasks must be configured.
Privilege separation
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).
Rule of thumb
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) & Account Isolation
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.
Rule of thumb
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.
More info
Reference:
- [5.] Segregation of duties/ Separation of duties
4-eyes principle
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.”
Number of accounts vs. security risk
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
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.
Direct Links
- FIM 2010: Planning security setup for accounts, groups and services - Table of contents
- FIM 2010: Planning security setup for accounts, groups and services - Part 1. Introduction
- FIM 2010: Planning security setup for accounts, groups and services - Part 2. FIM Security principles
- FIM 2010: Planning security setup for accounts, groups and services - Part 3. Compact Checklist** **
- FIM 2010: Planning security setup for accounts, groups and services - Part 4. Detailed Description** **
- FIM 2010: Planning security setup for accounts, groups and services - Part 5. Operational Best Practices
- FIM 2010: Planning security setup for accounts, groups and services - Part 6. References & authoritative resources** **
- FIM 2010: Planning security setup for accounts, groups and services - Part 7. Additional resources** **
- FIM 2010: Planning security setup for accounts, groups and services - Part 8. Glossary
Return to Table of Contents of the article series.