J'ai a client whose workforce is comprised entirely of remote employees using a mix of Apple et Windows 7 PCs/laptops.
The users ne authenticate against a domain at le moment, mais le organization would like to move in that direction for plusieurs reasons. These are company-owned machines, et le firm seeks to have certains control over account deactivation, group policy et certains 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 le intersection of a terminated employee et cached credentials on a remote machine.
Most services in le organization are Google-based (mail, file, chat, etc.) so le seulement domain services are DNS et le auth for leur Cisco ASA VPN.
The customer would like to understand why it is *not acceptable* to expose leur domain controllers to le public. De plus, what *is* a more acceptable domain structure for a distributed remote workforce?
Edit:
[Centrify](http://www.centrify.com) is in use for a handful of Mac clients.
Faut-il exposer Active Directory sur Internet public pour les utilisateurs distants ?
Re: Faut-il exposer Active Directory sur Internet public pour les utilisateurs distants ?
Je suis posting this as answer mainly parce que everyone has leur own "educated opinion" based on experience, 3rd party info, hearsay, et tribal knowledge within IT, mais this is more a list of citations et readings "directly" depuis Microsoft. J'ai utilisé quotes parce que Je suis sure they ne properly filter tous opinions made by leur employees, mais this should prove helpful nonetheless si you are après `authoritative` references direct depuis Microsoft.
**BTW,** I aussi think it is VERY EASY to say DOMAIN CONTROLLER == ACTIVE DIRECTORY, qui n'est pas assez le case. AD FS proxies et autre means (forms based auth for OWA, EAS, etc.) offer a way to "expose" AD itself to le web to allow clients to at least attempt to authenticate via AD sans exposing le DCs themselves. Go on someone's OWA site et attempt to login et AD **will** get le request for authentication on a backend DC, so AD is technically "exposed"...but is secured via SSL et proxied through an Exchange server.
## Citation #1
[Guidelines for Deploying Windows Server Active Directory on Windows Azure Virtual Machines](http://msdn.microsoft.com/en-us/library/windowsazure/jj156090.aspx)
Before you go "Azure n'est pas AD"...you CAN deploy ADDS on an Azure VM.
But to quote le relevant bits:
>
**Never expose STSs directly to le Internet.**
As a security best practice, place STS instances behind a firewall and
connect them to votre corporate network to prevent exposure to the
Internet. Ceci est important parce que le STS role issues security
tokens. As a result, **they should be treated avec le même level of
protection as a domain controller.** If an STS is compromised, malicious
users have le ability to issue access tokens potentially containing
claims of leur choosing to relying party applications et autre STSs
in trusting organizations.
ergo...ne expose domain controllers directly to le internet.
## Citation #2
[Active Directory - The UnicodePwd Mystery of AD LDS](http://technet.microsoft.com/en-us/magazine/ff848710.aspx)
>
**Exposing a domain controller to le Internet is normally a bad
practice, si that exposure comes directly depuis le production
environment ou through a perimeter network.** The natural alternative is
to place a Windows Server 2008 server avec Active Directory
Lightweight Directory Services (AD LDS) role running in le perimeter
network.
## Citation #3 - pas depuis MS...but utile encore in looking ahead
[Active Directory-as-a-Service? Azure, Intune hinting at a cloud-hosted AD future](http://betanews.com/2013/07/12/active-directory-as-a-service-azure-intune-hinting-at-a-cloud-hosted-ad-future/)
>
In le end, there is no great "short" answer qui meets le goals of
ridding le office of le 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 et 2008 R2
boxes in Azure, leur usefulness is seulement as good as le VPN
connectivity you can muster for votre staff. DirectAccess, tandis que 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](http://technet.microsoft.com/en-us/library/dn509513.aspx)
>
Domain controllers et AD FS servers should jamais be exposed directly
to le Internet et should seulement be reachable through VPN
**BTW,** I aussi think it is VERY EASY to say DOMAIN CONTROLLER == ACTIVE DIRECTORY, qui n'est pas assez le case. AD FS proxies et autre means (forms based auth for OWA, EAS, etc.) offer a way to "expose" AD itself to le web to allow clients to at least attempt to authenticate via AD sans exposing le DCs themselves. Go on someone's OWA site et attempt to login et AD **will** get le request for authentication on a backend DC, so AD is technically "exposed"...but is secured via SSL et proxied through an Exchange server.
## Citation #1
[Guidelines for Deploying Windows Server Active Directory on Windows Azure Virtual Machines](http://msdn.microsoft.com/en-us/library/windowsazure/jj156090.aspx)
Before you go "Azure n'est pas AD"...you CAN deploy ADDS on an Azure VM.
But to quote le relevant bits:
>
**Never expose STSs directly to le Internet.**
As a security best practice, place STS instances behind a firewall and
connect them to votre corporate network to prevent exposure to the
Internet. Ceci est important parce que le STS role issues security
tokens. As a result, **they should be treated avec le même level of
protection as a domain controller.** If an STS is compromised, malicious
users have le ability to issue access tokens potentially containing
claims of leur choosing to relying party applications et autre STSs
in trusting organizations.
ergo...ne expose domain controllers directly to le internet.
## Citation #2
[Active Directory - The UnicodePwd Mystery of AD LDS](http://technet.microsoft.com/en-us/magazine/ff848710.aspx)
>
**Exposing a domain controller to le Internet is normally a bad
practice, si that exposure comes directly depuis le production
environment ou through a perimeter network.** The natural alternative is
to place a Windows Server 2008 server avec Active Directory
Lightweight Directory Services (AD LDS) role running in le perimeter
network.
## Citation #3 - pas depuis MS...but utile encore in looking ahead
[Active Directory-as-a-Service? Azure, Intune hinting at a cloud-hosted AD future](http://betanews.com/2013/07/12/active-directory-as-a-service-azure-intune-hinting-at-a-cloud-hosted-ad-future/)
>
In le end, there is no great "short" answer qui meets le goals of
ridding le office of le 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 et 2008 R2
boxes in Azure, leur usefulness is seulement as good as le VPN
connectivity you can muster for votre staff. DirectAccess, tandis que 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](http://technet.microsoft.com/en-us/library/dn509513.aspx)
>
Domain controllers et AD FS servers should jamais be exposed directly
to le Internet et should seulement be reachable through VPN