49

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.

10
  • 4
    There is a related question HERE. Allowing external services to connect to your AD to synch or authenticate is not a terrible practice but placing your domain controllers on an open DMZ, essentially as you've asked is very insecure. Without security in place you are asking for a variety of potential attacks and issues. I would highly recommend against it and suggest a VPN or VPN client from a firewall such as Sonicwall with local device users. Feb 6, 2014 at 15:36
  • 10
    Setup an always-on, machine-wide, auto-reconnecting, certificate-based VPN. (OpenVPN, DirectAccess, etc) so VPN authentication is not tied to the user accounts, and the user has no direct interaction with the VPN software.
    – Zoredache
    Feb 6, 2014 at 18:01
  • DA is perfect, but has serious endpoint requirements that the customer doesn't meet (Mac, for sure.)
    – mfinni
    Feb 6, 2014 at 18:10
  • 1
    +10 - For Zoredache's suggestion. Feb 6, 2014 at 18:25
  • 7
    If you're backing up end user devices you're doing it wrong. If you're backing up end user devices via USB you're doing it really really wrong.
    – MDMarra
    Feb 7, 2014 at 0:49

8 Answers 8

32

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

1
  • This is a reasonable answer, although only the first citation says anything about what bad things could happen if you disregard the advice.
    – Casey
    Jul 11, 2014 at 13:45
19

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.

5
  • 2
    +1 for the OpenVPN running as a service, I've used this approach with road warriors successfully in the past. There were mixed feelings from the Sr sys admins though, particularly because if a machine was compromised then that's an automatic backdoor into the network. Valid concerns of course, for each environment though on must ask themselves if the benefits outweigh the risk....?
    – MDMoore313
    Feb 6, 2014 at 18:39
  • 2
    Microsoft runs their own corporate network on the public Internet with IPSec. So it's doable. Feb 6, 2014 at 19:05
  • 1
    @MichaelHampton but they use domain isolation with Windows Firewall and IPSec so it's not quite "AD on the Internet" it's "AD on the internet and in a security zone similar to that which a firewall would provide using host-based firewall rules instead"
    – MDMarra
    Feb 6, 2014 at 21:13
  • 2
    @MDMoore313 - Certificate revocation FTW, albeit the user needs to report that stolen machine quickly. Feb 6, 2014 at 23:07
  • There are also ways with certain VPN clients (Juniper for example) to force a logoff after connection. It's not as nice as the old GINA infused ones, but it forces the user to log in again while on the VPN to actually authenticate against AD and get GPOs, etc. You log in first with cached credentials, launch the VPN if needed, and it logs you off immediately and stays connected while you log back in.
    – TheCleaner
    Feb 7, 2014 at 14:01
15

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.

1
14

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

6
  • Actually, Centrify is in use in this environment for managing policy on a handful of Mac systems right now.
    – ewwhite
    Feb 6, 2014 at 19:12
  • @ewwhite what do you mean by manage? It looks like nothing more than a central authentication utility.
    – MDMoore313
    Feb 6, 2014 at 20:38
  • @MDMoore313 you are late by a few hours, I win: chat.stackexchange.com/transcript/127?m=13626424#13626424 -- :)
    – TheCleaner
    Feb 6, 2014 at 20:49
  • @TheCleaner haha it appears so, You win this time, you know the art of Google Fu well, but your technique eludes you In my best Kung Fu with terrible lipsync voice. After you posted your answer I had to search doubly hard to find one that wasn't a duplicate of yours!
    – MDMoore313
    Feb 6, 2014 at 21:03
  • 2
    LOL, no worries...next time we meet the victory might be yours. (in terrible lipsync voice)
    – TheCleaner
    Feb 6, 2014 at 21:04
7

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.

5

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.

3
  • 2
    AD does not use (or at least depend on) broadcasts for anything, for as long as it has been AD, to my knowledge. Certain technologies may require WINS, which can fall back to broadcast requests if there's no WINS server available, but that's not relevant to AD in general. If it depended in broadcasts, you couldn't have remote users without local DCs at all.
    – mfinni
    Feb 6, 2014 at 16:26
  • 2
    Edited that line out. Thanks for the input. Cllearly a Linux guy like me shouldn't guestimate on Windows. Feb 6, 2014 at 18:01
  • If it were so "obvious" it wouldn't be a question, would it?
    – Casey
    Jul 11, 2014 at 13:49
2

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

-3

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.

1
  • How does this manage Windows machines, or secure anything like a DC that is exposed to the internet? It doesn't read like it does, at all.
    – mfinni
    Feb 7, 2014 at 2:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .