Disaster Recovery Planning for AD & Entra ID

Disaster Recovery Planning KB ID 0001911

Problem

When Disaster Recovery Planning for Active Directory (AD) and Entra ID (formerly Azure AD) is vital to ensure the continuity of identity services during failures, cyberattacks, or unforeseen disasters. Below is a structured approach to building a resilient disaster recovery strategy.

Solution: Disaster Recovery Planning

Define Objectives and Scope

Recovery Time Objective (RTO): Determine how quickly AD/Entra ID must be restored.

Recovery Point Objective (RPO): Decide how much data loss is acceptable.

Business Impact Analysis (BIA): Assess dependencies on AD and Entra ID within business operations.

Compliance Requirements: Ensure adherence to relevant standards like ISO 27001, NIST, or GDPR.

Active Directory (AD) Disaster Recovery Planning

Backup and Recovery

System State & Bare Metal Backups:

Back up system state data using Windows Server Backup or third-party tools (e.g., the AD database NTDS.dit).

Ensure backups cover at least two domain controllers per domain.

Securely store backups offline or on an isolated network.

Authoritative vs Non-Authoritative Restore:

Non-Authoritative: Used when other domain controllers are operational.

Authoritative: Restore a specific version or recover deleted objects.

Active Directory Recycle Bin:

Enable this feature for quicker recovery of deleted objects.

Test Restores:

Test recovery processes in a controlled environment to verify their success.

Redundancy and High Availability

Multiple Domain Controllers:

Deploy at least two DCs per site, configured as Global Catalogue Servers.

For remote or low-security locations, use Read-Only Domain Controllers (RODCs).

Active Directory Sites and Services:

Properly configure to optimise authentication and replication.

Regularly check replication health using tools like repadmin.

Time Synchronisation:

Keep domain controllers synced with a reliable NTP source.

Security Hardening

Least Privilege Access:

Implement a tiered administrative model with separate permissions for each level.

Deploy Just-in-Time (JIT) and Just Enough Administration (JEA).

Admin Security Enhancements:

Require Multi-Factor Authentication (MFA) for admin accounts.

Use Privileged Access Workstations (PAWs) for AD management tasks.

Security Information and Event Management (SIEM):

Monitor replication and logins with tools like Microsoft Sentinel or Splunk.

Recovery Procedures

Offline Domain Join (ODJ):

Pre-provision computers for seamless domain joining in emergencies.

Catastrophic Failures:

Restore domain controllers from a trusted backup in an isolated network.

Use Install from Media (IFM) for faster deployments.

Testing and Validation:

Simulate AD failures regularly to ensure recovery processes are sound.

Entra ID (Azure AD) Disaster Recovery Planning

While Entra ID benefits from cloud-based resilience, a backup plan is still necessary.

Backups and Exports

Native Limitations:

Microsoft does not offer traditional backup/restore functions. Export data regularly using Azure AD Connect Export or the Microsoft Graph API.

Third-Party Tools:

Use tools like Quest Recovery Manager or Veeam to back up objects.

Entra ID Recycle Bin:

Recover deleted data (users, groups, and roles) within 30 days.

Disaster Recovery Planning Resiliency and Redundancy

Hybrid Identity Redundancy:

Deploy multiple Azure AD Connect servers in Staging Mode.

Ensure failover for Pass-Through Authentication (PTA) by deploying multiple agents.

Conditional Access:

Maintain break-glass accounts (MFA-protected cloud accounts) for emergency access.

Configure fallback authentication like Password Hash Sync.

Disaster Recovery Planning Continuous Testing

Recovery Tests:

Conduct quarterly drills and failover tests.

Maintain an isolated testing environment.

Security Audits:

Perform penetration testing and red-team exercises to identify weaknesses.

Disaster Recovery Planning Documentation

Maintain clear and up-to-date runbooks for all DR processes.

Automate repetitive tasks using PowerShell or Azure Automation.

Review and revise your disaster recovery plan regularly to keep it current.

Disaster Recovery Planning: Conclusions and Final Thoughts

A solid disaster recovery plan for AD and Entra ID includes:

  • Regular backups and restores.

  • Redundant systems to ensure continuity.

  • Strict security to mitigate risks.

  • Comprehensive testing to validate all recovery processes.

Related Articles, References, Credits, or External Links

NA

Windows – Setting Domain Time

Domain Time KB ID 0000112

Problem

If you have arrived here, you have either noticed that the time is wrong on your server(s) or client PC(s), or you have looked in the event viewer and seen one of the following events being logged. Event ID’s 12, 22, 29, 36, 38, 47, and 50.

Time Problem Events – On the PDC Emulator

