Active Directory, File, Print Services in the Cloud

Short answer is "don't."  The various protocols that active directory uses are not internet friendly and the single point of failure is high.

Azure AD is *not* "AD in the cloud" and would require a significant shift in planning and infrastructure.  Azure ADDS is a purpose-built implementation of AD, but is meant for cloud/Azure VM workloads that still need AD, so they are effectively still on a LAN.

Neither is suitable for your suggested use case. Your best bet is rrolacing snd migrating servers and staying on-prem.

Just get 2 new servers, run hyper-v, have a dc on each and then a file server/print server vm on one that you could replicate to the other using hyper-v replica for disaster recovery.  How old are the servers (specs) and what os?  Upgrading AD is easy, you just add a new vm with new os, make it a dc and transfer FSMO roles and there's no shortage of documentation on that.  You could also re-purpose the old servers as additional storage using a NAS solutions or or free pseudo-san solutions.  

For Azure ad you need to sync with an on-prem ad so that's a non-starter.  You could have dc's in the cloud but you'd need a vpn between the school and Azure.  In the long run it will cost more than just buying on-prem servers.  Azure is really for web apps that need to scale so you only pay for what you use, not as a colocation service for your servers.

I run and manage AD, print and file services in the cloud for two clients with multiple sites and have been doing so for going on three years now.

We did not go with Azure or AWS,(Their wallet and decision).  I found other hosting services that do the job quite well and they are very happy with its performance.

Now preparing to move a 3rd client to the same hosting platform.

Are you planning to create a site-to-site VPN, express-route? If you are, it is exactly the same as putting a new DC in a new data center.

I would however still keep a DC on-prem

nappy_d, very interesting.  Nothing against those who say it's not possible but I would have to think it's doable these days with the predominance of cloud solutions and cloud integration.  What hosting services do you use?

I want to stress that while some people have had limited success doing this, that doesn't necessarily make it a good practice.  Nobody here said "it't not possible"  but I stand by my initial comment that "he various protocols that active directory uses are not internet friendly and the single point of failure is high."  Those two statements are NOT the same thing.  What's possible and what's reliable are very very different.

"I would have to think it's doable these days with the predominance of cloud solutions and cloud integration."  You're mixing apples and oranges.

Active Directory was built more than 20 years ago and was based on technologies intended for LAN usage from client to server.  Even replication, to be more WAN friendly, was upgraded from FRS to DFS-R.  The rest (LDAP, Kerberos) was really designed for local connections and is why Microsoft guidance was and still is to have a DC at each site (and why read-only domain controllers are a thing.)

Conversely, cloud solutions and integrations aren't built on Active Directory (Domain Services) or those protocols.  Internet friendly authentication protocols have also been around awhile, but are not Kerberos based, or NTLM based, or any of the core ADDS technologies.  Microsoft made ADFS for a reason.  

When you look at ADFS, Azure AD (a cloud native identity provider), OneLogin, Okta, Lastpass SSO, JumpCloud, or *any* "cloud solution" or "cloud integration" provider of any notable reputation, and you'll see NONE of them use Kerberos for cloud integration.  They use SAML or OAuth for cloud integration purposes.  And cloud native apps all have adopted that as well.  ADDS does *not* offer these protocols natively.  Thus ADFS.

For organizations that have ADDS and want to offer "modern cloud" auth integrations, most of the above services have an on-premises agent for syncing and/or authentication.  Azure AD uses AADConnect (and does have an optional passsword passthrough feature), Okta has the on-prem okta agent, and on and on.  Why?  Because for authentication, the agent is *local* to the DC...just like the best practice for the last 20 years of ADDS.  *MAJOR CLOUD IDENTITY PROVIDERS* still want an agent local to the DC!!!

When you take this all together, you can draw some pretty clear conclusions:

1) You shouldn't simply throw a DC in the cloud and expect things to work.
2) Modern identity solutions, cloud native solutions, *do* exist but apps have to support them (SAML, not kerberos)
3) Migrating to a cloud-native identity solution is not a trivial act or quick solution.

IF you need ADDS then you should keep an on premises DC, or ideally 2.  Per site.
If you don't need ADDS then you can migrate to a cloud identity provider, but that is exactly what it is: a *migration* with all the planning one would expect.  

And to sum up, nothing I wrote says that doing bad practices isn't possible.  Plenty of bad configurations have always been possible (let's just make all users domain admins so they can install apps on any machine!) ...but bad practices are bad practices for a reason.  It is easy to fall into confirmation bias or to have someone tell you what you want to hear.  But doing things the right way is a harder decision.

So here's what I did with this client and their long term care facilities.

Client wanted staff to move between locations to:

• Print
• Login
• Access shared files

Appliances to support IPSec at my client's 6 sites, each with 8 users.

Each site has a 250Mbps internet connection with a static IP.

You can choose Amazon AWS, Azure or any other cloud host vendor you want.

I setup at each facility a device that supports IPSec and client had already bought Zyxel USG20-VPN devices.

In the cloud I setup a pfSense firewall.

Created a site to site tunnel from each facility to the cloud.

Created a Windows 2016 server for AD, another for file and print services.

To date we've had no issues.

While we may differ on what is right, client would not invest in putting a physical domain controller at each site just for 8 staff.

Their network has been up and functioning for going on two years .

All the 3rd Partly Cloud implementations that I have seen do it with LDAPS

I would not use it in this manner unless for a small implementation