Should I expose my Active Directory to the public Internet for remote users?

I'm posting this as answer mainly because everyone has their own "educated opinion" based on experience, 3rd party info, hearsay, and tribal knowledge within IT, but this is more a list of citations and readings "directly" from Microsoft. I used quotes because I'm sure they don't properly filter all opinions made by their employees, but this should prove helpful nonetheless if you are after authoritative references direct from Microsoft.

BTW, I also think it is VERY EASY to say DOMAIN CONTROLLER == ACTIVE DIRECTORY, which isn't quite the case. AD FS proxies and other means (forms based auth for OWA, EAS, etc.) offer a way to "expose" AD itself to the web to allow clients to at least attempt to authenticate via AD without exposing the DCs themselves. Go on someone's OWA site and attempt to login and AD will get the request for authentication on a backend DC, so AD is technically "exposed"...but is secured via SSL and proxied through an Exchange server.

Citation #1

Guidelines for Deploying Windows Server Active Directory on Windows Azure Virtual Machines

Before you go "Azure isn't AD"...you CAN deploy ADDS on an Azure VM.

But to quote the relevant bits:

Never expose STSs directly to the Internet.

As a security best practice, place STS instances behind a firewall and connect them to your corporate network to prevent exposure to the Internet. This is important because the STS role issues security tokens. As a result, they should be treated with the same level of protection as a domain controller. If an STS is compromised, malicious users have the ability to issue access tokens potentially containing claims of their choosing to relying party applications and other STSs in trusting organizations.

ergo...don't expose domain controllers directly to the internet.

Citation #2

Active Directory - The UnicodePwd Mystery of AD LDS

Exposing a domain controller to the Internet is normally a bad practice, whether that exposure comes directly from the production environment or through a perimeter network. The natural alternative is to place a Windows Server 2008 server with Active Directory Lightweight Directory Services (AD LDS) role running in the perimeter network.

Citation #3 - not from MS...but useful still in looking ahead

Active Directory-as-a-Service? Azure, Intune hinting at a cloud-hosted AD future

In the end, there is no great "short" answer which meets the goals of ridding the office of the AD server in exchange for an Azure alternative. While Microsoft is being complacent in allowing customers to host Active Directory Domain Services on Server 2012 and 2008 R2 boxes in Azure, their usefulness is only as good as the VPN connectivity you can muster for your staff. DirectAccess, while a very promising technology, has its hands tied due to its own unfortunate limitations.

Citation #4

Deploy AD DS or AD FS and Office 365 with single sign-on and Windows Azure Virtual Machines

Domain controllers and AD FS servers should never be exposed directly to the Internet and should only be reachable through VPN

Active Directory (AD) wasn't designed for that kind of deployment.

The threat models used in the design of the product assume a "behind-the-firewall" deployment with some amount of hostile actors filtered at the network border. While you can certainly harden Windows Server to be exposed to public network, the correct functioning of Active Directory requires a security posture that is decidedly more lax than a host hardened for public-facing networks. A lot of services have to be exposed from a Domain Controller (DC) for AD to work properly.

Zoredache's suggestion in the comments, particularly referencing something like OpenVPN running as a machine-wide service w/ certificate authentication, might just be a good fit. DirectAccess, as others have mentioned, is exactly what you need, except that it doesn't have the cross-platform support you'd like.

As an aside: I've toyed with the idea of using certificate-based transport-mode IPSEC to expose AD directly to the Internet but never actually had time to do it. Microsoft made changes in the Windows Server 2008 / Vista timeframe that supposedly made this feasible but I've never actually exercised it.

What everyone else said. I'm particularly nervous about the brute force attempts Christopher Karel mentioned. A presentation at the last Def Con was on the topic:

So You Think Your Domain Controller is Secure?

JUSTIN HENDRICKS SECURITY ENGINEER, MICROSOFT

Domain Controllers are the crown jewels of an organization. Once they fall, everything in the domain falls . Organizations go to great lengths to secure their domain controllers, however they often fail to properly secure the software used to manage these servers.

This presentation will cover unconventional methods for gaining domain admin by abusing commonly used management software that organizations deploy and use.

Justin Hendricks works on the Office 365 security team where he is involved in red teaming, penetration testing, security research, code review and tool development.

I'm sure you can find lots of other examples. I was looking for articles about domain controllers and hacking in hopes of getting a description of how quickly the DC would be found, etc., but I think that'll do for now.

If you're trying to convince management, A good start would be that:

It goes against Microsoft's Best Practices for Active Directory Deployment.

Update : See this technet article on securing domain controllers against attack, and the section titled Perimeter Firewall Restrictions that states:

Perimeter firewalls should be configured to block outbound connections
from domain controllers to the Internet. 

And the section titled Blocking Internet Access for Domain Controllers which states:

Launching web browsers on domain controllers should be prohibited not only
by policy, but by technical controls, and domain controllers should not be
permitted to access the Internet

I'm sure you can drum up some Microsoft documentation on the matter, so that's that. In addition to that, you could state the hazards of such a move, something along the lines of:

A gaping hole would be created, possibly resulting in severe data loss and/or loss of company secrets.

Cached credentials are just that -- cached. They work for the local machine when it can't connect to the domain, but if that account were disabled they would not work for any network resource (svn, vpn, smb, fbi,cia, etc) so they need not worry about that. Also remember that users already have full rights over any files in their profile folder on a local machine anyway (and likely removable media) so disabled credentials or not they can do what they please with that data. They also wouldn't work for the local machine once it reconnects to the network.

Are you referring to the services that Active Directory or a Domain Controller provides, such as LDAP? If so, LDAP is often broken out securely for purposes of authentication and directory querying, but just turning off the Windows Firewall (or opening all the required ports up to the public - Same thing in this example) could cause severe problems.

AD doesn't truly manage Macs, so a seperate solution would be required (think OS X Server). You can join a Mac to a domain but that does little more than let them auth with network credentials, set domain admins as local admins on the mac, etc. No group policy. MS is trying to breach that ground with newer versions of SCCM that claim to be able to deploy applications to macs and *nix boxes, but I've yet to see it in a production environment. I also believe you could configure the macs to connect to OS X Server which would authenticate to your AD based directory, but I could be wrong.

That being said, some creative solutions could be devised, such as Evan's suggestion for using OpenVPN as a service, and disabling the machine cert if/when the time comes to let that employee go.

It sounds like everything is Google based, so Google is acting as your ldap server? I would recommend my client keep it that way if at all possible. I don't know the nature of your business, but for web based apps such as a git or redmine server, even when setup in house can authenticate with OAuth, taking advantage of a Google account.

Lastly, a roadwarrior setup such as this would almost require a VPN to be successful. Once the machines are brought into the office and configured (or configured remotely by way of script), they need a way of receiving any changes in configuration.

The macs would need a separate management approach in addition to the VPN, it's too bad they don't make real mac servers anymore, but they did have some decent policy implementations in OS X Server the last time I checked (a couple of years ago).