Let’s start with some credit first. Part of the title was borrowed from an article written by my dear colleague Nara. That article can be found here and is totally unrelated to this topic. Well, the relation is Active Directory, you know that old system that nobody uses and should have been gone for ages. 😜 You should read that article though!
Now back to the subject I wanted to write about which is also f(c)urious, at the least! The main topic today is “delegated Managed Service Accounts (dMSAs).
Windows Server 2025 (W2K25) has been out for a while. One of its coolest features, IMHO, is the availability of dMSAs. I will not discuss dMSAs in full as otherwise this article would turn out to be way longer than I anticipated. There is quite a lot to write about. I have delivered multiple presentations about dMSAs at multiple conferences.
For ages orgs have been using (legacy) service accounts (lSVCAs). Microsoft has tried to get orgs of those accounts with the implementation of Stand Alone Managed Service Accounts (sMSAs) and Group Managed Service Accounts (gMSAs). Fast forward many years later and lSVCAs are still being used, some with passwords so old it would make you cry. Hence the intro of dMSAs. The core idea of a dMSA is to allow orgs keep using a lSVCA where those a re being used today and from an authentication perspective link it to a dMSA so that the dMSA takes over the authentication. Reason? Well the password of the lSVCA is very likely something very weak and probably static (i.e. “Password Not Expires”), whereas like a gMSA, the password of a dMSA is rotated every 30 days by default when not specifying a custom password rotation interval. TIP: DO NOT use the default password rotation interval (for both gMSAs and dMSAs!), but rather use a much lower value like 2 to 5 days, which needs to be specified during the creating of the object. With this everyone is for sure running to start migrating lSVCAs to dMSAs! Well, in reality…..unfortunately NO! “Why?”, you ask?
dMSAs have some requirements and those are unfortunately so strict that current application landscapes are not moving anywhere and therefore not using those as quickly as everyone would want it.
Requirements For Using dMSAs:
- At least 1 W2K25 RWDC is needed in the AD domain to support authentication for dMSAs, but in reality you need more than 1, trust me you do! If you do not have enough W2K25 RWDCs, it will very likely overburdened if many W2K25 servers with dMSAs are targeting the single or small amount of W2K25 DCs.
- NO special AD or DC configuration is needed besides having the W2K25 schema to be able to create the dMSA object. That is of course already taken care of by having at least 1 W2K25 RWDC. Besides that, nothing else is needed in AD!
- On every computer where you want to use the dMSA the operating system MUST be W2K25. That is the case today and unfortunately no backporting to W2K22 or even W2K19 (HINT1)
- On every W2K25 computer where you want to use the dMSA, support must explicitly be enabled (HINT2)
Enabling dMSA support can be done through a GPO to target specific W2K25 computers or in the registry of individual W2K25 computers
Through a GPO…
Through the registry…
$dmsaStateParams1 = @{ Path = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters" Name = "DelegatedMSAEnabled" Value = 1 # 1 = Enabled, 0 = Disabled (Default) Type = "DWORD"}Get-ItemProperty $dmsaStateParams1.Path $dmsaStateParams1.NameSet-ItemProperty @dmsaStateParams1Get-ItemProperty $dmsaStateParams1.Path $dmsaStateParams1.Name$dmsaStateParams2 = @{ Path = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters" Name = "DmsaRealms" Value = @("<REALM 1>","<REALM 2>","<REALM X>") Type = "MultiString"}Get-ItemProperty $dmsaStateParams2.Path $dmsaStateParams2.NameSet-ItemProperty @dmsaStateParams2Get-ItemProperty $dmsaStateParams2.Path $dmsaStateParams2.Name
Now let’s discuss what happens when you enable support to use a dMSA on ANY W2K25 computer (HINT3). To keep it simple, that W2K25 computer will ONLY look for W2K25 DCs for authentication in its own AD domain and any other AD domain its own AD domain has a trust with. And the kicker here is that you might think “ONLY for the dMSA authentication!”. That thought is unfortunately wrong! As soon as dMSA support on ANY W2K25 computer has been enabled, that computer will ONLY want to communicate with W2K25 DCs for ALL authentication requested by that W2K25 computer. Think of the authentication of its own computer account, any other service account (lSVCA, sMSA, gMSA) running on that computer and any user authentication! Therefore, yes ANY AUTHENTICATION! So in an environment with multiple OS versions for DCs things can get weird pretty quickly if not thought through. Your NON-W2K25 DCs will therefore be COMPLETELY ignored in the same AD domain and any other trusting AD domain.
The question is now: “Is it possible to ‘massage’ this ‘only W2K25 DCs for authentication’ behavior a bit? Yes fortunately that is possible! Unfortunately, I also consider this to be the weak part in the Microsoft documentation as IMHO it is not described as thoroughly as I think it should be. My personal experience is that I have made some mistakes in my own testlab(s), and with that the main reason for writing this blog post!
So in the same AD domain as the W2K25 computer you should not only have 1 W2K25 DC, but rather “enough” W2K25 DCs to accommodate all authentication requests from any W2K25 servers using dMSAs. In any other trusting AD domain you would also need to add W2K25 DCs to support authentication requests across that trust. Fortunately there is another easier option to stop the W2K25 computer from requesting W2K25 DCs across trusts. That is done by configuring, and therefore telling, the W2K25 computer (through the registry or preferably a GPO) which AD domains have W2K25 DCs (whether or not those AD domains have dMSAs). That part is accomplished by specifying both the FQDN and the NetBIOS name of the realms (a.k.a. AD domains) that have W2K25 DCs, therefore at least the AD domain of the W2K25 computer for which dMSA support was enabled. Summarizing this again, but in different words:
- To use an dMSA on a W2K25 computer (RWDC or Server), that W2K25 computer must first have dMSA support enabled, and the dMSA’s own AD domain must have W2K25 DCs
- If your AD estate only has W2K25 DCs (no other OS for DCs!), then NO realms need to be specified
- If you have multiple AD domains/forests, and you have a mixed environment regarding the OS of the DCs, then you must configure the realms. The rule of thumb to configure the realms is to configure every server using a dMSA (therefore dMSA is enabled) with all AD domains where W2K25 DCs exists. At a minimum that includes at least the own AD domain of the dMSA. If a realm is not specified, the W2K25 computer will use the non-W2K25 DC in other AD domain for authentication.
All the above somewhat summarizes the nuts and bolts of dMSAs in THIS context!
So in the beginning of 2025 I was researching dMSAs. My then W2K22 DC-based AD domain IAMTEC.NET did not have any W2K25 DCs. It had 3x W2K22 RWDCs and 1x W2K22 RODC. To test dMSAs I replaced 2x W2K22 RWDCs with 2x W2K25 RWDCs and 1x W2K22 RODC with 1x W2K25 RODC. 1 W2K22 RWDC was kept in place. I started with only that to play with dMSAs and see how those work and behave. That IAMTEC.NET AD domain had a trust with another AD forest called PARTNER.LAN that only had 1x W2K12R2 RWDC. Yes, Still have some old stuff in place for testing 😜.
To test dMSAs in IAMTEC.NET I created a GPO in that AD domain and linked it to the Domain Controllers only targeting W2K25 DCs through a WMI filter as the AD domain also had 1x W2K22 RWDC. In that GPO I ONLY enabled dMSA and DID NOT specify any realms as I was only working with that AD domain and nothing else. Back then I did not see the need for any other configuration! Did all my testing initially on those DCs.
Some time later I also upgraded my ADTEC.NET AD domain/forest that has a similar setup and added 2 additional W2K25 computers/servers and 1 additional W2K22 computer/server to perform additional tests. I did all my testing for the research and presented all that at some point in time in June at the Troopers 2025 conference in Heidelberg Germany. The configuration that I used in the IAMTEC.NET and ADTEC.NET AD domains/forest, was never removed!
Along the way I also tested in using TLS 1.3 and RC4 deprecation.
Fast forward to the beginning of 2026. As soon as the first W2K25 RWDC is introduced, the AD schema will be extended to support those DCs. As soon as the PDC FSMO is transferred onto the W2K25 RWDC, the following happens:
- The global security group “Forest Trust Accounts” (objectSid = <Forest Root Domain SID>-528) is created
- The global security group “External Trust Accounts” (objectSid = <Domain SID>-529) is created
I wanted to understand if those 2 new groups would add additional security measures to protect the trusted AD domain/forest from being attacked through the trusting AD domain/forest. That research can eventually be found in this blog post.
Below you see the environment I was working with.
TRUSTED AD FOREST
- Single AD Domain Forest
- FQDN = IAMTEC.NET
- NetBIOS Name = IAMTEC
- DFL = W2K16
- FFL = W2K16
- RWDCs
- R1FSRWDC1.IAMTEC.NET = W2K25 OS
- R1SCRWDC2.IAMTEC.NET = W2K25 OS
- R1FSRWDC3.IAMTEC.NET = W2K22 OS
- RODCs
- R1FSRODC1.IAMTEC.NET = W2K25 OS
TRUSTING AD FOREST
- Single AD Domain Forest
- FQDN = PARTNER.LAN
- NetBIOS Name = PARTNER
- DFL = W2K12R2
- FFL = W2K8
- RWDCs
- R2FSRWDC1.PARTNER.LAN = W2K12R2 OS
TRUST SETUP
- Type = Forest Trust
- Direction = One-way
- Trusted AD forest = IAMTEC.NET
- Trusting AD forest = PARTNER.LAN
- Authentication Scope = Forest-wide
To make sure my future upcoming tests and research would have a working starting point I wanted to validate the basics. Unfortunately that is where the misery started, where it took ages to resolve!
The error occurred when I on an RWDC in the IAMTEC.NET AD domain using Active Directory Users And Computers (ADUC) targeted the AD domain PARTNER.LAN
When trying to access the RWDC (R2FSRWDC1.PARTNER.LAN) in the other AD forest using a UNC path to its C drive, I got the error as shown.
My first reaction was: WTF! It took me ages to resolve this as there was nothing that gave me a hint of what was causing this. The weird part was that nothing was giving me any hint of what the underlying cause is/was. At first I thought of all the tests I had done to determine if that was impacting it or not. Long story short, NONE of the previous tests was causing this behavior, and some time like I learned “except one test”. I look at all kinds of logs in the Event Viewer, nothing! I bumped up diagnostic logging in the registry for the DC, nothing. At some point in time I realized I had forgotten one type of logging, being NETLOGON DEBUG LOGGING. This, amongst others, helps you troubleshoot account lockouts, and for this I was hopeful it would to.
So I decided to enable NETLOGON DEBUG LOGGING on the RWDC with the PDC FSMO role and restart the NETLOGON service, using the following PowerShell code:
Invoke-Command -ScriptBlock { Try { Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" -Name "DbFlag" -ErrorAction Stop Write-Host "" Write-Host "WARNING: A value already exists for 'DBFlag'. Make sure to record this!" -ForegroundColor Magenta Write-Host "" } Catch { } Try { New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" -Name "DbFlag" -PropertyType DWord -Value "0x2080ffff" -ErrorAction Stop } Catch { Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" -Name "DbFlag" -Value "0x2080fffe" } Try { Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" -Name "MaximumLogFileSize" -ErrorAction Stop Write-Host "" Write-Host "WARNING: A value already exists for 'MaximumLogFileSize'. Make sure to record this!" -ForegroundColor Magenta Write-Host "" } Catch { } Try { New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" -Name "MaximumLogFileSize" -PropertyType DWord -Value "104857600" -ErrorAction Stop } Catch { Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" -Name "MaximumLogFileSize" -Value "104857600" } Restart-Service NETLOGON -Force}
Then I tried the test as shown in figure 2 above. The next step is to check out the NETLOGON Debug Log
NOTEPAD.EXE $ENV:WINDIR\DEBUG\NETLOGON.LOG
Figure 5: Reviewing The Netlogon Debug Log
Do you notice the RWDC in the IAMTEC AD domain/forest specifically requesting a W2K25 DC in the PARTNER.LAN AD domain/Forest? When I saw this I immediately realized what was causing this. It was the dMSA configuration in the environment! As I used a GPO, this was the config.
So WHAT is wrong here and is the possible solution? A solution to fix the trust issue would be to DISABLE dMSA support. However that would prevent me from using a dMSA, which is not feasible! Have a look at the numbered list and specifically number 3. The real solution here is to defined the realms where the W2K25 DCs are. Remember this is a mixed environment with also non-W2K25 DCs in other AD forests (i.e. PARTNER.LAN). So, looking at the GPO it would need to look like:
Giving the DCs the time to reapply that GPO or forcibly running GPUPDATE /FORCE helps! Retrying the cross-forest access with ADUC, now works!
And something NOT to forget is to disable NETLOGON DEBUG LOGGING using the following code
Invoke-Command -ScriptBlock { Try { Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" -Name "DbFlag" -ErrorAction Stop } Catch { } Try { Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" -Name "MaximumLogFileSize" -ErrorAction Stop } Catch { } Restart-Service NETLOGON -Force}
CONCLUSION
Unless in a W2K25 only DC environment (all AD domains/forests!) enabling dMSA support on a W2K25 computer without realm definition is OK.
However in a mixed environment with W2K25 DCs and other OS version DCs, especially in other trusting AD domains/forest, then when enabling dMSA support on a W2K25 computer you must also define the realms (a.k.a. AD domains) that have W2K25 DCs. This ALSO applies if that W2K25 computer is a DC. That helps to NOT break your trusts when using dMSAs! Make sure to check the numbered bullet list above!
Cheers,
Jorge
————————————————————————————————————————————————————-
This posting is provided “AS IS” with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### https://jorgequestforknowledge.wordpress.com/ ###################
————————————————————————————————————————————————————
Identity | Security | Recovery
————————————————————————————————————————————————————-
