Microsoft moved on from Active Directory. Should you?

Organizations should evaluate moving from Active Directory if identity needs now span cloud, Linux, Macs, and SaaS. Microsoft moved to Entra ID for a reason. Wholesale migration only makes sense when legacy LDAP and Kerberos dependencies are eliminated or replaced. Incremental migration reduces risk. Assess your actual directory usage first.

1. The scar tissue

Every organisation of a certain age carries an Active Directory scar. It usually formed the same way. A single forest was stood up in the early 2000s to solve Windows authentication, and over two decades it quietly absorbed every identity problem the business ever had. Linux boxes joined the domain because someone needed Kerberos tickets for NFS. Postgres started binding to LDAP because it was the only directory anyone trusted. Macs got MCX policies bolted on. AWS accounts grew a Managed Microsoft AD instance because the on premises forest could not be trusted to reach the VPC. None of this was a strategy. It was accretion, and accretion is how you end up running a domain controller that nobody remembers commissioning but everybody is terrified to switch off.

The deeper problem is not that Active Directory is old. It is that twenty years of accumulation converted a design decision into an assumption. Servers join the domain because servers join the domain. Applications authenticate over LDAP because LDAP was there when they were written. Service accounts live in AD because that is where service accounts live. Nobody chose any of this recently, which means nobody has evaluated whether it is still the right answer, which in turn means the organisation has lost the ability to make a decision about its own identity architecture.

That is what this article is about. Not that you should abandon Active Directory because it is legacy, but that the disruption now being forced on you is the first opportunity in two decades to choose again, and that it would be a considerable waste to spend that opportunity recreating the same architecture somewhere else.

2. What Microsoft actually did

Let me qualify the headline before someone else does it for me, because the literal claim is easy to attack.

Microsoft has not abandoned Active Directory Domain Services as a product. Windows Server 2025 delivered the first meaningful AD DS investment in years. New domain controllers can be installed with a 32k page database using 64-bit Long Value IDs while running in 8k page mode for backwards compatibility, and there is a new Windows Server 2025 domain functional level, the first increase since Windows Server 2016, alongside a schema update, TLS 1.3 for LDAP over TLS, object repair capabilities, and delegated managed service accounts that bind authentication to specific machine identities to resist credential harvesting attacks such as Kerberoasting. Anyone claiming AD DS is being discontinued is simply wrong.

The accurate claim is narrower and considerably harder to dispute. Microsoft has not given up on supporting Active Directory. It has given up on Active Directory being the strategic centre of modern identity. Every genuinely new capability in Microsoft’s identity portfolio, conditional access, continuous access evaluation, risk based authentication, passwordless, workload identity, agent governance, arrives in Entra and not in AD DS. What arrives in AD DS is hardening, scalability, and the removal of protocols Microsoft would prefer you stopped using.

That second category is the forcing function. The 2026 Kerberos changes moved through audit, then default enforcement in April, then the July update removing the temporary registry rollback that let administrators defer the change. RC4 support is going, NTLM is following, and each step obliges identity teams to go and find every service account, appliance and forgotten scheduled task that still depends on the old behaviour.

It matters how you frame that. Microsoft’s RC4 deadline is not the reason to leave Active Directory. It is the event forcing organisations to discover how much they still depend on it. The inventory you are compelled to build in order to survive a hardening deadline is the same inventory you would need to plan an exit, which is why this year is when the question becomes answerable rather than merely uncomfortable.

3. Microsoft is offering you a migration, not an architecture

Here is where most AD modernisation programmes go wrong, and it happens in the first month.

The obvious path from self managed AD is Microsoft’s own managed equivalent. Entra Domain Services provides domain join, LDAP, Group Policy, Kerberos and NTLM as a managed service, with identities synchronised one way out of Entra ID. It is competent technology and Microsoft is honest about what it is for: primarily a transitional capability for Azure hosted workloads that still require legacy directory protocols, rather than a general replacement for AD everywhere.

Read that positioning carefully, because it has an architectural consequence that nobody in the sales cycle will spell out. Entra Domain Services places domain controllers in an Azure region and an Azure virtual network. Machines that consume those domain services need network connectivity to that virtual network, and Microsoft documents connectivity from other clouds as a supported VPN architecture rather than an unusual one.

So picture an organisation whose strategic compute platform is AWS taking the obvious migration path. A production EC2 instance now depends on AWS availability, on network connectivity from AWS to Azure, on Azure networking, on Entra Domain Services availability, on DNS resolution across that boundary, and on Kerberos and LDAP responding over it. Six dependencies where there were previously two, and one of them is a cloud the organisation has no strategic commitment to. That is not modernisation. In some circumstances it is simply cross cloud coupling with a managed service badge on it.

The principle I would put at the centre of any AD programme is therefore this. Do not confuse moving a dependency with removing a dependency. And its corollary: if you are going to endure the cost and risk of leaving Active Directory, earn the right to choose what replaces each of its functions.

There is an obvious objection to this, and it deserves a direct answer. If you federate AWS to Entra ID for human access, have you not created exactly the same cross cloud dependency you just warned against? Not really, and the distinction is important enough to state as a rule. AWS’s identity model is deliberately built around federation and temporary credentials, so once an identity has exchanged its proof for a role session, the credentials AWS issues are used against AWS resources without further reference to the identity provider. That is not immunity from an identity provider outage, since session initiation and renewal still depend on it. But it is fundamentally different from thousands of production machines continually reaching another cloud for LDAP binds, Kerberos tickets, DNS resolution and secure channel operations. Cross cloud federation is normal. Cross cloud runtime dependency should be a deliberate exception, made consciously, for named workloads, with the failure mode understood.

4. The five dependencies Active Directory bundles

The instinct when people hear “exit Active Directory” is to imagine ripping out authentication wholesale over a single weekend. That is not what happens in a well run migration.

