Promoting a domain controller with PowerShell: the short version

Vitalii Shumylo — Thu, 22 Oct 2026 09:51:44 +0000

Promoting a Windows Server to a domain controller takes two steps, and most failed promotions come from skipping the groundwork before them. The server needs its final name, a static IP address and a DNS setting that points at itself (or at the existing DC) before you start. Renaming a DC afterwards is possible, but it is a fiddly job you can avoid.

After that, install the role, run the matching Test- cmdlet, and only then run the real promotion. The test catches the usual problems (DNS, prerequisites, forest level) before anything is changed, so you do not find out halfway through a reboot.

For a brand-new forest, the first DC looks like this:

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools
Test-ADDSForestInstallation -DomainName 'corp.example.test' -DomainNetbiosName 'CORP' `
    -ForestMode 'Win2025' -DomainMode 'Win2025' -InstallDns

If the test passes, swap Test-ADDSForestInstallation for Install-ADDSForest. A second DC uses Install-ADDSDomainController instead, and the full guide also covers the checks that prove both servers really are working domain controllers: dcdiag, repadmin /replsummary and a DNS fix that people often forget on the second DC.

Read the full guide, with every step and the post-reboot checks: https://learnitlessons.com/articles/promote-domain-controller-powershell/

I also keep the lab scripts for this on GitHub: https://github.com/vitalii-shumylo/it-lab-scripts

Written with AI assistance and checked by the author.

Kerberoasting in plain words: find your exposed service accounts

Vitalii Shumylo — Thu, 22 Oct 2026 09:51:38 +0000

Kerberoasting is an attack on service accounts, and it works because Kerberos is doing exactly what it was designed to do. Any signed-in domain user can ask a domain controller for a service ticket to any account that has a service principal name (SPN). Part of that ticket is encrypted with a key made from the service account's password, so the attacker takes the ticket away and guesses the password offline. There are no failed logons and no lockouts to notice.

So the weak point is not Kerberos. It is a human-chosen password on an account with an SPN, made worse when the ticket uses RC4 instead of AES. Computer accounts and group managed service accounts (gMSAs) are safe from this because their passwords are long, random and rotated automatically.

The first job is to know which ordinary user accounts carry an SPN:

Get-ADUser -Filter {ServicePrincipalName -like "*"} `
    -Properties ServicePrincipalName, PasswordLastSet, msDS-SupportedEncryptionTypes, adminCount |
    Select-Object Name, PasswordLastSet, msDS-SupportedEncryptionTypes, adminCount, ServicePrincipalName

An old password, an adminCount of 1 or no AES setting each push an account to the top of your list. The full guide shows how to move accounts to gMSAs, force AES, and spot an attack by watching event 4769 for RC4 tickets.

Read the full guide: https://learnitlessons.com/articles/kerberoasting-explained-prevention/

A read-only version of this audit is in my GitHub lab scripts: https://github.com/vitalii-shumylo/it-lab-scripts

Written with AI assistance and checked by the author.

DEV Community: Vitalii Shumylo

Promoting a domain controller with PowerShell: the short version

Kerberoasting in plain words: find your exposed service accounts