Separate AD Accounts for Different Work Functions
Posted by DesperateForever6607@reddit | sysadmin | View on Reddit | 31 comments
Hello everyone,
Our security team recently proposed an idea to improve account security by requiring separate accounts for different functions—e.g., one account for daily work, another for email, another for remote VPN, and yet others for firewall or network tasks.
The rationale is to reduce the risk of lateral movement or broader domain access in case an account (like email) gets compromised.
Has anyone else implemented a similar approach?
Would love to hear your thoughts and experiences!
Zizonga@reddit
So the thing is this this approach arguably just makes more excess accounts you may or may not use. Tier 1 and 0 in MSFT are closely related enough to group them, thus having one daily driver and one admin one is fine. Especially given that you as a sysadmin aren’t going to probably have sysadmins on your team that won’t need domain controller access.
SpiceIslander2001@reddit
It's interesting that your security team can only propose an idea. In my office, multiple accounts was mandated by Security.
I've got:
My regular account
An admin account for my PC and some servers
Separate domain-admin level account for each domain I manage (the count is now up to 8)
Caldtek@reddit
Your infose department are smoking something. Probably crack
william_tate@reddit
You should ask the security team who is going to manage all these separate, disparate authentication systems, then put together a budget submission for the systems and costs to get that many with mechanisms working and secured. Possibly include some extra headcount. Take all of it to the CFO. Sit back and wait for the inevitable “that’s not happening “.
Few_Breadfruit_3285@reddit
No, just, no. The norm is for admins to have a separate admin account from their daily account, for performing privileged tasks. Not for end users to need separate logins for email, VPN, etc.
If anything, single sign-on should be considered as not only more convenient, but also more secure. It's easy to implement MFA when all applications are authenticating against a single identity provider.
Have you all even implemented MFA? If not, start there. Also look at Privileged Identity Management.
DesperateForever6607@reddit (OP)
Sorry i was not clear in OP, we are talking about only admin users.
AppIdentityGuy@reddit
Your admin accounts should not have email or teams/slack etc at all. They must be kept separate and should have PIM.
Status_Baseball_299@reddit
Email is now required for Mfa authentication but the other stuff agree.
AppIdentityGuy@reddit
What do mean by that?
Status_Baseball_299@reddit
Admin accounts where I worked do have email but it’s just for authenticate and login for different apps, that are allow for these accounts in Azure, Apps site etc.
DesperateForever6607@reddit (OP)
What about SSL VPN like Global protect?
Discomm@reddit
SSLVPN should be on their normal user accounts. They should be logging only into administrative functions using admin accounts, and everything else using their normal user accounts.
DesperateForever6607@reddit (OP)
Lets say we got O365 email account linked with on-prem AD account, can same account be used for VPN and normal daily work like login to own workstation. Eventually 1 separate account for privileged access such as servers, network devices and firewalls
Discomm@reddit
Yes, that would be perfectly fine. At the end of the day, the “normal” account should be for day-to-day things which anyone would be able to do, like logging into the corporate VPN or checking email or etc. Normal account should be setup with access to non-sensitive and non-infrastructure related things, while admin account should be the one with all the privileges.
Side note, Entra Connect will make your life infinitely easier if your goal is marry O365 email and on-premises AD identities together.
AppIdentityGuy@reddit
Many VPN solutions nowadays support EntraID for authentication which means you can enforce EntraID CAP for VPN access....
Discomm@reddit
Pushing so hard for it where I’m at. We’re still on GlobalProtect running HIP checks n shit….
Few_Breadfruit_3285@reddit
Ok, I still think you should be using Privileged Identity Management in lieu of separate accounts.
The concept of using separate accounts was common before PIM became as advanced as it is today. With PIM, you can require approval processes before the administrative role is enabled and then expire the administrative role after x hours or minutes. You can also be more granular in requesting and granting administrative roles.
With separate accounts, the admin account stays active and vulnerable 24/7.
DesperateForever6607@reddit (OP)
If we onboard a PAM solution like CyberArk or BeyondTrust, how would that work? Never used any PAM solution. I can discuss with management
Discomm@reddit
Delinea Secret Server user here. All you really need to do if you’re in a hybrid env is configure a couple of VMs with their software on it to act as brokers that can connect to AD for password changing and connect to the cloud platform for user access/auditing/general visibility. You can even require certain categories of accounts to get approval to access from other delegated groups/users, which I find to be a big plus for domain admin accounts.
Then I recommend running sign-in for that thru whatever SSO provider you use with some sort of conditional access policies that require extra, nuanced forms of auth. MFA first of all obviously, but it would also be good to have policy that requires the device that is signing-in to be joined to domain/aad for example, or managed by Intune if you have that.
You can configure automatic password rotation for any time frame you’d like, and you can also configure “templates” for having the local machine open a specific application under the privileged user account. You can also allow/deny viewing the account’s current password to the owner and/or other users if you have teams that use the same pool of service accounts, for example. All the end user has to do is log into the platform, go to the “secret” (the account they need), hit copy and go.
At the end of the day, it’s stupid simple to implement, but the actual problem lays in interrupting people’s existing processes and workflows. Good luck!
New-Pop1502@reddit
Hi,
Here's how it's implemented in our highly regulated and secured environnement.
A "level 1" account that represents all users for daily and tasks. Emails, VPN, CRM, name it.
A "level 2" account for privilege access. This one is accessible only in a highly monitored and restricted citrix environnement.
To protect the level 1 account from threat actors, have as much as possible of your non priviledge access configure to SSO with it. Then apply policy to restrict usage of this account on corporate computer and enforce MFA.
Same thing for the level 2, but in the realm of the citrix environment. Level 2 security policies are configured to be mroe restrictive and aggressive than Level 1. E.g : refresh authentication token lifecycle way shorter.
The identity trend these days is to be able to prove as much as possible that the person using an account is actually the genuine person, the more accounts you have, the more difficult it is to put in place and as a side effect cost more as you need more identity security product licences.
enforce1@reddit
The logical extreme of this is workstation admin, server admin, domain admin, and normal user account. I had a job like this and it was horrible.
No_Dot_8478@reddit
We use 3, with a specialty 4th. Daily use, standard admins on data side, standard admins on network side, then high level overall root access no limits admin. Should mention we have network and data side separated by actual job function, so no network engineer get data admins, no sys admins get network admins.
wrootlt@reddit
We have regular user account (email, Teams, OneDrive, etc.). Privileged account that has admin rights on workstations and some servers. We have a few non user domains (infra) where we have separate priv accounts, but these are used rarely and are edge cases. We don't have separate account per system. There are of course local accounts in most systems, but these are not domain accounts.
HenrikJ88@reddit
Heck no.
One for day-to-day activities and one for administrative/privileged activities. And if you have a hybrid environment, you should have one for Entra ID, that is not the same as the one with privileged activities.
Implement MFA for all three accounts.
/ Identity and Access Specialist.
extremetempz@reddit
We have 3 accounts.
Regular User Member Server / Local Computer admin Domain Admin for DCs and CA
Although it may be 4 in the not too distant future for me as I start to look after AIX and Solaris Boxes, for whatever reason LDAP points to a particular sub OU I need to be in for UNIX in my company, if I move myself then I break other things I can't be bothered fixing, ah the joys
slugshead@reddit
We have three accounts.
Beginning-City-7085@reddit
It is the norm to have one normal account and another one for privileged access. I only see more for companies who have legal obligations/certifications. Already with 2 accounts and good process, you can achieve great security. Too much constraints tend to make people try to bypass or implement bad workaround.
DesperateForever6607@reddit (OP)
Having one account for email and VPN, and one privileged account for servers, firewalls, and network seems like a reasonable balance? How’s that approach?
poolmanjim@reddit
If these are On-Prem administrative accounts, this is more-or-less the standard model still. Usually it is referred to as the tiering model. The idea is to control the blast radius of compromise and to reduce cross-contamination from privilege.
Generally you'll see three tiers, but it isn't law.
The idea is that higher privilege tiers should not have dependencies that are managed by lower tiers and then also your higher tiers are restricted from accessing lower tiers. This all is built around the fact that a local administrator on a workstation can become any user on that workstation regardless of the local administrator's domain affiliation or not.
Blog From Microsoft on Securing Tier 0
Detail on Tiering from Brian Desmond (wrote the book on AD)
BSides KC 2024 Talk on AD Security by Eric Woodruff (MVP)
Microsoft Enterprise Access Model (Spiritual successor to tiering, but the idea of tiering is still there)
ElevenNotes@reddit
No. You add multiple authentication principals and factors to an administrative account, not multiple administrative accounts. For instance, different levels of secondary or tertiary authentication requests like 2FA or even PIM.
InsufficientBorder@reddit
A system made too complicated will invariably fail, based on the concept of users being the weakest link. If we take the perspective of an end user to this regime, what makes you think I'd have different passwords between these functions? The net outcome is that you haven't stopped lateral movement, you've just introduced a fluffy blanket that looks good - but not much else.
We separated out accounts (not to the degree listed here), and are on the path of now consolidating identities - with the view that there is a minimum amount of access afforded to all, and that anything else needs to be (1) time bound, and (2) be raised with counter approvals (in combination with other controls, such as phishing resistant MFA, etc). As an organisation, you ultimately need to make sane security practices easier and convenient (not harder).