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.
Entra ID Connect cloud sync: User and group sync is quarantined
Hi, I connected our on-premise AD with Entra ID with Azure AD Connect Cloud Sync. Agents are active, but User and group sync is quarantined with the following error. Error code: HybridSynchronizationContainerStateEnumerationFailed Error message: We were unable to process this request at this point. If this issue persists, please contact support and provide the following job identifier: AD2AADProvisioning.... Additional details: Encountered an error while enumerating container changes in the provisioning agent. Please make sure you are running the latest version of the agent. Contact support if the issue persists. Additional Error Details: UnwillingToPerform: The server cannot handle directory requests.. ResultCode: UnwillingToPerform, HResult: -2146233088, responseType: System.DirectoryServices.Protocols.SearchResponse, serializedResponse: {"MatchedDN":"","Controls":[],"ResultCode":53,"ErrorMessage":"error in module dsdb_paged_results: Unwilling to perform during LDB_SEARCH (53)","Referral":[],"References":[],"Entries":[],"RequestId":null}. I use SaMBa servers (4.19.4) as DCs. Agents are installed on Windows 2019 servers. How can I resolve the problem?
Dynamic group membership rules stopped working
We've been using the following the following dynamic membership rule to check if a user is a member of another group: user.memberOf -any (group.objectId -in ['2b930be6-f46a-4a70-b1b5-3e4e0c483fbf']) The group is an Active Directory group that is represented in Entra with the stated Entra group object Id. The validation fails for every user and looks like this: It seems that all out dynamic groups are affected and stopped working. Have you seen this before? Thanks.
Adding AD users to a specific security group
Hi Everyone, Sorry if this question has already been asked as I couldn't find an answer. I’m trying to write a PowerShell script that runs as a scheduled task to add AD users to a specific AD security group. The goal is for this to run daily. The script will first check the users' OU to determine if they are already members of the security group. If they are, it will skip them; if they are not members, it will add them to the group. I have created the following script, but I’m unsure if it's the best approach. Additionally, can this script be executed on a server that doesn’t have Active Directory installed? If AD must be installed, would it be ideal to run it on a Domain Controller? # Check if Active Directory module is already imported, import only if necessary if (-not (Get-Module -Name ActiveDirectory)) { Import-Module ActiveDirectory } # Define the base OU and security group $BaseOU = "OU=W11_USERS,DC=W11,DC=NET" $SecurityGroup = "HR" # Get all users from W11_USERS and its sub-OUs $Users = Get-ADUser -SearchBase $BaseOU -SearchScope Subtree -Filter * # Loop through each user and check group membership before adding foreach ($User in $Users) { $UserDN = $User.DistinguishedName # Check if user is already a member of HR $IsMember = Get-ADGroupMember -Identity $SecurityGroup | Where-Object { $_.DistinguishedName -eq $UserDN } if (-not $IsMember) { Try { Add-ADGroupMember -Identity $SecurityGroup -Members $User -ErrorAction Stop Write-Host "Added $($User.SamAccountName) to $SecurityGroup" -ForegroundColor Green } Catch { Write-Host "Failed to add $($User.SamAccountName): $_" -ForegroundColor Red } } else { Write-Host "$($User.SamAccountName) is already a member of $SecurityGroup" -ForegroundColor Yellow } } Write-Host "User addition process completed."
Enable MFA method
Dear, Currently in our company, the authentication methods policy > Microsoft Authenticator defaults to “any”. Either “passwordless” or “Push”. It is possible to enable the following authentication method through a conditional access policy, currently it is enabled for some users. Desired authentication method: The current method is as follows: Can it be enabled for professional accounts or is it only focused on personal accounts? Thanks in advance.Access Package Approval automation with our Servicedesk ticketing tool
Hi Team, I am trying to automate all the access package approvals to be logged in our Service desk ticketing tool. Example: When a user requests access, once an approval request triggers from Microsoft it should also log a ticket in our ticketing tool. If the request got approved, the ticket should log this information & automatically gets closed. Our ticketing tool dev team is working on it however, they are stuck in the middle & looking to extract the necessary webhook information required for triggering actions from the Azure solution. Any input or guidance regarding webhook information supported by the Azure solution would be greatly appreciated and would assist us in progressing with the discussed requirements accordingly. Looking forward for your help to achieve this. Thanks, GarimaWS2025 Preview (26100.1) fails to boot after joining WS2016 forest
I installed WS2025 Preview (Datacenter, 26100.1) in a virtual machine and after joining the domain, the box is rendered unbootable (boot loops). I can reinstall and do other tasks as a standalone server with no problem but joining the domain immediately bricks the VM, 100% of the time. The forest is running at functional level WS2016. I disabled all GPs and verified with gpresult they are not applied. Safe mode boots if you need me to poke around. Am working to get a kernel debugger attached. No memory dump is generated and disabling reboot on errors yields nothing.
SSRS group adding
Hi everybody, I have an SQL server with SSRS. The reports work fine, but the reports are only available with the administrator profile. So I thought I would like to add another "profile" which is only for reading data. I created a new AD group, which is 'DOMAIN\users_test' but when I want to add the group on SSRS webpage I've got the following error message: "The user or group name 'DOMAIN\users_test' is not recognized." I have no idea what should I do. Can you give me some advice? Thank you. PN
API-driven provisioning to on-premises Active Directory mapping of the manager not working anymore
Hello Guys, I have a problem with the provisioning service of the above enterprise application. The whole time it was working fine until yesterday when I changed an attribute mapping (not the manager mapping) and now the manager is not sync because he can't lookup the manager, with every user even though the all worked before. Error: UnableToResolveReferenceAttributeValue Someone have an Idea or the same problem?Microsoft Entra Hybrid Join Issue Despite Setting Up All Essentials
I’m facing an issue where my client computer is unable to join Hybrid Azure AD, even though I’ve already set up all the essential steps, I downloaded that Microsoft Entra Connect Sync tool from the official site and did all the necessary steps. including configuring the SCP (Service Connection Point). Our main server is in New York, and our branch office is in Asia region, I want to have Microsoft Entra Hybrid Joined to all of my office PC in order to apply some conditional access policies. Despite these setups, the device fails at the discovery phase, and I can’t figure out what’s missing. This is what it says when I try to manually add the client PC TenantInfo::Discover: Failed reading registration data from AD. Defaulting to autojoin disabled 0x800706ba DsrCmdJoinHelper::Join: TenantInfo::Discover failed with error code 0x801c001d. Has anyone encountered a similar issue? Any guidance or troubleshooting tips would be greatly appreciated. Thanks!
