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

Question

I have a client whose workforce is comprised entirely of remote employees using a mix of Apple and Windows 7 PCs/laptops.

The users don't authenticate against a domain at the moment, but the organization would like to move in that direction for several reasons. These are company-owned machines, and the firm seeks to have some control over account deactivation, group policy and some light data-loss prevention (disable remote media, USB, etc.) They are concerned that requiring VPN authentication in order to access AD would be cumbersome, especially at the intersection of a terminated employee and cached credentials on a remote machine.

Most services in the organization are Google-based (mail, file, chat, etc.) so the only domain services are DNS and the auth for their Cisco ASA VPN.

The customer would like to understand why it is not acceptable to expose their domain controllers to the public. In addition, what is a more acceptable domain structure for a distributed remote workforce?

Edit:

Centrify is in use for a handful of Mac clients.

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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).

Answer 5

It's unfortunate that DirectAccess is only available on Win7+ Enterprise Edition, because it's tailor-made for your request. But not knowing your edition, and seeing that you have MacOS, that won't work.

/Edit - looks like some 3rd parties claim that they have DA clients for Unices : http://www.centrify.com/blogs/tomkemp/what_is_microsoft_directaccess_and_unix_linux_interoperability.asp

There are MDM solutions available that can work to meet your needs; we're rolling one of them (MAAS360) out to a client that is in a similar position.

Answer 6

This would obviously be a significant security risk. Furthermore, it probably wouldn't work as well as you'd like. If random people on the Internet are able to attempt logins to your AD environment, odds are good that all your users are going to get locked out. Forever. And removing the lockout requirements means that it gets pretty easy to brute force check for simple passwords.

More importantly, you should have no problems implementing your goal (end users logging into a laptop with domain credentials) without making the AD servers directly accessible. Namely, Windows machines can cache the last X successful logins, so that those same credentials work when disconnected. This means end users can login and do useful work, without needing to touch your AD servers. They'll obviously need to utilize a VPN to connect to other major corporate resources, and can refresh AD/GPO settings at the same time.

Answer 7

Ewwhite,

Your question is extremely valid and deserves a careful review.

All security professionals recommend layers of security in front of any network resource, including SPI Firewalls, IDS, Host Based Firewalls, etc. You should always use a proxy perimeter gateway firewall like ISA (now TMG) when possible.

That said, Microsoft Active Directory 2003+ has had no major vulnerabilities disclosed publicly. LDAP technology and it's hash algorithms are generally very secure. It's arguably more secure than the SSL VPN if that SSL VPN runs OpenSSL and is vulnerable to heartbleed.

I would caution 5 things:

1. Be concerned about the other services that face the network such as Terminal Server, DNS Services, CIFS, and especially IIS with its terrible security record.

2. Use LDAPS with a security certificate to avoid passing clear text domain credentials over the wire. This happens automatically after installing Certificate Services (use a separate machine for PKI)

3. Put a packet sniffer on the interface and watch your traffic, correct any clear text passwords because firewall or not, if your not using a VPN or LDAPS, some legacy systems will send clear text passwords.

4. Know that MITM attacks can force the native authentication mechanisms to downgrade and expose passwords to weaker NTLM authentication.

5. Be aware of some user enumeration vulnerabilities that may still exist.

That said, Active Directory has a great track record for security. Further, MS Active Directory doesn't store passwords, only hashes which may also mitigate the severity of a compromise.

You may benefit from a more seamless security infrastructure, you don't have to set special DNS servers or use domain.local and you can use your actual domain on the public internet such as domain.com.

In my professional opinion there's a substantial benefit to deploying security technologies like Active Directory publicly, where other technologies like Exchange and DNS and Web Servers simply provide no benefit and all the risk.

Note: if you deploy Active Directory it will include a DNS server. Be CERTAIN to disable recursion on your DNS servers (enabled by default) or you will absolutely be participating in denial of service attacks.

Cheers,

-Brian

Answer 8

Dell (via buying Quest (via buying Vintela)) has a cross-platform solution that is deployed frequently in F500 enterprises for this express purpose.

Things to consider...

1. Are your users always connected? If so you will be best served with a flexible VM-based hosting environment that can flex when lots of active users are hammering LDAP
2. Are you running in more than one physical data center? Consider geographic load-balancing in front of the AD services to reduce the number of hops between users and your systems
3. Also, if the answer to #2 is yes, then make sure you set up some dedicated network resources to replicate your forest as depicted here

And make sure your firewall solution is able to handle extremely high re-transmit rates if you have users on throttled uplinks, connecting from noisy wifi centers, etc.