AD was never one thing. It bundled a set of separable services into a single forest, and the exit strategy treats each of them separately. These are not everything AD does, and I will come back to the parts that resist this decomposition, but they are the five dependencies you have to consciously separate.

The first is human identity and authentication, proving that a person is who they claim to be. The second is machine and workload identity, the equivalent problem for servers, services and applications, which AD solves through computer accounts, service accounts, service principal names and group managed service accounts. The third is authorisation and governance, deciding what an identity may touch and being able to evidence why. The fourth is directory and compatibility services, the address book function of resolving a name to attributes and group membership, plus the LDAP and Kerberos surface that legacy applications consume. The fifth is policy and configuration distribution, the Group Policy machinery that pushes settings to joined machines.

Separating human identity from machine identity is the change that matters most, and it is the one most migration plans get wrong. For people you might reasonably choose Entra ID, Okta, Ping, Keycloak or something else, and the decision is largely about workforce lifecycle, governance integration and strategic independence. For workloads in AWS you have an entirely different set of primitives available: EC2 instance roles delivering temporary credentials, EKS Pod Identity and IRSA for containerised workloads, IAM Roles Anywhere issuing temporary credentials against X.509 certificates for things outside AWS. Those are not alternative authentication products competing with an identity provider. They are a different identity model, in which the machine never holds a long lived credential at all.

Bundling both problems under one heading called “authentication” is how organisations end up buying an identity provider and then discovering that it has not touched the reason their servers are still domain joined.

Once you see AD as five separable dependencies rather than one monolith, something more useful becomes visible. Some of these capabilities move to specialised systems. Some become native cloud capabilities. And some simply disappear. A domain joined EC2 instance becomes an instance with an IAM role. A domain based administrator login becomes a Session Manager session. An AD service account becomes an EKS workload identity. A GPO becomes a line in an immutable image build. An AD group may vanish entirely because authorisation moved into the application that actually cared about it. The objective is not to replace Active Directory with four or five products. It is to reach a state where you no longer need one.

5. Choose the destination before you choose the products

Before any migration sequencing, decide where you are going. There are four broadly coherent end states, and the right one depends on your compute strategy rather than on your identity team’s preferences.

One correction to a common framing, including one I have used carelessly myself. AWS Managed Microsoft AD is not a disposable LDAP cache. AWS describes it as an actual managed Microsoft Active Directory domain, supporting users, computers and directory aware workloads, with resource forest and trust options and a hybrid edition for extending an existing forest into AWS. It is genuinely useful, and for AWS hosted Windows workloads that need a domain it is architecturally far more sensible than reaching across to Azure. But it should be labelled accurately. Moving to it reduces operational burden. It does not constitute an AD exit, because what you are running is still Active Directory. OpenLDAP, by contrast, can serve a narrow directory lookup requirement for applications that only need to resolve users and groups, and it is a reasonable choice for exactly that and nothing more.

Then work through the decomposition question by question, because the answers are what determine your product choices rather than the other way round.

If you cannot answer those, you are not ready to start, and no amount of tooling will substitute for the decisions.

6. The hard bit: what happens to your Windows servers

Everything above is comfortable. This section is where large enterprises actually get stuck, and any AD exit article that skips it is not being honest with its readers.

Microsoft’s own documentation is clear that for Windows Server, domain join remains required in most situations. Windows Server 2025 can use Entra accounts in some contexts, but the general case has not changed, and Microsoft positions Entra Domain Services as the managed answer specifically for Windows Server VMs in Azure that need a domain. If you run twenty thousand Windows servers, the honest position is that you are not going to make Active Directory disappear from that estate on any timeline a board would recognise as a project.

What you can do is separate the estate into categories and shrink the domain to fit only the category that genuinely needs it.

Start with human administrative access, because this is usually the largest source of domain dependency and the easiest to remove. Ask why engineers need operating system level identities distributed through a directory at all. For AWS hosted servers, Systems Manager Session Manager provides audited, brokered access without inbound ports, bastion hosts or SSH keys, and the identity doing the accessing is an IAM principal federated from your identity provider. That removes interactive domain login as a requirement for a large fraction of servers without touching what the applications on them do.

Then handle machine and service identity. This is where group managed service accounts deserve a direct mention, because a reader will otherwise raise them as the obvious alternative to everything I am proposing. gMSAs, and the newer delegated managed service accounts in Windows Server 2025, are a genuine improvement over the old pattern of a domain user account with a password in a config file, since they rotate credentials automatically and bind authentication to specific machine identities to resist Kerberoasting. If you are staying on AD they are unambiguously the right answer, and where you have not adopted them you should. But recognise what they do to the exit. A gMSA solves the credential rotation problem by deepening the domain dependency, because the account only works because the domain issues it. Migrating service accounts to gMSAs is a hardening move, not a migration move, and the two should not be confused on a programme plan.

Next is Windows Integrated Authentication, which in practice means IIS applications and SQL Server. This is the single most common hard blocker in financial services, because a decade of internal applications were written on the assumption that the web tier could impersonate the caller into the database using Kerberos and nobody would ever need to think about credentials. Each of those applications requires a decision: modernise it to OIDC with the database accessed through a workload identity, wrap it behind an authenticating proxy that terminates modern authentication and presents Kerberos inward, or accept it into the compatibility island. There is no configuration change that makes this go away, and the honest estimate is that this is where most of your programme’s effort lands.

Then SMB and file services, which are underestimated for the same reason DNS is. Kerberos authenticated SMB with NTFS access control lists is a directory dependency embedded in file permissions across potentially millions of objects. FSx for Windows File Server keeps you domain joined by design. Moving to object storage is an application rewrite. The realistic answer for most estates is that file services stay in the compatibility island and shrink through consolidation rather than through migration.

Finally Group Policy. The useful reframing here is that GPO was always configuration management, just configuration management with no version control, no review process, and no ability to diff two states. Moving it to Ansible, DSC, image baking or MDM policy is not a downgrade, it is the same function performed in a way you can audit. The catch is that GPO also carries security baselines that auditors have accepted for years, so plan for a mapping exercise and evidence trail rather than a translation.

