Question: We're a medium-sized enterprise with many different IT administrators (e.g. domain admins, Azure admins, DB admins, ...). We're worried that hackers can easily breach an admin's laptop and through that steal data / do serious harm. 

We thought about using VDI / jump server so that an admin would connect from his personal laptop to that remote machine and administer the network through that. However, it doesn't seem to really solve the problem as if an attacker owns the admin's personal laptop, he can simply control the remote machine. 
We also read about [Privileged Access Workstations](https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/privileged-access-workstations) (PAW). While the approach seems safer, it's too cumbersome for our users and requires discipline.

What's the best (practical) way to protect IT administrators?

Answer: 
I agree with and would like to expand on Odo's answer. I know for our organization the idea of a dedicated PAW was great, but the practicality of implementing one based on actual STIG guidelines wasn't there. Especially for SMBs, having a dedicated access VLAN with that machine with only specific admin accounts it's a little more than most can handle. We ended up implementing an environment akin to what odo suggested. We have multiple administrators who perform various tasks across multiple sites, and so the threat vector for someone to gain admin access to our DCs was significant. I think you'll find though if you really consider your roles, there are only a handful of admins who actually require full domain admin permissions on your DCs. We ended up creating (for lack of a better word) an elevation admin group that our everyday IT admins used on everyday workstations. These accounts have no administrative privileges on the servers, and have actually been denied logon privileges through GPOs. Due to restrictions in our environment we aren't able to use any mobile devices in our building, and don't have the budget for tokens, so MFA wasn't really an option. We ended up using Terminal Service GPOs (I think they're called RDS now though) to allow or deny remote access to accounts depending on their privilege level. For example the elevate admins aren't able to remotely log into any workstation, and domain admins aren't able to remotely login to any servers (should also mention any members of DA/EA are also denied from login on everyday workstations). This significantly helps prevent an attacker from stealing credentials that are used on a daily basis and wreaking havoc on your system. There's some pretty useful guidelines on this from a number of different sources, I (we) generally use [STIG templates](https://iase.disa.mil/stigs/Pages/a-z.aspx) to create our baseline. Some important ones to note which touch on the stuff above are Deny Log on for highly privileged domain accounts ([V-63877](https://www.stigviewer.com/stig/windows_10/2015-11-30/finding/V-63877)) and deny log on through RDS for highly privileged domain accounts ([V-63879](https://www.stigviewer.com/stig/windows_10/2015-11-30/finding/V-63879)). Your administrators would need to elevate in a UAC prompt using their privileged accounts, but it ensures that if their laptop or workstation is broken into, the attacker would need multiple sets of credentials really accomplish anything.
I'd separate administartors' less-privileged operational accounts (for day-to-day duties) from more privileged accounts like domain/db admin (which are used during changes in domain/database architecture - a much rarer tasks). 

Yes it could require fine-tuning, custom roles and so on, but during it you'll better understand your RBAC-related landscape.

For most privileged accounts I'd recommend shared passwords (i.e. half of password stored in warbox) combined with 2FA.