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, I’m 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”…
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:
- installer accounts: typically administrator accounts to run the setup, with some privileges on the server and back-end systems to get the server components running
- service accounts: account that will be configured on applications running continuously in the background (FIM Sync service, FIM Service service, SQL Database services
- account 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, …)
- personal 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,… )
- 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…)
So what are the key differentiators to define and separate these accounts?
One of the primary differentiators is interactive desktop logon (1).
Typically an installation account or an administrator needs to logon…. A service account running the application in the background on the server, … does not.
Also, when securing your environment this is a key parameter to lock down the privileges.
This differentiator is also directly related to password management.
Account logging on in the desktop can 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.
So, another easy differentiator is the link to a physical person (2).
Typically physical persons are ‘managed’ with a lifecycle (eg under contract with your company). You know the typical hire-change-fire processes… (people on-board, people change jobs, people leave the company)
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?
In normal (I should rather say normalized) security situations, the principle of least-privilege dictates that normal user accounts should not have extensive administrative rights, these should be attributed to separate administrative accounts.
So, the parameter: “highly privileged rights” (3) is a another key differentiator between the different types of accounts that can logon to a desktop.
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 me 2 other differentiators
- run as a background service (4)
- run as a batch job (5)
Based on these differentiators, the basic accounts types you can define are
- service accounts
- technical accounts
- functional accounts
- personal accounts
- personal admin accounts
|
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 |
I’ve been working with a variety of customers and environments and I challenge this matrix every single time.
So I would like to challenge you to find a better, easier, more solid matrix.
Is there anything in this set of parameters that doesn’t make sense? Too simple, to complex, anything missing?
If yes, let me know and we go for the next version.
Like this:
Like Loading...