There is a category I have not listed, and it is the one that most often derails this work: AD Certificate Services. In most banks Active Directory is also the internal certificate authority, issuing device certificates, WiFi and 802.1X credentials, VPN certificates and S/MIME through autoenrollment tied to computer accounts. This matters enormously here because the target architecture in this article leans on certificates for mutual TLS and workload identity, which means a careless plan recommends a solution that quietly depends on the thing being decommissioned. Decide early where certificate issuance lives, whether that is AWS Private CA, Vault, or a standalone PKI, and sequence it before anything that consumes certificates.

8. The accelerant: why delay is getting more expensive

There is a second forcing function alongside Microsoft’s deprecation schedule, and it deserves naming plainly.

Frontier AI models have moved decisively into vulnerability research. The current top tier of capability, the class of models Anthropic calls Mythos, sits meaningfully above what was available a year ago at reading disassembled binaries, reasoning about protocol implementations, and chaining partial weaknesses into working exploit paths. Anthropic’s own reporting on this work describes complete working exploits produced against sophisticated targets. Kerberos, NTLM and AD’s delegation machinery are exactly the sort of decades old, densely documented, universally deployed protocol surface this suits, because the RFCs, the tooling, and twenty years of conference talks on AD attack paths are all public.

The practical effect is that the interval between a CVE being published and a working exploit existing is compressing, and it is compressing fastest for legacy infrastructure with poorly mapped dependencies. That is what I mean by a CVE wave. Not one bad patch Tuesday, but a sustained increase in the rate at which disclosed weaknesses convert into usable attacks, arriving at estates full of unpatched service accounts and delegation paths nobody has audited in a decade.

Two honest caveats. This does not mean the tooling is new in kind, since BloodHound and Mimikatz have automated much of this tradecraft for years. What changes is the speed and the breadth of coverage, which is enough to matter when your defence relies on obscurity about your own environment. And the second caveat cuts against my own argument: during the migration you will be operating two identity systems simultaneously, which is more attack surface, not less. The transition window is the most exposed period of the entire programme. That is an argument for resourcing it properly and compressing it, not for avoiding it, but it should be on the risk register rather than discovered later.

9. The programme: six phases

The sequence that works runs in six phases, and the order matters more than the calendar time each takes.

Phase one is discovery, because you cannot decommission what you cannot see. Phase two decouples human identity from the directory. Phase three removes machines and workloads from the domain. Phase four extracts DNS and the infrastructure services that hide inside the directory. Phase five deals with applications and data. Phase six moves governance and retires what remains. Only when all six are complete for a given population do you touch the domain controllers serving it, and by then powering them off is an anticlimax rather than an event.

A note on duration, since articles like this tend to imply a quarter. For an enterprise of any size this is an eighteen to thirty month programme with a dedicated team, and it competes for the same engineers as everything else. Treat it as the security programme it is, not as an IT hygiene project that can slip when budget tightens.

10. Phase one: discover every dependency, not just the RC4 ones

The most common failure mode in an AD exit is discovering a dependency after you have already turned something off. The trap in 2026 is that Microsoft’s hardening deadlines push you to build an RC4 inventory, which is necessary but is not an AD dependency inventory. Those are different exercises and the second is much larger.

A complete phase one maps human logons, computer accounts, service accounts and their service principal names, gMSAs and dMSAs, LDAP binds, Kerberos ticket activity, forest and external trusts inherited from acquisitions, DNS zones and dynamic registration, DHCP, Group Policy objects and what they actually enforce, Windows Integrated Authentication endpoints, SQL Server logins, file shares and their access control lists, NFS and print services, certificate templates and autoenrollment, scheduled tasks and service logon accounts, and application group lookups. Every one of those is a line item that has to be closed before a domain controller goes away.

The script below covers the service account and encryption slice of that inventory, which is the piece most immediately forced on you by the July deadline. Two things to note about it. It does not cross reference ticket activity, because that is a separate exercise against the domain controller event logs, and I have seen too many plans conflate the two. And the flag it produces deliberately says review rather than dependent, because Microsoft’s guidance is that when msDS-SupportedEncryptionTypes is undefined the key distribution centre falls back to DefaultDomainSupportedEncTypes, so an unset attribute means unknown rather than RC4.

# Inventory-ADServiceIdentities.ps1
# Enumerates user accounts, computer accounts and managed service accounts
# holding service principal names, and flags those whose Kerberos encryption
# configuration needs review. This is an inventory, not a verdict: confirm
# actual encryption use from DC event logs before acting.

Import-Module ActiveDirectory

$outputPath = "C:\ADExit\service_identity_inventory.csv"
New-Item -ItemType Directory -Force -Path (Split-Path $outputPath) | Out-Null

$props = @(
    "ServicePrincipalName",
    "msDS-SupportedEncryptionTypes",
    "LastLogonDate",
    "PasswordLastSet",
    "OperatingSystem"
)

# SPNs live on users, computers and managed service accounts. Enumerating
# only users, which is the common mistake, misses the majority of them.
$identities = @()
$identities += Get-ADUser    -Filter 'ServicePrincipalName -like "*"' -Properties $props |
                 Select-Object *, @{n='ObjectClass';e={'user'}}
$identities += Get-ADComputer -Filter 'ServicePrincipalName -like "*"' -Properties $props |
                 Select-Object *, @{n='ObjectClass';e={'computer'}}
$identities += Get-ADServiceAccount -Filter * -Properties $props |
                 Select-Object *, @{n='ObjectClass';e={'msa'}}

