In September of 2022, Joey Verlinden (@jvldn1) published an excellent article on his experience with recovering access to an Azure AD tenant that he was completely locked out of. You can, and should, read the full article here, What happens if you lock-out your Azure Tenant? – Joey Verlinden.
In this, Joey details the process for recovering access to an Azure AD tenant, which includes a detailed verification process, which is rightfully put in place to ensure that someone isn’t capable of a tenant takeover through social engineer. As part of the process, the request is verified by means of either:
- Calling the phone number associated with a Tenant
- Emailing a Global Administrator
- Requesting that the organization creates a DNS TXT record associated with one of the verified domains
Now, under normal “oops” scenarios, you likely could use a phone call or email to a Global Administrator. Of course, if a GA is mail-enabled, the email should be forwarded, as your Global Admins should not actually be receiving or checking email directly in that inbox (which is a different story).
But say my tenant has come under some sort of cyber attack. Or more mundane You can’t guarantee that a phone call or email will still go to where you expect. And while these changes should be audited, when you’re in a state of needing to authenticate yourself from a support perspective, it’s likely you’ll still have to try and complete one of these steps, if you don’t want further delay.
This leaves us with DNS. But what if that DNS is hosted in a subscription associated with the same Azure AD tenant? Things could potentially not turn out so well.
Even if you have DNS management delegated out to accounts that are not a GA (which in a large-scale enterprise, GA should not own resources in subscriptions)… can you guarantee that their access would not be tampered with if a threat actor is involved?
From a resilience perspective, it seems like it’s one of the times to not host DNS in Azure, or at least not in a subscription that is tied to the same tenant that uses those domains for services.
You may already have a DNS architecture with secondary zones hosted outside of Azure, but those read-only copies won’t save you when you need to edit a zone.
And if you host DNS with something like Amazon Route 53… do you federate authentication for your account owners and resources back to Azure AD? If your Azure tenant is breached, it’s certain a threat actor will try to follow your multi-cloud sprawl.
So what’s the resilient path?
Your mind may go to contacting your domain name registrar, and updating your NS records. But, you now are adding another external dependency.
This past summer I was trying to update NS records for a domain with Directnic, and ticket response time was 12-24 hours, let alone actually having the records updated. Why did I open a ticket? Updates in the portal were not reflecting days after the change.
While it may seem suboptimal, the most resilient path would be hosting DNS either in another small subscription and tenant that has no association to your primary production tenant, or using another large-scale cloud provider for DNS, but not associating authentication back to Azure AD.
Considering the reality that most organizations struggle to keep as many nines as cloud providers (even with their occasional outages), this wouldn’t be time for a knee-jerk reaction to bring DNS back to an on-premise data center, unless your organization is still robust enough to handle those high SLA’s.
About This Posts Featured Image
The chosen photo is the work of engin akyurt, used under the Unsplash license.