Event ID 12 (W32 Time Time Provider NtpClient: This machine is configured to use {text omitted}, but it is the PDC emulator…).

Event ID 29 (The time provider NtpClient is configured to acquire time from one or more time sources…).

Event ID 36 (The time service has not synchronized the system time for 86400 seconds…).

Event ID 38 (The time provider NtpClient cannot reach or is currently receiving invalid time data from…).

Event ID 47 (Time Provider NtpClient: No valid response has been received from manually configured peer…).

Domain Time Problem Events – On Domain Members

Event ID 50 (The time service detected a time difference of greater than 5000 milliseconds for 900 seconds…).

Event ID 22 (The time provider NtpServer encountered an error while digitally signing the NTP response for peer…).

Solution : Domain Time Problems

Setting domain time is a TWO-STEP process, set the time correctly on the PDC emulator, then let the clients take their time from the PDC emulator.

Locate the PDC Emulator

1. On a domain controller, Windows Key+R > netdom query fsmo {Enter}.

2. Take note of the PDC name and go to that server.

NTP Firewall config (Domain Time)

1. Ensure UDP Port 123 is open outbound from the PDC Emulator. How this is done will vary depending on your firewall vendor. If you have a Cisco ASA or a Cisco PIX see my article here.

To Test Use NTPTool

Below either the port is blocked (or the hostname/IP of the external NTP server is incorrect);

This is how it should look, every-time you press query you should get a response, now you know the correct port is open;

Configure the PDC Emulator to collect Reliable Domain Time

There’s two ways to do this, 1. Use Group Policy, and 2. Use command line.

Setting PDC Emulator Time With Group Policy

Of course our PDC Emulator is also a domain controller, so we need to link a GPO to the domain controllers OU. But we dont want all DC’s getting their time from an external source, so we will create a WMI filter to ensure the policy will only apply to the PDC emulator server.

Administrative tools > Group Policy Management > WMI Filter > New > PDC-Emulator-Only > Add > Select * from Win32_ComputerSystem where DomainRole = 5 > OK.

Don’t panic if you see this error > OK > Save.

Create a new GPO linked to the Domain Controllers OU.

Change the policy so it uses your WMI filter;

Edit The Policy, and navigate to;

[box]Computer Configuration > Policies > Administrative eTemplates > System > Windows Time Service > Time Providers[/box]

Configure Windows NTP Client

Enable the policy > set the NtpServer setting to server-name(comma)stratum-type(space). If you get this wrong you wont sync, and you will see this error.

Enable Windows NTP Client

Enable the Policy (The server still needs to get its time from the external source!)

Enable Windows NTP Server

Enable the policy (The server also needs to provide time to the domain clients).

Save and exit the policy editor, then on the PDC emulator force a policy update  and resync the time. Finally run rsop to make sure the settings have applied.

Setting PDC Emulator Time From Command Line

 

1. On the PDC emulator Windows Key+R > cmd {Enter}.

2. At command line execute the following four commands;

[box]

w32tm /config /manualpeerlist:ntp2d.mcc.ac.uk /syncfromflags:manual /reliable:yes /update

net stop "windows time"

net start "windows time"

w32tm /resync 

[/box]

Note: If you are NOT in the UK or simply want to use a different NTP time server go here for alternatives.

3. Look in the servers Event log > System Log for Event ID 37.

 

---------------------------------------------------------------
Event Type: Information
Event Source: W32Time
Event Category: None
Event ID: 37
Date: xx/xx/xxxx
Time: xx:xx:xx
User: N/A
Computer: {servername}
Description:
The time provider NtpClient is currently receiving valid time 
data from ntp2d.mcc.ac.uk (ntp.m|0x0|10.0.0.1:123->130.88.203.64:123).

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. —————————————————————

4. You will also see Event ID 35.

---------------------------------------------------------------
Event Type: Information
Event Source: W32Time
Event Category: None
Event ID: 35
Date: xx/xx/xxxx
Time: xx:xx:xx
User: N/A
Computer: {servername}
Description:
The time service is now synchronizing the system time with the time source 
ntp2d.mcc.ac.uk (ntp.m|0x0|10.0.0.1:123->130.88.203.64:123).

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. —————————————————————

Step 2 Check the domain clients

This is all you should need to do, because, (by default) all Domain clients get their time from the PDC when they log on, but to check;

1. Windows Key+R > cmd {enter}.

2. Execute the following command;

[box] w32tm /monitor [/box]

3. You will see the time this client can see, on all the domain controllers.

[box]