$results = foreach ($id in $identities) {
    $encTypes = $id.'msDS-SupportedEncryptionTypes'

    # Undefined means the KDC applies its configured default, which may or may
    # not include RC4. Treat it as unknown and requiring confirmation.
    $needsReview = ($null -eq $encTypes) -or ($encTypes -band 0x4)

    [PSCustomObject]@{
        Name                   = $id.Name
        ObjectClass            = $id.ObjectClass
        ServicePrincipals      = ($id.ServicePrincipalName -join "; ")
        OperatingSystem        = $id.OperatingSystem
        LastLogonDate          = $id.LastLogonDate
        PasswordLastSet        = $id.PasswordLastSet
        EncryptionTypesValue   = $encTypes
        EncryptionTypesSet     = ($null -ne $encTypes)
        NeedsEncryptionReview  = $needsReview
        MigrationOwner         = ""   # populate during application owner triage
        TargetIdentityModel    = ""   # gMSA, workload identity, retire, compatibility
    }
}

$results |
    Sort-Object NeedsEncryptionReview, ObjectClass -Descending |
    Export-Csv -Path $outputPath -NoTypeInformation

Write-Host "Wrote $($results.Count) service identities to $outputPath"
Write-Host "$(($results | Where-Object NeedsEncryptionReview).Count) require encryption review."
Write-Host "Populate MigrationOwner and TargetIdentityModel before phase three planning."

Separately, establish what is actually happening rather than what is merely configured. Microsoft’s guidance for detecting RC4 use is to examine Kerberos authentication events, specifically 4768 for ticket granting ticket requests and 4769 for service tickets, looking for ticket encryption type 0x17. That produces a much shorter and considerably more urgent list than the configuration inventory does.

#!/usr/bin/env bash
# summarise_kerberos_encryption.sh
# Summarises observed Kerberos ticket encryption types from exported DC
# Security event logs. Expects a CSV export containing the Account Name and
# Ticket Encryption Type fields from events 4768 and 4769.

set -euo pipefail

LOG_CSV="${1:?Usage: $0 <exported_security_events.csv>}"

echo "Observed RC4 (0x17) ticket requests by account:"
grep -E '4768|4769' "${LOG_CSV}" \
    | grep -F '0x17' \
    | awk -F',' '{ for (i=1;i<=NF;i++) if ($i ~ /^"?[A-Za-z0-9._-]+\$?"?$/ && $i ~ /\$|[a-z]/) { print $i; break } }' \
    | sed 's/"//g' \
    | sort | uniq -c | sort -rn

echo
echo "Cross reference these against the PowerShell inventory. Accounts appearing"
echo "in both are your phase three critical path."

That awk field matching is deliberately crude, because event log export formats vary between SIEM platforms. In practice you will pull this from your SIEM with a proper query rather than from a CSV, and the point of including it is the correlation step rather than the parsing.

11. Phase two: separate human identity from the domain

This is the conceptual heart of the migration and it comes second for a reason. Once people no longer authenticate through the directory, almost every subsequent decision becomes reversible, because you have removed the population that would notice a mistake within minutes.

The work is to stand up your chosen workforce identity provider as the authoritative source for human authentication, migrate application single sign on to OIDC and SAML, and move lifecycle provisioning so that joiners, movers and leavers are processed there rather than in AD. Critically, you do this while leaving the directory running and still receiving synchronised identity, so that anything you have missed continues to work. The directory becomes a downstream consumer of identity rather than the origin of it, and that inversion is the actual milestone.

Three things are worth being deliberate about. First, enforce phishing resistant authentication at this point rather than deferring it, because you are already changing every login flow and you will not get a second free window. Second, decide the provider question on strategic grounds rather than convenience. Choosing Entra ID because you already have the licence is defensible; choosing it without noticing that you have just handed workforce identity to the same vendor whose migration gravity you are trying to escape is not. Okta, Ping and Keycloak all exist precisely so that neither Microsoft nor AWS owns your workforce identity, and the tradeoff is another critical platform to run or buy. Third, treat every new tool onboarded from this point as forbidden from authenticating against on premises AD. That rule sounds pedantic and it is the single highest leverage piece of governance in the entire programme, because the alternative is that your migration tooling itself becomes a new AD dependency.

What you should not do in phase two is touch servers. Human identity and machine identity are separate problems and combining them into one cutover is how programmes acquire a reputation for causing outages.

12. Phase three: remove machines and workloads from the domain

This is the largest phase and the one that most distinguishes a real exit from a relocation.

The framing question for every server is not “how do we authenticate this machine after the domain goes away” but “why does this machine need a centrally distributed operating system identity at all”. For a great many AWS hosted servers the honest answer is that it does not, and that the domain join is a habit inherited from the data centre.

For Linux, the traditional pattern is SSSD with realmd performing a domain join, giving POSIX identity and Kerberos authentication from the directory. There is now a supported replacement path, since SSSD 2.11.0 introduced a generic IdP provider that integrates Linux systems with identity providers over OAuth2 and OpenID Connect, using the OAuth 2.0 Device Authorization Grant flow to handle authentication where a browser cannot be rendered directly, such as a terminal session, by generating a URL and device code the user completes on another device. The correct configuration looks like this, and note that the provider is idp rather than oidc:

Two warnings before anyone deploys that. This is new, and on Red Hat Enterprise Linux it currently ships as a Technology Preview, which is explicitly for testing and feedback rather than production support scope. You cannot put a regulated estate’s Linux fleet on a technology preview, and pretending otherwise is how a migration acquires an audit finding.

More importantly, the existence of this path does not make it the right one. If administrative access is mediated through Session Manager against a federated IAM principal, and applications hold IAM roles rather than service account credentials, then the question of how a Linux server resolves centrally managed POSIX users may simply not arise. Reach for the IdP provider where local POSIX identity genuinely matters, such as shared HPC or build infrastructure where consistent UIDs across nodes are a hard requirement. For a fleet of single purpose application servers, the better answer is usually no central directory at all.

For macOS, retire Directory Utility bindings in favour of Platform SSO delivered through your MDM, whether Jamf, Kandji or Intune used purely as an MDM rather than as a directory. Users keep the unlock at login experience, backed by the identity provider, without the fragility AD binding on macOS has always carried across major OS upgrades.

