User, Technician, and Administrator accounts

[Sephiroth]

I'm looking at the way we do secure accounts for technicians/domain admins and have started to go full circle driving myself barmy!

 

Would you be willing to share how you manage the security and group policy for techs in your domains so I can see how others do it?

 

For reference we are a secondary with ~2000 users and 2 sites supported by 3 staff.

 

As it stands we have LAPS set up and technicians have 3 accounts: test user; technician; and domain admin.

 

The test user is exactly the same as a staff account. The Domain admin account is a named but standalone account, not restricted by group policy. The technician user is a standard staff account but with a few overrides in group policy; for example, to enable CMD, PowerShell, and MMC and to allow access to the local disk. We still have to escalate to the DA account if something needs administrator access.

 

I suppose my slightly rambly question is: Is this secure/effective/efficient, or is there a better way to do it?

 

Thanks!

[mavhc]

I have a AD user that's a local admin on client machines, and an AD user that's allowed to log in remotely to servers, and then a domain admin

 

You shouldn't be logging in as domain admin to any computer really, only using runas. Hackers will steal domain admin credential kerberos tickets and have unrestricted access to your domain.

 

You can use delegation to make your elevated technician accounts have access to certain OUs etc.

 

So I'd have test & normal technician (no rights above staff, but ability to run cmd etc) & elevated technician (to use via runas for mmc stuff with delegated rights) & localadmin local admin on clients & serveradmin allowed to log into servers & domain admin (when you're using this something terrible has happened, or you're assigning delegation rights to a elevated technician account)

 

A bat file with

C:\Windows\System32\runas.exe /user:domain\elevatedtech "cmd /c mmc C:\Users\username\console1.msc"

 

Where console.msc is a saved msc config file with all the snap-ins saved

[PotNoodleTech]

In an ideal world you could have a Domain Admin acount for each member of staff - but this does is only to be used on a dedicated privelidged access workstation / server / VM to do active dir stuff etc. Not a daily use PC no waching youtube on it and general web browsing etc.

 

Then I have a server account for doing individual work on servers/vms that has local admin on all servers.

 

Then you can have your tech accounts which have elavated permissions on your local tech pcs in your office e.g. local admin.

 

Then you need a sperate technician account for technicians to work on the individual pcs out in the wild, if this account has anything go wrong it's one account with no Y drive no server connections preferably just elaceted access or even local admin on each PC.

 

keeping the accounts seperate is the key to mitigating risk - the DA for rare stuff that needs DA, the server accoutnonly used for servers in the server room, the tech account for pcs in the wild, and your own office pc tech accout should never be domain admins or have wide ranging permissions.

 

 

[paulkerton]

We're a Google MAT, but we have two accounts. One for day-to-day work, and the other that is seperate for administrative purposes and those purposes only.

 

You might find this helpful?
 

https://www.ncsc.gov.uk/guidance/introduction-identity-and-access-management

[psydii]

A couple of threads that might also be useful:

 

Each tech for us has their own

their daily driver account (exactly the same as all staff)

A endpoint local admin account (protected account,  with gpo managing membership of local adminstrators for all endpoints (clients not servers) as per one of the above threads)

A server admin account (as per the local admin, but where our working practice is to purge membership of the serveradmin_servername groups daily/when we are done working on the server.

 

Only half of the team have  a domain admin account (for use only when working on Domain Controllers or other tier 1 systems).

 

Currently this means any changes to users accounts/groups and/or group policy is done on a DC with a DA account.  Adding privilege levels to delegate group policy management or group management adds more complexity that benefit at the 4 people-2000 user scale (in my opinion). We do however delegate password reset right for objects in the student OU to a group of which our daily driver accounts are members.  

 

We have also implemented best practice around accounts used by Configuration Manager.

 

 

 

 

 

[Olliedawg]

Here we have the below, i might re think this sometime though.

 

Everyday user account 

- this account is local admin on the techs laptop, also has some delegated permissions in AD to change passwords, view LAPS, view bitlocker keys etc..

 

Server account 

- each tech has a "server" user account, which has rights to log into the VM's via group policy. They have local admin access on the VM's (beside the domain controllers)

 

Test Staff & Student account

- duplicate staff/student account in special "test" OU which has duplicates of the GPO's for testing

 

DA account 

- we have 2 DA accounts, the main one, and a backup which isnt used. The DA credentials are not shared with the other techs & is stored away in the master password DB. I have been thinking about a DA for each tech too, but they can do 95% of what they need with delegated permissions anyway via RSAT