question

@ImranShaikh-2100 ,

I understand that you are trying to plan for a disaster recovery in the event of on-premise going down due to hardware failure or virus attack. You already have Password hash sync in place so your users are synced to azure AD along with their passwords. There could be some scenarios which can occur in this case.

Hardware failure :- This is something you can never be prepared for . Hence its better to keep at least two domain controllers and setup a remote backup . Depending upon your budget , designing for disaster recovery can include co-location to a different datacenter or creating a site-to-site VPN with Azure cloud with Virtual machines running as domain controllers serving as extension of your on-premise environment .

Malware attack :- You need to make sure that you have a daily backup for your on-premise Active directory to avoid any scenario of Virus attack . even though any Anti-malware app can detect and clean many of the old viruses , you can never know what all got affected so you may have to find and assess the extent of damage in these cases . A built-up of the on-prem environment from scratch is a better way to go . So you may need to rebuild the machines, install latest windows updates, anti-viruses patches and restore the domain controller backup using either windows backup you have or the custom backup software you may be using in your environment .

Since you are using Office 365 and you have password synced to the cloud, your users will surely be able to access the mails even if your on-premise infrastructure goes down. You would not be able to provision a new user on-premise. So no new users will be synced to the Azure AD . However the user will still be able to directly access the Office 365 mails if you do not have any federation setup with on-premise . If you have ADFS or any on-premise federation service like Okta/PingFederate etc. setup in on-premise environment with federation to Azure AD you should be able to change the status of federated domain to managed. Managed here would mean that azure AD will manage the authentication request and Federated means the user authentication is served by the on-premise federation service that you have setup . In order to check authentication type you can use the cmdlet Get-MsolDomain as shown below.

If your users email is using a UPN suffix which is not federated in your environment then they will continue to access the emails and it will not cause any disruption for them. Lets say you have 5 different custom domains associated with your azure AD tenant but only 2 are used for provisioning email addresses for your users . Then if those two are managed then you wont see any problem but if the domains are federated you may need to convert the domain to managed in order for the users to be able to sign-in to Office 365 mails.

In order to convert your domain from Federated to Managed , you would need to use the Connect-MsolService to connect to the Microsoft Online service . This comes as a part of Azure AD PowerShell which you can install from here . Once you have the modules installed you can run the following cmdlet and set the domain authentication to Managed. You can change the authentication for the domain to Managed using the following cmdlet .

 PS C:\Users> Set-MsolDomainAuthentication -Authentication Managed -DomainName contoso.com
    
  PS C:\Users> Get-MsolDomain
        
  Name                        Status     Authentication
  ----                        ------     --------------
  xxxxxxt.com                Verified      Managed       
  xxxxxxxe.in                  Verified      Federated     
  xxxxxxxxr.in                Verified       Federated     
  pxxxxxxx.in                 Verified       Managed       
  pxxxxxx.in                  Unverified   Managed       

Generally anyone with an on-premise environment have local applications which may or may not support modern authentication protocols (like oAuth) . If there are old applications that you have which do not support modern authentication (like apps using legacy auth protocols like Kerberos/NTML ) and are not registered with Azure AD then they will stop working for your users until the ADFS or the federation service is setup again with proper configuration . In case of a disaster your ADFS server may not exit hence you can use the cmdlet directly to convert to managed authentication for your domain . Even if ADFS server is not affected , it may still not be functional as it depends on active directory domain controllers which would be down in this scenario .

Hope the above explanation clarifies the disaster recovery scenarios you were looking for . Should you have any further queries , please feel free to let us know and we will be happy to answer further. If the information is helpful , please do accept the post as answer which will help other members in the community who have similar queries. I have included multiple links and would request you to go though the attached documentation which will help in your case while planning .

Thank you .

---

• Please don't forget to click on whenever the information provided helps you. Original posters help the community find answers faster by identifying the correct answer. Here is how
  

• Want a reminder to come back and check responses? Here is how to subscribe to a notification
  

• If you are interested in joining the VM program and help shape the future of Q&A: Here is how you can be part of Q&A Volunteer Moderators