Protect Tier 1. Sleep well at Night.
In case you have not yet protected Tier 0, consider reviewing our article about protecting Tier 0 the modern way. Tier 1 is more difficult to outline as there are typically different security levels, from highly critical (e.g. personal data or business secrets) to informative, or even public information. What remains the same is the “assume breach” approach: no matter which (Tier 1) system gets compromised, the infection must not spread. What causes us a lot of headaches is something we call “Permanently privileged Tier 1 accounts”: accounts which are members of the Local Administrators group on most (or even all) Tier 1 servers and left there indefinitely. This type of accounts draws attackers like moths to the flame, because by compromising a single account, attackers can gain full control of Tier 1. Optional Refresher: Lateral Movement (in Tier 1) In general, the term “lateral movement” refers to a group of techniques cyber criminals use to explore an infected network to find vulnerabilities, escalate and cement access privileges, and finally reach their ultimate target. It is called “lateral movement” because of the way the attackers move sideways from their initial point of entry to device, to application and so forth. The illustration below depicts how attackers move laterally across Tier 1: Attackers compromised T1-Server-01. Thanks to LAPS, lateral movement to other Tier 1 servers using the (local) Administrator account and password is unsuccessful. T1-Admin-01 logs on to T1-Server-01 to perform some administrative tasks, thereby exposing reusable credentials to the attackers waiting for their chance. Attackers steal reusable credentials from the server’s memory. Attackers move laterally to all T1-Servers accessible with the credentials stolen in step (3). Tackling the Security Challenge of standing Privileges Just-in-time (JIT) administration in Active Directory is a security practice that temporarily elevates user privileges only when needed, which massively reduces the risk of misuse. It works by granting privileged access for a limited time, ensuring that users can elevate only on a limited number of devices at the same time and are automatically removed from privileged groups after a defined period. By introducing JiT, we can get rid of identities which hold permanently privileged access to many systems at the same time. Let’s be very clear on this: JiT will not prevent a single server or account from being compromised, but it can prevent the attack from spreading by minimizing the window of opportunity for attackers to exploit elevated privileges. By limiting the duration and scope of privileged access, JIT administration reduces the chances of attackers moving laterally across the network and gaining control over critical systems. Due to complexity, pricing, and environmental overhead of many commercial JiT solutions, we were looking for an easier way to achieve secure JiT on a budget. The solution developed by Andreas Lucas and Andreas Luy is based on a PowerShell scripts, comes with a graphical user interface and is published on Github. So, what is still holding you back from protecting Tier 1? JiT on a Budget Please note: This is not an "official" Microsoft solution, but a project created and developed by people working in Microsoft Security Enterprise Services (which used to be known as Microsoft Consulting Services some time ago). The tool is written in PowerShell. Please review carefully before introducing in your environment. When doing that you will find some not yet documented features. We are working on improving the documentation. We also want to emphasize that implementing this tool is only one part of the journey to protect Tier 1 against today's attacks. JiT Configuration The configuration for the JiT solution will be stored in Active Directory. To make this possible an Active Directory Schema extension must be implemented. Even though most AD admins do not enjoy schema updates, AD turned out to be the perfect location for storing the JiT configuration: it is highly available by default, is less likely to be messed up (or even deleted) than config files. The solution uses an Active Directory object to save the general JiT configuration (like OU locations for T1-Servers or maximum allowed elevation time). In addition to that, an individual object is created for each T1-Server and a Container is used to hold individual objects for allowed delegations (in other words: which user is allowed to request elevation on which server/OU). JiT Automation After the JiT solution has been installed and configured, a Scheduled Task will be running on the JiT Management Server every few minutes (step 1 in the illustration below). This task runs in the security context of a gMSA (group Managed Service Account) and monitors Active Directory for newly added Tier 1 servers (step 2). In case a new T1 server is found, the Scheduled Task creates an individual AD group for each new Tier 1 server (step 3, e.g. T1-Admin#Server-01). The group is automatically added to the according Tier 1 server’s (local) Administrators group through Group Policy (step 4). All these “Jit administrative groups” created are Tier 0 groups and cannot be modified by Tier 1 assets. At this point no T1-Admin is yet a local Administrator on any Tier 1 server. T1-Admins who want to self-elevate to local Administrator on a Tier 1 Server, must log on to the JiT Management Server (step 1 in the illustration below). Please note that the JiT Management Server is classified as a Tier 0 system. There they start a PowerShell-based elevation UI Tool and select the Tier 1 Server they want to request elevation for (step 2). A Scheduled Task running in the security context of a gMSA then adds their T1-Admin account to the T1 Server’s specific domain group (e.g. T1-Admin#Server-02) together with the requested time-to-live (TTL) (step 3). Now the T1-Admin-01 is an indirect member of the (local) Administrator’s group on the T1-Server-02 and can log on to this server to fulfill his admin tasks (step 4 in the illustration above). After a defined time span (TTL), the Privileged Access Management (PAM) optional feature ensures that the T1-JiT-Admin’s account is removed from the T1-Admins#T1-Server-02 group. In addition, the gMSA-based task ensures that the Jit-Administrator Groups will not contain ANY permanent membership in the (local) Administrators groups. The PAM optional feature essentially unlocks two new capabilities in the AD Forest: Temporary time-based group memberships, and shadow principals. Both were introduced to allow the implementation of a Red (or bastion) Active Directory Forest, using a MIM (Microsoft Identity Manager) for requesting temporary privileged access. However, our JiT solution only leverages the former to ensure that after the specified time has elapsed, the user will be automatically removed from the security group (without administrator intervention). Find more information about possible drawbacks when enabling the PAM option feature, check out our colleague's blog: https://ryanries.github.io/?title=possible_performance_pitfall_privileged_access_management.html Let’s get started Now is the time to protect Tier 1. For too long, this critical layer has remained vulnerable—not because it’s unimportant, but because safeguarding it seemed too complex or resource-intensive. That’s no longer the case. With a simple and effective solution now available, there are no more excuses. Protecting Tier 1 is not just a technical necessity—it’s a strategic imperative. Let’s take this opportunity to secure what matters most, before it’s too late. The code and detailed documentation are provided at https://github.com/Kili69/Just-in-time.Can I use Azure Just in Time (JIT) RBAC without PIM e.g. as a standalone solution
Hello I saw a video show PIM (Privilaged Access Management) and part of it Showed using Just In Time administration to allow a user (after MFA authentication) to elevate to admin to do some work for a set period of time). I need to know more about JIT for RBAC whereby I want to for example give someone the ability to elevate their role (to contributor for example) via MFA or some kind of admin approval, so they can perform a task then their contributor role expires (without necessarily using PIM). However I am having great difficultly finding vidoes, documentation (prefer good videos if available) showing how to set this up and make it work with a few examples and what level of Azure subscription you need to allow JIT RBAC Can someone please advise and point me towards some good vidoes or blog articles on this please Thanks __AAnotherUser