For workloads, this is where the AWS native primitives replace directory concepts outright. An application on EC2 uses an instance role and receives temporary credentials from the instance metadata service. A containerised workload on EKS uses Pod Identity or IRSA. Something outside AWS entirely uses IAM Roles Anywhere, exchanging an X.509 certificate for temporary credentials. In each case there is no long lived secret and no directory in the path, which is a strictly better security posture than the gMSA it replaces, not merely a different one.

For Windows servers, apply the categorisation from section six and expect a long tail. The realistic phase three outcome for a Windows heavy estate is that interactive administrative access leaves the domain, a substantial fraction of service accounts convert to workload identities, and the remainder are consciously scheduled into the compatibility island with named owners and expiry dates.

13. Phase four: DNS and the services hiding inside the directory

Every AD exit plan I have reviewed underestimates DNS, and it is the one omission that reliably turns a controlled migration into an outage. The reason is that in a standard Active Directory deployment, DNS is not a service running alongside the directory. It is a service running inside it. Zones are stored as objects in the directory and replicated by AD replication rather than by zone transfer, the domain controllers are themselves the authoritative name servers, and dynamic registration of client records is authenticated with Kerberos through GSS TSIG so that a machine can only update its own record. On top of that, the mechanism by which any domain joined machine finds a domain controller in the first place is a DNS SRV lookup against records like _ldap._tcp and _kerberos._tcp.

That produces a circular dependency which is worth stating explicitly, because it dictates the migration order. AD replication depends on DNS to locate replication partners, and DNS depends on AD replication to distribute zone data. You therefore cannot decommission domain controllers and then sort DNS out afterwards. DNS has to be extracted from the directory and given an independent life before the directory can be retired, which in practice means DNS work starts early in the programme even though the cutover itself happens late.

13.1 What actually breaks when you move DNS carelessly

Four things go wrong, in roughly this order of frequency. The first is resolver configuration, because thousands of machines, appliances, printers and network devices have domain controller IP addresses hardcoded as their resolvers rather than pointing at an abstraction you can repoint. The second is dynamic registration, since client machines currently register their own A and PTR records into AD DNS using their machine account, and once they are no longer domain joined that mechanism simply stops without any error anyone notices until a monitoring system starts resolving stale addresses. The third is the conditional forwarders, stub zones and split horizon behaviour that has accumulated over twenty years to make internal and external views of the same domain name resolve differently, none of which is documented anywhere. The fourth is reverse lookup zones, which nobody thinks about until a Kerberos service or a logging pipeline starts failing because reverse resolution has quietly gone away.

13.2 The target: BIND, Route 53, or both

For an AWS first estate there are two credible destinations for authoritative internal DNS, and most organisations end up with a deliberate combination rather than a single choice.

The first is ISC BIND, self hosted, with zone data held in version control and deployed by your existing configuration management. This is the right answer for the internal corporate namespace, particularly where you have on premises networks, campus infrastructure, and requirements that predate the cloud. BIND is unglamorous, extremely well understood, supports DNSSEC properly, and critically supports TSIG authenticated dynamic updates, which is the replacement mechanism for the Kerberos authenticated updates you are giving up.

The second is Route 53 private hosted zones for the namespaces that belong to AWS workloads, with Route 53 Resolver endpoints handling the hybrid resolution path in both directions. This is the right answer for anything born in the cloud, because it removes an operational burden entirely rather than relocating it. The judgement call is where you draw the line between the two, and the useful rule is that a namespace should live wherever its records are created. Records created by Terraform when a workload is provisioned belong in Route 53. Records created by a network engineer commissioning a switch belong in BIND.

Migrating a zone out of AD DNS is mechanically simpler than people expect, because AD DNS will perform a standard zone transfer if you enable it, which gives you a clean extraction path.

#!/usr/bin/env bash
# extract_ad_zones_to_bind.sh
# Pulls zones out of AD integrated DNS via AXFR and writes BIND compatible
# zone files. Requires zone transfer to be permitted to this host's address
# on the source DC. Run this repeatedly during migration, not once.

set -euo pipefail

SOURCE_DC="${SOURCE_DC:-10.0.0.10}"
ZONE_DIR="${ZONE_DIR:-/var/named/zones}"
NAMED_INC="${NAMED_INC:-/etc/named/zones.conf}"

ZONES=(
    "corp.example.com"
    "0.0.10.in-addr.arpa"
    "1.0.10.in-addr.arpa"
)

mkdir -p "${ZONE_DIR}"
: > "${NAMED_INC}"

for zone in "${ZONES[@]}"; do
    echo "Transferring ${zone} from ${SOURCE_DC}..."

    if ! dig "@${SOURCE_DC}" "${zone}" AXFR > "${ZONE_DIR}/db.${zone}.raw"; then
        echo "ERROR: AXFR failed for ${zone}. Check zone transfer permissions." >&2
        continue
    fi

    if grep -q "Transfer failed" "${ZONE_DIR}/db.${zone}.raw"; then
        echo "ERROR: DC refused transfer for ${zone}." >&2
        continue
    fi

    # Strip dig's comment lines and the trailing statistics block.
    grep -v '^;' "${ZONE_DIR}/db.${zone}.raw" \
        | grep -v '^$' \
        > "${ZONE_DIR}/db.${zone}"

    RECORD_COUNT=$(wc -l < "${ZONE_DIR}/db.${zone}")
    echo "  ${RECORD_COUNT} records written to ${ZONE_DIR}/db.${zone}"

    cat >> "${NAMED_INC}" <<EOF
zone "${zone}" IN {
    type master;
    file "${ZONE_DIR}/db.${zone}";
    allow-update { key dhcp-updater; };
    allow-transfer { key zone-xfer; };
    notify yes;
};

EOF
done