C:Documents and SettingsAdministrator.yourdomain>w32tm /monitor
server-dc.yourdomain.co.uk [192.168.1.1]:
ICMP: 0ms delay.
NTP: +363.2032725s offset from server-pdc.yourdomain.co.uk
RefID: server-pdc.yourdomain.co.uk [192.168.69.6]
site2-dc.yourdomain.co.uk [192.168.2.1]:
ICMP: 70ms delay.
NTP: +0.0470237s offset from server-pdc.yourdomain.co.uk
RefID: dc.yourdomain.co.uk [192.168.69.4]
serverdc2.yourdomain.co.uk [192.168.1.4]:
ICMP: 0ms delay.
NTP: +0.0000553s offset from server-pdc.yourdomain.co.uk
RefID: server-pdc.yourdomain.co.uk [192.168.1.6]
server-pdc.yourdomain.co.uk *** PDC *** [192.168.1.6]:
ICMP: 0ms delay.
NTP: +0.0000000s offset from server-pdc.yourdomain.co.uk
RefID: scarp.mc.man.ac.uk [130.88.203.64]

[/box]

(In the case above the time on server-dc is way out, address that first – (it was an old Windows 2000 server and running “net time server-pdc” {enter} fixed it).

4. Once all the domain controllers have a time that’s accurate (like the last three in the example above), then proceed.

5. Execute the following commands on a client machine;

[box]

net stop "windows time"

net start "windows time"

w32tm /resync 

[/box]

6. The machines event log should show the following successful events;

Event ID 37 (The time provider NtpClient is currently receiving valid time data from..).

Event ID 35 (The time provider NtpClient is currently receiving valid time data from..).

Setting Domain Clients Time via GPO

As already outlined you should not need to do this, (as it’s the default setting,) but if there’s a problem you can force domain clients to look at your PDC emulator for reliable time.

Create a GPO, and link it to the OU containing the computers you want to sync’

Edit the policy and navigate to;

[box]Computer Configuration > Policies > Administrative eTemplates > System > Windows Time Service > Time Providers[/box]

Configure Windows NTP Client

Enable the policy > Set the NtpServer to {Your-PDC-Name},0x9  > Set the Type to NT5DS.

Enable Windows NTP Client

Enable this policy.

Testing Client NTP Settings

Either run;

[box]w32tm /query /status[/box]

Or run RSOP.

 

Related Articles, References, Credits, or External Links

PDC Emulator: PDC Emulator: Cannot Sync Time From External NTP Server

Cisco ASA – Configuring for NTP 

 

Rename a Domain Controller

Rename a Domain Controller KB ID 0001886

Problem

I’ve done a few migrating to {version} domain controller articles, and today I got asked,

How can you rename the “Server Name” back to the old one after migration ?e.g. from “Lan-2025” to “Lan-2019”

So, as the VMs from the last article were still running on the test bench, I ran though it to demonstrate.

Solution: Rename a Domain Controller

If you would like to add a new Windows Server 2025 domain controller to an existing domain here is the procedure.

Note: if you are not changing the domain controller name to a previous one, and simply want to rename a DC to something else, skip to THIS SECTION.

Rename a Domain Controller: Remove Stale DNS records

Never assume that demoting, and removing the old DCs does a great job of tidying up DNS it does not. So before we rename out new DC to the old DC name let’s make sure there’s nothing ‘hanging about’ that needs to be cleaned up. You can of course go hunting for them manually and remove them, but why when we have PowerShell. Typically a simple domain will have a” _msdcs.domain-name.domain-extension” and a “domain-name.domain-extension” forward lookup domain. (Your DNS server might have many forward lookup zones so run through them sequentially.

I’m stating with my _msdcs.test.net forward lookup zone, First I’m reading in ALL the DNS records for that domain.

[box]

$alldnsrecords = Get-DnsServerResourceRecord -ZoneName “_msdcs.test.netVIEW THE RESULTS BY SIMPLY CALLING THAT BACK

$alldnsrecords
[/box]

In my example there are not many records and I can see there’s none for the old DC name LAN-2019.test.net or for its IP address 192.168.110.10 so I’m skipping to the next step. Yours may have, if so you can delete them with the following commands;

[box]

$deadDC = $alldnsrecords | Where-Object {$_.RecordData.IPv4Address -eq “192.168.110.10” -or $_.RecordData.NameServer -eq “LAN-2019.test.net.” -or $_.RecordData.DomainName -eq “LAN-2019.test.net.”}

$deadDC | Remove-DnsServerResourceRecord -ZoneName “_msdcs.test.net

[/box]

Let’s do the same for my normal domain forward lookup zone test.net.

[box]

$alldnsrecords = Get-DnsServerResourceRecord -ZoneName “test.net

[/box]

As you can see (below) there a a few old records here for the LAN2019.test.net server, and a few for its old IP address (192.168.110.10) WARNING: I’m making the assumption your DCs have static IP addresses and those IP addresses ARE NOT in a DHCP scope, or some clown HAS NOT issued the old IP to another server!

Let’s filter those records so we just see the ones we are interested in.

[box]

$deadDC = $alldnsrecords | Where-Object {$_.RecordData.IPv4Address -eq “192.168.110.10” -or $_.RecordData.NameServer -eq “LAN-2019.test.net.” -or $_.RecordData.DomainName -eq “LAN-2019.test.net.”}

[/box]

And we can remove them with. (WARNING add -whatif to the end of the command if you are nervous and want to check what will happen before proceeding, if you are happy rerun the command without the -whatif switch).

[box]

$deadDC | Remove-DnsServerResourceRecord -ZoneName “test.net

[/box]

Rename a Domain Controller: Remove Stale Reverse DNS Records

Reverse DNS lookup zones typically are a lot easier to just do manually.

Rename a Domain Controller: Domain Cleanup

There should not be any need to do a metadata cleanup if the demotion and removal went smoothly, but there will probably be some junk left behind. I’ve demoted the old DC and removed it from the domain, but the computer object still remains (in a disabled state) let’s remove that.

    

Also often there’s an orphaned object in sites and services for the old DC, let’s remove that.

Rename a Domain Controller

Finally! The process is simple, we add a secondary name to the Domain controller (the old DC name), then we make that second name the primary name, reboot the server, and remove the unwanted server name. To add a new secondary name open an administrative PowerShell Window and use the following syntax.

[box]

netdom computername LAN-2025.test.net /add:LAN-2019.test.net

THEN TO VIEW THE RESULTS

netdom computername LAN-2025.test.net /enumerate

[/box]

Change the OLD DC name to be the primary with the following command, which will need to reboot the server, so then execute a Restart-Computer.

[box]

netdom computername LAN-2025.test.net /makeprimary:LAN-2019.test.net

Restart-Computer

[/box]

REMEMBER at this point the old and new server names have swapped, so your commands will now assume that (in this case) LAN-2019.test.net is the name of the DC you are on. Once the server has rebooted.

[box]

netdom computername LAN-2019.test.net /enumerate

CHECK THE NEW NAME IS LISTED FIRST, THEN REMOVE THE UNWANTED NAME

netdom computername LAN-2019.test.net /remove:LAN-2025.test.net

FINALLY CHECK AGAIN

netdom computername LAN-2019.test.net /enumerate

[/box]

Related Articles, References, Credits, or External Links

NA

Migrate to Server 2025 Domain Controller

Server 2025 Domain Controller KB ID 0001884

Problem

If you would like to add a new Windows Server 2025 domain controller to an existing domain here is the procedure.

Solution: Server 2025 Domain Controller

Server 2025 Pre Requisites

2025 Hardware Requirements

  • Processor: 1.4 GHz 64-bit processor (or faster) with support for security features.
  • RAM: Minimum of 512 MB (2 GB for Server with Desktop Experience installation).
  • Disk Space: Minimum of 32 GB or more, depending on the server installation options.
  • Network Adapter: Ethernet adapter capable of at least gigabit throughput.

Software Requirements

  • Operating System: Windows Server 2025 (evaluation version or full licensed version).
  • Static IP Address: Assign a static IP address to the server before promoting it to a domain controller.
  • DNS: The server should point to itself for DNS or to another DNS server that is already part of the Active Directory.

User Permissions

  • You must be a member of the Administrators group on the server where you are installing the AD DS role.

Minimum Required Functional Levels for Windows Server 2025

Note: These are estimated based on the previous versions of Window Server.

Forest Functional Level:

  • The minimum forest functional level required for Windows Server 2025 is expected to be Windows Server 2016.
  • This means all domain controllers within the forest must be running at least Windows Server 2016.

Domain Functional Level:

  • The minimum domain functional level required for Windows Server 2025 is expected to be Windows Server 2016.
  • This ensures that all domain controllers within the domain are running at least Windows Server 2016.

Additionally: Ensure your third party applications also support Windows Server 2025, e.g. AV, MDR, Endpoint protection, and backup solutions.

Server 2025 Domain Controller AD Services Role Installation

At this point I’m assuming your 2025 server is fully updated and added to the domain as a member server. Server Manager > Manage > Add Roles and Features.

You can tick ‘Skip by default’ if you wish > Next >  Next > Next > Tick ‘Active Directory Domain Services’ > Add Features (as shown) > Next.

Next >  Next > Next > Install > When complete click ‘Close’.

Server 2025 Domain Controller: Promote to DC

Once the role is installed, you need to actually promote the server so that it is a domain controller > From within Server Manager you will see you now have a waring triangle at the top of the screen, click it and you will get the option to ‘promote this server to a domain controller‘.

It will automatically assume that you want to promote it to be a Dc in the domain that you are in, ensure that the credentials used have the appropriate rights > Next > Check the Site is correct And enter a new DSRM password > Next > At the warning about ‘A delegation for this DNS server cannot be created…“*

Note: In case you are worried about this error, see the following article for peace of mind.
Windows – A Delegation For This DNS Server Cannot Be Created

Next > Next > Next,

Next > Next > Once the pre-requisite checks have passed > Install.

If you look in Active Directory Users and Computers > In the Domain Controller OU there, will be your new Domain Controller.

That’s the new Server 2025 Domain Controller successfully added as a new domain controller. Rember at this point if you are retiring any old Domain Controllers take a look at the following list of things to thing about.

Retiring a Domain Controller Checklist

  • DNS: Is the retiring domain controller specified in one of your DHCP scopes or been manually specified on servers/endpoints. Offenders are network printers, VMware ESX servers (or vCenters), Non Windows devices, Hardware appliances.
  • DHCP: Is the retiring domain controller Hosing a DHCP scope? Or involved in a HA DHCP scope, If so this will need migrating.
  • LDAP/Kerberos/AAA: Are there any devices that look to the IP/Name of the retiring domain controller that are providing authentication services e.g. RSA Appliances, Firewalls authenticating remote access, Door entry or security systems that lookup AD users. Note This includes IAS/NPS
  • MFA: Do you have an MFA system that required Active Directory? If so does that need migrating.
  • Email: Modens Microsoft Exchange does not care (as long as DNS works.) But older versions needed to look at a specific domain controller, and any third part email applications may need to do the same.
  • Third Party Applications: This is a bit of a catch all but in most cases, (especially in SMB environments) Other programs/applications/services sometimes get installed on domain controllers make sure you know what apps are on the old DC before retiring e.g. Printer auditing software, third party password and AD Management tools, Management consoles for other solutions, Agent software for monitoring AD users.
  • Backups: These days less of an issue, but if you backup solution had an Active Directory element, ensure that post migration id continues to function normally.

For the demotion and role removal procedure, please see the video (above).

Related Articles, References, Credits, or External Links

Migrate DHCP Scope

Windows: Migrate DHCP HA

Migrate NPS Server

Find Domain Schema Version

Find Domain Schema Version KB ID 0000025 

Problem

You want to upgrade or find out your current Schema version, or check that an” adprep / forestprep” command has worked correctly.

Solution

Find Domain Schema Version: PowerShell

Use the following sytax
[box]

Get-ADObject (Get-ADRootDSE).schemaNamingContext -Property objectversion

[/box]

Post Server 2016 Find Domain Schema Version

The value is populated with Server 2016 again.

If you check the value above on a domain that has Windows 2012 domain controllers, you will see the value is ‘not set’.

If the entry is blank;

Instead navigate to this registry key;

[box][HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSParameters[/box]

Locate the ‘Schema Version’ Note: the figure in brackets is the decimal value!

Find Domain Scheman Version For Windows Servers Before 2012 RTM

1. For Windows Server 2003 you will need to Install the Support Tools on your server. (2008, 2008 R2, and 2012 have the tools built in).

2. Press (Windows Key+R) > adsiedit.msc > {enter}

3. Right Click > CN=Schema,CN=Configuration,DC=domain,DC=com > Properties

<pNote: If you cannot see this you need to select “Connect To” then pick “Schema”.

4. On the Attribute Editor tab > Locate objectVersion.

 

What Are The Windows Server Schema Versions?

20: Windows 2000

30: Windows 2003 RTM, Windows 2003 SP1, and Windows 2003 SP2

31: Windows 2003 R2

44: Windows Server 2008 RTM

47: Windows Server 2008 R2 (and SBS 2011)

56: Windows Server 2012 RTM

69: Windows Server 2012 R2

87: Windows Server 2016 RTM

88: Windows Server 2019 RTM

88: Windows Server 2022

91: Windows Server 2025

Related Articles, References, Credits, or External Links

NA

Windows Server 2025 Domain Join

Server 2025 Domain Join KB ID 0001883

Problem

To perform a  Windows Server 2025 Domain Join (Local Domain). The end process is the same as it’s always been, they’ve just made the job of getting to there a little more convoluted, (this is the same with Windows 11).

 

Solution: Windows Server 2025 Domain Join

Before attempting to join the domain, let’s make sure we can ‘resolve’ the domain name, (because most domain join problems are DNS related). Whilst logged in as a (local) administrative user, click the Windows button > Windows PowerShell.

Ensure you can ‘ping’ the domain name (see below), Also here I verify that the IP address that responds in my domain controller (Note: this will only work if your DNS zone has a correctly setup reverse DNS zone!)

Click the Windows button > System.

System > About.

Advanced System Settings.

   

Computer Name.

Change.

Select ‘Domain’ and enter the domain name > OK > enter credentials that have the rights to join a machine to the domain* > OK

*Note: All domain users have the right to join x10 machines to the domain.

OK > OK.

OK > Restart Now > The server will reboot.

Ensure you don’t mistakenly log on as the local administrator > Other User > Then remember if you are logging on as domain administrator use DOMAIN/Administrator, or administrator@domain-name.domain extension.

Solution: PowerShell Windows Server 2025 Domain Join

Windows button > Open an administrative PowerShell window.

As above, before attempting to join the domain, let’s make sure we can ‘resolve’ the domain name, (because most domain join problems are DNS related).

Use the following syntax.
[box]

Add-Computer -DomainName {your-domain-name}

[/box]

When prompted, provide credentials that have rights to add computer object to the domain.

When successfully joined, you will be asked to reboot.

[box]

Restart-Computer

[/box]

Ensure you don’t mistakenly log on as the local administrator > Other User > Then remember if you are logging on as domain administrator use DOMAIN/Administrator, or administrator@domain-name.domain extension.

Leave a Windows Domain Using PowerShell

Firstly I’m making sure I am correctly domain joined by using the following command.

[box]

Get-WmiObject win32_computerSystem | Select-Object -ExpandProperty domain

[/box]

Then to ‘leave’ the domain use the following command.

[box]

Remove-Computer

[/box]

When prompted reply to Y for yes then to complete the process reboot the server with the following command.

[box]

Restart-Computer

[/box]

Leave a Windows Domain Using GUI

To do the same graphically, it’s just the reverse of a domain join, use the instructions above you get you to the following dialog then select workgroup, and enter the workgroup name.

OK > OK.

Close > Restart Now.

Related Articles, References, Credits, or External Links

How to Join a Windows Domain

Windows: Join Azure AD (AAD)

Windows Server 2022 Domain Join

How to Join Windows 11 to a Domain

Disable NTLM

Disable NTLM KB ID 0001880

Problem

NTLM (NT LAN Manager) is a suite of Microsoft security protocols intended to provide authentication, integrity, and confidentiality to users in a network. It is an older protocol that has been largely replaced by Kerberos, (since Server 2008 and windows Vista!) In modern Windows environments due to its enhanced security features. NTLM is a challenge-response authentication protocol used to authenticate a client to a resource on a network. It operates in three versions: NTLMv1, NTLMv2, and NTLMv2 Session Security.

Key Components

Authentication Process:

    • Challenge-Response Mechanism: NTLM uses a challenge-response mechanism where the server challenges the client, and the client responds with a value that proves its knowledge of the user’s password.
    • Session Security: Provides confidentiality (encryption) and integrity (signing) for data sent over the network.

NTLM Versions:

    • NTLMv1:
      • Uses DES (Data Encryption Standard) for encryption.
      • The client sends a hashed password, and the server compares it to the stored hash.
      • Known for its vulnerabilities, including susceptibility to replay attacks and weak password hashes (LM hashes).
    • NTLMv2:
      • Introduced to address the security shortcomings of NTLMv1.
      • Uses HMAC-MD5 for cryptographic operations.
      • Provides stronger encryption and better resistance to replay attacks.
      • Supports mutual authentication where both client and server authenticate each other.
    • NTLMv2 Session Security:
      • Provides additional security by creating a session key based on both client and server challenge-response pairs.
      • Ensures integrity and confidentiality for the session.

Components of NTLM:

    • User Authentication: Verifies the identity of a user or system requesting access.
    • Message Integrity: Ensures that messages are not tampered with during transmission.
    • Message Confidentiality: Encrypts messages to protect sensitive information.

Security Weaknesses

  1. NTLMv1:
    • Weak Hashing (LM Hash): The LM hash is derived from passwords in a way that is susceptible to brute-force attacks.
    • Replay Attacks: Can be exploited to reuse valid authentication tokens.
    • Lack of Mutual Authentication: Only the client is authenticated, not the server.
  2. NTLMv2:
    • Improved but Still Vulnerable: While it significantly improves upon NTLMv1, it is still not as secure as Kerberos and can be vulnerable to certain types of attacks, especially in environments where NTLMv1 is still supported for backward compatibility.

Deprecation and Modern Alternatives

  • Kerberos: Introduced in Windows 2000, Kerberos provides stronger security features, including mutual authentication, and is now the default authentication protocol in Active Directory environments.
  • Recommendations: Organizations are encouraged to disable NTLM where possible, particularly NTLMv1, and to use Kerberos or other modern authentication protocols.

In Summary

NTLM played a crucial role in early Windows network security, providing a means of authenticating users and securing communications. However, due to its security vulnerabilities, especially in NTLMv1, it has been largely replaced by more secure protocols like Kerberos. NTLMv2 offers improvements but is still not as robust as modern alternatives, making it advisable for organizations to phase out NTLM in favour of stronger authentication methods.

As of Jun 2024 Microsoft has declared that NTLM (all versions) are depreciated.

Solution : Disable NTLM

Developers are being encouraged to STOP using NTLM, and the advice is to set your systems to ONLY use NTLM if Kerberos is not available. You first challenge is to find out what (if anything) is still using NTLM.

On your server(s) look in the (Security) Event logs for Event ID 4624 That mentions NTLM.

But there’s thousands of Event ID 4624 events, so let’s narrow the search with some PowerShell.

[box]

$query= @"
    <QueryList> 
           <Query Id="0"> 
              <Select Path="Security"> 
                *[System[(EventID='4624')]] 
                 and 
                *[EventData[Data[@Name='AuthenticationPackageName'] and (Data='NTLM')]]
               </Select> 
           </Query> 
    </QueryList>
"@
Get-WinEvent -FilterXml $query

[/box]

Now I can review each of those events (by their time stamp!) and I’ve only got two offenders to investigate.

You can also have a reconnoitre with WireShark, and scan for ntlmssp.

Disable NTLM v1

It’s considered best practice to disable NTLM version 1 first, then wait for a while (a period of a few weeks,) then you can attempt to disable NTLM version 2 also.

Edit the Default Domain Controller Policy and Navigate to.

[box]

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options >  
Network Security: LAN Manager Authentication Level

[/box]

Settings;

  • Send LM and NTLM responses
  • Send LM and NTLM (use NTLMv2 session security if negotiated)
  • Send NTLM response only
  • Send NTLMv2 response only
  • Send NTLMv2 response only, Refuse LM: Domain controllers offer only NTLMv2 but still accept NTLMv1 authentication.
  • Send NTLMv2 response only, Refuse LM and NTLM: Domain controllers refuse LM and NTLMv1, accepting only NTLMv2.

To keep NTLM v2 and disable NTLM v1 choose the last option.

WARNING: This will effectively tattoo this setting into registry of the domain controller(s), even if you have a problem and revert the setting back to not defined, it will remain. If that happens to you, you can manually change the setting in the registry at.

[box]

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

[/box]

 

There’s six settings (0 to 5) that correspond to the ones in the group policy for further information see this article.

Disable NTLM Completely

Before proceeding its a good idea to enable the “Restrict NTLM: Audit NTLM authentication in this domain” policy then waiting a while longer and reviewing the logs, if something does appear you can simply add it to the “Restrict NTLM: Add server exceptions in this domain” policy

This time in the default domain controller’s policy navigate to.

[box]

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options >  
Network Security: Restrict NTLM: NTLM authentication in this domain

[/box]

  • Disable: the policy is disabled (NTLM authentication is allowed in the domain).
  • Deny for domain accounts to domain servers: the domain controllers reject NTLM authentication attempts for all servers under the domain accounts, and the “NTLM is blocked” error message is displayed.
  • Deny for domain accounts: the domain controllers are preventing NTLM authentication attempts for all domain accounts, and the “NTLM is blocked” error appears.
  • Deny for domain servers: NTLM authentication requests are denied for all servers unless the servername is on the exception list in the “Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain” policy.
  • Deny all: the domain controllers block all NTLM requests for all domain servers and accounts.

To stop client computers attempting to connect with NTLM you can edit the Default Domain Policy.

  • Network security: Restrict NTLM: Incoming NTLM traffic = Deny all accounts
  • Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers = Deny all

Related Articles, References, Credits, or External Links

NA

Migrate to Microsoft Entra Connect

 Migrate to Microsoft Entra Connect KB ID 0001857

Problem

You want to migrate from Microsoft Azure AD Connect to Microsoft Entra ID connect.

Let me let you into a secret, (at time of writing) Entra ID connect and Azure AD connect ARE THE SAME THING, if you go to download Entra ID connect, the file you will download is called AzureADConnect.msi. So what you want to do is, upgrade Azure AD Connect.

If your existing Azure AD connect is running on Window Server 2016 (or newer) you can simply ‘in place upgrade‘ the existing Azure AD connect to version 2 and there’s no need to migrate anything.

If you MUST Migrate, because you are deploying on a new server for example, the process is straight forward.

  • Install on New Server and put into Staging Mode.
  • Put Old Server into Staging Mode.
  • Take New Server out of  Staging Mode, (ensure there are no errors/problems).
  • Uninstall from Old Server.

Solution: Migrate to Microsoft Entra Connect

So if you simply want to perform an in place upgrade because your OS is Windows Server 2016 (or newer), use the following article.

Upgrade Azure AD Connect

If you’ve made it this far then you are WANTING to Migrate to Microsoft Entra ID Connect, or as previously mentioned migrate to Azure AD connect on another server!

Migrate to Microsoft Entra Connect Step One: Export Settings

On the Old Server, launch the Azure AD connect shortcut > Configure.

Select  ‘View or export current configuration’ > Next.

Export Settings > Save them (by default in C:\ProgramData\AADConnect) > Save > Exit.

Migrate to Microsoft Entra Connect Step Two: Import Settings

Assuming you’ve done nothing other than download the install package on the new server  > Run the installer package > Agree to the EULA > Continue.

Customise.

Select ‘Import synchronisation settings > In the Location section enter \\old-server-name\c$\ProgramData\AADConnect\filename.json >  Install.

From this point forward I will assume you want everything set the same, so other than usernames and passwords accept the defaults > Next.

Enter the password to authenticate to M365/Azure AD.

This next screen can be confusing because you can’t click Next, and it’s not apparent why! Next to your domain there should be a green tick, if there’s a red cross you need to select ‘change password’ > Then enter the (local AD account) account you use for synchronisation > Next.

Next.

Both options should be ticked by default > Install.

Exit.

Migrate to Microsoft Entra Connect Step Three: Put Old Server Into Staging Mode

I find this much easier to do with PowerShell, but I’ll put the graphical procedure below if you prefer. Issue the following two commands.

[box]

$aadSyncSettings=Get-ADSyncGlobalSettings
$aadSyncSettings.parameters

[/box]

Locate the ‘Microsoft.synchronize.StagingMode‘ section and you will see its value is set to ‘False‘ i.e. staging mode is NOT enabled (or it’s in production mode).

To change the value to ‘True‘ i.e. enable staging mode use the following command.

[box]

($aadSyncSettings.parameters | ?{$_.name -eq "Microsoft.Synchronize.StagingMode"}).value="True"
Set-ADSyncGlobalSettings $aadSyncSettings

[/box]

You can then  confirm that the staging mode value is set to ‘True’ with the following command.

[box]

$aadSyncSettings.parameters

[/box]

Migrate to Microsoft Entra Connect Step Four: Take the New Server Out of Staging Mode

On the New Server, use the following two commands.

[box]

$aadSyncSettings=Get-ADSyncGlobalSettings
($aadSyncSettings.parameters | ?{$_.name -eq "Microsoft.Synchronize.StagingMode"}).value="False"
Set-ADSyncGlobalSettings $aadSyncSettings

[/box]

You can then  confirm that the staging mode value is set to ‘False’ with the following command.

[box]

$aadSyncSettings.parameters

[/box]

Migrate to Microsoft Entra Connect Step Five: Check for Errors

On Premises: You can look in ‘Azure AD Connect Synchronisation Service.’

Microsoft 365: The main Admin console will tell you (in the user management pane).

Microsoft Entra Admin Panel: Look under identity > Provision from Active Directory.

Alternate Steps to Enable Staging Mode (From GUI)

On the Old Server, launch the Azure AD connect shortcut > Configure.

Configure Staging Mode > Next.

Enter your admin password > Next.

Tick to select ‘Enable Staging Mode‘ > Next.

Configure.

Exit

Alternate Steps to Disable Staging Mode (From GUI)

On the New Server, launch the Azure AD connect shortcut > Configure.

Configure Staging Mode > Next

Enter your admin password > Next.

Untick to deselect ‘Enable Staging Mode‘ > Next.

Configure.

Exit

Migrate to Microsoft Entra Connect Step Five: Uninstall Microsoft Azure AD Connect

On the Old Server, search for appwiz.cpl > run it > Select Microsoft Azure AD Connect > Uninstall > Yes > Remove.

Exit.

Related Articles, References, Credits, or External Links

Locate Your Azure AD Connect Server

Azure AD Connect: Correct Or Remove Duplicate Values

Cannot Recreate Azure AD ‘Local’ AD Connector

Forcing Azure AD Connect Sync