Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

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

ayi

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:
<a href="http://www.centrify.com" rel="noopener nofollow ugc">Centrify</a> is in use for a handful of Mac clients.
<hr>
Source : <a href="http://www.centrify.com" rel="noopener nofollow ugc">Server Fault</a>

ayi_2

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 <code>authoritative</code> 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.
<h2><a name="p-32776-citation-1-1" class="anchor" href="#p-32776-citation-1-1" aria-label="Heading link"></a>Citation #1</h2>
<a href="http://msdn.microsoft.com/en-us/library/windowsazure/jj156090.aspx">Guidelines for Deploying Windows Server Active Directory on Windows Azure Virtual Machines</a>
Before you go “Azure isn’t AD”…you CAN deploy ADDS on an Azure VM.
But to quote the relevant bits:
<blockquote></blockquote>
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.
<h2><a name="p-32776-citation-2-2" class="anchor" href="#p-32776-citation-2-2" aria-label="Heading link"></a>Citation #2</h2>
<a href="http://technet.microsoft.com/en-us/magazine/ff848710.aspx">Active Directory - The UnicodePwd Mystery of AD LDS</a>
<blockquote></blockquote>
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.
<h2><a name="p-32776-citation-3-not-from-msbut-useful-still-in-looking-ahead-3" class="anchor" href="#p-32776-citation-3-not-from-msbut-useful-still-in-looking-ahead-3" aria-label="Heading link"></a>Citation #3 - not from MS…but useful still in looking ahead</h2>
<a href="http://betanews.com/2013/07/12/active-directory-as-a-service-azure-intune-hinting-at-a-cloud-hosted-ad-future/">Active Directory-as-a-Service? Azure, Intune hinting at a cloud-hosted AD future</a>
<blockquote></blockquote>
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.
<h2><a name="p-32776-citation-4-4" class="anchor" href="#p-32776-citation-4-4" aria-label="Heading link"></a>Citation #4</h2>
<a href="http://technet.microsoft.com/en-us/library/dn509513.aspx">Deploy AD DS or AD FS and Office 365 with single sign-on and Windows Azure Virtual Machines</a>
<blockquote></blockquote>
Domain controllers and AD FS servers should never be exposed directly 
to the Internet and should only be reachable through VPN