echo "Validating generated configuration..."
named-checkconf "${NAMED_INC}"

for zone in "${ZONES[@]}"; do
    named-checkzone "${zone}" "${ZONE_DIR}/db.${zone}" || \
        echo "WARNING: ${zone} failed validation, review manually"
done

echo "Extraction complete. Do not cut over until the comparison harness passes."

The comparison harness matters more than the extraction. Before you repoint a single resolver, resolve every record in the extracted zone against both the old and the new authority and diff the answers, because a zone transfer that succeeds is not the same thing as a zone that resolves identically.

#!/usr/bin/env bash
# compare_dns_authorities.sh
# Resolves every name in a zone file against the legacy AD DNS server and the
# new BIND server, and reports any divergence. Exit non zero on mismatch so
# this can gate a pipeline.

set -uo pipefail

OLD_NS="${OLD_NS:-10.0.0.10}"
NEW_NS="${NEW_NS:-10.0.2.20}"
ZONE_FILE="${1:?Usage: $0 <zone_file>}"

MISMATCHES=0
CHECKED=0

# Extract owner names and types for A, AAAA, CNAME, MX, SRV and TXT records.
awk '$4 ~ /^(A|AAAA|CNAME|MX|SRV|TXT)$/ { print $1, $4 }' "${ZONE_FILE}" \
    | sort -u \
    | while read -r name type; do
        old_answer=$(dig +short "@${OLD_NS}" "${name}" "${type}" | sort | tr '\n' ' ')
        new_answer=$(dig +short "@${NEW_NS}" "${name}" "${type}" | sort | tr '\n' ' ')

        CHECKED=$((CHECKED + 1))

        if [[ "${old_answer}" != "${new_answer}" ]]; then
            echo "MISMATCH ${type} ${name}"
            echo "  legacy: ${old_answer:-<empty>}"
            echo "  new:    ${new_answer:-<empty>}"
            MISMATCHES=$((MISMATCHES + 1))
        fi
    done

echo "Checked ${CHECKED} records, ${MISMATCHES} mismatches."
[[ "${MISMATCHES}" -eq 0 ]]

13.3 Replacing Kerberos authenticated dynamic updates

Once machines leave the domain they can no longer register themselves using GSS TSIG, and the correct replacement is to stop having clients register at all. Make DHCP the authority instead, so that the DHCP server writes the A and PTR record on lease assignment using a TSIG shared key, and the record lifecycle becomes tied to the lease rather than to a machine account. This is a better model than the one you are leaving, because it removes the client’s ability to write to DNS entirely.

# named.conf fragment: TSIG key for DHCP driven updates
key "dhcp-updater" {
    algorithm hmac-sha256;
    secret "<generate with tsig-keygen, store in your secrets manager>";
};

# dhcpd.conf fragment: authoritative registration on lease
key dhcp-updater {
    algorithm hmac-sha256;
    secret "<same secret>";
}

zone corp.example.com. {
    primary 10.0.2.20;
    key dhcp-updater;
}

ddns-update-style standard;
ddns-updates on;
update-static-leases on;

For anything provisioned by Terraform, skip dynamic DNS entirely and have the provisioning pipeline write the record, so that the source of truth for a workload’s name is the same commit that created the workload.

13.4 Why BIND alone is not an operating model

Here is where a lot of AD exits go wrong for a second time. BIND solves resolution, but it does not solve operations. If your plan is a pair of BIND servers with hand edited zone files, you have replaced a directory integrated DNS estate that at least had a management interface and delegated permissions with a set of text files that any engineer with root can break silently at three in the morning. You will also still have Route 53 zones, probably some Azure DNS from an acquisition, and an IPAM function currently living in a spreadsheet that disagrees with reality.

This is the gap a DDI platform fills, DDI being the industry term for DNS, DHCP and IP address management treated as one discipline rather than three. BlueCat’s Micetro is the option I would look at first for this specific migration, and the reason is architectural rather than featural. It is an orchestration overlay that unifies DNS, DHCP and IPAM across multi vendor environments, sitting on top of existing infrastructure rather than replacing it. It deploys as a non disruptive overlay connecting to Microsoft DNS, ISC BIND, Kea, and cloud DNS services, reading and writing without forcing you to repoint resolvers or replace servers.

That property is precisely what a migration needs. During the transition you are unavoidably running AD integrated DNS and BIND and Route 53 simultaneously, and the failure mode is not any one of those systems but the absence of a single view across all three. An overlay gives you one control plane spanning both sides of the cutover, which means the migration becomes a series of zone by zone moves visible in one interface rather than a coordinated flag day. Micetro exposes RESTful APIs that connect to Ansible, Terraform and ServiceNow, and supports role based access control with granular permissions applied to DNS zones, DHCP scopes and IP ranges. The Terraform integration matters more than it sounds, because it is what lets you move record creation into the same pipeline that creates the workload, which is the actual end state you are aiming at.

The vendor’s own framing of the problem is that organisations commonly run Microsoft DNS for Active Directory alongside BIND, cloud platforms and regionally managed infrastructure, producing a fragmented landscape with no unified view and inconsistent permissions. That is a fair description of where most banks actually are, and it is worth noting that they also address the multi cloud IPAM problem directly, since overlapping IP ranges across Azure and AWS environments are common and spreadsheet based IPAM becomes unreliable at that point.

One important caveat, and it is the kind of thing that undermines an entire programme if missed. Micetro supports role based access control, single sign on and multi factor authentication through Active Directory, Entra ID and Okta, and its role based access control across managed DNS platforms integrates with on premises Microsoft Active Directory and Linux LDAP. If you configure the tool against on premises AD because that is the path of least resistance during the pilot, you have introduced a fresh AD dependency into the very platform you bought to help you remove one. Wire it to your OIDC identity provider from the first day of the proof of concept, and treat any AD backed authentication in new tooling as a defect rather than a convenience.

