> Kerberos can’t survive in untrusted networks...

Wasn't Kerberos designed to work in untrusted networks?

It was, but Active Directory wasn't. If you put your DCs on the Internet you're asking to get hacked.

Another point worth mentioning is that as we move towards zero trust by default, AD getting replaced by Azure AD is a logical step towards that goal.

Kerberos is designed for untrusted networks.. and Azure AD is just AD hosted somewhere else. Same problems.

> Azure AD is just AD hosted somewhere else

Azure AD DS (https://azure.microsoft.com/en-us/services/active-directory-...) is a specific offering from Azure which gives you a hosted AD instance, but otherwise AAD is completely different.

AD is mostly used internally on corporate networks. Why would untrusted networks be relevant?

As corporate datacenters migrate to the cloud, the distinction between internal and external will fade.

Additionally, with cloud email/office becoming the standard, there’s powerful levers to incentive cloud adoption and shifting of compliance standards.

> As corporate datacenters migrate to the cloud

I don't think this trend is as large as SV web devs think it is, nor do I think the trend will continue indefinitely in that direction. My current corporate masters hate the cloud because they want to be in control of their own data and services. They don't want to twiddle their thumbs when somethings wrong while waiting for BigCorp to get around to fixing it. They really, really don't like paying rent on business essential tooling.

And they've pretty much been proven right in all their concerns so far.

Consider both ways: even if you run 100% of your backend on-prems, a significant portion of your routes may go outside to reach roaming employees, remotes, maybe customers for some apps, etc. You likely have some Infrastructure-as-a-Service, dynamic subnetting and addressing for containers, VPNs, firewalls to cross, etc. AD and MS Server DCs in general are just not suited to this environment, where IPs may change on-the-fly, hosts die quickly, etc.

You typically need a more robust, web-compliant solution using e.g. tokens + MFA and web-compliant centralization of authority and certs on e.g. Consul or Red Hat Identity Management.

That being said, IMHO, it's a much saner and safer approach to bite that bullet and setup a rock-solid ID/Auth system on-prems (or at least vendor-agnostic and load-balanced over at least 2 major providers). It's really the kind of low-level infra that you can setup properly once and use for a decade, + cost of extra features you may want to add later.

> AD and MS Server DCs in general are just not suited to this environment

Don't know what you're talking about, they work just fine. All of our branch offices and salesmen are remote workers.

I think that really big and really small companies will go the way you describe.

Most places want to control capex and limit capacity wastage. Nobody wants to invest in datacenter facilities. Even the government, which has access to super cheap capital, is embracing cloud.

The shift is real. In my area, a major infrastructure OEM like HPE has like 2 CEs that cover the region. There was probably 14-16 20 years ago.

Because the distinction of internal and external networks is eroding. Read about zero trust networking.

That's not a trend we're interested in following. You bring your own device? Fine, it's on the guest network that is treated like the internet as far as our services are concerned. This isn't rocket science.

If your services are internet accessible and secure, what is the distinction between your trusted internal network and the internet?

The answer is usually that legacy apps, SMB, Voip, and printing require trust derived from the network.