3 ms·
> In fairness to Microsoft, there's no way to make authentication not a single point of failure. Huh? x509-type authentication works without a single point of
by wallacoloo 6y ago
> In fairness to Microsoft, there's no way to make authentication not a single point of failure.
Huh? x509-type authentication works without a single point of failure. I can authenticate myself to any client via public-key cryptography without any external dependencies, after we've agreed on a root of trust.
Active Directory chose a solution that requires centralized availability. They didn't have to do it this way (though it does make certain administrative tasks, like revocation, simpler).
Note that even AD itself does not require a single point of failure though! You can define secondary (i.e. failover) DCs (usually via DNS). Then DNS becomes your point of failure -- and again most DNS implementations support failover, such that any single point of failure gets pushed lower to the stack (e.g. NICs), which also support failover or multipathing, etc, if you really need high availability.
Anyway, it's totally possible to make authentication not be a single point of failure. Of course, you have to make some tradeoff to do it (see: the CAP theorem).
- macintux 6y agoMy point was poorly stated, based on one line of the GP comment: > Azure AD taking down pretty much the entirety of Azure / O365 / Teams is frankly inexcusable My objection was that the Microsoft Azure AD service is down, there's nothing that Microsoft can do to protect the services that rely on it. Setting aside your valid x509 counter-argument, the remaining options you listed to increase availability, to me, have to do with resilience of the Azure AD service. They're not alternative services. It depends on where you draw the boundary around the service. Again, clearly Microsoft has failed to provide sufficient resiliency, not arguing against that at all. But once the service is down, practically by definition Teams and Exchange and everything else is doomed.