The same discipline applies to any DDI choice, whether that is Micetro, Infoblox, or a self assembled combination of BIND, Kea and pipeline automation. The question to ask of each candidate is not which features it lists but whether it can manage the old world and the new world at the same time, because a DDI platform that only manages the destination is of no use during the eighteen months you spend getting there.

14. Phase five: applications and data

Postgres environments authenticating through pg_hba.conf LDAP entries are among the easiest AD dependencies to underestimate, because they were configured once by whoever built the cluster and never revisited. The old pattern looks like this, and every one of these lines is a runtime dependency on a domain controller:

# pg_hba.conf, before
host  all  all  10.0.0.0/16  ldap ldapserver=dc01.corp.example.com ldapbasedn="dc=corp,dc=example,dc=com"

The important development is that the target is no longer certificates and passwords. PostgreSQL 18 configures OAuth authentication in pg_hba.conf using the oauth method with parameters for your provider, which means database access can finally consume the same identity provider as everything else, and the client obtains a bearer token from the identity provider and presents it at connection, eliminating stored database passwords.

# pg_hba.conf, after
# Human access via the enterprise identity provider
hostssl  all  all  10.0.1.0/24  oauth issuer=https://login.microsoftonline.com/TENANT-ID/v2.0 scope="openid profile" delegate_ident_mapping=1

# Service to service via mutual TLS, no shared secret anywhere
hostssl  all  all  10.0.0.0/16  cert clientcert=verify-full

Two caveats that matter for a regulated estate, and which most write ups of this feature omit. PostgreSQL 18 provides the oauth_validator_libraries parameter and a framework for building validator modules but does not ship a built in validator, so you must install a third party or custom module such as Percona’s pg_oidc_validator. And that validator becomes part of the trusted authentication path and a potential single point of failure. That is a real risk to accept consciously rather than discover in production, and it is why SCRAM remains a legitimate interim for clusters where the driver and validator ecosystem is not yet where you need it. If you do use SCRAM, remember that password_encryption governs how a password is hashed at the moment it is set, so setting it after creating the role changes nothing about the existing credential.

The broader principle for this phase is the one that generalises beyond Postgres: do not replace an LDAP bind with a long lived password unless you genuinely have no alternative. Every application in this phase gets the same triage as the Windows Integrated Authentication cases in section six. Modernise it to OIDC, front it with an authenticating proxy, or admit it to the compatibility island with an expiry date.

15. Phase six: governance takeover and directory retirement

The hardest part of AD to replace is not authentication. It is the ability to answer who has access to what, why, and when it was last reviewed. AD group nesting technically supports this if you are disciplined, but nested groups five layers deep named GRP_APP_FIN_RO_LEGACY2 are how access reviews become a box ticking exercise rather than a control.

SailPoint, or an equivalent identity governance platform, becomes the system of record. Access requests, approvals, certification campaigns and separation of duties rules move there, and the directory becomes a downstream provisioning target rather than the place decisions are made. The migration step people skip is the certification campaign. Import existing group membership as a baseline, then run a full certification against it to establish what is actually justified rather than what has merely accumulated, and only then treat the governance platform as authoritative. Importing everything as is simply relocates your AD scar tissue into a more expensive tool.

Retirement then happens by attrition. As each compatibility consumer is closed out, the corresponding directory component loses its last dependent and can be removed. If phases one through five were done properly, no single event in this phase is dramatic.

16. The compatibility island

Some things will not leave. Print services remain stubbornly convenient. Vendor appliances bought a decade ago hardcode LDAP binds with no supported alternative. File shares carry directory dependencies inside millions of access control entries. A handful of applications need Kerberos in a way that cannot be proxied.

The rule I would apply is this. Legacy compatibility is allowed to shrink. It is not allowed to dictate the target architecture.

Whatever residual directory remains, whether self managed AD, AWS Managed Microsoft AD for AWS locality, or Entra Domain Services for Azure hosted legacy, should have enumerated consumers, restrictive network boundaries, no new workloads admitted under any circumstances, no human convenience use, explicit ownership, and a decommission trigger attached to every remaining dependency. Entra Domain Services and AWS Managed Microsoft AD both belong in this section rather than in your target architecture, and that is not a criticism of either. If you have legacy Windows workloads in Azure needing domain join, Group Policy and Kerberos, Entra Domain Services may be exactly the right compatibility service. That is a very different thing from making it the strategic identity dependency of an AWS estate because Microsoft provided the obvious migration path.

17. When keeping Active Directory is the right answer

An honest article has to include this option, and including it strengthens the rest.

If your estate contains thousands of Windows servers, pervasive Windows Integrated Authentication, SQL Server everywhere, mature Group Policy baselines your auditors have accepted, and vendor applications with deep Kerberos dependencies, then retaining Active Directory while shrinking and hardening it may be the rational choice. Move to Windows Server 2025 domain controllers, take the functional level and the security improvements, convert service accounts to gMSAs and dMSAs, eliminate RC4 and NTLM properly, tighten delegation, and shrink the attack surface. That is a legitimate strategy with a defensible risk position.

What is not legitimate is arriving at that outcome by default, because nobody ever evaluated the alternative. The argument of this article is not that AD is bad and must go. It is that you should know what Active Directory is buying you and what it is costing you, and then make a deliberate architectural decision rather than inheriting one made in 2003.

18. Closing

Active Directory’s real problem is not that it is old. It is that twenty years of dependency accumulation turned a design decision into an assumption. Servers joined the domain because servers joined the domain. Applications used LDAP because LDAP was there. Service accounts lived in AD because that was where service accounts lived. Along the way the organisation stopped choosing and started inheriting.

Microsoft has not discontinued Active Directory Domain Services, and Windows Server 2025 proves it is still being developed. What Microsoft has effectively deprecated is the idea that the domain controller should remain the centre of your future identity architecture. The hardening deadlines are how that decision reaches you, and they will force you to unwind dependencies whether or not you have a strategy for what replaces them.

