Windows server 2025 Forest and Domain functional levels.
As many will no doubt have noticed, there is a 2025 forest and domain functional level introduced in build 25941. The schema updates suggest these are delegated managed service accounts (dMSA) and 32k pagesize for the active directory database. Is there any documentation on these?
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.
WS2025 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.Microsoft Entra ID Continuous access evaluation and how it works!
Dear Microsoft Entra ID Friends, In this article, we take a closer look at Microsoft Entra ID continuous access evaluation. What is Microsoft Entra ID Continuous access evaluation (CAE)? https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation How should CAE support us? Microsoft Entra ID continuous access evaluation is a feature that helps to improve the security and resilience of cloud applications. It allows Microsoft Entra ID to issue access tokens that are valid for a longer time, but can be revoked immediately if there is a change in the user account or the tenant policy. This way, applications can enforce the latest security policies without relying on the expiration of the access tokens. For example, if an administrator disables a user account or changes the IP address range for accessing the application, the existing access tokens for that user will be invalidated and the user will have to reauthenticate with Microsoft Entra ID. This reduces the risk of unauthorized access and also reduces the number of token requests, which makes the application more resilient to network issues. Build resilience by using Continuous Access Evaluation https://learn.microsoft.com/en-us/entra/architecture/resilience-with-continuous-access-evaluation Revoke access in (near) real time with Continuous Access Evaluation Continuous Access Evaluation (CAE) allows Microsoft Entra applications to subscribe to critical events that can then be evaluated and enforced. CAE includes evaluation of the following events: User account deleted or disabled Password for user changed MFA enabled for user Administrator explicitly revokes a token Elevated user risk detected Let's examine CAE on the example of a connection with Microsoft Graph. Lets start with the following scenario: In the PowerShell ISE we create a connection with Microsoft Graph and in the background we record it all with the Fiddler tool. In the Fiddler tool we copy the access token: Now we can decode the access token on the web page https://jwt.ms/: We can see that the access token is valid for approximately 24 hour: With the fiddler tool we can see that the microsoft graph is continous access evaluation aware: Now lets generate an event that will revoke the access token: Back in the PowerShell ISE we can see that the access token is no longer valid (Request for re-authentication): In the Fiddler tool we can see that the access token is no longer valid: The exact info from Fiddler: I realize that this was not necessarily spectacular. It was simply important for me to share my experience with you. Nevertheless, I hope that this article was helpful. Thank you for taking the time to read the article. Best regards, Tom Wechsler P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on GitHub! https://github.com/tomwechslerActive Directory Vs Azure Active Directory
Active Directory (AD) and Azure Active Directory (AAD) are both identity management solutions from Microsoft, but they serve different purposes. In this blog post, we’ll explore the differences between AD and AAD and when you might want to use one over the other. Active Directory (AD) Active Directory is a service provided by Microsoft that is used to manage users, computers, and other resources in a Windows-based network. It was first introduced in Windows 2000 and has since evolved into the core identity management solution for most organizations that use Windows-based systems. AD is a domain-based directory service, which means that it is designed to work within a single organization’s network. AD stores user and computer account information, authentication and authorization data, and security policies. It also provides services such as Group Policy, which allows administrators to configure and enforce policies for users and computers in the domain. AD is typically deployed on-premises and requires a domain controller to operate. Domain controllers are servers that store and manage AD data and provide authentication and authorization services to users and computers in the domain. Azure Active Directory (AAD) Azure Active Directory is a cloud-based identity management solution that is used to manage users and groups, control access to cloud-based applications, and integrate with other cloud-based services. It is a multi-tenant directory service, which means that it can be used by multiple organizations at the same time. AAD provides many of the same features as AD, such as user and group management, authentication and authorization, and security policies. However, AAD is designed to work with cloud-based applications and services, and it does not require a domain controller. AAD is often used in conjunction with other cloud-based services, such as Office 365, Azure, and other SaaS applications. AAD provides a single sign-on (SSO) experience for users, which means that users only need to log in once to access all of the cloud-based applications and services that they have access to. When to use AD vs AAD AD is still the go-to solution for managing identity and access in on-premises Windows-based networks. If you are running a Windows-based network and you need to manage users, computers, and other resources within your organization, then AD is the right choice. AAD is best suited for organizations that are using cloud-based services and applications. If you are using Office 365 or other cloud-based services and you need to manage users and control access to those services, then AAD is the right choice. It is also possible to use both AD and AAD in a hybrid environment. In this scenario, AD is used to manage on-premises resources, while AAD is used to manage cloud-based resources. This allows organizations to maintain a consistent identity and access management strategy across their on-premises and cloud-based environments. Active Directory and Azure Active Directory are both powerful identity management solutions, but they serve different purposes. AD is designed for on-premises Windows-based networks, while AAD is designed for cloud-based services and applications. Depending on your organization’s needs, you may choose to use one or the other, or a combination of both in a hybrid environment.Double entries in userCertificate avoids Hybrid Join
Hey guys, I have an interesting situation at a customer. He utilizes a third party MFA provider while being on a federation. That means new computers never will have a registered state. For users it is mandatory that theirs clients have fulfilled the Hybrid Join to use M365 apps, what can be a real pain. So the Automatic-Device-Join task has to create the userCertificate on the OnPremises computer object, before it can be synchronized to Entra. Here comes the issue. In some cases we see that some computers will create two userCertificate entries. This situation will lead to an inconstistent Hybrid Join. I already tried to remove one of the certificates, but for me it is impossible to recognize which is the right one. Only solution for me was to remove both entries under userCertificate and let the Automatic-Device-Join task create a new one. Afterwards the Hybrid Join will work. I want to understand, which process or scenario might create the double userCertificate entries?Unable to add Azure Virtual Desktop Client Enterprise App to Conditional Access
We currently use conditional access to allow certain contractors to sign into VMs, and from these VMs, access other MS Apps. Currently we block all applications from outside the VM ip range, but exclude the Virtual desktop applications to allow the users to do the initial signin to the VM. When contractors are using the Virtual Desktop app, it seems to work ok. However, recently when signing in via the browser only and launching from there, the conditional access rule is blocking them as the application ID isn't in the exclude list, and we are unable to add it: a85cf173-4192-42f8-81fa-777a763e6e2c The documentation: https://learn.microsoft.com/en-us/azure/virtual-desktop/set-up-mfa?tabs=avd shows that web signins may originate from this application ID, but without the ability to add this to the exclusion apps, we cannot find another workaround that allows access via the browser. I also tried adding this app in to the policy via GraphAPI, but I get an error saying that this first party application isn't allowed. I need to know if there is another workaround or if Microsoft are planning to add this to the CA compatibility list? I'm not sure why some of the Virtual desktop apps are there but this one is not.Questions about moving Windows endpoint from locally joined domain to Azure AD
Just a couple questions, when moving a current AD domain joined endpoint (i.e. Windows 10/11 Pro) to Azure AD. 1. Does the user's desktop look/feel change upon their next Azure AD-centric login, versus their previous domain joined profile? 2. If there were previously changes pushed out to the endpoints via local AD Domain GPOs, do those changes still remain on the endpoint machine, even after the cutover to Azure AD? 3. Is there a way to have an Azure AD authenticating machine, while still allowing the machine to access local network SMB shares, if the Azure AD and Local AD domain are in hybrid mode?
Azure AD extension attributes from AD Connect
I'm struggling with finding my data in AAD. We've been running Azure Connect for years to bring the data from our on-prem AD over to our AAD instance. Back last spring, I expanded the scope of the fields we were bringing over; in Azure Connect I configured it to also send the uid from AD, where we were storing a value that I needed for SSO for a specific application. I was able to configure the claims rules for the enterprise application that I configured in AAD to send the value along to the app, and SSO works fine. My problem is where that data is. I'll be referring here mostly to Powershell commands to look at the users. If I run a Get-Azureaduser a user -- I've tried several, all who can successfully use the SSO -- then pipe that along to select to expand the extension properties, the extension property isn't even in the list. The one place I have found it is if I run Get-AzureADApplication | Get-AzureADApplicationExtensionProperty It is in the list of defined extension properties, targetting users. Ideally, I'd like to be able to see the value for a given user from AAD, and set it through Powershell as well. Help? Why doesn't it show up in the extension attributes for our users?
