AAD Users from main subscription can't login to the application after failing over the VMs

[Manoj Karunarathne]

Hi Azure Folks!

AAD users from main subscription can't login to the application after failing over the VMs to another region (via ASR).

I'm working on a DR solution for an in-house developed application (consists of a Web server and a DB server in Azure VMs) to replicate across two regions. I've provisioned all resources in a separate Azure subscription (resource groups, VMs, Network interfaces etc..) however, when failed over to the DR via ASR, the application doesn't authenticate users from the main tenant (AAD users). 

What's configured: 

1. New isolated Subscription containing following resources 

2. Shared services resource group 

3. Dedicated resource group containing replica VM’s and PaaS resources. 

4. Virtual Network for shared resources, DCs, jump hosts. 

5. Isolated subnet containing replica domain controllers and shared services. 

6. Isolated subnet for Azure Bastion hosts. 

7. Isolated subnet to host replica VM’s and resources. 

8. A dedicated host used to access isolated DR instance.

My question is, as DR resources are hosted in a totally separate/isolated subscription, would we need to consider other areas (i.e. app registration or integration between two subscriptions) in addition to the above list of items configured (to facilitate the authentication for all AAD users in the main subscription) ? Am I missing something here?

Thanks and appreciate any ideas !

Cheers

Manoj

[#2]

Hi,

First Question would be: How is the Authentication done for that App, via AD or AAD?
If AAD, how did you grant access to the Users from Tenant A for the Application in Tenant B?
Do you use App Registrations?
Do you use Conditional Access?

Kind Regards,

Peter

[#3 · Accepted solution]

I have managed to sort this out by simply resolving the domain name (app1.domain.net) locally as this will be only accessed by a small group of people after the failover.

Short term solution:
1. Add a host file entry in the DR Web server to resolve the app1.domain.net with the Web server IP itself.
2. Modify the IIS bindings to match the same.
This way, it simply used the existing Azure AD enterprise app registration.

Long term solution:
1. Register a new domain and configure DNS to have a dedicated DR experience (i.e. app1-dr.domain.net)
2. Configure IIS bindings to match the above
3. Register a new AAD Enterprise App to match the above and that will serve the Identity/Auth Integration.

Hope this will be useful for someone out there. Cheers!

[#4]

Thanks for your prompt response @Peter_Beckendorf !
I have posted an update above on how I dealt with it.
Cheers!