Do not waste that. Decide how humans should authenticate. Decide how workloads should identify themselves without holding secrets. Decide where authorisation and certification should live. Decide which applications genuinely still need a directory, and which never needed one in the first place. And be suspicious of any migration path whose main virtue is that the vendor made it easy, because ease of migration is not the same as fitness of architecture.

The objective is not to replace Active Directory. It is to reach the point where you no longer need one.

19. Glossary

This article leans on protocol detail not everyone carries around day to day, so here is the vocabulary in plain terms.

RC4 is an old, fast stream cipher that Kerberos used for years to encrypt tickets. It is cryptographically weak because the key derives directly from the NTLM password hash, so a captured ticket can be cracked far faster than an AES equivalent. Microsoft’s 2026 hardening is what stops Kerberos accepting it by default.

Kerberos is the authentication protocol running inside Active Directory. When a user logs into a domain joined machine, Kerberos issues tickets proving identity to other services without the password being retyped.

The KDC, or Key Distribution Center, is the service on a domain controller that issues those tickets, and the component hardened to default to AES rather than RC4.

A TGT, or Ticket Granting Ticket, is what a user receives at login. A service ticket is presented afterward to a specific resource. Event IDs 4768 and 4769 in the Windows Security log record each request, which is how you audit who is still using weak encryption.

NTLM is an older Windows authentication protocol predating Kerberos and weaker still, which lingers as a silent fallback in environments that assume they retired it years ago.

msDS-SupportedEncryptionTypes is the attribute declaring which encryption types an account may use. When undefined the KDC applies its configured default, which is why an unset value means unknown rather than RC4.

A service principal name, or SPN, is the identifier a client uses to request a Kerberos ticket for a specific service. SPNs live on user accounts, computer accounts and managed service accounts, which is why an inventory that enumerates only users misses most of them.

gMSAs and dMSAs are group managed and delegated managed service accounts, AD’s answer to the service account with a password in a config file. They rotate credentials automatically and bind authentication to specific machines. They are a hardening measure that deepens the domain dependency rather than a migration path away from it.

Windows Integrated Authentication is the pattern where a Windows client authenticates to a service such as IIS or SQL Server transparently using its existing Kerberos or NTLM credentials. It is the most common hard blocker in an AD exit.

LDAP is the protocol for reading and writing directory data, the address book function of AD, distinct from Kerberos authentication. An LDAP bind is when an application authenticates by sending a username and password to the directory and checking whether it succeeds.

SSSD is the Linux daemon handling identity and authentication lookups, traditionally against AD via Kerberos and LDAP. Its newer IdP provider points it at an OIDC identity provider instead, using the OAuth device authorization flow so a terminal session can authenticate via a browser on another device.

OIDC, or OpenID Connect, and SAML are the modern web based authentication protocols behind current identity providers. Rather than tickets and binds, a user receives a signed token.

SCRAM SHA 256 is PostgreSQL’s modern password mechanism, a salted challenge and response rather than a password sent to a directory. A validator module is the component PostgreSQL 18 requires to verify OAuth tokens, which it does not ship, and which sits inside the trusted authentication path.

Mutual TLS, or mTLS, is a connection where both sides present certificates. It is what replaces shared secrets for service to service connections.

Platform SSO is Apple’s mechanism, delivered through an MDM, for backing macOS login with an identity provider directly, without binding the Mac to a domain.

Instance roles, IRSA, EKS Pod Identity and IAM Roles Anywhere are the AWS primitives that deliver temporary credentials to workloads, on EC2, in Kubernetes, and outside AWS via X.509 certificates respectively. They replace the directory concept of a machine or service account entirely rather than substituting for it.

Session Manager is the AWS Systems Manager capability providing audited shell access to instances without inbound ports, bastion hosts or SSH keys, and the reason many servers do not need centrally distributed operating system identities at all.

ADCS, Active Directory Certificate Services, is the certificate authority built into AD, issuing device, WiFi, VPN and email certificates through autoenrollment. It is frequently the most overlooked dependency in an exit plan, and it matters because the target architecture consumes certificates heavily.

AD integrated DNS means zones stored as objects inside the directory and replicated by AD replication rather than zone transfer, with domain controllers acting as authoritative name servers. It produces the circular dependency described in phase four.

GSS TSIG is how a domain joined machine authenticates a dynamic DNS update using its Kerberos credentials, and why that registration stops working once a machine leaves the domain. TSIG is the shared key equivalent that replaces it when DHCP takes over registration.

An SRV record advertises which host provides a given service. Records such as _ldap._tcp and _kerberos._tcp are how every domain joined machine locates a domain controller. AXFR is a full DNS zone transfer, the extraction mechanism used in phase four.

BIND is ISC’s long established open source DNS server, the usual destination for a self hosted internal namespace. Kea is ISC’s modern DHCP server.

DDI means DNS, DHCP and IP address management treated as one operational discipline. Micetro, now part of BlueCat following its acquisition of Men and Mice, is a DDI orchestration overlay managing existing DNS and DHCP services in place rather than replacing them, which is what makes it useful while old and new must coexist.

Entra Domain Services is Microsoft’s managed offering providing domain join, LDAP, Group Policy, Kerberos and NTLM from domain controllers in an Azure region, with identities synchronised one way from Entra ID. AWS Managed Microsoft AD is AWS’s equivalent, an actual managed Active Directory domain running inside AWS. Both are compatibility services, not AD exits.

Mythos class models is Anthropic’s naming for the tier of models above Opus, the current frontier of capability. The relevant point for security is that each tier has improved at protocol analysis and exploit chaining, which is what compresses the interval between a CVE being disclosed and a working exploit existing.

BloodHound and Mimikatz have defined manual AD attack tradecraft for close to a decade, mapping delegation paths to privileged accounts and extracting credentials from memory respectively. Both assume a human operator working at human speed, which is the assumption section eight argues is no longer safe.