Identity Manager (FIM/MIM): Planning security for accounts, groups and services - Core account type differentiators (Part 10)

Introduction

When handling solutions in the identity & access management area (and practically speaking working with FIM/MIM), a very basic discussion is always coming back: which types of accounts do you need?

It's seems a trivial question but you can apply it to different areas of the solution, both from a technical as from a logical perspective... When talking about the technical perspective, we're looking at securing your technical implementation.

A more practical question would be:

• what user accounts do I need to prepare before I start implementing my IAM solution?
• What is needed to implement my solution in a secure, but manageable way, with respect to principles of "segregation of duties" and "least-privilege", but also "due care", "due governance"...

Typical operations

With a bit of experience; referring to the installation requirement of a typical FIM/MIM configuration), you can easily list at 5 categories of accounts you need:

1. application and hotfix installer accounts: typically administrator accounts to run the setup, with some elevated privileges on the server and back-end systems like database to get the server components running
2. service accounts: account that will be configured on applications running continuously in the background (FIM Sync service, FIM Service service, SQL Database services
3. accounts that are not running full time in the background, but run a technical task now and then, not continuously, but automated without user interaction (eg like the FIM Sync run profile scheduling, …)
4. operational user  accounts, that logon to the desktop, what every single person is using to do his daily job and IT work (logging on on your laptop, remotely connecting to the server,… )
5. personal administrator accounts: that logon to the desktop, or to the server desktop for highly priviledged IT work (logging on your laptop as admin, connecting to the server as admin, administrative tasks…)

Key Differentiators

So what are the key differentiators to define and separate these accounts, and how to secure them?

1. Does the account require Interactive Desktop logon?

One of the primary differentiators is interactive desktop logon (1).. Typically you need to logon for installation or operational administration. 

But the application on the server, to run as a service in the background, does not need desktop login.

When securing your environment this is a key parameter to lock down the privileges, because it's very powerful to have the desktop logon for a hacker.

This differentiator is also directly related to password management.

• Account logging on in the desktop can and must change their passwords.
• Accounts running in the background, without interaction will have major trouble when they are under password change policy.

Unless the application supports managed service accounts, but that's not wide spread yet, certainly not for the FIM/MIM components...so I'll skip that track for now.

But an installer account, DOES NEED desktop logon, but SHOULD NOT be deleted when someone leaves the company.

The best example of this difference is the FIM Installer account, that gets local admin access to the Windows server and to the SQL server as SA. This account is also injected in the FIM portal as default (GOD MODE) admin, so you DON'T want to loose this account. 

2. Physical person & identity lifecycle

So, another easy differentiator is the link to a physical person (2) and the person's lifecycle**.**

Typically physical persons are 'managed' with a lifecycle (eg under contract with your company).

You know the typical hire-change-fire processes...

1. people on-board,
2. people change jobs,
3. people leave the company...

Why is this important

You don't want to run your background services on a personal account. Because... if you are running your identity management the proper way (and you will), they will be deprovisioned one time, right?

And when you disable accounts that are run by background services, the solution will stop working.

3. SoD & Principle of least-privilege

In normal (or rather normalized) security situations, the principle of least-privilege dictates that normal user accounts should not have extensive administrative rights for operational tasks, these should be attributed to separate administrative accounts that are used for specific tasks.

So, the parameter: "highly privileged rights" (3) is a another key differentiator between the different types of accounts that can logon to a desktop.

From a security perspective this is a important privilege that require,

• just in time elevation (only attribute rights when needed and removal after finishing task)
• close monitoring (to detect abuse and anomalies, like unauthorized elevation)

4. Run in the back ground or as a scheduled task

The opposite of the 'physical' account are accounts that are not (or better, SHOULD not be) used by people, but run in the background, most server and/or Active Directory admins immediately think about the following system / GPO settings

• deny run as a service
• deny logon as a batch job

So, considering "segregation of duties" and "least-privilege" makes them mutually exclusive. (I beg you to disagree and provide me motivated arguments ...), which provides 2 other differentiators

• run as a background service (4)
• run as a batch job (5)

Account classification

With a bit of experience (referring to the installation requirement of a typical FIM/MIM configuration), you can easily list at 5 categories of accounts you need:

1. service accounts:
   • account that will be configured on applications running continuously in the background (like IAM application service, FIM Sync service, FIM Service service, portal services, web services, SQL Database services …)
2. technical account that
   • are not running full time in the background,
   • but run a specific technical task now and then, not continuously, but
   • automated
   • without or limited user interaction (eg like the FIM Sync run profile scheduling, ...)
3. functional  accounts:
   • non-personal account,
   • typically general administrator accounts to run the setup,
   • with some special privileges on the server and back-end systems to get the server components running
4. personal accounts
   • used by physical persons to
   • logon to the desktop for office or operational work,
   • what every single person is using to do his daily job and IT work (logging on on your laptop, remotely connecting to the server,... )
5. personal administrator accounts:
   • physical persons
   • that logon to the desktop, or to the server desktop
   • for highly privileged IT and system work (logging on your laptop as admin, connecting to the server as admin, administrative tasks...)  

Examples of typical use

Rights And permissions

Account Type

Task type

Service Account

Technical Account

Functional Account

Personal Account

Personal Administrator Account

Run as a Background Service (continuously)

YES

NO

NO

NO

NO

Running a batch job (Specific Task or script)

NO

YES

NO

NO

NO

Interact with desktop/Physical Logon

NO

NO

YES

YES

YES

Highly Privileged Rights

NO

NO

YES

NO

YES

Direct Link to physical person (link to HR)

NO

NO

NO

YES

YES

Direct Links

• FIM/MIM: Planning security setup for accounts, groups and services - Table of contents
• FIM/MIM: Planning security setup for accounts, groups and services - Part 1. Introduction
• FIM/MIM: Planning security setup for accounts, groups and services - Part 2. FIM Security principles
• FIM/MIM: Planning security setup for accounts, groups and services - Part 3. Compact Checklist
• FIM/MIM: Planning security setup for accounts, groups and services - Part 4. Detailed Description
• FIM/MIM: Planning security setup for accounts, groups and services - Part 5. Operational Best Practices
• FIM/MIM: Planning security setup for accounts, groups and services - Part 6. References & authoritative resources**      **
• FIM/MIM: Planning security setup for accounts, groups and services - Part 7. Additional resources** **
• FIM/MIM: Planning security setup for accounts, groups and services - Part 8. Glossary
• Identity Manager (FIM/MIM): Planning security setup for accounts, groups and services - Part 9. Release Schedule
• Identity Manager (FIM/MIM): Planning security for accounts, groups and services - Core account type differentiators (Part 10)

Return to Table of Contents of the article series.

↑ Back to top