Share via


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

 

Back to top


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.

 

Back to top

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.

 

Back to top

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.

 

Back to top


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:

 

Back to top

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.

 

Back to top

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.

 

Back to top

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).

 

Back to top


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

 

Back to top

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 mitiga­tions are not fully effective.

 

Back to top

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.

 

Back to top

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.

 

Back to top

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

 

Back to top

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.”

 

Back to top

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.

 

Back to top


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.

 

Back to top


 

Return to Table of Contents of the article series.

 

Back to top